MiniMax M3 正式发布：首创 MSA 稀疏注意力架构，1M 上下文开源模型对标海外旗舰

MiniMax 正式发布新一代旗舰大模型 M3。

这次 M3 的关键词非常明确：MSA 稀疏注意力架构、1M Token 上下文、原生多模态、强 Agent 能力、开源对标海外旗舰。

和普通模型升级不同，MiniMax M3 的核心不是单纯增加参数或刷新单项榜单，而是围绕真实生产力场景做系统优化。它面向 AI 编程、长文档处理、多模态对话、工具调用、长线程自主任务和企业级 Agent 工作流，试图解决大模型在真实应用中最常见的几个问题：上下文不够长、长文本处理太慢、工具调用不稳定、任务执行无法持续、部署成本过高。

MiniMax 开放平台信息显示，MiniMax-M3 已于 2026 年 6 月 1 日正式发布，面向 Agent 推理、工具调用、代码、多模态 Chat 输入和长上下文任务。

M3 的最大亮点：自研 MSA 稀疏注意力架构

MiniMax M3 最重要的技术变化，是采用自研 MSA 架构。

MSA 可以理解为一种面向超长上下文场景的稀疏注意力机制。它的核心目标，是让模型在处理 1M Token 级别上下文时，不再对所有 Token 进行同等强度的全量计算，而是更高效地识别重点信息，把算力集中在真正有用的部分。

传统 Transformer 的全量注意力在长上下文场景下会遇到很大的计算瓶颈。输入越长，计算量和显存压力就越高。尤其是百万 Token 级别上下文，如果继续依赖全量注意力，推理成本和响应延迟都会变得非常高。

M3 的 MSA 架构，正是为了解决这个问题。

它让模型在长文档、长代码、长对话和多轮 Agent 任务中，能够更快处理上下文，并减少大量无效计算。

1M 上下文，不只是“能装下”，更要“跑得动”

现在很多大模型都开始强调长上下文能力，但真正的难点并不是窗口写到 1M，而是模型能不能高效使用 1M 上下文。

一个模型支持 1M Token，只说明它理论上可以接收非常长的输入。
但如果读取太慢、生成太慢、成本太高，实际使用价值就会大幅下降。

MiniMax M3 的重点，是让 1M 上下文更适合真实生产环境。

公开资料显示，M3 在 1M 上下文下，每 Token 计算量仅为上代模型的大约十分之一，同时在预填充和解码阶段都实现明显加速。此前关于 M3 架构的公开信息也提到，相比 M2，M3 在 Prefill 阶段提速 9.7 倍，在 Decoding 阶段提速 15.6 倍。

这意味着，当用户上传长文档、大型代码仓库、企业知识库资料或复杂任务历史时，M3 可以更快完成初始处理，并以更高效率生成结果。

Prefill 和 Decoding 提速，直接影响真实体验

长上下文模型里有两个非常关键的阶段：Prefill 和 Decoding。

Prefill 可以理解为模型先读取和处理用户输入的上下文。
Decoding 则是模型开始逐步生成回答。

如果 Prefill 慢，用户上传一份长报告或一个代码仓库后，要等很久才能看到模型开始工作。
如果 Decoding 慢，模型生成内容时就会像“慢慢吐字”，影响交互体验。

M3 在这两个阶段都强调提速，说明它并不只是让上下文窗口变大，而是在优化完整使用链路。

这对 AI 编程、长文档问答、企业知识库、Deep Research 和 Agent 自动化任务都很重要。

比如开发者让模型理解一个大型项目，如果 Prefill 快，模型可以更快完成项目读取；如果 Decoding 快，模型可以更快输出修改方案、代码和解释。

原生多模态：不只读文字，也能处理图像输入

MiniMax M3 还具备原生多模态能力。

这意味着它不只是文本大模型，也可以在对话中处理多模态输入，适合图文混合任务。

这类能力在真实办公和开发场景中非常实用。

用户可能上传：

截图；
设计稿；
图表；
报错图片；
表格截图；
产品图片；
文档扫描件；
网页界面；
多模态资料组合。

M3 如果能同时处理文字和视觉输入，就可以支持更多复杂任务，比如看设计稿生成前端代码、分析图表生成报告、理解截图定位问题、读取图文混排资料并总结重点。

这也是它对开发者和企业更有吸引力的地方。

