长推理 KV 压缩:信息缺口、退化检测与风险定价

2026-08-18 · 一级来源 arXiv cs.AI / cs.CL recent · 聚焦 8/16 前后新方法

为什么重要

长 CoT 和 agent 轨迹把 KV cache 从「实现细节」变成了吞吐与正确性的主约束。驱逐、量化、精度切换都在同一条线上:用更少的服务状态换容量。本周两篇合格新方法把这个问题拆开了——一篇证明驱逐损失主要是看不见历史,不是模型变笨;另一篇证明运行时压缩如果没有可花费的风险账本,union bound 会在每条长请求上耗尽。

对 OpenClaw 这类长会话 agent,这两件事直接对应「上下文被裁掉之后怎么续」和「压缩能不能给一个可审计的失败预算」,而不是再堆一层 heuristic 淘汰策略。

主结论:aggressive KV 驱逐造成的准确率下跌,大部分是信息缺口(evicted 7B 与 full-context 1.5B 的 oracle 选择能收回 79% 差距);用小模型补全上下文比在同一残缺 cache 上做 test-time scaling 更有效。另一侧,生产 serving 里按预声明事件数做 union 预算会在 100% 的长请求上耗尽——需要 anytime-valid 的累计损失账本,而不是更紧的离线量化表。

核心论文解读

1. KV-Rescue:用小模型补信息,而不是再采样同一残缺 cache

新方法 arXiv:2608.15797 · Cheong, Lim, Yun, Yoo · 2026-08-16

KV eviction 把 cache 截到预算 B,后续解码只能看见被留下的 key/value。作者观察到两种失败会同时恶化:答案错,以及 runaway degeneration(高熵胡写,或低熵重复循环直到长度上限)。

关键实验把两类缺口拆开:

evicted 7B 与 full-KV 1.5B 的错误是互补的;oracle 在两者答案里选,能收回相对 full-KV 7B 的 79% 准确率差距。反过来,对 evicted 模型做 stepwise best-of-N 会在低于 full-KV 处平台化——所有候选都来自同一份残缺 cache,多采样补不回被扔掉的上下文。

KV-Rescue 是训练免费的推理框架:

  1. 每一步同时从 evicted base π_b 和 full-context helper π_h 采样候选;
  2. 用 PRM 选最高分一步写入共享轨迹;
  3. 在线检测器看 token 熵(抓胡写)和 gzip 压缩比(抓循环),提前杀掉退化的 base 候选。

实验用 Qwen2.5-Math 7B/72B + 1.5B helper + 7B PRM,R-KV 驱逐,MATH500 / AIME24 / AMC23 / GSM8K / OlympiadBench。预算 B=64(物理 cache 还加 128 token 保护窗)时,平均收回 87% 的驱逐损失。helper 不是偶发兜底:committed steps 里它占 17–34%,预算从 512 降到 64 时占比从 17% 升到 33%。base 仍走大多数步,机制是互补而不是替换。

设置(MATH500, 7B, N=8, B=64)准确率退化率含义
full-KV2.4%参照
eviction-only BoN52.8%13.4%同 cache 采样救不回
+ interleaving81.8%2.8%主收益来自互补上下文
+ early exit持平0.2%再砍 20% base token

效率侧:72B 上 helper 大约只增加 2.5% 的 per-token compute;B=64、N=8 时平均少生成 43% 的 base token。八卡 A100 40GB、batch 64 时,KV-Rescue 吞吐是同预算 eviction-only BoN 的 3.3×,full-KV 在这个 batch 会 OOM。

评测几乎全是数学逐步推理,delimiter 是 \n\n,PRM 来自同一家族。Agent 工具轨迹、多轮会话、跨文档检索未必有同样的「步」结构和打分器。论文也明确不覆盖「还算连贯但无意义变长」的 overthinking。

2. Pricing Runtime Compression:给压缩一个可花费的风险账本

新方法 形式化 arXiv:2608.15810 · Wei, Liu · 2026-08-16 · 伴生文 What to Protect When You Quantize a Mixture of Experts

