一句话结论
vLLM v0.21.0 新增双向 KV 传输功能，通过预填充与解码节点间共享缓存，显著降低多轮智能体负载的首字延迟。
关键要点
- 在 vLLM v0.21.0 及更高版本中，启用该功能需配置 NixlConnector 和 KV 缓存感知路由器，并参考 GitHub 复现指南。
- 测试数据显示，Qwen3-32B 模型的首字时间（TTFT）最多减少 1.6 倍，而 zai-org/GLM-5-FP8 模型减少最多 3.3 倍。
- 默认配置下，预填充节点的 KV 重算阈值为 64 个令牌，低于此值时本地重计算，达到或超过时则从解码节点拉取 KV。
- 解码实例在双向模式下保留 KV 块的默认生存时间（TTL）为 480 秒，防止会话缓存被意外逐出。
- 该特性依托 AWS 弹性 Fabric 适配器（EFA）实现低延迟 RDMA 传输，支持 GPU 和 Trainium 设备内存间直接数据交换。
背景与事实
随着多轮智能体（Agentic）工作负载的普及，客户端在每次交互中重新发送包含系统指令、历史提示、工具结果及模型响应的完整对话历史，导致底层推理引擎反复处理大量重复上下文。传统的预填充-解码（P-D）分离架构中，KV 缓存传输通常仅支持从预填充节点向解码节点的单向流动。这种机制导致解码节点保留提示及新生成令牌的 KV 缓存，但预填充节点无法获取。当会话进入后续轮次时，预填充节点因不维护会话状态，易造成活跃会话缓存逐出；在全缓存缺失场景下，必须重新计算完整对话历史的 KV 投影，这不仅增加了加速器容量消耗，更显著推高了首字时间（TTFT）。
为了解决这一效率瓶颈，vLLM 在 v0.21.0 版本中引入了双向 KV 传输机制。该机制允许解码节点在后续对话轮次中向预填充节点返回先前计算的 KV，避免预填充节点重复计算共享上下文。这一过程受可配置的 KV 重算阈值控制：预填充节点通过参数 kv_recompute_threshold（默认 64 个令牌）判断是否复用，低于阈值时本地重计算，达到或超过时从解码节点拉取 KV。同时，解码实例在双向模式下保留 KV 块，配置参数 decoder_kv_blocks_ttl 默认为 480 秒。扩展后的 NVIDIA 推理传输库（NIXL）KV 连接器使得预填充节点能够消费远程 KV 块，而 KV 传输机制（NIXL READ）在预填充到解码（P->D）和解码到预填充（D->P）方向通用，由 KV 缓存感知路由器协调元数据流。
性能评测基于 Amazon EC2 P5en 实例构建，采用 1 预填充节点和 1 解码节点（1P1D）架构，实例间通过 AWS 弹性 Fabric 适配器（EFA）连接。EFA 提供低延迟远程直接内存访问（RDMA）网络，支持在支持的实例类型下直接在 GPU 或 AWS Trainium 设备内存间传输 KV 块。基准测试对比了开启与关闭双向传输时 Qwen3-32B 和 zai-org/GLM-5-FP8 模型在不同提示长度下的表现。具体数据显示，对于 Qwen3-32B，开启双向传输后，TTFT 从 2k 令牌的 122 毫秒增至 24k 令牌的 460 毫秒，而关闭时则从 158 毫秒激增至 778 毫秒；对于 zai-org/GLM-5-FP8，TTFT 从 2k 令牌的 358 毫秒增至 20k 令牌的 702 毫秒，关闭时则从 500 毫秒增至 2,334 毫秒。KV 传输耗时方面，Qwen3-32B 约为 30 至 130 毫秒，zai-org/GLM-5-FP8 约为 29 至 110 毫秒。开启传输后的总预填充持续时间分别为 128 至 414 毫秒及 316 至 541 毫秒，均低于仅重计算路径的 153 至 744 毫秒及 500 至 2,331 毫秒。
影响分析
对于中文开发者与从业者而言，vLLM 双向 KV 传输机制为高并发、长上下文的多轮智能体应用提供了更高效的部署方案。这一功能使得在 P-D 分离架构下，无需昂贵的集中式全局缓存即可维持会话状态的连续性，降低了加速器显存压力。在实际工程中，团队需权衡配置 kv_recompute_threshold 和 decoder_kv_blocks_ttl 参数，以平衡缓存命中率与内存占用。分析判断认为，随着模型参数量和上下文窗口进一步扩大，KV 复用带来的收益将更加显著，尤其是对于单次令牌重算时间较高的模型（如 GLM-5-FP8），该机制能有效避免长历史对话带来的延迟峰值，提升用户体验。
适用边界
该结论主要适用于基于 vLLM v0.21.0 及以上版本、部署在支持 AWS EFA 的 Amazon EC2 P5en 或 Trainium 实例、并采用 1P1D 架构的多轮智能体负载场景。性能收益高度依赖网络配置（EFA 低延迟 RDMA）和硬件类型（GPU/Trainium），在缺乏 EFA 支持或非 P-D 分离架构的集群中，双向 KV 传输可能无法有效实施或收益有限。此外，对于单轮交互或上下文极短（低于重算阈值 64 令牌）的工作负载，直接本地重计算可能比拉取远程 KV 更高效，此时开启该功能反而可能因网络传输开销降低整体效率。
孤本观察
编辑判断认为，vLLM 通过引入可配置的 KV 重算阈值与默认 TTL 机制，将“缓存复用”从简单的命中/缺失逻辑升级为精细化的成本控制模型，这反映出大模型推理架构正从追求极致吞吐转向兼顾交互延迟与资源效率的务实阶段。
常见问题
启用vLLM双向KV传输功能需要哪些核心配置？
需配置NixlConnector和KV缓存感知路由器，并参考GitHub复现指南，同时可调整kv_recompute_threshold和decoder_kv_blocks_ttl参数。
KV重算阈值默认值是多少？低于或高于该阈值时分别如何处理？
默认阈值为64个令牌。低于此值时预填充节点本地重计算；达到或超过时，则从解码节点拉取KV缓存。
解码实例在双向模式下保留KV块的默认生存时间（TTL）是多少？
默认生存时间（TTL）为480秒，旨在防止会话缓存被意外逐出。
在缺乏AWS EFA支持或非P-D分离架构的场景下，双向KV传输的适用性如何？
该机制可能无法有效实施或收益有限，因其高度依赖EFA提供的低延迟RDMA网络及P-D分离架构。