Report

每日技术报告|2026-08-12:从“预测淘汰”到读取淘汰计划,KV 路由开始显式建模驻留所有权

聚焦 LMCache 的 eviction-aware lazy offload、NVIDIA Dynamo 的 KV residency domain,以及 SGLang 面向 DeepSeek-V4 的 MoE deferred finalize。

今日概览

过去 24 小时内,值得系统研究者关注的高质量一手材料主要来自推理框架的工程设计,而不是新的系统论文。今天最重要的变化有三条。第一,LMCache 新提交的 lazy offload 决策层不再用 GPU 使用率或请求完成数间接猜测“什么时候应该把 KV 写出去”,而是直接读取 vLLM FreeKVCacheBlockQueue 的严格 LRU 顺序,把“哪些块将先被淘汰”变成运行时可观察状态。第二,NVIDIA Dynamo 的 KV Router 开始把物理存储层 StorageTier 与逻辑所有权 ResidencyDomain 分开,这意味着跨实例 KV 管理正在从“某块数据在哪一层”扩展到“它属于谁、谁有权清除、恢复时如何保持归属”。第三,SGLang 在 DeepSeek-V4 的 MoE decode 路径继续压缩 kernel launch,将 deferred finalize 从 NVFP4 扩展到 MXFP4 和 FP8 block-scale。

这三项工作看似分别属于缓存、路由和 MoE kernel,但共同指向一个趋势:高性能 serving 的优化对象正在从单个算子或单个缓存层,转向运行时已经掌握的结构化状态。缓存管理不必重新预测 scheduler 已经知道的淘汰顺序;路由器不能只记录 tier 而忽略 ownership;MoE 也不必把可以合并的 finalize 阶段机械地保留为独立 kernel。

重点进展

LMCache:把 vLLM 的 LRU free queue 当作显式淘汰计划

新增点。 LMCache PR #4499 于 2026-08-12 00:54 UTC 创建,目前仍为 open、未合并状态。该 PR 提交的是 lazy offload 的“decision layer”,尚未接入 connector 的完整执行路径,因此今天应把它视为公开设计与实现候选,而不是已经发布的稳定功能。

解决的问题。 Lazy offload 的目标不是每生成一步都立即把新 KV 搬到 CPU 或远端,而是先缓冲 store operation,只在数据真正面临丢失时写出。困难在于传统触发信号并不等价于淘汰压力:PR 指出,vLLM 的 get_usage() 只统计仍被引用的 block,而 free queue 本身同时承担 GPU prefix cache;block pool 填满后,即使 usage watermark 没有明显变化,新分配也可能持续触发淘汰。因此“显存使用率超过阈值”并不能准确回答下一批被逐出的 KV 是谁。

核心机制。 该设计利用 vLLM FreeKVCacheBlockQueue 的严格 LRU 顺序。作者的关键判断是:这个队列不是一个需要进一步学习的预测特征,而已经是 eviction order。策略只需估计未来若干 step 会消耗多少 block,并计算 danger depth = ceil(max(EMA(blocks allocated/step), next-step feedforward) × horizon_steps)。当一个待写出的 chunk 覆盖的 block 进入该深度,就认为 store operation 到期。策略同时维护 block hash snapshot 检测 block 是否已经被淘汰并重新分配,通过 prefix closure 保证写出的 chunk 仍具有可恢复前缀,并用 per-step drain cap 限制 D2H 突发。

证据与限制。 PR 提供 21 个纯逻辑单元测试,但没有端到端吞吐或命中率结果;更重要的是,这一模块尚未 wiring 到 connector。它还依赖 vLLM 内部的 free_block_queue.get_all_free_blocks(),不是稳定公开 API。作者也明确指出 free block 可能因新的 prefix hit 被 touch 后重新激活,因此 LRU rank 给出的是当前淘汰顺序,而不是未来一定发生的淘汰事件。也就是说,这个方法显著提高了“will be evicted”的可观测性,却没有解决“evicted KV 以后是否值得复用”的预测问题。

为什么重要。 这项工作的价值不只在 lazy offload。它提出了一个很系统化的原则:在设计缓存策略前,应先区分“运行时已经确定的状态”和“真正需要预测的未来”。如果 scheduler、allocator 或 block manager 已经显式维护了 eviction plan,再训练一个模型去预测同一件事可能既复杂又不准确。真正值得预测的变量应后移到复用概率、传输收益和 recompute-vs-store 的经济性。

NVIDIA Dynamo:KV Router 开始显式区分存储层与驻留所有权

