看到"支持超长上下文"的宣传时，值得多问一句：大模型是真的把全文算了一遍，还是用了滑窗注意力这类近似方案。这个区别直接影响两件事——算力花得多不多，以及相距很远的两处信息能不能被准确关联。这篇把滑窗注意力的机制讲清楚：账是怎么从平方级压回线性的，省下的算力换来了什么代价，哪些任务要当心。
平方增长的账怎么算
标准注意力机制里，每个字都要和其他所有字算一遍关联度。文本翻一倍，字与字的组合大约翻四倍，这就是平方级增长。十万字的文档按平方级算，开销约为万字文档的一百倍。长文本贵、慢、显存占用高，根源都在这条曲线上。注意区分另一个变量：模型参数量说的是模型本身有多大，注意力计算量说的是读一篇长文有多贵，两者常被混在一起谈，其实是两条独立的账。
滑窗只算附近一段
滑窗的做法是把"看全文"改成"看附近一段"。设定一个固定大小的窗口，处理第 N 个字时，只让它和窗口范围内的字计算关联，窗口之外一概不算。举例来说，窗口设 4096，处理第 10000 个字时，它只关注前面窗口内的那一段。这样计算量随文本长度线性增长：文本翻倍，计算量也只翻倍，账就从平方级压回了线性。
用"进来—发生—出去"描述一遍：进来的是当前字和窗口内的邻居，发生的是一次小范围的注意力计算，出去的是融合了邻居信息的新表示。每个字都走一遍这个流程，整篇就处理完了。窗口大小是设计参数，不同模型取值不同，具体以模型官方说明为准。
远处的信息怎么补回来
只看附近意味着第 1 个字和第 100 万个字之间没有直接关联。常见的弥补方式是叠加多层：第一层每个字只看到邻近窗口，第二层看到的"邻近"已经带着第一层传过来的更远信息，像消息在人群里一层层传，层数堆够，远处信息可以间接抵达。
但"传话"这个比喻有失效的地方：传的人越多，失真越重。滑窗结构对"跨越很远的两处信息做精确关联"的任务，表现通常打折——比如小说开头的伏笔和十几万字外的呼应，靠层层传话能不能传准，要看层数和实现。这也是为什么有的模型只在部分层用滑窗、关键层保留全注意力的混合设计，在省算力和保精度之间取平衡。
它和稀疏注意力的关系
稀疏注意力是个更大的类别：不把所有字对全算一遍，只挑一部分来算。挑法有很多——滑窗按位置挑，还有按内容相关性挑、分块挑、加全局节点挑。滑窗是其中最直观的一种切法。判断一个长文本模型省在哪里，问的其实是它挑哪部分不算、代价转嫁到了哪类任务上。
什么任务会踩坑
| 任务类型 | 表现与原因 | 处理建议 |
|---|---|---|
| 概括单篇长文主旨 | 主旨信息局部就有，够用 | 放心用 |
| 长文档里找跨章节矛盾 | 两处相隔远，靠多层传递，可能失真 | 结论回原文核对 |
| 代码库级跨文件分析 | 依赖关系常跨很远 | 分文件处理再汇总更稳 |
| 超长对话多轮追问 | 早期消息可能已滑出有效关联 | 关键前提每隔几轮重申一次 |
这张表的用法：拿到任务先判断信息分布——局部信息就够了，还是必须全局精确关联。
三条判断标准
第一，看任务的信息局部性。摘要、改写、翻译这类信息局部性强的任务适合滑窗类模型；跨章对照、长代码依赖这类全局一致性强的事，分段处理再拼合更稳。第二，算力省下来会体现在价格和生成速度上，同样的预算能处理更长的文本，速度与输出节奏的关系可以看每秒输出多少 token一篇。第三，免费版和付费版大模型的差别里，上下文长度和精度策略往往不同，选之前先想清楚你的任务要不要全精度。另外别混淆两种省法：模型量化压缩的是模型本身，滑窗压缩的是计算过程，两者可以同时存在。
三个补充问题
问：滑窗和检索增强是一回事吗？答：两者不同。检索增强是把需要的资料先检索出来放进上下文，滑窗是模型内部计算时的省算技巧，两者可以在同一个系统里同时出现。
问：窗口越大越好吗？答：不一定。窗口越大越接近全注意力，算力开销也越大，模型方会权衡后选择，用户感知到的是价格和速度的差异。
问：怎么知道自己用的模型用了滑窗？答：查官方技术报告或说明文档，普通产品页一般不写这类实现细节。
滑窗注意力速查
- 标准注意力随长度平方增长，滑窗只算附近窗口，压回线性
- 远处信息靠多层传递，传得越远失真越重
- 局部性强的任务放心用，跨章对照类分段处理更稳
- 窗口大小与混合结构以模型官方说明为准
