vLLM 파드를 스케일아웃하면 KV 캐시 히트율이 0%로 떨어지는 이유, 그리고 llm-d가 이를 해결하는 방식 (prefix-aware routing / distributed KV cache)

LLM 서비스를 운영하다 보면 어느 순간 이런 상황을 맞닥뜨리게 됩니다. vLLM의 Automatic Prefix Caching(APC)을 켜두고 단일 서버에서 멀티턴 챗봇을 돌릴 때는 두 번째 요청부터 확실히 빨라지는 걸 체감했는데, 트래픽이 늘어서 파드를 3개, 5개로 늘리고 나니 그 이점이 완전히 사라져버리는 겁니다. 캐시 히트율이 뚝 떨어지고, TTFT가 다시 느려지고, "GPU를 더 달면 빨라지겠지"라는 기대가 어긋나기 시작합니다. 저도 처음엔 설정 문제인가 싶어서 한참 헤맸는데, 이건 설정 문제가 아니라 분산 환경에서 KV 캐시 로컬리티가 근본적으로 깨지는 구조적 문제였습니다.

llm-d는 바로 이 지점을 정면으로 파고든 오픈소스 프레임워크입니다. Kubernetes 위에서 동작하며, 요청을 어느 파드로 보낼지를 라운드로빈이 아닌 "어느 서버가 이 요청의 KV 캐시를 이미 갖고 있는가"를 기준으로 결정합니다. 이 글을 다 읽고 나면, prefix-aware 라우팅이 단일 서버 APC와 어떻게 다른지 이해하고, 자신의 클러스터에 llm-d를 적용할지 판단하는 근거를 갖추게 됩니다.

한 가지 미리 언급해두면, llm-d는 Red Hat, IBM, Google, NVIDIA가 함께 만들어가고 있는 프로젝트이고 CNCF Sandbox에도 편입됐습니다. 초기 단계이지만 그만큼 생태계 지원이 빠르게 붙고 있는 프로젝트입니다.

핵심 개념

단일 서버 APC가 작동하는 방식

vLLM의 APC는 꽤 우아한 메커니즘입니다. 프롬프트가 들어오면 토큰 시퀀스를 일정 크기의 블록 단위로 나누고, 각 블록에 해시 값을 붙입니다. 동일한 프리픽스가 다시 들어오면 이미 계산된 KV 캐시 블록을 GPU 메모리에서 그대로 꺼내 쓰고, 달라진 뒷부분만 새로 계산합니다.

요청 A: [시스템 프롬프트 512토큰] + [유저 메시지 1]
         └── KV 블록 해시: abc123 → GPU 메모리에 저장
 
요청 B: [시스템 프롬프트 512토큰] + [유저 메시지 2]
         └── KV 블록 해시: abc123 → 캐시 히트! 재계산 불필요

문제는 이 모든 과정이 단일 인스턴스 메모리 경계 안에서만 유효하다는 것입니다. 파드가 여러 개라면 각자 자신만의 캐시를 가질 뿐, 서로 공유하지 않습니다.

수평 확장 시 캐시 로컬리티가 사라지는 이유

파드가 3개(A, B, C)인 환경을 생각해봅니다. 라운드로빈 로드밸런서를 쓰고 있다면 요청이 A → B → C → A 순서로 분배됩니다. 멀티턴 대화라면 이런 상황이 벌어집니다.

턴 1: 파드 A → [시스템 프롬프트 + 대화 히스토리 1] 계산 → A의 캐시에 저장
턴 2: 파드 B → [시스템 프롬프트 + 대화 히스토리 1 + 2] 처음부터 재계산
턴 3: 파드 C → [시스템 프롬프트 + 대화 히스토리 1 + 2 + 3] 처음부터 재계산

캐시 히트율은 0%에 수렴하고, 파드를 늘릴수록 오히려 낭비가 커집니다.

