稀疏注意力分类学：读什么、不读什么、以及为什么读得少不等于存得少

稀疏注意力方法有十几个名字——Sliding Window、Longformer、StreamingLLM、Vegas、NSA、H2O、CSA、Linformer——但它们都在回答同一个问题：对于当前 query，全量 KV 中哪些真正值得算注意力？本文按决策时机将稀疏注意力分为三条路线：计算前固定模式、计算中动态选择、先压缩再近似计算。每条路线的取舍不同，但共享同一个被普遍忽视的约束——读得少不等于存得少。

一、注意力为什么需要「稀疏」？

一个 128K 上下文的请求，单次 decode 需要为当前唯一的 query token 计算 128K 次 QK 内积。compute 本身不是唯一的瓶颈——把 128K 个 token 的 K 和 V 从 HBM 搬进 SM 才是。以 70B 模型为例，128K token 的 KV 总量约 40 GB，H100 的 HBM 带宽约 3.35 TB/s，仅 KV 读取就需要 ~12ms。而一个 decode step 的目标延迟通常在 10–20ms 以内——KV 读取一项就几乎吃掉了全部预算。

1.1 全量 attention 的不可持续性

这个数字随着上下文长度线性恶化。256K 上下文下，KV 读取吃掉 ~24ms，已经超过单个 decode step 的延迟目标。百万级上下文下，单靠 HBM 带宽根本无法在一个 step 内读完所有 KV。不是「要不要优化」的问题，而是「不优化的 decode 根本跑不动」。

1.2 稀疏的直觉：大多数 token 的注意力权重趋近于零

即使所有 KV 都被搬进 SM，绝大多数 token 对当前 query 的注意力权重也接近于零——真正承载信息的 token 只占全量 KV 的一小部分。稀疏注意力的核心直觉是：如果你能提前知道哪些 token 的注意力权重会最高，你只需要为那部分计算精确注意力，其余的可以直接跳过。

但这引出了一个悖论：注意力权重需要计算了才知道，而稀疏注意力的目的就是不计算。所有稀疏注意力方法被迫回答同一个问题：在计算之前，如何决定哪些 token 值得算？

1.3 一个决定时机，三种答案

按决策时机，业界给出了三种答案。这个分类本身就是本文的核心框架：

决策时机	路线	代表方法
计算开始前就已确定	固定模式	Sliding Window、Longformer、BigBird
计算过程中根据数据决定	动态选择	StreamingLLM、Vegas、NSA/DSA、H2O
不选了，改计算方式	压缩近似	CSA、HCA、Linformer

三条路线不是等级递进的——它们适合不同的约束条件和任务类型。关键区别在于：决策越早，开销越低，但越不懂内容；决策越晚，选择越精确，但决策本身的开销越接近完整的 attention。

二、固定模式：在看数据之前就画好地图

固定模式是最古老的稀疏注意力路线。在任何一个 token 被处理之前，注意力能「看到」的范围已经被确定——与序列的具体内容无关。

2.1 滑动窗口：只读最近的 W 个

滑动窗口是最简单的稀疏注意力：每个 token 只 attend 到它前面的 W 个 token。W 通常设置为 4096 或 8192。决策完全由位置距离决定，与序列内容无关。

优势：计算复杂度从 O(n²) 降到 O(nW)，显存占用从 O(n) 降到 O(W)——KV cache 只需保留最近 W 个 token，其余既不算也不存。滑动窗口是所有稀疏注意力方法中唯一既省计算又省存储的方案。

局限：一刀切地剥夺了所有长程注意力的可能性。长文档中跨段落的引用、代码中远程函数的依赖——全部丢失。更致命的发现来自 StreamingLLM 论文¹：仅保留最近 W 个 token（不给注意力提供数值锚点）会导致注意力的数值稳定性崩溃——输出在超过预训练长度后呈断崖式退化。这一现象的数学根源已在 KV Cache 淘汰策略 §3 中详细展开，此处不再重复。

vLLM 支持状态：支持滑动窗口模型（如 Mistral、Gemma 2），通过模型 config 中的 sliding_window 参数配置——这是训练时决定的架构特性，非运行时通用选项。FlashAttention 和 FlashMLA 后端原生支持滑动窗口掩码，不产生额外开销。

2.2 结构化稀疏：固定模式的工程化升级

Longformer² 和 BigBird³ 在滑动窗口之上叠加了额外的固定注意力通道，试图在保持 O(n) 复杂度的同时恢复部分长程能力：

