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

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

- 作者：David（道雾轩）
- 专栏：AI 大模型解构（https://daiw.org/manual/llm-anatomy.md）
- 最后更新：2026-07-13
- 原文：https://daiw.org/manual/llm-anatomy/sliding-window
- 转载与引用：请注明出处并附原文链接（https://daiw.org/about/copyright）

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

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

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

## 全局注意力的两笔账

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

1. **计算**：一段长度 $T$ 的序列，注意力矩阵是 $T \times T$，开销随 $T$ **平方**增长。上下文拉到 128K，这笔账很吓人。
2. **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$。就像消息在人群里一层层口耳相传，虽然没人能直接喊到很远，但传够多层也能传到。

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

## 各家的配方：比例与窗口

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

| 模型 | 滑窗 ： 全局 | 窗口大小 | 说明 |
| --- | --- | --- | --- |
| **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 为什么突然统治了大模型](https://daiw.org/manual/llm-anatomy/moe-dense-vs-sparse)

## 参考文献

- [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 弃用滑窗的背景。