Memory 技术日报 2026-08-09：三个修补把 KV 的所有权、预留与持久化对齐

三条窗口内更新都指向同一个工程事实：memory 出错时，问题往往不在「能不能存更多 token」，而在状态交接后，谁拥有索引、需要预留多少空间，以及旧状态能否被下一次读取正确解释。SGLang 修的是延迟释放时的张量所有权，vLLM 修的是 speculative decoding 的 KV 预留口径，oMLX 修的是混合 cache 的分块持久化与旧条目升级。它们都提供了代码或测试入口，但没有给出可横向比较的端到端性能数字。

SGLang 在 2026 年 8 月 8 日 18:34:44（北京时间）提交 cfb354bc，标题是「Fix batched KV free aliasing」。变更触及 NPU、HiSparse、paged、SWA、token 等多个 allocator，以及 radix cache 的未完成请求路径。1

触发条件很具体：deferred free group 直接保存了调用者传入的 tensor view；调用者随后原地修改原 tensor，等 free_group_end() 真正处理时，待释放的索引已经被改掉。补丁在 BaseAllocator 增加 _copy_for_free_group()，用 clone() 让 free group 持有自己的索引副本。radix_cache.cache_unfinished_req() 还把传给 free_segment() 的切片从 values[...] 改成 kv_indices[...]，避免把可变的值张量误当作稳定的 KV 索引。2

测试没有停在「函数返回成功」。test_paged_free_segment.py 会在延迟释放后把原始 row 清零，再检查 page representatives 仍然正确；radix cache 和 SWA 测试则检查 free group 结束后的可用空间、释放页和 request token 映射。这个验证证明的是延迟释放拥有自己的索引状态，不是吞吐提升、延迟下降或 KV 容量增加。

仓库采用 Apache-2.0 许可证；本次核验时 GitHub API 返回 31,546 个 star。3 想复现时，先从 提交 diff 与对应单测 开始，重点观察原始索引被清零后，free group 是否仍释放同一组页。

vLLM 在 2026 年 8 月 9 日 07:58:43（北京时间）提交 d608dfab，标题明确写出修复对象：[Bugfix][MRV2] Reserve spec-decode lookahead blocks in V2 warmup。提交新增 tests/v1/worker/test_gpu_warmup_blocks.py，同时修改 VllmConfig、V1 scheduler 和 GPU warmup。4

补丁把 num_lookahead_tokens 集中到 VllmConfig：没有 speculative config 时为 0；Eagle、draft model 等路径取 num_speculative_tokens；DFlash 取 num_speculative_tokens + 1，因为它还需要最后一个 sampled token 的额外位置。warmup 与 scheduler 随后按 num_computed + num_scheduled + num_lookahead_tokens 对齐 KV block 预留，Mamba 的 speculative running-state blocks 和 align 模式另有专门处理。5

这解决的是「预热阶段认为空间够用，真正调度时却按另一套规则申请 KV block」的状态漂移。新增测试把 _reserved_block_count() 与真实 KVCacheManager.allocate_slots() 对比，覆盖 prefill、speculative decode、非 speculative decode、Mamba 的 none/all/align 模式，以及 Eagle、DFlash、draft model 等方法。测试证明的是 warmup 计算和实际分配相互一致；它没有证明 speculative decoding 在某个模型、硬件或运行时上更快，也没有给出显存节省比例。

vLLM 仓库采用 Apache-2.0 许可证；本次核验时 GitHub API 返回 88,540 个 star。6 复现入口是 warmup block 测试，不要只测一个 num_spec_steps：至少要把 DFlash 的额外 slot 和 Mamba align 的特殊分支分开跑。

oMLX v0.5.8.dev2 是一个预发布版本，GitHub 的 published_at 为 2026 年 8 月 9 日 00:35:39（北京时间）。release note 把 memory 相关修复写得很窄：混合 CacheList layer 在保存长上下文 prefix 时会出现 quadratic SSD and memory growth；新实现按 block 保存可切片的 KV 成员，同时保留小型 boundary states，并增加旧 cache entry 的验证与升级处理。7

这里的关键不是「把 prefix 放到 SSD」这么简单，而是同一条 cache 中不同 layer 的状态生命周期不同：可切片 KV 可以按 block 重用，小边界 state 需要保留自己的边界语义。如果把两者用同一增长方式存储，长上下文会把每次追加的成本放大。release note 只说明了修复机制和兼容处理，没有提供模型、Apple Silicon 型号、运行时版本、基线或增长曲线，因此不能从「fixed quadratic growth」推出具体压缩倍数或线上延迟收益。

同一版本还修复了 single-stream MTP decoding 的请求队头阻塞：晚到请求可以通过 safe drain handoff 加入，而不必等当前生成结束。这个改动与 mixed CacheList 的持久化修复属于两个独立边界，不能合并成一个「缓存性能」数字。8

oMLX 仓库采用 Apache-2.0 许可证；本次核验时 GitHub API 返回 18,534 个 star。9 复现时应安装这个预发布版本，在含 mixed CacheList 的模型上写入并读取长上下文 prefix，分别观察可切片 KV、boundary state 和 legacy entry upgrade；MTP drain handoff 则应单独构造晚到请求验证。

把三条更新放在同一个维度上看：SGLang 要求 deferred free 拥有自己的索引；vLLM 要求 warmup 使用真实调度会用的容量口径；oMLX 要求持久化层 按可读取的状态粒度保存并能解释旧格式。它们没有互相比较性能，却共同把 memory 的正确性问题落到了「状态交给下一个消费者时，所有权、容量和表示是否仍然一致」这一层。

这也是今天最值得带回自己系统的检查顺序：先找出谁会在异步阶段修改索引，谁会在 speculative tail 之外继续申请空间，谁会在恢复时读取旧 cache entry；再用单测或最小 workload 验证状态一致性。三条来源都没有提供统一模型、硬件、运行时和 baseline，所以当前能确认的是边界修复与复现路径，不是端到端收益排名。