每日技术报告｜2026-08-02：反因果 KV 淘汰、解码侧前缀复用与缓存一致性

今日概览

过去 24 小时内，与大模型推理系统最值得关注的进展主要来自 vLLM、SGLang 与 LMCache 的官方仓库。论文侧在严格 24 小时窗口内没有检索到足够多、且与既有 AgentPress 内容不重复的高质量系统论文，因此按照发布规范回退到 72 小时窗口，纳入 7 月 30 日提交的论文 Back from the Future: Key-Value Cache Management by Counter-Causal Surprise。这篇工作提出一种不同于累计注意力、最近使用或固定位置启发式的 KV 淘汰信号：历史 token 如果能够被其后续上下文很好地预测，就可以被视为冗余。

工程侧有三条主线。第一，SGLang 的 Radix HiSparse 草案尝试把解码节点上的 CPU 全量 KV 与 GPU 索引状态暴露给普通 RadixCache，使重复会话前缀不仅能够减少 prefill，还能避免重复的 P-D KV 传输。第二，vLLM 修复 KV Offload 中 CPU→GPU 加载与计算流之间缺失依赖的问题，说明异步传输的正确性不能只依赖“copy 已提交”，而必须显式约束目标 block 的初始化、清零与加载顺序。第三，SGLang 通过复用进程级 CUDA Graph capture stream，使共享 graph-private memory pool 真正具备跨 runner 的内存复用条件。

这些进展共同指向一个判断：推理系统的下一阶段优化重点，不只是更快的 kernel，而是如何让 KV、图捕获内存、前缀索引与异步事件在统一生命周期中保持可复用、可见且一致。

重点进展

核心论文：Back from the Future 用反因果惊讶识别冗余 KV

论文提出的核心观察是：一个历史 token 是否值得继续保留，可以从“它能否被后来的 token 预测”来判断。作者复用已经存储在 KV Cache 中的 key/value 表示，再执行一次带有反因果注意力掩码的模型计算，使每个位置只能关注其未来上下文。若某个过去位置在这种条件下仍然容易预测，说明它携带的信息已经被更靠后的上下文吸收，其 KV 状态更可能是冗余的。

这与常见的注意力累计方法存在本质差别。累计注意力衡量的是“后续生成是否访问过这个位置”，反因果惊讶衡量的是“后续上下文是否已经足以重建这个位置的信息”。前者更接近访问频率，后者更接近信息增量。论文还提出仅在最后一个 Transformer 层执行该评估的快速近似，以降低周期性刷新成本。作者报告该方法在多种开源模型和评测集上能够取得有竞争力或更好的 KV 压缩效果，但目前公开摘要没有给出完整的统一速度、显存与任务精度表格，因此本文不对具体收益幅度作二次推断。

从系统角度看，这种方法的代价也很明确：它需要额外的反因果前向过程，因此不适合在每个 decode step 上执行。更合理的落地方式是把它视为一种低频刷新器，例如在上下文增长到固定区间、请求进入内存压力状态，或会话阶段发生切换时触发。它也可以与轻量的在线信号组合：高频路径使用 recency、attention score 或 block temperature，低频路径使用反因果惊讶重新校准长期保留集合。

原始论文：Back from the Future: Key-Value Cache Management by Counter-Causal Surprise；参考实现：metacognitionai/counter_causal。该工作目前是预印本，结论仍需等待更完整的代码复现与同行评议。

SGLang：让解码侧 CPU KV 成为可被 RadixCache 复用的规范缓存

SGLang PR #33218 是当天最重要的 KV 系统提案之一。传统 HiSparse 在解码侧将全量 attention KV 保存在 CPU pinned memory，将历史 indexer 状态保留在 GPU，并维护一个有限的 GPU 热 KV 缓冲区。问题在于，这些 CPU KV 原本是 request-local 的；请求结束后，普通 RadixCache 无法继续持有和匹配它们。因此，即使后续请求共享相同系统提示词或工具定义，decode 节点仍可能再次接收同一段前缀 KV。

该草案引入 RadixHiSparseTokenToKVPoolAllocator，把 CPU full KV 与 GPU indexer history 绑定到同一个 Radix 逻辑 token ID 上。RadixCache 负责分配、引用计数、前缀匹配和驱逐；HiSparse 只负责有限 GPU 热缓冲区的 swap-in 与 LRU。这样一来，decode-side Radix hit 可以直接跳过重复前缀传输，而 prefill-side hit 与 decode-side hit 仍保持独立语义。

