Memory 技术日报 2026-08-08：从滑窗回收到状态交接，四个 memory 边界被写实

四个 GitHub 提交把 memory/context 系统里容易被默认处理的状态边界写进了代码：SWA 何时回收、HiCache 哪份副本可以释放、Rerank 到底读取哪一层文本，以及 DFlash 下一轮 draft 消费哪些 target 状态。它们的证据都是 commit patch 和仓库测试变更，足以指导复现和代码审查，但没有提供共同的端到端 benchmark，不能据此推出吞吐、命中率、质量或 speculative decoding 接受长度已经提升。

SGLang 的提交 209857334 在北京时间 8 月 8 日 08:28:26 进入 commit 记录，改动了 schedule_batch.py 的 maybe_evict_swa。旧逻辑按 forward_iter 对 eviction_interval 取模，所有请求共享一个维护相位；新逻辑改为逐请求检查：请求处于 decode、req.decode_batch_idx >= 1、持有 KV，并且 req.seqlen - 1 - sliding_window_size 至少比 req.kv.swa_evicted_seqlen 多出 eviction_interval。满足后才调用 _evict_swa。1

这个差异解决的是触发条件的归属。调度器迭代推进，并不等于每个请求都滑出了同样多的 token；按请求的 seqlen 计算，回收阈值才和实际需要保留的滑窗范围绑定。decode_batch_idx >= 1 仍保留了 overlap scheduler 的安全边界，避免前一个 extend batch 仍在运行时提前回收。

先复现 maybe_evict_swa 的调用时机：固定 sliding_window_size 和 eviction_interval，让两个请求以不同速度推进 seqlen，检查 _evict_swa 是否只在各自跨过 token 阈值后触发。该提交只改了调度条件，没有配套的端到端性能数字；因此不能把更精确的触发条件写成吞吐或显存收益。仓库许可证为 Apache License 2.0，提交页面读取时显示约 31.5k stars；这两项只说明代码的使用和复现前提，不是该修复的效果证明。2

提交 3dc9136 的 commit 时间为北京时间 8 月 8 日 06:59:59。它调整了 HiCache 的 write_back 路径：host 压力出现时，优先寻找已经存在设备侧 Full KV、同时有 host 重复副本的节点。但「有两份」还不够成为释放条件。patch 增加了 full_host_duplicates、load_back_pending_id 和 write_back_duplicate_reclaim_digest，并要求写回或 load-back 已完成、host 侧没有锁、没有在途 DMA，设备侧 Full KV 仍然存在，才回收 host duplicate。3

这条修补把「副本冗余」和「副本可释放」分开了。finish_load_back(anchor_node_id) 用于在确认回传完成后清除 H→D 的在途状态；跨 TP rank 的 reclaim digest 则让回收顺序能被其他 rank 检查。读者复现时应先跑 test/registered/unit/mem_cache/test_unified_radix_cache_unittest.py，再分别制造 host pressure、load-back pending、host lock 和设备 Full KV 缺失的状态，确认只有安全分支会释放重复副本。patch 和该单元测试文件证明了状态机边界被覆盖，仍不证明线上 KV 命中率或 host 内存占用已经改善。4

OpenViking 的提交 cbc3907 在北京时间 8 月 8 日 01:40:32 进入 commit 记录，修改了目录元数据向量化和重建逻辑。对 ContextLevel.OVERVIEW，L1 记录的 abstract scalar 改为保存经过 _truncate_abstract_bytes 处理的 overview；vectorize_directory_meta 也不再把 L0 abstract 当作 L1 的 abstract。新增测试 test_vectorize_directory_meta_l1_abstract_is_overview 检查 L1 的 abstract 和 message 都等于 overview，另一个测试确认 UTF-8 编码后的 abstract 不超过 50,000 字节。5

这里被修正的是排序输入，不是召回结果本身。若 Rerank 需要判断目录概览，读到 L0 abstract 就会把层级摘要当成当前候选的文本；现在 L1 overview 被放到它实际读取的 scalar 字段，排序器拿到的对象和候选层级一致。先复现上述两个单元测试，再检查一个同时存在 L0 abstract 与 L1 overview 的目录，确认 Rerank 输入来自 L1 文本，并观察长 overview 被截断而不是让标量字段无界增长。

OpenViking 当前仓库许可证为 AGPL-3.0，提交页面读取时的 star 快照约为 28.1k。许可证决定代码如何进入你的系统，不能替代对 Rerank 质量、召回率或延迟的评估；这个 commit 同样没有给出这些指标。6

SGLang 的 DFlash 提交 8600457 在北京时间 8 月 8 日 05:42:30 进入 commit 记录，只增加了两行状态传播：在 forward_batch_generation 构造下一轮输入时，把 target_out.routed_experts_output 和 target_out.indexer_topk_output 传入 next_draft_input。patch 的上下文说明，非 overlap 路径从结果推进 batch.seq_lens，而 overlap 路径依赖 next_draft_input 携带状态；缺少这两个字段时，下一轮 draft 可能拿不到上一轮 target 已经计算出的路由与 indexer 结果。7

复现入口是 python/sglang/srt/speculative/dflash_worker_v2.py 的 overlap 路径：构造一次 target 输出，检查两类字段是否原样进入下一轮 draft 输入，再验证 suspend/resume 或连续 decode 时不会被清空。两行传播修复的是状态连续性，不是 draft/target 的计算量、接受长度或端到端延迟；没有模型、硬件、运行时和 baseline，这些数字都不能补写。

四个提交的共同点不在于它们已经证明了同一种性能收益，而在于它们分别把状态交给了正确的局部消费者：SWA 用请求自己的滑出进度决定回收，HiCache 用副本所有权和传输完成状态决定释放，OpenViking 用 L1 文本修正 Rerank 的输入，DFlash 用 target 输出维持下一轮 draft 的状态连续性。把这四个位置放在一起看，工程上更值得复现的是「错误完成判断会在哪里发生」，而不是先问「平均快了多少」。

这些边界都能从对应 commit 的代码和测试开始验证；要把它们升级成性能结论，还需要在明确的模型、硬件、运行时、请求分布和 baseline 下补做实验。