Longformer：滑动窗口 + 膨胀窗口（间隔采样的全局视野）+ 全局 token（CLS、SEP 等特殊 token 对所有位置可见，也对所有位置可被 attend）
BigBird：滑动窗口 + 随机注意力（随机选出一些 token 作为全局 token）+ 固定全局 token

膨胀窗口和随机注意力为长程依赖提供了结构化的通道，但它们的选择仍然与序列内容无关——全局 token 的类型是固定设计的，随机 token 是真正随机的，膨胀窗口的采样间隔是预设常数。

优势：比纯滑动窗口好得多的长程能力，复杂度保持 O(n)。局限：需要训练时支持——预训练模型无法直接使用 Longformer 的注意力模式，必须从头训练或专门微调。vLLM 支持状态：当前无原生支持。这两种方法的注意力掩码模式不是标准的因果掩码，需要自定义 attention kernel。

2.3 固定模式的共同取舍

固定模式的核心优势是零决策开销——模式在计算前已确定，没有任何动态判断消耗计算资源。代价是完全不懂内容——一个代码文件和一个财经文本，注意力焦点应该完全不同，但固定模式无视这种差异。

更根本的局限在于显存：只有纯滑动窗口同时省了存储——因为它只需要保留最近 W 个 token 的 KV。Longformer 和 BigBird 的额外通道（全局 token、随机 token）需要访问全序列的 KV，所以仍然需要全量存储。即使是固定模式内部，读得少也不一定存得少。

三、动态选择：让数据自己说话

动态选择路线回答固定模式的盲区：不看数据就决定读哪儿，怎么可能精确？它的策略是——先扫一眼数据（轻量扫描），再根据扫描结果决定读哪里（选出 top-k），最后只对 top-k 做完整的注意力计算。

3.1 通用框架：扫描 → 选择 → 精确计算

所有动态选择方法遵循同一个三步模板：

扫描阶段：用极低代价对所有候选 token 做一次粗糙打分。不需要完整的 QK^T + SoftMax——可以是简化的内积计算、历史累积分数的查询、或专用 Indexer 模块的轻量前向
选择阶段：根据扫描结果选出分数最高的 k 个 token
精确计算阶段：只对这 k 个 token 做完整的注意力计算

每一步在「扫描精度」和「扫描开销」之间存在权衡。扫描越精确，选出的 top-k 越接近真实的全量注意力 top-k；但扫描本身越接近完整的 attention 计算——极端情况下扫描 = 全量 attention，稀疏退化回密集。

3.2 StreamingLLM：位置规则中的动态发现

StreamingLLM¹ 的核心策略是固定的：保留前 4 个 token（Attention Sink）+ 最近 W 个 token。在本文的分类体系中，它处于固定模式和动态选择的边界上——执行是固定的位置规则，但规则的来源是动态的数据洞察（对注意力分布的观测发现了 Sink 现象）。

StreamingLLM 的独特价值在于：它不需要轻量扫描。因为选择规则完全基于位置，决策开销为零——这是它作为固定模式实现的动态选择洞察。关于 Sink 的数学机制和 StreamingLLM 的工程细节，参见 KV Cache 淘汰策略 §3–§4.1。

3.3 Vegas：累积注意力分数的动态窗口

Vegas 将「选哪些 token」从固定位置规则变为动态分数规则：维护每个 KV token 的累积注意力分数——所有历史 decode step 中该 token 被分配的注意力权重之和——每步选出累积分数最高的 top-k 个 token 参与注意力计算。

与 StreamingLLM 的关键区别：Vegas 的 top-k 不固定于序列末尾。如果某个中间 token 在过去的 decode 中被反复关注，它可以跨越几百个 token 的距离，持续留在 top-k 中。这使 Vegas 具备 StreamingLLM 不具备的长程 memory 保留能力。

代价：需要为每个 token 维护一个累积分数，每步更新 top-k 个最活跃 token 的分数。在大并发、长序列下，分数 tracking 的元数据存储和更新开销不可忽视。分数的降级（FP32 → FP16 → INT8）和更新频率（每步 vs 每 N 步）是工程落地的关键调优点。

vLLM 支持状态：RFC #47351 提案阶段，尚未合入主分支。

3.4 NSA/DSA：专用 Indexer 的高精度扫描

NSA（Native Sparse Attention）/ DSA 是 DeepSeek 的稀疏选择技术，在 V3.2 中首次引入：在 MLA 框架内增加一个轻量级的 Indexer 模块。Indexer 是一个专门训练的注意力子网络——在完整的 MLA decode 之前，对所有历史 token 做一次廉价扫描（远少于完整 QK^T 的计算量），筛选出 top-k 个候选位置，仅对这些位置执行完整的 MLA decode。DSA 在 V4 中继续使用，但应用对象从原始 KV 变为压缩后的 KV（见 §4.3）。

