vLLM 双向 KV 传输提升了多轮智能体工作负载的 TTFT

TL;DR

vLLM 增加了双向 KV 缓存传输功能，允许解码节点在后续轮次中将其 KV 块交还给预填充节点，从而在多轮智能体工作负载中将首字延迟 (TTFT) 降低了高达 1.6 倍 (Qwen3-32B) 和 3.3 倍 (GLM-5-FP8)。

为什么双向 KV 传输很重要

多轮智能体应用程序在每一轮都会重新发送整个对话历史记录，迫使预填充节点为之前生成的 token 重新计算 KV 缓存。随着上下文的增长，这种冗余工作增加了加速器的使用量和 TTFT。通过在轮次之间实现 KV 重用，vLLM 消除了大部分重复计算，即使对于非常长的提示词，也能保持延迟平稳。

核心技术贡献

双向 KV 传输机制

  • 双向 KV 流 – 除了传统的预填充到解码 (P→D) NIXL READ 之外，解码节点现在可以在生成后保留符合条件的 KV 块，并将它们的元数据返回给路由器。路由器将此元数据附加到下一个预填充请求中，从而允许解码到预填充 (D→P) NIXL READ。
  • 可配置控制 –
    • decoder_kv_blocks_ttl (默认 480 秒) 决定解码节点保留 KV 块的时长。
    • kv_recompute_threshold (默认 64 个 token) 根据可重用的 token 数量决定是拉取远程 KV 还是在本地重新计算。

NIXL KV 连接器增强

  • 扩展了 NVIDIA Inference Xfer Library (NIXL) KV 连接器，使预填充节点能够使用远程 KV 块，从而镜像了现有的解码端功能。
  • 实际的数据移动仍然是单次 NIXL READ；只有控制流在 P→D 和 D→P 方向之间有所不同。

KV 缓存感知路由器

  • 一个轻量级的有状态代理维护着从 conversation_id 到从解码节点接收到的最新 kv_transfer_params 的内存映射。
  • 路由器仅存储元数据（块位置、TTL、过期时间），从不存储 KV 张量本身，从而保持控制平面的轻量化。
  • vLLM 仓库中提供了示例实现 (disagg_proxy_multiturn.py)。

性能影响

基准测试设置

  • 硬件 – Amazon EC2 P5en (8× NVIDIA H200) 上的 1 个预填充 + 1 个解码节点，通过 AWS Elastic Fabric Adapter (EFA) 连接。
  • 模型 – Qwen3-32B 和 zai-org/GLM-5-FP8 (FP8)。
  • 配置 – 在预填充节点上禁用前缀缓存以模拟缓存驱逐场景；kv_recompute_threshold = 64，decoder_kv_blocks_ttl = 480 秒。

TTFT 结果

模型 提示词长度 (tokens) TTFT 关闭 TTFT 开启 加速比
Qwen3-32B 24 k 778 ms 460 ms 1.6×
GLM-5-FP8 20 k 2 334 ms 702 ms 3.3×
  • 当禁用 KV 重用时，TTFT 会急剧增加（每一轮都进行完全重新计算）。
  • 通过双向传输，TTFT 保持近乎平稳；适度的 KV 传输延迟 (≈30-130 ms) 远小于节省的重新计算时间。

预填充持续时间分解

  • KV 传输时间 – Qwen3-32B 为 30-130 ms；GLM-5-FP8 为 29-110 ms。
  • 节省的预填充计算 – 预填充阶段的大部分时间消失了，特别是对于 GLM-5-FP8，其每个 token 的重新计算成本更高。
  • 原文中的图表展示了针对每个提示词长度的堆叠柱状图比较。

如何采用此功能

  1. 升级到 vLLM v0.21.0+ (或更高版本) 并安装 NIXL 连接器。
  2. 在预填充和解码服务器的 KV 传输配置中启用 bidirectional_kv_xfer。
  3. 部署 KV 缓存感知路由器 – 使用提供的 disagg_proxy_multiturn.py 示例或实现等效逻辑。
  4. 调整参数 – 根据预期的轮次间延迟调整 decoder_kv_blocks_ttl，并根据模型大小和网络带宽调整 kv_recompute_threshold。
  5. 运行基准测试 – 遵循可重复性指南（脚本 serve_pd_multiturn.sh、run_multiturn_sweep.sh、cleanup.sh）以验证您自己集群上的性能。

对智能体 AI 部署的影响

  • 可扩展的延迟 – 自主助手、工具使用智能体和多步推理流水线等应用程序即使在对话历史记录达到数千个 token 时也能保持低延迟。
  • 加速器效率 – 通过避免重复的 KV 重新计算，GPU/TPU 周期被释放用于其他工作负载，从而降低了每个请求的成本。
  • 硬件无关的优势 – 尽管该功能最初是在 AWS Trainium 集群上验证的，但在基于 GPU 的 P5en 实例上也出现了同样的收益，这表明它在各种加速器类型中具有广泛的适用性。
  • 未来扩展 – 解码端 KV 块的租约续期机制可以进一步减少内存浪费，动态阈值可以适应不断变化的网络条件。

可重复性检查清单

  • 实例 – 两个启用了 EFA 的 p5en.48xlarge (8 × H200)，位于同一可用区。
  • 软件栈 – Ubuntu 24.04, NVIDIA driver 580+, CUDA 13.0, EFA 1.50.0, libfabric 2.6.0, NIXL 1.4.1, vLLM 0.29.0 (已应用 PR #40186)。
  • 关键命令 – EFA 安装、vLLM/NIXL 安装、模型下载、服务器启动脚本、代理启动、基准测试扫描脚本。
  • 故障排除提示 – 确保发送了 conversation_id，已应用 PR #40186，TTL 足够，并且正确检测到了 EFA 提供程序。

结论

双向 KV 缓存传输允许解码节点将其 KV 块交还给预填充节点以用于下一轮，从而显著缩短了长对话、多轮智能体对话的 TTFT。在 AWS P5en GPU 上使用 EFA 进行 1 个预填充 + 1 个解码的部署中，该功能在测试的最长提示词下，使 Qwen3-32B 的 TTFT 加速了 1.6 倍，GLM-5-FP8 的 TTFT 加速了 3.3 倍。该方法与加速器无关，可通过 TTL 和重新计算阈值进行配置，并可以使用 vLLM 的 NIXL 连接器和 KV 缓存感知路由器进行集成。

参考资料:

Sources