본문으로 건너뛰기

KV Cache 최적화 (vLLM Deep Dive + Cache-Aware Routing)

2026-04-03 작성2026-07-17 수정9분 읽기

개요​

LLM 추론 엔진의 성능은 대부분 KV Cache(Key-Value Cache)를 얼마나 효율적으로 관리하느냐에 달려 있습니다. 본 문서는 vLLM의 핵심 기술 스택과 GPU 메모리 설계 원리, 그리고 여러 Pod 간 KV Cache를 공유·재사용하는 KV Cache-Aware Routing 전략(llm-d vs NVIDIA Dynamo)을 다룹니다.

vLLM Deep Dive​

핵심 기술 스택​

vLLM(v0.22+/v0.24.x)은 현재 가장 널리 사용되는 LLM 추론 엔진입니다. 핵심 기술과 성능 영향은 다음과 같습니다.

기술성능 영향설명
PagedAttentionKV Cache 메모리 60-80% 절감 (vLLM 벤치마크 기준, 워크로드별 상이)OS 가상 메모리 기법으로 KV 캐시를 비연속 블록 저장
Continuous Batching처리량 2-24x 향상 (vLLM 벤치마크 기준, 워크로드별 상이)반복(iteration) 수준에서 요청을 동적 추가/제거
FP8 KV CacheKV 캐시 메모리 약 2배 절감KV 캐시를 FP8 정밀도로 저장 (v0.3.0+)
Prefix Caching반복 프롬프트 고히트율에서 TTFT 최대 3~4x 개선 (워크로드 의존)공통 시스템 프롬프트의 KV 캐시 재사용
Speculative Decoding속도 2-3x 향상소형 드래프트 모델이 토큰 예측, 메인 모델이 검증
Chunked PrefillTTFT/처리량 균형 개선Prefill과 Decode를 동일 배치에서 혼합 처리

GPU 메모리 계산​

모델 배포 전 GPU 메모리를 정확히 계산해야 합니다.

필요 GPU 메모리 = 모델 가중치 + 비torch 메모리 + PyTorch 활성화 + (KV 캐시 × 배치 크기)

정밀도별 메모리 요구사항:

정밀도파라미터당 바이트70B 모델32B 모델
FP324280GB128GB
BF16/FP162140GB64GB
INT8170GB32GB
INT40.535GB16GB

병렬화 전략 선택 기준​

모델 크기별 권장 구성:

모델 예시파라미터정밀도GPU 구성병렬화
Qwen3-32B32BFP81× H100 80GB없음
Llama-3.3-70B70BBF164× H100 (TP=4)텐서 병렬
Kimi K2.51T MoE (32B active)INT48× H200 141GB (TP=8)텐서 병렬
GLM-5744B MoE (40B active)FP816× H100 (PP=2, TP=8)파이프라인 + 텐서 병렬

핵심 성능 파라미터​

vllm serve Qwen/Qwen3-32B-FP8 \
  --gpu-memory-utilization=0.95 \   # KV 캐시에 사전 할당할 VRAM 비율 (기본 0.92, v0.21+)
  --max-model-len=32768 \           # 최대 시퀀스 길이 (KV 캐시 크기에 직접 영향)
  --enable-prefix-caching \         # 공통 프리픽스 KV 캐시 재사용
  --kv-cache-dtype=fp8 \            # FP8 KV 캐시로 메모리 절감
  --enable-auto-tool-choice \       # Tool calling 자동 지원
  --tool-call-parser=hermes         # Tool call 파서 선택

양자화 전략 비교​

양자화메모리 절감품질 손실추론 속도권장 시나리오
FP850%최소빠름프로덕션 기본 (품질 우선)
AWQ75%낮음매우 빠름비용 최적화
GPTQ75%낮음빠름오프라인 양자화
GGUF50-75%낮음~중간빠름다양한 정밀도 선택

KV Cache-Aware Routing​

기존 문제: Round-Robin의 한계​

