AI 토큰 한 개가 데이터센터를 통과하는 길
토큰은 LLM이 텍스트를 처리하고 생성하는 단위이자 API 과금의 기준이다. 같은 내용도 언어와 모델의 토크나이저에 따라 토큰 수가 달라진다.
긴 입력을 처리하는 프리필은 대체로 연산 집약적이고 한 토큰씩 생성하는 디코드는 작은 배치에서 메모리 대역폭의 영향을 크게 받는다. 배칭, 양자화, KV 캐시, 프리필-디코드 분리는 이 병목을 줄이기 위한 기술이다.
GB200 NVL72처럼 랙당 소비전력이 약 120kW에 이르는 시스템이 등장하면서 전력과 냉각은 추론 인프라의 핵심 제약이 됐다. 다만
tokens per watt는 같은 모델·품질·지연 조건에서 비교해야 의미가 있다.
엔터를 누릅니다. 커서가 잠깐 멈춘 뒤 첫 토큰이 화면에 나타납니다. 그사이 질문은 토큰 ID로 바뀌고 여러 서버와 가속기, 메모리와 네트워크를 거쳐 답으로 돌아옵니다.
최근 Data Gravity에 올라온 「How an AI Token Travels Through a Data Center」는 이 과정을 15단계로 나눠 설명합니다. 실제 구현은 서비스와 모델 규모에 따라 다릅니다. 단일 GPU에서 끝나는 요청도 있고 TPU나 전용 가속기를 사용하는 서비스도 있습니다. 따라서 이 15단계는 모든 시스템에 공통된 고정 경로라기보다 대규모 LLM 서빙을 이해하기 위한 참조 모델에 가깝습니다.
엄밀히 말하면 토큰 하나가 독립적으로 데이터센터를 여행하는 것도 아닙니다. 입력 요청이 묶음으로 처리된 뒤 출력 토큰이 하나씩 생성됩니다. 이 글에서는 편의상 그 과정을 ‘토큰의 여정’이라고 부르겠습니다.
이 여정이 중요한 이유는 추론의 비중이 빠르게 커지고 있기 때문입니다. Deloitte는 2026년 추론이 전체 AI 컴퓨팅의 약 3분의 2를 차지할 것으로 전망했습니다. 이제는 모델을 학습시키는 비용뿐 아니라 학습된 모델을 계속 운영하는 비용도 따져야 합니다.
토큰의 여정
15단계 전체를 크게 묶으면 다음과 같습니다.
입장: 입력이 토큰 ID 목록으로 바뀌고 API 게이트웨이가 인증과 사용 한도를 확인합니다. 이후 로드밸런서와 추론 라우터가 요청을 처리할 모델 인스턴스를 고릅니다.
배차: 스케줄러가 여러 사용자의 요청을 배치로 묶습니다. GPU가 가중치를 한 번 읽을 때 여러 요청을 함께 처리해 활용률을 높이기 위해서입니다.
생성: 프리필이 입력을 처리하고 KV 캐시를 만든 뒤, 디코드가 출력 토큰을 순서대로 생성합니다. 모델이 여러 GPU에 나뉘어 있다면 이 과정에 GPU 간 통신도 들어갑니다.
귀로: 생성된 토큰 ID가 다시 텍스트로 바뀌고 네트워크를 통해 사용자 화면에 스트리밍됩니다.
이제 시간과 비용이 크게 달라지는 지점인 토큰화, 프리필·디코드, KV 캐시, 네트워크와 전력을 차례로 보겠습니다.
토큰은 처리와 과금의 단위
LLM은 문장을 그대로 읽지 않습니다. 텍스트를 토큰이라는 조각으로 나누고 각 토큰을 정수 ID로 바꿔 처리합니다. 토큰은 한 글자일 수도, 단어의 일부나 자주 쓰이는 단어 전체일 수도 있습니다.
토크나이저의 어휘 크기와 분할 방식은 모델마다 다릅니다. 최근 모델의 어휘집은 대체로 수만 개에서 수십만 개 항목으로 구성되지만 정해진 표준은 없습니다. 같은 문장도 어느 모델에 입력하느냐에 따라 토큰 수가 달라지는 이유입니다.
영어 이외의 언어가 영어보다 더 많은 토큰으로 분할되는 현상은 여러 연구에서 확인됐습니다. 다만 “한국어는 항상 영어보다 두세 배 비싸다”고 일반화할 수는 없습니다. 토큰 수는 토크나이저의 학습 데이터와 어휘 배분, 문체, 번역 방식에 따라 크게 달라집니다. 정확한 비용을 계산하려면 실제로 사용할 모델의 토크나이저로 입력 데이터를 측정해야 합니다.
규모부터 보겠습니다. Google은 2026년 5월 I/O 키노트에서 자사 제품과 API 전반이 한 달에 3,200조 개가 넘는 토큰을 처리한다고 밝혔습니다. 1년 전 발표한 월 480조 개의 약 7배입니다. 이 수치는 입력과 출력의 구분이나 서비스별 구성을 공개하지 않은 총량이지만 AI 사용량이 얼마나 빠르게 늘고 있는지는 보여 줍니다.
에이전트는 단발성 질의보다 훨씬 많은 토큰을 사용합니다. 8개 프런티어 모델이 SWE-bench Verified 과제를 수행한 궤적을 분석한 2026년 연구는 코딩 에이전트가 한 과제를 해결하는 동안 평균 수백만 토큰을 처리할 수 있음을 보여 줍니다. 파일을 반복해서 읽고 도구 결과를 다시 문맥에 넣고 여러 차례 추론하기 때문입니다. 다만 이 결과는 특정 코딩 벤치마크와 에이전트 구성에서 나온 값이므로 일반적인 챗봇 질문의 평균치로 확대해서는 안 됩니다.
프리필은 연산, 디코드는 메모리
GPU에 올라간 LLM 추론은 성격이 다른 두 단계로 나뉩니다.
프리필(prefill)은 입력 토큰 전체를 한꺼번에 처리해 각 층의 중간값을 계산하는 단계입니다. 입력이 충분히 길거나 배치가 크면 행렬 연산의 병렬성이 높아져 대체로 연산 성능의 영향을 많이 받습니다. 프리필 시간은 첫 토큰이 나오기까지의 지연인 TTFT(Time to First Token)의 주요 구성 요소입니다. 다만 실제 TTFT에는 대기열, 스케줄링, 네트워크, 토큰화 시간도 포함되므로 프리필만으로 결정되지는 않습니다.
디코드(decode)는 이전까지의 문맥을 바탕으로 출력 토큰을 하나씩 생성하는 단계입니다. 밀집형 모델을 작은 배치로 처리할 때는 매 단계마다 활성화되는 가중치 대부분을 HBM 혹은 GDDR 메모리(GPU global memory)에서 읽고 이전 토큰의 KV 캐시도 참조해야 합니다. 연산량에 비해 이동해야 할 데이터가 많기 때문에 메모리 대역폭이 병목이 되기 쉽습니다.
배치를 크게 묶으면 한 번 읽은 가중치를 여러 요청이 함께 사용하므로 요청당 메모리 비용이 줄어듭니다. MoE 모델은 매 토큰마다 일부 전문가 가중치만 활성화합니다. 모델 구조, 배치 크기, 입력·출력 길이와 병렬화 방식에 따라 병목은 달라질 수 있습니다.
Data Gravity가 인용한 예에서는 배치 크기 1로 H100에서 디코드를 수행할 때 SM 활용률이 약 30~40%에 그쳤습니다. 이를 모든 GPU와 모델의 고정값으로 볼 수는 없지만 작은 배치의 디코드가 연산기를 충분히 채우기 어렵다는 점은 잘 보여 줍니다.
이 문제는 일시적인 현상이 아닙니다. 버클리 연구진이 20년간 서버 하드웨어의 발전을 분석한 「AI and Memory Wall」에 따르면 최고 연산 성능은 2년마다 약 3배 증가한 반면 DRAM 대역폭은 약 1.6배 증가했습니다. 20년을 누적하면 연산 성능은 약 6만 배, 메모리 대역폭은 약 100배 늘어난 셈입니다. 연구진은 이 격차로 인해 AI 서빙의 병목이 연산에서 메모리로 이동하고 있다고 설명합니다.
따라서 “연산 성능이 높은 GPU일수록 항상 답변도 빠르다”는 말은 정확하지 않습니다. 특히 작은 배치의 디코드에서는 HBM 대역폭과 용량, 메모리 계층, 서빙 소프트웨어의 효율이 함께 중요합니다.
대표적인 해법이 연속 배칭(continuous batching)입니다. 서로 다른 시점에 들어온 요청을 반복 단계마다 배치에 넣고 빼면서 GPU가 쉬는 시간을 줄입니다. FP8이나 FP4 같은 저정밀도 형식도 지원되는 하드웨어와 정확도 조건에서 가중치와 캐시의 이동량을 줄일 수 있습니다.
처리량 비교는 반드시 같은 모델, 같은 양자화 방식, 같은 KV 캐시 형식, 같은 입력·출력 길이와 같은 TTFT 목표에서 해야 합니다. 동시 요청 수뿐 아니라 다른 설정까지 바뀐 두 결과를 비교해 “배칭으로 처리량이 몇 배 늘었다”고 결론 내리면 원인을 분리할 수 없습니다.
KV 캐시와 프롬프트 캐싱
KV 캐시는 각 토큰이 어텐션 층에서 만든 Key와 Value 벡터를 저장하는 공간입니다. 이 값이 없으면 새 토큰을 만들 때 이미 처리한 이전 토큰의 K/V까지 계속 다시 계산해야 합니다. KV 캐시는 이 중복 계산을 없애는 대신, 문맥 길이와 동시 요청 수에 비례해 GPU 메모리를 사용합니다.
vLLM의 PagedAttention은 운영체제의 가상 메모리와 비슷한 방식으로 KV 캐시를 고정 크기 블록으로 관리합니다. 요청마다 최대 길이만큼 연속 공간을 미리 잡지 않아도 되므로 메모리 단편화와 과도한 예약을 줄입니다. SOSP 2023 논문에서 vLLM은 비교 대상 시스템보다 같은 수준의 지연에서 2~4배 높은 처리량을 보였습니다. 이 수치는 논문의 실험 조건에서 나온 결과이며 모든 모델과 하드웨어에 그대로 적용되지는 않습니다.
여기서 요청 내부의 KV 캐시와 요청 사이에 반복되는 앞부분을 재사용하는 프롬프트 캐싱 또는 프리픽스 캐싱을 구분해야 합니다.
KV 캐시는 한 요청이 다음 토큰을 생성할 때 앞선 토큰의 중간값을 재사용합니다.
프롬프트 캐싱은 시스템 프롬프트나 문서처럼 여러 요청에서 반복되는 접두부의 계산 결과를 다시 사용합니다.
API 사업자의 캐시 할인도 프롬프트 캐싱의 경우에 해당합니다. Anthropic은 현재 캐시 적중 토큰을 일반 입력 가격의 10%로 과금합니다. 반면 캐시를 처음 쓰는 비용은 기본 입력보다 비싸고 모델과 캐시 유지 시간에 따라 요율이 다릅니다. 따라서 “프롬프트 캐싱은 항상 90% 할인”이라기보다 캐시에 적중한 입력 부분의 읽기 단가가 기본 입력의 10%라고 표현하는 편이 정확합니다.
캐시 적중이 계산을 완전히 없애는 것도 아닙니다. 저장된 KV를 읽고 현재 토큰이 이를 참조하는 과정, 이후 디코드 계산과 데이터 이동은 여전히 필요합니다. 다만 반복되는 접두부의 프리필을 건너뛸 수 있어 긴 공통 문맥을 자주 쓰는 에이전트와 RAG 서비스에서 효과가 큽니다.
이 때문에 동일한 접두부의 요청을 관련 캐시가 남아 있는 인스턴스로 보내는 캐시 인식 라우팅(cache-aware routing)도 중요해지고 있습니다. 다만 모든 서빙 환경의 기본 기능이라고 단정하기보다는 대규모 분산 서빙에서 빠르게 채택되는 최적화라고 보는 편이 맞습니다.
대규모 장문맥 서빙은 프리필과 디코드를 분리
프리필과 디코드의 자원 특성이 다르다면 두 단계를 서로 다른 GPU 풀에 배치할 수 있습니다. 프리필 전용 워커가 입력을 처리해 KV 캐시를 만들고 이를 네트워크로 디코드 전용 워커에 넘기는 프리필·디코드 분리(PD disaggregation) 구조입니다.
이 구조는 프리필과 디코드의 GPU 수와 병렬화 방식을 독립적으로 조정할 수 있어 TTFT와 토큰 간 지연을 따로 관리하기 좋습니다. 반면 대용량 KV 캐시를 옮기는 네트워크 비용과 두 풀의 처리율을 맞추는 운영 복잡성이 추가됩니다. 짧은 입력이나 작은 규모의 서비스에서는 통합형 구성이 더 효율적일 수도 있습니다.
Moonshot AI가 Kimi 서비스에 적용한 Mooncake는 이 구조를 실제 트래픽에서 검증한 대표 사례입니다. 논문에 따르면 Mooncake는 CPU DRAM과 SSD까지 KV 캐시 계층으로 활용했고 실제 워크로드에서 기준 시스템보다 75% 많은 요청을 처리했습니다. 특정 시뮬레이션 조건에서는 SLO를 지키면서 최대 525% 높은 처리량을 기록했습니다.
NVIDIA Dynamo와 SGLang 등도 PD 분리를 지원합니다. 이는 대규모 서빙의 중요한 설계 선택지로 자리 잡고 있지만 모든 추론 시스템이 반드시 프리필과 디코드를 분리해야 한다는 뜻은 아닙니다. 입력·출력 길이 분포, 지연 목표, GPU 구성과 네트워크 비용을 함께 측정해 결정해야 합니다.
멀티 GPU와 네트워크
모델이 한 GPU에 들어가지 않거나 처리량을 높이기 위해 모델을 여러 GPU에 나누면 GPU 간 통신이 추론 경로의 일부가 됩니다.
텐서 병렬화에서는 행렬 연산의 부분 결과를 합치는 collective 통신이 자주 발생합니다. MoE의 전문가 병렬화(Expert Parallelism)에서는 토큰을 여러 GPU의 전문가로 보내고 다시 모으는 all-to-all 통신이 필요합니다. 반면 파이프라인 병렬화 등 다른 방식은 통신 패턴이 다릅니다. 따라서 “모든 다중 GPU 모델이 매 레이어마다 같은 방식으로 통신한다”고 일반화할 수는 없습니다.
랙 안에서는 NVLink와 NVSwitch가 고속 scale-up 통신을 담당하고 랙을 넘어가면 InfiniBand나 이더넷 기반 scale-out 네트워크가 이어받습니다. Blackwell 세대 NVLink 5의 GPU당 양방향 대역폭은 1.8TB/s입니다. 다만 이 수치는 링크의 이론적 총대역폭이며 실제 애플리케이션 성능과 같지는 않습니다.
네트워크에서도 전력이 중요한 제약입니다. Data Gravity는 광 트랜시버가 네트워크 장비 비용의 약 60%를 차지한다고 추정합니다. 이는 공개 자료를 종합한 2차 추정치이므로 환경에 따라 달라질 수 있습니다. NVIDIA는 광학 부품을 스위치 패키지에 통합하는 공동 패키징 광학(CPO)이 기존 플러거블 광모듈 방식보다 광학 전력 효율을 최대 5배 높일 수 있다고 발표했습니다.
토큰의 여정의 끝
열다섯 단계는 결국 전력이라는 한정된 자원 위에서 돌아갑니다. 서버에 공급된 전력 대부분은 계산과 메모리, 네트워크를 거쳐 열이 되고 냉각 설비는 그 열을 데이터센터 밖으로 내보내야 합니다.
NVIDIA 공식 문서에 따르면 GB200 NVL72 랙의 소비전력은 약 120kW입니다. 이 시스템은 72개 Blackwell GPU와 36개 Grace CPU를 하나의 NVLink 도메인으로 묶으며 직접 액체냉각(Direct Liquid Cooling, DLC · 수랭)을 전제로 설계됐습니다. 2027년 하반기로 예고된 Rubin Ultra NVL576 ‘Kyber’ 랙은 약 600kW를 소비할 것으로 발표됐습니다. 후자는 아직 출시 전인 로드맵 수치이므로 실제 제품 사양은 달라질 수 있습니다.
이 정도의 랙 밀도에서는 전력 인입, 배전, CDU, 배관과 열교환 설비까지 서버와 함께 설계해야 합니다. 액체냉각이 필요한 이유도 단순히 GPU 온도를 낮추기 위해서가 아닙니다. 공랭만으로 처리하기 어려운 열밀도를 감당하고 제한된 시설 전력 안에서 냉각 오버헤드와 팬 전력을 관리하기 위해서입니다.
Google은 2025년 8월 실제 운영 환경을 반영한 방식으로 Gemini Apps 텍스트 프롬프트의 에너지 사용량 중앙값을 0.24Wh로 추정했습니다. 유휴 장비, CPU와 RAM, 데이터센터 냉각과 배전 오버헤드까지 포함한 값입니다. Google의 비유로는 TV를 9초 미만 시청할 때 쓰는 에너지와 비슷합니다. 같은 발표에서 12개월 동안 프롬프트당 에너지 사용량이 33분의 1로 줄었다고 밝혔습니다.
이 수치를 모든 AI 요청의 대표값으로 사용할 수는 없습니다. 모델, 프롬프트와 출력 길이, 추론 방식이 공개되지 않았고 평균이 아니라 중앙값이기 때문입니다. 긴 추론이나 이미지·영상 생성, 에이전트 작업은 훨씬 많은 에너지를 쓸 수 있습니다.
효율이 빠르게 좋아져도 전체 전력 수요는 늘 수 있습니다. 단가가 낮아지면 기존 사용이 늘고 새로운 용도가 생기기 때문입니다. Epoch AI는 동일한 벤치마크 성능 수준을 달성하는 LLM API 가격의 하락 속도가 과제와 성능 기준에 따라 연 9배에서 900배까지 달랐다고 분석했습니다. 연구진도 최근의 가장 빠른 하락세가 계속될지는 불확실하다고 덧붙였습니다. 따라서 특정 단일 수치를 “LLM 가격이 매년 평균 몇 배 하락한다”고 일반화하기보다는, 품질을 고정한 비용이 매우 빠르게 낮아지고 있다고 이해하는 편이 안전합니다.
한국에서는 전력망 제약도 함께 봐야 합니다. 산업통상자원부가 2023년에 발표한 자료에 따르면 당시 2029년까지 수도권에 신설을 신청한 데이터센터 601곳 가운데 적기에 전력을 공급할 수 있을 것으로 예상된 곳은 40곳, 6.7%였습니다. 오래된 전망치이므로 2026년 현재의 확정 사업 수로 읽어서는 안 되지만 수도권 전력 계통이 데이터센터 입지의 중요한 제약이라는 점은 분명합니다.
중요한 지표는 와트당 처리량
전력 용량이 제한된 환경에서는 같은 전력으로 얼마나 많은 유효 작업을 처리하는지가 중요합니다. NVIDIA가 신제품을 설명할 때 tokens per watt나 tokens per second per megawatt를 강조하는 이유입니다.
다만 토큰은 모델마다 정보량이 다르고 낮은 품질의 짧은 답을 빠르게 만들수록 숫자가 유리해질 수 있습니다. 그러므로 서로 다른 시스템을 비교할 때는 다음 조건을 고정해야 합니다.
모델 또는 동등한 품질 수준
입력·출력 길이와 동시 요청 분포
TTFT와 토큰 간 지연 등 SLO
양자화 방식과 정확도 허용 범위
서버 전력만 측정할지 냉각과 배전을 포함할지
실무적으로는 단순한 tokens per watt보다 정해진 품질과 SLO를 만족한 토큰 처리량, 즉 goodput per watt가 더 유용합니다. FLOPS가 칩의 이론적 능력을 보여 준다면 goodput per watt는 실제 서비스가 제한된 전력을 얼마나 효과적으로 결과로 바꾸는지 보여 줍니다.
AI인프라와 매니코어소프트
토큰을 API로 구매하는 조직에는 이 과정이 공급자의 내부 사정으로 보일 수 있습니다. 반대로 GPU 서버를 직접 운영하는 대학 연구실, 사내 LLM 운영 기업, 데이터 반출이 어려운 기관에는 모두 직접 부담해야 할 비용입니다.
자체 추론의 토큰당 비용에는 전기요금과 냉각만 들어가지 않습니다. 서버와 네트워크의 감가상각, 소프트웨어, 운영 인력, 장애 대비 용량, 그리고 무엇보다 GPU 활용률이 함께 들어갑니다. 같은 장비라도 낮은 활용률로 운영하면 토큰당 비용은 크게 올라갑니다.
결국 AI 추론 인프라는 전력과 장비를 유효한 모델 출력으로 바꾸는 생산 시스템에 가깝습니다. 칩의 최고 FLOPS뿐 아니라 메모리 대역폭, 서빙 소프트웨어, 네트워크, 전력과 냉각을 하나의 시스템으로 봐야 하는 이유입니다.
자체 추론 인프라를 검토하고 있다면 문의하기로 연락 주세요. 매니코어소프트에서는 효율적인 AI인프라를 구성하기 위한 다방면의 아이디어를 제공합니다.
참고 자료
Data Gravity, How an AI Token Travels Through a Data Center (2026.7)
Deloitte, More compute for AI, not less (2025.11)
Sundar Pichai, Google I/O 2026 opening keynote (2026.5)
Gholami et al., AI and Memory Wall (IEEE Micro, 2024)
Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention (SOSP 2023)
Qin et al., Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving (FAST 2025)
Bai et al., How Do AI Agents Spend Your Money? (2026)
Anthropic, Prompt caching
NVIDIA, NVIDIA Dynamo: A Low-Latency Distributed Inference Framework (2025.3)
NVIDIA, Spectrum-X Photonics Co-Packaged Optics Networking Switches (2025.3)
Google Cloud, Measuring the environmental impact of AI inference (2025.8)
Epoch AI, LLM inference prices have fallen rapidly but unequally across tasks (2025.3)
산업통상자원부, 데이터센터 수도권 집중 완화 방안 (2023.3)
Data Center Dynamics, Nvidia's Rubin Ultra NVL576 rack expected to be 600kW (2025.3)