Memory 技术日报 2026-06-29：写入验证、InfoKV 与长上下文 serving

过去 24 小时里，memory 方向的一手论文首发不多；这期的时间依据主要来自窗口内的社区周榜、GitHub 工程扫描和 X 上的长上下文 serving 实测讨论。表格里的「原始论文时间」单独列出，避免把窗口内讨论误写成论文当天首发。

速览

信号	窗口依据	原始材料时间	为什么值得看	今天可做的动作
AgentDB 写入验证与时间覆盖规则	GitHub issue 于 6 月 28 日 14:07 发布，集中讨论 TRUSTMEM、MemStrata、MemClaw、Metis 对 agent memory 写入链路的启发1	相关论文多在 6 月 23-25 日提交2 3	长期记忆不只是检索，写入、覆盖、溯源会变成系统状态问题	检查自己的 memory write path：是否有覆盖率、保真度、旧事实覆盖规则
InfoKV：用信息量信号补 KV 压缩	X 上的 HF Daily Papers 简报在 6 月 29 日 07:35 把「Information-Aware KV Cache Compression for Long Reasoning」列为当天推送项之一4	arXiv v1 于 6 月 25 日 19:03 提交5	它把预测不确定性、表示层演化和 attention score 合在一起，补上纯 attention 选 token 的短视问题	长推理场景压 KV 时，不要只看局部 attention；把远期影响纳入 ablation
GLM-5.2 NVFP4 serving：SGLang 与 vLLM 分工更清楚	TheValueist 于 6 月 28 日 09:58 发布长帖，给出 2x B300 上的 GLM-5.2 NVFP4 对比结果6	这是社区实测帖，不等同官方 benchmark	32K-256K 内 SGLang 更快，但 512K/768K 边界下 vLLM 依靠 CPU KV offload 完成了请求	serving 路由按上下文长度、prefix 复用率和内存压力分流，不要只选一个默认引擎
JetSpec：把 speculative decoding 往长 reasoning 推	HF Daily Papers 简报在 6 月 29 日 07:35 同时列出 JetSpec，指向近期 speculative decoding 进展4	arXiv v3 于 6 月 25 日 14:18 更新7	它用 causal parallel draft head 缓解「草稿越长、接受率越差」的问题，论文报告 H100 上 MATH-500 最高 9.64x 加速	如果 agent loop 主要卡在长输出 decode，可关注 vLLM 集成，不要把它当成 prefill/KV 压缩替代品

逐条解读

1. 记忆写入需要「提交前验证」，不是只靠检索质量

Ruflo 的 6 月 28 日 memory 扫描把问题放在写入链路上：LLM 生成的 memory update 如果直接进库，错误会从一次回答变成可被后续轮次反复召回的系统状态。它把 TRUSTMEM 和 MemStrata 放在一起看，前者处理「写入是否忠实」，后者处理「旧事实何时该被新事实覆盖」1。

TRUSTMEM 的核心是 Memory Transition Verifier，用 coverage、preservation、faithfulness 三类指标检查记忆更新。论文摘要报告，相比各错误类型最强 baseline，它把 transition-level omission、corruption、hallucination 分别降低 40.1%、79.1%、50.0%，并在 HaluMem memory extraction 上提升 12.14 F1 points2。

MemStrata 则把 stale fact 问题从「相似度阈值」改成「事实槽位覆盖」。论文指出，RAG 在 evolving knowledge 任务上会把过期事实和当前事实一起召回，RAG 准确率只有 0.20-0.47；MemStrata 通过 subject-relation-object 的 supersession rule，把 evolving knowledge 准确率推到 0.95-1.00，并把 stale-fact-error rate 压到约 0%3。

工程上可以先做三件小事：第一，memory 写入前保留原始观察、候选更新和 verifier 判定；第二，给可变事实显式建 entity/predicate key；第三，把 delete、revise、supersede 当成一等操作，而不是让后续 retrieval 自行「看起来更相关」。

2. InfoKV 提醒：长 reasoning 的 KV 压缩不能只盯 attention

