토큰당 KV 캐시 크기로 계산하는 온프레미스 동시 처리량

온프레미스 LLM 서버 한 대가 동시에 받을 수 있는 세션 수는 GPU 메모리에서 가중치를 빼고 남은 공간을 토큰당 KV 캐시 크기로 나눈 값에서 시작합니다. SOSP 2023에 발표된 vLLM 논문(Kwon et al.)은 이 KV 캐시 메모리가 서빙 처리량을 제한한다는 점을 수치로 보였고, 이 글은 그 계산을 공개 모델의 config.json으로 직접 재현합니다. 최근 DeepSeek V4.1 Flash가 토큰당 KV 캐시 890바이트를 공개한 것도 같은 계산식으로 비교할 수 있습니다. PagedAttention의 동작 원리는 KV 캐시를 가상 메모리처럼 다루는 PagedAttention에서 다뤘습니다.

핵심 요약

토큰당 KV 캐시 크기는 레이어 수, KV 헤드 수, 헤드 차원, 원소당 바이트 수의 곱에 2(키와 값)를 곱한 값이며 config.json만으로 계산할 수 있습니다.

같은 80GiB GPU에서 Qwen3-8B는 8,192토큰 세션을 최대 57개, Qwen3-32B는 최대 9개 담습니다. 가중치 크기는 4배 차이지만 세션 상한은 6배 이상 차이입니다.

GQA와 MLA는 토큰당 KV 캐시 자체를 줄이는 설계이고, PagedAttention은 계산된 용량을 낭비 없이 쓰게 하는 메모리 관리 방식입니다.

문제 배경

vLLM 논문은 NVIDIA A100 40GB에서 13B 모델을 서빙할 때 메모리의 약 65%가 가중치, 30% 가까이가 요청별 KV 캐시에 쓰인다고 보고했습니다. 같은 논문은 OPT-13B의 토큰당 KV 캐시를 2 × 5120(은닉 차원) × 40(레이어) × 2(FP16 바이트)로 계산해 800KB로 제시했고, 2,048토큰 요청 하나가 최대 1.6GB를 차지한다고 적었습니다. 요청마다 최대 길이만큼 연속 메모리를 미리 잡던 기존 시스템에서 실제 토큰 상태 저장에 쓰인 비율은 20.4%에서 38.2%였습니다. PagedAttention은 KV 캐시를 고정 크기 블록으로 나눠 필요한 만큼만 할당해 낭비를 거의 0으로 줄였고, 같은 지연 수준에서 처리량을 2배에서 4배 높였습니다.

토큰당 KV 캐시 계산식

계산식은 다음과 같습니다.

KV 바이트/토큰 = 2 × num_hidden_layers × num_key_value_heads × head_dim × 원소당 바이트

config.json에 head_dim이 없으면 hidden_size ÷ num_attention_heads를 씁니다. 아래는 논문의 OPT-13B 수치와 Hugging Face에서 받은 Qwen3 두 모델의 config.json(torch_dtype bfloat16, 2바이트) 값입니다.

모델	레이어	KV 헤드 × 헤드 차원	토큰당 KV 캐시
OPT-13B (논문)	40	5,120 (MHA)	2 × 40 × 5,120 × 2 = 819,200바이트 (800KiB)
Qwen3-8B	36	8 × 128 = 1,024	2 × 36 × 1,024 × 2 = 147,456바이트 (144KiB)
Qwen3-32B	64	8 × 128 = 1,024	2 × 64 × 1,024 × 2 = 262,144바이트 (256KiB)

OPT-13B 값은 819,200바이트이며 논문은 이를 800KB로 적었습니다. 논문 표 1의 13B 구성(KV 캐시용 메모리 12GB, KV 캐시 슬롯 15.7K)도 12GB를 12GiB로 읽으면 12GiB ÷ 819,200바이트 = 15,728로 일치합니다.

GPU 메모리에서 동시 세션 수로

80GiB GPU 1장(85,899,345,920바이트)을 기준으로 계산합니다. 가중치는 각 모델의 safetensors 인덱스에 적힌 총 크기로 Qwen3-8B가 16,381,470,720바이트(15.26GiB), Qwen3-32B가 65,524,246,528바이트(61.02GiB)입니다. 남은 메모리를 토큰당 KV 캐시로 나누면 Qwen3-8B는 471,448토큰, Qwen3-32B는 77,724토큰을 담습니다.

