vLLM是面向大语言模型的开源推理与服务引擎。LLM推理分为两个阶段：prefill处理输入prompt并构建KV缓存，decode用该缓存逐个生成输出token。两个阶段在计算、内存和扩展特性上各不相同。P-D分离把两个阶段放在不同的引擎实例上运行，让各自独立扩展和优化，可以提升资源利用率、吞吐以及负载下的延迟。但代价是：token生成开始前，KV缓存必须从prefill实例传到decode实例，因此高效的KV传输对首token延迟（TTFT）至关重要。
vLLM完成这种传输的方式之一是通过NIXL连接器，它走RDMA网络（如AWS EFA）搬运KV块。在支持的实例类型上，AWS EFA支持GPUDirect RDMA和Neuron Direct RDMA，使NIXL可以在GPU或Trainium设备内存之间直接传输KV块，无需经过主机内存中转。NIXL连接器的默认模式是pull：prefill实例算完prompt的KV缓存后，路由器把源元数据（包括prefill块ID）转给decode实例；decode实例再分配目标块、准备NIXL传输、发起NIXL READ去拉取KV块。这些协调和设置步骤在prefill之后、decode开始之前串行发生，因此拉长了TTFT关键路径。
本文介绍一种push模式的NIXL连接器，把post-prefill的传输协调和设置移出关键路径。对于使用vLLM运行分离式prefill/decode推理的用户，这可以降低TTFT和TPOT，从而改善应用响应性，在高请求速率下尤其明显。
在1P1D部署、用EFA连接的Amazon EC2 P5en实例上，针对Qwen3-32B模型，push模式相比pull模式，TTFT最高提升3倍，TPOT最高提升30%；结果取决于工作负载和配置。该特性先在用EFA连接的AWS Trainium实例集群上构建并验证，之后作为加速器无关的特性贡献给vLLM。本文给出的结果来自带EFA的AWS p5en（GPU）集群，表明这些收益在GPU上同样成立。
push模式KV传输
push模式提升TTFT和decode吞吐，原因有两点：
- 它通过重叠producer和consumer的工作，消除了pull模型的串行化。decode实例在producer还在计算KV时就提前注册目标块，传输在producer的块一就绪时立即开始，而不是在consumer侧发现标识符的往返之后，从而把这个往返从首token路径上移除。
- 它把传输设置时间从decode实例挪走。准备NIXL描述符、提交传输这些设置工作，在prefill侧、在后台线程上运行，decode实例不用在延迟敏感的token生成阶段花这些周期。
净效果就是decode实例上更低的TTFT和更高的输出token吞吐。
push连接器协调三个角色：decode实例提前注册目标块；prefill实例匹配每个请求并发起传输；一个专用后台线程把KV写入带离引擎的forward-pass循环。
实现细节
协议分三个逻辑步骤。
- 注册（decode侧）：当decode实例为需要远程prefill的请求分配本地块时，它准备一份注册信息，描述prefill该往哪写KV——自己的身份和刚预留的块位置。在同一个引擎step内，worker把这份注册作为NIXL通知发给prefill实例。因为注册发生在分配时，连接器在prefill实例完成prefill前就知道目标块在哪。
- 会合（prefill侧）：来自decoder的注册和producer上prefill的完成，到达顺序不定，连接器两种都能处理。注册先到，producer就hold住它直到自己的prefill完成；prefill先完成，producer就hold住请求的块直到注册到达。谁后到谁触发传输。连接器按标识符配对请求，匹配逻辑会考虑重新发起的请求，正确关联被抢占或重试的请求。
- 传输（prefill侧）：请求匹配后，producer建立到decode实例的连接（如果还没有），发起NIXL WRITE，把KV块直接拷进decoder注册的内存，按目标tensor-parallel rank寻址。producer和consumer可能使用不同的内部块布局。每一侧在传输时把块位置映射到自己的物理布局，允许两侧块大小不同。每次WRITE都带一个完成通知，NIXL在数据到达后把它投递给decode实例。decoder统计这些通知，每个向它写入的producer rank对应一个，只有在所有预期通知都到达后才认为KV已收到。
热门跟贴