Memory 技术日报 2026-07-30：压缩账本、shared-KV 预算与上下文恢复

先看四个边界

7 月 29 日至 30 日的四条工程更新，都没有把重点放在「模型再塞进更多 token」。它们分别补了四个容易被混在一起的问题：压缩和缓存到底省了什么、shared-KV 如何计入统一内存、上下文重建怎样让状态可见且不粘连，以及变长状态 kernel 如何减少准备阶段的扫描开销。

这四条的证据等级也不同：Headroom 是已发布版本，另外三条是已落地的 GitHub commit。它们都有可复现入口，但都没有提供可以互相横比的端到端收益数字。

压缩层：Headroom 把 cache 账本和插件边界收进一个 release

Headroom 在 7 月 30 日凌晨发布 v0.33.0。这个版本的新增不只是再接一个压缩器，而是把压缩、缓存和代码记忆的接口重新收拢：

compressor registry 可以按 registry 选择内置或外部 compressor，proxy 还加入 model-aware cold-prefix hook，用于 reasoning compaction 和 cold recompaction；
cache 层保留 cache_control TTL，记录 provider 的 cache read、write、uncached tokens，并把 tool-schema savings 和每个扩展名的 token savings 纳入指标；
code-memory 默认路径切到 Serena，并在 wrap 阶段做项目语言范围和预索引处理。

这些变化对做 agent gateway、MCP proxy 或多 agent context 共享的人更有用：压缩器不再只是一个黑盒函数，缓存命中、未命中和工具 schema 的节省也有机会落到同一份成本账里。仓库 README 仍将它定位为 Apache 2.0 的 context compression layer，支持 Python/TypeScript library、proxy 和 MCP server；仓库页面显示约 6.3 万颗 star。1 2

先复现什么： 用 README 中的 headroom proxy --port 8787 或 compress(messages) 入口，分别记录原始 token、压缩后 token、provider cache read/write 和工具 schema savings，再比较 cold-prefix 与热缓存路径。

不要先下的结论： release body 列的是功能变更，不是同一硬件、同一模型、同一运行时下的 benchmark。README 中的压缩比例不能改写成 v0.33.0 的独立实测；外部 compressor 还要承担路由、失败回退和 tokenizer 口径差异。

KV 层：oMLX 先修正 shared-KV 的内存预算

oMLX 在 7 月 30 日 08:47（北京时间）的 commit 9b5a118 为 Gemma 4 shared-KV 增加 oQe calibration 支持。关键点不是宣称 prefix cache 命中率上升，而是让校准阶段的内存估算与真实 forward contract 对齐：

计算每个样本的 gemma4_state_bytes，把持续驻留的 shared-KV 状态计入 sample_bytes，避免 E2B/E4B 在统一内存上被过大的 micro-batch 推到耗尽边界；
对 shared-KV 的 tail layers 使用专门的 layer walk 和 state commit，避免把有状态的 decoder block 当成互相独立的层；
更新 layer_walk cache signature，使旧的 imatrix 结果失效，测试则检查手工 layer walk 与 native forward、shared-KV tail 的 sensitivity 计算，以及 stateful 情况下 micro-batch 变小。

这条更新适合 Apple Silicon 本地推理和量化校准链路。oMLX 的 README 描述了 continuous batching、RAM/SSD 分层 KV cache、prefix sharing 和重启后的缓存恢复；仓库采用 Apache 2.0，页面显示约 1.8 万颗 star。3 4

先复现什么： 在 Apple Silicon 上跑 tests/test_oq.py 中的 Gemma 4 shared-KV 测试，比较 dense 与 stateful 配置的 estimated_sample_bytes、micro-batch size 和 cache signature；再把校准结果接回实际 server，确认校准预算没有掩盖运行时的 SSD/RAM 传输成本。

边界在哪里： 这不是一个 prefix-cache 性能 benchmark，也没有给出统一硬件上的吞吐或延迟增益。它修复的是「校准时有没有把持久状态算进去」这个前置条件；换成离散 GPU 或非 Gemma 4 模型时，内存账和 layer walk 不能直接照搬。

恢复层：MiMo-Code 让 rebuild 边界可见，并阻断旧状态粘连

MiMo-Code 在 7 月 30 日 00:07（北京时间）的 commit fe747f0 继续收紧 context rebuild 的状态语义。它把 /rebuild 插入的 checkpoint 边界渲染成明确的 context rebuilt 提示，并说明较早消息已被摘要；同时，session.status 不再依赖 store 的合并行为，而是通过 reconcile 丢弃新状态未携带的旧字段。