Indexer 与 Vegas 的累积分数有本质区别：Indexer 是当前 query 驱动的实时打分——它根据当前 query 的内容判断哪些 token 可能相关。Vegas 的累积分数是历史驱动的统计打分——它根据过去被关注的频率判断哪些 token 重要。前者的扫描更精确（专为当前 query 定制），但扫描计算量更大；后者的扫描更廉价（只是查表和排序），但可能错过从未被关注但当前 query 恰好需要的 token。

vLLM 支持状态：DeepSeek V3.2 / GLM-5 的 Sparse MLA 后端已支持（FLASHMLA_SPARSE、FLASHINFER_MLA_SPARSE）。Indexer 模块位于 vllm/model_executor/layers/sparse_attn_indexer.py。关于 Indexer 与 MLA 的集成细节，参见注意力机制演进与 vLLM 支持全景 §4。

3.5 H2O：一个边界案例

H2O⁴ 在本文的分类框架中是动态选择路线上的一个边界案例。它的核心机制——累积注意力分数 → 选出 Heavy Hitter——与 Vegas 高度相似。但 H2O 的原始动机是「永久删除哪些 KV」（eviction），而非「跳过哪些 KV 不读」（稀疏注意力）。

这个边界案例恰好暴露了动态选择路线的一个深层性质：用注意力分数做选择（读哪些）和做淘汰（删哪些），底层评分基础设施完全相同——区别仅在阈值和执行动作。 这一洞察在稀疏注意力 × KV Cache Offloading §4.4 中有更详细的展开。关于 H2O 的次模函数最优性保证和工程实现，参见 KV Cache 淘汰策略 §4.2。

3.6 动态选择的共同取舍

决策开销不可忽略：Indexer 的前向、累积分数的追踪和排序、top-k 的更新——每一步都有计算成本。在较短上下文（< 32K）下，扫描开销可能吃掉全部稀疏收益。
选择质量远优于固定模式：因为看了数据，且是 query 驱动的实时数据（NSA/DSA）或历史驱动的统计数据（Vegas），选出的 top-k 更接近真实的注意力分布。
存储不减少：动态选择只决定「读哪些 KV」，不决定「存哪些 KV」——全量 KV 仍然需要保存在显存中，因为每步的轻量扫描需要遍历全量 KV。这里是「读得少 ≠ 存得少」的第一个关键显现：动态选择的稀疏注意力省了计算（读的数据量少了），但省不了存储（为了扫描，全量 KV 都必须在 GPU 上可见）。

四、压缩近似：不选了，换一种计算方式

动态选择无论如何优化扫描，扫描和选择的组合开销始终存在。第三条路线放弃「选哪些」这个问题本身：不选了，而是将全量 KV 压缩为一个更小的表示，只用压缩后的表示做注意力计算。

4.1 核心思路：用压缩替代选择

与其从 n 个 KV token 中选出 k 个做精确计算，不如将 n 个 KV token 压缩为 k 个「虚拟 token」——每个虚拟 token 是多个真实 token 的 K 和 V 的加权组合——然后对这 k 个虚拟 token 做注意力。关键洞察：过程中没有「丢掉」任何 token 的信息，每个原始 token 的 K 和 V 都通过压缩参与了虚拟 token 的构造。这是压缩近似与动态选择最根本的哲学差异。

4.2 Linformer：线性复杂度的理论先驱

Linformer⁵ 用两个可学习的投影矩阵 E 和 F（形状为 n × k，k ≪ n）将 K 和 V 从 n × d 投影到 k × d。投影矩阵在训练时学习，推理时固定。注意力复杂度从 O(n²) 降到 O(nk)——k 是常数，线性于 n。

优势：首次在理论上证明了线性复杂度自注意力的可行性。局限：投影矩阵大小与序列长度 n 绑定——训练时用 n=512 的 k，推理时扩展到 n=128K，投影矩阵需要重新训练。这使 Linformer 在长度泛化上几乎是不可用的，但它开创了压缩近似这条路线的理论基础。

vLLM 支持状态：无。

4.3 CSA/HCA：DeepSeek V4 的压缩-选择混合系统

CSA（Compressed Sparse Attention）和 HCA（Heavy Compressed Attention）代表了压缩近似路线的当前工程巅峰。两者共同构成了 DeepSeek V4 的注意力系统。