KV 캐시 (Key-Value Cache): 트랜스포머 어텐션 연산에서 각 토큰의 Key, Value 벡터를 저장해두는 공간입니다. 이미 처리한 토큰에 대해 재계산하지 않아도 되므로, 긴 컨텍스트일수록 재사용 효과가 커집니다. vLLM의 블록 크기 기본값은 16토큰 단위이므로, 캐시 이점을 보려면 공유되는 프리픽스가 최소 16토큰 이상이어야 합니다.

llm-d의 세 가지 핵심 컴포넌트

llm-d는 "어느 파드가 이 요청의 KV 캐시를 갖고 있는지"를 클러스터 전체 단위로 추적하고, 그 정보를 라우팅에 활용합니다.

llm-d-router: 인입 요청의 프롬프트 프리픽스를 해시해서 글로벌 인덱서에 질의하고, 캐시가 있는 파드로 요청을 보냅니다. 캐시가 없다면 부하가 가장 낮은 파드를 선택합니다.

KV Cache Indexer: 클러스터 전체 파드의 KV 캐시 블록 현황을 실시간에 가깝게 추적합니다. vLLM 파드가 블록을 저장하거나 제거할 때마다 BlockStored / BlockRemoved 이벤트를 gRPC 스트림으로 발행하고, 인덱서가 이를 수신해 인덱스를 갱신합니다. gRPC 스트림이라 오버헤드가 낮지만, 네트워크 지연이나 큐 적체가 생기면 인덱서의 상태가 실제 파드 캐시와 시간 차이를 보일 수 있습니다(이를 Staleness라고 합니다).

Scorer: prefix 캐시 히트 가중치와 파드 부하(load) 가중치를 합산해 최적 파드를 선택합니다. 저희 팀은 처음에 prefix 가중치만 지나치게 높게 잡았다가 인기 있는 시스템 프롬프트를 가진 파드 하나가 OOM으로 다운된 적 있습니다. 두 지표를 함께 봐야 하는 이유가 있습니다.

최종 점수 = (prefix 히트 가중치 × 히트 여부) + (부하 가중치 × 파드 여유율)

Staleness: 캐시 인덱서가 관리하는 상태 정보가 실제 파드 상태와 시간 차이로 인해 어긋나는 현상입니다. 네트워크 이벤트 딜레이나 처리 큐 적체 등으로 발생하며, 히트로 판정해 보낸 요청이 실제로는 미스일 가능성이 있습니다.

Approximate vs Precise 라우팅

llm-d는 두 가지 라우팅 전략을 지원합니다.

초기에는 Approximate 방식으로 시작했지만, v0.3 이후 Precise Prefix Cache Aware Routing이 도입되면서 실제 캐시 상태를 직접 조회하는 방식이 더 선호되고 있습니다. Staleness가 걱정된다면 Precise 모드로 전환하는 것이 현실적인 대응입니다.

이중 해시 공간 문제 — 조금 더 파고들면

단점 목록에 등장하는 "이중 해시 공간 문제"는 실제로 운영해보기 전까지는 실감이 안 되는 함정입니다. 좀 더 풀어서 설명해 드릴게요.

llm-d 라우터는 요청 토큰 ID 시퀀스를 해시해서 "이 프리픽스가 어느 파드에 있는가"를 인덱싱합니다. 반면, vLLM 내부 엔진은 실제 KV 텐서 콘텐츠를 해시해서 블록을 식별합니다. 이 두 해시는 서로 다른 공간을 씁니다.

문제가 생기는 지점은 BlockRemoved 이벤트입니다. vLLM이 캐시 블록을 제거할 때 내보내는 이벤트에는 엔진 내부 키(콘텐츠 해시)만 들어 있고, 라우터가 쓰는 토큰 시퀀스 기반 키는 없습니다. 인덱서 입장에서는 "이 블록이 사라졌다"는 건 알지만, 라우터가 참조하는 인덱스에서 어떤 항목을 지워야 하는지 바로 찾을 수 없어서 역매핑 로직이 필요합니다. vLLM 내부 구조를 깊게 알지 못하면 이 부분에서 인덱스가 어긋나 잘못된 라우팅이 발생할 수 있습니다.

