LLM API를 호출할 때 실제로 일어나는 일

당신은 느껴본 적이 있을 것입니다.

프롬프트 (prompt)를 입력하고 전송 버튼을 누르면, 1초도 안 되어 응답이 스트리밍 (streaming) 되기 시작합니다. 매끄럽고 즉각적이죠. 마치 기계와 함께 소리 내어 생각하고 있는 듯한 기분이 듭니다.

그러다 다음 날 — 같은 모델 (model), 같은 프롬프트 (prompt) — 당신은 기다립니다. 3초. 5초. 커서가 깜빡입니다. 아무것도 없습니다. 그러다 모든 것이 한꺼번에 쏟아져 나옵니다.

당신은 아마 와이파이 (wifi) 탓을 했을 것입니다.

당신의 와이파이 탓이 아니었습니다.

그 추가적인 몇 초 동안 실제로 일어난 일은, 당신이 절대 방문할 일 없는 건물에서 시작되어, 해저 케이블을 타고 흐르고, 당신의 차례가 오기 전까지 다른 누군가의 생각을 처리하느라 바빴던 GPU (GPU)에서 끝나는 이야기입니다.

그리고 만약 당신이 아프리카나 버지니아 (Virginia), 아일랜드 (Ireland), 프랑크푸르트 (Frankfurt)가 아닌 곳에서 개발하고 있다면 — 그 이야기에는 당신에 관한 특별한 장(chapter)이 포함되어 있습니다.

API 호출 한 번의 여정

당신이 전송 버튼을 누르는 순간부터 단 하나의 요청 (request)을 따라가 봅시다.

당신의 프롬프트 (prompt)는 장치를 떠나 ISP (ISP)를 통해 데이터 패킷 (packets of data) 형태로 이동하고, 해저 광섬유 케이블 (submarine fibre cable)을 치고, 대양을 건너, 데이터 센터 (data centre)에 도착하며, 올바른 서버 (server)로 라우팅 (routed) 되고, 사용 가능한 GPU (GPU)가 생길 때까지 기다렸다가, 처리된 후, 응답 (response)이 같은 경로로 되돌아옵니다.

그 모든 왕복 과정은 아무 일도 일어나지 않은 것처럼 느껴질 정도로 빠르게 일어납니다.

하지만 아무 일도 없는 것이 아닙니다. 모든 단계에는 시간이 소요됩니다. 그리고 지구상 어디에 앉아 있느냐에 따라 그 단계 중 일부는 더 많은 시간을 소모합니다.

데이터 센터란 실제로 무엇인가

흥미로운 부분으로 넘어가기 전에, 기초를 다져봅시다.

데이터 센터 (data centre)는 서버 (servers)로 가득 찬 건물입니다. 때로는 축구장 여러 개 크기에 달하기도 합니다. 그 서버 (servers)들은 화면이 없는 컴퓨터들입니다. 금속 랙 (racks)에 쌓여 있습니다. 수천 개가 존재합니다. 하루 24시간, 일주일 내내, 단 한 번도 꺼지지 않고 작동합니다.

당신이 하는 모든 API (API) 호출, WhatsApp (WhatsApp)에서 보내는 모든 메시지, 모든 구글 (Google) 검색, 모든 유튜브 (YouTube) 영상 — 이 모든 것들은 어딘가에 있는 이런 건물 안의 서버 (server)를 거치게 됩니다.

이 건물(데이터 센터)이 작동하려면 세 가지가 필요합니다: 전력 (power), 냉각 (cooling), 그리고 연결성 (connectivity)입니다. 전력은 서버를 구동합니다. 냉각은 서버가 녹는 것을 방지합니다. 서버는 이 정도의 밀도에서 엄청난 열을 발생시키기 때문입니다. 연결성은 건물을 인터넷의 나머지 부분과 연결하는 광섬유 케이블 (fibre cable)입니다.

나이지리아에는 이런 건물이 17개 있습니다. 미국에는 5,500개가 넘습니다.

그 격차는 중요합니다. 이 부분은 나중에 다시 다루겠습니다.

지연 시간 (latency): 아무도 경고해주지 않은 물리학적 문제

지연 시간 (latency)은 데이터가 지점 A에서 지점 B로 이동했다가 다시 돌아오는 데 걸리는 시간입니다.

이는 물리학에 의해 제한됩니다. 데이터는 광섬유 케이블 (fibre optic cable)을 통해 빛의 속도의 약 3분의 2 속도로 이동합니다. 이보다 더 빠르게 만들 수는 없습니다. 오직 거리를 단축할 수 있을 뿐입니다.

라고스 (Lagos)에서 런던 (London)까지의 거리는 약 5,000km입니다. 빛의 속도의 3분의 2를 기준으로 할 때, 거리만으로 발생하는 최소 왕복 시간 (round-trip time)은 약 50밀리초 (ms)입니다. 여기에 라우팅 (routing), 혼잡 (congestion), 처리 (processing) 과정을 더하면, 요청이 서버에 도달하기도 전에 이미 100~150ms를 보게 됩니다.

