1,400배 늘어난 토큰 수요, 인퍼런스 최적화의 현재와 미래

지난 10월 1일 열린 LG U+ × OptAI Tech Day 'Efficient AI: From Model to Service'에서 베슬에이아이(VESSL AI) 전지환 CTO가 발표한 내용을 블로그로 정리했습니다.

전지환 CTO는 VESSL AI 공동창업자로, 이전에는 Google Spanner의 SRE와 크래프톤·데브시스터즈의 시니어 소프트웨어 엔지니어로 대규모 트래픽을 다뤄왔습니다. 지금은 VESSL AI에서 대규모 GPU 클러스터 운영을 이끌고 있어요.

발표의 결론은 토큰 단가는 계속 내려가지만 작업 한 건에 드는 토큰이 그보다 더 빨리 늘고 있어서, 결국 같은 GPU에서 사용자와의 속도 약속을 지키며 얼마나 많은 토큰을 뽑아내느냐가 인퍼런스 사업의 원가를 결정한다는 것입니다.

핵심 요약

• 토큰 수요는 2년 만에 1,400배 늘었고, 같은 성능의 토큰 단가는 2,400배 떨어졌습니다. 그런데도 시장이 줄지 않는 건 추론형·에이전트형 작업이 작업 1건당 수백만 토큰을 쓰기 때문이에요. a16z의 LLMflation 분석에 따르면 MMLU 42점 수준 모델의 가격은 2021년 백만 토큰당 60달러였습니다.
• 인퍼런스의 기준은 총 처리량이 아니라 약속한 응답 속도(SLO)를 지킨 처리량, 즉 goodput입니다. 이를 끌어올리는 축은 KV 캐시 재사용, prefill과 decode 분리, 양자화와 커널, 드래프트 모델 네 가지예요.
• VESSL AI는 이 네 가지를 쌓아 실제 운영 모델에서 같은 Hopper GPU 기준 처리량을 2.7배로 끌어올렸습니다. 운영 단계에서는 워크로드별 우선순위, 선행 지표 기반 어드미션 컨트롤, 캐시와 부하를 함께 보는 라우팅이 성패를 가릅니다.

토큰 단가가 2,400배 떨어졌는데 왜 인퍼런스 시장은 더 커질까요?

엔비디아 젠슨 황 CEO가 말한 '토큰 팩토리'라는 표현, 한 번쯤 들어보셨을 거예요. 지금 인퍼런스 시장이 어떻게 움직이는지 숫자로 보면 그 의미가 분명해집니다. 2024년 초 하루 0.1조 개 수준이던 토큰 처리량은 2026년 4월 아시아 지역에서만 하루 140조 개를 넘어섰어요. 약 2년 만에 1,400배입니다. 아시아만큼은 아니어도 다른 지역 역시 수백 배씩 늘었고, 올해가 인퍼런스 수요가 학습 수요를 넘어서는 원년이라는 이야기까지 나오고 있습니다.

재미있는 건 같은 기간 토큰 가격이 반대로 움직였다는 점이에요. GPT-3가 처음 나왔을 때 백만 토큰당 60달러였던 가격이, 같은 성능(MMLU 42점 이상) 기준으로 지금은 0.0245달러입니다. 학습 기법과 GPU 활용 기술, 인프라 최적화가 함께 발전한 결과예요. 수요가 1,400배인데 가격이 2,400배 내려갔다면 시장이 반으로 줄어든 걸까요? 전혀 그렇지 않습니다.

AI가 싸고 똑똑해진 만큼 사용자가 맡기는 일의 크기가 달라졌기 때문이에요. 불과 2년 전만 해도 뉴스 요약 한 건에 850토큰, 단문 질의응답에 1,200토큰 정도를 썼다면, 지금은 딥리서치 보고서 한 건에 31만 토큰, 코딩 에이전트가 이슈 하나를 해결하는 데 417만 토큰을 씁니다. 여기에 추론형·에이전트형 응답은 화면에 보이지 않는 추론 과정과 도구 호출, 재시도까지 모두 과금 토큰으로 소비해요. 토큰 단가는 내려갔지만 작업 한 건당 원가는 그대로이거나 오히려 늘어난 셈입니다.