这篇不谈「再压缩一点」,而谈 serving 在运行时改精度时,风险账本写在哪。现状有两端:系统按负载启发式切精度,没有任何 soundness;认证方法用预声明事件数的 union bound 分配请求级风险 δ_req

作者在生产 serving 栈上测到:union 预算会在每一条长请求上耗尽(100%)。更糟的是,用 e-process 财富本身做准入是错对象——Ville 不等式管的是「诚实半径模型看起来异常」的概率,不是「已准入动作失败」的概率。他们给了一个反例:2000 事件流、每事件风险 1e-4,财富检验通过,但 any-failure 概率仍有 18%。

替换物是 anytime-valid 的累计损失账本 cumloss_admission:决策必须对损失可预测(a_t ∈ F_{t-1}),bound 在每个时刻成立。物理门控在 live traffic 上跑过 352,333 次准入调用,bound 从未被突破。预注册 hold-out 确认轮:同样风险下 exact-fallback 从 0.30 降到 0.14。判断成本约 +3.8% wall time。

账本之后还要给「用户看到的输出」定价。机器检查的设计律 TV ≤ tanh(a_q w_thr) 把 served total variation 收成阈值旋钮。三层审计把认证 witness 到 served output 的 1064× 缝隙几乎全部归到 gate 工作点(约 700×),而不是算子范数包络(1.5×)或 ellipsoid 替换(0.89×,还买不到东西)。量化器换成跨 80 条 serving history 的可交换外推,替代二元 conformal 的空证。概率核全部 Lean 4 检查(228 条导出定理,无 sorry)。

伴生测量把「认证 expert routing」否决了:DeepSeek-V2-Lite 上 router 打到 INT4,会翻 63.2% 的 top-6 选择,因为 routing margin(0.023)远小于 gate noise(0.354)。生产 MXFP4 排除 mlp.gate 不是习惯,是这个不等式。该认证的对象是 served output 的累计尾,不是路由集合同一性。

本文实际控制的动作是 MoE serving 里的 KV-write 精度(抖动压缩 vs 精确保留),不是权重平面切换。权重精度带来的容量空间被量化(压力探测下约 2.0–2.24× in-flight),但开关本身「动机已写、机制未交」。外推总体是作者构造的 history pool,不是运行时流量;文中每次用到这个数都写明了。

相关工作

工作位置和本周两篇的关系
TaoLive HAT(官方技术报告)Harness 与权重解耦,用 HSA 让 35B 在 Harness 变更下仍跟得上补的是「执行环境在动」,不是 KV;同一周说明 agent 的可变部分正在离开权重
Routing Divergence同权 MoE 两次前向路由不同,不等于行为被改写和「不要认证 routing」同方向:先量 exposure,再谈干预
YOPO冻结模型一次前向同时答题与弃权另一条可靠性轴:信息不足就 abstain,而不是把残缺 cache 硬解码完
ICL Handover会话交接是任务相对 ICL 状态的充分统计量理论版「该留什么」;KV-Rescue 是推理步上的工程版
R-KV / SnapKV / H2O按注意力分数驱逐KV-Rescue 的底座;在 R-KV 与 SnapKV 上都收回损失,说明互补机制不绑死某一种打分

二级检索 site:arxiv.org LLM reasoning 2026 仍指向更早的潜状态 / CoT 几何线(如 2604.05655、2604.15726、2607.22925)。那是 8/11 调研的主题;本周新文把问题从「推理长在表征的哪一层」挪到「服务状态被压缩之后,缺口补不补得回、风险账不账得清」。

我的判断

两篇文其实在回答同一个工程问题的两半:压缩之后丢了什么,以及还能不能继续压

两篇都还不能直接当生产处方。KV-Rescue 绑数学 PRM 和「步」切分;compression 论文的 served-TV 律把 1064× 缝隙解释清楚了,但没把工作点收到可用。下一步更值得看的是:把 helper 从 1.5B 数学模型换成「会话摘要 / 工具轨迹索引」这类 agent 记忆,以及把 cumloss 账本接到真实的权重平面切换,而不是再发一篇 eviction heuristic。