멀티턴 에이전트 워크로드는 에이전트가 추론하고, 도구를 호출하고, 이전 결과를 반영하면서 축적된 컨텍스트 위에서 동작합니다. 새로운 턴마다 클라이언트는 시스템 지침, 이전 프롬프트, 도구 결과 및 모델 응답을 포함한 대화 기록을 다시 전송하므로, 커지는 컨텍스트가 반복적으로 처리됩니다. Prefill-decode (P-D) disaggregation에서 각 요청은 전문화된 노드들로 분할됩니다. 프리필 노드가 프롬프트를 처리하고 키-값(KV) 캐시를 생성한 다음, 디코드 노드가 해당 KV 블록을 가져와 응답을 생성합니다.
그러나 기존의 분리형(disaggregated) 서빙은 프리필 노드에서 디코드 노드로의 한 방향으로만 KV 캐시를 전송합니다. 이 단방향 흐름은 멀티턴 워크로드에 두 가지 비효율을 만듭니다. 첫째, 응답을 생성한 후 디코드 노드는 프롬프트와 새로 생성된 토큰 모두에 대한 KV 캐시 항목을 보유합니다. 다음 턴을 처리할 때 프리필 노드는 이러한 항목을 검색할 수 없으므로, 이전 응답 토큰에 대한 KV 프로젝션을 다시 계산해야 합니다. 둘째, 디코드 노드는 세션 상태를 유지하는 반면 프리필 노드는 그렇지 않아, 프리필 노드에서 활성 세션의 캐시 축출(eviction) 가능성이 높아집니다. 캐시 미스가 완전히 발생하면 프리필 노드는 시스템 지침, 이전 사용자 요청, 도구 결과, 모델 생성 응답을 포함한 전체 대화 기록에 대해 KV 프로젝션을 다시 계산해야 합니다. 대화가 길어질수록 이 중복 작업은 가속기 용량을 더 많이 소모하고 첫 토큰까지의 시간(TTFT)을 증가시킵니다.
대화형 어시스턴트와 에이전트 애플리케이션을 구축할 때, 길어지는 상호작용 기록은 반복적인 프리필 계산을 통해 지연 시간을 늘리고 가속기 용량을 소모할 수 있습니다. 이 게시물에서는 양방향 KV 캐시 전송 이 프리필 노드와 디코드 노드가 이전에 계산된 컨텍스트를 턴 간에 재사용할 수 있게 하여 가속기 활용도를 높이고 대화가 길어져도 애플리케이션이 빠른 TTFT를 유지하도록 돕는 방법을 보여줍니다.
Amazon Elastic Compute Cloud(Amazon EC2) P5en 인스턴스를 사용한 1P1D 배포의 멀티턴 벤치마크에서, 양방향 KV 전송은 Qwen3-32B의 경우 TTFT를 최대 1.6배, zai-org/GLM-5-FP8의 경우 최대 3.3배까지 단축했습니다(Performance data 섹션 참조). 결과는 워크로드와 구성에 따라 달라집니다. 인스턴스는 AWS Elastic Fabric Adapter(AWS EFA)로 연결되어 있으며, 이는 AWS 전체의 서버들에서 사용되는 저지연 원격 직접 메모리 액세스(RDMA) 네트워크입니다. 지원되는 인스턴스 유형에서 AWS EFA는 GPUDirect RDMA와 Neuron Direct RDMA를 지원하여 프리필 노드와 디코드 노드 간에 GPU 또는 AWS Trainium 장치 메모리 사이에서 KV 블록을 직접 이동시킵니다.
우리는 원래 EFA로 연결된 AWS Trainium 인스턴스 클러스터에서 이 기능을 구축하고 검증했으며, 가속기 독립적인 기능으로 vLLM에 기여했습니다. 여기에 제시된 결과는 EFA가 장착된 Amazon EC2 P5en GPU 클러스터에서 얻은 것으로, 이점이 GPU에도 적용됨을 보여줍니다. 이 게시물에서는 양방향 KV 전송 아키텍처, 라우터 메타데이터 흐름, KV 블록 보존 및 재계산 제어, 성능 결과, 벤치마크 재현 방법을 설명합니다.
양방향 KV 전송
양방향 KV 전송은 대화의 후속 턴에서 디코드 노드가 이전에 계산된 KV를 프리필 노드에 반환하는 메커니즘입니다. 이는 프리필 노드에서 공유 컨텍스트를 재계산하는 것을 방지하며, 구성 가능한 KV 재계산 임계값에 의해 제어됩니다. 이는 앞서 설명한 두 가지 계산 중복 시나리오를 모두 완화합니다. 이것이 작동하려면, KV가 이를 생성한 턴 이후에도 유지되고, KV 캐시 인식 라우터에 의해 조정되어 역방향으로 이동해야 합니다.
양방향 전송을 위한 NIXL KV 커넥터 개선 사항
NVIDIA Inference Xfer Library(NIXL)의 KV 커넥터 를 확장하여 프리필 노드가 원격 KV 블록을 소비할 수 있도록 했으며, 이는 디코드 노드가 이미 프리필 노드가 제공하는 KV 블록을 소비하는 방식과 유사합니다. 두 노드 유형은 아키텍처적으로 다르기 때문에 이는 간단한 변경이 아닙니다. 프리필 노드는 새로운 프롬프트 토큰에 대한 KV 표현을 계산하며 완전한 프롬프트 KV 블록을 제공할 수 있습니다. 디코드 노드는 완전한 KV 표현을 생성하는 기능(또는 효율성)이 없으며 이전에 캐시된 KV 블록만 제공할 수 있습니다. 결과적으로, 프리필 노드와 디코드 노드는 원격 및 로컬 KV 블록의 메타데이터를 계산하기 위한 각자의 역할과 로직을 계속 유지합니다. 그러나 실제 KV 전송 메커니즘(NIXL READ)은 P->D 및 D->P 양방향 모두에서 공통입니다.
다음 다이어그램은 먼저 기존 흐름을 파란색으로 보여줍니다. 라우터가 요청을 prefill 노드로 보내면, prefill 노드가 프롬프트 KV를 계산하여 블록 메타데이터를 반환하고, 라우터가 요청과 메타데이터를 decode 노드로 전달하여 표준 P→D NIXL READ를 수행합니다. 번호가 매겨진 빨간색 경로는 양방향 KV 전송 추가 사항을 보여줍니다: (1) decode 노드가 생성 후 조건에 맞는 KV 블록을 유지하고, (2) 스트리밍 응답에 해당 메타데이터를 반환하며, (3) 라우터가 다음 prefill 요청을 위해 해당 메타데이터를 캐시합니다. 그런 다음 prefill 노드는 (4) 로컬 캐시 매치를 적용한 후 원격으로 재사용 가능한 KV를 확인하고, (5) 재사용 가능한 토큰 수가 임계값을 충족하면 비동기 수신을 큐에 넣으며, (6) 나머지 접미사를 계산하기 전에 D→P NIXL READ를 수행합니다.
Figure 1: 표준 prefill-to-decode 흐름(파란색)과 양방향 KV 전송 추가 사항(빨간색)
KV-캐시 인식 라우터
vLLM은 커넥터 측 양방향 KV 전송 지원을 포함하며, 대화 턴 간 KV 재사용을 조정하려면 KV 캐시 인식 라우터가 필요합니다. vLLM GitHub는 다음을 제공합니다. 예시 프록시 이 게시물에서 사용된 흐름을 구현한 것으로, 사용자의 환경에 맞게 조정할 수 있습니다.
KV-cache 인식 라우터는 클라이언트, 프리필(prefill), 디코드(decode) 노드 사이에 위치하는 가볍고 상태를 유지하는 컨트롤 플레인 컴포넌트입니다. 이 라우터는 클라이언트가 제공한 값으로부터의 인메모리 매핑을 유지합니다. conversation_id decode의 kv_transfer_params. 라우터는 KV 텐서가 아닌 블록 위치 메타데이터만 저장하며, 별도로 디코드 노드를 조회하는 것이 아니라 응답 스트림에서 해당 메타데이터를 가져옵니다.
다음 다이어그램은 라우터가 대화 턴 전반에서 KV 메타데이터를 관리하는 방법을 보여줍니다. 첫 번째 턴에서는 캐시 조회가 실패하고 요청이 표준 P→D 흐름을 따릅니다. 그런 다음 라우터는 응답 스트림에서 디코드의 메타데이터를 저장합니다. 이후 턴에서 라우터는 다음을 사용하여 해당 메타데이터를 가져오며, conversation_id 프리필이 디코드의 KV를 재사용할 수 있습니다. 그런 다음 생성이 끝난 후 다음 턴을 위해 메타데이터를 갱신합니다.
그림 2: 대화 턴 간 KV 캐시 인식 라우터 메타데이터 흐름
블록 보존 TTL
일반적으로 디코드 인스턴스는 생성이 끝나는 즉시 요청의 블록을 해제합니다. 양방향 KV 전송 모드에서는 구성 가능한 수명(decoder_kv_blocks_ttl, 기본값 480초) 동안 블록을 유지하고 위치와 만료 시점을 게시합니다. 그러면 프롬프트 접두사와 생성된 응답을 모두 포함하는 대화의 KV가 다음 턴에서 계속 사용 가능한 상태로 유지됩니다. TTL(time to live)이 만료되기 전에 도착한 턴의 경우 프리필 노드가 KV를 재사용합니다. 이후에 도착한 턴은 일반 프리필로 폴백합니다. 이 TTL은 고정되어 갱신되지 않으므로, KV 재사용과 가속기 메모리 사용량 사이의 균형을 맞추기 위해 턴 사이의 예상 간격에 맞게 조정하십시오. 자연스러운 다음 개선 방향은 하트비트로 갱신되는 임대를 디코드 측에도 확장하는 것입니다. 그러면 디코드 인스턴스는 고정 타이머가 끝날 때가 아니라 대화가 유휴 상태가 되는 즉시 블록을 회수할 수 있습니다.
KV 재계산 임계값
KV 재사용이 항상 로컬 재계산보다 빠른 것은 아닙니다. 재사용 가능한 접두사가 짧으면 상호연결 및 조정 오버헤드가 토큰 재계산에 필요한 시간을 초과할 수 있습니다. 기본값이 64 토큰인 kv_recompute_threshold 기본값이 64 토큰으로 설정된 이 설정이 이 결정을 제어합니다. 프리필 노드는 계산할 토큰 수가 임계값 미만일 때 재계산하고, 임계값 이상일 때 디코드 노드에서 KV를 가져옵니다. 배포 환경에서는 모델 계산 시간, KV 크기, 상호연결 성능에 따라 이 값을 조정할 수 있습니다.
성능 데이터
평가를 위해 EFA로 연결된 Amazon EC2 P5en 인스턴스를 사용하는 1P1D 배포에서 Qwen3-32B 및 GLM-5-FP8 모델을 사용했습니다. 프리필 노드가 로컬 캐시를 제거했거나 라우터가 해당 대화의 KV 블록이 없는 다른 프리필 노드를 선택하는 시나리오를 재현하기 위해 프리필 노드에서 접두사 캐싱을 다음과 같이 비활성화했습니다: --no-enable-prefix-caching.
두 모델 모두에서 양방향 KV 전송을 켜면 멀티 턴 대화에서 프리필 계산이 줄어들며, 그 효과는 일반적으로 프롬프트 길이가 길어질수록 커집니다. 이 기능이 OFF일 때 프리필 인스턴스는 매 턴마다 증가한 전체 컨텍스트를 재계산하므로 TTFT가 가파르게 상승합니다. Qwen3-32B는 2k에서 158 ms에서 24k에서 778 ms로 상승하고, GLM-5-FP8은 2k에서 500 ms에서 20k에서 2,334 ms로 상승합니다. 이 기능이 ON이면 디코드 인스턴스가 보존한 KV가 재계산 대신 재사용되어 TTFT가 훨씬 완만하게 유지됩니다. Qwen3-32B는 동일한 범위에서 122 ms에서 460 ms로만 상승하고(가장 긴 프롬프트에서 약 1.6배 감소), GLM-5-FP8은 358 ms에서 702 ms로 상승하며 긴 프롬프트에서 재계산 경로보다 최대 3.3배 낮게 실행됩니다. 프리필 소요 시간 분석이 그 이유를 설명해 줍니다.
양방향 전송은 약간의 KV 전송 시간을 추가하지만(Qwen3-32B의 경우 약 30 ms~130 ms; GLM-5-FP8의 경우 약 29 ms~110 ms), 제거되는 프리필 계산이 그 KV 전송 시간을 훨씬 능가합니다. 결과적으로 전송 ON일 때의 총 프리필 소요 시간(Qwen3-32B: 128 ms~414 ms; GLM-5-FP8: 316 ms~541 ms)은 재계산 전용 경로(Qwen3-32B: 153 ms~744 ms; GLM-5-FP8: 500 ms~2,331 ms)보다 훨씬 낮게 유지됩니다. 더 큰 GLM-5-FP8 모델은 토큰당 재계산 시간이 더 높아 모델과 컨텍스트가 커질수록 KV 재사용의 효과가 더 커지기 때문에 절대적 및 상대적 격차가 더 큽니다.
Qwen3-32B
다음 차트는 Qwen3-32B에 대해 프롬프트 길이에 따른 TTFT를 양방향 KV 전송 ON과 OFF로 비교하여 보여줍니다.
그림 3: 양방향 KV 전송 켜기/끄기에 따른 Qwen3-32B의 프롬프트 길이별 TTFT
다음 차트는 동일한 실행에 대한 프리필 소요 시간을 재계산 구성 요소와 KV 전송 구성 요소로 분해하여 보여줍니다.
그림 4: 재계산 및 KV 전송 구성 요소로 분해된 Qwen3-32B 프리필 소요 시간
두 차트를 함께 보면 기능을 켰을 때 TTFT는 거의 수평을 유지하는 반면, 기능을 끈 경로는 컨텍스트가 커짐에 따라 가파르게 상승하는 것을 보여주는데, 이는 작은 KV-transfer 시간보다 재계산을 제거하는 효과가 훨씬 크기 때문입니다.
zai-org/GLM-5-FP8
동일한 두 가지 관점이 GLM-5-FP8에도 적용됩니다. 첫 번째는 프롬프트 길이에 따른 TTFT를 기능 ON versus OFF로 비교해 보여줍니다.
그림 5: zai-org/GLM-5-FP8의 KV 재사용 켜기/끄기에 따른 TTFT
두 번째는 프리필(prefill) 소요 시간을 재계산(recompute) 구성 요소와 KV 전송 구성 요소로 나눕니다.
그림 6: zai-org/GLM-5-FP8 프리필(prefill) 소요 시간 분석
GLM-5-FP8는 Qwen3-32B보다 훨씬 큰 격차를 보이는데, 긴 프롬프트에서 TTFT가 최대 약 3.3배 낮아집니다. 이는 토큰당 재계산 시간이 더 길어 문맥 길이가 길어질수록 KV 재사용의 이점이 더욱 커지기 때문입니다.
벤치마크 실행 방법
1P1D 벤치마크 구성, 즉 prefill 노드 1개와 decode 노드 1개를 재현하려면 EFA를 갖춘 Amazon EC2 P5en 인스턴스를 사용하여 다음 문서의 단계별 지침을 따르십시오. 우리의 결과 재현 가이드. 이 가이드는 환경 설정, vLLM prefill 및 decode 서버 실행, 벤치마크 실행, 결과 수집 방법을 다룹니다. 이 기능은 다른 지원되는 구성에서도 실행할 수 있지만, 성능 결과는 하드웨어, 모델, 워크로드 및 네트워크 구성에 따라 달라집니다.
결론
이 게시물에서는 에이전트의 대화 기록이 길어질 때 양방향 KV 캐시 전송이 TTFT를 어떻게 줄일 수 있는지 보여드렸습니다. P-D 분리 배포에서는 이 기능을 통해 prefill 노드가 여러 턴에 걸쳐 decode 노드가 보관한 KV 블록을 재사용하여 반복 연산을 줄일 수 있습니다. 구성 가능한 블록 보유(block-retention) 및 재계산(recompute) 임계값이 재사용이 발생하는 시점을 결정합니다. EFA로 연결된 Amazon EC2 P5en 인스턴스를 사용하는 1P1D 배포에서, 테스트된 가장 긴 프롬프트 길이에서 Qwen3-32B의 경우 1.6배, zai-org/GLM-5-FP8의 경우 3.3배의 TTFT 감소를 관찰했습니다. 결과는 워크로드와 배포 구성에 따라 달라집니다. 사용자 환경에서 이를 구현하려면 NixlConnector와 함께 vLLM v0.21.0 이상을 사용하고, 다음을 활성화하십시오. bidirectional_kv_xfer 프리필(prefill) 서버와 디코드(decode) 서버 양쪽 모두에서 kv-cache를 인식하는 라우터를 사용하고, 다음을 따르십시오 GitHub 재현 가이드.
관련 자료
감사의 말
이 기능을 유지하는 데 도움을 주신 vLLM 커뮤니티에 감사드립니다.