그렇다면 GPU를 많이 사서 클라우드를 지으면 될까요? 그렇게 단순하지 않습니다. Llama 3.1 405B 기준으로 B300은 H200보다 GPU 1장당 시간당 토큰을 3.2배 더 만들지만, 시간당 단가도 2.3배 비싸서 백만 토큰당 비용 차이는 1.4배에 그쳐요. 모델에 따라 어떤 세대에서는 효율이 잘 나오고 어떤 세대에서는 안 나오기도 합니다. 전력도 문제예요. GB300 NVL72 랙 한 대는 142kW를 쓰는데, 일반 랙 평균 7.5kW의 약 19배입니다. 709곳의 데이터센터를 조사한 Uptime Institute 2025 설문에서 50kW 이상 랙을 수용하는 곳은 9%에 불과했어요. 결국 GPU를 얼마나 많이 갖느냐보다 어떤 GPU를 어떻게 효율적으로 운영하느냐가 훨씬 복잡하고 중요한 문제가 됐습니다.

왜 총 처리량이 아니라 SLO를 지킨 처리량을 봐야 할까요?

챗봇이나 코딩 에이전트를 쓸 때 사용자가 기다리는 시간은 두 종류예요. 프롬프트를 보내고 첫 글자가 뜰 때까지 빈 화면을 바라보는 시간이 첫 응답 지연(TTFT, Time To First Token)이고, 첫 글자 이후 답변이 스트리밍으로 이어져 나오는 속도가 토큰 간 지연(TPOT, Time Per Output Token)입니다. 기술적으로는 입력 전체를 읽어 계산하는 구간을 prefill, 토큰을 하나씩 이어 붙이는 구간을 decode라고 불러요.

코딩 에이전트로 예를 들어볼게요. 출력 500토큰짜리 응답 한 건을 받는 데 첫 응답 20초, 초당 20토큰이면 45초가 걸립니다. 기다리다 지쳐서 다른 일을 하게 되고 흐름이 끊기는 수준이에요. 현재 주요 코딩 에이전트의 통상 수준인 첫 응답 4.5초, 초당 60토큰이면 12.8초로, 사용자가 참고 기다릴 수 있는 거의 최대치입니다. 이걸 첫 응답 1초, 초당 250토큰까지 끌어올리면 3초 안에 끝나요. 말 그대로 생각하는 속도로 코딩할 수 있게 되는 거죠. 에이전트는 한 작업이 여러 단계를 돌기 때문에 이 차이가 단계마다 반복해서 쌓입니다.

goodput은 약속한 첫 응답 지연과 생성 속도(SLO)를 지키면서 만든 토큰만 센 처리량입니다. 지연과 상관없이 초당 만든 토큰을 모두 더한 총 처리량과는 다른 지표예요. GPU를 열심히 돌려 토큰을 많이 만들기만 하면 되는 게 아닌 이유가 여기에 있습니다. 동시 요청을 계속 늘리면 GPU당 총 처리량은 올라가지만, 어느 지점부터는 사용자 한 명당 대기 시간이 길어져 서비스를 쓸 수 없게 돼요. 느리게 오는 답은 사실상 오지 않는 답과 같습니다. 사용자가 기다리지 않고 떠나버리니까요. 반대로 속도만 지키려고 사용자를 적게 받으면 GPU가 만들 수 있는 만큼 토큰을 팔지 못해 사업이 성립하지 않습니다. 약속한 첫 응답 지연과 생성 속도를 지키면서 만든 토큰, 즉 goodput을 최대로 끌어올리는 균형이 인퍼런스 서비스의 핵심이에요.

goodput을 끌어올리는 네 가지 기술은 무엇일까요?

클라우드에서 효율적인 AI를 만드는 핵심은 네 가지로 정리됩니다. 이미 계산한 앞부분을 다시 계산하지 않는 KV 캐시 재사용, 성격이 다른 두 단계를 다른 서버로 나누는 prefill과 decode 분리, 서빙할 GPU 세대에 맞춰 모델과 연산을 다시 맞추는 양자화와 커널, 그리고 작은 모델이 먼저 쓰고 큰 모델이 한 번에 검증하는 드래프트 모델이에요.

