编者按本文由 AI 每日精选自动整理编译内容基于 2026 年 8 月的公开英文技术资料翻译与二次加工供国内开发者快速了解前沿进展。文末附有原始信息来源欢迎在评论区交流。MiniMax M3 深度解读用「稀疏注意力」把百万上下文的算力成本打到 1/20目录MiniMax M3 深度解读用「稀疏注意力」把百万上下文的算力成本打到 1/20一、为什么这条新闻值得关注二、核心规格速览三、稀疏注意力MSA到底解决了什么问题3.1 标准注意力的老毛病O(n²)3.2 MSA 的关键思路把「看哪些 KV」和「怎么算注意力」拆开3.3 工程上的收益四、和其他主流模型的定位差异五、对国内开发者的几点实操启示六、小结参考资料 / 信息来源一、为什么这条新闻值得关注2026 年上半年是大模型极其热闹的半年Anthropic 发布 Claude Sonnet 5、Google 在 I/O 上推出 Gemini 3.5、xAI 的 Grok 4.3 登顶 LMArena 排行榜、OpenAI 也罕见地开源了 GPT-oss 系列权重。但在这一堆「参数更大、榜单更高」的常规叙事里真正让工程师眼前一亮的是来自上海的MiniMax M3。它的看点不在于「又刷了一个榜」而在于架构层面的改动M3 用自研的MiniMax Sparse AttentionMSA稀疏注意力替换掉了标准 Transformer 那套 O(n²) 复杂度的注意力把处理百万 token 长上下文的每 token 计算成本压到了传统方案的约1/20同时保持了前沿水平的编程与推理能力。对做长文档、代码库级理解、以及 Agent 工作流的同学来说这是一个「成本结构」层面的变化值得认真拆解。二、核心规格速览维度MiniMax M3模型类型混合专家MoE 稀疏注意力总参数量约 4280 亿428B每 token 激活参数约 230 亿23B上下文窗口最高 100 万1Mtoken注意力机制MiniMax Sparse AttentionMSA块稀疏 Lightning Indexer多模态原生多模态M3-VL 版本搭配 CLIP 风格视觉塔定位前沿编程能力、超长上下文、Agent 工作流注以上数字来自 MiniMax 官方博客及 Hugging Face 模型卡等公开资料翻译时保留了原始口径。一句话概括这套配置的精髓总参数很大保证能力上限但每个 token 实际只激活约 23B保证推理便宜再叠加稀疏注意力保证长上下文不爆炸。三招叠加才有了「前沿性能 极低成本」的组合拳。三、稀疏注意力MSA到底解决了什么问题3.1 标准注意力的老毛病O(n²)标准 Transformer 的自注意力需要让序列里每个 token 都和其他所有 token 两两算一遍相关性。序列长度是 n计算量和显存占用就随 n² 增长。上下文从 4K 拉到 1M是 250 倍的长度但注意力的开销大致是6 万倍级别的膨胀。这正是「长上下文很贵、很慢」的根本原因。MiniMax 更早的 MiniMax-Text-014560 亿参数、每 token 激活 45.9B就已经在用混合的线性注意力Lightning Attention思路来对抗这个问题M3 则把它进一步演进成了MSA。3.2 MSA 的关键思路把「看哪些 KV」和「怎么算注意力」拆开按照社区对 M3 架构图的解读MSA 最核心的一步是把注意力拆成两个动作先筛选Lightning Indexer / 预过滤阶段用一个轻量的「索引器」分支快速判断——对当前 token 来说历史里的哪些 Key/Value 块是真正值得看的。再计算块稀疏注意力只对被选中的那一小部分 KV 块做完整的注意力计算其余直接跳过。换句话说模型不再「无脑地」对全序列做稠密注意力而是先用便宜的方式定位重点再把宝贵的算力花在刀刃上。3.3 工程上的收益根据 NVIDIA 的部署博客MSA 用一个预过滤阶段替换了传统的二次方注意力带来的实测收益包括连续 KV cache 访问速度提升 4 倍以上每 token 计算成本约为原来的 1/20能够高效支撑100 万 token级别的上下文窗口。此外M3 的层结构是混合的前几层用「稠密注意力 稠密 MLP」保证基础表达能力后续大部分层则采用「稀疏注意力 MoE」来省算力。MoE 部分用的是 Sigmoid 路由带有路由偏置校正并配有一个共享专家shared expert。四、和其他主流模型的定位差异2026 年这一批新模型大致可以分成两条路线路线一把中端模型做到接近旗舰。典型是 Anthropic 的Claude Sonnet 52026 年 6 月 30 日发布。它把原本只有 Opus 级大模型才有的自主 Agent、工具调用、浏览器操作能力下放到更便宜的 Sonnet 档标配 100 万 token 上下文SWE-bench Verified 达到 72.7%在 Terminal-Bench 2.1 上甚至以 80.4% 反超旗舰 Opus 4.8 的 74.6%。它解决的是「性价比曲线」问题。路线二从架构层面改写成本结构。这正是MiniMax M3的路子。它不满足于「同样的 Transformer、把参数调便宜」而是直接换掉注意力机制本身。对于长上下文、代码库理解、Agent 长链路这类场景这种改动的边际收益会随着上下文变长而不断放大。两条路线并不冲突但对做工程落地的人来说信号很清晰当上下文越来越长、Agent 链路越来越深时架构级的效率优化而非单纯堆参数会越来越重要。五、对国内开发者的几点实操启示长上下文不再是「土豪专属」。如果你之前因为 O(n²) 的成本而不敢把整个代码仓库、整本手册塞进上下文稀疏注意力类模型给了你重新评估的理由。可以针对自己的 RAG / 长文档场景做一次成本对比测试。关注「每 token 激活参数」而不只是总参数。MoE 模型的总参数决定能力上限但推理成本主要由激活参数决定。M3 的 428B 总参 / 23B 激活是理解其成本优势的关键。部署生态正在跟上。vLLM、TensorRT-LLM、NVIDIA NeMo 等主流推理框架均已支持 MiniMax-M3这意味着自建推理服务的门槛在下降可以纳入选型评估。多模态是默认项不是附加项。M3-VL 原生支持视觉输入对需要「文档 截图 代码」混合理解的 Agent 场景很友好。六、小结MiniMax M3 这条新闻的真正价值不在于又一个「大参数、高榜单」的模型诞生而在于它把**「长上下文很贵」这个行业默认假设**给动摇了。用「先筛选、再计算」的稀疏注意力把百万上下文的每 token 成本压到 1/20这是一次从架构底层出发的效率革命。在「堆参数」逐渐边际递减的当下这类架构级创新可能才是接下来最值得国内工程师持续跟踪的方向。参考资料 / 信息来源MiniMax 官方博客MiniMax M3: Frontier Coding, 1M Context, Native MultimodalityHugging Face 模型卡MiniMaxAI/MiniMax-M3 READMENVIDIA 开发者博客Deploy Long-Context Reasoning and Agentic Workflows with MiniMax M3社区架构解读Decoding M3’s Attention from a Single DiagramMiniMax-01 开源仓库MiniMax-AI/MiniMax-01 (GitHub)行业动态汇总LLM News Today (August 2026)Claude Sonnet 5 参考Claude Sonnet 5 Benchmarks Explained (Vellum)本文为编译整理技术细节以官方文档为准。如有翻译或理解偏差欢迎在评论区指正交流。转载请注明来源。#大模型#MiniMax#稀疏注意力#长上下文#MoE#AI工程化
编者按本文由 AI 每日精选自动整理编译内容基于 2026 年 8 月的公开英文技术资料翻译与二次加工供国内开发者快速了解前沿进展。文末附有原始信息来源欢迎在评论区交流。MiniMax M3 深度解读用「稀疏注意力」把百万上下文的算力成本打到 1/20目录MiniMax M3 深度解读用「稀疏注意力」把百万上下文的算力成本打到 1/20一、为什么这条新闻值得关注二、核心规格速览三、稀疏注意力MSA到底解决了什么问题3.1 标准注意力的老毛病O(n²)3.2 MSA 的关键思路把「看哪些 KV」和「怎么算注意力」拆开3.3 工程上的收益四、和其他主流模型的定位差异五、对国内开发者的几点实操启示六、小结参考资料 / 信息来源一、为什么这条新闻值得关注2026 年上半年是大模型极其热闹的半年Anthropic 发布 Claude Sonnet 5、Google 在 I/O 上推出 Gemini 3.5、xAI 的 Grok 4.3 登顶 LMArena 排行榜、OpenAI 也罕见地开源了 GPT-oss 系列权重。但在这一堆「参数更大、榜单更高」的常规叙事里真正让工程师眼前一亮的是来自上海的MiniMax M3。它的看点不在于「又刷了一个榜」而在于架构层面的改动M3 用自研的MiniMax Sparse AttentionMSA稀疏注意力替换掉了标准 Transformer 那套 O(n²) 复杂度的注意力把处理百万 token 长上下文的每 token 计算成本压到了传统方案的约1/20同时保持了前沿水平的编程与推理能力。对做长文档、代码库级理解、以及 Agent 工作流的同学来说这是一个「成本结构」层面的变化值得认真拆解。二、核心规格速览维度MiniMax M3模型类型混合专家MoE 稀疏注意力总参数量约 4280 亿428B每 token 激活参数约 230 亿23B上下文窗口最高 100 万1Mtoken注意力机制MiniMax Sparse AttentionMSA块稀疏 Lightning Indexer多模态原生多模态M3-VL 版本搭配 CLIP 风格视觉塔定位前沿编程能力、超长上下文、Agent 工作流注以上数字来自 MiniMax 官方博客及 Hugging Face 模型卡等公开资料翻译时保留了原始口径。一句话概括这套配置的精髓总参数很大保证能力上限但每个 token 实际只激活约 23B保证推理便宜再叠加稀疏注意力保证长上下文不爆炸。三招叠加才有了「前沿性能 极低成本」的组合拳。三、稀疏注意力MSA到底解决了什么问题3.1 标准注意力的老毛病O(n²)标准 Transformer 的自注意力需要让序列里每个 token 都和其他所有 token 两两算一遍相关性。序列长度是 n计算量和显存占用就随 n² 增长。上下文从 4K 拉到 1M是 250 倍的长度但注意力的开销大致是6 万倍级别的膨胀。这正是「长上下文很贵、很慢」的根本原因。MiniMax 更早的 MiniMax-Text-014560 亿参数、每 token 激活 45.9B就已经在用混合的线性注意力Lightning Attention思路来对抗这个问题M3 则把它进一步演进成了MSA。3.2 MSA 的关键思路把「看哪些 KV」和「怎么算注意力」拆开按照社区对 M3 架构图的解读MSA 最核心的一步是把注意力拆成两个动作先筛选Lightning Indexer / 预过滤阶段用一个轻量的「索引器」分支快速判断——对当前 token 来说历史里的哪些 Key/Value 块是真正值得看的。再计算块稀疏注意力只对被选中的那一小部分 KV 块做完整的注意力计算其余直接跳过。换句话说模型不再「无脑地」对全序列做稠密注意力而是先用便宜的方式定位重点再把宝贵的算力花在刀刃上。3.3 工程上的收益根据 NVIDIA 的部署博客MSA 用一个预过滤阶段替换了传统的二次方注意力带来的实测收益包括连续 KV cache 访问速度提升 4 倍以上每 token 计算成本约为原来的 1/20能够高效支撑100 万 token级别的上下文窗口。此外M3 的层结构是混合的前几层用「稠密注意力 稠密 MLP」保证基础表达能力后续大部分层则采用「稀疏注意力 MoE」来省算力。MoE 部分用的是 Sigmoid 路由带有路由偏置校正并配有一个共享专家shared expert。四、和其他主流模型的定位差异2026 年这一批新模型大致可以分成两条路线路线一把中端模型做到接近旗舰。典型是 Anthropic 的Claude Sonnet 52026 年 6 月 30 日发布。它把原本只有 Opus 级大模型才有的自主 Agent、工具调用、浏览器操作能力下放到更便宜的 Sonnet 档标配 100 万 token 上下文SWE-bench Verified 达到 72.7%在 Terminal-Bench 2.1 上甚至以 80.4% 反超旗舰 Opus 4.8 的 74.6%。它解决的是「性价比曲线」问题。路线二从架构层面改写成本结构。这正是MiniMax M3的路子。它不满足于「同样的 Transformer、把参数调便宜」而是直接换掉注意力机制本身。对于长上下文、代码库理解、Agent 长链路这类场景这种改动的边际收益会随着上下文变长而不断放大。两条路线并不冲突但对做工程落地的人来说信号很清晰当上下文越来越长、Agent 链路越来越深时架构级的效率优化而非单纯堆参数会越来越重要。五、对国内开发者的几点实操启示长上下文不再是「土豪专属」。如果你之前因为 O(n²) 的成本而不敢把整个代码仓库、整本手册塞进上下文稀疏注意力类模型给了你重新评估的理由。可以针对自己的 RAG / 长文档场景做一次成本对比测试。关注「每 token 激活参数」而不只是总参数。MoE 模型的总参数决定能力上限但推理成本主要由激活参数决定。M3 的 428B 总参 / 23B 激活是理解其成本优势的关键。部署生态正在跟上。vLLM、TensorRT-LLM、NVIDIA NeMo 等主流推理框架均已支持 MiniMax-M3这意味着自建推理服务的门槛在下降可以纳入选型评估。多模态是默认项不是附加项。M3-VL 原生支持视觉输入对需要「文档 截图 代码」混合理解的 Agent 场景很友好。六、小结MiniMax M3 这条新闻的真正价值不在于又一个「大参数、高榜单」的模型诞生而在于它把**「长上下文很贵」这个行业默认假设**给动摇了。用「先筛选、再计算」的稀疏注意力把百万上下文的每 token 成本压到 1/20这是一次从架构底层出发的效率革命。在「堆参数」逐渐边际递减的当下这类架构级创新可能才是接下来最值得国内工程师持续跟踪的方向。参考资料 / 信息来源MiniMax 官方博客MiniMax M3: Frontier Coding, 1M Context, Native MultimodalityHugging Face 模型卡MiniMaxAI/MiniMax-M3 READMENVIDIA 开发者博客Deploy Long-Context Reasoning and Agentic Workflows with MiniMax M3社区架构解读Decoding M3’s Attention from a Single DiagramMiniMax-01 开源仓库MiniMax-AI/MiniMax-01 (GitHub)行业动态汇总LLM News Today (August 2026)Claude Sonnet 5 参考Claude Sonnet 5 Benchmarks Explained (Vellum)本文为编译整理技术细节以官方文档为准。如有翻译或理解偏差欢迎在评论区指正交流。转载请注明来源。#大模型#MiniMax#稀疏注意力#长上下文#MoE#AI工程化
)
