Memory 技术日报 2026-08-14：五个更新把状态交接写成显式边界

五条工程更新共同碰到一件容易被低估的事：memory 状态跨过边界之后，接收方凭什么知道它仍然可以被原路径解释。SGLang 把 linear-attn verify backend 变成显式选择；vLLM 把 MTP 预填阶段尚未定稿的 KV 尾部排除在 prefix cache 之外；LMCache 给 fleet 事件流加上实例时代、序号和缺口；OpenViking 则分别收紧 session memory 的提取依赖，并把 commit 的追踪号传到插件日志。它们没有共同 workload，能确认的是交接协议变得更明确，而不是系统已经普遍变快。

SGLang 的 commit 704e512 于 2026 年 8 月 14 日 08:59:52（北京时间）合入，标题是「Honor configured linear-attn verify backend in the kernel dispatcher」。补丁给 GDNKernelDispatcher 增加可选的 verify_backend，并把 get_linear_attn_verify_backend() 接入初始化路径。显式配置的 Triton backend 会优先生效；只有没有显式选择时，代码才沿用「selected backend 支持 MTP verify 就使用 FlashInfer」的历史规则。1

这条边界针对的是状态类型，不是一个抽象的后端偏好。提交注释写明，SM90 上的 FlashInfer verify 要求 FP32 SSM state；如果启动配置使用 --mamba-ssm-dtype bfloat16，调用方就需要有办法强制走 Triton。过去的自动规则可能根据 decode 或 prefill backend 选择 FlashInfer，却没有把 verify 阶段的 state dtype 一并纳入判断。现在，verify kernel 的选择至少能与实际状态格式对齐。

复现时先固定 bfloat16 SSM state，再分别使用显式 Triton 和未指定 verify backend 的配置，检查 verify_kernel 的落点；不要只看服务是否启动成功。这个 commit 没有给出 kernel latency、MTP 接受长度或端到端吞吐，因此它证明的是 dispatch 条件被写进代码，不是 Triton 或 FlashInfer 谁更快。SGLang 仓库当前 API 返回 Apache-2.0 许可证和 31,759 stars；stars 只是仓库规模线索。2

vLLM 的 commit f80b66f 于 2026 年 8 月 14 日 07:22:29（北京时间）合入，标题是「Add KV cache support for multi-layer MTP」。它把 Inkling MTP 配置测试里的 n_predict 从 1 改为 8，并将 num_prefill_lookahead 贯穿 scheduler、KV cache coordinator 和 manager。测试现在明确断言多个 checkpoint depth 都会暴露出来，而不是只暴露第一层。3

难点在 chunked prefill 的最后一段。MTP drafter 会读取当前已计算 token 之后的 lookahead；这些位置可能还会被重新 prefill，不能因为「已经算过」就直接当作稳定 KV 写进 prefix cache。vLLM 现在用 num_prefill_lookahead - 1 得到可重新 prefill 的尾部，只把前面的 finalized token 交给各个 KV manager。多层 MTP 下，尾部长度随 num_speculative_tokens 增长；如果启用 prefix caching 而 scheduler_block_size 小于这个 lookahead，初始化会直接抛出 ValueError，避免缓存命中落到含有错误 next-token 的 slot 上。滑窗 KV 的 spec 也会额外保留 num_speculative_tokens - 1 个 token。

最小复现入口是 tests/config/test_speculative_draft_hf_overrides.py 中的 Inkling 配置测试，以及 tests/v1/core/test_scheduler.py 的 lookahead 调度测试。接着检查 prefix caching 下的 block-size 约束，确认被排除的尾部没有进入 cache key 对应的 block。提交没有提供接受长度、decode latency、显存占用或共同模型基线；n_predict=8 是配置和测试事实，不能改写成八倍吞吐。vLLM 仓库当前 API 返回 Apache-2.0 许可证和 88,995 stars。4

LMCache 的 commit 8d72417 于 2026 年 8 月 14 日 08:08:31（北京时间）合入，标题是「cache-event ingest layer and fleet controllers」。重构把原来的 cache-control 拆成 ingest/ 与 controllers/：所有 fleet cache facts 先经过 EventGate，再由 broadcaster 分发给 key directory 和 eviction controller。5

EventGate 为每个 emitter 维护 stream cursor，分别处理三类容易混淆的状态：incarnation 用来隔离重启前后的实例事实，seq 用来去重，gap detection 用来标记事件流缺口。实时 emitter 走 ingest()；没有 stream position 的扫描则走 reconcile()。这让「收到一个事件」和「这个事件可以改变当前目录」变成两个步骤：事件先取得准入资格，消费者再应用它。

删除控制也被放到独立的 FleetEvictionController。它持有 quota、usage、LRU 和 pins，按策略周期检查水位，再向共享 L2 发出分块删除请求；prefetch_manager 仍然只是请求级代理，没有自己的后台控制循环。文档同时承认一个很实际的恢复边界：协调器重启后，directory、usage view 和 LRU 只会从 cache-event stream 重新构建，事件回来前 quota 会低估，不能把空状态当成真实的零占用。5

