왜 KV cache가 serving의 병목인가
- B 규모의 dense 모델을 시퀀스 길이 128K로 256 병렬 실행하면, KV cache만으로 1TB급의 HBM이 요구됩니다. MoE(Mixtral-8x22B나 DeepSeek-V3 계열)는 expert 선택으로 희소하게 동작하기 때문에 연산은 가볍지만, KV cache는 전체 보유이므로 용량 압박은 dense와 동등하거나 그 이상입니다. 2026년의 serving 팀이 하루의 대부분을 소비하는 문제는 "GPU compute를 가동시키기 위해 어떻게 KV를 최적화하는가"이며, HBM만으로는 명백히 부족합니다. 본고는 FP8 양자화, paging, CPU/NVMe 오프로드, RadixAttention, 멀티 테넌트 분리를 하나의 설계론으로 정리합니다.
FP8 KV cache의 품질 트레이드오프
FP8 KV(전형적으로 E5M2 또는 E4M3)는 HBM 사용량을 FP16 대비 절반으로 줄입니다. 2025년 시점에서는 출력 품질 저하가 우려되었지만, 2026년 현재는 다수의 논문과 사내 벤치마크에서 "적절한 양자화 방식을 선택하면 품질 손실은 0.5% 이내"가 통설이 되었습니다. 권장 사항은 다음과 같습니다.
- E5M2 (5 exp, 2 mantissa): 다이나믹 레인지가 넓습니다. 장문맥, 다국어 워크로드에 강합니다. 정밀도 손실은 E4M3보다 약간 크지만, 환각적 실패는 적습니다.
- E4M3 (4 exp, 3 mantissa): mantissa가 많아 정밀도 중심입니다. 코드 생성, 수학 추론에 적합합니다. 이상값을 가진 activation은 clip됩니다.
- per-channel scale + per-token shift: Activation-aware 양자화로, 이상값을 흡수합니다. SGLang 0.4 계열과 vLLM 0.7 계열 양쪽에 구현되어 있습니다.
KGA의 품질 벤치(MT-Bench, HumanEval, JMMLU, 자체 일본어 RAG 벤치 4종)에서, Llama-3.3-70B를 FP16 KV에서 FP8 E5M2 KV로 낮춰도 aggregate score의 저하는 -0.3%, Qwen3-72B에서는 -0.6%에 그쳤습니다. 한편 HBM 사용량은 절반이 되어, 동일 GPU에서 동시 세션 수를 1.8배 늘릴 수 있습니다. 프로덕션 투입 시에는 E5M2를 초기 설정으로 하고, 코드/수학 특화 엔드포인트에서 E4M3를 검토하는 운용이 최적입니다.
MoE의 메모리 프로파일
MoE 모델은 라우팅의 희소성으로 오해받기 쉽지만, KV cache는 모든 token에 대해 완전히 구체화됩니다. DeepSeek-V3 계열(671B total, 37B activated)에서는 expert 파라미터가 HBM의 대부분을 차지하는 반면, 장문맥 운용에서는 KV가 앞질러 지배적이 됩니다.
MoE 특유의 KV 설계 포인트는 세 가지입니다. 첫 번째로, MLA(Multi-head Latent Attention) 계열 모델은 KV의 압축 표현을 학습 시부터 가지고 있어, KV 용량이 동등한 파라미터의 dense 모델보다 70% 이상 작습니다. DeepSeek-V3나 Qwen3-MoE 계열에서는 이것이 serving 비용을 극적으로 낮추고 있습니다. 두 번째로, GPU별 expert 배치(expert parallelism)와 KV cache 배치(tensor parallelism)를 혼합하면 부하의 편중으로 일부 GPU의 KV가 먼저 넘칩니다. EP와 TP를 올바르게 분리하고, KV는 전 GPU에 균등하게 분산시키는 설계가 필수입니다. 세 번째로, 라우팅의 hot/cold 패턴으로 활성화되는 expert에는 편중이 있어, 특정 expert의 KV가 빈번하게 접근되는 것을 전제로 prefetch를 설계해야 합니다.
페이징과 CPU/NVMe 오프로드
PagedAttention은 KV를 16토큰의 페이지 단위로 관리하여 물리 HBM을 연속 확보하지 않아도 됩니다. 2026년 현재, 이 "페이지"를 HBM, CPU 메모리, NVMe의 3계층에 걸쳐 운용하는 구성이 실용 단계에 진입했습니다.
CPU 오프로드. 유휴 중인 세션(사용자 대기, 에이전트 스텝 중)의 KV를 CPU 메모리로 퇴피시킵니다. 재개 시 PCIe 전송 비용은 40GB/s 오더로, 70B 모델의 128K 시퀀스 KV도 수백 ms 내에 GPU로 돌아올 수 있습니다. vLLM의 swap, SGLang의 offload backend, LMCache 중 하나를 사용합니다.
NVMe 오프로드. 더 저빈도의 세션(수 분~수 시간 유휴)을 NVMe로 내립니다. Gen5 NVMe로 실효 12GB/s, 128K KV는 2~3초의 복귀 비용이 됩니다. 장시간 유휴 후 복귀 시에는 "NVMe에서 CPU, CPU에서 GPU"의 2단 복귀를 비동기로 파이프라인화합니다.
계층 정책. KGA의 고객 사례에서는 최근 30초의 활성 KV를 HBM, 30초~10분을 CPU, 10분 이상을 NVMe로 내리는 휴리스틱이 범용적으로 통합니다. 단, 멀티 테넌트에서는 테넌트별로 고유한 TTL을 갖게 할 필요가 있습니다.
LMCache와 SGLang RadixAttention의 벤치마크
- 년 Q1에 KGA 사내에서 실시한 벤치마크입니다. 워크로드는 RAG 채팅(system prompt 1.5K, retrieved context 8K, user turn 평균 200토큰, 멀티턴 평균 6턴), 모델은 Qwen3-72B FP8, 하드웨어는 H200 SXM 8장입니다.
- vLLM prefix caching만: aggregate throughput 2100 tok/s, TTFT p50 210ms, TTFT p99 720ms, prefill 재계산율 38%.
- SGLang RadixAttention: throughput 2650 tok/s, TTFT p50 140ms, TTFT p99 510ms, prefill 재계산율 17%.
- vLLM + LMCache (로컬 CPU+NVMe): throughput 2450 tok/s, TTFT p50 160ms, TTFT p99 430ms, prefill 재계산율 11%.
- vLLM + LMCache (분산, 공유 NVMe): throughput 2380 tok/s, TTFT p50 180ms, TTFT p99 480ms, prefill 재계산율 6%. 분산 시에는 노드 로컬 HBM 재활용에는 미치지 못하지만, 클러스터 전체에서 cache를 공유하는 효과가 p99에 영향을 줍니다.
결론으로, 단일 노드라면 SGLang RadixAttention, 멀티 노드 공유 캐시가 필요하면 vLLM + LMCache가 현재의 양강입니다. TensorRT-LLM도 동등한 기능을 가지지만, 구성의 유연성에서는 위 두 가지가 우위입니다.
멀티 테넌트에서의 분리와 공정성
SaaS에서 멀티 테넌트 serving을 할 경우, KV 레이어에 네 가지 설계 제약이 붙습니다.
누출 위험. 동일 system prompt를 공유하는 경우에는 문제가 없지만, 테넌트 고유 데이터를 포함한 KV를 다른 테넌트의 요청이 참조하는 "cache timing side channel"의 가능성이 완전히 없지는 않습니다. 금융·의료·정부 등 고보안 영역에서는 테넌트 단위로 GPU 프로세스 또는 GPU 그룹을 분리하여 물리적으로 KV를 분리하는 운용이 현실적인 해법입니다.
공정성. 단순한 LRU는 대량 요청을 보내는 테넌트가 KV를 독점하여 다른 테넌트의 TTFT가 저하됩니다. KGA에서는 "테넌트별로 KV quota를 설정하고, quota를 초과한 부분은 LRU이지만 통상 운용 시에는 1테넌트 50% 상한"이라는 hybrid policy를 제안하고 있습니다.
SLA별 서비스 품질. 프리미엄 테넌트에는 HBM 상주 구역을 보장하고, 베이직 테넌트는 CPU/NVMe 오프로드 우선이라는 계층화가 일반화되고 있습니다. vLLM, SGLang 모두 pluggable scheduler를 가지고 있어 커스텀 policy를 구현할 수 있습니다.
가시성. prometheus 익스포터로 테넌트별 KV hit rate, KV eviction rate, KV quota 사용률을 대시보드화해 두면, 과금과 캐퍼시티 플랜이 연동될 수 있습니다. KGA의 표준 스택에서는 이를 Grafana로 시각화하고 있습니다.
설정 예: vLLM + LMCache + FP8 KV
```python from vllm import LLM from lmcache.integration.vllm import LMCacheConnector
llm = LLM( model="Qwen/Qwen3-72B-Instruct", tensor_parallel_size=8, kv_cache_dtype="fp8_e5m2", enable_prefix_caching=True, enable_chunked_prefill=True, max_num_batched_tokens=8192, kv_transfer_config={ "kv_connector": "LMCacheConnector", "kv_role": "kv_both", "kv_buffer_size": 5e9, }, ) ```
LMCache 측에서는 CPU 계층에 256GB, NVMe 계층에 2TB를 할당하고, 테넌트별로 논리 namespace를 나누어 quota를 관리합니다.
결론
- 년의 KV cache는 "HBM에 들어가는 양을 무작정 보유한다"는 시대가 아닙니다. FP8 KV로 용량을 절반으로 줄이고, MLA 계열 모델로 구조적으로 압축하며, PagedAttention으로 단편화를 배제하고, LMCache나 RadixAttention으로 prefix 공유를 효과적으로 하고, CPU/NVMe 계층으로 장기 KV를 저장하며, 멀티 테넌트 분리와 공정성 정책으로 서비스 품질을 지킵니다. 이 6계층이 동시에 작동해야 비로소 1노드당 수천 tok/s의 실효 처리량과 p99 TTFT 500ms의 SLO가 양립합니다. KV를 지배하는 자가 2026년의 LLM serving을 지배합니다.