CSA（c4a 层，30 层）：先将 KV 做 4× 压缩（每 4 个连续 token 的 K 和 V 压缩为 1 个），然后对压缩后的 token 应用 DSA 选出 top-512 做注意力。CSA 同时做了压缩（c4a 将 n 缩小到 n/4）和动态选择（DSA 从 n/4 中再选 top-512）。CSA 的名字本身就说明了这一点：Compressed（压缩）+ Sparse Attention（稀疏注意力，即 DSA）。原始 token 数：250K → 压缩后：~62.5K → DSA 选择后：512 个压缩 token。计算量相对全量注意力节省约 1500×。

HCA（c128a 层，30 层）：压缩更激进（128×），1M token 压缩后仅约 8K 条目。因为压缩后的条目数已足够少，HCA 不做稀疏选择——对这 8K 个压缩 token 直接做全量注意力。计算量相对全量注意力节省约 128×。

CSA 和 HCA 的分工：CSA 负责「检索」——在 4× 压缩的粗粒度表示上做 top-512 的精确选择，定位关键信息的位置。HCA 负责「整合」——在 128× 压缩的极粗粒度表示上做全量注意力，获得全局上下文。两层各有 30 个 transformer layer，交替排布。

关于 CSA/HCA 的完整架构演进——它们如何从 V2 的 MLA、V3.2 的 NSA 逐步演化而来——参见 DeepSeek 注意力架构进化：从 MLA 到 CSA/HCA。本节仅聚焦于 CSA/HCA 在稀疏注意力分类框架中的位置：它们代表了压缩近似的工程成熟形态。

4.4 压缩近似的共同取舍

信息保存完整：与动态选择不同，压缩近似不会「丢掉」任何 token 的信息——每个原始 token 都通过压缩参与了虚拟 token 的构造。压缩的代价是细微差异被抹平，而非信息被丢弃。
压缩损失不可逆：4× 压缩意味着 4 个 token 的细微差异在压缩后不可区分——对于需要精确 token 定位的任务，这个损失可能被放大。
存储可减少（但当前实现不减少）：从理论上，如果模型在训练时以压缩格式存储 KV（即不存储原始 K/V，只存储压缩后的 K/V），推理时的存储量将成倍降低。但 CSA/HCA 的当前 vLLM 实现仍然全量存储原始 KV——压缩只在计算时发生，不在存储时发生。这是「读得少 ≠ 存得少」的第二个、也是最典型的显现。
训练耦合：压缩策略（4× vs 128×、压缩函数的设计）需要在训练时引入——对已发布模型不可用。这是压缩近似路线的最大进入门槛。

五、三条路线的统一对比

5.1 七维对比表

维度	固定模式	动态选择	压缩近似
决策时机	计算前	计算中（轻量扫描后）	训练时（压缩设计）+ 计算中（部分含选择）
决策开销	零	扫描开销（索引查询/累分排序）	压缩投影开销
是否省计算？	✓	✓	✓
是否省存储？	部分（仅滑动窗口省）	✗（扫描需要全量 KV 可见）	理论可省，当前实现不省
对已发布模型可用？	滑动窗口可，结构化需训练	StreamingLLM/Vegas 可，NSA/DSA 需训练	否（压缩在训练时引入）
长程 memory 保留？	滑动窗口无，结构化部分	取决于扫描精度	CSA：top-512 保留；HCA：全局整合
vLLM 支持状态	滑动窗口通用	NSA/DSA ✓，Vegas RFC	CSA/HCA ✓（V4 专属）

5.2 「读得少 ≠ 存得少」：一个隐含约束的显式澄清

所有稀疏注意力方法减少了读取的 KV 数据量——每次 decode 从「全量 KV 搬进 SM」变成「部分 KV 搬进 SM」。但减少读取不一定减少存储。

读和存的关系	代表方法	为什么
既少读又少存	Sliding Window	不需要的 KV 既不算也不存——直接从 KV cache 中丢弃
少读但不省存	Vegas、NSA/DSA	每步的轻量扫描需要全量 KV 可见——必须全量存储才能扫描
少读但当前不省存	CSA/HCA	压缩只在计算时发生，存储的仍是原始全量 KV
少读且理论可省存	CSA/HCA（如果训练时存储压缩 KV）	不存储原始 K/V，只存压缩后的——当前无实现

读和存的正交性是理解稀疏注意力与 KV Cache 压缩之间关系的钥匙。 稀疏注意力优化「读路径」——SM 从 HBM 搬多少数据来做 attention。KV Cache 压缩（量化、MLA 低秩压缩）优化「存路径」——HBM 里放的数据占多少空间。两者的目标不同，优化手段不同，但在工程讨论中经常被混淆。

