长上下文的硬件账本：稀疏注意力如何改写显存需求

模型上下文窗口每翻一倍，硬件的隐形成本就翻着倍地涨。预训练计算量的平方增长还算显性，真正卡脖子的是注意力机制带来的 KV Cache：它随上下文长度线性膨胀，随并发数再乘一遍。要读懂长上下文的硬件账本，得从每 token 的 KV 开销算起。

KV Cache：线性膨胀的隐形成本

自回归解码时，注意力要回看全部历史 token，历史位置的键值向量必须缓存下来。每 token 每层的 KV 开销等于 2 乘以 KV 头数乘以头维度乘以精度字节数，再乘层数。一个 70B 级模型若采用传统多头注意力，单条 128K 上下文的 KV Cache 可以膨胀到几十 GB；并发 16 路，几张 H100 都不够放。这就是长上下文推理服务成本居高不下的结构性原因。

第一轮减负来自注意力结构本身。分组查询注意力（GQA）让多个查询头共享一组 KV 头，KV 开销直接砍掉数倍，如今几乎是长上下文模型的标配。DeepSeek 的 MLA 走得更远：把键值投影到低秩潜空间，缓存的是压缩后的潜向量，据其公开技术报告，KV 显存占用相比传统方案下降了一个数量级，这为 DeepSeek 系列的高并发长上下文服务提供了硬件红利。

稀疏注意力：少读多用

结构压缩之外，更激进的思路是承认一个经验事实：注意力权重高度集中，绝大多数历史 token 对当前生成的贡献可以忽略。稀疏注意力据此只挑选一小部分关键块参与计算——DeepSeek 的原生稀疏注意力（NSA）、月之暗面的 MoBA 以及 Quest 等方法，都在"选块策略"上做文章：按块粒度估计重要性，只把少数高分块读进计算，其余不碰。

对硬件来说，稀疏注意力省的是 HBM 带宽——解码阶段的瓶颈正是 KV 读取，KV 读取量被压掉一个量级，长上下文解码的速度与显存压力同步缓解。但代价也要看清：选块与索引本身有计算开销，稀疏访问模式让 GPU 利用率下降；更关键的是精度风险，"哪块重要"的判断如果失误，模型会漏看关键信息，长文检索类任务最先暴露问题。

方案对照

方案	KV 显存/读取量	精度风险	实现与迁移成本
多头注意力（MHA）	基线	无	无，但硬件成本最高
分组查询（GQA）	降至数分之一	极低，已充分验证	训练时确定，改动小
MLA 潜空间压缩	下降一个数量级	低，需配套训练	需专有算子支持
稀疏注意力选块	读取量与长度近似解耦	中，依赖选块策略	框架与算子支持要求高

实操建议

百万级上下文没有银弹，主流配方是三层叠加：模型侧选 GQA 或 MLA 压缩 KV 本体；注意力侧按业务特性选稀疏策略——代码改写、文档问答这类"相关内容集中"的任务收益最大，全局推理类任务要谨慎评估；系统侧用 KV 量化与 CPU/SSD 分层卸载兜底容量缺口。评估时重点跑长文大海捞针与多跳检索测试，稀疏方案的短板往往藏在最需要"看全文"的样本里。