vLLM 官方博客十月十四日发文，作者来自 AWS 与 Mistral，介绍推式（push-based）KV 传输如何改善分离式推理的 TTFT 与 TPOT。分离式推理把预填充（prefill）与解码（decode）拆到不同 GPU 池，预填充算完的 KV 缓存必须搬到解码实例才能开始吐字。

拉模式和推模式差在哪？

早期分离式多用拉模式：解码实例轮到自己时，主动向预填充实例要 KV 缓存。这意味着传输发生在解码已经在等的时候，首 token 延迟里硬生生塞进一次跨机拷贝往返。推模式反过来：预填充一算完，就主动把 KV 推给已注册好的解码实例，传输与解码准备重叠起来。

独立后台线程解决了什么？

博客强调用一个专用后台线程把 KV 写操作搬出引擎的前向传播循环。若 KV 传输卡住，在拉模式下会阻塞主引擎，连累同批其他请求。推模式把传输交给后台线程，主引擎继续处理下一批，延迟不再被跨机网络抖动直接传导到每个 token。

TTFT 和 TPOT 为什么一起变好？

TTFT 是首 token 时间，主要被预填充加 KV 搬迁决定；TPOT 是相邻 token 间隔，被解码稳态决定。推模式让 KV 搬迁与预填充尾部重叠，压 TTFT；又因为不阻塞解码主循环，稳态吞吐更稳，TPOT 也跟着改善。这套机制跑在 NIXL 库上，走 Libfabric 底层，是当前分离式推理最主流的 KV 交接路径。

推模式对网络拓扑有什么要求？

推模式要求预填充实例能主动把数据推到解码实例，底层跑在 NIXL 与 Libfabric 上，对 RoCE 或高速互联更友好。如果预填充和解码跨可用区、网络抖动大，推出去的 KV 仍要等到达，收益会打折扣。部署时把配对的预填充与解码实例放在同一低延迟域，才能拿满 TTFT 红利。

去论坛讨论

前往 silicon-agi.com 论坛 参与讨论

你在部署或复现这个技术细节时踩过什么坑？欢迎到论坛交换实测数据与配置片段。