未来 AI 助手不会只面对纯文本，而是要处理用户真实工作环境中的各种信息形式。原生多模态能力，让 M3 更接近实际生产场景。

Agent 编程能力：从代码生成走向任务交付

MiniMax M3 的另一个重点，是 Agent 和 Coding 能力。

公开报道显示，M3 在多个编程与 Agent 能力评测中表现突出，并在 SWE-Bench Pro 等真实软件工程评测中超过 GPT-5.5 和 Gemini 3.1 Pro，接近 Claude Opus 4.7。

这说明 M3 的编程能力并不只是“写一段代码”，而是更接近真实软件工程任务。

真实开发任务通常包括：

理解需求；
读取项目文件；
定位问题；
修改多个文件；
运行测试；
分析报错；
继续修复；
生成文档；
最终交付可用结果。

这类任务非常依赖模型的长上下文、工具调用、代码理解和持续执行能力。

M3 支持 1M 上下文，又面向 Agent 推理、工具调用和代码任务优化，因此更适合 AI 编程工具和自主开发 Agent。

长线程自主规划能力，适合复杂生产力任务

你提供的信息里提到，M3 展现出强大的长线程自主规划能力。

这点非常重要。

很多模型短任务表现不错，但一旦任务变长，就容易出现问题：

忘记最初目标；
重复无效步骤；
工具调用混乱；
中途逻辑跑偏；
无法根据错误继续修正；
长时间任务状态管理不稳定。

MiniMax M3 强调长线程自主任务能力，说明它希望解决 AI Agent 在复杂生产力任务中的持续执行问题。

比如：

复现论文；
完成复杂研究；
分析大型代码库；
执行多小时开发任务；
进行多轮工具调用；
完成企业级办公流程；
处理长文档和多文档组合任务。

这类任务不是一次回答就能完成，而是需要模型持续规划、执行、反馈和修正。

M3 的价值正在于此：它不仅能回答问题，也更适合承担完整任务链路。

开源策略，让开发者生态获得更多机会

MiniMax M3 的另一个重要看点，是全面开源。

在当前大模型竞争中，开源模型的意义非常大。

对于开发者来说，开源意味着更高的可控性。
对于企业来说，开源意味着更容易评估私有化部署和定制化应用。
对于研究者来说，开源意味着可以深入分析模型架构、训练路线和长上下文机制。
对于生态来说，开源意味着更多工具、插件、Agent 框架和应用可以围绕模型快速生长。

M3 同时具备 1M 上下文、原生多模态、Agent 编程和 MSA 架构，这种组合如果开放给开发者，将为长文档处理、AI 编程、企业知识库、多模态助手和自主 Agent 带来更多可能。

相比单纯提供 API，开源策略能让开发者拥有更大的探索空间。

为什么 MSA 对开源模型尤其重要？

开源模型能否被广泛使用，不只看能力，也要看成本。

如果模型能力很强，但推理成本高、部署要求高，普通开发者和中小团队依然很难真正用起来。

MSA 架构的价值就在于提升效率。

当 1M 上下文下的每 Token 计算量大幅下降，开发者就更容易把长上下文能力放进真实产品。

比如：

开发长文档问答工具；
构建代码仓库分析助手；
部署企业知识库 Agent；
开发多模态办公助手；
搭建 Deep Research 工作流；
制作长线程自主任务系统。

如果没有效率优化，1M 上下文可能只是少数大厂能负担的能力。
如果 MSA 能真正降低计算成本，长上下文就有机会成为更多开发者可用的基础能力。

对 AI 编程有什么价值？

M3 对 AI 编程的价值非常直接。

过去很多 AI 编程模型受限于上下文长度，只能看局部代码。开发者让模型修一个复杂 Bug，模型可能只能理解当前文件，却看不到跨文件依赖、配置、测试和项目结构。

1M 上下文可以让模型读入更多项目资料。

再结合 MSA 提升效率，M3 更适合处理：

大型代码仓库理解；
多文件工程修改；
跨模块 Bug 修复；
前后端联动开发；
测试用例生成；
长日志分析；
性能优化；
长时间自主编码任务。

这意味着 AI 编程正在从“代码补全”走向“项目级协作”。

开发者不再只是让 AI 写一个函数，而是可以让它理解整个项目，并参与完整研发流程。

对长文档和企业知识库有什么价值？

企业最常见的大模型需求之一，就是长文档处理。

企业内部有大量资料：

