长推理把显存吃爆了？BeaconKV：用几个「信标查询」预判模型会回头看什么

你有没有算过这笔账：让 Qwen3-4B 生成 32K token 的推理链，batch size 开到 16，光 KV cache 就要吃掉 77GB 显存——一张 80GB 的 A100 直接顶到嗓子眼。这不是假设，是这篇论文开篇甩出来的数字。

大推理模型（LRM）靠超长 CoT 打天下，但 KV cache 随序列长度线性膨胀，成了部署上最硬的钉子。已有的压缩方案（SnapKV、RPC、R-KV 这一挂）思路都差不多：拿最近一小段 query 的注意力权重给历史 KV 打分，分低的踢掉。这个思路藏了一个没明说的假设——最近的 query 能代表未来的注意力模式。

这篇 ICML 2026 的论文说：在长程推理里，这个假设是错的。

核心摘要：作者在长推理链中发现了一类「思想重访 token」（Thought Revisiting Tokens, TRT）——模型会在某些解码步突然回头去 attend 几千 token 之前写下的解题计划或题目约束，而这些「回头看」的时刻稀疏且不可预测，靠最近 query 打分的压缩方法会系统性误删这些关键 KV。更妙的是，作者发现 TRT 对应的 query 在嵌入空间里会聚成少数几个簇，于是提出 BeaconKV：用最远点采样（FPS）在线维护一小撮「信标查询」作为各簇的代表，压缩时让信标查询模拟未来的全局注意力，提前把会被重访的 KV 保下来。全程免训练，在 4 个开源 LRM 上最高压缩 5.8 倍显存、吞吐提升超 4.3 倍，精度几乎不掉，比 RPC/R-KV 最多高出 31.7 个百分点。我的判断：这是 KV 压缩方向里少有的「观察驱动」工作，洞察本身比工程实现更值钱。

论文信息

• 标题：BeaconKV: Key-Value Cache Compression Guided by Beacon Queries for Efficient Large Reasoning Model Inference
• 作者：Janghyeon Kim、Minsoo Kim（汉阳大学）、Kyuhong Shim（成均馆大学）、Jungwook Choi（汉阳大学，通讯作者）
• 发表：ICML 2026，arXiv:2609.04971（2026 年 9 月 4 日提交）
• 代码：https://github.com/aiha-lab/BeaconKV
• 论文链接：https://arxiv.org/abs/2609.04971

🎯 问题动机：推理模型的 KV 压缩，难在「未来不可知」

先交代一下背景。KV cache 压缩这个方向其实已经卷了很久：H2O 用累计注意力找 heavy hitter，SnapKV 用观察窗口的注意力打分，都是「用注意力权重估重要性」的路子。到了推理模型时代，RPC 和 R-KV 把这套思路搬到了长 CoT 场景——拿最近若干个 query 对历史 KV 算注意力权重，聚合成分数，保留 top-K。

这条路在传统长上下文任务里挺好使，但推理模型有个本质区别：token 是边想边生成的，驱逐决策必须在解码途中做。你站在第 5000 步，要猜第 9000 步的模型会需要哪段历史。已有的方法相当于赌「未来几步关心的东西，跟最近几步关心的差不多」。

这个赌注在短程依赖为主的文本里能赢。但推理链不是这种文本——模型写着写着会突然说「等等，回到最开始的条件」，这种时刻就是论文命名的 TRT。说实话，做过长 CoT 部署的人对这个现象应该有体感：推理链越写越长，但模型并不是一路向前滚的，它会周期性地「翻笔记」。翻笔记的时候，被翻的那几页要是刚被你删了，推理直接断片。

🔬 观察：TRT 是真实存在、可量化、还有几何结构的

这篇文章我最喜欢的部分是第三章，观察做得相当扎实，不是拍脑袋讲故事。

作者把解码中的 query 分成两类：局部查询只看邻近的 key（维持局部连贯），全局查询会跨过整段推理链去 attend 远处的 key。TRT 就是产生全局查询的那些 token。

图1（a）：R1-Distill-Qwen-7B 在 AIME24 样本上、第 18 层第 16 头的注意力热力图。大多数 query（token 1066–1092）只 attend 近处 900–1092 的 key，但 token 1068 和 1090 明显「跳出来」，把注意力拉到了 100–450 这段早期上下文——那里正是题目约束和解题计划所在的位置。图1（b）：两个层/头的注意力距离直方图，局部查询（红）距离集中在 0 附近，全局查询（蓝）分布宽得多，两类模式在分布上干净利落地分开了。

作者还给了个更具体的例子：token 1068 和 1090 的 top-K 注意力落在开头的解题计划和问题约束上，而相邻的局部 token（1089、1091）只关心正在进行的计算。这个「翻笔记」行为不是个例。

