What Actually Happens When You Call an LLM API
you've felt it. you type a prompt, hit send, and the response starts streaming in under a second....
개요 #
같은 모델에 같은 프롬프트를 넣었는데 어제는 1초 만에 응답이 흘러나오고 오늘은 5초를 기다린다. 대부분 와이파이를 탓하지만, 진짜 원인은 다른 데 있다. 당신의 요청은 기기를 떠나 해저 광케이블을 타고 바다를 건너, 버지니아나 아일랜드 어딘가의 데이터센터에 도착한 뒤, 다른 사용자의 연산을 처리하던 GPU가 비기를 기다렸다가 돌아온다.
Daniel Nwaneri는 이 왕복 여정을 단계별로 뜯어보며, 우리가 흔히 겪는 지연이 코드 문제가 아니라 물리학과 지리, 인프라의 문제라고 설명한다. 특히 서버가 자기 대륙에 없는 개발자에게 이 이야기는 남의 일이 아니다.
API 호출 한 번의 여정 #
요청 하나를 처음부터 끝까지 따라가 보자. 프롬프트는 기기를 떠나 데이터 패킷 형태로 ISP를 거치고, 해저 광케이블에 올라타 바다를 건넌다. 데이터센터에 도착하면 알맞은 서버로 라우팅되고, GPU가 빌 때까지 대기했다가 처리되며, 응답은 왔던 길을 그대로 되짚어 돌아온다.
체감상으로는 순식간이다. 하지만 각 단계는 저마다 시간을 잡아먹는다. 그리고 몇몇 단계는 당신이 지구의 어디에 앉아 있느냐에 따라 훨씬 더 비싼 값을 치른다.
데이터센터라는 물리적 건물 #
데이터센터는 결국 건물이다. 축구장 몇 개 넓이의 공간에 화면 없는 컴퓨터, 즉 서버 수천 대가 금속 랙에 쌓여 하루 24시간 쉬지 않고 돌아간다. 우리가 보내는 모든 API 호출, 메신저 메시지, 검색, 동영상은 어딘가의 이런 건물 속 서버를 건드린다.
이 건물이 돌아가려면 전력, 냉각, 연결성 세 가지가 필요하다. 전력은 서버를 돌리고, 냉각은 고밀도로 쌓인 서버가 뿜는 엄청난 열을 식히며, 연결성은 건물을 인터넷 전체와 잇는 광케이블이다.
여기서 원문이 짚는 격차가 등장한다. 나이지리아에는 이런 건물이 17개 있다. 미국에는 5,500개가 넘는다.
지연: 아무도 경고해주지 않은 물리 문제 #
지연(latency)은 데이터가 A에서 B까지 갔다가 돌아오는 데 걸리는 시간이다. 그리고 이 값은 물리 법칙에 묶여 있다. 데이터는 광케이블 안에서 빛의 약 3분의 2 속도로 움직인다. 더 빠르게 만들 수는 없고, 거리를 줄이는 것만 가능하다.
라고스에서 런던까지는 약 5,000km다. 빛의 3분의 2 속도로 계산해도 거리만으로 왕복 최소 50ms가 든다. 여기에 라우팅과 혼잡, 처리 시간이 더해지면 요청이 서버에 닿기도 전에 이미 100~150ms가 쌓인다. 그다음 모델이 생각을 하고, 응답이 다시 돌아온다.
나이지리아에서 개발하는 대부분은 버지니아(us-east-1)나 아일랜드·프랑크푸르트(eu-west)의 LLM 서버를 호출한다. 불평이 아니라 서버가 거기 있으니 어쩔 수 없다. 다만 그 탓에 추론이 시작되기도 전에 모든 API 호출이 지리적 거리만으로 100~200ms의 지연을 짊어진다. 스트리밍 챗봇에서 첫 토큰이 나오기 전의 그 멈칫거림은 모델이 느린 게 아니라, 거리에 적용된 빛의 속도다.
추론: GPU가 실제로 하는 일 #
프롬프트가 서버에 도착하면, 검색 엔진처럼 키워드를 맞춰보는 방식으로 처리되지 않는다. 모델은 프롬프트를 수십억 번의 수학 연산에 통과시켜 층층이 계산하며, 다음에 올 가장 그럴듯한 토큰 하나를 예측한다. 그리고 다음 토큰, 또 그다음 토큰을 하나씩 순차적으로 만들어 응답이 끝날 때까지 반복한다. 이 과정이 추론(inference)이다.
토큰은 대략 단어의 4분의 3 정도다. "hello"는 한 토큰, "infrastructure"는 두 토큰으로 쪼개진다. 이 글 정도의 응답이면 수백 토큰이 든다. 왜 중요할까. 토큰 하나마다 연산 비용이 붙기 때문이다. 입력 프롬프트가 길면 입력 쪽 연산이, 응답이 길면 출력 쪽 연산이 늘고, 그 모든 계산은 실제 전기를 태우는 데이터센터의 GPU에서 벌어진다.
GPU: 왜 하필 이 하드웨어인가 #
노트북의 CPU는 브라우저 실행, 코드 컴파일, 운영체제 처리 같은 범용 작업을 위해 설계됐다. 한 번에 하나씩 아주 빠르게 처리한다. 반면 GPU는 원래 게임 화면을 그리려고 만든 물건이다. 작은 코어 수천 개가 동시에 계산을 수행하는 이 병렬 구조가, 수십억 개 파라미터에 같은 연산을 한꺼번에 돌려야 하는 LLM 추론에 딱 들어맞았다.
LLM 추론에 쓰이는 고급 GPU 한 장, 엔비디아 H100은 약 3만 달러다. 프런티어 모델을 돌리는 데이터센터는 이걸 수천 장 갖추고 있다. API를 호출하면 요청은 이 GPU 중 하나로 라우팅되는데, 그 GPU가 다른 사용자의 요청을 처리 중이면 당신 요청은 기다린다. 그 대기 시간은 실재하며, 당신 쪽에서 지연으로 나타난다. 레이트 리밋이 실제로 강제하는 건 바로 이 하드웨어의 물리적 처리 용량이다.
콜드 스타트: 첫 요청이 유독 느린 이유 #
한동안 안 쓰다가 처음 부른 호출이 눈에 띄게 오래 걸린 적이 있을 것이다. 착각이 아니라 콜드 스타트(cold start)다.
모델은 크다. 프런티어 모델은 가중치, 즉 모델이 아는 것을 담은 숫자들만 수백 기가바이트에 이른다. 추론이 시작되려면 이 가중치가 GPU 메모리에 올라와 있어야 하는데, 한동안 요청이 없으면 시스템이 다른 작업을 위해 메모리를 비우려고 모델을 일부 내려놓기도 한다. 그러면 첫 요청은 모델이 다시 올라오기를 기다려야 하고, 뒤이은 요청들은 이미 데워진 모델에 닿아 더 빠르게 느껴진다. 트래픽이 적을 때 비용을 아끼는 서버리스 LLM 배포일수록 이 현상이 잘 나타나는데, 대신 조용한 시간이 지난 뒤 첫 사용자가 그 대가를 체감한다.
왜 하필 나이지리아인가 #
나이지리아의 데이터센터 17개 중 14개는 라고스에 있고, 거의 전부가 디젤 발전기로 돌아간다. 국가 전력망이 하루 평균 네 시간만 전기를 공급하는 탓에, 데이터센터들은 그 부족분을 발전기로 종일 디젤을 태워 메운다. 비용이 많이 들고, 전력이 안정적인 시장처럼 로컬 클라우드 인프라가 확장되지 못한 이유이기도 하다.
개발자 입장에서 이게 뜻하는 바는 분명하다. 당신이 날리는 모든 LLM API 호출은 나이지리아에도, 서아프리카에도, 심지어 그 대륙에도 없는 서버로 향한다. 그 거리에 따른 지연 비용을 요청마다, 사용자마다 매번 치른다. 이건 소프트웨어 문제가 아니라 지리와 인프라의 문제이고, AI 제품이 사용자에게 어떻게 느껴지는지에 직접 영향을 준다.
그래서 만들 때 무엇을 해야 하나 #
원문은 실천 가능한 세 가지를 제안한다.
응답을 스트리밍하라. 전체 응답이 완성되기를 기다렸다가 한꺼번에 보여주지 말자. 토큰이 도착하는 대로 흘려보내면, 실제로 빨라지지 않아도 체감 속도는 크게 올라간다. 사용자가 무언가 일어나고 있음을 보기 때문이다.
적극적으로 캐싱하라. 같거나 거의 같은 프롬프트를 반복해서 호출한다면 응답을 캐시하자. 추론도 비싸고 지연도 비싸다. 캐싱은 반복 질의에서 이 둘을 한꺼번에 없앤다.
작업에 맞는 모델을 골라라. 700억 파라미터 모델은 70억 파라미터 모델보다 느리고 비싸다. 분류, 추출, 짧은 생성 같은 작업이라면 작은 모델로 충분하고 결과도 훨씬 빠르게 돌아온다. 프런티어 모델이 늘 정답은 아니다.
더 큰 그림 #
데이터센터가 존재하는 이유는 연산이 물리적 어딘가에 살아야 하기 때문이다. AI를 매끄럽게 느끼게 하는 인프라를 돌리려면 전력, 물, 땅, 연결성이 필요하다. 아프리카는 세계 인구의 18%가 사는데도 전 세계 데이터센터 용량의 1%도 차지하지 못한다. 대륙이 만들어내는 디지털 수요와 실제로 소유한 인프라 사이의 이 간극에서 지연이, 의존이, 그리고 가치의 유출이 생겨난다.
지연이 코드가 아니라 물리학의 문제임을 알면 어디를 봐야 할지가 바뀐다. 그리고 그 대륙의 쓸 만한 용량 대부분을 Equinix, AWS, Microsoft가 쥐고 있다는 사실을 알면, 그 문제를 어떻게 바라볼지가 바뀐다. 아마 당신 코드 탓이 아니다. 어딘가에서 디젤로 돌아가고 있는 건물 탓이다.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.