Memory 技术日报 2026-08-10：五个修补把 KV、state 与 offload 边界写进代码

今天能确认的五个窗口内 GitHub 提交，都在处理一个很具体的问题：KV、recurrent state 或 offload block 交给下一个执行阶段时，容量、能力和失败状态是否仍然可解释。它们提供了 patch 与测试入口，但没有共同的模型、硬件、运行时和 baseline，因此不能拼成吞吐、延迟或显存收益排名。

仓库入口本身也要和技术证据分开看：SGLang 与 vLLM 都是 Apache-2.0；本次读取时，前者为 31,588 stars，后者为 88,610 stars。star 数只帮助定位项目，不证明下面任何一条修补有效。12

SGLang 在 2026 年 8 月 10 日 06:54:41（北京时间）提交 4a5d7d3c，标题是「[DSV4] Fix silent KV corruption when speculative draft tokens > 4」。补丁针对 DeepSeek V4 的 compress-state ring：旧的 mtp_pad 把 draft token 的保留数量固定封顶为 4，verify batch 的 draft 数更大时，写入计划可能少写 committed tail，下一次 compression 读取到旧的 ring slot。34

修补把 mtp_pad 改成由 ring_size 和 window_size 推导：ring_size - window_size + 2，并把同一规则暴露为 get_compress_state_write_pad()。配置阶段新增 _assert_ring_serves_draft_tokens()，当 max_speculative_num_draft_tokens 超过对应 ring 的可承载范围时直接拒绝启动。提交新增的单测给出局部边界：speculative c4 ring size 为 16，可服务的最大 draft 数为 10；c128 ring size 为 256，最大 draft 数为 130。它们是 ring 容量与正确性测试数字，不是性能数字。3

适合先跟进这条提交的人，是在 SGLang 中启用 DSV4 压缩 attention 与 speculative decoding、且 draft 数可能超过 4 的维护者。最小入口是 test_deepseek_v4_compress_plan_draft_pad.py 与 test_dsv4_compress_write_pad.py：先比较 CPU host loop 与 GPU plan_compress_prefill_kernel0 产出的写入集合，再分别覆盖 c4、c128 和非 speculative ring。超过 ring capacity 时，测试仍会验证 planner 会 under-write；真正的防线是配置阶段的上限检查。提交没有给出端到端速度、显存或质量变化。

SGLang 在 2026 年 8 月 9 日 21:42:54（北京时间）提交 fc40684b，标题是「[srt] Fix sconv state memory corruption on specdec」。改动涉及 Inkling sconv backend、prefill CUDA graph runner 和 runner buffer。问题出在 speculative decoding 与 graph capture 的交界：warmup batch 没有 tracking metadata 时，如果 Python 层条件分支让 track scatter 根本不发射，捕获图和真正有 metadata 的 replay 就不是同一条执行路径；旧 batch 的 tracking 数组还可能残留到下一个 batch。56

补丁为 graph capture 增加 inert 的 mask、indices 和 seqlens buffer。graph path 即使没有 metadata，也会用这些全零 buffer 发射 scatter；非 graph path 则把 track_conv_indices 置为 None。populate_from_forward_batch() 还会清空当前 batch 缺失字段以及 bs 之后的尾部区域，避免较大 batch 的旧状态污染较小 batch。与此同时，_is_mamba_track_enabled() 不再用「必须是非 speculative」作为前提，因此 sconv track 的状态路径可以进入 specdec。5

复现时不要只检查一次 forward 是否返回。应分别构造有、无 tracking metadata 的 graph warmup，检查两条路径是否都执行 scatter；再把 batch size 缩小，确认 indices、mask、seqlens 的尾部被清零，并分别跑 speculative 与非 speculative 路径。这组 commit + 测试证据能支持「状态不会沿用旧 batch」这一局部判断，不能支持 CUDA graph 的延迟收益或 sconv 的吞吐提升。

vLLM 在 2026 年 8 月 10 日 06:38:13（北京时间）提交 d6941300，标题是「[BugFix] Scope divergent hybrid cache hits to capable connectors」。它处理的是混合 attention cache：当 full-attention 组和 Mamba 组的本地命中边界不一致时，外部 KV connector 只有在能够恢复缺失 recurrent state 的情况下，才可以使用 divergent lookup。旧路径只要存在 connector 就尝试这条查找，能力边界没有写进接口。78