세션당 컨텍스트	세션당 KV 캐시 (8B / 32B)	Qwen3-8B 최대 세션	Qwen3-32B 최대 세션
4,096토큰	0.5625GiB / 1GiB	115	18
8,192토큰	1.125GiB / 2GiB	57	9
32,768토큰	4.5GiB / 8GiB	14	2

표의 값은 모든 세션이 해당 길이를 채우고 남은 메모리 전부를 KV 캐시에 쓴다는 가정의 계산입니다. 논문 표 1의 13B 구성도 40GB 가운데 가중치 26GB와 KV 캐시 12GB를 빼고 약 2GB를 활성값 등 나머지 용도로 남겼습니다. 같은 계산에 논문이 측정한 기존 시스템의 실사용률 20.4%를 적용하면 Qwen3-8B의 32,768토큰 세션은 2개 수준으로 줄어듭니다. 가중치 크기 비율(4배)만으로 장비를 산정하면 32B 모델의 동시 처리 용량을 과대평가하게 됩니다.

아키텍처가 바꾸는 토큰당 크기

GQA(Ainslie et al., 2023)는 여러 쿼리 헤드가 키와 값 헤드를 나눠 쓰게 해, MQA에 가까운 속도로 멀티헤드 어텐션에 가까운 품질을 냈습니다. Qwen3-8B는 쿼리 헤드 32개에 KV 헤드 8개를 씁니다. KV 헤드가 32개였다면 토큰당 589,824바이트가 되고 32,768토큰 세션 상한은 3개로 줄어듭니다(config 값으로 계산한 가정입니다).

DeepSeek-V2의 MLA는 키와 값을 저차원 잠재 벡터로 압축해, 잠재 벡터와 분리된 RoPE 키만 캐시합니다. 논문 설정(레이어 60, 압축 차원 512, 분리 키 차원 64)에서 토큰당 원소 수는 (512 + 64) × 60 = 34,560개이고, 같은 헤드 구성의 MHA는 2 × 128 × 128 × 60 = 1,966,080개로 계산됩니다. bf16으로 저장한다고 가정하면 69,120바이트입니다. 논문은 DeepSeek 67B 대비 KV 캐시를 93.3% 줄이고 최대 생성 처리량을 5.76배로 높였다고 보고했습니다.

같은 방향의 최신 사례로, 코텍시스 블로그의 10월 첫째 주 AI 동향은 DeepSeek V4.1 Flash 모델 카드를 출처로 KV 캐시가 토큰당 890바이트이며 V4 Flash의 약 4분의 1이라고 정리했습니다. Qwen3-8B의 147,456바이트와 비교하면 약 166분의 1입니다.

한계와 주의점

계산식은 가중치와 KV 캐시만 다룹니다. 활성값, 런타임 예비 메모리, 텐서 병렬화 시 장치 간 분할은 별도로 빼야 합니다. 반대로 표의 값은 모든 세션이 해당 길이를 채운다는 가정이므로, 평균 컨텍스트가 짧은 업무에서는 더 많은 세션이 들어갑니다. KV 캐시를 8비트로 저장하면 원소당 바이트가 1이 되어 값이 절반이 되지만 품질 영향은 모델별로 측정해야 합니다. MLA나 슬라이딩 윈도 어텐션을 쓰는 모델은 위 계산식이 그대로 맞지 않으므로 논문이나 모델 카드의 구조 설명을 기준으로 다시 계산합니다.

도입 검토 가이드

구분	내용
검토 주체	GPU 수량을 산정하는 인프라 담당자, 서빙 런타임을 고르는 ML 플랫폼팀
전제 조건	후보 모델의 config.json과 가중치 크기, 업무별 평균 및 최대 컨텍스트 길이, 목표 동시 사용자 수
첫 적용 지점	사내 문서 질의응답처럼 긴 문서를 컨텍스트에 넣는 서비스의 장비 견적
판단 기준	토큰당 KV 캐시 바이트, 컨텍스트 길이별 세션 상한, PagedAttention 지원 런타임에서 측정한 실제 동시 처리량

온프레미스 구축 견적은 후보 모델마다 토큰당 KV 캐시와 컨텍스트 길이별 세션 상한을 먼저 계산하고, 그 값으로 GPU 수량을 정하는 순서로 진행합니다.