详细解释
Sparse Attention（稀疏注意力） 一句话定义：普通全注意力是「每个 token 看全部 N 个 token」，计算量 N×N 爆炸（4K 上下文=16M 对，128K 上下文=164 亿对算不动）；稀疏注意力是「每个 token 只看它应该看的一小部分 token（比如邻居、全局锚点、分块对角线），其他不看」，精度损失 0-5%，速度和显存直接省 5-20 倍。没有稀疏注意力，现在动辄 128K、1M 的长上下文模型是根本跑不起来的。
稀疏注意力的鼻祖是 2019 年 OpenAI 的 Sparse Transformer 论文（第一个把 Image Transformer 做到 64K 像素级），2020 年谷歌的 Longformer、BigBird 把它做火并普及，2023 年之后 Mistral 7B 用的 Sliding Window Attention（滑窗注意力，稀疏注意力的一个最实用的特例）直接把它变成了 2024 年后所有新模型的标配。当代主流长上下文模型（GPT-4o 128K、Claude 3 200K、Qwen 2.5 128K、Llama 3 128K）全部内置了某种形式的稀疏注意力，区别只是稀疏模式不同。
唯元智创 的长上下文推理引擎默认对 32K 以上请求自动切换「稀疏模式」——自动根据上下文长度在「全注意力（< 8K）→ 滑窗稀疏（8K-64K）→ 分块+全局锚点稀疏（64K-1M）」之间动态切换，业务方不需要改任何代码，也不用关心稀疏模式怎么选，P95 推理延迟比全开全注意力省 60% 以上。
五种主流稀疏注意力模式对比（2025 年生产环境选哪个）
| 稀疏模式 | 每个 token 看哪些 token | 复杂度 | 典型实现模型 | 精度损失（相对全注意力） | 最适合场景 |
|---|---|---|---|---|---|
| ① 滑窗窗口（Sliding Window / Local） | 只看左边 W 个邻居 + 自己（W=4096 常见） | O(N·W) ≈ O(N) | Mistral 7B/8x7B, Llama 3.1 128K | <1% | 绝大多数日常场景；对话、代码、RAG 召回的 chunk 都是局部的 |
| ② 分块全局稀疏（Block + Global Tokens / Longformer） | 分块看块内 + 看 5-20 个全局锚点 token（CLS、任务指令等） | O(N·√N) ≈ O(N) | Longformer, BigBird, LED | 1-3% | 长文档分类、摘要、需要全局开头结尾信息的任务 |
| ③ 跨步/扩张模式（Dilated / Strided / Axial） | 看邻居 + 每隔 stride 个 token 看一个远程的 | O(N·(W + N/stride)) | Sparse Transformer, Image GPT | 2-5% | 图像、音频、DNA 序列等有空间周期性的模态 |
| ④ 基于路由的动态稀疏（Dynamic / FlashAttention-2 Block-sparse） | 不固定模式，按 query 计算 top-k 最相关 key 只看这 k 个 | O(N·K)，K=128/256 | FlashAttention v2 原生支持、LongNet | 0.5-2% | 需要保留远程精准召回的科学文献、法律合同 |
| ⑤ 层次化稀疏（Hierarchical / Block-recurrent / RWKV 风格） | Transformer 分块 + 在块之间跑 RNN 传递状态，跨块只看状态不看全部 token | O(N) 严格线性 | RWKV, Mamba (SSM 家族)、Block-Recurrent Transformer | 3-8% | 百万级超超长上下文、流式日志、整本书阅读 |
工程落地 Sparse Attention 的四个关键注意点
注意 1：不同稀疏模式要和你的下游任务「注意力真实分布」吻合，否则稀疏 10% 精度掉 30%。稀疏注意力的本质是「牺牲掉不需要看的那些注意力对，保留需要看的」。举反例：你用滑窗 W=4096 做「10 万字合同最后一页问第一页的签约日期」——滑窗只能看最近 4K token，签约日期在第 1 个 token，根本看不到，召回直接 0%，这种必须要「全局锚点 token 模式」。正确做法是上线前先拿 100 条你下游任务的典型样本，在全注意力模型上跑一遍画出「真实注意力热力图分布」：如果 99% 的注意力权重都集中在附近 ±2K 窗口内，选滑窗即可；如果有 10% 注意力跳转到开头结尾，选全局锚点；如果有大量精准远程跳转，选动态路由稀疏。
注意 2：滑窗 SWA（Mistral 模式）不是越大越好，4K 是甜点。 很多团队贪心设 W=16K 以为越大越好，结果显存翻了 4 倍、速度慢 3 倍，而精度只涨了 0.2%。工业界经验：在大多数中英文综合任务上，W=4096 时已经覆盖了 95% 的真实注意力权重分布（绝大多数 token 只看最近 2-3K 个邻居），再往大了调边际效益递减极快。经验比例：滑窗 2K→4K 精度 +2.5%，4K→8K +0.7%，8K→16K +0.3%，16K→32K +0.1%，够了就停。
注意 3：KV Cache + 稀疏注意力组合时，推理引擎必须做「缓存分块对齐」，否则稀疏省下来的时间全被缓存管理吃了。 全注意力的 KV Cache 是连续的，O(1) 访问；滑窗稀疏的 KV Cache 是环形队列，只保留最近 W 个 token 的 K/V，超了直接覆盖最老的，这块如果推理引擎（vLLM/SGLang）没做优化，会频繁做内存 copy 导致整体延迟反而比全注意力还高。所以选稀疏不要自己写，直接用推理引擎内置的（vLLM 0.3.6+ 原生支持 Sliding Window Attention，不用改一行代码，开模型配置里 sliding_window 参数就行）。
注意 4：稀疏注意力是「注意力机制内部的稀疏」，和「检索增强 RAG 是外部稀疏」是互补关系，不要搞二选一。 很多初学者问「我有了 128K 稀疏注意力是不是就不需要 RAG 了？」。不是！128K 稀疏注意力的成本是每次输入全部 128K token 花一次钱（200 万 token 输入一次 ¥0.2-0.5），而 RAG 只花 2-4K token 输入（¥0.002-0.005），成本差 100 倍。正确的组合拳是：超长文档（整本书、1000 份合同）先用稀疏 RAG / Graph RAG 做外部粗筛，召回 Top-20 chunk，压缩到 32K token 以内，再喂给带稀疏注意力的 LLM 做深度阅读和推理。两者配合而不是替代。