직접 커스텀 인덱서를 만들 게 아니라면, llm-d가 제공하는 공식 인덱서를 그대로 쓰는 것을 권장합니다. 이 역매핑 로직이 이미 내장돼 있습니다.

Prefill-Decode 분리: 성능의 다음 단계

2025년을 기점으로 프리필 단계(프롬프트 처리)와 디코드 단계(토큰 생성)를 물리적으로 다른 서버에서 처리하는 아키텍처가 업계에서 주목받고 있습니다. Meta, LinkedIn, HuggingFace가 이미 프로덕션에 올렸다는 게 확인됐고, 저는 그걸 보고 "이게 실험 단계가 아니구나"라고 읽었습니다. NVIDIA도 GTC 2025에서 전용 프레임워크 Dynamo를 발표했고요. llm-d도 이 패턴을 지원하는데, 프리필 파드에서 계산한 KV 캐시를 RDMA 네트워크를 통해 디코드 파드로 전송하는 구조입니다.

일반 이더넷을 쓰면 안 되냐는 의문이 자연스럽게 생깁니다. 문제는 KV 텐서의 크기입니다. Llama 70B 모델 기준으로 단일 요청의 KV 캐시가 수 GB에 달할 수 있고, 이를 디코드 단계 시작 전에 전송 완료해야 합니다. 일반 이더넷(10~25Gbps)으로는 전송 지연이 TTFT를 오히려 늘리는 병목이 됩니다. InfiniBand나 RoCE 같은 RDMA 네트워크는 200Gbps 이상의 대역폭과 수 마이크로초 단위의 지연을 제공하며, CPU를 거치지 않고 메모리 간 직접 전송이 가능해 GPU 연산을 방해하지 않습니다. 클라우드 환경에서는 AWS의 EFA, Google Cloud의 GPUDirect RDMA 등 동등한 기능을 제공하는 서비스가 있습니다.

RDMA (Remote Direct Memory Access): CPU를 거치지 않고 네트워크를 통해 원격 서버의 메모리에 직접 접근하는 기술입니다. 데이터센터급 NIC(InfiniBand HCA 또는 RoCE 지원 이더넷 카드)와 전용 스위치가 필요한 인프라입니다. 온프레미스나 고성능 클라우드 인스턴스 타입을 쓰지 않는다면 별도 확인이 필요합니다.

처음 llm-d를 도입할 때는 Prefill-Decode 분리 없이 prefix-aware 라우팅만으로도 상당한 효과를 볼 수 있습니다. RDMA 인프라가 확보된 이후에 분리 구성으로 단계적으로 발전시키는 접근이 현실적입니다.

실전 적용

예시 1: 멀티턴 대화 서비스에서의 TTFT 단축

가장 체감 효과가 큰 시나리오입니다. 사용자와 여러 번 대화를 주고받는 챗봇에서 대화 히스토리가 길어질수록 이전 컨텍스트를 매번 재계산하는 비용이 커집니다. llm-d를 적용하면 이전 대화 컨텍스트의 KV 캐시를 보유한 파드로 후속 요청이 라우팅되므로, 앞부분 계산을 건너뛸 수 있습니다.

아래 YAML 예시에서 llm-d-epp는 llm-d의 Endpoint Picker Pod로, InferencePool을 배포하기 전에 클러스터에 미리 설치돼 있어야 합니다. 공식 Helm 차트로 설치하면 자동으로 생성됩니다.

# llm-d InferencePool 설정 예시
apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferencePool
metadata:
  name: llama-chat-pool
spec:
  targetPortNumber: 8000
  selector:
    matchLabels:
      app: llama-chat
  extensionRef:
    name: llm-d-epp  # Helm 설치 시 자동 생성되는 prefix-aware 라우터 오브젝트
---
apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferenceModel
metadata:
  name: llama-chat
spec:
  modelName: "meta-llama/Llama-3.1-8B-Instruct"
  criticality: Standard
  poolRef:
    name: llama-chat-pool

