KV缓存不再等解码端来拉：vLLM改由预填充端推送，首token延迟最多降到三分之一
核心概要
vLLM新增推送式NIXL连接器，把预填充到解码的KV缓存传输协调从关键路径上移开。此前拉取模式要等预填充完成后，由路由器把元数据转给解码实例，解码端再分配块并发起读取，这段串行开销直接计入首token延迟。推送模式让解码端在分配块时就登记目标位置，预填充端在后台线程发起NIXL WRITE，在Qwen3-32B、1P1D的P5en加EFA部署上，8 QPS、16k输入时首token延迟从约1744毫秒降到约540毫秒，TPOT从约10.4毫秒降到约7毫秒，结果随负载与配置变化。
深度剖析
分离式预填充/解码推理中，KV缓存传输的协调与建立不再压在解码实例的关键路径上，解码可以更早开始生成token。 此前的拉取模式在预填充完成后才由路由器转发源元数据，解码实例再分配目标块、准备传输并发起NIXL READ，这些步骤串行发生在预填充之后、解码之前。 在1P1D部署、Amazon EC2 P5en实例加EFA、Qwen3-32B上，关闭前缀缓存以强制每个请求都从预填充节点取完整KV，扫描1k–16k输入长度与1–8 QPS；低负载短提示下两种模式几乎相同，随QPS和输入长度上升拉取模式急剧退化。
推送模式把传输建立工作放到预填充侧的后台线程，解码实例不再在延迟敏感的token生成阶段消耗这些周期。 拉取模式在解码worker的引擎循环内同步提交NIXL描述符，这段工作会阻塞token生成。 8 QPS、16k输入时拉取模式首token延迟约1744毫秒，推送模式约540毫秒，约三倍差距；TPOT在轻载时两者都在5.6–5.8毫秒附近，高负载长上下文下拉取升至约10.4毫秒，推送保持在约7毫秒附近。
推送连接器用三步协议协调解码实例、预填充实例和后台传输线程，使目标块在预填充完成前就已登记。 拉取模式需要一次消费者侧的标识发现往返，推送模式去掉了这次往返。 解码端在分配本地块时把自身标识和块位置作为NIXL通知发给预填充端；预填充端按标识配对请求并处理重发请求，随后建立连接并发出NIXL WRITE，直接写入解码端已登记内存，每个写入携带完成通知，解码端收齐所有生产者rank的通知后才进入解码。
启示与展望
演示范围是1P1D部署、Amazon EC2 P5en实例加EFA、Qwen3-32B，输入长度1k–16k、请求率1–8 QPS，并关闭前缀缓存以强制每个请求都取完整KV。该特性先在连接EFA的AWS Trainium集群上构建验证，再作为加速器无关特性贡献给vLLM，报告的结果来自P5en GPU集群。启用推送模式需要预填充与解码服务器都配置NixlPushConnector；其他受支持配置也可运行，但性能随硬件、模型、负载和网络配置变化。
推送模式需要更早选定解码实例，因此牺牲了拉取模式在预填充完成后按负载选择解码实例的灵活性；拉取模式仍是需要双向KV传输或延后解码实例选择场景的更合适选择。低负载短提示下两种模式表现几乎相同，收益主要出现在高请求率与长上下文。作者表示正在探索把后台NIXL线程模型引入拉取模式连接器，并已就此开出拉取请求。