滑动窗口 · Gemma 与 GPT-OSS 的局部注意力 · AI 大模型解构

省 KV 缓存的另一条路——不压缩每个 token 的缓存，而是干脆让每个 token 只看附近一个窗口。看 Gemma 3 的局部/全局 5:1 交错、GPT-OSS 的隔层滑窗，以及 Mistral 为什么又把它去掉了。

滑动窗口 · Gemma 与 GPT-OSS 的局部注意力

上一章的 MHA→GQA→MLA，压的是「每个 token 的 KV 缓存有多大」。这一章讲一条正交的省法：不动单个 token 的缓存，而是减少要缓存的 token 数——让每个位置只看附近一个固定窗口里的 token，窗口外的一律不看、也不必缓存。

这就是滑动窗口注意力(Sliding Window Attention， SWA)。

全局注意力的两笔账

标准（全局）注意力，每个 token 要看前面所有 token。这带来两笔开销：

计算：一段长度 $T$ 的序列，注意力矩阵是 $T \times T$ ，开销随 $T$ 平方增长。上下文拉到 128K，这笔账很吓人。
KV 缓存：要缓存全部 $T$ 个历史 token 的 K/V，缓存随 $T$ 线性增长——正是上一章反复念叨的显存杀手。

滑动窗口的主意特别朴素：大部分时候，一个词的意思由它附近的词决定，未必要盯着几万字之外。 那就只让每个 token 看最近的 $W$ 个（比如 $W=1024$ 或 $4096$ ）。于是：

注意力矩阵从 $T \times T$ 变成 $T \times W$ ， $W$ 是常数——计算随长度线性增长，不再平方。
KV 缓存封顶在 $W$ ，不管上下文多长，只留最近一窗——显存不再随上下文疯涨。

这个思路不新。早期的 Sparse Transformer(Child et al.， 2019)和 Longformer(Beltagy et al.， 2020)就用局部 + 少量全局的稀疏模式处理长文档。真正把它带进主流开源 LLM 的，是 Mistral 7B(2023)：它用了 $W=4096$ 的滑动窗口。

但纯局部有个硬伤：远处怎么办

如果每一层都只看附近，那么相距很远的两个 token，岂不是永远碰不上面？

不完全是——信息可以「逐层接力」传得更远。第 1 层里，位置 $i$ 看到 $[i-W, i]$ ；到第 2 层， $i$ 看的那些邻居又各自看过它们的邻居……叠 $L$ 层滑窗，有效感受野能扩到约 $L \times W$ 。就像消息在人群里一层层口耳相传，虽然没人能直接喊到很远，但传够多层也能传到。

可「接力」终究不如「直达」：要精确用到很远处的某个信息（比如开头定义的一个术语），纯局部模型会吃力。于是现代模型的解法不是「非黑即白」，而是「局部为主、全局点缀」——大多数层用便宜的滑窗，隔一段插一层全局层，给远程依赖留一条直达通道。

各家的配方：比例与窗口

下面这些数字会随版本变动，记比例逻辑比记具体值更重要：滑窗层越多越省，全局层越多越能抓远程依赖，各家在这条线上取不同的点。

模型	滑窗：全局	窗口大小	说明
Mistral 7B(2023)	全部滑窗	4096	早期激进方案，整模型滑窗
Gemma 2(2024)	1 ： 1 交替	4096	一层滑窗一层全局
Gemma 3(2025)	5 : 1	1024	更省：5 层滑窗才配 1 层全局，窗口还缩到 1024；消融显示对质量「几乎无影响」
GPT-OSS(2025)	隔层(≈1:1)	——	每隔一层用滑窗

Gemma 3 是把「省」推得最狠的：窗口从 Gemma 2 的 4096 砍到 1024，全局层的比例从 1/2 降到 1/6。据其技术报告，如此激进地削减全局注意力，建模质量几乎没掉——这说明「大部分注意力其实是局部的」这个假设，在实践中相当成立。

反转：Mistral 又把它去掉了

有意思的是，Mistral Small 3.1(2025)反而把滑动窗口关掉了（配置里 "sliding_window": null），退回普通 GQA 全局注意力。

为什么开创者反悔了？这是个很好的「工程 vs 理论」案例：

滑动窗口在理论上省显存、省计算；
但它给推理实现添了复杂度。而这些年，FlashAttention 这类底层内核把标准（含 GQA）注意力优化得极好、生态极成熟；滑窗要吃到同等优化，得额外费劲。
对 Mistral Small 这种「以低延迟为首要目标、层数本就不多」的模型，用成熟高效的 GQA 全局注意力，反而比自找麻烦的滑窗更划算。

这个反转的启示很实在：架构选择从来不是「哪个理论上更优」，而是「在我的目标（延迟？显存？上下文长度？）和现有工具链下，哪个综合最划算」。 同一个滑动窗口，Gemma 觉得值、Mistral 觉得不值——因为它俩要的东西不一样。

小结：两种省法，正交互补

到这里，「省 KV 缓存」这条主线的两种思路就凑齐了：

压缩每个 token 的缓存：MHA→GQA→MLA（上一章）。
减少要缓存的 token 数：滑动窗口（本章）。

两者正交，可以叠加——一个模型完全可以「GQA + 滑动窗口」一起上（Gemma、GPT-OSS 就是）。它们共同回答了这一代大模型最要命的一个工程问题：怎么让又长又便宜的推理成为可能。

省完了显存，下一条主线是省计算——当参数堆到几百上千亿，怎么不让每一步都把全部参数算一遍？答案是把前馈层稀疏化，也就是MoE。这是下一站，也是和注意力并列的另一个主战场。👉 稠密 vs 稀疏：MoE 为什么突然统治了大模型

参考文献

[1] Child et al. “Generating Long Sequences with Sparse Transformers.” 2019. arXiv:1904.10509. —— 稀疏（含局部）注意力。
[2] Beltagy et al. “Longformer: The Long-Document Transformer.” 2020. arXiv:2004.05150. —— 局部 + 全局注意力模式。
[3] Jiang et al. “Mistral 7B.” 2023. arXiv:2310.06825. —— 把滑动窗口带入主流开源 LLM。
[4] Gemma Team, Google DeepMind. “Gemma 2: Improving Open Language Models at a Practical Size.” 2024. arXiv:2408.00118. —— 局部/全局交错注意力。
[5] Dao et al. “FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness.” NeurIPS 2022. arXiv:2205.14135. —— 让标准注意力极致高效的底层内核，是 Mistral 弃用滑窗的背景。

滑动窗口 · Gemma 与 GPT-OSS 的局部注意力