6 月 1 日，MiniMax 正式发布新一代模型 MiniMax M3。

如果只把它理解为一次常规升级，很容易错过这次发布真正值得关注的地方。M3 想回答的不是“模型能不能写几段代码”，而是一个更接近工程现实的问题：当任务跨越大量文件、持续多个小时、需要调用工具，还夹杂图片、视频和桌面操作时，模型能否继续稳定工作？

MiniMax 给出的答案可以概括为三条主线：面向 Coding 与 Agent 的能力强化、最高 1M tokens 的上下文窗口、原生多模态能力。而把这三者连接起来的关键，是新的稀疏注意力架构 MSA。

一、M3 的目标，不只是“更会写代码”

官方将 M3 定位为面向 Coding 与 Agentic Work 的前沿模型。相比一次性生成代码，Agent 型任务更像一段持续推进的工程过程：理解需求、拆解任务、读取上下文、调用工具、执行、验证、修正，再进入下一轮。

这意味着，评价模型时不能只看某一次回答是否漂亮。更重要的是，它能否在更长的任务链条里保持方向感，能否在出错后继续修正，能否把工具调用真正转化为可交付结果。

按照 MiniMax 官方披露，M3 在多项 Coding 与 Agent 评测中给出了较有竞争力的结果：

评测	MiniMax M3 官方披露成绩
SWE-Bench Pro	59.0%
Terminal-Bench 2.1	66.0%
SWE-fficiency	34.8%
KernelBench Hard	28.8%
MCP Atlas	74.2%

这些数字值得关注，但也需要谨慎解读。官方页面列出了较详细的评测方法，其中部分结果来自内部基础设施或内部评测。在更多第三方复测出现之前，最稳妥的说法是：M3 展示了值得验证的能力，而不是已经凭一张榜单完成了定论。

二、为什么 1M 上下文很重要？

M3 支持最高 100 万 tokens 的上下文窗口。官方模型页同时注明，API 至少保障 512K 上下文。

更大的上下文窗口不是为了让聊天记录无限增长。它的价值在于让模型可以在一次任务中接触更完整的信息，例如：

• 读取更大规模的代码仓库与跨文件依赖；
• 同时处理论文、代码、实验日志与评测反馈；
• 理解更长的视频内容；
• 在长程 Agent 任务中保留更多执行轨迹。

但上下文越长，计算与访存成本通常越突出。传统全注意力机制的计算开销会随上下文长度快速增长。把窗口做大只是第一步，能否以可接受的速度和成本真正用起来，才是关键。

三、MSA：这次升级的核心变量

MiniMax 为 M3 引入了 MSA，也就是 MiniMax Sparse Attention。

按照官方说明，MSA 会先筛选更相关的 KV blocks，再采用 “KV outer gather Q” 的方式组织计算：以 KV blocks 作为外层循环，聚合命中这些 blocks 的 Query。这样可以减少重复读取，并让内存访问更加连续。

官方披露，在 1M 上下文长度下：

• 单 token 计算量约为上一代模型的 1/20；
• Prefill 阶段加速超过 9 倍；
• Decode 阶段加速超过 15 倍。

这组数据比“上下文达到 1M”更值得工程团队关注。对生产系统来说，窗口上限是规格，实际吞吐、延迟和成本才决定能力能否进入日常工作流。

四、原生多模态，意味着 Agent 的输入边界继续扩张

M3 的另一条主线是原生多模态。

官方表示，M3 从训练早期就混合文本、图片等模态，并重建了数据管线，将训练数据扩展到 100T+ 量级。模型支持图片、视频输入，还可以进行桌面操作。

这对 Agent 场景很重要。现实中的工作任务很少只存在于纯文本里：需求可能写在文档中，数据位于表格中，报错出现在截图中，操作还需要跨越浏览器、本地客户端和文件系统。原生多模态让模型更有机会从“对话工具”走向“工作流参与者”。

MiniMax 同时更新了 MiniMax Code。官方给出的方向包括多 Agent 协作、持续反思与纠错，以及基于桌面环境执行跨应用任务。

五、几个值得观察的真实任务

为了展示长程执行能力，官方页面列出了几个案例。

其中一个案例是复现 ICLR 2025 优秀论文。M3 连续运行接近 12 小时，完成 18 次代码提交并生成 23 张实验图。另一个案例是优化 NVIDIA Hopper GPU 上的 FP8 GEMM kernel：在约 24 小时里完成 147 次 benchmark 提交和 1,959 次工具调用，将硬件峰值利用率从 7.6% 提升至 71.3%，对应 9.4 倍加速。

这些案例的意义不只在最终分数。它们展示的是一种新的模型使用方式：把模型放入一个能够执行、验证和迭代的环境中，让它持续推进任务。

当然，案例仍然来自官方披露。工程团队真正要做的，不是照搬结论，而是把自己的任务集拿来跑一遍。

六、谁适合优先测试 M3？

如果团队正在处理以下任务，M3 值得进入候选列表：

• 跨文件、跨模块的代码理解与修改；
• 需要读取长文档、长日志或较大仓库的 Agent；
• 图文混合输入与视频理解；
• 持续数小时、多轮修正的研究或工程任务；
• 对成本敏感，但仍希望尝试长上下文与多模态能力。

但“值得测试”不等于“可以直接替换”。上线前至少需要用真实业务验证四件事：正确率、工具调用稳定性、延迟与成本、失败模式。尤其是涉及自动修改代码、桌面操作或生产数据时，应当保留权限隔离、日志记录、人工确认与回滚机制。

结语

MiniMax M3 的看点，不是单独把某一个参数推高，而是试图把 Coding 与 Agent、1M 上下文、原生多模态放进同一个模型里，再用 MSA 解决长上下文的效率问题。

这条路线很明确：模型正在从“回答问题”转向“持续完成任务”。

接下来真正值得观察的，是技术报告、开放权重与第三方复测。MiniMax 在官方发布页中表示，将在随后 10 天内发布技术报告并开放相应模型权重。对开发者来说，最实际的动作也很简单：不要只看榜单，用自己的任务集做一次场景化验证。