Memory 技术日报 2026-08-11：从 draft KV 预算到 session 召回，五个边界更新

今天的五个 GitHub commit 没有可横向比较的吞吐、延迟或显存数字，却都在修正 memory 交接时容易被省略的前提：容量按谁的空间计算，字节按哪种布局持久化，首次召回何时写入会话，以及一个 cache manager 是否真的适合当前执行拓扑。SGLang 处理 draft KV 和 unified pool，vLLM 处理跨并行拓扑的 KV offload，OpenViking 处理首次 recall 的 session 落盘，TensorRT-LLM 则把 GPT-OSS 的 KV manager 默认值和双 engine speculative decoding 分开。

这些改动能支持的判断是「复用条件被写得更可测」，不是「线上性能已经提升」。本次读取时，SGLang 和 vLLM 仓库标注为 Apache-2.0，stars 分别为 31,640 和 88,707；OpenViking 标注为 AGPL-3.0、28,171 stars；TensorRT-LLM 的 GitHub API 返回许可证字段为 NOASSERTION、14,354 stars。stars 只用于定位项目，不能替代下面的 patch 和测试证据。1234

SGLang 在 2026 年 8 月 11 日 08:15（北京时间）提交 d59c1ddf，标题为「fix(dflash): account for DCP in draft KV pool sizing」。改动只触及 pool configurator 和对应单测，但它修正的是 speculative decoding 里一个容易被 target KV 账覆盖的对象：DFLASH draft pool 的每 token 额外空间。5

补丁把 DFLASH 的 draft cell size 从固定的 cell_size 改为 cell_size × attn_dcp_size。提交里的解释是，DCP 下 target pool 按 rank 分片，而 draft pool 覆盖 allocator 扩大的虚拟位置空间，所以 draft 项需要按 DCP rank 复制。新增单测把 draft 每 token 的局部值设为 10,240，在 DCP 为 1 和 8 时固定 target geometry，只检查 draft additive term 是否分别按 1 倍和 8 倍计入。5

这条提交适合 DFLASH、DCP 同时开启的 SGLang 维护者先跑。复现时看 test_pool_configurator.py 的 test_dcp_replication_scales_draft_budget，确认目标 pool 的几何量没有被 mock 改写，再核对 draft 项是否随 attn_dcp_size 线性变化。它证明了预算公式的局部正确性，没有报告总显存、接受长度、吞吐或端到端 speculative decoding 收益。

SGLang 在 2026 年 8 月 11 日 01:35（北京时间）提交 77380622，标题直接把范围写在一起：「Support DSPARK speculative decoding + fix two NaN root causes」。它不是单一 kernel 优化，而是把 unified memory 下的 DSPARK 路径收窄到一组已经有状态约束的组合。6

启动检查现在只接受 --enable-unified-memory 搭配 DSPARK 的线性 draft chain：speculative_eagle_topk 只能是 None 或 1，attention backend 也必须落在已经审计的集合内；其他 speculative 算法、tree verify，以及 unified hybrid-SWA pool 会被拒绝。draft pool 的大小改为覆盖 UnifiedMambaTokenToKVPoolAllocator.size_full，并向上取整到 page boundary，避免高位 virtual token id 写出 draft pool。6

两个 NaN 根因也被拆开处理。统一 MLA pool 在 allocator handout 时清零整页 envelope，防止复用页的未写尾部被 NaN-unsafe 的读取带入；SGLANG_DEBUG_POISON_POOL 可以在启动时用 bf16 NaN 填充整池，把这类错误变成可重复的 debug 失败。另一个修复把 CuTe kernel 中 slot × stride 提升为 int64，并放宽 Mamba scatter 对 envelope-strided view 的检查：layer/slot stride 可以不连续，但 entry 内部必须连续。6

复现顺序应按状态角色走：先跑 test_unified_handout_zeroing.py，检查 fresh page 和 recycled page 都在发放时归零；再跑 slot-stride 测试，比较人工放大的 stride 与 contiguous pool 的 bitwise 结果；最后检查 DSPARK verify 的 virtual-to-physical index translation。提交里的测试和配置门槛支持「这条路径的状态边界被收紧」这一判断，不支持 unified memory 的速度、容量或 NaN 故障率改善。

vLLM 在 2026 年 8 月 10 日 15:44（北京时间）提交 81840a17，标题为「Canonical CPU layout for parallelism-agnostic KV offload」。它新增可选的 canonical_layout，不再把 host 端持久化字节简单理解为某个 worker 私有 tensor 的整页拷贝。7

canonical 路径用 CanonicalPageMapping 描述 local offset 到 canonical offset 的 runs，启动时展开成 CopyPlan，再由各 rank 把自己的 KV shard 写入共享的 canonical page。MLA 的 replicated latent 可以被去重成一份 canonical copy，head-sharded KV 则按映射散入同一页。格式版本 v1 和当前 KV layout 一起组成 canonical_format_id，并进入 file mapper 的 storage namespace；因此 canonical bytes 不会和旧的 direct layout 共用同一批持久化文件。7

