토큰 한 개의 원가

🚧메모리에 묶인 디코드#

기다리는 것은 연산이 아니라 대역폭이다

모델은 토큰을 하나 만들 때마다 가중치의 거의 전부를 메모리에서 다시 읽는다. 70B 모델을 16비트로 올리면 가중치만 약 140GB라서, 요청을 하나씩 처리할 때는 연산 코어보다 메모리 대역폭이 먼저 한계에 닿는다. 그래서 추론 비용을 줄이는 방법은 대부분 한 번 읽을 때 토큰을 더 많이 얻거나, 읽어야 할 바이트를 줄이는 쪽으로 모인다.

프리필과 디코드#

두 단계는 병목이 다르다

프롬프트를 읽는 프리필은 입력 토큰을 한꺼번에 처리하므로 연산량이 병목이다. 답을 쓰는 디코드는 토큰을 하나씩 만들며 가중치와 KV 캐시를 매번 읽으므로 메모리가 병목이다. 첫 토큰이 나오기까지의 시간은 주로 프리필이, 이후 토큰 사이의 간격은 디코드가 정한다. DistServe와 Splitwise 같은 연구가 두 단계를 서로 다른 GPU에 나눠 돌리는 방식을 제안한 이유다.

🛠️서빙 기법#

같은 병목을 돌아가는 세 갈래

모델을 바꾸지 않고 서빙 단계에서 토큰당 비용을 낮추는 방법은 크게 셋이다. 배칭은 한 번 읽은 가중치로 여러 요청의 토큰을 함께 만들고, 양자화는 읽을 바이트 자체를 줄이며, 추측 디코딩은 한 번의 검증으로 토큰 여러 개를 확정한다. 배칭과 추측 디코딩은 모델의 출력 분포를 바꾸지 않는다. 양자화는 품질을 조금 내주는 대신 메모리를 확보한다.

연속 배칭과 KV 캐시#

한 번 읽어 여러 요청에 나눈다

연속 배칭은 요청 하나가 끝나기를 기다리지 않고 디코드 단계마다 빈자리에 새 요청을 넣어, 한 번의 가중치 읽기로 여러 사람의 토큰을 함께 만든다. 이때 배치 크기를 제한하는 것은 요청마다 쌓이는 KV 캐시다. 2023년 vLLM 논문은 기존 시스템이 KV 캐시용 메모리의 60~80%를 낭비한다고 보고하고, 캐시를 페이지 단위로 관리해 같은 지연 시간에서 처리량을 2~4배로 높였다.

양자화#

8비트면 읽을 바이트가 절반

가중치를 16비트에서 8비트로 줄이면 토큰마다 메모리에서 읽을 양이 절반이 되고, 4비트면 4분의 1이 된다. GPTQ, AWQ처럼 가중치만 줄이는 방식은 메모리가 병목인 디코드에 곧바로 효과가 나고, 활성값까지 8비트로 내리는 W8A8은 연산이 병목인 프리필도 빠르게 한다. 비트를 줄일수록 품질이 떨어질 수 있으므로, 비트 수는 실제 서비스 과제로 다시 평가해 정한다.

추측 디코딩#

작은 모델이 쓰고 큰 모델이 한 번에 검증한다

작은 초안 모델이 토큰 몇 개를 먼저 제안하면, 본 모델은 그 토큰들을 한 번의 순전파로 함께 검증한다. 받아들인 토큰만 남기므로 출력 분포는 본 모델이 혼자 만들 때와 같다. 2023년 구글 연구진은 T5-XXL에서 출력을 바꾸지 않고 2~3배의 가속을 보고했고, 실제 이득은 초안 토큰이 받아들여지는 비율에 달려 있다.

💸토큰 원가 계산#

처리량은 두 배, 원가는 절반

직접 서빙한다면 토큰 한 개를 만드는 원가는 GPU의 시간당 비용을 한 시간 동안 만든 토큰 수로 나눈 값이다. 서빙 기법과 모델 구조는 GPU 값이 아니라 처리량을 높여 원가를 낮춘다. 다만 토큰 단가가 내려가도, 에이전트처럼 작업 한 건에 모델을 여러 번 부르는 제품은 호출 수가 더 빠르게 늘어 전체 청구서가 커질 수 있다.