첫째, KV 캐시 재사용입니다

가장 중요한 축이에요. 같은 요청이라도 캐시 적중률이 얼마냐에 따라 같은 GPU의 처리량이 몇십 퍼센트가 아니라 몇 배 단위로 갈립니다. 코딩 에이전트를 쓰다 보면 긴 대화인데도 어떤 요청은 금방 오고 어떤 요청은 1~2분씩 걸리는 경험을 하셨을 거예요. 빨리 오는 요청은 GPU가 열심히 일해서가 아니라, 앞선 턴을 이미 계산해둔 캐시를 불러와 남은 부분만 계산했기 때문입니다.

숫자로 보면 차이가 더 분명해요. 캐시 적중률 99%인 서비스와 70%인 서비스를 비교해 볼게요. 29%포인트 차이처럼 보이지만, 캐시를 못 써서 GPU로 다시 계산해야 하는 비율로 보면 1% 대 30%, 즉 GPU를 30배 더 쓰느냐의 차이예요. 실제로 VESSL AI가 캐시 인프라 장애를 잡아 적중률을 46%에서 94%로 복구했을 때 같은 장비의 처리량이 80% 늘었습니다. 그래서 요즘 중국의 오픈소스 모델 기업들, 미국의 인퍼런스 기업들, 국내 플랫폼 기업들이 모두 KV 캐시 중심 아키텍처(KV cache-centric architecture)에 가장 큰 초점을 맞추고 있어요.

캐시는 보통 여러 계층에 나눠 저장합니다. 가장 빠르지만 용량이 작은 GPU 메모리(HBM)에는 진행 중인 대화를, 조금 느리지만 용량이 큰 CPU 메모리(DRAM)에는 최근 세션을, 가장 느리지만 가장 큰 로컬 SSD에는 자주 쓰지 않는 컨텍스트를 둬요. 아무리 느려도 GPU로 다시 계산하는 것보다는 낫다면 아래 계층에라도 저장해두는 거죠. 계층별 속도와 규모를 감안해 캐시 구조를 설계하는 것이 중요합니다.

둘째, prefill과 decode 분리입니다

P/D 분리는 입력을 읽는 prefill 단계와 토큰을 만드는 decode 단계를 서로 다른 GPU 서버에 나눠 맡기는 서빙 구조입니다. 이렇게 나누는 이유는 두 단계의 병목이 다르기 때문이에요. prefill은 입력 전체를 한 번의 대규모 행렬 연산으로 처리하기 때문에 GPU 연산량이 병목이고, decode는 토큰 하나를 만들 때마다 모델 가중치와 KV 캐시 전체를 다시 읽기 때문에 메모리 대역폭이 병목이에요. 개인이 요청 한두 건을 처리할 때는 티가 안 나지만, GPU 한 장이 수십, 수백 명의 요청을 감당하는 클라우드에서는 두 단계가 같은 GPU에서 섞이면 서로를 방해합니다.

부하가 걸리면 문제가 더 커져요. 진행 중인 decode 사이사이에 새 요청의 prefill이 끼어들면, 생성 속도가 빨라졌다 느려졌다를 반복하며 불안정해집니다. 사용자 입장에서는 들쭉날쭉한 서비스로 느껴지죠. 두 단계를 서버 단위로 분리하면 decode가 decode에만 집중할 수 있어 속도가 일정해지고, 단계별로 필요한 GPU 종류와 규모를 따로 고를 수도 있어요. 예를 들어 prefill에는 연산 효율이 좋은 적당한 GPU를, decode에는 비싼 고대역폭 HBM을 가진 GPU를 쓰는 식입니다. 이 구조는 vLLM, SGLang, NVIDIA Dynamo 같은 주요 서빙 스택이 기본으로 지원하는 방향으로 확산되고 있어요.

셋째, 양자화와 커널입니다