그다음 모델이 생각해야 합니다.

그다음 응답이 다시 돌아옵니다.

나이지리아에서 개발하는 대부분의 개발자들은 us-east-1 (버지니아) 또는 eu-west (아일랜드 또는 프랑크푸르트)에 있는 LLM 서버에 접속합니다. 이것은 불평을 하려는 것이 아닙니다. 서버가 그곳에 있기 때문입니다. 하지만 이는 추론 (inference)이 시작되기도 전에 모든 API 호출이 지리적 요인만으로 100~200ms의 지연 시간을 수반한다는 것을 의미합니다.

스트리밍 챗봇 (streaming chatbot)의 경우, 이를 체감하게 됩니다. 첫 번째 토큰 (token)이 나타나기 전의 그 멈춤은 모델이 느려서 발생하는 것이 아닙니다. 그것은 거리에 적용된 빛의 속도 때문입니다.

추론 (inference): GPU가 실제로 하고 있는 일

여러분의 프롬프트 (prompt)가 서버에 도착하면, 검색 엔진이 키워드를 매칭하는 방식처럼 상상하는 방식으로 처리되지 않습니다.

모델은 가장 가능성 높은 다음 토큰이 무엇인지 예측하기 위해, 수십억 개의 수학적 연산을 레이어 (layer)별로 프롬프트에 수행합니다. 그다음 토큰, 그다음 토큰을 예측합니다. 각 토큰은 응답이 완료될 때까지 한 번에 하나씩, 순차적으로 생성됩니다.

이것이 추론 (inference)입니다.

토큰 하나는 대략 단어의 4분의 3 정도 크기입니다. "hello"는 하나의 토큰입니다. "infrastructure"는 두 개의 토큰입니다. 당신이 지금 읽고 있는 이 응답도 수백 개의 토큰으로 이루어져 있을 것입니다.

이것이 왜 중요할까요? 모든 토큰은 연산 비용 (compute cost)을 발생시키기 때문입니다. 프롬프트 (prompt)가 길어질수록 입력 측면에서 더 많은 연산 비용이 들고, 응답이 길어질수록 출력 측면에서 더 많은 비용이 듭니다. 그리고 이 모든 연산은 데이터 센터 내부의 GPU에서 실제 전력을 소비하며 수행됩니다.

GPU: 왜 이 특정 하드웨어인가

당신의 노트북에는 CPU — 중앙 처리 장치 (Central Processing Unit)가 있습니다. 이는 브라우저 실행, 코드 컴파일, 운영 체제 처리와 같은 일반적인 작업을 위해 설계되었습니다. 한 번에 한 가지 일은 매우 빠르게 처리합니다.

GPU — 그래픽 처리 장치 (Graphics Processing Unit) — 는 원래 비디오 게임을 렌더링하기 위해 설계되었습니다. 수천 개의 작은 코어들이 동시에 수많은 계산을 수행할 수 있습니다. 결과적으로 이러한 병렬 아키텍처 (parallel architecture)는 LLM 추론 (inference)에 정확히 필요한 요소임이 밝혀졌습니다. 즉, 수십억 개의 파라미터 (parameters) 전체에 걸쳐 동일한 수학적 연산을 한꺼번에 실행하는 것입니다.

LLM 추론에 사용되는 단일 하이엔드 GPU인 NVIDIA H100은 약 30,000달러에 달합니다. 프런티어 모델 (frontier model)을 실행하는 데이터 센터에는 이러한 GPU가 수천 개 있습니다.

LLM API를 호출하면, 당신의 요청은 이러한 GPU 중 하나로 라우팅 (routing)됩니다. 만약 해당 GPU가 다른 사용자의 요청을 처리하느라 바쁘다면, 당신의 요청은 대기하게 됩니다. 그 대기는 실제 상황이며, 당신 쪽에서는 지연 시간 (latency)으로 나타납니다.

이것이 바로 속도 제한 (rate limits)이 실제로 강제하고 있는 것입니다: 바로 하드웨어의 물리적 용량입니다.

콜드 스타트 (Cold Starts): 왜 첫 번째 요청이 더 느린가

한동안 요청이 없다가 아주 첫 번째 호출을 할 때 눈에 띄게 더 오래 걸리는 것을 경험해 보셨을 것입니다.

이는 착각이 아닙니다. 바로 콜드 스타트 (cold start)입니다.

모델은 거대합니다. 프런티어 모델은 모델이 알고 있는 것을 인코딩하는 숫자들인 가중치 (weights)가 수백 기가바이트에 달할 수 있습니다. 추론이 일어나기 전에 이 가중치들을 GPU 메모리에 로드 (load)해야 합니다. 만약 한동안 요청이 들어오지 않았다면, 시스템은 다른 용도로 메모리를 확보하기 위해 모델을 부분적으로 언로드 (unload)했을 수도 있습니다.

