Articleaws.amazon.com·2026년 10월 19일·0

Improve TTFT for multi-turn agentic workloads with bi-directional KV transfer in vLLM

Quick Summary

vLLM의 양방향 KV 전송은 멀티턴 대화에서 decode의 캐시를 prefill이 재사용하게 하며, EFA로 연결한 Amazon EC2 P5en의 1P1D 벤치마크에서 TTFT를 Qwen3 32B는 최대 약 1.6배, zai org/GLM 5 FP8은 최대 약 3.3배 개선했다.

Improve TTFT for multi-turn agentic workloads with bi-directional KV transfer in vLLM 관련 대표 이미지

🖼️ 인포그래픽

Improve TTFT for multi-turn agentic workloads with bi-directional KV transfer in vLLM 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

Improve TTFT for multi-turn agentic workloads with bi-directional KV transfer in vLLM의 핵심 내용을 4단계로 요약한 인포그래픽
Improve TTFT for multi-turn agentic workloads with bi-directional KV transfer in vLLM 핵심 내용을 4단계로 압축한 4컷 인포그래픽

💡 한 줄 요약

vLLM의 양방향 KV 전송은 멀티턴 대화에서 decode의 캐시를 prefill이 재사용하게 하며, EFA로 연결한 Amazon EC2 P5en의 1P1D 벤치마크에서 TTFT를 Qwen3-32B는 최대 약 1.6배, zai-org/GLM-5-FP8은 최대 약 3.3배 개선했다.

📌 핵심 요약

  • 기존 prefill-decode(P-D) 분리 구조는 KV 캐시를 prefill에서 decode로만 전송하므로, 다음 턴에 이전 응답의 KV를 다시 계산해야 한다. prefill의 캐시가 완전히 사라지면 대화 전체를 재계산하면서 가속기 자원 사용과 첫 토큰 지연 시간(TTFT)이 증가한다.
  • 양방향 KV 전송은 확장된 NIXL KV 커넥터를 통해 decode가 보존한 KV 블록을 prefill로 가져온다. KV-cache-aware router는 conversation_id와 kv_transfer_params의 연결을 메모리에 저장하며, KV 텐서 대신 응답 스트림에서 얻은 블록 위치 메타데이터만 관리한다.
  • decode 블록 보존 시간인 decoder_kv_blocks_ttl의 기본값은 480초이며, 만료 시간이 자동 갱신되지 않는다. kv_recompute_threshold의 기본값은 64토큰으로, 재사용 대상 토큰 수가 기준 미만이면 재계산하고 이상이면 원격 KV를 가져오므로 턴 간격·메모리 사용량·모델 계산 비용·네트워크 성능에 따른 조정이 필요하다.
  • 성능 평가는 EFA로 연결한 Amazon EC2 P5en의 1P1D 구성에서 prefill에 --no-enable-prefix-caching을 적용해 로컬 캐시가 없는 상황을 모사했다. Qwen3-32B의 TTFT는 2k~24k 프롬프트에서 기능 OFF 시 158~778ms, ON 시 122~460ms였고, GLM-5-FP8은 2k~20k에서 각각 500~2,334ms와 358~702ms였다.
  • 양방향 전송은 KV 전송 시간을 추가하지만 두 모델에서는 제거한 prefill 재계산 비용이 이를 웃돌았으며, 토큰당 재계산 비용이 더 큰 GLM-5-FP8의 개선 폭이 컸다. 기능은 AWS Trainium에서 처음 개발·검증한 뒤 가속기 독립 기능으로 vLLM에 기여됐고 GPU에서도 효과를 보였지만, 결과는 하드웨어·모델·워크로드·네트워크 구성에 따라 달라진다.

🧩 주요 포인트

  1. decode가 보유한 이전 응답과 대화 문맥을 prefill로 역전송 → 턴이 누적될 때 반복 계산을 줄이며, 턴 간 재사용을 연결하는 라우터의 메타데이터 관리가 필요하다.
  2. 고정 TTL과 토큰 수 임계값으로 재사용 여부 결정 → 캐시 보존에 드는 메모리 비용과 원격 전송·로컬 재계산 비용을 함께 고려해야 한다.
  3. prefill 로컬 캐시가 없는 조건에서 긴 문맥과 높은 토큰당 계산 비용이 더 큰 이득으로 연결 → 제시된 최대 개선치를 적용하려면 실제 배포의 캐시 상태와 실행 조건을 함께 평가해야 한다.

