Memory 技术日报 2026-07-24：远程 KV 兜底、P-D 无缝交接与动态推测解码陷阱
过去 24 小时的三条 GitHub 工程信号，分别从 P-D KV 交接、远程 KV 读取尾延迟和动态 speculative decoding 并发退化切入，帮助工程团队决定先读 RFC、做故障注入还是复现 batch 阈值问题。
先看结论
北京时间 2026 年 7 月 23 日 09:00 至 7 月 24 日 09:00，窗口内最值得跟进的三条 memory/context 信号都来自 GitHub，而且都还停留在 open RFC 或 issue：SGLang 讨论如何把 P-to-D 的 KV 传输等待藏到 token replay 后面，vLLM 讨论远程 KV 读取变慢时何时改走本地重算，另一条 vLLM 报告则显示动态 speculative decoding 在并发跨过 batch 阈值后可能把吞吐打穿。它们没有提供可直接复用的稳定版本，适合进入阅读、复现和压测队列。
| 进展 | 窗口内时间 | 读者要看什么 | 当前动作 |
|---|---|---|---|
| SGLang P-to-D token replay RFC | 7 月 23 日 12:16 | 用短 token log 重建 post-prefill KV tail，减少 handoff bubble | 先读协议和页冻结边界，暂不当作已实现优化 |
| vLLM remote KV soft-timeout RFC | 7 月 23 日 15:21 | 远程 Mooncake get 变慢时并行本地重算，隔离旧 KV block | 用真实尾延迟和额外 HBM 做小流量实验 |
| vLLM dynamic speculative decoding 报告 | 7 月 23 日 15:25 | batch 阈值切换与 KV lookahead、drafter forward、CUDA graph 形状变化的耦合 | 先复现 8 并发对照，不要把报告数字当官方 benchmark |
三条进展
1. SGLang：用 token replay 藏住 P-to-D 的 KV 交接尾部
现有路径要等待 prompt KV 从 Prefill worker 传到 Decode worker，Decode 才能继续生成。RFC 的改法是：Prefill 在传输进行时暂时继续生成，把新 token 写入一个单调递增的 handoff log；Decode 收到冻结的 prompt KV 后，用短 extend 并行 replay 这些 token，只重建 post-prefill 的 KV tail，追上 Prefill 后再原子地接管输出。它不替换 Mooncake，也不改 attention math，目标是去掉传输完成前的等待气泡。
这套设计最有价值的地方在于把「传 KV」和「传输期间产生的少量新状态」拆开了。token log 很小，而逐层 KV tail 更大，replay 可能用更高吞吐追上源端。不过 RFC 只允许同模型、同 TP、同 KV layout 的 1P1D greedy MVP，不支持 speculative decoding 和多模态输入，也没有提交性能结果。
工程上更该先看正确性边界。Prefill 进行 bridge decode 时，Decode 正在读取的 prompt KV 必须保持不变；RFC 要求冻结最后一个 prompt page，或在首个 bridge token 前做 copy-on-write。没有这个保护时，实验路径宁可拒绝某些 paged MLA 配置，也不能悄悄开启。对使用 P/D 分离的团队，第一步应是补齐页冻结、重复 ACK、旧 epoch 和失败回退测试，再谈 TTFT 收益。
判断： 这是一个值得读协议细节的 serving RFC，不是可以直接升级的 feature。它把 KV handoff 的问题从「传输带宽」扩展到了「输出所有权和页边界」，复现门槛高，但和长 prompt、P/D 分离服务直接相关。
2. vLLM：远程 KV 读慢时，先重算还是继续等
问题来自一个很具体的尾延迟：远程 Mooncake
get 通常比本地重算快，但少数慢请求可能等待约 60 秒才失败。提案建议增加一个可配置的 soft timeout，例如 5 秒。超时后，请求不再把远程加载放在关键路径上，而是保留原来的 KV block A，把它从 allocator 中隔离出来，再分配物理上不同的 block B 做本地 KV 重算。远程加载继续在后台完成，结束后丢弃结果并释放 A。这里的关键不是把 60 秒硬改成 5 秒。原 RFC 特别强调，只要旧传输还可能写入
A，就不能把 A 还回 allocator；逻辑上的超时不等于底层传输已经结束。这个细节决定了方案是否会把偶发慢请求变成 KV corruption 或 allocator race。代价也很清楚：快路径不变，慢请求会暂时多占一份 HBM，并重复计算 KV；如果没有额外 block，系统继续沿用原来的等待或失败行为。RFC 没有报告线上收益，也没有定义 RDMA 取消和传输层恢复。适合复现的实验是固定远程命中率，注入不同
get 延迟，分别记录 P99 TTFT、quarantined HBM、重复 prefill token 和 allocator 压力。判断： 对已有远程 KV offload 的团队，这条比单纯调大超时更值得读。它把异常恢复明确成一个有内存账本的双路径问题，但在没有传输取消和容量上限压测前，不能把 soft timeout 当作默认配置。
3. vLLM：动态 speculative decoding 在 batch 阈值处可能拖垮并发吞吐
报告者在 NVIDIA GB10 / DGX Spark 上，用 Qwen3.5-122B-A10B INT4、原生 MTP 和 8 个并发请求做了对照。静态
k=2 时，8 个 180-token 请求的聚合速度约为 232 tok/s，约 6.3 秒完成；动态配置在 batch 1-4 使用 k=2、batch 5-512 关闭 speculation 后，聚合速度落在 24-157 tok/s，耗时 40-60 秒。单流速度从 59.6 tok/s 变成 50.0 tok/s，输出 token 数相同。4这不是官方 benchmark，报告者也没有 profiler trace。当前可见的代码阅读假设包括：
K=0 时 drafter 仍可能先做一次完整 forward 以保持自己的 KV cache 同步；动态 schedule 关闭了保持 uniform spec shape 的 padding，使 PIECEWISE 路径遇到更频繁的形状变化；batch 计数还可能把 prefill 和 chunk 一起算入阈值，导致 K=2 与 K=0 来回切换。报告还提出 KV lookahead 在 K=0 时仍按静态 k=2 预留，但作者把这一点列为最低置信度假设，不能直接当成根因。它对 memory 系统的提醒是：KV cache 的问题不只在容量和命中率，调度器里一个动态 token budget 也会改变 draft KV、lookahead slot、CUDA graph shape 和 preemption 条件。复现时应把静态
k=2、动态阈值配置和真正的 non-spec 配置放在同一硬件、同一 prompt、同一并发度下，额外记录 draft forward 次数、KV 预留 block、batch 阈值切换次数和 P50/P95 ITL。判断： 这条报告适合进入复现队列，不适合直接作为「动态 speculation 有问题」的结论。它给出的吞吐落差足够大，值得先排查；但根因仍待 profiler 和维护者确认，且测试环境是 GB10 单设备与 nightly 版本，不能外推到所有 vLLM 部署。
怎么排优先级
- 使用 SGLang P/D 分离和 Mooncake：先读 token replay 的状态机、KV page freeze/COW 与失败语义，暂不追求端到端 benchmark。
- 已经部署远程 KV offload：优先做慢
get注入实验，验证旧 block 隔离、额外 HBM 和本地重算是否会把尾延迟转成容量抖动。 - 正在测试动态 speculative decoding：先复现 vLLM #49548 的 batch 4/5 边界，再把 KV lookahead、drafter forward 和 CUDA graph shape 变化分开计数。
三条记录都还是开放讨论或报告，今天没有可以直接当作稳定发布结论的版本更新。
References
- 1SGLang issue #32143 API record
api.github.com
- 2vLLM issue #49545 API record
api.github.com
- 3vLLM issue #49548 API record
api.github.com
- 4vLLM issue #49548 report details
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.