vLLM双向KV传输：让多轮智能体对话少做重复预填充

导语

多轮智能体的上下文会随着推理、工具调用和结果整合持续增长。客户端在新一轮请求中通常会重新发送系统指令、历史问题、工具结果以及模型此前生成的内容。对采用Prefill-Decode（P-D）分离的服务系统来说，这意味着预填充节点可能反复处理已经计算过的历史Token，首Token延迟（TTFT）也会随对话变长而上升。

vLLM近期介绍的双向KV传输，试图把这部分重复工作削减掉。传统架构主要沿Prefill到Decode方向传输KV缓存；新机制允许Decode节点在生成结束后保留合适的KV块，并在下一轮将其提供给Prefill节点使用。

核心要点

• 从单向变为双向复用。 首轮请求仍由Prefill节点计算提示词KV，再由Decode节点读取。生成完成后，Decode节点保留提示词和响应相关的KV元数据，下一轮由Prefill节点读取可复用部分，只计算新增后缀。
• 路由器只管理元数据。 KV感知路由器以conversation_id关联会话，缓存Decode返回的块位置和有效期信息。真正的KV张量不经过路由器，而是通过NIXL在节点之间点对点传输。
• 复用受到阈值和期限控制。 Decode节点不会永久保留请求块，默认的decoder_kv_blocks_ttl为480秒。Prefill节点在本地前缀缓存匹配后评估远程KV，只有可复用Token数量达到kv_recompute_threshold时，才异步发起反向读取。
• 保持节点分工。 Prefill节点负责为新提示词计算KV，Decode节点主要提供已经存在的缓存块；两种方向共用NIXL READ传输机制，但各自维护远程和本地块的元数据逻辑。

性能与意义

vLLM在配备AWS EFA网络的Amazon EC2 P5en、1P1D部署上进行了多轮测试。结果显示，双向传输对Qwen3-32B的TTFT最高带来1.6倍改善，对zai-org/GLM-5-FP8最高带来3.3倍改善。官方同时强调，具体结果会受工作负载和配置影响，不能简单视为所有部署的固定收益。

这项改动的价值不只是降低一次请求的延迟。它把多轮会话中的缓存生命周期从单个节点扩展到Prefill和Decode协作流程，减少长上下文场景中的重复预填充，帮助服务系统把加速器容量用于新内容处理。对于会话助手和工具调用密集的智能体，缓存命中情况、路由状态管理、网络带宽以及TTL设置将成为部署效果的重要因素。

从工程角度看，双向KV传输也说明P-D分离并非只能按请求的单次生命周期设计。要让跨轮复用稳定工作，系统需要一个有状态的KV感知路由器，并处理会话标识、缓存过期、节点可达性和失败后的重新计算。vLLM提供了相关连接器支持及示例代理，且该能力最初在AWS Trainium集群上验证，之后作为与加速器无关的能力贡献到vLLM；本文展示的结果则来自GPU集群。

来源：vLLM Blog