这也是为什么 DeepSeek V4 同时使用 CSA/HCA（优化读路径）+ MLA（优化存路径）+ FP8 量化（读和存双重优化）——每个技术各自瞄准自己的瓶颈，互相不替代。CSA 的 4× 压缩不减少 HBM 中的 KV 存量，MLA 的 576 维低秩压缩不减少每次 attention 的读取量。两条优化方向的叠加，才能同时压缩读和存的开销。

一个自然的推论：DSA 和 CSA 没有让 offloading 变得多余——它们让 offloading 变得更聪明。 DSA 的 Indexer 和 H2O/Vegas 的累积注意力分数天然产出「哪些 KV 被反复读取」的信号。没有这些信号时，offloading 只能按 LRU/FIFO 做盲目卸载；有了这些信号后，offloading 决策可以从「按时间」升级为「按语义重要性」。稀疏注意力优化了读路径（省计算），同时产出的副产品恰好解决了 offloading 最缺的东西——一个可用的 KV 优先级排序。关于这个信号链的问题空间，参见稀疏注意力 × KV Cache Offloading。

六、取舍与边界

6.1 选型：三个前置问题

选择哪种稀疏注意力，不取决于哪种「更好」，而取决于三个前置约束：

你的模型可以被修改吗？

不可以 → 只能在固定模式（滑动窗口）和不需要训练的动态选择（StreamingLLM、Vegas）之间选
可以微调 → 动态选择 + Indexer（NSA/DSA 路线）可用
可以从头训练 → 压缩近似（CSA/HCA）是最彻底的方案

你的任务需要多精确的长程 memory？

不需要（流式对话、多轮聊天）→ StreamingLLM 够用，零开销
偶尔需要（长文档中定位特定段落）→ Vegas 或 NSA/DSA 的动态选择
随时需要（代码库的全局理解、整本书的推理）→ CSA/HCA 的压缩-选择混合系统

你的瓶颈是计算还是存储？

计算瓶颈（高并发，SM 利用率接近上限）→ 任何稀疏注意力都有效——省计算是三条路线的共识
存储瓶颈（长上下文，显存快满了）→ 只有滑动窗口和训练时嵌入的压缩近似能省存储
两者都紧 → 需要稀疏注意力 + KV Cache 压缩的叠加

6.2 三个开放问题

扫描精度与扫描开销的黄金分割点。动态选择路线中，扫描精度越高，稀疏质量越好；但扫描本身越贵。NSA/DSA 的 Indexer 在 128K+ 上下文下证明了高精度扫描的收益大于成本。但 32K 以下上下文，这个 crossover point 在哪里？是否存在上下文长度自适应的扫描策略——短上下文用廉价扫描（累积分数查询），长上下文用高精度扫描（Indexer 前向）？

压缩近似的不可逆信息损失。CSA 的 4× 压缩抹平了相邻 4 个 token 的 K/V 差异。对于大多数 token 这无关紧要（语义是冗余的），但对于代码中的变量名、数字、API key——一个 token 的差异就决定了对错。「哪些 token 不能被压缩」这个判断本身需要计算，而做这个判断的计算又抵消了压缩节省的计算。是否存在任务感知的压缩粒度——对代码层使用 2× 压缩，对自然语言层使用 8× 压缩？

稀疏注意力 × speculative decoding 的深层协同。当 sparse_attn self-speculation（投机解码方法全景 §5.4）成熟后，稀疏注意力的输出将同时服务于两个目的：减少当前 forward 的 KV 读取量（省计算），以及为下一轮 speculative decoding 提供草拟信号（保接受率）。两个目的的稀疏度需求可能冲突——前者要求极稀疏（top-256），后者要求中等稀疏（top-2048，否则接受率暴跌）。同一个稀疏选择能否用不同的 k 同时兼容两个目的？

七、一句话总结

稀疏注意力方法的三条路线——固定模式、动态选择、压缩近似——分别代表了「不看数据先画地图」「扫一眼再决定」「不选了改计算方式」三种设计哲学。它们共享同一个目标（少搬一些 KV 数据进 SM），但实现这个目标的决策时机不同，导致了完全不同的计算开销、存储代价和模型侵入性。选哪条路线，取决于三个前置问题——模型能不能改、任务需要多精确的长程 memory、瓶颈是计算还是存储——因为在稀疏注意力的世界里，读得少从来不等于存得少。