本周精读：Push-Based KV Transfer to Improve TTFT and TPOT for Disaggregated Inference in vLLM。
作者：Sunita Nadampalli（AWS）、Nicolò Lucchesi（Mistral）；发布平台：vLLM 官方博客；发布日期：2026-10-14；本期导读日期：2026-10-17。原文已完整阅读，以下为原创导读。文中测量来自作者，本期未自行复测。
核心观点与证据
作者把 KV 交接改为 decode 提前登记目标内存、prefill 就绪后主动写入；传输准备交给 prefill 后台线程，以减少 decode 主循环上的工作。两侧准备事件可以先后任意到达，必须匹配成功才发起传输。架构与实现见原文。
代价是更早确定 decode 节点。作者仍建议需要延后路由或双向 KV 传输的场景考虑 pull。权衡见原文。
实测条件：Qwen3-32B、BF16、1P1D；两个 EC2 p5en.48xlarge 节点，各 8 张 H200、节点内 TP8，经 EFA 互联；输出 128 tokens，decode 关闭前缀缓存。在 16k 输入、8 QPS 时，作者报告 TTFT 由 pull 约 1,744ms 降到 push 约 540ms。该测量隔离完整 KV 传输成本，不代表开启缓存后的生产收益。性能与复现条件见原文。
为什么值得你关注
我的判断：上期适合判断服务要不要拆，本期适合追问拆开之后谁在等待谁。它把服务编排、内存生命周期、线程职责与延迟指标连接起来，工程信息密度很高。
精读时建议自己画两条时间线：标出每一步依赖什么事件、占用哪个执行线程、能否与计算重叠。再问一句：改进来自数据搬得更快，还是搬运前的等待变少？这个区分也适用于分布式存储、通信流水线和异步任务系统。
读实现部分时，把请求重试、目标内存何时能回收、完成信号如何计数写成问题带进去。这些是我建议用于审阅同类系统的检查点，并不表示本文已经验证了所有异常场景。
阅读前置知识
- Prefill / decode 与 KV cache：输入处理建立注意力中间状态，后续生成复用它；分离部署需要交接状态。
- TTFT 与 TPOT：前者衡量首 token 等待，后者衡量平均输出 token 时间；TPOT 不等同于最慢一次 token 间隔。
- RDMA 与内存登记：理解跨设备直接访问需要可寻址、有效的目标内存，以及数据到达和可消费之间的边界。
- 关键路径与异步并发：总延迟由依赖链决定；“移到后台”之后仍须检查资源竞争和完成通知。
- TP 与路由：多卡共同执行一个模型时，状态交接涉及多个 rank；路由决定请求由哪个实例承接。
读完最该带走的 3 个结论
- 先拆等待，再谈带宽。 我的工程建议是为交接路径分别测量准备、排队、传输和接收确认，再决定优化方向。适用于传输前后控制开销不可忽略的系统。
- 提前准备也会提前消耗调度选择。 我会把“目标节点何时确定、预留内存占用多久、负载突变能否改派”纳入方案评审。长 prefill 或负载波动明显时，需用真实流量评估这一代价。
- 用生产缓存与故障行为重新验收。 本文的关闭缓存实验有助于定位传输机制；我的上线判断还需要加入实际命中率、多轮请求、取消与重试，并同时检查正确性、尾延迟和有效吞吐量。