GPU 세대에 따라 16비트, 8비트, 최근에는 4비트까지 정밀도를 낮춰 서빙할 수 있습니다. 문제는 압축만 한다고 끝나지 않는다는 거예요. Hopper 이전 세대에는 4비트(FP4) 연산을 처리하는 텐서 코어가 없어서, 4비트로 압축한 모델을 올려도 결국 16비트로 다시 풀어 계산하게 됩니다. 이 디퀀트 오버헤드 때문에 오히려 서빙이 느려지기도 해요. 압축으로 얻은 정밀도를 서빙할 GPU에서 실제로 활용할 수 있느냐가 핵심이고, 그래서 GPU 세대 전용 커널을 따로 작성하는 작업이 뒤따릅니다.

VESSL AI는 B300의 네이티브 포맷인 NVFP4로 모델을 직접 재양자화해 메모리 점유를 854GB에서 230GB로 줄이고, 처리량 17.9% 증가와 지연 33.9% 감소를 얻었습니다. 공식 커널이 지원하지 않는 SM90 세대 GPU에서는 커널을 직접 작성해 연산 속도를 2.3배 끌어올렸어요.

넷째, 드래프트 모델입니다

투기적 추론(speculative decoding)이라고도 불러요. 정확도는 조금 낮지만 훨씬 작은 모델이 여러 토큰 후보를 먼저 만들고, 타깃 모델이 이 후보를 한 번에 검증하는 방식입니다. 드래프트 모델을 잘 학습시키면 한 스텝에 적게는 2~3개, 많게는 6~7개 토큰을 한 번에 채택할 수 있어요. 결과는 타깃 모델 단독으로 생성한 것과 동일해서 품질 손실 없이 decode만 빨라집니다. DeepSeek, 알리바바 Qwen을 비롯해 많은 모델 업체가 이 기법을 적용한 모델을 내놓고 있어요.

다만 이득이 늘 생기는 건 아닙니다. 드래프트 생성 비용이 이득보다 크면 오히려 느려지고, 같은 구성이라도 한가할 때는 1.5배 빠르다가 요청이 몰리면 1.4배 느려지는 반전이 생기기도 해요. 도입 전에 확인할 트레이드오프는 Speculative Decoding 도입 전에 확인해야 할 것들에서 자세히 다뤘습니다.

네 가지를 쌓으면 처리량은 얼마나 달라질까요?

모델 회사가 서빙 플랫폼을 고를 때 가장 중요하게 보는 건 속도와 정확도예요. 그래서 VESSL AI는 주어진 모델을 그대로 올리지 않고 앞의 기법들을 최대한 활용해 효율을 끌어올립니다. 실제 운영 중인 대형 오픈소스 모델을 Hopper GPU에서 서빙한 사례에서는 KV 캐시 재사용, 양자화와 커널, 드래프트 모델, P/D 분리를 차례로 쌓아 최적화 전 대비 처리량을 2.7배로 높였어요. 같은 GPU로 2.7배의 토큰을 서빙할 수 있게 된 셈입니다.

실제 서비스에서는 무엇을 더 고려해야 할까요?

워크로드 성격에 따라 최적화 우선순위가 달라집니다

같은 모델이라도 쓰는 패턴이 다르면 최적화 전략이 달라져요. "오늘 날씨 어때?", "우산 챙기세요" 같은 두세 턴짜리 대화형 서비스는 짧은 요청을 얼마나 많이, 빨리 처리하느냐가 중요하고 첫 응답 지연과 배칭이 우선입니다. 반면 코딩 에이전트는 수만에서 100만 토큰에 가까운 긴 대화가 여러 턴에 걸쳐 이어지기 때문에 앞선 맥락을 잘 캐싱하는 게 무엇보다 중요해요. 지연이 무관하고 양만 많은 배치 작업은 처리량과 양자화가 핵심이고요. 같은 최적화를 모든 워크로드에 일괄 적용하면 어느 한쪽에는 반드시 맞지 않습니다. 들어오는 트래픽의 성격을 먼저 보고 전략을 정해야 해요.

특히 코딩 에이전트는 매 턴마다 직전 대화와 코드 저장소 컨텍스트를 통째로 다시 보냅니다. 캐시가 맞으면 새 입력만 계산하면 되지만, 못 맞히면 턴이 쌓일수록 계산량이 누적돼요. 캐시를 잘 탔을 때와 못 탔을 때의 GPU 부담은 20~30%가 아니라 많게는 30~40배까지 벌어집니다.

