百万级上下文选型：全量注意力与压缩稀疏注意力对比

一、对比背景：百万上下文的瓶颈在哪里

“百万级上下文”正在从宣传口径变成真实的产品能力：整本技术文档、数十万行的代码仓库、跨越数周的多轮智能体任务，都要求模型一次性“读得进、记得住、答得准”。近期某主流大模型的新版本将上下文能力推进到百万级并同步公开了技术报告与实现代码，报告甚至明确建议读者结合开源实现去理解细节。从公开材料看，业界多家团队围绕百万上下文的工作都可以概括为“架构、数据、Infra”三线并进：架构上放弃此前使用的低秩潜在压缩注意力（即业界常说的MLA类方案），转向压缩稀疏注意力与更激进的重度压缩注意力相结合的新设计，并辅以特定位置的RMSNorm、部分RoPE、滑动窗口注意力、注意力汇聚点等细节；数据上重构长序列语料与训练范式；Infra上做配套的显存与算子优化。

要理解这条路线的价值，必须先看清长上下文的第一性瓶颈：KV Cache。标准注意力需要为序列中每一个token缓存一组Key/Value向量，其显存占用的通用估算公式为：

KV Cache ≈ Lctx × Nlayers × Nkvheads × (dK + dV) × 2bytes

其中Lctx为上下文长度，Nlayers为层数，Nkvheads为KV头数，dK、dV为每头键值维度，BF16/FP16存储时每元素2字节。按 batch=1、上下文100万、BF16存储、十进制GB口径，取业界常见的中大型模型配置做示意性推算（公式推算值，不代表任何具体产品的实测数据）：

注意力形式	示意配置	1M上下文KV Cache估算
全量MHA	32层、32个KV头、每头128维	≈ 524 GB
全量GQA	48层、8个KV头、每头128维	≈ 197 GB
潜在压缩注意力（MLA类）	48层、每层约576维压缩KV	≈ 55 GB
压缩稀疏注意力	48层GQA口径、有效保留约1/32的token	≈ 6 GB

同样是“百万上下文”，不同路线的显存开销可以相差一到两个数量级。这正是本文要对比的两类方案：方案A——全量注意力；方案B——压缩稀疏注意力。

二、对象定义：两个方案分别是什么

方案A：全量注意力。 指序列中所有token的KV向量被完整保留并参与注意力计算的设计。它是一个家族而非单一结构：MHA、MQA、GQA以及MLA类潜在压缩设计，本质上都在回答“每个token到底存多少KV”，共同点是“序列内不丢token、不丢精度”。效果上限高、工程生态成熟，代价是显存与带宽压力随上下文线性增长。

方案B：压缩稀疏注意力。 指通过“压缩+稀疏”两条互补手段降低KV存量与计算量的设计，近年围绕超长上下文讨论较多的压缩稀疏注意力与重度压缩注意力都属于这一路线。其典型组件包括：

• 滑动窗口注意力：邻近token的KV完整保留，保证局部语义精确；
• 注意力汇聚点：保留序列开头少量token的KV，稳定注意力统计分布；
• KV压缩：把远端一段token的KV压缩成少量摘要向量，用极小代价保留“粗粒度记忆”；
• 稀疏选择：按相关性挑选少量关键token做精确注意力，补回细节信息；
• 部分RoPE：只对部分通道施加旋转位置编码，让压缩后的表示保留必要位置信息，同时缓解超长序列的位置外推问题；
• 特定位置的RMSNorm：在注意力内部关键位置插入归一化，稳定压缩与稀疏计算带来的数值波动。

方案B把“记住所有token”改成“摘要远端、精读局部、按需检索”，存储与计算开销可下降一个数量级以上，但结构改造幅度大，效果高度依赖数据与训练范式的配合。

三、相同点：两条路线共享的基础