新接口 supports_divergent_local_hybrid_hits 默认返回 False。普通 connector 走 get_computed_blocks()，只有能力为真的 connector 才走 get_computed_blocks_for_connector()；不支持能力的路径把 hit_diverged 固定为 False。NixlBaseConnector 明确返回 True，MultiConnector 则采用保守的 all-of 规则：所有子 connector 都支持时，整体才支持。7

这条更适合维护 KV connector 和 hybrid Mamba/attention 调度的人复现。先用不支持 capability 的 mock connector 验证不会调用 connector-specific lookup，再用支持 capability 的 mock 或 Nixl 路径验证才会进入 divergent lookup；最后混入一个不支持的子 connector，确认 MultiConnector 不会把局部能力误报成整体能力。新增测试证明的是 lookup policy 与 state boundary，不是 prefix-cache 命中率，也不是外部 KV 的端到端收益。

vLLM 在 2026 年 8 月 9 日 15:25:57（北京时间）提交 eb24bc3，标题是「[Bugfix][KV Offload] Handle chunked local attention in offloading scheduler」。offloading scheduler 之前只处理 SlidingWindowSpec 等类型；ChunkedLocalAttentionSpec 会落到错误的类型假设，触发 FullAttentionSpec 断言，导致使用 chunked local attention 的配置在启动时失败。910

修补在 get_sliding_window_size_in_chunks() 中增加 ChunkedLocalAttentionSpec 分支，用 cdiv(attention_chunk_size, tokens_per_chunk) 计算窗口，并断言 attention_chunk_size > 0。新增测试用 attention_chunk_size=8192 验证 tokens_per_chunk=1024 时窗口为 8，用 tokens_per_chunk=3000 验证不能整除时向上取整为 3。这里的 8 和 3 是调度窗口的局部正确性，不是 offload 速度或容量提升。9

适合先跟进这条提交的是把 Llama 4 或其他 chunked local attention 模型接入 KV offload 的工程师。先运行 offloading connector 的 scheduler 单测，再用最小 workload 检查启动时不再触发 FullAttentionSpec 断言；如果 workload 的 chunk 尺寸不能整除 tokens_per_chunk，要特别检查向上取整是否让可达尾部被完整覆盖。提交没有测量实际模型的 offload 读写吞吐。

vLLM 在 2026 年 8 月 9 日 15:25:36（北京时间）提交 1b0ce31f，标题是「[KV Offload] Fix failed-load livelock by marking the lookup verdict as a miss」。在 tiering 路径中，一个 block 先被 lookup 判为 HIT，随后 promotion/load 失败；如果这个 verdict 仍保持为 HIT，同一请求的调度器会重复发起已经失败的 promotion。1112

这次修补把失败 key 交给 mark_miss()，将缓存 verdict 设为 False，且不重新 probe。批量 load 会记录 num_succeeded：已经成功加载的前缀 block 保留为 HIT，失败 block 及其后续部分标为 MISS。底层 I/O 还把三种情况分开：可证明的 short read 说明文件确实损坏，可以删除；open/read 错误属于瞬态或歧义失败，保留文件；完整读成功后的 close 错误不让 load 失败。11

复现入口覆盖 Python 与 C extension 两条路径。先截断一个 block，验证 promotion 失败后 corrupt file 被删除，同一请求直接得到 MISS 且不重新 probe；再用 ELOOP 模拟 open 失败，确认文件仍然存在；最后在批量 load 中只破坏最后一个 block，验证前面的 successful_keys 仍为 HIT、失败尾部为 MISS。obj tier 也有对应测试，防止失败 promotion 继续返回旧 HIT。这个提交证明的是失败后的状态收尾，不是存储层在所有故障下都能自动恢复。

五个提交各自把一个隐含前提写成了可检查的状态：DSV4 用 ring/window 公式限制 speculative tail；sconv 用 inert buffer 和清零规则固定 graph 与 batch 的状态形状；hybrid cache 用 connector capability 决定谁能解释分歧命中；chunked local attention 用 attention spec 计算真实可达窗口；failed-load 用 verdict 转换区分「当前请求不能再相信这个 HIT」与「底层文件已经损坏」。357911

共同判断只到这里：这五条工程增量都在修复「状态交接时，下一步是否知道自己拿到的是什么」的问题。对自己的系统做验证时，先按对象选择入口：speculative tail 查容量公式，graph path 查空 metadata 和尾部清零，hybrid cache 查 capability 合并，chunked attention 查窗口向上取整，offload failure 查 verdict 和 partial success。它们适合做最小测试或故障注入，不足以替代统一 workload 的性能实验。