감당할 수 있는 만큼만 받는 어드미션 컨트롤

사용자 입장에서 요청이 한없이 느리게 오는 것과 "지금은 바쁘니 1분 뒤에 다시 와주세요"라는 응답 중 어느 쪽이 나을까요? 후자예요. 이러지도 저러지도 못하고 기다리는 것보다 깔끔하게 돌려받는 편이 시간을 아낄 수 있습니다. 그래서 서비스는 요청을 무작정 다 받지 않고, 감당할 수 있는 만큼만 받다가 넘치면 적당히 돌려보내야 해요. 이걸 어드미션 컨트롤이라고 부릅니다.

쉬워 보이지만 타이밍이 어렵습니다. 식당에 비유하면, 손님이 이미 꽉 찬 뒤에 "더는 못 받아요"라고 하면 늦어요. 그때는 이미 기다리던 손님들이 화를 내고 평점 1점을 남기고 있죠. GPU 사용률, 응답 지연, SLO 위반율은 고객이 이미 불편을 겪은 뒤에 올라가는 후행 지표라서 이걸 보고 차단하면 사후 조치가 됩니다. 서비스에 실제 영향을 주기 전에 움직이고, 진동 없이 연속적이며, GPU 세대나 엔진과 무관하게 일정하게 측정되는 선행 지표를 찾아 그 신호로 선제적으로 제어하는 것이 중요해요.

캐시 적중과 부하 분산을 함께 보는 라우팅

서비스가 커지면 GPU 한두 장이 아니라 수십, 수백, 수천 장으로 운영합니다. 그러면 요청을 어느 GPU 워커로 보내야 캐시를 가장 잘 쓸 수 있는지 라우터 단에서 판단해야 해요. 캐시 적중을 관리하지 못하면 서비스를 운영할 수 없습니다.

그런데 캐시 적중만 보고 라우팅하면 쏠림이 생겨요. 처음 1번 워커로 간 사용자는 계속 1번으로만 가게 되고, 긴 대화를 오래 이어가는 사용자들이 몰린 워커는 부하가 쌓이다 무너집니다. 공개 벤치마크에서도 프리픽스 적중만 기준으로 라우팅하면 첫 응답 지연이 140초를 넘고 요청 성공률이 55%까지 떨어졌지만, 프리픽스와 부하를 함께 고려하면 첫 응답 지연이 거의 0, 성공률 100%를 기록했어요. 캐시 적중률을 최대한 높이되 부하 불균형이 임계를 넘으면 분산으로 돌리는 균형점은, 결국 서비스를 운영하며 경험적으로 찾아야 합니다.

인퍼런스 최적화는 앞으로 어디로 갈까요?

모델 서비스의 원가, 즉 매출과 이익이 나느냐는 세 가지의 곱으로 결정됩니다. 모델 자체를 얼마나 작게 만드느냐(모델 최적화), 같은 모델을 얼마나 싸게 서빙하느냐(서빙 최적화), 그리고 운영 과정에서 SLO를 얼마나 잘 지키느냐(운영)예요. 발표에서는 이 흐름 위에서 지금 진행 중인 세 갈래의 개선 시도를 소개했습니다.

커널을 하나로 묶는 메가커널

토큰 하나를 생성할 때 함수 한 번만 호출하면 되는 게 아니라 여러 개의 커널이 순서대로 실행되고, 그때마다 중간 결과가 HBM과 텐서 코어 사이를 왕복합니다. 이 왕복이 쌓이면 수백 마이크로초에서 수 밀리초가 돼요. 토큰 하나를 7~8밀리초, 길어도 20밀리초 안에 만들어야 하는 지금은 1밀리초도 아깝습니다. 그래서 디코드 한 스텝 전체를 하나의 커널로 묶는 메가커널이 주목받고 있어요. 스탠퍼드 Hazy Research의 2025년 연구에서 시작된 흐름입니다. 다만 사용자당 속도는 1.9배 빨라지는 대신 GPU당 처리량은 0.67배로 줄어드는 트레이드오프가 있어서, 어디에 적용할지 신중하게 골라야 해요. 모델이 나오는 속도를 사람이 커널로 따라잡기 어려워지면서, 에이전트가 커널을 작성하게 하는 시도도 활발합니다.

