Memory 技术日报 2026-07-29：稀疏 KV、跨 rank 状态与可恢复上下文

在北京时间 7 月 28 日 09:00 至 7 月 29 日 09:00 的公开更新里，能回到一手页面的新增主要集中在 GitHub 工程侧；时间窗外的 arXiv 论文不计入下文。

四条更新可以分成两组。vLLM 和 SGLang 都在处理 KV 的运行时状态，但前者先定义跨 rank GPU 对象怎样被拥有、发布和回收，后者先定义已有 dense 模型怎样选择可见 KV。ai-memory 和 MiMo-Code 则落在 agent memory 的另一端：一个把会话观察沉淀为可检索 handoff，另一个修补消息写入和恢复时的内容完整性。

SGLang 在 7 月 28 日 21:09（北京时间）提出 [RFC] A Unified KV-Cache Sparsity Framework for Post-Hoc Sparse Attention。它想把 mem_cache/sparsity 扩成一个统一接口，让已有 dense MHA/GQA checkpoint 在不改模型、不重新训练的情况下接入多种 KV 选择策略。初始设计覆盖 token 或 page/block 粒度，以及 position、KV-derived、current-query-aware 三类证据，并把决策范围拆到 request、step、layer 三层。1

第一版的边界写得很清楚：只改变 attention 能看到的 KV 子集，完整 KV 仍留在 HBM，不做物理 eviction、compaction、CPU/NVMe offload，也不接入需要训练的 selector。于是它可以减少 attention 计算和内存流量，却不能直接换算成更高的 KV 容量或更高的并发。RFC 还承认当前 coordinator 尚未接入 live inference path，没有完整 memory accounting contract，也没有端到端测试或 benchmark。1

对工程团队来说，这个 RFC 的价值更像一份接口和测试清单，而不是性能结论。先看它是否能把 selector、backend adaptor、dense fallback 和 unsupported configuration 变成可独立测试的边界，再谈某个稀疏方法能否获得收益。

vLLM 在 7 月 28 日 18:16（北京时间）开放的 Shared Context Parallelism RFC，处理的是 PCP/DCP 路径里跨 rank 复用 GPU 对象的语义。设计重点包括 owner-local allocation、稳定的 rank-major peer mapping、local/peer view、发布与复用协议，以及可确定性 teardown。RFC 特别提醒，shared 不等于硬件缓存一致性、零传输或自动分布式张量放置；第一阶段也只覆盖单机 NVIDIA GPU 和已有的 PCP/DCP process group。2

文中引用了若干对象级或方向性的证据，例如 owner-sharded history 在 PCP4 上最高可提供 4 倍 persistent KV capacity。但同一份 RFC 也写明，完整 Shared-DCP 栈还没有可重复、同源、明确对比的端到端加速结果。因此，这个数字不能当成整个 serving engine 的 4 倍容量承诺。眼下最值得复现的是 peer mapping、发布/复用和关闭顺序，而不是把对象级结果直接外推到线上吞吐。2

两份 RFC 放在一起看，分界线很实用：SGLang 选择逻辑上哪些 KV 参与 attention，vLLM 约束跨 rank 之间的 GPU 状态怎样被访问和回收。一个省计算路径，一个管状态所有权，不能把其中一方的数字套到另一方身上。当前也没有证据表明两者已经集成。

ai-memory 在 7 月 29 日 04:18（北京时间）发布 v1.19.2，release 页面给出了 Linux、macOS、Windows 的校验和，以及 Docker、AUR 和 Cargo 安装入口。release body 没有功能 changelog，所以不能把这个版本写成记忆算法更新。3

项目 README 描述的系统机制是：在会话结束时把 lifecycle observations 编译成 handoff，写入 Git 管理的 Markdown wiki；运行时再通过 SQLite、FTS5、可选向量检索和 graph-neighbor RRF 找回相关内容。它还把 raw/ 会话片段、db/ 索引和 wiki/ 页面分开，CLI 通过 MCP/HTTP server 访问这些状态。4

这次 release 适合做安装和恢复链路实验：验证 handoff 是否保留架构决策、失败方案和未决问题，检查索引重建、git 同步和多客户端交接的代价。release 页面能证明版本和安装入口，不能证明 README 中的机制都是 v1.19.2 新增。

MiMo-Code 在 7 月 28 日 21:34 至 22:34（北京时间）之间连续修补 inbox 和 provider 消息处理：包括不再把无正文通知写成空 user text part、禁止 normalizeContentArray 给 tool message 强行补文本，以及保证 trailing continuation turn 使用合法的 text part。56

这类修复不增加记忆容量，却直接影响压缩后能不能恢复出 provider 接受的消息序列。仓库 README 的 context reconstruction 会在接近窗口上限时，依据最新 checkpoint、project memory、task progress 和保留的最近消息重建上下文，并用 token budget 控制注入量。7

把 ai-memory 和 MiMo-Code 放在一起，工程上的落点是：记忆写入负责留下可回取的状态，消息协议负责让这些状态能重新进入模型。前者适合测跨会话召回和索引维护，后者适合做空消息、tool message、压缩恢复和 provider 转换的故障注入。两边都没有提供可与线上任务成功率直接对应的独立 benchmark，不能用仓库功能列表替代评测。

本期最清楚的共同点，是 memory 的成本和正确性被拆到了不同状态边界：KV selector 决定哪些 token 进入 attention，跨 rank 对象协议决定谁能访问这些状态，持久记忆决定哪些信息跨会话留下，消息修复决定留下的内容能否再次被模型消费。下一步若要做组合实验，应先分别测这四个边界，再讨论端到端收益。