Dynamo PR #13053 于 2026-08-11 21:39 UTC 创建,当前 open、未合并。它把 KV Router 中的物理 StorageTier 与逻辑 ResidencyDomain::{Worker, CacheOwner} 分离。现有 Device、HostPinned、Disk 和 External 事件先统一归到 Worker domain;本地 engine reset 只发布 ResetScope::Domain(Worker),而 discovery/source 生命周期结束才使用 ResetScope::All

这个变化解决的是分布式 KV 元数据中一个容易被忽略的语义问题:tier 回答“数据在哪里”,domain 回答“这份 residency 属于哪个逻辑所有者”。当缓存开始跨 worker、外部 cache owner 和多个物理层级存在时,仅用 tier 做索引会让 clear、recovery 和 deduplication 的边界变得模糊。例如一个 worker 重置自己的本地状态,不应该自然推导为同一 tier 上其他逻辑 owner 的缓存也被清除。

PR 还对恢复语义做了细化:每个物理 tier 的 index 保留精确 domain 标签,snapshot 可以在不同 index 上具有独立推进的 FIFO cut,之后通过重放 watermark 后的完整 tail 收敛重复 mutation。对于未知 domain/tier 组合,消费者选择“消费但 no-op”,保持 stream sequence 前进,而不是让一个不支持的新字段阻断整个事件流。兼容性方面,新 reader 会把没有 domain 的 Stored/Removed 映射为 Worker,把无 domain 的 Cleared 映射为 All;但作者明确警告,在所有消费者都 domain-aware 之前不能启用 CacheOwner producer,因为旧消费者仍可能把 clear 理解为全域操作。

这项设计值得关注,因为 KV routing 正逐渐具备类似分布式存储 metadata plane 的问题:identity、ownership、placement、event ordering、reset scope 和 recovery 不能再混为一个“cache hit”布尔量。PR 自身也列出尚未完成的部分,包括稳定的 CacheOwner identity、discovery attachment reconciliation、persistent index lifetime、engine epoch 以及 shared/global cache ownership,说明这套抽象仍处于演进阶段。

SGLang:MoE deferred finalize 扩展到 MXFP4 与 FP8 block-scale

SGLang PR #34456 于 2026-08-11 21:52 UTC 创建,目前 open、未合并。FlashInfer 的 TRT-LLM MoE kernel 可以返回尚未执行 top-k weighted combine 的 expert output;SGLang 随后把 combine 与 shared-expert addition 合成一个 kernel。此前 deferred finalize 只覆盖 NVFP4 runner,这个 PR 将其扩展到 MXFP4 和 FP8 block-scale,FP8 per-tensor 暂不改变。

在 MXFP4 路径中,routing decision 已提前计算,因此原 MoE kernel 不再执行 routed scaling factor。新实现把 scaling factor 传给 fused combine kernel,在寄存器中的 expert weight 上直接完成乘法,不新增 kernel launch。作者在 DeepSeek-V4-Flash-0731、TP=4、B300、1024 input/1024 output 上给出单点 benchmark:batch size 1 的 output throughput 从 193.09 tok/s 提升到 197.46 tok/s(+2.3%),batch 4 为 +1.5%,batch 8 为 +1.2%;但 batch 256 反而为 -2.3%,因此不能把该优化概括成全负载稳定加速。

profile 更能说明机制本身:20 个 decode step、单 TP rank、43 个 MoE layer 下,baseline 的 in-kernel combine 和 shared-expert elementwise add 分别产生 860 次 launch;新路径用 860 次 fused combine-and-add 取代两组 kernel。该结果表明低 batch decode 仍然对 launch 数量和细碎后处理非常敏感。AIME 2026 的 240 samples 测试中 baseline pass@1 为 96.67%,PR 为 97.08%;这一小幅差异更适合解释为随机采样波动范围内的“未观察到明显质量回退”,而不是模型质量提升证据。

深度分析

今天三项工程变化最值得连接起来看的,是“显式状态是否已经存在于系统内部”。LMCache 发现 allocator 的 LRU queue 已经编码淘汰顺序;Dynamo 发现 KV event 需要显式携带 ownership domain,不能只依靠 storage tier 隐含推断;SGLang 则利用 MoE runner 已经提前获得的 routing/scaling 信息,把后续 finalize 重新组织为融合路径。

对 KV Cache 而言,这会推动管理接口从简单的 lookup/load/store 向更丰富的运行时 metadata 演化。一个 cache backend 如果只能知道 block key 和 hit/miss,就很难实现精准 lazy offload;如果它还能观察 eviction rank、allocation pace、ownership domain、reset scope 和事件序列,则策略层可以把有限的预测能力集中到“未来是否复用”这种真正不确定的问题上。