🧠 상세 정리

1. 멀티턴 대화에서 반복되는 prefill 계산

멀티턴 에이전트는 추론하고 도구를 호출하며 이전 결과를 반영하는 동안 대화 문맥을 계속 축적하고, 클라이언트는 새 턴마다 시스템 지침·이전 요청·도구 결과·모델 응답을 다시 전송한다. P-D 분리 구조에서는 prefill 노드가 프롬프트를 처리해 KV 캐시를 만들고, decode 노드가 해당 블록을 가져와 응답을 생성한다. 기존 전송은 prefill에서 decode로만 이루어지므로, decode가 이전 응답 토큰의 KV까지 갖고 있어도 다음 턴의 prefill은 이를 가져오지 못해 다시 계산한다. 또한 decode와 달리 prefill은 세션 상태를 유지하지 않아 활성 세션의 캐시가 퇴출될 가능성이 커지고, 완전한 캐시 미스가 발생하면 대화 이력 전체를 재계산해야 한다. 원문은 이렇게 문맥 길이에 따라 늘어나는 중복 계산이 가속기 용량을 소비하고 TTFT를 높이는 문제를 개선 대상으로 제시한다.

2. 양방향 전송과 NIXL 커넥터의 확장

양방향 KV 전송은 decode 노드가 이미 계산한 KV를 이후 대화 턴의 prefill 노드에 돌려주어 공통 문맥의 재계산을 줄이는 방식이다. 이를 위해 NVIDIA Inference Xfer Library(NIXL) KV 커넥터를 확장해, prefill도 decode에 있는 원격 KV 블록을 가져올 수 있게 했다. 다만 prefill은 새 프롬프트의 완전한 KV 표현을 계산할 수 있는 반면 decode는 이미 캐시한 블록만 제공하므로, 양쪽의 역할과 로컬·원격 블록 메타데이터 계산 로직은 계속 구분된다. 실제 데이터 이동에는 P→D와 D→P 모두 동일한 NIXL READ 메커니즘을 사용하며, prefill은 로컬 캐시 일치를 적용한 뒤 원격 재사용 범위를 확인하고 조건이 맞으면 비동기 수신을 대기열에 넣는다. 이후 D→P 전송을 수행하고 남은 접미부를 계산하며, 이 기능은 EFA로 연결한 AWS Trainium 클러스터에서 처음 개발·검증된 뒤 가속기 독립 기능으로 vLLM에 기여됐다.

3. 대화 턴을 연결하는 KV-cache-aware router

vLLM은 커넥터 수준의 양방향 전송을 지원하지만, 서로 다른 대화 턴 사이에서 KV 재사용을 조율하려면 KV-cache-aware router가 필요하다. 이 라우터는 클라이언트와 prefill·decode 노드 사이에 위치하는 가벼운 상태 유지 제어 구성요소로, 클라이언트가 제공한 conversation_id를 decode의 kv_transfer_params와 연결해 메모리에 저장한다. 저장 대상은 KV 텐서가 아니라 블록 위치 메타데이터이며, decode를 별도로 조회하지 않고 응답 스트림에서 해당 정보를 얻는다. 첫 턴에는 메타데이터 조회가 실패하므로 기존 P→D 경로를 따르고, 생성이 끝나면 decode가 반환한 메타데이터를 다음 턴을 위해 보관한다. 이후에는 conversation_id로 저장 정보를 찾아 prefill의 원격 KV 재사용을 지원하고 생성 후 정보를 갱신하며, 원문은 이 흐름을 구현한 vLLM GitHub의 예제 프록시를 환경에 맞게 수정할 수 있다고 안내한다.

4. 고정 TTL에 따른 KV 블록 보존