첫 번째 요청은 모델이 다시 로드될 때까지 기다려야 합니다. 이후의 요청들은 이미 활성화된 (warm) 모델에 도달하므로 더 빠르게 느껴집니다.

서버리스 (serverless) LLM 배포는 특히 이러한 현상이 발생하기 쉽습니다. 트래픽이 적을 때는 비용을 덜 지불할 수 있지만, 사용자는 조용한 기간 이후의 첫 번째 요청에서 그 차이를 느끼게 됩니다.

왜 특히 나이지리아인가

나이지리아의 17개 데이터 센터 — 그 중 14개가 라고스(Lagos)에 위치 — 는 거의 전적으로 디젤 발전기에 의존하여 운영됩니다. 국가 전력망은 평균적으로 하루에 4시간의 전력만을 공급합니다. 모든 데이터 센터는 디젤을 태우는 발전기를 24시간 가동하여 그 차이를 메웁니다.

이는 비용이 많이 듭니다. 또한 전력이 안정적인 시장만큼 현지 클라우드 인프라가 확장되지 못한 이유이기도 합니다.

개발자인 당신에게 미치는 결과는 다음과 같습니다: 당신이 수행하는 모든 LLM API 호출은 나이지리아에 있지 않은 서버로 라우팅됩니다. 서아프리카에도 없습니다. 종종 아프리카 대륙 내에 있지도 않습니다. 당신은 모든 사용자 각각의 모든 요청마다 그 거리로 인한 지연 시간 (latency) 비용을 지불하고 있는 것입니다.

이것은 소프트웨어 문제가 아닙니다. 지리 및 인프라의 문제입니다. 그리고 이는 당신의 AI 기반 제품을 사용하는 사람들이 느끼는 체감 성능에 직접적인 영향을 미칩니다.

제품을 구축할 때 의미하는 바

세 가지 실질적인 방법:

응답을 스트리밍 (stream) 하세요. 전체 응답이 올 때까지 기다렸다가 보여주지 마세요. 토큰이 도착하는 대로 스트리밍하면 실제 속도가 더 빠르지 않더라도 경험상 더 빠르게 느껴집니다. 사용자가 무언가 일어나고 있는 것을 보게 되므로 인지된 지연 시간 (perceived latency)이 극적으로 감소합니다.

공격적으로 캐싱 (cache) 하세요. 동일한 프롬프트나 거의 동일한 프롬프트를 반복적으로 호출하고 있다면 응답을 캐싱하세요. 추론 (inference)은 비용이 많이 듭니다. 지연 시간도 비용이 많이 듭니다. 캐싱은 반복되는 쿼리에 대해 이 두 가지를 모두 제거합니다.

작업에 적합한 모델을 선택하세요. 700억 파라미터 (70 billion parameter) 모델은 70억 파라미터 모델보다 느리고 더 비쌉니다. 분류 (classification), 추출 (extraction), 짧은 글 생성 (short-form generation)과 같은 많은 작업의 경우, 더 작은 모델로도 충분하며 결과를 훨씬 더 빠르게 반환합니다. 프런티어 모델 (frontier models)이 항상 정답인 도구는 아닙니다.

더 큰 그림

데이터 센터 (data centres)가 존재하는 이유는 연산 (computation)이 물리적인 어딘가에 존재해야 하기 때문입니다. AI가 마치 노력이 들지 않는 것처럼 느껴지게 만드는 인프라를 운영하려면 전력, 물, 토지, 그리고 연결성 (connectivity)이 필요합니다.

아프리카는 세계 인구의 18%를 차지하고 있지만, 전 세계 데이터 센터 용량의 1% 미만을 차지하고 있습니다. 이 대륙이 생성하는 디지털 수요와 보유하고 있는 인프라 사이의 격차가 바로 지연 시간 (latency)이 발생하는 곳이며, 의존성 (dependency)이 생기는 곳이자, 가치 추출 (value extraction)이 일어나는 곳입니다.

이것이 코드의 문제가 아니라 물리학의 문제라는 점을 아는 것은 관점을 바꾸어 놓습니다. Equinix, AWS, 그리고 Microsoft가 대륙 내 사용 가능한 용량의 대부분을 소유하고 있다는 사실을 아는 것은 이에 대한 생각을 변화시킵니다.

문제는 아마 당신의 코드가 아닐 것입니다. 어딘가에서 디젤로 돌아가고 있는 건물일 것입니다.

AI가 이 글을 조사, 구조화 및 편집하는 데 도움을 주었습니다. 논거, 사례 및 의견은 저의 것입니다. 그 의견들에 잘못된 점이 있다면 그것 또한 저의 책임입니다.