长上下文推理的瓶颈从来不是"模型能不能记住"，而是"算力够不够烧"。MiniMax 最近扔出来一篇论文和一套配套 CUDA 内核，直接把这个问题掀了个底朝天——他们在 109B 参数的多模态模型上做到 1M 上下文、注意力计算量砍掉 28.4 倍，同时模型输出质量纹丝不动。核心武器叫做 MSA，一种基于 GQA（Grouped-Query Attention）架构改造而来的块状稀疏注意力方案。论文、推理内核、模型权重，三件套全部公开。
MSA 的结构逻辑：两条分支，各司其职
稀疏注意力这个赛道从来不缺玩家，但大多数方案的痛点在于"稀疏选不准"或"稀疏之后算得更慢"。MSA 的解法很干脆——干脆把选块和计算拆成两个独立分支，让它们各自做好一件事。
Index Branch：轻量级筛选器
Index Branch 是整个方案的入口。它的任务只有一项：在每一步推理前，快速判断哪些 KV 块值得保留、哪些可以丢掉。注意，这里的"筛选"不是全局共享的——每个 GQA 组都会独立运行自己的 Index Branch，选出属于自己的 Top-k KV 块。这种设计的优势在于：不同注意力头的关注点天然不同，强制共享索引反而会引入噪声。Index Branch 本身极其轻量，参数开销可以忽略不计，但它为后续的计算节省了超过九成的 KV 访问量。
Main Branch：精确计算只落在选中块上
筛选完之后，Main Branch 接管剩下的活。它不对所有历史 KV 做完整注意力计算，而是只对 Index Branch 选出来的那部分块执行精确的块稀疏注意力。GQA 的分组结构在这里再次发挥作用——同组内的查询头共享同一组 KV 块，索引结果天然适配，不存在跨组同步的额外开销。这种"先粗筛、再精算"的两段式流水线和传统 dense attention 相比，输出分布在统计意义上几乎不可区分，但计算路径被大幅收窄。
性能数据：28 倍不是营销话术
稀疏注意力方案每年冒出来几十种，真正落地时往往要面对一个问题：纸面算力节省漂亮，但加上访存和调度开销后，实际加速比远低于理论值。MiniMax 给出的数字直接绕过了这种落差。
1M 上下文下的注意力 FLOPs 实测
在 109B 参数的多模态模型上，处理 1M token 序列时，每 token 的注意力计算量从 GQA baseline 的水平直接降到原来的 1/28.4。这不是单层的局部优化，而是整条流水线的端到端结果。关键在于 Index Branch 的筛选准确率足够高——选中的 Top-k 块覆盖了几乎全部的真实注意力质量分布，Main Branch 的精算落在这些块上时，模型输出与 full attention 的 KL 散度保持在极低水平。
H800 上的端到端加速比
单看 FLOPs 没用，硬件实际能跑多快才是关键。配合团队协同设计的 GPU 内核，在 H800 上测得 14.2 倍 prefill 加速和 7.6 倍 decoding 加速。Prefill 阶段收益更高，因为大量历史 KV 在筛选阶段就被拦在门外，访存压力骤降；decoding 阶段虽然受制于逐 token 生成的天花板，但 7.6 倍仍然是相当可观的数字。对于需要实时响应的长上下文 agent，这意味着单卡可服务的并发量直接翻了一个数量级。
为什么是 GQA 而不是 MHA
MSA 的设计选择并非偶然。GQA 在当前主流大模型架构中几乎是默认配置，把稀疏机制直接嫁接在 GQA 上意味着零迁移成本——已有的 checkpoint 不用重新训练，推理栈不用大规模重写。
分组结构天然适配块级索引
GQA 中同一组内的多个查询头共享同一份 KV，这个特性让 Index Branch 可以按组粒度做块选择，而不必为每个头单独跑一遍筛选逻辑。选块次数从 H（头数）降到 H/G（G 是每组共享的 KV 头数），筛选开销被进一步压缩。这种"架构先于算法"的思路在工程上往往比纯算法创新更值钱。
对已有推理栈的兼容性
主流推理框架如 vLLM、SGLang 对 GQA 都有深度优化支持。MSA 在 GQA 之上做减法，落地时几乎可以复用现有 KV cache 管理逻辑，只需要替换注意力计算的内核调用。对于正在用 70B、100B 级模型跑长上下文业务的团队来说，迁移成本被压到了极低水平——理论上换个 attention backend 就能拿到十倍级的速度提升。
开源节奏与落地建议
MiniMax 在论文发布的同时，把推理内核和基于 MSA 的多模态模型都放了出来。这不是"论文先发、代码后补"的常见套路，而是真刀真枪可以拉下来跑的东西。
直接可用的资源清单
从公开信息来看，这次释放的资产包含两块：高性能 CUDA attention kernel，以及基于 MSA 训练完成的多模态模型权重。前者可以直接集成到现有推理框架中作为 attention backend 的替换选项；后者则提供了完整的端到端参考实现，省去了自己从零训练的算力消耗。对于需要处理代码仓库级输入、或者长文档多轮对话的 agent 系统，这套方案几乎是为它们量身定做的。
上手前需要评估的几件事
即便方案看起来完美，工程团队在接入时仍需要确认几个边界条件：业务场景的上下文长度是否稳定在 100K 以上——低于这个量级，MSA 的筛选开销相对于节省的注意力计算可能得不偿失；硬件是否在 H800/A100 级别——低端卡上访存瓶颈更突出，加速比会打折扣；现有推理框架是否支持自定义 attention kernel——如果走的是闭源推理服务，迁移路径会复杂得多。
长上下文推理的军备竞赛还在继续，MSA 给出的回答很务实：与其追求更长的理论窗口，不如让每个 token 的实际计算成本降下来。这条路线对算力的解放程度，远比单纯堆参数或拉长 position embedding 要直接得多。