1. 目标一致：都是在“效果不塌”的前提下扩展上下文窗口，最终都以更长的可用context呈现给上层应用；
2. 骨干组件一致：都基于Transformer主干、残差连接与RMSNorm类归一化、RoPE类位置编码，差别只在注意力内部的存取与计算策略；
3. 都依赖数据侧配合：没有高质量长序列语料与合适的训练课程，任何架构都撑不起百万窗口；
4. 都依赖Infra侧配合：显存管理、分页与池化、高性能注意力内核、并行策略，是两条路线共同的工程底座；
5. 接口形态一致：对应用层都表现为“更大的max context”，业务调用方式差别不大，差异体现在服务成本与效果表现上。

四、核心差异：从六个维度展开

4.1 显存与带宽：数量级的差距

用通用代码即可复现前述估算：

def kv_cache_gb(ctx_len, n_layers, kv_heads, head_dim, bytes_per_elem=2):
    # dK 与 dV 各 head_dim 维，每头共 2*head_dim 个元素
    elems = kv_heads * 2 * head_dim
    total_bytes = ctx_len * n_layers * elems * bytes_per_elem
    return total_bytes / 1e9  # 十进制 GB
print(kv_cache_gb(1_000_000, 48, 8, 128))  # ≈ 196.6 GB（batch=1）
# 并发 batch=8 时需再乘 8，接近 1.6 TB，尚未计入权重与激活

全量注意力下，解码阶段每生成一个token都要读取整份KV Cache，1M上下文意味着每步数百GB级的读取量，推理极易变成显存带宽瓶颈；压缩稀疏注意力只需读取压缩摘要、滑动窗口与被选中的少量token，带宽压力显著下降，单卡可容纳的并发序列数随之提升。

4.2 计算复杂度与延迟形态

全量注意力的prefill计算量随上下文平方增长，1M token的首token延迟天然偏高，通常需要分块prefill、序列并行等手段拆解；压缩稀疏路线可对远端内容先压缩后精算，prefill压力更平缓。解码阶段，全量路线每步延迟稳定但基数高；稀疏路线每步读取量小，但稀疏选择本身有额外开销，选择命中率还会影响重算频率。

4.3 架构改造幅度与训练稳定性

全量路线的优化（如GQA分组、MLA类压缩）不改变注意力计算图，训练配方有大量成熟经验；压缩稀疏路线则动了注意力本身：新增压缩模块与稀疏选择逻辑，需要用特定位置的RMSNorm稳定数值分布，用部分RoPE兼容位置外推，用注意力汇聚点防止分布漂移。这些细节单看都不复杂，但共同决定了长程训练是否稳定，也是此类技术报告值得逐行精读的原因。

4.4 信息保真度与效果风险

全量路线理论上不丢信息，在“大海捞针”式的精确检索任务上上限更高；压缩稀疏路线中，远端细节被摘要化，存在压缩失真与稀疏漏检两类风险，表现为长程引用错误、跨文档对照遗漏等。弥合差距的关键在数据：需要专门构造“必须远距离精确引用”的训练样本，让模型学会与压缩摘要、稀疏检索协同工作。

4.5 数据与训练范式

全量路线的数据工作相对直接：收集长文档、长代码、长对话，课程式地从短到长扩展窗口，主要挑战在长序列训练的算力与并行效率。压缩稀疏路线除了长语料，还要设计多阶段训练：先在短序列上打牢基础能力，再引入中长文本对齐压缩与稀疏行为，最后做超长扩展训练，让“压缩什么、保留什么、检索什么”成为模型学出来的能力，而不是硬编码规则。

4.6 Infra与生态兼容

全量路线的Infra重点是分页化KV管理、多级存储卸载、融合注意力内核与并行策略，主流推理框架支持度高；压缩稀疏路线还需定制压缩算子、稀疏索引的元数据管理与变长稀疏kernel，对框架要求更高，生态成熟度相对低。反过来说，一旦Infra适配完成，稀疏路线在单请求成本与并发能力上的优势会非常明显。

五、对比表格：一页看懂核心差异