일반적인 decode 인스턴스는 응답 생성이 끝나면 요청의 KV 블록을 즉시 해제하지만, 양방향 전송 모드에서는 설정한 수명 동안 블록을 보존하고 위치와 만료 정보를 제공한다. decoder_kv_blocks_ttl의 기본값은 480초이며, 보존 대상에는 프롬프트 접두부와 새로 생성한 응답의 KV가 모두 포함된다. 다음 턴이 TTL 만료 전에 도착하면 prefill이 해당 KV를 재사용하고, 만료 후 도착하면 일반적인 prefill 처리로 돌아간다. 이 TTL은 고정값이고 자동 갱신되지 않으므로, 예상 턴 간격에 맞춰 재사용 가능성과 가속기 메모리 점유 사이의 균형을 조정해야 한다. 원문은 향후 개선 방향으로 heartbeat에 의해 갱신되는 임대 방식을 decode 측에도 확장하여, 고정 타이머 종료를 기다리는 대신 대화가 비활성화되면 블록을 회수하는 방안을 제시하지만 현재 구현의 기능으로 설명하지는 않는다.

5. 원격 전송과 재계산을 가르는 임계값

양방향 KV 재사용이 모든 프롬프트에서 로컬 재계산보다 빠른 것은 아니며, 재사용 가능한 접두부가 짧으면 연결망 전송과 조율에 드는 비용이 계산 시간을 넘어설 수 있다. 이 선택을 제어하는 kv_recompute_threshold의 기본값은 64토큰으로, prefill은 대상 토큰 수가 임계값 미만이면 재계산하고 이상이면 decode에서 KV를 가져온다. 따라서 원격에 캐시가 있다는 사실만으로 전송을 수행하는 것이 아니라, 재사용할 문맥의 크기를 기준으로 전송 여부를 결정한다. 원문은 모델 계산 시간, KV 크기, 연결망 성능에 따라 이 값을 조정할 수 있다고 설명하므로 기본값을 모든 구성의 최적값으로 해석할 수는 없다. TTL이 다음 턴까지 블록을 남겨둘지를 좌우한다면, 이 임계값은 남아 있는 블록을 실제로 가져오는 편이 유리한지를 결정하는 별도의 제어 수단이다.

6. 벤치마크 구성과 결과 해석의 전제

평가는 Qwen3-32B와 GLM-5-FP8을 대상으로, prefill 노드 하나와 decode 노드 하나를 사용하는 1P1D 구성의 Amazon EC2 P5en 인스턴스에서 수행했다. 인스턴스 사이는 저지연 RDMA 네트워크인 AWS EFA로 연결했으며, 지원 인스턴스에서 EFA는 GPUDirect RDMA와 Neuron Direct RDMA를 통해 GPU 또는 AWS Trainium 장치 메모리 사이로 KV 블록을 직접 이동할 수 있다. 실험에서는 prefill에 --no-enable-prefix-caching을 적용해 로컬 접두부 캐시를 비활성화했다. 이는 prefill 캐시가 퇴출됐거나 라우터가 해당 대화의 KV를 갖고 있지 않은 다른 prefill 노드를 선택한 상황을 모사하기 위한 설정이다. 따라서 기능 OFF에서 매 턴 늘어난 문맥 전체를 재계산하는 비교 결과는 이러한 조건을 전제로 이해해야 하며, prefill 로컬 캐시가 유지되는 모든 배포에서 동일한 개선 폭을 보장하는 자료는 아니다.

7. Qwen3-32B의 TTFT와 prefill 시간

Qwen3-32B에서는 프롬프트 길이가 2k에서 24k로 늘어날 때 양방향 전송 OFF의 TTFT가 158ms에서 778ms로 증가했다. 전송 ON에서는 같은 구간의 TTFT가 122ms에서 460ms로 증가해 상승 폭이 줄었으며, 원문은 가장 긴 프롬프트에서의 개선을 약 1.6배로 설명한다. KV 전송 자체에는 약 30~130ms가 추가됐지만, 전체 prefill 시간은 ON에서 128~414ms로 OFF의 153~744ms보다 낮았다. 이는 이미 계산한 문맥을 가져오는 비용보다 생략한 prefill 계산 비용이 컸다는 근거로 제시된다. 다만 ON에서도 문맥 길이에 따라 TTFT가 증가하므로, 결과는 지연 시간이 일정해졌다는 의미보다는 전체 문맥을 재계산하는 경로에 비해 증가가 완화됐다는 의미로 읽는 것이 수치에 부합한다.

8. GLM-5-FP8에서 더 크게 나타난 재사용 이득