复现应优先构造 emitter 重启、重复 seq、缺口和 fence_instance 四条路径，再看消费者收到的失效范围；不要先跑一个完整 fleet benchmark。提交没有给出事件吞吐、重建时长、缓存命中率或 eviction 尾延迟。LMCache 仓库当前 API 返回 Apache-2.0 许可证、11,136 stars，默认分支为 dev；这些是仓库线索，不是本次重构的性能指标。6

OpenViking 的 commit ed1bd4b 于 2026 年 8 月 13 日 21:48:49（北京时间）合入，标题是「统一 V3 提取并提升会话提交与评测稳定性」。它退役 SessionCompressorV2，把 session commit 的主流程改成 SessionCompressorV3 → ExtractLoop → MemoryUpdater → SemanticQueue，并在文档中明确：V3 先抽取启用的 user-memory schema，其中包括 cases；只有至少产出一个 case，才继续生成 trajectories、experiences 和可选的 executable session skill。7

这条依赖关系改变了「配置里出现一个 memory type」的含义。memory_policy.memory_types 中没有 experiences 时，即使显式写入 cases 或 trajectories，这些条目也会被忽略；没有 case 的 session 也不会凭空产生执行派生物。提交还禁用了不受支持的 tools 与 skills extraction，并把 memory link 的更新统一交给共享 MemoryUpdater，同时补上 overview 文件的 update lease 和 replacement link 的锁覆盖。最终配置文档把 SessionCommit 的默认并发数改为 8。

最小复现不是跑一次 session 后看 HTTP 200，而是准备三份 policy：有 case 且启用 experiences、没有 case、以及缺少 experiences 但显式列出 cases/trajectories。分别检查最终写入的 memory 类型和 link 更新结果。commit 没有给出 recall precision、提取延迟、评测分数或长期 retention；并发默认值是配置变化，不是吞吐提升。OpenViking 仓库当前 API 返回 AGPL-3.0 许可证和 28,389 stars。8

另一个 OpenViking commit 33043cb 于 2026 年 8 月 13 日 23:29:41（北京时间）合入，标题是「expose session commit trace IDs」。它没有改变 memory 的提取算法，而是修补了异步提交最难排查的那一段：插件 HTTP wrapper 从 result.trace_id、error.trace_id 或顶层 body.trace_id 提取标识，成功和失败返回都保留 traceId。auto-capture、pre-compact、session-end 和 pending replay 的日志及用户确认也会带上这个标识。9

测试没有只模拟成功响应。新增的 node:test 用 trace-success 检查成功 commit，用 trace-error 检查 HTTP 500 的失败响应，同时验证 pending queue replay 的日志仍然保留 trace_id。这让「服务端接受了哪一次提交」和「插件向用户报告了什么」可以通过同一标识对上，而不是只剩一个布尔值 committed: true/false。

复现时先跑 examples/claude-code-memory-plugin/scripts/lib/pending-queue.test.mjs，再故意让 commit 返回成功和失败两种 body，核对 wrapper、replay log 和用户确认里的 trace 是否一致。它改善的是可观察性，不能证明 commit 已经持久化、memory 已经能被召回，也不能保证所有第三方 HTTP wrapper 都会返回 trace ID。仓库的许可证和 stars 线索与上一条相同，仍以 OpenViking 当前元数据为准。8

五个 commit 的位置可以排成一条更具体的链：SGLang 标记「verify 阶段用哪种 kernel 解释 SSM state」；vLLM 标记「哪些预填 token 已经有最终 KV」；LMCache 标记「哪个 emitter 的哪一代事件可以改写目录」；OpenViking V3 标记「哪些 memory type 有资格由 case 触发」；OpenViking trace commit 标记「一次 session commit 如何在成功、失败和 replay 之间保持可追踪」。

共同机制因此很窄：状态交接的元数据也是 memory 合同的一部分。没有 backend 角色，state dtype 可能把 verify 路径选错；没有 finality，未定稿的 KV 可能进入 prefix cache；没有 incarnation 和 seq，重启后的旧事实可能污染 fleet 目录；没有类型依赖，执行记忆可能在没有 case 时被误认为已经生成；没有 trace ID，失败后的恢复动作就难以与服务端那次提交对应。这个判断来自五条提交的代码和测试边界，不能外推为全领域趋势或共同性能收益。

如果正在做跨层 KV、speculative decoding 或 agent memory，今天最短的工程动作不是先找一个更大的 benchmark，而是把交接协议拆开验：先确认状态角色，再确认是否定稿，再确认 epoch/序号和失败 trace，最后才测吞吐、召回和成本。这样测出来的性能数字，才知道自己建立在一个没有被错误状态污染的路径上。