기존 vLLM 배포는 단순 Round-Robin 로드 밸런싱에 의존합니다. 동일한 시스템 프롬프트를 사용하는 요청이 매번 다른 Pod로 분산되면, 각 Pod에서 동일한 프리필 연산을 반복 수행합니다. 이는 GPU 연산 낭비이자 TTFT 증가의 원인입니다.

해결: KV Cache 상태 인식 라우팅​

llm-d와 NVIDIA Dynamo는 각 vLLM Pod의 KV Cache 상태를 인식하여, 동일한 prefix를 가진 요청을 이미 해당 KV Cache를 보유한 Pod로 라우팅합니다.

라우팅 결정과 추론(inference)은 별개의 작업

KV 캐시 인지 라우팅에서 라우팅 결정 자체는 추론이 아닙니다. 게이트웨이는 프롬프트를 고정 크기 블록으로 해시한 뒤, 해당 prefix를 이미 캐시한 Pod를 인덱스에서 조회합니다. 모델 forward pass가 없는 기계적 해시 조회입니다(Gateway API Inference Extension의 prefix-cache-scorer, vLLM Automatic Prefix Caching, llm-d의 KV-event 인덱서가 모두 이 방식입니다).

반면 컨텍스트 인지(시맨틱) 라우팅은 프롬프트를 인코더·분류 모델(BERT 계열)에 통과시켜 의도를 분류하므로, 라우팅 경로에서 경량 추론이 한 번 발생합니다(vLLM Semantic Router).

두 경우 모두 라우팅으로 선택된 Pod가 수행하는 최종 워크로드는 LLM 추론입니다. 따라서 "라우팅 결정이 추론인가"와 "최종 워크로드가 추론인가"는 분리해서 판단해야 합니다.

KV Cache-Aware Routing의 효과:

시나리오TTFT 개선GPU 연산 절감처리량 향상
동일 시스템 프롬프트50-80% 감소프리필 스킵400%+
RAG 반복 컨텍스트30-60% 감소부분 재사용200%+
완전 랜덤 요청변화 없음없음LB 폴백

llm-d vs NVIDIA Dynamo 비교​

두 프로젝트 모두 KV Cache-aware 라우팅을 제공하지만 접근 방식이 다릅니다.

항목llm-d v0.8+NVIDIA Dynamo v1.2.x
주도Red Hat (Apache 2.0)NVIDIA (Apache 2.0)
KV Cache 인덱싱Prefix-aware 라우팅Flash Indexer (radix tree)
KV Cache 전송NIXL (네트워크)NIXL (NVLink/RDMA 초고속)
라우팅Gateway API + Envoy EPPDynamo Router + 자체 EPP
Pod 스케줄링K8s 기본 스케줄러KAI Scheduler (GPU-aware)
오토스케일링HPA/KEDA 연동Planner (SLO 기반 profiling)
KV Cache 계층화HBM→CPU RAM→공유 파일시스템 (OffloadingConnector/LMCache/Mooncake)4-tier: G1 GPU / G2 CPU / G3 로컬 SSD / G4 원격 스토리지
복잡도낮음높음
벤치마크 성능경량, K8s 네이티브최대 7x (disaggregation + wide EP, GB200 NVL72)
선택 기준
  • 소규모~중규모 (GPU ≤16): llm-d — 빠른 도입, K8s Gateway API 네이티브, 다중 계층 KV 캐시 오프로딩 지원
  • 대규모 (GPU 16+), 최대 처리량: Dynamo — Flash Indexer, SLO 기반 오토스케일링, 4-tier KV Cache
  • 긴 컨텍스트 (128K+): 두 프로젝트 모두 CPU/스토리지 계층 오프로딩 지원
  • 점진적 전환: llm-d로 시작 → 규모 확장 시 Dynamo로 전환 (둘 다 NIXL 사용)

Gateway 아키텍처: llm-d 배포 구성​

참고 자료​

공식 문서​

논문·기술 블로그​

관련 문서​