2026 年 9 月 3 日提交到 arXiv cs.CL 的 Random Attention: Rethinking KV Cache Eviction for Efficient Reasoning 是今天很值得放进论文速读的推理效率论文。它出现在 arXiv cs.CL recent，也被 Hugging Face Daily Papers 和 X 上的研究者讨论。论文摘要的结论非常反直觉：在长推理任务里，很多复杂 KV cache evictor 试图给缓存 token 打重要性分数，但选择信号贡献可能很小；只要保护 prompt，在每个 attention head 内均匀随机淘汰，效果就能接近最强 prior evictor，同时在 vLLM 部署中获得 32-43% 更高吞吐。
这类论文的价值不在“随机就是最优”的口号，而在它挑战了一个工程直觉：我们总以为缓存淘汰一定要更聪明，结果瓶颈可能在打分器自己。
KV cache 为什么会卡住长推理
自回归 LLM 每生成一个 token，都会保存历史 token 的 key/value，以便后续 token 注意到过去信息。这就是 KV cache。没有缓存，生成会重复计算历史；有缓存，生成速度大幅提升。但长上下文和长 chain-of-thought 会让 KV cache 占用显存快速增长。
长推理尤其麻烦。模型为了解题会生成大量中间步骤，推理 trace 越长，缓存越大。服务端为了多用户吞吐，必须控制显存。最直接的方法是淘汰一部分缓存，只保留“重要”的 token。
过去很多方法都围绕重要性打分：看注意力权重、看最近使用、看特殊 token、看聚类代表性。直觉上这很合理，像操作系统页面置换。但 LLM 长推理不一定符合传统缓存直觉。
Random Attention 的核心观察
论文摘要给出两个关键解释。
第一，prompt 是脆弱部分。题目、约束、输入事实、工具结果通常都在 prompt 或前缀里。如果这些信息被淘汰，模型可能失去任务定义。很多 evictor 的差距，可能主要来自它们是否意外保住了 prompt。
第二，推理 trace 有冗余。模型在思考时会反复重述关键状态，比如“我们需要证明 X”“已经知道 A 和 B”“下一步计算 C”。这意味着后续 token 不一定只依赖某一个精确位置。再加上多头注意力中不同 head 会保留不同副本，随机抽样也可能留下足够信息。
因此，Random Attention 的策略非常简单：始终保留 prompt；对后续推理缓存，在每个 attention head 内均匀随机淘汰。它不计算重要性分数，也不排序。
为什么这有工程意义
很多高明的 evictor 在论文图表里有效，但上线时会被额外开销吃掉收益。你需要收集统计、计算分数、维护数据结构、做排序或选择，还要适配推理引擎。对于高并发服务，这些操作不是免费的。
Random Attention 的吸引力在于它把策略成本压到很低。随机选择可以在内核或调度层更容易实现，也减少了控制逻辑复杂度。如果质量接近强基线，吞吐提升就很现实。
这类结果对 vLLM、SGLang、TensorRT-LLM、llama.cpp server 这类推理系统都有启发：不要只优化保留哪些 token，也要计算“决定保留哪些 token”本身的成本。
一个简化伪代码
下面是思路级伪代码，不是完整高性能实现：
type CacheBlock = {
tokenIndex: number;
isPrompt: boolean;
head: number;
};
export function randomAttentionEvict(blocks: CacheBlock[], keepRatio: number) {
const prompt = blocks.filter((block) => block.isPrompt);
const generated = blocks.filter((block) => !block.isPrompt);
const byHead = new Map<number, CacheBlock[]>();
for (const block of generated) {
const list = byHead.get(block.head) ?? [];
list.push(block);
byHead.set(block.head, list);
}
const kept: CacheBlock[] = [...prompt];
for (const list of byHead.values()) {
const shuffled = [...list].sort(() => Math.random() - 0.5);
const budget = Math.ceil(list.length * keepRatio);
kept.push(...shuffled.slice(0, budget));
}
return kept;
}真实推理引擎不会用上面这种随机排序写法，也不会用对象数组管理缓存。但伪代码表达了重点：prompt 保护是硬约束，后续 trace 按 head 随机保留。
什么时候可能失效
随机淘汰不是免费午餐。第一类风险是事实密集任务。如果输入里有很多一次性事实，而模型后续没有重述，随机淘汰可能丢掉关键证据。
第二类风险是代码和表格。代码行号、变量名、表格单元格关系通常位置敏感，冗余不如自然语言推理 trace 高。简单随机可能破坏精确引用。
第三类风险是工具调用 agent。Agent 的轨迹里有工具返回、错误日志、文件 diff 和权限状态。这些信息不一定会被模型自然重述，不能简单假设 trace 自我保护。
第四类风险是短推理。Random Attention 针对的是长推理缓存瓶颈。如果上下文本来不长，淘汰策略带来的收益有限，额外机制反而增加复杂度。
如何落地评测
上线前应该用自己的任务做四组对比：
baseline: 不压缩 KV cache
strong evictor: 当前生产或论文强基线
random attention: 保护 prompt 后随机淘汰
ablation: 不保护 prompt 的随机淘汰指标不要只看准确率。还要看吞吐、p95 延迟、显存峰值、重试率、输出长度变化和失败样例类型。尤其要比较 ablation，如果不保护 prompt 后质量大幅下降，说明你的任务确实依赖前缀事实，prompt pinning 是必要条件。
还要按任务分桶：数学推理、代码生成、日志分析、RAG 问答、工具调用、多轮对话。Random Attention 很可能在不同桶里表现差异明显。平均分好看不代表适合所有生产流量。
对长推理模型的启发
这篇论文也提醒我们，长推理 trace 并不是纯粹浪费。它虽然消耗 token 和缓存，但也在不断刷新任务状态。模型反复写“现在我们知道什么”，可能让后续推理更鲁棒。过去我们只把这种重复看成冗余成本，Random Attention 则说明冗余也可能是容错机制。
这会影响 prompt 设计。对于需要缓存压缩的长任务，要求模型定期总结状态、显式保留约束，可能比让它写极简推理更适合服务端压缩。换句话说，推理文本的形状会影响 KV cache 策略。
和现有缓存压缩工作的关系
Random Attention 不意味着所有精细 evictor 都没价值。它更像一个强基线审计：任何复杂方法都应该证明自己比“保护 prompt 后随机保留”明显更好，并且扣除计算开销后仍然更好。
这对论文和工程都公平。复杂方法可以在低冗余任务、精确检索任务或多模态上下文里胜出；但如果只在高冗余长推理任务上略微超过随机，却引入大量开销，它的生产价值就要重新计算。
结论
Random Attention 的最大贡献，是把 KV cache 淘汰问题从“怎么精准预测每个 token 的未来重要性”拉回到“哪些信息真的脆弱，哪些信息天然冗余”。如果 prompt 是脆弱核心，而推理 trace 有足够冗余，那么随机策略就不再荒唐。
对推理系统开发者来说，下一步很明确：把保护 prompt 的随机淘汰加入基线，用真实流量做分桶 A/B。如果它在你的长推理场景里接近强 evictor，同时吞吐更高，那就没有必要为复杂打分器付账。工程优化有时不是更聪明，而是找到哪里不需要聪明。