AWS Machine Learning Blog · 2026/10/20 00:05:17
vLLM 引入推送式 KV 传输优化分离推理延迟
vLLM 推出基于 NIXL 连接器的推送式 KV 缓存传输机制，旨在解决预填充与解码分离架构中的通信瓶颈。该方案通过 RDMA 技术直接推送数据，显著降低首 Token 时间（TTFT）和每输出 Token 时间（TPOT），提升大规模 LLM 服务效率。
报道全文原始报道全文
本文目录9 个章节
vLLM 是一款用于大语言模型（LLM）的开源推理与服务引擎。LLM 推理包含两个截然不同的阶段：预填充（prefill），负责处理输入提示并构建键值（KV）缓存；以及解码（decode），利用该缓存逐 token 生成输出。这两个阶段在计算、内存和扩展特性上存在显著差异。预填充-解码分离架构（P-D disaggregation）将这两个阶段运行在独立的引擎实例上，从而允许每个阶段独立进行扩展和优化。这有助于提高负载下的资源利用率、吞吐量和延迟表现。然而，这也要求在开始 token 生成之前，将 KV 缓存从预填充实例传输到解码实例，因此高效的 KV 传输对于降低首 token 时间（TTFT）至关重要。
vLLM 执行此传输的方式之一是通过 NVIDIA Inference Xfer Library (NIXL) 连接器，它支持通过具备远程直接内存访问（RDMA）能力的互连网络移动 KV 块，例如 AWS Elastic Fabric Adapter (AWS EFA，即 AWS 服务器间使用的低延迟 RDMA 网络)。在支持的实例类型上，AWS EFA 支持 GPUDirect RDMA 和 Neuron Direct RDMA。因此，NIXL 可以直接在 GPU 或 AWS Trainium 设备内存之间传输 KV 块，而无需经由主机内存中转。NIXL 连接器的默认模式为 拉取式（pull-based）：当预填充实例完成提示词 KV 缓存的计算后，路由器会将源元数据（包括预填充块 ID）中继给解码实例。随后，解码实例分配目标块，准备 NIXL 传输，并发起 NIXL READ 操作以从预填充实例拉取 KV 块。由于这些协调和设置步骤是在预填充之后、解码开始之前顺序执行的，它们延长了 TTFT 的关键路径，如下方时间线所示。
图 1：拉取模式（Pull-mode）KV 传输时间线，其中路由器中继、解码端分配和 NIXL READ 在通往首 token 的路径上串行执行
本文介绍了一种基于推送（push-based）的 NIXL 连接器，它将预填充后（post-prefill）的传输协调与设置移出关键路径。如果你使用 vLLM 运行分离式预填充/解码推理，推送模式可以通过降低 TTFT（首 token 延迟）和 TPOT（每输出 token 时间）来提升应用响应速度，尤其是在高请求速率下效果显著。
在我们于 Amazon Elastic Compute Cloud (Amazon EC2) P5en 实例上使用 EFA 连接的 1P1D 部署基准测试中，对于 Qwen3-32B 模型，与拉取模式相比，推送模式实现了高达 3 倍的 TTFT 改善以及高达 30% 的每输出 token 时间（TPOT）改善（详见“性能数据”部分）。结果取决于工作负载和配置。
我们在通过 EFA 连接的 AWS Trainium 实例集群上构建并验证了该功能，随后将其作为加速器无关的功能贡献给 vLLM。此处展示的结果来自带有 EFA 的 Amazon EC2 P5en (GPU) 集群，表明这些增益同样适用于 GPU。本文解释了基于推送的架构、传输流程、线程模型、性能结果以及如何复现基准测试。
基于推送的 KV 传输
本节解释基于推送的设计：其架构、传输协议以及使 KV 传输脱离关键路径的线程模型。
架构概览
基于推送的传输通过以下两点改善了 TTFT 和解码吞吐量：
- 它消除了拉取模型的串行化，通过重叠生产者和消费者的工作来实现。解码实例在生产者仍在计算 KV 时预先注册其目标块。因此，一旦生产者的块就绪，传输即可立即开始，而不是等待消费者端的 ID 发现往返过程，从而将该往返过程从通往首 token 的路径中移除。
- 它将传输设置时间移出了 decode 实例。 该设置运行在预填充侧和一个后台线程上。它准备 NIXL 描述符并提交传输，因此 decode 实例不会在其对延迟敏感的 token 生成阶段消耗这些周期。
最终效果是降低了 TTFT，并提高了 decode 实例上的输出 token 吞吐量。
推送连接器协调三个角色：decode 实例预先注册其目标块，prefill 实例匹配每个请求并发起传输，而一个专用的后台线程将 KV 写入操作从引擎的前向传播循环中分离出来。下图展示了这些组件如何协同工作。
图 2：基于推送的 KV 传输架构，展示 decode 实例、prefill 实例和后台传输线程之间的协调机制
实现细节
该协议包含三个逻辑步骤。
1. 注册（decode 端）。 当 decode 实例为需要远程 prefill 的请求分配本地块时，它会准备一份注册信息，描述 prefill 实例应将 KV 写入何处：包括自身标识以及刚刚预留的块位置。在同一个引擎步骤内，worker 通过 NIXL 通知将此注册信息发送给 prefill 实例。由于注册发生在分配时刻，连接器在 prefill 实例完成预填充之前就已知道目标块。
2. 会合（prefill 端）。 来自解码器的注册信息与生产者上预填充的完成可能以任意顺序到达，连接器能够处理这两种情况。如果注册信息先到达，生产者会将其保留直到自身的预填充完成。如果预填充先完成，生产者会保留该请求的块直到注册信息到达。后发生的事件触发传输。连接器通过 ID 配对请求，且匹配过程考虑了重新发出的请求，能够正确关联被抢占或重试的请求。
3. 传输（Prefill 侧）。 一旦请求匹配成功，生产者会建立与解码实例的连接（如果尚未存在），并发起 NIXL WRITE 操作，将 KV 块直接复制到解码器已注册的内存中，同时寻址每个张量并行 rank。生产者和消费者可以使用不同的内部块布局。在传输时，每一方都会将块位置映射到其自身的物理布局，从而允许两侧使用不同的块大小。每次 WRITE 操作都携带一个完成通知，当数据到达后，NIXL 会将该通知发送给解码实例。解码器会对这些通知进行计数，每个写入它的生产者 rank 对应一个通知。只有在收到所有预期的通知后，解码器才会认为 KV 已接收完毕，此时请求进入解码阶段。
线程模型
Push 连接器通过在每个 Prefill worker 上使用专用的后台传输线程，将模型执行与 KV 传输准备分离开来。在请求开始时，解码主循环分配其目标 KV 块并将其注册到 Prefill 实例，与此同时，Prefill 主循环计算提示词（prompt）的 KV 缓存。当目标注册和提示词 KV 均就绪后，Prefill 主循环将 KV 块交给后台线程，并迅速返回以继续模型执行。
后台线程负责建立或复用 NIXL 连接，将请求的 KV 块 ID 映射为内存描述符，合并连续的块以形成更大的传输区域，并向解码实例提交 NIXL WRITE 操作。当 NIXL 完成传输时，它会向解码实例发送完成通知，随后解码实例开始生成 token。将描述符准备和传输提交工作从延迟敏感的主循环中移出，可防止这些每请求开销延迟模型执行。下图展示了单个请求在主循环和后台线程之间的交接过程。
图 3：基于 Push 的线程模型中，单个请求在主循环和后台线程之间的交接过程
Pull 与 Push 的时间对比
图 4：Pull 与 Push 传输流程对比，突出显示 Push 模式如何将解码端（decode-side）的初始化与预填充（prefill）重叠
这两种模式还涉及路由权衡。Pull 模式允许路由器在预填充完成后选择解码实例，这为负载感知路由和服务质量（QoS）管理提供了更大的灵活性。Push 模式则更早地选择解码实例，以便目标端的初始化可以与预填充过程重叠。作为回报，在同等负载下，预填充实例可以更早释放其 KV 块，因为一旦 Prompt KV 和目标注册就绪，传输即可立即开始。
性能数据
在评估中，我们在采用 EFA 互联的 Amazon EC2 P5en 实例上，以 1P1D（1 个预填充节点 + 1 个解码节点）部署架构运行了 Qwen3-32B 模型。为了隔离 P→D 传输性能，我们配置基准测试禁用前缀缓存，使用参数 --no-enable-prefix-caching。此配置使得解码节点必须从预填充节点检索完整的 KV Cache 来处理每个请求。否则，重叠的 Prompt 可能会复用解码节点的本地缓存并绕过传输，从而产生误导性的对比结果。
下图比较了 Push 和 Pull KV 传输的 TTFT（首 Token 延迟）。我们扫描了 1k–16k 的输入长度以及 1–8 每秒查询数（QPS）的请求速率。在低负载和短 Prompt 情况下，两种模式的性能几乎相同。随着 QPS 和输入长度的增加，Pull 模式性能急剧下降，在 8 QPS 和 16k 输入长度时达到约 1,744 ms。而 Push 模式保持在较低水平，约为 540 ms，实现了大约 3 倍的降低。差距产生的原因在于，Pull 模式在解码工作线程上同步内联发布 NIXL 描述符（位于引擎循环内部），这会阻塞 Token 生成。Push 模式将该操作移至后台线程，使其脱离关键路径。
图 5：在不同输入长度和请求速率下，Push 与 Pull KV 传输的 TTFT 对比（1P1D 拓扑结构，输出 128 个 Token，解码节点禁用前缀缓存）
该图表展示了相同条件下的 TPOT。其趋势与 TTFT 一致。在轻负载下，push 和 pull 模式表现接近，约为 5.6–5.8 ms。随着负载和输入长度的增加，pull 模式在 4–8 QPS 且输入长度为 16k 时攀升至约 10.4 ms，而 push 模式则保持在 7 ms 左右。这是因为 push 模式将描述符准备和传输提交从 decode worker 中卸载出去。由于 token 生成不会因此受阻，即使在高并发和长上下文场景下，单 token 延迟也能保持平稳。
图 6：在不同输入长度和请求速率下，push 与 pull KV 传输的 TPOT 对比（1P1D 拓扑结构，输出 128 个 token，decode 节点禁用前缀缓存）
如何运行基准测试
要复现我们的 1P1D 基准测试配置（即一个 prefill 节点和一个 decode 节点），并使用通过 EFA 连接的 Amazon EC2 P5en 实例，请参考 Reproducing our results 指南中的详细说明。该指南涵盖了环境搭建、启动 vLLM prefill 和 decode 服务器、运行基准测试以及收集结果等内容。此功能也可在其他支持的配置上运行，但性能结果会因硬件、模型、工作负载和网络配置的不同而有所差异。
结论
在本文中，我们展示了基于 push 的 KV connector 如何将 prefill 计算与 decode 端的块分配及注册重叠执行，从而将 post-prefill 路由器的往返开销以及 decode 端的传输设置从关键路径中移除。这降低了 TTFT 和 TPOT，尤其是在高请求速率下。在我们使用通过 EFA 连接的 Amazon EC2 P5en 实例进行的 Qwen3-32B 1P1D 部署基准测试中，与 pull 模式相比，push 模式使 TTFT 最高提升了 3 倍，TPOT 提升了 30%。具体结果因工作负载和配置而异。若要使用 push 模式，请将 prefill 和 decode 服务器均配置为使用 NixlPushConnector 而非 NixlConnector。
当可以接受提前选择 decode 节点且优先降低 TTFT 时，请选择基于推送（push-based）的连接器。对于需要双向 KV 传输或希望在 prefill 之后才确定 decode 实例以实现负载感知路由的工作负载，基于拉取（pull-based）的连接器仍然是更合适的选择。vLLM 同时支持基于推送和基于拉取的 KV 连接器，因此你可以选择最适合自身部署的方案。
作为未来的改进方向，我们正在探索将后台 NIXL 线程模型引入 pull-mode 连接器，把 NIXL 的设置移出关键路径，从而使 pull-mode 工作负载也能受益于同样的优化。我们已提交了一个 pull request 来探讨这一方案。
致谢
感谢 vLLM 社区在维护此功能方面提供的支持。