캐시를 덜 만들도록 모델을 설계하기

KV 캐시가 그렇게 중요하다면 캐시 자체를 작게 만들면 같은 하드웨어로 훨씬 많은 요청을 처리할 수 있지 않을까요? 이 발상에서 나온 흐름이에요. 불과 작년 모델인 GLM-4.7은 토큰당 KV 크기가 약 368KiB였지만, 압축·희소 어텐션을 도입한 GLM-5는 약 88KiB, 선형 어텐션으로 층을 교체한 GLM-5.3-Flash는 약 11KiB로 33분의 1까지 줄었습니다. 다만 캐시가 작아지면 저장할 수 있는 맥락의 정밀도도 줄어들기 때문에 정확도와의 트레이드오프가 있어요. 이 균형을 고려해 모델 구조를 설계하는 것이 지금 많은 모델 팀이 고민하는 주제입니다.

KV 캐시 전용 스토리지 계층의 등장

마지막은 하드웨어입니다. 지금까지 KV 캐시는 GPU 메모리, CPU 메모리, SSD 사이를 오갔는데, NVIDIA는 그 사이에 KV 캐시 전용 계층을 새로 만들었어요. 이더넷으로 연결된 플래시 기반의 컨텍스트 메모리 계층으로, 파드 단위 PB급 용량을 BlueField-4로 묶는 구조입니다. 데이터센터 단위에서도 캐시를 그만큼 중요하게 보고 있다는 뜻이고, 여러분이 쓰는 코딩 에이전트와 채팅 서비스가 이런 시도들 위에서 돌아가고 있어요.

마무리: 토큰 단가가 아니라 작업 1건당 원가의 시대

정리하면 이렇습니다. 토큰 단가는 크게 떨어졌지만 에이전트형 작업의 난이도가 올라가면서 작업당 토큰이 폭증해 그 하락을 상쇄했어요. 그래서 이제 비용을 재는 단위는 토큰 단가가 아니라 작업 1건당 원가입니다. 그 원가를 낮추는 기준은 GPU에서 토큰을 많이 뽑는 것이 아니라 사용자와의 속도 약속을 지키며 뽑는 것이고, 캐시 최적화, P/D 분리, 양자화와 커널, 드래프트 모델을 쌓아 최대한 효율적으로 서빙하는 노력이 그 답이에요. 그리고 단일 요청 벤치마크의 숫자와 실제 부하 상태의 운영 성능은 별개라서, 워크로드에 맞춘 우선순위와 선행 지표 기반 운영이 마지막 차이를 만듭니다.

VESSL AI는 대규모 GPU 클러스터를 직접 운영하며 이런 인퍼런스 최적화를 실제 서비스에 적용하고 있습니다. 모델 서빙 효율화나 GPU 도입이 고민이라면 언제든 문의해 주세요.

GPU 인프라 상담 신청하기

자주 묻는 질문

이어 읽기

에이전틱 AI 시대의 GPU 인프라 신뢰성 엔지니어링

수천 장에서 수십만 장 규모의 클러스터에서 장애는 없앨 수 있는 변수가 아니라 설계의 전제입니다. 감지, 자동화, SLO 관리라는 세 층위로 장비 증설 없이 SLO를 지킨 처리량을 2.7배로 끌어올린 VESSL AI의 운영 방식을 정리했습니다.

VESSL AI Blog

Speculative Decoding 도입 전에 확인해야 할 것들

decode는 몇 자릿수 차이로 memory-bound 상태입니다. 닫힌 형태의 방정식 하나로 speculation이 그 낭비를 얼마나 되찾고 다른 곳에서 무엇을 치르는지 계산할 수 있습니다.

VESSL AI Blog

토큰 수출국이 되려면, 토큰 공장의 진짜 주인이어야

안재만 베슬AI 대표가 전자신문에 기고한 글 전문이에요. 18.4GW·550조원 AI 데이터센터 구상에서 GPU 자산을 누가 보유하고 운영하느냐를 묻고, 지원사업 평가에 더할 네 가지 기준을 제안했어요.

VESSL AI Blog