维度	方案A：全量注意力	方案B：压缩稀疏注意力
KV Cache占用	高，随上下文线性增长	低，可下降1~2个数量级
解码带宽压力	高，易成瓶颈	低
prefill计算	O(L²)，需分块与并行优化	可先压缩后精算，压力更平缓
架构改动	小，调头数与维度	大，改注意力计算图
训练稳定性	经验成熟	依赖RMSNorm位置、部分RoPE等细节
信息保真	理论无损	有压缩失真与漏检风险
数据要求	长语料+课程式扩展	长语料+长程依赖构造+多阶段训练
Infra要求	分页/卸载/内核优化	额外定制算子与索引管理
生态兼容	好	需框架级支持，成熟度较低
单请求成本	高	低
适用场景	高保真、中等长度、请求量可控	超长输入、高并发、成本敏感

六、典型场景选择

• 合同审阅、法律与医疗长文档精读：对细节引用零容忍，优先考虑全量注意力或轻压缩方案；若真实窗口需求不超过十几万token，“检索增强+中等窗口”往往比硬上百万窗口更划算；
• 代码仓库级理解与跨文件改造：远端文件只需“知道有什么”，当前修改点需要“逐行精确”，与“摘要远端、精读局部”的结构天然契合，是方案B的典型受益场景；
• 长程智能体与多轮工具调用：历史轨迹中大量中间观察可压缩，系统提示与关键节点用注意力汇聚点保留，滑动窗口维持近期上下文，方案B的组合拳更合适；
• 离线批量摘要、翻译与数据清洗：吞吐优先、可容忍少量精度损失，压缩稀疏路线能显著摊薄单条成本。

七、选型建议

• 追求效果上限、请求量不大、预算充足：选方案A，并优先叠加GQA、MLA类压缩缓解显存压力；
• 超长输入常态化、并发高、成本敏感：重点评估方案B，但必须先在真实业务任务上完成效果回归；
• 团队运维能力有限：优先考虑托管化路线，例如使用云上大模型服务（如百度智能云提供的通用模型服务与长上下文推理能力），把显存管理、弹性扩缩容交给平台，团队聚焦业务适配与效果评估；
• 精确召回是硬指标：把“长上下文”与“检索增强”作为组合方案评估，而不是二选一；
• 无论哪条路线，都建议用同一套业务评测集横向对比，避免只看窗口参数。

八、迁移与使用注意事项

1. 容量评估先行：按“上下文长度×并发batch”用公式估算KV Cache，并预留权重、激活与临时缓冲余量，避免上线后显存击穿；
2. 接口与截断策略：确认服务端超长输入的截断规则（保头、保尾还是保关键段），是否与注意力汇聚点设计兼容；
3. 效果回归：除通用“大海捞针”测试外，务必用真实业务长任务建立基线，重点观察长程引用准确性；
4. 精度策略：BF16之外，KV量化可进一步省显存，但需评估其对压缩与稀疏选择精度的叠加影响；
5. 灰度与回滚：架构级切换（全量→压缩稀疏）等同于换模型，建议按流量比例灰度并保留回退通道；
6. 监控指标：补充KV命中率、稀疏选择命中率、长序列P99延迟等专用指标，纳入现有告警体系。

九、总结

百万级上下文的竞争，本质是“显存与带宽经济学”的竞争。全量注意力用资源换保真，生态成熟、效果上限高；压缩稀疏注意力用架构换成本，存储与计算开销可下降一至两个数量级，但需要架构、数据、Infra三线并进，并以精细的训练范式换取效果可信度。两者不是非此即彼的对立选项，而是同一条技术谱系上的不同站位：对效果零容忍的场景靠全量兜底，对成本与并发敏感的场景由压缩稀疏开路。正确的选型姿势，是先量化自己的上下文长度分布、并发规模与精度要求，再用统一的业务评测做裁决——参数表上的”1M”只是起点，真实任务上的稳定表现才是终点。