Memory 技术日报 2026-08-01：旋转 KV、草稿状态与路由边界
本期五条窗口内工程更新分别处理量化 KV、MTP 权重加载、DCP/DSpark 状态交接、KV router 所有权和 TensorRT-LLM 的 cache/context 预发布能力，重点标出各自的复现动作与不能外推的结论。
先看五个边界
本期覆盖北京时间 7 月 31 日 09:00 至 8 月 1 日 09:00。窗口内值得跟进的变化，集中在五个不同的状态边界：模型是否真的需要加载 MTP 权重，量化后的 KV 是否能在特定模型的旋转路径中保持正确，draft/target 与 recurrent state 怎样跨 DCP 和 verify 阶段交接，KV router 的局部 output block 谁拥有，以及一组 KV cache、上下文和 disaggregated serving 功能如何进入同一个预发布版本。
共同判断只有这一条：memory 的收益不能只看「能不能复用」，还要先确认状态的形状、加载条件、所有权和恢复时机。下面五条材料的对象不同，证据也不同；它们适合分别复现，不能拼成一个端到端性能结论。
1. llama.cpp：Minimax M3 开始接住 rotated KV cache quant
llama.cpp 的 b10213 在北京时间 7 月 31 日 21:06 合入 a09d8ab。提交信息是「Support rotated kv cache quant」，对应的 PR 标题进一步限定为 Minimax M3 的量化 KV cache 支持。123这不是把所有模型的 KV cache 都改成同一种量化格式。代码增量落在
src/models/minimax-m3.cpp：原先 index branch 会直接断言 rotated attention cache 不支持；本次改动改为在 self_k_rot 和 self_v_rot 存在时，对当前的 Q/K/V 以及后续输出应用 Hadamard 变换，再进入或离开 cache 路径。它解决的是 Minimax M3 这条模型特定的旋转状态契约，而不是一项通用的显存压缩承诺。2适合谁先跟进： 在本地推理栈中运行 Minimax M3、并且已经在评估量化 KV cache 的团队。对其他模型，不能因为 release 标题里出现 KV quant 就默认获得同样路径。
先复现什么： 从 b10213 的二进制或源码开始，找到 Minimax M3 的 rotated KV cache quant 配置，固定同一段长前缀，做未旋转和旋转路径的输出一致性、显存、TTFT、decode 速度对照。报告至少写清模型版本、KV 精度、GPU、运行时、上下文长度和 baseline。当前 release、commit 和 PR 页面没有给出可直接引用的 MB 节省或 tokens/s 数字，也没有在页面中给出完整 CLI 示例。
不要先下的结论： 这条提交证明了一个模型特定的 cache 变换路径已经进入主线，不证明所有模型都能使用 rotated KV quant，也不证明端到端吞吐或显存一定改善。
2. llama.cpp：不跑 MTP，就不再默认把 MTP tensors 搬进来
b10212 在北京时间 7 月 31 日 20:57 合入
82dbc4f，改动的直接背景是已有 GGUF 在此前变更后会默认加载 NextN/MTP tensors，且没有 load-time opt-out。456修复方式很直接：新增
load_mtp 参数，只有 speculative 类型里真的包含 DRAFT_MTP 时才打开；支持 MTP 的模型 loader 则在未启用时给相关 tensor 加 TENSOR_SKIP。patch 明确覆盖 Cohere2MoE、GLM-DSA、HY-V3 等路径，量化时仍显式加载 MTP 权重。5这条变化与 KV cache 容量不是一回事。它首先影响模型加载阶段的权重驻留和初始化成本：普通 decode 不需要 MTP，就不必为没有启用的 draft 分支付加载代价；真正使用 MTP 时，所需 tensors 仍然要加载。
适合谁先跟进： 在同一套 GGUF 和运行时之间切换普通 decode、MTP speculative decoding 的本地部署团队，尤其是遇到启动显存或主机内存被无关 MTP 权重占用的场景。
先复现什么： 选一个包含 MTP tensors 的 GGUF，在 b10212 上分别运行普通 decode 和 MTP speculative 路径，记录模型加载 RSS、GPU 显存、模型加载时间和首 token 时间；再核对 MTP 路径确实读入 draft 所需 tensors。不要只看生成阶段的 KV 使用量。
局限在哪里： 公开页面没有给出节省多少 MB、使用什么模型和硬件，也没有提供统一 benchmark。因此当前能确认的是加载条件修复，不是固定的显存收益，更不是生成质量变化。
3. SGLang：DCP + DSpark 把 draft pool 和 recurrent state 对齐
SGLang 在北京时间 8 月 1 日 08:39 合入
1496bfee，提交标题是「Support DCP + DSpark」。它不是单一 kernel 调优，而是把 speculative decoding 的几类状态重新对齐。7patch 中有四个值得分开看的点：
- TokenSpeed MLA workspace 按 DCP 的完整 head 数 sizing，并把
max_speculative_num_draft_tokens纳入 query 长度上界； - draft worker 的 KV pool 在 DCP 下按
dcp_size扩容，因为 draft pool 是复制的，并不按同一方式分片； - 释放 overallocated KV 时从实际 allocator 读取 page size，避免用全局 schedule 参数代替物理分配器的页大小；
- DSpark 在 target verify 后，把最后一个被接受的 KDA/Mamba state 写回持久 cache，但当前实现明确只覆盖 chain layout，Eagle topk 必须是
None或1。
同一个提交还新增了 Kimi linear DCP/DSpark 的 registered test。也就是说，修复对象不是抽象的「spec decode 更快」，而是 draft KV、workspace、KV 回收和 recurrent state 各自怎样跨阶段交接。7
适合谁先跟进： 使用 DCP、DSpark 或带线性 attention state 的 SGLang serving 团队。尤其要关注 draft worker 和 target worker 是否共用一套容量假设。
先复现什么： 先跑新增的
test_kimi_linear_dcp_dspark4.py，再分别改变 dcp_size、最大 draft token 数和 verify 接受长度。检查三件事：draft pool 是否越界，overallocated KV 是否按真实 allocator 回收，verify 后重新读取的 recurrent state 是否与 accepted prefix 一致。不要先下的结论： 这条提交没有给出统一吞吐或显存 benchmark。DCP、draft/target、KV pool 和 Mamba state 的证据要分开记录，不能把状态边界修复改写成端到端加速。
4. Dynamo：output block 的负载观察不再发布局部快照
Dynamo 的 KV router 在北京时间 8 月 1 日 08:38 合入
7d12fbf。改动把 ActiveSequencesMultiWorker::add_output_block 中的完整 worker snapshot 发布改为本地 observation。8原因是 output block 产生频率高，而且每个 frontend 只知道 worker 的局部 output 活动。如果在这个边界直接发布完整 shared snapshot，局部状态可能覆盖另一 router 刚发布的更新。现在 output block 仍会更新本地
ActiveSequences、PromptRegistry 和 Prometheus observation，但不再自己排队 replica sync event，也不触发 shared ActiveLoad 发布。8仓库新增的单元测试把这个契约写得很具体：添加 output block 后，event 和 single-load publication 为空，observation 数量为 1，active block count 仍然更新为 4。这里的 4 是测试 fixture 的计数，不是生产吞吐数字。
适合谁先跟进： 维护 KV-aware routing、跨 replica 负载同步或 agent 长生成会话的工程团队。它影响的是 router 对「谁持有什么状态」的判断，而不是 KV tensor 本身的格式。
先复现什么： 先跑
kv-router 的 sequences 单测，再用两个 router/replica 高频注入 output block，检查 shared load 是否会被局部快照覆盖；同时确认 local active block、Prometheus observation 和后续完整生命周期 snapshot 仍然收敛。局限在哪里： 这是状态所有权和发布时序修复，不是 cache hit-rate 或 KV transfer latency benchmark。提交中的文档还明确保留了事件丢失、重复和乱序时的收敛边界，不能把「不再发布局部快照」理解成分布式状态已经无条件一致。
5. TensorRT-LLM v1.3.0rc23：一组 cache/context/disagg 功能进入预发布
TensorRT-LLM 的
v1.3.0rc23 在北京时间 8 月 1 日 02:55 发布，是本期唯一按 release 发布时间计入的预发布材料。官方 release body 同时列出多项与 memory/context 直接相关的变化：Python KV-cache transceiver 默认化、per-conversation KV cache block reuse、fine-grained context chunk management、KV cache compression 的 runtime integration、rank-aware host-tier sizing，以及 disaggregated transfer 使用 attention cache dtype。910release 还列出启动时输出初始 KV cache stats、MTP replay、dynamic-tree MTP decoding 和多项 disaggregated serving 修复。它们放在同一个版本里，并不意味着已经被同一条 benchmark 串起来；release body 是功能清单，不是跨模型的总收益报告。9
适合谁先跟进： 已经运行 TensorRT-LLM、需要在 KV reuse、压缩、host tier 和 P/D transfer 之间做组合验证的 serving 团队。对于生产环境，先把它当预发布候选，不要直接当稳定版升级建议。
先复现什么： 固定一个模型、GPU、TensorRT-LLM runtime、batch 和请求轨迹，先单独打开 per-conversation block reuse 或 KV compression，再测 cache hit、显存、TTFT、decode 和输出正确性；之后再加入 host tier 或 disaggregated transfer。每一步都保留 baseline 和开关组合，避免把多项功能的结果混在一起。
局限在哪里： release 没有给出同一模型、硬件和运行时下的综合性能数字，且已知问题包含 GB300 disagg hang、chunked prefill 失败和 A100 OOM 等场景。它适合列入复现清单，不适合直接推出普遍的成本或吞吐收益。9
放在同一张工程地图上
| 状态边界 | 本期变化 | 证据等级 | 先做的动作 | 暂时不能推断 |
|---|---|---|---|---|
| 模型特定的 KV 变换 | llama.cpp b10213 支持 Minimax M3 rotated KV cache quant | 已合并 commit；代码可读 | 做量化 KV 的正确性、显存、TTFT 对照 | 不能外推到所有模型或通用压缩收益 |
| MTP 权重加载 | llama.cpp b10212 仅在使用 DRAFT_MTP 时加载 MTP tensors | 已合并 commit；有回归背景 | 对普通 decode/MTP 分别测加载 RSS、显存和启动时间 | 不能当成 KV cache 容量提升 |
| draft 与 recurrent state | SGLang DCP + DSpark 对齐 pool、workspace、回收和 verify 后 state | 已合并 commit；含 registered test | 改变 DCP、draft 长度和 accepted length 做状态测试 | 不能当成统一吞吐 benchmark |
| replica-local output block | Dynamo KV router 不再从 output block 发布局部 shared snapshot | 已合并 commit；含单元测试 | 做多 replica 高频 output block 和生命周期收敛测试 | 不能推断 cache hit 或传输延迟改善 |
| release 级功能集合 | TensorRT-LLM rc23 集中加入 cache/context/disagg 选项 | 官方预发布 release | 逐项开关做固定口径的 A/B | 不能把 release notes 当跨模型性能报告 |
本期五条进展都在提醒同一件事：先把状态的角色和边界写清楚，再谈复用收益。
load_mtp 决定的是权重是否进入加载路径，rotated KV quant 决定的是特定模型的 cache 变换，DCP/DSpark 处理 draft 与 recurrent state 的交接，Dynamo 处理 replica 对局部 output block 的所有权，TensorRT-LLM 则把多个 cache/context 机制放进可组合的预发布版本。它们可以进入同一张技术路线图，但下一步复现仍应按边界逐项进行。References
- 1llama.cpp b10213 release
github.com
- 2llama.cpp commit a09d8ab
github.com
- 3
- 4llama.cpp b10212 release
github.com
- 5llama.cpp commit 82dbc4f
github.com
- 6PR #26296：MTP tensors 按需加载
github.com
- 7SGLang commit 1496bfee
github.com
- 8Dynamo commit 7d12fbf
github.com
- 9TensorRT-LLM v1.3.0rc23 release
github.com
- 10TensorRT-LLM v1.3.0rc23 release API
api.github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.