zai-org/GLM-5-FP8에서는 프롬프트 길이가 2k에서 20k로 늘어날 때 전송 OFF의 TTFT가 500ms에서 2,334ms로 증가한 반면, ON에서는 358ms에서 702ms로 증가했다. 원문은 긴 프롬프트에서 TTFT가 최대 약 3.3배 개선됐다고 보고하며, Qwen3-32B보다 절대적인 시간 절감과 상대적인 개선 폭이 모두 컸다고 설명한다. 이 모델의 KV 전송 시간은 약 29~110ms였고, 전체 prefill 시간은 ON에서 316~541ms, 재계산만 수행한 OFF에서는 500~2,331ms였다. 원문이 제시한 이유는 GLM-5-FP8의 토큰당 재계산 시간이 더 길어, 누적 문맥의 계산을 생략하는 가치가 더 커진다는 것이다. 따라서 두 모델의 비교는 문맥 길이뿐 아니라 모델의 계산 비용도 KV 재사용 효과를 좌우함을 보여주지만, 제시된 수치는 해당 실험 구성에서 얻은 결과다.

9. 재현 방법과 적용 범위

원문은 EFA로 연결한 Amazon EC2 P5en에서 prefill 하나와 decode 하나를 사용하는 벤치마크를 재현하려면 Reproducing our results guide의 단계별 안내를 따르도록 설명한다. 해당 안내는 실행 환경 설정, vLLM prefill·decode 서버 기동, 벤치마크 실행, 결과 수집을 다룬다. 기능은 다른 지원 구성에서도 실행할 수 있지만 성능은 하드웨어, 모델, 워크로드, 네트워크 구성에 따라 달라지므로, 제시된 최대 개선치를 다른 환경에 그대로 적용할 수는 없다. AWS Trainium에서 시작한 기능이 P5en GPU 클러스터에서도 이득을 보였다는 점은 원문이 제시하는 가속기 적용 범위의 근거다. 실제 적용에서는 대화 이력이 커질 때 줄어드는 반복 계산의 가치와 함께, 블록 보존 시간에 따른 메모리 사용 및 임계값에 따른 전송 선택을 해당 구성의 성능과 연결해 판단해야 한다.

🧾 핵심 주장 / 시사점

  • 멀티턴 문맥의 재사용 범위는 prefill의 로컬 캐시만으로 결정되지 않는다. decode가 생성한 응답의 KV까지 다음 턴에 연결하면, 이전 생성 작업의 결과를 후속 prefill 계산 절감에 활용할 수 있다.
  • TTL과 재계산 임계값은 서로 다른 비용을 제어한다. 오래 보존하면 재사용 기회와 메모리 점유가 함께 늘고, 짧은 문맥까지 전송하면 전송·조율 비용이 계산 절감 효과를 상쇄할 수 있다.
  • GLM-5-FP8의 더 큰 개선 폭은 원격 전송 비용만이 아니라 생략 가능한 계산 비용이 중요함을 보여준다. 다만 로컬 접두부 캐시를 비활성화한 결과이므로 실제 캐시 상태에 따른 효과를 구분해 해석해야 한다.

✅ 액션 아이템

  • Amazon EC2 P5en·EFA의 1P1D 구성과 --no-enable-prefix-caching 조건을 기준으로 Qwen3-32B 및 GLM-5-FP8의 TTFT 개선 폭 검증.
  • 예상 턴 간격과 메모리 사용량을 고려해 decoder_kv_blocks_ttl 기본값 480초의 적합성 평가.
  • 모델 계산 비용과 네트워크 성능을 기준으로 kv_recompute_threshold 기본값 64토큰의 조정 필요성 검토.

❓ 열린 질문

  • prefill의 로컬 캐시가 유지되는 실제 워크로드에서도 Qwen3-32B와 GLM-5-FP8의 TTFT 개선 폭은 어느 정도인가?
  • 예상 턴 간격과 메모리 사용량을 고려할 때 decoder_kv_blocks_ttl의 기본값 480초는 적절한가?
  • 모델 계산 비용과 네트워크 성능이 달라지면 kv_recompute_threshold의 기본값 64토큰을 어떻게 조정해야 하는가?

관련 문서

공통 태그와 주제 흐름을 기준으로 같이 보면 좋은 문서를 이어서 제안합니다.