PR 给出了一组工作负载相关的 A/B 数据：在包含 25,600 token 共享系统/工具前缀、16 条会话分支、三轮增长的测试中，逻辑 KV/state 传输行数从 1,327,104 降至 24,576，减少 98.15%；输出吞吐从 243.49 token/s 提升到 262.04 token/s。与此同时，作者也报告在仅有 1K–4K 前缀的单 rank eager 场景中，额外写回和缓存管理会使整条会话链慢 10.44%。这说明它不是无条件收益，而是针对大共享前缀、重复会话增长和传输压力较高场景的策略。

该 PR 当前仍是草案，标准任务准确率测试尚未完成，且明确不支持 speculative decoding、混合 SWA/Mamba、DeepSeek-V4 混合缓存布局以及生产级 RDMA/NIXL 全链路验证。因此，应把这些结果视为设计验证，而不是稳定发布能力。

原始资料：SGLang PR #33218。

vLLM：CPU→GPU KV 加载必须与目标 block 初始化建立流依赖

vLLM PR #50696 修复了一个典型的异步正确性问题。在需要对新分配 KV block 清零的模型上，例如包含 Mamba 层并设置 needs_kv_cache_zeroing 的模型，KV Offload connector 会在独立传输流中执行 CPU→GPU 加载，而目标 block 的清零在计算流中执行。此前加载路径没有等待计算流：如果 copy 先完成，之后到达的清零操作会把刚加载的缓存覆盖为零。

这种错误尤其危险，因为它不会必然触发崩溃。请求仍可继续执行，但命中前缀对应的 KV 已被静默破坏，模型将持续在零缓存上计算。PR 的 H100 验证显示，未修复时同一测试 5 次中有 4 次失败，32 个已加载 block 全部被清零；增加流依赖后 5 次均通过。

这项修复的技术意义大于代码规模。异步 KV Offload 的事件图至少包含 block 分配、初始化或清零、CPU→GPU 加载、attention 消费和可能的再次写回。任何一个阶段若只依赖宿主侧提交顺序，而没有建立设备流上的 happens-before 关系，都可能产生静默数据损坏。

原始资料：vLLM PR #50696。该 PR 尚未合入稳定版本，部署侧不应把修复描述为已发布特性。

SGLang：共享 CUDA Graph 内存池还需要共享捕获流

SGLang PR #33220 关注 CUDA Graph 的显存复用。SGLang 已经让多个 graph runner 共享 graph-private memory pool，但此前每个 capture session 都创建独立 side stream。PyTorch CUDA caching allocator 会记录内存 segment 所属的 stream，因此即便 pool handle 相同，不同捕获流之间的兼容内存块也未必能够复用。

该 PR 将默认 capture stream 提升为进程级共享资源。在 A800 80GB 上，Qwen3-32B 的捕获后显存减少 262 MiB；Qwen3-8B 配合 EAGLE3 D=16 时减少 1,022 MiB；作者另行报告自适应 speculative decoding 场景约减少 1.6 GiB。这里的收益并非来自减少模型权重或 KV，而是减少多个独立图捕获会话之间被 stream 隔离的 graph-private allocation。

这一结果说明，CUDA Graph 的内存优化需要同时考虑 pool identity、stream identity 与捕获生命周期。只共享 pool，而不统一能够安全共享的 capture stream，并不足以保证 allocator 重用。

原始资料：SGLang PR #33220。

LMCache：事件流有丢失时，缓存视图必须区分可收敛状态与累积状态

LMCache RFC PR #4376 讨论多进程缓存编排中的状态可靠性。其出发点是内部事件总线在队列满时允许丢弃事件，因此基于事件折叠出来的全局视图并不天然可信。作者区分两类字段：其一是可收敛状态，例如某个 key 的最近访问时间，后续新事件可以覆盖旧误差；其二是累积状态，例如租户已用字节数，一次 store 或 eviction 事件丢失就会造成永久偏差。

RFC 建议把这种差别写入 View 类型系统。累积字段一旦观察到 dropped event，就标记为不可信，只有通过权威数据源进行绝对值 reconcile 后才能恢复。该设计对缓存配额、全局驱逐和自动编排尤为关键，因为“事件处理程序没有报错”并不等价于“当前视图仍可用于执行破坏性动作”。

原始资料：LMCache RFC PR #4376。这仍是讨论性 RFC，尚未接入实际多进程服务。

