vLLM 양방향 KV 전송으로 다중 턴 에이전트 워크로드의 TTFT 개선
요약 (TL;DR)
vLLM에 양방향 KV 캐시 전송 기능이 추가되었습니다. 이를 통해 디코드 노드가 생성 후 KV 블록을 프리필 노드로 다시 전달하여 다음 턴에 재사용할 수 있게 되었으며, 다중 턴 에이전트 워크로드에서 첫 토큰 생성 시간(TTFT)을 Qwen3-32B 기준 최대 1.6배, GLM-5-FP8 기준 최대 3.3배 단축합니다.
양방향 KV 전송이 중요한 이유
다중 턴 에이전트 애플리케이션은 매 턴마다 전체 대화 기록을 다시 전송하므로, 프리필 노드는 이전에 생성된 토큰에 대한 KV 캐시를 매번 다시 계산해야 합니다. 이러한 중복 작업은 컨텍스트가 길어질수록 가속기 사용량과 TTFT를 증가시킵니다. vLLM은 턴 간 KV 재사용을 활성화함으로써 대부분의 재계산 과정을 제거하여 매우 긴 프롬프트에서도 지연 시간을 일정하게 유지합니다.
핵심 기술 기여
양방향 KV 전송 메커니즘
- 양방향 KV 흐름 – 기존의 프리필-투-디코드(P→D) NIXL READ 방식에 더해, 이제 디코드 노드가 생성 후 적격한 KV 블록을 유지하고 해당 메타데이터를 라우터로 반환합니다. 라우터는 이 메타데이터를 다음 프리필 요청에 첨부하여 디코드-투-프리필(D→P) NIXL READ를 가능하게 합니다.
- 구성 가능한 제어 옵션 –
decoder_kv_blocks_ttl(기본값 480초): 디코드 노드가 KV 블록을 유지하는 시간을 결정합니다.kv_recompute_threshold(기본값 64토큰): 재사용 가능한 토큰 수를 기준으로 원격 KV를 가져올지, 로컬에서 재계산할지 결정합니다.
NIXL KV 커넥터 개선
- NVIDIA Inference Xfer Library (NIXL) KV 커넥터를 확장하여 프리필 노드가 원격 KV 블록을 소비할 수 있도록 했습니다. 이는 기존의 디코드 측 기능과 동일한 방식입니다.
- 실제 데이터 이동은 여전히 단일 NIXL READ로 수행되며, P→D와 D→P 방향 간의 차이는 제어 흐름뿐입니다.
KV 캐시 인식 라우터
- 경량 상태 유지 프록시가
conversation_id와 디코드 노드로부터 수신된 최신kv_transfer_params간의 메모리 내 맵을 유지합니다. - 라우터는 KV 텐서 자체가 아닌 **메타데이터(블록 위치, TTL, 만료 시간)**만 저장하므로 제어 평면을 가볍게 유지합니다.
- 구현 예시는 vLLM 저장소(
disagg_proxy_multiturn.py)에서 확인할 수 있습니다.
성능 영향
벤치마크 설정
- 하드웨어 – Amazon EC2 P5en (8× NVIDIA H200) 상의 1 프리필 + 1 디코드 노드 구성, AWS Elastic Fabric Adapter (EFA) 연결.
- 모델 – Qwen3-32B 및 zai-org/GLM-5-FP8 (FP8).
- 구성 – 캐시 제거 시나리오를 모방하기 위해 프리필 노드에서 프리픽스 캐싱 비활성화;
kv_recompute_threshold= 64,decoder_kv_blocks_ttl= 480초.
TTFT 결과
| 모델 | 프롬프트 길이 (토큰) | TTFT OFF | TTFT ON | 속도 향상 |
|---|---|---|---|---|
| Qwen3-32B | 24k | 778ms | 460ms | 1.6배 |
| GLM-5-FP8 | 20k | 2,334ms | 702ms | 3.3배 |
- KV 재사용이 비활성화되면(매 턴마다 전체 재계산) TTFT가 급격히 증가합니다.
- 양방향 전송을 사용하면 TTFT가 거의 일정하게 유지됩니다. 약간의 KV 전송 지연(약 30~130ms)은 절약된 재계산 시간으로 충분히 상쇄됩니다.
프리필 소요 시간 분석
- KV 전송 시간 – Qwen3-32B의 경우 30
130ms, GLM-5-FP8의 경우 29110ms. - 절약된 프리필 연산 – 프리필 단계의 대부분이 사라지며, 특히 토큰당 재계산 비용이 높은 GLM-5-FP8에서 효과가 큽니다.
- 원문 차트에서 각 프롬프트 길이에 따른 누적 막대 비교를 확인할 수 있습니다.
기능 도입 방법
- vLLM v0.21.0 이상으로 업그레이드하고 NIXL 커넥터를 설치합니다.
- 프리필 및 디코드 서버 모두의 KV 전송 설정에서
bidirectional_kv_xfer를 활성화합니다. - KV 캐시 인식 라우터 배포 – 제공된
disagg_proxy_multiturn.py예제를 사용하거나 동일한 로직을 구현합니다. - 매개변수 튜닝 – 예상되는 턴 간 지연 시간에 맞춰
decoder_kv_blocks_ttl을 조정하고, 모델 크기와 네트워크 대역폭에 따라kv_recompute_threshold를 조정합니다. - 벤치마크 실행 – 재현 가이드(스크립트
serve_pd_multiturn.sh,run_multiturn_sweep.sh,cleanup.sh)를 따라 클러스터 성능을 검증합니다.
에이전트 AI 배포에 미치는 영향
- 확장 가능한 지연 시간 – 자율 비서, 도구 사용 에이전트, 다단계 추론 파이프라인과 같은 애플리케이션은 대화 기록이 수천 토큰으로 길어져도 낮은 지연 시간을 유지할 수 있습니다.
- 가속기 효율성 – 반복적인 KV 재계산을 방지하여 GPU/TPU 자원을 다른 워크로드에 할당할 수 있어 요청당 비용이 절감됩니다.
- 하드웨어 독립적 이점 – 이 기능은 AWS Trainium 클러스터에서 처음 검증되었으나, GPU 기반 P5en 인스턴스에서도 동일한 성능 향상이 나타나 다양한 가속기 유형에 폭넓게 적용 가능함을 보여줍니다.
- 향후 확장 – 디코드 측 KV 블록에 대한 임대 갱신 메커니즘을 통해 메모리 낭비를 추가로 줄일 수 있으며, 동적 임계값을 통해 변화하는 네트워크 상태에 적응할 수 있습니다.
재현 체크리스트
- 인스턴스 – EFA가 활성화된 동일 가용 영역(AZ) 내 두 대의
p5en.48xlarge(8 × H200). - 소프트웨어 스택 – Ubuntu 24.04, NVIDIA 드라이버 580+, CUDA 13.0, EFA 1.50.0, libfabric 2.6.0, NIXL 1.4.1, vLLM 0.29.0 (PR #40186 적용).
- 주요 명령어 – EFA, vLLM/NIXL 설치, 모델 다운로드, 서버 실행 스크립트, 프록시 시작, 벤치마크 스윕 스크립트.
- 문제 해결 팁 –
conversation_id가 전송되는지, PR #40186이 적용되었는지, TTL이 충분한지, EFA 공급자가 올바르게 감지되는지 확인하십시오.
결론
양방향 KV 캐시 전송을 통해 디코드 노드는 다음 턴을 위해 KV 블록을 프리필 노드로 다시 전달할 수 있으며, 이는 길고 복잡한 다중 턴 에이전트 대화에서 TTFT를 획기적으로 단축합니다. EFA가 장착된 AWS P5en GPU 환경의 1 프리필 + 1 디코드 배포에서, 이 기능은 테스트된 가장 긴 프롬프트에서 Qwen3-32B의 TTFT를 1.6배, GLM-5-FP8의 TTFT를 3.3배 빠르게 만듭니다. 이 접근 방식은 가속기 종류에 구애받지 않으며, TTL 및 재계산 임계값을 통해 구성 가능하고, vLLM의 NIXL 커넥터와 KV 캐시 인식 라우터를 사용하여 통합할 수 있습니다.
참고 자료:
- Prefill-Decode (P-D) 분산 서빙
- NIXL KV 커넥터 문서
- 벤치마크 스크립트 및 데이터는 원문 블로그 게시물에 링크되어 있습니다.