图3：全局查询在「层 × 注意力头」网格上的出现次数热力图（token 512–639 区间）。颜色越亮表示该层该头出现的全局查询越多。可以看到全局查询散布在很多层和头上，而不是集中在某个特定组件——这说明 TRT 是模型的系统性行为，不是某个头的怪癖。

到这儿为止，结论是「回头看」现象存在且普遍。但光知道这个还不够用——全局查询稀疏、出现时机不可预测，你总不能把全部历史 query 存下来等它。真正的关键发现在下一步：

图4（a）：pre-RoPE query 两两余弦相似度矩阵。token 1068 和 1090 跟周围邻居的相似度都很低（它们是全局查询，跟局部查询格格不入），但它俩彼此之间相似度很高。图4（b）：query 的 PCA 投影，全局查询聚成了少数几个簇，1068 和 1090 落在同一个簇里。

这就是全文的题眼：全局查询不是随机乱飞的，它们在嵌入空间里聚成少数几个相似组。想想看这个结构带来的好处——你不需要记住历史上所有 query，只需要每个簇留一个代表，就能「代表」未来可能出现的各种全局注意力模式。这个代表，作者叫它信标查询（beacon query），像灯塔一样立在 query 空间里，标出哪些远处的 KV 未来会被回头访问。

一个观察能从现象一路推到可操作的几何结构，这个推导链条是漂亮的。

🏗️ 方法：BeaconKV 怎么把信标查询用起来

BeaconKV 是免训练的，整套东西可以拆成三块：观察 query 集怎么构建、信标查询怎么在线维护、KV 分数怎么算。

观察 query 集 = 最近查询 + 信标查询

已有方法（图5(a) 对应的 RPC 类方案）在缓存到达预算上限时，只拿最近 32 个 query 打分。BeaconKV 把观察集扩成两部分：

• 最近查询：保持局部连贯信号，常规操作；
• 信标查询：从历史 pre-RoPE query 里选出的几何代表，覆盖全局重访模式。

为什么用 pre-RoPE query？因为要在「没被位置编码旋转过」的干净空间里度量几何相似性，避免位置信息污染簇结构。这个细节挺讲究。

Continual FPS：有界内存的在线最远点采样

最远点采样（FPS）是个经典算法：从点集里贪心地选出彼此最不相似的 m 个点，保证几何覆盖度。离线跑 FPS 很简单，但推理是流式的，query 不断产生，总不能把几万条 query 都存着（尤其 GQA 模型 query 状态非常多）。

作者的解法是「填满-压缩」循环：每个注意力头维护一个有界 buffer，新 query 不断进来，buffer 涨到上限 \(B_Q^{\max}\) 时触发一次 FPS，压回下限 \(B_Q^{\min}\)：

这样信标集合随推理进行持续演化，内存占用却始终有界。论文 Figure 7 验证过，Continual FPS 的精度跟理想离线方案（K-Means 质心、Naive FPS）相当，但峰值显存明显更低。具体配置：信标预算最大 32、最小 16，最近查询固定 16 条。

打分时的 RoPE 对齐：一个容易被忽略但很关键的设计

驱逐时刻到来时（解码第 t 步），BeaconKV 对两类 query 施加不同的 RoPE 位置：

• 信标查询被旋转到当前步 t——等于在问：「如果一个全局查询现在出现，它会去看哪些 KV？」这是在模拟未来的 TRT；
• 最近查询保留各自的原始位置 \(\tau\)——维持标准的局部注意力信号。

然后用 max 聚合算每个 KV 位置的重要性：

为什么用 max 不用 mean？因为 TRT 的信号是「稀疏但幅度高」的——某个信标查询可能死死盯住某段 KV，而其他查询对它无感。mean 会把这种关键信号稀释进背景噪声，max 保证「只要有一个信标说它重要，就保住」。prefix token 和最近一小段 token 始终保留，剩下的预算按分数填 top-K。

为什么不用「Initial+Recent」这种更省事的方案？

你可能会想：既然模型回头看的是开头的计划，那把开头的 query 固定保留下来不就行了？作者专门做了这个消融（Table 3），结论是不行——开头的 query 是个固定、有限的历史参照集，覆盖不了长程推理中不断涌现的多样化重访模式。Continual FPS 的收益来自动态捕捉演化中的全局模式，而不是静态地记住开头。这个消融做得很有针对性，直接堵住了最自然的质疑。

📊 实验：低预算区间优势最大

实验配置：4 个开源 LRM（R1-Distill-Qwen-7B、R1-Distill-Llama-8B、Qwen3-4B、Qwen3-14B），基准覆盖数学（AIME24、MATH-500）、代码（LiveCodeBench）、科学问答（GPQA-Diamond）。最大生成 32768 token，temperature 0.6，top-p 0.95。缓存预算采用「最大-最小」双阈值：到达 \(B_{\text{KV}}^{\max}\) 时驱逐八分之一，压到 \(\frac{7}{8}B_{\text{KV}}^{\max}\)。

