Memory 技术日报 2026-08-02：actor 隔离、块化 KV 与 draft attention

本期覆盖北京时间 8 月 1 日 09:00 至 8 月 2 日 09:00。精确窗口内没有找到足以单独核验的 arXiv memory 新提交，因此本期不拿旧论文补数，只收录三条 GitHub 工程变更：OpenViking 把并发 Agent 的身份边界带进 recall/capture，LMCache 把 DSA 索引器的 blocked-scale 页面布局接入 KV 传输，SGLang 则让 Gemma 4 MTP 的 draft attention 增加一个 TRT-LLM MHA 后端。

它们分别位于「记忆属于谁」「KV 页面怎样寻址」「draft 状态走哪条注意力路径」三个层面。共同判断是：本期没有新的端到端收益数字，值得复现的是状态隔离、物理布局和后端适配本身，而不是把三个提交拼成一条吞吐结论。

OpenViking 的 c1d38eb 于北京时间 8 月 1 日 22:55:33 提交，标题是「support request-scoped actor peers」。它为 LangChain/LangGraph middleware 增加了从每次运行时上下文解析 actor peer 的入口，并把这个身份作用到 recall 和 capture 期间发出的 HTTP 请求。1

这里的 actor peer 不是新的用户身份，而是同一个凭证下并发运行的逻辑执行者。patch 把 capture 的去重与待处理上下文 key 从 session_id + peer_id 扩展为包含 actor_peer_id 的组合；因此两个 actor 在相同用户和 session 下工作时，捕获进度不会因为共用一把 key 而互相覆盖。recall 和 capture 都在 actor-peer scope 中执行，session 接口仍然按 user 作用域工作，不用 actor-peer header 给消息归属打标。1

适合谁先跟进： 把多个并发 Agent、子任务或工作流运行接到同一套长期记忆服务的团队。尤其是现在用一个凭证绑定的 HTTP client 复用多个 LangGraph run 的场景。

先复现什么： 从提交中新增的 test_actor_peer.py、test_runtime_actor_peer.py 和 test_langchain_runtime_actor_peer.py 开始，构造两个 actor peer 访问同一用户，再分别检查 recall 请求、capture progress 和消息归属。若两个 peer 有独立历史，还要给它们解析出不同的 session ID；否则 actor 隔离并不能自动替代 session 隔离。1

局限在哪里： resolver 只能改变请求级 actor peer，不能改变 account 或 user；多用户应用仍需先选择与凭证绑定的 client。官方说明要求从已认证、服务端控制的 runtime 字段解析 actor peer，不要信任模型状态或客户端可控参数。能力只覆盖 HTTP-backed middleware，不覆盖 embedded path= client；自定义 client 还必须声明并实现 request-scoped actor peer 支持。提交没有给出并发吞吐、召回质量或记忆污染率 benchmark，所以它证明的是隔离契约，不是 memory 服务性能提升。1

LMCache 的 0427938 于北京时间 8 月 1 日 10:08:09 提交，标题是「add NL_X_NB_BSV_BSS format for CB」。核心变化不是提出新的 KV 压缩算法，而是为 DSA indexer cache 增加一种能被 cache blend 和多进程传输识别的物理布局：[NB, BS, 132] 的 uint8 页面，页面内部按 block 排列 value 与 scale。2

代码新增 NL_X_NB_BSV_BSS engine format，并在 vLLM detector 看到单层、三维、uint8 且最后一维为 132 时选择该格式。传输 kernel 不再把它当普通 MLA 页面：它按 block_size 计算 block 基址，把每个 token 的 value 区和 block 尾部的 scale 区分开复制；同时 blend 的 re-RoPE 路径增加 rope_base_offset，处理 MLA latent row 中旋转维度位于尾部的情况。换句话说，本次增量解决的是「缓存对象已经存在，但 cache connector 不知道怎样正确寻址和搬运」的问题。2

适合谁先跟进： 在 vLLM DSA/MLA 路径上使用 LMCache 做 GPU cache transfer、blend 或多进程缓存复用的团队。只做普通 MHA、没有 DSA indexer blocked-scale 页面的人，不应把这个提交当作通用 KV 格式升级。

先复现什么： 先跑提交新增或修改的 test_blocked_scale_format.py、test_cb_mla_rope.py 和 KV format classification 测试。验证两类内容：一是 detector 是否只在 uint8、最后一维 132 的页面上选择新格式；二是 host/device 双向传输后 value 与 scale 的页内位置、MLA re-RoPE 的偏移和 blend 结果是否一致。2

局限在哪里： 该格式要求按 4-byte transfer unit 工作，页面寻址还依赖正确的 block_size；patch 对不满足约束的行宽和类型会直接报错。测试证明的是布局与 kernel 的正确性，没有给出模型、GPU、运行时、基线一致的 cache 命中率、显存节省或传输吞吐数字。因此不能把「支持 DSA 页面」写成「KV cache 变小」或「推理更快」。2

SGLang 的 131bd51 于北京时间 8 月 2 日 07:16:04 提交，标题是「Add trtllm_mha support for Gemma 4 MTP draft attention backend」。它把 trtllm_mha 接入 Frozen-KV MTP 的 draft attention 初始化路径，扩展的是 draft 侧的 attention backend 选择，不是 target 模型的通用 attention 替换。3

具体变化有三个边界。第一，MLA page constraints 现在会把 speculative_draft_attention_backend 也纳入 trtllm_mha 判断。第二，Frozen-KV MTP 在 topk > 1 时，允许 triton 或 trtllm_mha，后者通过 TRTLLMHAAttnBackend(..., skip_prefill=True) 初始化。第三，CUDA graph 的 draft attention state 容量按 max_bs * topk 初始化，而不是只按 batch size 预留。这对应的是多候选 draft token 的工作集边界。3

适合谁先跟进： 使用 Gemma 4 MTP、Frozen-KV speculative decoding，并且已经依赖 TensorRT-LLM MHA 或希望比较多个 draft attention backend 的 SGLang serving 团队。

先复现什么： 以 frozen_kv_mtp_worker_v2.py 的 backend 选择和 frozen_kv_mtp_cuda_graph_runner.py 的 state sizing 为入口，分别固定 topk=1 与 topk>1，检查 draft KV 绑定、CUDA graph capture 和 verify 前后的状态是否一致；再跑提交修改的 test_trtllm_mha.py，确认后端选择不会绕过既有 correctness case。3

局限在哪里： 这条提交只扩大后端兼容范围，没有发布 tokens/s、显存或接受长度 benchmark。测试本身要求 CUDA、FlashInfer 和特定 GPU 架构条件；代码也只对 Frozen-KV MTP 的 draft attention 放开 trtllm_mha，不能据此推出普通 decode、target attention 或其他 speculative 路径都得到同样收益。3

本期三条进展的共同点不是「memory 更大」或「推理更快」，而是把隐含状态写成了可检查的边界：actor peer 不能越过凭证绑定的 user，DSA 页面不能按普通 MLA 的地址规则搬运，draft attention 的工作集也不能只按 batch size 估算。对工程团队来说，最有价值的下一步是沿着这些边界做最小复现，再把性能数字放回完整的模型、硬件、运行时和 baseline 口径中。