这解决的是两类很具体的问题：重建发生过但用户看不见，以及上一轮 rebuild 的状态 message 残留到下一轮 spinner。提交还把状态消息压到 48 个字符以内、给 context counter 保留不可压缩的位置，并显式处理 checkpoint 的 null/undefined 边界。5

MiMo-Code 的 README 把这项修复放在更大的恢复链路里：MEMORY.md 保存项目知识和架构决策，checkpoint.md 保存会话快照，notes.md 和任务进度记录补充状态；上下文接近上限时，再从 checkpoint、project memory、task progress 和最近消息重建，并用 token budget 控制注入量。源代码是 MIT，但 README 同时列出使用限制、托管服务条款和商标政策；仓库页面/API 显示约 1.25 万颗 star。6

先复现什么： 安装 README 中的 @mimo-ai/cli，在 TUI 中触发 /rebuild，观察 checkpoint 边界、/status 的上下文计数器和下一轮 busy message；再注入长状态文本、空 checkpoint 和旧 message，检查 reconcile 是否保持状态隔离。

不要先下的结论： 这次修复提高的是恢复链路的可观察性和正确性，不是记忆容量，也没有任务成功率 benchmark。对线上 agent 来说，应该先把它当成恢复故障注入和 UI/状态审计的入口。

Kernel 层：FlashKDA 把变长 sequence 的准备查找改成二分

MoonshotAI 的 FlashKDA 在 7 月 29 日 10:07（北京时间）提交 1ce47ea，标题是 optimize kda prepare cu_seqlens scan with prefix-sum and binary search。它面向 Kimi Delta Attention 的 varlen prepare 阶段：先为 sequence tile 构建 prefix-sum，再用二分查找把 global_tile_idx 映射到 seq_idx，替代原来的 cu_seqlens 线性扫描。单次查找从 O(N) 变为 O(log N)，代价是 workspace 里新增 N+1 个 int32 的 tile-prefix buffer，并按 128-byte 对齐。7

它和 KV cache 不是同一个对象：FlashKDA 是基于 CUTLASS 的 Kimi Delta Attention kernel，state 通过 initial_state/final_state 传递，README 给出的当前约束是 CUDA、K = V = 128，并自动作为 flash-linear-attention 的 chunk_kda backend。仓库采用 MIT，页面/API 显示约 991 颗 star，测试入口是 bash tests/test.sh，其中包含与 Torch reference 和 flash-linear-attention 的正确性对照。8

先复现什么： 在支持的 CUDA 架构上运行仓库测试，再构造大量不同长度的 varlen batch，分别测 prefix-sum build、prepare kernel 和整个 chunk_kda 的时间与 workspace；不要只根据 O(log N) 的局部复杂度推断端到端吞吐。

成本和未验证点： 新的 prefix buffer 增加 workspace，短序列或 sequence 数较少时，额外 kernel launch 和内存可能抵消查找收益。该 commit 没有给出统一 batch、GPU 和 runtime 下的加速数字，所以它目前是一个适合 kernel review 和 profile 的工程信号，而不是 serving 性能结论。

四条更新放在同一张工程地图上

边界	本次变化	适合先做的动作	暂时不能推断
压缩 / cache 账	Headroom v0.33.0 收拢 compressor registry、cold-prefix 和 provider cache telemetry	在 proxy 里拆分压缩节省、命中与未命中成本	不能把 README 比例当成此次 release 的独立 benchmark
shared-KV 预算	oMLX 将 Gemma 4 持久 state 纳入 calibration memory estimate	对比 stateful/dense 的 sample bytes、micro-batch 和校准结果	不能外推到所有模型或离散 GPU
恢复正确性	MiMo-Code 显示 rebuild 边界并隔离 session.status 旧字段	做空消息、长状态、checkpoint 和重建恢复故障注入	不能推导 agent 任务质量提升
变长 state kernel	FlashKDA 用 tile prefix-sum + binary search 替代线性 scan	profile prepare、workspace 和端到端 `chunk_kda`	不能把局部 O(log N) 改写成吞吐倍数

四条线索共同指向一个更实际的判断：memory 系统的瓶颈不只在「能存多少」，还在于压缩后省下的 token 是否可计费、shared state 是否被正确计入预算、重建后的状态是否可见且不串台，以及变长请求在进入 kernel 前是否已经付出过多准备成本。下一步做路线评估时，应先按这四个边界分别测量，再讨论端到端收益。