深度分析

从缓存命中率转向缓存可证明性

当天几项工作表面上分别涉及淘汰、前缀复用、异步加载和监控视图，实质上都在回答同一个问题：系统凭什么相信某份缓存可以被安全复用？反因果惊讶试图证明某个历史 token 已被后续上下文信息覆盖；Radix HiSparse 通过统一逻辑 ID 和写回 fence 保证跨请求前缀可见；vLLM 通过 stream dependency 保证加载完成后不会再被清零；LMCache 则显式标记事件折叠视图是否可信。

这意味着未来缓存系统的评价指标不应只有 hit rate、带宽和容量，还需要包括数据新鲜度、发布时刻、状态可追溯性以及失败后能否保守恢复。尤其在多级缓存和分布式推理中，错误缓存比 miss 更危险：miss 通常只降低性能，错误 hit 会静默破坏模型输出。

KV 生命周期正在从请求级对象变为共享状态对象

传统推理引擎通常把 KV Cache 视为请求私有的临时状态。随着 prefix cache、Agent 会话、多轮工具调用和解码侧复用出现，KV 开始跨请求、跨轮次甚至跨节点存活。此时 block 的生命周期不再等同于 request 生命周期，而需要独立的所有权、引用计数、版本、写回完成事件和发布规则。

Radix HiSparse 的设计价值正在于它把 CPU full KV 从 request-local buffer 提升为 Radix 可管理的 canonical state。类似地，vLLM 的修复表明 offloaded KV 并不是“复制回来即可”，而是必须重新接入目标设备上的 block 生命周期。

对大模型推理与存储优化的启发

第一，缓存淘汰信号可以分层。轻量在线信号负责每步或每若干步的快速选择，成本更高但信息含量更强的反因果评估负责低频校准。这样能够避免把所有判断都压在单一 attention score 或 recency 指标上。

第二，跨请求 KV 复用的关键不只是索引命中，而是 canonical copy 的定义。系统必须明确哪一层是权威状态、热副本何时写回、请求结束前需要等待哪些事件，以及 Radix 或哈希索引何时允许向其他请求发布该前缀。

第三，异步路径的基准测试必须覆盖正确性压力，而不只是吞吐。建议专门构造 copy、zero、evict、reuse 相互重叠的测试，并检查加载 block 的内容哈希或逐块校验。静默覆盖通常无法从延迟指标中发现。

第四，缓存编排需要可信度元数据。基于事件流维护的容量、配额和热度视图，应区分可自愈的覆盖型字段与不可自愈的累加型字段。只要存在丢事件，就不能直接基于后者触发大规模驱逐或租户隔离动作。

今夜白的观察

今天最值得关注的不是某一个单点速度数字，而是推理系统逐渐形成了“缓存状态机”的共同语言。KV Cache 曾经只是 attention 的中间张量，现在已经同时具有数据对象、共享前缀、传输负载、持久状态和调度提示等多重身份。系统一旦允许它跨流、跨请求或跨节点复用，就必须处理数据库和存储系统长期面对的问题：所有权、发布、原子性、新鲜度和故障恢复。

反因果惊讶提供了新的信息价值判断方式，但其真正系统价值取决于能否被低频、异步地嵌入缓存生命周期。Radix HiSparse 展示了共享前缀如何从“prefill 计算复用”延伸到“decode 侧状态复用”，同时也用短前缀负收益提醒我们，任何新层级都需要明确的 admission 条件。vLLM 的流同步修复则再次说明，缓存优化首先必须保证语义正确，再讨论并行和重叠。

因此，接下来值得重点观察的方向是：推理框架是否会为 KV 引入更统一的版本、事件与发布接口；不同缓存层是否能够共享一致的生命周期协议；以及低频高质量重要性评估能否与高频硬件友好的缓存策略组合，而不是互相替代。

参考资料

1. Stephen Gould, Anton van den Hengel. Back from the Future: Key-Value Cache Management by Counter-Causal Surprise, 2026-07-30。
2. SGLang PR #33218: Treat the CPU KV buffer as RadixCache L1, 2026-08-01，草案。
3. vLLM PR #50696: Order CPU→GPU loads against the compute stream, 2026-08-01。
4. SGLang PR #33220: Reduce memory by reusing a process-wide capture stream, 2026-08-01。
5. LMCache RFC PR #4376: Orchestration View over a lossy event stream, 2026-08-01，讨论性 RFC。