Red Hat의 OpenShift AI 환경 실측 데이터에 따르면, 멀티턴 워크로드에 llm-d를 적용했을 때 P99 TTFT가 18.3초에서 8초로 절반 이하로 줄었습니다. 8개 파드(16× H100) 환경에서 라운드로빈 대비 최대 57배 단축된 사례도 있는데, 이는 대화 히스토리가 매우 길고 같은 시스템 프롬프트를 공유하는 워크로드가 집중된 조건에서 측정된 값입니다. 워크로드 특성에 따라 효과의 폭은 달라질 수 있습니다.

예시 2: 공통 시스템 프롬프트를 공유하는 멀티테넌트 환경

솔직히 이 시나리오는 처음엔 "얼마나 차이가 날까" 반신반의했는데, 실제로 적용해보면 수치가 꽤 드라마틱하게 나옵니다. 여러 고객사가 같은 플랫폼을 쓰는데, 각자 긴 시스템 프롬프트(사내 RAG 컨텍스트, 코드베이스 요약 등)를 공유하는 패턴이 있습니다. 이 경우 동일한 프리픽스 KV 캐시를 특정 파드가 유지하도록 라우팅을 집중시키면, 클러스터 전체에서 동일한 연산을 반복하는 낭비를 없앨 수 있습니다.

캐시 이점이 생기려면 공유 프리픽스가 vLLM 블록 크기(기본 16토큰) 이상이어야 하는데, 아래처럼 수천 토큰짜리 시스템 프롬프트를 쓰는 경우라면 캐시 재사용 효과가 큽니다.

import openai
 
client = openai.OpenAI(
    base_url="http://llm-d-gateway/v1",  # llm-d 게이트웨이로 base_url만 교체
    api_key="..."
)
 
# 공통 시스템 프롬프트 (3000토큰 이상의 RAG 컨텍스트)
# 이 프리픽스가 캐시 라우팅의 기준이 됩니다
SHARED_SYSTEM_PROMPT = """
당신은 XXX 회사의 내부 문서를 기반으로 답변하는 어시스턴트입니다.
[... 3000 토큰 분량의 문서 컨텍스트 ...]
"""
 
response = client.chat.completions.create(
    model="meta-llama/Llama-3.1-70B-Instruct",
    messages=[
        {"role": "system", "content": SHARED_SYSTEM_PROMPT},
        {"role": "user", "content": user_message}
    ]
)
# llm-d-router가 SHARED_SYSTEM_PROMPT 프리픽스 해시를 기준으로
# 해당 캐시를 보유한 파드로 자동 라우팅합니다

기존 vLLM OpenAI 호환 코드에서 base_url만 llm-d 게이트웨이 주소로 바꾸면 그대로 동작합니다. 클라이언트 코드 변경이 거의 없다는 게 도입 장벽을 낮춰줍니다.

예시 3: 계층형 KV 캐시 오프로딩

GPU 메모리가 가득 차면 캐시를 버려야 하는 상황이 생깁니다. v0.5부터 llm-d는 KV 캐시 블록을 GPU → CPU → SSD → 공유 파일시스템 순서로 내리는 계층형 오프로딩을 지원하며, 라우터가 각 티어의 위치를 인식해 라우팅합니다.

아래 ConfigMap은 llm-d vLLM 파드의 볼륨 마운트로 연결되어, 파드 스펙의 volumeMounts에서 /etc/llm-d/config.yaml 경로로 마운트해 사용하게 됩니다.

# llm-d KV 캐시 오프로딩 설정 (파드 스펙에서 /etc/llm-d/config.yaml로 마운트)
apiVersion: v1
kind: ConfigMap
metadata:
  name: llm-d-kv-config
data:
  config.yaml: |
    kv_cache:
      tiered_offload:
        enabled: true
        tiers:
          - type: gpu_memory
            capacity_gb: 40
          - type: cpu_memory
            capacity_gb: 200
          - type: local_ssd
            path: /mnt/nvme/kv-cache
            capacity_gb: 1000