主结果（论文 Figure 8，因 HTML 渲染问题只有曲线图描述，这里转述关键数字）：

• 同预算下 BeaconKV 在绝大多数模型 × 基准组合上精度最高，低预算区间优势最大；
• 最大单次提升 31.7 个百分点：Qwen3-14B 在 AIME24、预算仅 1024 时达到——这种极限压缩下，recent-query 方法基本崩了，BeaconKV 还能扛住；
• 对比 Initial+Recent（预算 1024）的差距相当夸张，比如 AIME24 上 Qwen3-14B 是 57.92 对 23.75，Qwen3-4B 是 33.33 对 19.58。

效率数据（Qwen3-4B，生成 32K token，单卡 A100 80GB）：

同 batch（14）下，峰值显存从 77.0GB 压到 13.3GB，5.8 倍压缩，吞吐从 82.3 提到 356.4 tokens/s，精度只从 54.4 掉到 51.1。跟 RPC 在同预算同 batch 下比：吞吐、显存基本打平，但精度在 2K 预算下高 6.3 个点、1K 预算下高 12.3 个点。附录里对 SnapKV 的对比（1K 预算、batch 320）也类似：SnapKV 30.9%、RPC 29.9%、BeaconKV 42.2%，效率和 RPC 几乎一致。

消融实验里有两个值得细看的点：

信标/最近查询的配比（Qwen3-4B、AIME24、预算 2048）：16+16 是甜点，64.6% 精度、4355.7s 延迟；全押信标（1+31）精度 63.5% 但延迟暴涨到 10871.3s；而全押最近查询（即 RPC 的 32+0）只有 51.3%。我的第一反应是这个延迟差异很值得玩味——信标查询多了之后每次打分的开销不是白给的，全局信号和局部信号得平衡着来。

max vs mean 聚合（R1-Distill-Qwen-7B、AIME24）：256 预算下 max 是 23.3、mean 只有 18.8，符合「max 保稀疏信号」的叙事。但坦率地讲，2048 预算下 mean（50.8）反而赢了 max（46.7），论文没解释这个反转。我猜是预算宽松时大多数关键 KV 本来就能保住，mean 的平滑反而减少了误删，但这只是推测，原文没展开。

🤔 我的判断：观察值钱，适用边界也要看清

这篇论文最值钱的地方，在于它给「推理模型的注意力动态」贡献了一个干净的、可复用的观察：TRT 现象 + 全局查询的簇结构。BeaconKV 本身是这个观察的直接推论，工程上没有特别重的部件——FPS 是现成算法，max 聚合、RoPE 对齐都是轻量改动。免训练、即插即用，对部署方很友好。

但有几个地方得泼点冷水：

1. 适用边界窄于论文标题的暗示。作者自己在 limitations 里承认：评估全在推理任务上，标准的长上下文任务（检索、摘要）没测。TRT 是推理链特有的行为，这套方法迁移到普通长文本生成上还剩多少优势，是个开放问题。
2. 观察的统计基础偏薄。TRT 的可视化、PCA 聚类都基于 AIME24 sample-0 这一个样本（虽然跨了层和头）。出现频率热力图也来自同一样本。现象大概率是普遍的，但论文的证据链主要是单样本展示加下游精度反推，少了一点大规模统计。
3. 超参固定。信标数、最近查询数、预算全是手动定的，作者也说自适应调整留给了未来工作。实际部署时不同模型、不同任务的最优配比大概率不一样。
4. 延迟开销真实存在。同预算下 BeaconKV 的解码延迟略高于 RPC（7790.9s vs 7593.7s），信标打分不是零成本的，只是相对精度收益来说划算。

跟同期工作摆在一起看：可训练的方案（TRIM-KV、LightThinker、Fast KVzip）要学一个门控模块，跨域泛化存疑；稀疏注意力方案（Multipole Attention、ReSA、SeerAttention-R）保留全量 KV、省的是计算不是显存。BeaconKV 卡在「免训练 + 真省显存」这个位置，跟 RPC、R-KV 正面竞争，目前看是这个小生态位里最强的一档。说它是底层突破谈不上——核心是观察 + 组合已有技术——但作为 ICML 接收的工作，观察的清晰度和实验的完整度都在线。

工程启发：如果你在部署 R1 系或 Qwen3 系的推理模型、被长 CoT 的显存卡住，这套方法值得直接试——代码已开源，且不用动模型权重。实操上注意两点：信标/最近查询从 16+16 起步调，预算紧张时优先保 max 聚合。另外这个「信标」思路其实可以推广——任何「未来的重要性可以被历史的几何结构预示」的场景，都可能用类似的小集合代表来提前布局缓存。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我