合同；
财报；
技术文档；
制度文件；
客服记录；
会议纪要；
项目方案；
研发资料；
产品说明；
知识库文章。

这些资料通常很长，信息分散，格式复杂。

如果上下文不够长，模型只能看到局部；
如果上下文很长但处理慢，体验又不好；
如果成本太高，企业无法规模化使用。

M3 的 1M 上下文和 MSA 架构，可以让企业更高效地处理长文档和多文档组合任务。

比如：

从多份文档中查找答案；
总结长篇报告；
审阅复杂合同；
分析跨部门资料；
整理会议与项目记录；
构建内部知识问答系统。

这类场景会是 M3 很重要的落地方向。

对多模态办公有什么价值？

M3 的原生多模态能力，也让它适合更多办公场景。

现实办公资料往往不是纯文本。

比如：

一张报错截图；
一个设计稿；
一份扫描 PDF；
一张业务流程图；
一份图表报告；
一张产品图片；
一个网页界面截图。

用户希望 AI 不只是读文字，也能看懂图像里的信息，并结合文本完成任务。

M3 如果在多模态输入、长上下文和工具调用上保持稳定，就可以支持很多办公自动化场景：

截图分析；
图表解读；
设计稿转代码；
扫描件内容整理；
图文混合报告总结；
多模态资料问答；
产品图文案生成。

这会让 AI 办公助手更接近真实工作方式。

对 Agent 应用有什么价值？

Agent 应用最需要的是长期记忆、工具调用、任务规划和持续执行能力。

一个 Agent 任务可能会产生大量信息：

用户目标；
任务计划；
工具返回；
文件内容；
中间结果；
错误日志；
修改记录；
执行历史。

如果模型上下文不够长，Agent 很快就会丢失关键状态。
如果模型推理太慢，Agent 执行效率会很低。
如果模型不会调用工具，Agent 只能停留在聊天层面。

M3 面向 Agent 推理、工具调用和长上下文任务设计，因此非常适合用于：

AI 编程 Agent；
Deep Research Agent；
办公自动化 Agent；
企业知识库 Agent；
多模态助手；
多智能体协作系统；
长周期自主任务平台。

这也是 M3 被看作“对标海外旗舰”的重要原因之一。

M3 代表大模型竞争方向的变化

MiniMax M3 的发布，也说明大模型竞争正在发生变化。

过去行业更关注：

参数规模；
榜单分数；
回答质量；
写作能力；
数学能力；
代码能力。

现在竞争重点正在转向：

长上下文效率；
推理成本；
Agent 执行能力；
工具调用稳定性；
多模态任务处理；
真实生产力场景；
开源生态建设。

M3 的 MSA 架构、1M 上下文和开源策略，正是这个趋势的体现。

未来模型不只是要“聪明”，还要更快、更省、更能接入工具、更适合长任务、更容易被开发者部署和使用。

仍需关注哪些落地细节？

虽然 M3 的发布信息非常亮眼，但开发者和企业在使用前仍然需要关注一些实际问题。

比如：

开源许可证是否适合商业使用；
模型权重和代码是否完整开放；
本地部署需要多少显存和算力；
1M 上下文下实际推理成本如何；
多模态输入支持哪些格式；
API 价格如何；
工具调用能力是否稳定；
中文、英文、代码、多模态表现是否均衡；
企业私有化部署是否方便；
长任务执行是否能稳定复现。

这些细节会决定 M3 能否从技术亮点，变成开发者和企业真正长期使用的模型底座。

总结：MiniMax M3 的重点，是让长上下文、Agent 和多模态真正进入开源生产力场景

MiniMax M3 正式发布，代表国产开源大模型在长上下文、多模态和 Agent 能力上的一次重要升级。

它采用自研 MSA 稀疏注意力架构，支持 1M Token 上下文，在每 Token 计算量、预填充速度和解码效率上相比前代模型有明显提升。同时，M3 还具备原生多模态能力和强 Agent 编程能力，适合 AI 编程、长文档处理、企业知识库、多模态办公和长线程自主任务。

更重要的是，M3 选择全面开源，让开发者有机会围绕它构建更多工具、Agent 框架和生产力应用。

如果说过去大模型竞争主要看谁回答得更好，那么 M3 所代表的新方向是：谁能更高效地处理真实任务，谁能让 1M 上下文真正可用，谁能把 Agent 能力带进生产流程，谁就更有机会成为下一代 AI 应用的底座。