北京
一个模型在生成每个token时，都要把整个KV缓存（键值缓存）从头到尾读一遍，哪怕它最终只用到其中极小的一部分。如果你在一段100万token的对话里问某个细节，全局注意力层会在每一步生成时，把整段对话重新读一遍。
这是Google DeepMind和合作者最近一篇论文里指出的问题。论文标题是《Declarative Attention》，核心思路很直接：与其让模型每次都猜哪些token相关，不如让它自己声明要看哪里。
传统做法的成本卡在O(N)
通常的解决办法是先用廉价的代理分数（proxy scores）预筛出相关token，但这一步本身每一步仍然要付出O(N)的计算成本——N是上下文长度。也就是说，上下文越长，每一步的开销就越大，这个瓶颈始终绕不开。
Declarative Attention换了个思路：不再靠外部机制去猜，而是让模型在自己的思维链（chain-of-thought）内部，直接声明它接下来需要查看哪个区域。推理引擎解析这些声明的方式，和解析工具调用（tool calls）的方式是一样的，然后跳过大部分缓存读取。
三种读取模式：全局、聚焦、局部
按照这个设计，生成过程被拆成三种模式：
- 全局模式（global）：读取完整上下文，用于需要整体把握的场景；
- 聚焦模式（focus）：只读取模型指定的某个具体区域；
- 局部模式（local）：只读取最近生成的输出。
模型在思维链里声明自己处于哪种模式、要看哪个位置，推理引擎据此跳过无关的缓存读取。这相当于把"注意力范围"这件事，从隐式的计算过程变成了模型可以显式控制的动作。
零样本测试：注意力读取量下降明显
论文给出的实验数据来自零样本（zero-shot）设置，直接使用现成的模型权重，没有针对新方法做额外微调。在15个长上下文任务上，解码过程中实际被读取的token数量出现了明显下降：
- Gemma-4-31B模型：下降52.0%
- Qwen-3.6-27B模型：下降31.1%
这个数字意味着，在长上下文场景下，模型生成每个token时实际需要读取的缓存数据量，可以减少一半左右。对于推理成本随上下文长度线性增长的现状来说，这是一个值得关注的优化方向。
为什么这件事值得留意
长上下文模型的使用成本，很大一部分就消耗在"每步都读全部缓存"这件事上。用户问一个细节，模型却要把整段历史都过一遍，这在算力上是一种浪费。Declarative Attention把"看哪里"的决定权交给模型自己，让注意力读取从全量扫描变成按需取用。
当然，这篇论文目前还只是提出了方法并给出了初步实验结果。模型在思维链中声明注意力范围，是否会在复杂推理任务中引入新的误差，以及这种声明机制在不同模型架构上的泛化表现如何，都还需要更多验证。但至少，它给长上下文推理成本这个老大难问题，提供了一个新的解题角度。
论文已发布在arXiv上（编号2609.02737），感兴趣的话可以直接去看完整内容。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