GPU 캐시를 100% 채운 상태와 비교했을 때 TTFT 25% 감소, 처리량 21% 향상 사례가 보고됐습니다.

장단점 분석

장점

단점 및 주의사항

실무에서 가장 흔한 실수

1. Scorer 가중치를 기본값으로 두는 것: 워크로드마다 프리픽스 공유 비율과 파드별 부하 편차가 다릅니다. 초반에 히트율이 낮다면 prefix 가중치를 높이고, 특정 파드 과부하가 관찰되면 부하 가중치를 올려보는 튜닝이 필요합니다.

2. 단일 서버 APC와 동시에 켜두고 중복 의존하는 것: llm-d가 올바르게 라우팅하면 단일 서버 APC도 함께 동작하지만, APC 자체가 llm-d 라우팅을 보완해주는 건 아닙니다. 라우팅이 잘못되면 단일 APC도 무용지물이 됩니다.

3. Prefill-Decode 분리를 처음부터 도입하려는 것: RDMA 인프라가 없는 상태에서 분리 구성을 시도하면 오히려 네트워크 병목으로 성능이 저하될 수 있습니다. prefix-aware 라우팅만으로도 상당한 효과를 볼 수 있으니, 단계적으로 접근하는 것이 현실적입니다.

마치며

분산 LLM 추론에서 GPU를 더 추가하는 것만으로는 캐시 효율을 높일 수 없고, 라우팅 레이어에서 KV 캐시 로컬리티를 명시적으로 관리해야 성능이 선형 이상으로 개선됩니다.

지금 바로 시작해볼 수 있는 3단계를 소개합니다.

1. llm-d 퀵스타트로 로컬 환경 구성해보기: 아래 명령어로 Kubernetes 클러스터에 최소 구성을 올리고, 기존 vLLM 단독 배포와 TTFT를 직접 비교해볼 수 있습니다. v0.5 기준 설치 명령어이므로, 이후 버전에서는 공식 GitHub 퀵스타트 가이드에서 최신 명령어를 확인하는 것을 권장합니다.

   bash

   helm install llm-d llm-d/llm-d --namespace llm-d  # v0.5 기준

2. 멀티턴 벤치마크 시나리오 설계하기: 동일한 시스템 프롬프트와 대화 히스토리를 공유하는 요청 세트를 만들어서, 라운드로빈과 prefix-aware 라우팅 간 캐시 히트율과 TTFT 차이를 수치로 확인해보는 것을 권장합니다. 체감보다 데이터가 설득력 있고, 도입 결정의 근거로도 쓸 수 있습니다.

3. Scorer 가중치 실험 시작하기: 프로덕션 트래픽 패턴을 분석해서 프리픽스 공유 비율이 높은 워크로드라면 prefix 가중치를 우선 높게 설정하고, 파드 부하 분산이 더 중요한 상황이라면 부하 가중치를 조정해보면서 최적 균형점을 찾아볼 수 있습니다.

참고 자료

• KV-Cache Wins You Can See: From Prefix Caching in vLLM to Distributed Scheduling with llm-d | llm-d 공식 블로그
• Precise Prefix Cache Aware Routing 공식 문서 | llm-d.ai
• Feature: Precise Prefix Cache Aware Routing | GitHub
• Master KV cache aware routing with llm-d for efficient AI inference | Red Hat Developer
• Accelerate multi-turn LLM workloads on OpenShift AI with llm-d | Red Hat Developer
• llm-d-kv-cache | GitHub
• llm-d 메인 저장소 | GitHub
• llm-d 0.5: Sustaining Performance at Scale | llm-d 공식 블로그
• Automatic Prefix Caching | vLLM 공식 문서
• Prefix-aware routing | Ray Serve 문서
• Production-Grade LLM Inference at Scale with KServe, llm-d, and vLLM | llm-d 블로그
• Native KV Cache Offloading to Any Filesystem with llm-d | llm-d 블로그