vLLM 推出推送式 KV 传输连接器，将高负载下首字时间最高降低 3 倍

一句话结论

vLLM 引入基于推送模式的 KV 连接器，通过重叠计算消除关键路径延迟，高负载下首字时间最高降低 3 倍。

关键要点

• 基准测试在 Amazon EC2 P5en 实例上，使用 Qwen3-32B 模型（1P1D 架构）进行，通过 EFA 网络连接。
• 高负载场景下（8 QPS，16k 输入），拉取模式首字时间（TTFT）约为 1744 毫秒，而推送模式降至 540 毫秒。
• 在 16k 输入的高速率负载中，推送模式将每词时间（TPOT）从拉取模式的 10.4 毫秒降至 7 毫秒左右。
• 该功能先在 AWS Trainium 集群上验证，后作为加速器无关特性贡献至 vLLM，在 GPU 集群上同样有效。
• 启用此功能需将预填充和解码服务器均配置为使用 NixlPushConnector，替代默认的 NixlConnector。

背景与事实

vLLM 是一款开源的大语言模型推理引擎，其推理过程分为预填充（Prefill，处理输入并构建 KV 缓存）和解码（Decode，逐词生成输出）两个阶段。在预填充解码解耦（Prefill-Decode Disaggregation）架构中，这两个阶段运行在独立实例上，必须将 KV 缓存从预填充实例传输至解码实例。传输效率直接影响首字时间（TTFT）和每词时间（TPOT）。

此前，vLLM 通过 NVIDIA 推理传输库（Inference Xfer Library，NIXL）连接器传输 KV 块，支持利用远程直接内存访问（RDMA）进行高效传输，例如在 AWS 弹性 Fabric 适配器（EFA）支持的实例上，可实现 GPU 或 AWS Trainium 设备内存间的直接传输，无需经过主机内存中转。默认情况下，NIXL 连接器采用拉取（Pull-based）模式：预填充完成后，路由器将源元数据中继至解码实例，解码实例再发起读取操作拉取 KV 块。这种串行协调过程延长了关键路径，导致高负载下性能下降。

新引入的推送（Push-based）NIXL 连接器改变了这一机制。它将预填充后的传输协调移至关键路径之外。具体而言，解码实例在分配内存时会预先注册目标块并向预填充实例发送通知；预填充实例在完成计算后匹配请求并主动发起传输，利用专用后台线程执行 KV 块的写入操作。这一机制允许预填充计算与解码侧的内存块分配及注册过程重叠执行。在基准测试中，评估使用 Qwen3-32B 模型，在 Amazon EC2 P5en 实例配合 EFA 网络的 1P1D 部署架构下进行。测试禁用了前缀缓存以隔离传输性能。结果显示，在低请求速率（1 QPS）下两种模式表现相近，但在高请求速率（8 QPS）和长输入（16k）场景下，推送模式展现出显著优势。

影响分析

对于构建大规模语言模型推理服务的中文开发者与从业者而言，这一更新带来了实质性的性能提升机会。分析表明，在推理服务面临高峰流量或处理长文本场景时，采用推送模式可以显著降低用户感知到的首字延迟。例如，在 8 QPS 的高压测试下，首字时间从 1744 毫秒降至 540 毫秒，这意味着用户体验从“等待”转变为“即时响应”。

此外，该功能对基础设施的依赖性有所降低。由于该技术最初在 AWS Trainium 集群验证后便作为加速器无关特性贡献给 vLLM，且结果在 GPU 集群上同样有效，这意味着开发者无需锁定特定的硬件架构即可获得优化。在实际部署中，若允许早期选定解码节点且优先考虑降低延迟，推送模式是更优选择；但若需要双向传输或基于预填充后的负载均衡策略选择解码实例，拉取模式仍不可替代。vLLM 同时支持这两种模式，赋予了工程师根据具体业务场景进行精细调优的能力。未来随着后台线程模型的进一步引入，拉取模式的性能也有望得到改善，但这需要开发者在架构设计阶段进行前瞻性的考量。

适用边界

该结论的适用存在明确边界：推送模式的优势主要在高请求速率和长输入长度的场景下显现；在低负载或短输入场景中，其性能提升并不显著，两者表现相近。此外，该模式要求解码侧能够尽早进行内存注册与预填充侧的“会合”，因此不适用于那些严格依赖预填充完成后动态决策路由、或需要极其复杂的实时负载均衡策略的场景。硬件方面，虽然结果具有加速器无关性，但高性能的 RDMA 网络（如 EFA）是实现直接内存传输和最大化收益的关键前提，在缺乏高速网络支持的集群中，传输瓶颈可能会重新出现，削弱推送模式的优势。

孤本观察

基于上述事实，编辑判断 vLLM 此次更新标志着推理引擎从“简单搬运”向“系统级流水线优化”的演进；通过后台线程与异步注册将传输开销移出关键路径，是当前应对大模型长上下文高并发场景的有效技术路径。

来源：AWS Machine Learning Blog