资讯详情

资讯详情

AI推理时突然“想起“最初的问题,却总被系统忘记

你有没有过这样的经历写一篇长文章写到中间突然要回头翻看开头列的提纲确认自己没跑题大语言模型在做复杂推理的时候也会做同样的事情。而这篇论文要讲的就是当AI也需要翻回去看看开头时现有的记忆管理方法为什么会失灵以及研究者们想出了什么办法来解决它。先说清楚这件事有多麻烦。一块GPU撑不住的记忆账单现在的大推理模型比如DeepSeek-R1、Qwen3这些解题的时候都会先生成一长串思考过程业内管这个叫思维链。思维链Chain-of-ThoughtCoTAI在给出最终答案前先像人一样一步步展开推理过程的文本通常长达数千甚至数万个token。这个思考过程越长模型解题能力往往越强但代价也很直接模型每生成一个词都要把之前所有词的信息存起来方便后续计算时参考这部分存储在业内叫KV缓存。KV缓存Key-Value CacheTransformer模型在生成文字时为了避免重复计算把每个已生成词对应的键和值向量存下来后面生成新词时直接调用而不是每次都从头算一遍。这个缓存的问题在于它会随着生成长度线性增长。论文里给了一个具体数字Qwen3-4B模型如果生成32000个token批量大小设为16光是KV缓存就能吃掉77GB显存,而一块常见的A100 GPU总共也就80GB。这意味着模型还没怎么干活显存条已经快被挤爆了。这就好比你租了个仓库存货本来打算慢慢周转结果货物只进不出越堆越多,最后连叉车都开不进去了。为了活下去业内想出的办法是KV缓存压缩说白了就是定期把不重要的存货扔掉只留最关键的部分。问题是怎么判断哪些是不重要的现有方法的赌注赌未来长得像现在目前主流的压缩方法比如RPC和R-KV用的思路都差不多看最近几步生成的词在问什么也就是查询它们的注意力模式根据这个来判断历史信息里哪些该留、哪些该删。这个思路听起来很合理,毕竟最近的行为通常是未来行为最好的预测依据。但论文作者发现了一个致命漏洞:在长篇推理里这个假设经常不成立。具体来说作者观察到一种现象他们给它起了个名字叫思维回溯token。思维回溯tokenThought Revisiting TokensTRT推理过程中某些解码步骤生成的词会突然回头去关注很久以前的内容,比如最开始设定的解题思路或题目约束条件,而不是像大多数词一样只盯着眼前的上下文。论文里给了一个非常具体的案例。研究者分析了R1-Distill-Qwen-7B模型在做AIME24数学题时的注意力分布发现在某一层某个注意力头里位置1066到1092的大多数查询词都专注于附近900到1092范围内的内容,这很正常。但token 1068和1090却反常地把注意力甩向了100到450位置的内容,那正是题目最开始设定的两个场景条件。这就好比你在做一道复杂的数学题算到中间突然停下来翻回第一页确认题目到底问的是什么。这种回头翻页的动作在人类做题时很常见但对于只盯着最近几步在做什么来判断重要性的压缩算法来说这些早被判定为不再需要、已经清空的内容,恰恰是接下来必须用到的。更麻烦的是这种回溯行为不是偶发的巧合,论文统计发现这类全局关注模式会分散出现在模型的多个层和多个注意力头里而不是集中在某一个固定位置。这说明TRT是一种普遍存在、但出现时机不可预测的现象,你永远不知道下一步生成的词是继续埋头计算还是突然要回去翻旧账。如果只靠看最近几步来判断哪些历史信息该保留那些被回溯的关键内容早就被扔了,等真正需要用到的时候它已经不在了。这不是压缩率不够高的问题而是压缩策略从根本上猜错了未来会用到什么。藏在混乱背后的秩序:全局查询会抱团发现问题只是第一步真正让这篇论文站得住脚的是研究者接下来做的一个关键观察。既然无法预知哪一步会突然回头翻旧账那能不能找到一种规律用一个相对固定的、体量不大的东西去代表所有可能出现的回头翻页行为研究者把生成过程中的查询词分成了两类局部查询,那些只盯着附近内容看的正常查询全局查询,也就是产生思维回溯行为的那些查询。他们把这些全局查询在向量空间里的位置画出来用主成分分析降维展示结果发现一个很有意思的现象这些看似分散、随机出现的全局查询并不是杂乱无章地散落各处而是聚集成了少数几个紧密的簇。论文里举的例子是token 1068和1090虽然在时间上相隔了20多步出现的场合、上下文内容都不一样但它们对应的查询向量在几何空间里挨得很近属于同一个簇。这意味着尽管你无法预测下一次回溯会发生在哪一步但这些回溯查询背后所代表的意图类型其实是有限的、可归类的。这就好比一个班里总有几个学生上课容易走神但走神的原因翻来覆去就那么几种:要么想着中午吃什么要么惦记周末的计划。老师不需要盯着每个学生的每一秒动作只需要记住走神通常分这几类就能提前做好应对。基于这个发现研究者提出了这篇论文的核心方案:既然全局查询会抱团那就不用把整个历史查询都存下来只需要为每个簇挑一个代表存住这几个代表就够了。这些代表被称为信标查询。信标查询Beacon Queries从历史生成的所有查询中通过采样算法挑选出的一小批具有代表性的查询向量用来代表所有可能出现的全局关注模式从而在不存储完整历史的情况下预判哪些KV缓存内容未来可能被重新用到。这个方法的名字BeaconKV也是由此而来,beacon本意是灯塔或信标用来指引方向。这些信标查询就像是在漫长推理过程中竖起的几座灯塔,不需要记住路上的每一个脚印只要记住几个关键地标就能大致判断回头看的时候该往哪个方向找。怎么挑出这几个信标:一种叫FPS的采样算法光知道该挑代表还不够怎么挑才科学如果随便挑几个查询当代表效果可能很差,万一挑中的都是长得差不多的局部查询那和什么都不做没区别。研究者用的方法叫最远点采样。最远点采样Farthest Point SamplingFPS一种贪心算法每次都选择离当前已选集合最不像的那个点加入代表集合目的是让最终选出的一小撮代表尽可能覆盖整个数据分布的多样性而不是挤在同一个角落。具体过程是这样的算法先找一个和大家平均相似度最低的查询作为起点然后每一轮都从剩下的查询里挑出那个离当前已选集合最远、也就是最不相似的查询加进来如此反复直到凑够预设的数量。这里有个细节值得说一下:研究者是在RoPE旋转位置编码应用之前的查询向量上做这个相似度计算的。RoPERotary Position Embedding旋转位置编码Transformer里给每个词标注它在句子中位置的一种技术通过旋转向量来编码位置信息。之所以要在RoPE之前算相似度是因为RoPE会给向量叠加位置信息如果直接在带位置信息的向量上算相似度两个内容完全相同但位置不同的查询会被误判成不相似这会干扰对查询本身语义内容的判断。研究者想抓住的是查询在问什么而不是它在哪一步问的。但这里出现了一个新问题:如果每次压缩都要把从头到现在的所有查询拿出来跑一遍FPS计算量会随着推理进行越滚越大尤其是像Qwen3这类采用分组查询注意力GQA架构的模型查询数量本身就多这么做显存开销会失控。于是研究者又设计了一个轻量版本,持续最远点采样。持续最远点采样Continual FPS一种在线算法每个注意力头只维护一个容量有上限的小缓冲区缓冲区装满后就触发一次FPS压缩把它精简回一个更小的规模如此循环避免存储全部历史查询导致的内存爆炸。这个设计的逻辑是填满就压缩压缩再填满缓冲区永远不会无限膨胀,论文用一张图对比了持续FPS和几种理想化的离线方法(比如K均值聚类、朴素FPS)发现持续FPS在准确率上几乎不掉分但峰值显存占用大幅下降。这说明在线、有界的设计并没有牺牲太多效果换来的是可以长期稳定运行的工程可行性。如果不用持续版本会怎样论文里提到朴素FPS(也就是对全部历史查询做一次性采样)虽然效果好但显存消耗明显更高在实际部署时会重新引入内存压力问题,相当于绕了一圈又把最初想解决的麻烦带回来了。这就好比你为了省钱决定自己囤菜结果囤菜用的冰箱比买菜的钱还贵图省事反而更费钱。信标查询怎么用:位置对齐与打分策略有了信标查询接下来的问题是怎么用它们去判断哪些KV缓存该留。这里有个巧妙的设计:信标查询在参与打分计算时会被重新赋予当前解码步骤的位置编码而不是它们原本生成时的位置。这个操作的用意是在模拟一个假设:如果现在这一步真的发生了一次思维回溯它会去关注哪些历史内容通过把信标查询搬到当前位置再让它去和历史KV缓存做注意力计算就能提前预判出哪些内容有被回溯的风险从而优先保留。而与之相对的最近查询则保持它们原本生成时的位置不变用来维持局部连贯性的判断。打分时研究者还做了一个选择:用最大值聚合而不是平均值聚合。这个选择背后的逻辑值得琢磨。思维回溯本身是一种稀疏、偶发的事件,大多数查询都是普通的局部查询只有极少数是全局查询。如果用平均值来聚合所有查询对某个KV缓存位置的关注度那些稀少但重要的全局关注信号会被淹没在大量局部查询的噪音里就像一场大合唱里某个人唱错了关键的高音但因为周围声音太多评委根本听不出来。而最大值聚合的逻辑是,只要有任何一个信标查询认为某个位置重要就把它标记为重要不管其他查询怎么看。论文的消融实验也证实了这一点:在256个token预算这种极端压缩场景下最大值聚合的准确率是23.3%平均值聚合只有18.8%,差了将近5个百分点。效果到底怎么样数字说话说了这么多设计思路实际效果如何研究者在四个开源大推理模型上做了测试:R1-Distill-Qwen-7B、R1-Distill-Llama-8B、Qwen3-4B和Qwen3-14B覆盖了数学(AIME24、MATH-500)、代码(LiveCodeBench)、科学问答(GPQA-Diamond)四类任务。最直观的结果是准确率提升。在Qwen3-14B模型做AIME24任务、最大KV缓存预算只有1024的极端压缩场景下BeaconKV相比现有最好方法准确率提升了31.7个百分点。这是什么概念意味着在同样的显存预算下原来每做3道题只能对1道换成BeaconKV之后可能每做3道题能对接近2道。在效率方面论文用Qwen3-4B、32K生成长度的设定做了对比测试。完整KV缓存(不压缩)的情况下批量大小14时峰值显存就达到77GB几乎逼近A100的显存上限没法再往上加批量。而BeaconKV用2K的缓存预算把峰值显存压到13.3GB相当于降低了5.8倍吞吐量从每秒82.3个token提升到356.4个token提升超过4倍,解码延迟也从5573秒降到1287秒。方法 | 最大KV预算 | 批量大小 | 吞吐量(token/s) | 峰值显存(GB) | LiveCodeBench准确率Full KV | - | 14 | 82.3 | 77.0 | 54.4BeaconKV | 2K | 14 | 356.4 | 13.3 | 51.1RPC | 2K | 192 | 725.4 | 79.0 | 44.8BeaconKV | 2K | 192 | 704.8 | 79.3 | **51.1**RPC | 1K | 320 | 1380.8 | 72.0 | 29.9BeaconKV | 1K | 320 | 1345.9 | 72.5 | **42.2**从表格能看出在同等显存和吞吐量条件下BeaconKV相比RPC的准确率优势非常明显,1K预算场景下准确率从29.9%提升到42.2%超过12个百分点的差距而系统开销几乎持平。这说明BeaconKV不是靠多花资源换来的提升而是真的用更聪明的压缩策略把同样的显存预算用在了刀刃上。研究者还做了一个很有说服力的对照实验用来排除一种简单的解释:也许BeaconKV的提升只是因为它多保留了一开始的内容他们设计了一个叫InitialRecent的对比方法固定保留最开始生成的查询加上最近的查询。结果显示这个方法在多个任务上明显不如BeaconKV,比如在Qwen3-14B上做AIME24BeaconKV是57.92%InitialRecent只有23.75%差距超过34个百分点。这说明关键不在于记住开头而在于持续动态地捕捉推理过程中不断涌现的新的全局关注模式,毕竟推理越往后走需要回溯的内容也在不断变化固定住开头远远不够。信标和最近查询该怎么分配论文里还有一个细致的消融实验探讨了信标查询和最近查询数量的最佳配比。研究者在Qwen3-4B上测试了从(1个最近,31个信标)到(31个最近,1个信标)的多种组合。结果发现两个极端都不理想:信标太多、最近查询太少会牺牲对短期上下文的把握,准确率63.5%但延迟高达10871秒因为过多的信标查询计算负担很重信标太少、几乎只靠最近查询则退化成了传统方法的表现,准确率跌到55.6%。最终发现16个最近加16个信标是最平衡的配置准确率64.6%延迟只有4355.7秒。这个结果说明全局和局部两种信号缺一不可二者需要一个恰当的平衡点而不是简单地越多信标越好。从RPC、SnapKV到BeaconKV这条路是怎么走出来的这篇论文并不是凭空出现的它站在一系列前人工作的基础上。比较早期的KV缓存压缩方法像SnapKV思路是用注意力分数直接判断哪些历史token重要这套思路成为了后来很多方法的基础框架。RPC(Reasoning Path Compression推理路径压缩)则是专门针对大推理模型场景用最近查询的注意力权重给KV缓存打分,这也正是本文批评的对象。同期的R-KV在RPC的基础上额外引入了基于键相似度的冗余度评分尝试从另一个角度去除重复信息。这些方法有一个共同的局限,它们都默认最近的查询能代表未来的需求而BeaconKV这篇论文正是精准地打破了这个假设的普适性。值得一提的是这个方向在这篇论文之后还在继续演化。比如TRIM-KV和LightThinker这类工作选择了另一条路,用小型可训练模块来学习哪些token该保留通过蒸馏或监督微调的方式获得压缩策略。这类方法的好处是可能学到更精细的规律但代价是需要针对特定任务训练泛化能力打了折扣。与之相对BeaconKV走的是完全无需训练的路线直接利用查询向量本身的几何结构这在部署灵活性上是个明显优势,不需要为每个新模型、新任务重新训练一遍。另一条并行的技术路线是稀疏注意力比如SeerAttention-R这类方法用自蒸馏的门控模块来学习稀疏模式同样是为了降低长上下文场景下的计算和显存开销但它们通常保留完整KV缓存在内存里只是减少实际参与计算的部分这和BeaconKV直接删除不重要内容的思路有本质区别。写在后面读完这篇论文最让我意外的地方不是发现了一个问题而是研究者证明这个问题的方式,他们没有停留在直觉上应该存在思维回溯这种猜测而是真的把某个具体样本、具体层、具体注意力头的注意力权重矩阵画出来一个token一个token地指出看1068号和1090号在做和别人不一样的事。这种把抽象现象落到具体像素点上的做法本身就是一种研究态度的示范。另一个让我反复琢磨的细节是全局查询会在几何空间里聚类这个发现。这其实揭示了一个更普遍的道理:很多看似随机、不可预测的行为背后可能都藏着某种低维的结构。人类大脑里分心这件事看似随机但心理学研究早就发现走神的内容往往逃不出几个固定主题,担心的事、期待的事、没做完的事。AI的思维回溯某种程度上也是同样的逻辑,虽然什么时候回头看不可预测但回头看的意图类型是有限的。这种从不可预测的事件里提炼可预测的结构可能是很多复杂系统研究里都通用的一个思路。论文里也坦诚地留了一些没做完的事。它主要在推理任务上验证普通的长文本摘要、检索这类非推理场景效果如何作者自己也说还不够清楚。另外信标查询和最近查询的数量配比、压缩触发的时机目前都是人工设定的固定值如果能做到根据推理进程自适应调整,比如判断当前阶段更容易出现回溯还是更需要局部连贯,应该还有进一步提升的空间。一个AI模型在做题过程中会不会也像人一样有灵光一现突然想起最初那句话的时刻如果有我们又该如何设计系统让它不会因为记性不好而错过那个瞬间QAQ1BeaconKV是什么它解决了什么问题ABeaconKV是一种训练无需的KV缓存压缩方法专门用于降低大推理模型在长思维链推理时的显存占用。它通过维护少量代表性的信标查询来预判哪些历史信息未来可能被重新关注从而避免现有方法因只看最近查询而误删关键内容的问题。Q2什么是思维回溯token为什么现有压缩方法处理不好A思维回溯token指推理过程中突然重新关注很久以前内容(比如最初的题目条件)的特殊生成步骤。现有压缩方法只根据最近生成的查询判断哪些历史内容重要而思维回溯出现时机不可预测容易导致这些方法提前删除了后续实际需要用到的关键信息。Q3BeaconKV相比其他压缩方法效果提升有多大A在Qwen3-14B模型做AIME24任务、缓存预算仅1024的情况下准确率比现有最好方法高出31.7个百分点。在效率上BeaconKV能将峰值显存降低5.8倍吞吐量提升超过4.3倍且在相同资源开销下准确率明显优于RPC等方法。
觉得有用,分享给同行:

为您的企业打造数字门面

稳重轻奢商务风格,端正雅致视觉,长效耐看不易过时。

立即咨询 →