Memory 技术日报 2026-08-01：旋转 KV、草稿状态与路由边界

先看五个边界

本期覆盖北京时间 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 支持。1 2 3

这不是把所有模型的 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。4 5 6

修复方式很直接：新增 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 的几类状态重新对齐。7

patch 中有四个值得分开看的点：

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。9 10

release 还列出启动时输出初始 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 机制放进可组合的预发布版本。它们可以进入同一张技术路线图，但下一步复现仍应按边界逐项进行。