토큰세#

추론 비용은 매출원가에 들어간다

전통적인 SaaS는 사용자 한 명을 더 받는 비용이 작지만, LLM 제품은 요청마다 GPU 시간이 든다. 그래서 추론 비용이 매출원가에 들어가고, 정액 요금제에서는 가장 많이 쓰는 사용자가 가장 비싼 사용자가 된다. 요청 한 건의 입력 토큰, 출력 토큰, 캐시 적중률을 알아야 요금제가 남는 장사인지 계산할 수 있다.

캐시 적중 할인#

다시 읽지 않은 프롬프트는 싸다

같은 시스템 프롬프트나 긴 문서를 요청마다 앞에 붙이면, 앞부분의 KV 캐시를 다시 써서 그만큼 프리필을 건너뛸 수 있다. 주요 모델 API가 캐시에 적중한 입력 토큰을 일반 입력보다 싸게 받는 이유가 여기 있다. 캐시는 앞에서부터 똑같이 일치하는 부분에만 적중하므로, 고정된 내용을 앞에 두고 바뀌는 내용을 뒤에 두기만 해도 적중률이 달라진다.

📐모델 구조#

읽을 양을 설계 단계에서 줄인다

서빙 기법이 주어진 모델을 싸게 돌리는 방법이라면, 모델 구조는 토큰마다 읽고 계산할 양을 처음부터 줄이는 방법이다. 전문가 혼합(MoE)은 토큰마다 쓰는 파라미터를 줄이고, MLA는 요청마다 쌓이는 KV 캐시를 줄인다. DeepSeek-V3는 둘을 함께 사용하고 FP8 혼합 정밀도로 학습했으며, 가중치도 FP8로 공개했다.

전문가 혼합(MoE)#

671B 가운데 토큰마다 37B

DeepSeek-V3는 전체 파라미터 671B 가운데 토큰 하나를 처리할 때 37B만 활성화한다. 토큰당 연산량과 읽어야 할 가중치는 활성 파라미터만큼 줄지만, 어떤 전문가가 불릴지 미리 알 수 없어 671B 전체를 메모리에 올려 두어야 한다. MoE는 연산을 아끼는 대신 메모리 용량을 더 요구하고, 전문가를 여러 GPU에 나눠 싣는 설계가 뒤따른다.

MLA#

KV 캐시를 압축해 배치를 키운다

멀티헤드 잠재 어텐션(MLA)은 키와 값을 그대로 저장하는 대신 작은 잠재 벡터로 압축해 캐시에 둔다. DeepSeek-V2 기술 보고서는 MLA를 쓴 이 모델의 KV 캐시가 DeepSeek 67B보다 93.3% 작다고 적었다. 요청 하나가 차지하는 메모리가 줄면 같은 GPU에 요청을 더 많이, 맥락을 더 길게 올릴 수 있다.

🧑‍💻서빙 엔지니어#

토큰 원가를 깎는 일을 맡는 자리

추론 비용이 제품 마진을 직접 좌우하면서, 모델을 만드는 일과 별개로 모델을 싸고 빠르게 돌리는 일이 중요해졌다. vLLM, SGLang, TensorRT-LLM 같은 서빙 엔진을 고르고 조정해 같은 GPU에서 토큰을 더 많이 뽑아내는 것이 이 자리의 성과다. 이 맵의 가지 대부분은 이 직무가 매일 만지는 설정값이다.

서빙 엔지니어의 일#

워크로드 측정부터 디코딩 설정까지

먼저 워크로드를 측정해 프리필과 디코드 중 어디가 병목인지, 지켜야 할 지연 시간이 첫 토큰까지인지 토큰 사이 간격인지 가린다. 그다음 배치 크기, KV 캐시 메모리 할당, 양자화 비트 수, 추측 디코딩 사용 여부를 조정하고 품질이 그대로인지 확인한다. 설정 하나를 바꿀 때마다 처리량, 지연 시간, 품질을 함께 다시 잰다.