vLLM 양방향 KV 전송으로 멀티턴 에이전트 TTFT 단축

배경

에이전트형 대화에서는 모델이 추론하고, 도구를 호출하고, 반환된 결과를 반영할 때마다 컨텍스트가 길어진다. 새로운 턴이 시작되면 클라이언트는 시스템 지시, 과거 사용자 요청, 도구 결과, 이전 모델 응답을 포함한 대화 기록을 다시 전송하는 경우가 많다. Prefill-Decode, 즉 P-D 분리형 서빙에서는 Prefill 노드가 프롬프트를 처리한 뒤 Decode 노드가 응답을 생성한다. Prefill 측에서 이전 KV 상태를 활용하지 못하면 이미 처리한 기록을 다시 계산해야 한다.

vLLM의 양방향 KV 전송은 이 중복을 줄이기 위한 기능이다. 기존 분리형 서빙은 주로 Prefill에서 Decode로 KV를 전달했다. 새 방식에서는 Decode 노드가 생성이 끝난 뒤 재사용 가능한 KV 블록을 보존하고, 다음 턴에서 이를 Prefill 노드가 읽을 수 있다.

핵심 내용

• 양방향으로 컨텍스트를 재사용한다. 첫 요청은 기존 흐름과 같다. Prefill이 프롬프트 KV를 계산하고 Decode가 이를 읽는다. 생성이 끝나면 Decode가 프롬프트와 응답에 해당하는 블록을 보관한다. 다음 턴에서 Prefill은 재사용 가능한 접두부를 가져오고 새로 추가된 부분만 계산한다.
• 라우터는 메타데이터만 관리한다. KV 인식 라우터는 클라이언트가 제공한 conversation_id와 Decode의 블록 위치 및 만료 정보를 연결한다. 이 정보는 응답 스트림에서 얻어 다음 Prefill 요청에 첨부된다. KV 텐서는 라우터를 통과하지 않고 NIXL을 통해 노드 간 직접 이동한다.
• 보존 기간과 임계값으로 제어한다. 일반적으로 Decode는 생성이 끝나면 요청 블록을 해제한다. 양방향 모드에서는 일정 기간 보존하며, 설명된 구성에서 decoder_kv_blocks_ttl 기본값은 480초다. Prefill은 먼저 로컬 접두부 캐시를 확인하고, 재사용 가능한 토큰 수가 kv_recompute_threshold에 도달할 때만 비동기 원격 읽기를 시작한다.
• 노드의 역할은 유지된다. Prefill은 새 프롬프트 토큰의 KV를 계산하고 Decode는 이미 캐시된 블록을 제공한다. P→D와 D→P 모두 NIXL READ 전송 방식을 사용하지만, 각 노드는 자신의 역할에 맞는 원격 및 로컬 블록 메타데이터를 관리한다.

성능과 영향

보고된 멀티턴 테스트는 AWS Elastic Fabric Adapter로 연결된 Amazon EC2 P5en의 1P1D 배포에서 진행됐다. 양방향 전송은 Qwen3-32B에서 TTFT를 최대 1.6배, zai-org/GLM-5-FP8에서 최대 3.3배 개선했다. 다만 실제 수치는 워크로드와 설정에 따라 달라지므로 모든 환경에서 동일한 효과를 보장하는 수치는 아니다.

이 기능의 의미는 단일 요청의 지연을 낮추는 데 그치지 않는다. 생성이 끝난 KV를 즉시 버리는 대신 다음 턴에 활용할 상태로 보존해, 길어지는 대화에서 반복되는 Prefill 계산을 줄인다. 그 결과 가속기 자원을 과거 기록의 재처리보다 새 입력과 생성 작업에 더 효율적으로 배분할 여지가 생긴다.

동시에 운영 복잡성도 증가한다. 배포 환경에는 상태를 유지하는 KV 인식 라우터, 안정적인 대화 식별자, 만료 처리, 원격 블록을 읽지 못했을 때의 재계산 경로가 필요하다. TTL, 재계산 임계값, 로컬 캐시 적중률, 네트워크 성능, 세션 배치가 원격 재사용의 실질적 이득을 좌우한다.

vLLM은 이 기능을 처음 AWS Trainium과 EFA 클러스터에서 구축하고 검증한 뒤, 특정 가속기에 종속되지 않는 기능으로 프로젝트에 기여했다. 이번 글의 성능 결과는 EFA로 연결된 GPU 클러스터에서 얻은 것으로, 동일한 서빙 개념이 다른 가속기 환경에도 확장될 수 있음을 보여준다.

출처: vLLM Blog