InfoKV 的切口很具体：多数 KV cache 压缩方法用 attention weight 判断 token 重要性，但长 reasoning 里，某些 token 对远期上下文的影响不一定在局部 attention 里立刻显出来。论文引入 Forward Influence，观察到 attention score 更容易选中影响近邻上下文的 token，而高预测不确定性的 token 对更远上下文有更强影响5。

它的做法是把 token-level predictive uncertainty、layer-wise representation evolution 和 attention score 合起来。作者在 Llama-3.1、Llama-3.2、DeepSeek-R1 上做 long-context reasoning 实验，摘要称 InfoKV 在 long prefilling 和 decoding 场景下都优于 attention-based KV compression 方法5。

这条对线上系统的启发是：压 KV 时要按 workload 拆开看。问答或短上下文续写可以用 attention 做强 baseline；但如果是长链推理、代码修复、多轮 agent plan，压掉一个「当下不显眼、后面会影响分支」的 token，损失会延迟出现。下一步复现实验应优先看长输出任务的错误类型，而不是只看平均压缩率。

3. KV offload 正在从兜底机制变成路由变量

TheValueist 的 GLM-5.2 NVFP4 长帖不是官方 benchmark，但它有一个值得单独跟进的系统结论：同一个模型、同一组硬件，普通上下文和边界长上下文的最佳引擎可能不是同一个。长帖称，在 32K-256K 已完成工作负载里，SGLang 在 44 个双方都完成的 row 中赢了 42 个；但在 512K/768K 边界上，vLLM 通过 CPU KV offload 完成了 SGLang 未完成的请求6。

这类数据不要直接搬成「SGLang 全面优于 vLLM」或反过来。更合理的读法是：prefix reuse、RadixAttention、CPU scheduling 会影响中等上下文的 TTFT 和吞吐；到 512K 以上，能不能把 KV 从 HBM 扩到 CPU memory，可能比单次 token/s 更重要6。

如果你在做 RAG、代码库问答或长文档 agent，今天可以把路由条件写得更细：输入长度、预期输出长度、共享前缀概率、当前 HBM 压力、是否允许 CPU offload、是否需要 512K+ 完整完成。把这些条件接到 gateway，比在配置里永远固定一个 engine 更稳。

4. JetSpec 解决的是 decode 税，不是长上下文 prefill

JetSpec 处在另一个环节：它不是压 KV，也不是替你召回更好的 memory，而是降低 autoregressive decode 的串行成本。论文说，传统 speculative decoding 想加大 draft budget 时会撞上接受率和草稿开销的天花板；JetSpec 用 causal parallel draft head，让 candidate tree 的分数更贴近目标模型的 autoregressive factorization，从而把更大的 draft budget 转成更长 accepted prefix7。

论文摘要给出的结果很激进：在 H100 上，JetSpec 在 MATH-500 最高达到 9.64x 加速，在开放式对话任务上达到 4.58x，并展示了 vLLM 集成下的延迟收益7。这里要留一个工程边界：speculative decoding 主要省 decode；如果你的瓶颈是超长输入 prefill、RAG 文档拼接或 KV 内存爆掉，它不是 InfoKV 或 KV offload 的替代方案。

Agent 系统里这条仍然有价值。多步 agent 往往会产生计划、解释、代码 diff、测试日志摘要，decode loop 被重复缴税。JetSpec 这类方法如果能稳定接进 serving stack，会直接影响每轮 agent iteration 的成本和等待时间。

工程判断

今天的共同信号很清楚：memory 方向正在分成三层优化。

写入层：TrustMem、MemStrata、MemClaw 这条线把 memory 当系统状态，需要验证、覆盖、溯源和隔离。
缓存层：InfoKV、KV offload、RadixAttention 这条线处理长上下文的 HBM 压力和 prefill 复用。
解码层：JetSpec 这条线减少长 reasoning 与 agent loop 的输出成本。

如果只能跟一件事，优先检查自己的长期记忆写入链路。检索错一次只是回答错；写入错一次，后面每次检索都可能把错状态当事实带回来。KV 压缩和 speculative decoding 可以等到有真实长上下文流量再做基准，memory verifier 和 supersession rule 则应该尽早进入设计。