简介：本文围绕大模型长上下文处理中的两类主流注意力优化方案展开对比，从架构设计、计算效率、缓存占用、适用场景和选型依据等维度进行拆解，帮助开发者理解稀疏注意力与重度压缩注意力在百万级上下文场景下的真实差异，并给出条件化的选型建议与迁移注意事项。
在生成式大模型进入生产环境后，上下文长度已经成为影响应用形态的关键变量。无论是长文档解析、代码库理解、多轮智能体交互，还是超长会议纪要处理，模型能否在百万级 token 上保持可用性能和可控成本，直接决定了方案能否落地。
传统 Transformer 结构中的全量注意力机制，在长上下文下面临两个明显问题：
因此，行业逐步形成共识：要支持超长上下文，必须在注意力层做结构性改造，而不是继续堆硬件。当前常见的技术路径包括滑动窗口、线性注意力、稀疏注意力、压缩注意力等。本文重点对比其中两种在近期预览级模型中表现突出的方案——稀疏选择式注意力与重度压缩式注意力，并放在同一架构交替使用的视角下讨论其差异。
稀疏选择式注意力的核心思路是：将连续的 token 序列按固定窗口分组，每组通过池化或摘要策略生成若干条代表性向量，构成压缩后的 KV 候选集。在推理时，每个 query 只从这些摘要向量中选取相关性最高的 top-k 条进行计算，而非遍历全部历史 token。
这种机制类似于先浏览文档目录，再只精读与当前问题最相关的章节。它的重点在于 选择性忽略——即使候选集很大，实际参与注意力计算的条目仍然很少。
重度压缩式注意力采取更激进的压缩比，例如每 128 个 token 合并为一条摘要向量。不过与稀疏选择式注意力不同，它在压缩之后仍然对全部摘要向量执行注意力计算，不做 top-k 选择。
这种方式可以理解为“先把书读薄，再整体通读一遍”。它牺牲了 token 级细粒度，但保留了全局视野，适合需要稳定理解整段语义结构的任务。
在实际的预览级模型中，这两种注意力机制并非二选一，而是以分层交替的方式出现在不同网络深度上。同时，模型还会在部分层保留滑动窗口机制，直接读取最近的原始 token，以弥补压缩带来的局部细节损失。
这种组合设计的本质是：用不同粒度的注意力应对不同层级的语义需求——浅层更需要局部上下文，深层更需要全局结构。
尽管两种注意力机制在具体实现上差异明显，但它们的出发点和底层逻辑有若干共同之处：
无论是稀疏选择还是重度压缩，核心目的都是避免全量 token 参与注意力计算，从而将推理成本从“随长度平方增长”拉回到近似线性或亚线性水平。
两种方案都会对原始 token 的 KV 缓存进行聚合或压缩，生成维度相同的摘要向量。这意味着二者在底层数据结构上有一定通用性，工程实现上可以共享部分池化组件和缓存管理逻辑。
与全量注意力相比，两种方案都引入了近似误差。稀疏选择可能忽略某些不相关的健值对，重度压缩则必然损失 token 级细节。因此，二者都属于“用精度换效率”的折中路线，只是折中的位置不同。
仅靠压缩或稀疏选择都不足以保证生成质量，实际架构通常都会保留最近若干个原始 token 的完整注意力计算，以维持局部连贯性和生成长文的稳定性。
稀疏选择式注意力的计算路径可以描述为：
输入序列 → 分段摘要 → 生成候选集 → query 相关性打分 → top-k 筛选 → 局部注意力计算
而重度压缩式注意力的路径是：
输入序列 → 大窗口合并 → 生成压缩摘要 → 全量摘要注意力计算
前者在计算前多做了一次“筛选”，后者则省略了筛选步骤，直接对所有压缩结果进行计算。这意味着稀疏方案在候选数量很大时更有优势，而重度压缩在候选数量本身已经较小时更合适。
在百万 token 上下文下，两种方案对 KV 缓存的压缩效果有明显差异。假设原始 KV 缓存为基准 100%，稀疏选择式注意力通常可以将缓存降至基准的 10% 上下，而重度压缩式注意力可以进一步降至个位数百分比。
值得注意的是，这种差异在推理端的高并发场景下会被放大。当同一模型的 KV 缓存需要在多路请求间复用或长期驻留时，缓存占用直接决定显存容量需求和单节点可服务请求数。
重度压缩式注意力由于对全部压缩摘要进行计算，天然具备更强的全局视野。它不会因为筛选偏差而遗漏某些远距离的语义关联。在需要理解整篇文档结构、跨段落推理、或从全文提取统一主题的任务中，这种稳定性更有价值。
相比之下，稀疏选择式注意力虽然也能通过较大的候选池覆盖大部分相关信息，但 top-k 筛选本质上是一种启发式近似。在选择偏差较大的场景下，可能漏掉关键上下文。
稀疏选择式注意力通常使用较小的压缩窗口，例如每 4 个 token 生成一条摘要，因此摘要向量仍然保留了较高的位置粒度和局部语义分辨能力。对于需要精确引用原文片段、定位具体数值或关注局部语序的任务，稀疏方案更友好。
重度压缩式注意力每 128 个 token 才合并一次，压缩强度远高于前者，无法支撑细粒度定位需求。这也是为什么实际架构必须补充滑动窗口机制，用原始 token 的完整注意力来兜底局部细节。
稀疏选择式注意力隐含一个假设：在长上下文中，当前 query 只与少数远距离段落相关，其他内容可以安全忽略。这个假设在信息检索型任务中成立度较高，但在开放域推理或全局一致性要求高的任务中可能失效。
重度压缩式注意力则不做这种假设，它默认每个压缩摘要都可能对当前计算有贡献。因此它更适合语义密度均匀、上下文整体关联度高的输入。
稀疏选择式注意力需要额外的相关性打分模块和 top-k 选择逻辑，这带来了索引构建、排序计算、负载均衡等方面的工程开销。尤其在分布式部署时，如何高效地从分散的摘要候选集中选出 top-k 条目，本身就是一个不小的系统问题。
重度压缩式注意力实现相对直接：先做聚合，再做全量注意力。其工程复杂度主要集中在压缩阶段的池化策略设计上，推理阶段的计算图更简洁。
| 对比维度 | 稀疏选择式注意力 | 重度压缩式注意力 |
|---|---|---|
| 压缩窗口 | 较小，如每 4 个 token | 较大，如每 128 个 token |
| 注意力计算范围 | top-k 筛选后的子集 | 全部压缩摘要 |
| 缓存占用 | 约为原始 KV 的 10% | 可低至原始 KV 的个位数百分比 |
| 全局语义稳定度 | 中高，受筛选质量影响 | 较高，全量计算无遗漏 |
| 细粒度定位能力 | 较强，摘要粒度细 | 较弱，需滑动窗口兜底 |
| 计算前额外开销 | 有相关性打分和排序 | 无或极少 |
| 工程实现复杂度 | 较高 | 相对较低 |
| 适合的上下文分布 | 信息稀疏、关键段落分散 | 语义密集、整篇关联 |
| 最典型适用任务 | 长文档问答、信息检索、审计类 | 整篇总结、全局一致性检查、跨章节推理 |
在实际生产实践中，大多数超长上下文应用既需要局部精确理解，也需要全局语义把握。因此，采用分层交替的混合架构——即在不同网络层分别使用稀疏选择、重度压缩和滑动窗口——通常比单一方案更稳健。开发者需要关注的是不同层的分配比例，以及压缩窗口大小与任务类型的匹配。
如果上下文中信息高度集中、关键内容只占少部分，优先考虑稀疏选择式方案；如果上下文是连续论述、整体都是有效信息，则重度压缩式方案更稳妥。判断方法很简单：随机截取上下文中若干片段，看看片段之间是否存在强依赖关系。依赖越强，越需要全局计算。
在高频调用、缓存命中率高的智能体场景下，稀疏选择式注意力配合缓存定价策略可以获得更明显的成本优势。因为每次推理只需要从大量固定上下文中读取一小部分相关键值对。相比之下，重度压缩虽然缓存更小，但每次都需要对全部压缩摘要进行计算，在极端高频场景下计算量反而可能更高。
稀疏选择式方案在工程实现和调优上的门槛更高，涉及筛选模块训练、top-k 参数调整、分布式选优等问题。如果团队对注意力底层改造经验不足，可以先采用重度压缩加滑动窗口的简化组合，验证业务效果后再逐步引入稀疏选择机制。
不存在“稀疏一定比压缩好”或“压缩一定比稀疏稳定”的结论。两种方案的本质差异在于注意力计算的粒度和覆盖范围，它们解决的是长上下文下不同层级的问题。真正值得关注的是：你的业务上下文是“长而稀疏”还是“长而稠密”，以及你的基础设施是“算力受限”还是“存储受限”。
采用新型注意力机制后，原来的等长截断策略可能不再适用。开发者需要根据压缩窗口大小，规划输入的分段边界，避免重要信息恰好落在被大幅压缩的区间内。对于关键字段、数值和标识符，建议在编码前进行显式标注或前置到滑动窗口范围内。
由于缓存命中后的成本远低于未命中场景，固定内容应尽量放在请求头部，并保持顺序稳定。如果提示词结构频繁变化，缓存复用率会显著下降，稀疏选择的效果也会打折扣。
传统的短句级评测指标无法反映长上下文下的真实能力。迁移前应增加跨段落推理、全局总结、远距离事实关联等专项评测，重点观察模型在“关键信息恰好不在滑动窗口内”时的表现。
稀疏选择式注意力存在筛选偏差的可能，故障排查时难以及时发现模型“选错了段落”。建议在推理链路上增加轻量的可观测埋点，记录 top-k 选择分布和缓存命中情况，便于追踪质量波动。
新型注意力方案在不同上下文长度下可能呈现非线性的性能变化。上线前应在 8K、32K、128K、512K、1M 等关键长度点分别进行压测，记录延迟、缓存占用和吞吐变化，避免在极端长度下出现资源尖峰。
长上下文是生成式模型走向复杂业务场景的必经关口，而注意力机制的改造是其中最核心的技术分水岭。稀疏选择式注意力与重度压缩式注意力代表了两种不同的取舍方向：前者在计算前做筛选，擅于处理长而稀疏的上下文；后者在压缩后做全量，擅于维持长而稠密的全局语义。
当前预览级架构的实践表明，将两者与滑动窗口结合，以分层交替的方式组织注意力计算，可以在百万 token 上下文下同时获得较低的计算开销和较稳定的生成质量。对开发者而言，关键不是追求单一最优方案，而是根据业务上下文的真实结构、调用频率和基础设施约束，选择适合的注意力配置组合，并为后续的方案切换预留足够的可观测性和评测空间。