这里的「parallelism-agnostic」不是无条件放开。提交保留了 per-token-head quant、context parallel，以及无法由 live tensor stride 认证的 layer；hybrid grouping 也不会因为某一层可映射就整体被判为可跨拓扑复用。新增测试覆盖 CPU copy plan、writer rotation，以及 writer TP=2/4、reader TP=4/2、2/1 等跨 topology roundtrip，并要求读回字节与 ground truth 一致。7

对使用 CPU KV offload 的团队，最小复现入口是 tests/v1/kv_offload/cpu/test_canonical_layout.py。先验证一个 canonical page 能被不同 TP 的 writer 和 reader 组装、读回，再检查 canonical_format 是否改变存储命名空间。测试证明的是字节格式和跨 topology 的正确性，不是 offload 命中率、PCIe/NVLink 传输速度或线上尾延迟。

OpenViking 在 2026 年 8 月 10 日 13:55（北京时间）提交 3160d423，标题为「fix(retrieval): record first-turn session recalls」。核心代码把 context assembler 的 session 获取改为 auto_create=True，但真正的增量在测试中更清楚：首次召回、会话消息和 recall 去重账本必须落在同一条可检查的链路里。8

测试构造一个带 session_id 的 context search，请求 dedup_turns=3。第一次召回返回命中的 memory entry，状态为 dedup.status = new，并要求 session 下出现 messages.jsonl、.meta.json 和 .recall_log.json，召回条目写入 ledger。随后写入一条 user message，再提交同一个 search；第二次结果为空，统计中的 cooled 为 1。这个顺序说明「首次召回被记录」和「重复召回被抑制」是两个状态，而不是一个成功响应就能概括。8

失败路径同样重要：如果首次 materialization 写 messages.jsonl 失败，测试要求 session URI 可以存在，但 messages 和 recall ledger 都不存在；之后的 capture 请求仍可写入消息。对 agent memory 来说，这比「召回接口返回 200」更接近线上需要检查的事实：持久化、消息合法性和去重账本必须分别验证，不能把局部写入成功当成完整状态恢复。

先复现 test_context_mode_first_recall_materializes_session_and_records_ledger 和 materialization failure 测试，再把实际 session store、search 和 capture 的 IO 错误注入到同一条路径。提交没有给出召回质量、检索延迟或长期记忆保留率的 benchmark。

TensorRT-LLM 在 2026 年 8 月 10 日 16:45（北京时间）提交 67dd1b7e，把 GPT-OSS 默认接入 KV cache manager V2。文档和模型实现给出的原因是 GPT-OSS 的 VSWA 在不同 layer 使用两种 attention window，V2 可以按 layer lifecycle 分组，让 sliding-window pool 和 full-attention pool 独立计算，而不是静态切一份总预算。9

这不是强制改写用户配置：显式 use_kv_cache_manager_v2 仍然优先。新增的兼容性分支只处理模型默认值在双 engine speculative decoding 下会造成的问题。Eagle3 两模型模式有独立 draft engine 和独立 KV manager；V2 按实现会让 target 和 draft 都从完整 max_gpu_total_bytes 预算配池，所以 auto 把 GPT-OSS 的模型默认降回 V1，显式设置为 True 则直接报错。单模型 Eagle3 仍保留 V2。9

复现入口是 GPT-OSS 的 model defaults 单测：分别跑 auto、显式 false/true、双模型 Eagle3 和单模型 Eagle3。读者要核对的是「谁拥有 KV budget」和「有几个 manager」，不是只看最终选择了 V1 还是 V2。该提交没有提供 GPT-OSS 的吞吐、TTFT、显存占用或质量变化。

五条提交的对象不同，但它们在同一条交接轴上相互补足：DFLASH 把 draft pool 的复制因子写进容量公式；unified memory 把 virtual id、physical page 和未写内存的初始化状态分开；vLLM 把跨拓扑复用的字节格式和 namespace 写明；OpenViking 把首次 recall、session materialization 和 dedup ledger 排成可恢复的顺序；TensorRT-LLM 则把 manager default 和双 engine 的预算所有权拆开。

因此可以得到一个比「五个项目都在优化 memory」更窄、也更有用的判断：当 memory 跨 rank、跨 draft/target、跨 layer lifecycle 或跨 session 交接时，局部命中或局部写入都不足以证明状态可复用。至少还要同时回答容量、格式、持久化顺序和兼容路径中的对应问题。五个 commit 只各自覆盖其中一部分，也没有共同 workload；把它们拼成性能结论会越过证据边界。

对技术负责人而言，今天最短的决策路径不是选一个「收益最大」的项目，而是按自己的交接对象选入口：DCP 下的 draft KV 查预算公式；unified memory 查 page 和 index 的状态；跨 TP 的 offload 查 canonical bytes；agent recall 查 materialization 与 ledger；GPT-OSS speculative decoding 查 target/draft 两个 manager 的预算边界。每条都值得复现，但没有一条可以替代统一 workload 的性能实验。