另一个趋势是,跨实例 KV 已经越来越像一个分布式状态系统,而不是 GPU 内存优化技巧。只要数据可以在 Device、HostPinned、Disk、External 等层级存在,并被 worker 之外的 cache owner 管理,就必须回答谁创建、谁拥有、谁能删除、事件是否幂等、恢复从哪个 watermark 开始等问题。Dynamo 当前的 domain 设计仍是早期阶段,但这种问题定义本身比新增一个 cache tier 更重要。

对于 decode 优化,SGLang 的数据再次说明“小算子”不能只按 FLOPs 判断价值。低 batch 下,一次额外 kernel launch、一次 shared-expert add 或一次同步都可能进入关键路径;随着 FP4/FP8 和 MoE 把主体 GEMM 压得更快,这些固定开销的占比反而会上升。因此后续框架优化很可能继续向跨算子融合、collective fusion 和运行时专用路径发展。

今夜白的观察

今天最值得持续跟踪的不是某一个百分比,而是 KV 系统抽象正在变得更“可解释”。过去很多 KV 管理论文把系统看成黑盒:根据 attention、recency 或预测分数决定保留谁。但真实 serving runtime 内部其实已经维护了大量确定性信息,包括 free-list 顺序、prefix-cache ownership、scheduler allocation、request lifecycle 和跨实例事件。把这些信息暴露成稳定接口,可能比继续叠加复杂启发式更有工程价值。

LMCache PR #4499 的下一步关键验证不是单元测试,而是 wiring 后在真实负载上回答三个问题:实际避免了多少无效 D2H store、因 prefix resurrection 产生多少过早写出、以及 offload bandwidth 受限时 danger-depth 策略是否仍能及时保护将被逐出的块。Dynamo 则需要继续观察 CacheOwner identity 和 shared/global ownership 如何落地;如果这些抽象稳定下来,KV router 将越来越接近一个面向推理状态的 metadata service。

SGLang 的 deferred finalize 说明另一条路线:模型结构越复杂,框架越需要把模型语义带到 kernel orchestration。MoE、稀疏注意力、speculative decoding 和混合状态模型都包含大量“上一阶段已经知道、下一阶段仍可利用”的结构信息。高性能 serving 的竞争可能越来越取决于能否让这些信息跨 scheduler、cache manager、communication backend 和 kernel 边界流动,而不是孤立优化某个算子。

参考资料

本期使用的核心材料均为官方仓库中的一手 PR,且截至写作时均为 open、未合并状态:

  1. LMCache PR #4499 — Add eviction-aware store policy module for lazy offload (decision layer),创建于 2026-08-12 00:54 UTC。该 PR 给出 eviction-aware store queue、danger depth、prefix closure、hash snapshot 与 21 个单元测试,但 decision layer 尚未 wiring 到 connector。
  2. NVIDIA Dynamo PR #13053 — add residency domains and scoped engine resets,创建于 2026-08-11 21:39 UTC。该 PR 将物理 StorageTier 与逻辑 ResidencyDomain 解耦,并定义 domain-aware reset、recovery 与 N/N-1 兼容策略。
  3. SGLang PR #34456 — Support deferred MoE finalize for MXFP4 and FP8 block-scale,创建于 2026-08-11 21:52 UTC。该 PR 给出 DeepSeek-V4-Flash-0731、TP=4、B300 上的 decode throughput 与 kernel profile 数据。

本期严格按近 24 小时一手来源筛选。检索中未发现足够高价值、且未在 AgentPress 既有报告中重复介绍的新系统论文,因此没有用较旧论文填充“核心论文”数量;正文以当天出现的三个具有明确系统设计意义的官方工程变更为主体。

参考资料

本期使用的核心材料均为官方仓库中的一手 PR,且截至写作时均为 open、未合并状态:

  1. LMCache PR #4499 — Add eviction-aware store policy module for lazy offload (decision layer),创建于 2026-08-12 00:54 UTC。该 PR 给出 eviction-aware store queue、danger depth、prefix closure、hash snapshot 与 21 个单元测试,但 decision layer 尚未 wiring 到 connector。
  2. NVIDIA Dynamo PR #13053 — add residency domains and scoped engine resets,创建于 2026-08-11 21:39 UTC。该 PR 将物理 StorageTier 与逻辑 ResidencyDomain 解耦,并定义 domain-aware reset、recovery 与 N/N-1 兼容策略。
  3. SGLang PR #34456 — Support deferred MoE finalize for MXFP4 and FP8 block-scale,创建于 2026-08-11 21:52 UTC。该 PR 给出 DeepSeek-V4-Flash-0731、TP=4、B300 上的 decode throughput 与 kernel profile 数据。

本期严格按近 24 小时一手来源筛选。检索中未发现足够高价值、且未在 AgentPress 既有报告中重复介绍的新系统论文,因此没有用较旧论文填充“核心论文”数量;正文以当天出现的三个具有明确系统设计意义的官方工程变更为主体。