国内首个 Frontier 三件套开源大模型：MiniMax M3 完整技术拆解|minimax|三件套|上下文|新论文|模态|算法|调用

刚刚，MiniMax M3 正式官宣发布。

根据官方介绍，MiniMax M3 是国内首个同时具备「Coding Frontier+ 1M 上下文窗口 + 原生多模态」三个核心能力的开源模型，同时还推出了配套代码智能体产品 MiniMax Code。不过，开发者体验下来，M3 的体感全面超过Sonnet 4.6，但官方坦诚表示，其与 Opus 4.7、GPT-5.5 仍存在一定差距。

具体来说，在 SWE-Bench Pro 上超过了 GPT-5.5 和 Gemini 3.1 Pro，接近 Claude Opus 4.7。而在面向自主 Agent的端到端评测 Claw-Eval 上，M3 拿到了最高分。

更为重要的是，在此之前，能同时跑通这三项的只有极少数闭源模型，例如 claude opus 4.8、gemini 3.1、gpt5.5；而 MiniMax M3 是第一个把完整 frontier 能力带进开放世界的模型。

也就是说，M3 的真正难点不在于单项能力的突破，而在于让三项能力在同一个模型中协同工作，但长程 Agent 任务需要超长上下文支撑；多模态理解能力影响论文复现、代码审查等复杂场景的上限；而编程能力则直接决定了 Agent 的自主执行质量，任何一项的短板，都会拖垮整体表现。

那么，在“集齐”叙事之后，M3 在技术路径上做了哪些关键选择？这些选择背后的理念是什么？实际效果如何？

为什么 Frontier Agent 必须同时具备三项能力？

如果只看单轮问答，模型能力可以被拆成文本、代码、视觉等多个独立维度。但 Agent 场景不是这样。

一个真实的软件工程任务里，模型要处理的信息通常包括：

代码仓库结构、依赖关系和历史实现；
README、issue、PR、测试脚本和报错日志；
用户多轮反馈、方案变更和临时约束；
论文图表、产品截图、设计稿、表格和桌面应用界面；
工具调用轨迹、失败记录和中间产物。

这意味着 Coding、长上下文、多模态不是三个并列卖点，而是一个系统能力的三个接口。

图 1：MiniMax M3 的三块 Agent 地基

所以 M3 的技术叙事不是“某项能力很强”，而是这三项能力开始在一个国产开源模型中汇合。

MSA：1M 上下文的关键不是窗口，而是注意力计算

长上下文的难点从来不是把 context_length 写成 1M，而是如何在 1M token 下仍然算得动、跑得快、找得准。

标准 Transformer 的全注意力需要让每个 query 关注所有 key。序列长度增长时，注意力计算量按近似平方级上升。窗口从 128K 扩到 1M，不是多买几张卡就能解决的问题，必须在注意力机制上动刀。

MiniMax 给出的答案是MSA，MiniMax Sparse Attention。架构如下图：

官方披露的 MSA 有三个关键词：

稀疏注意力：通过筛选机制避免全量 token 两两交互；
更精确的 KV 分块：相比 DSA、MoBA 等方案，提高有效上下文覆盖；
硬件友好算子：采用 KV outer gather Q，以 KV 块为外层聚合命中的 query，使每块 KV 只读一次、访存更连续。

官方数据称，在 100 万上下文下，M3 每 token 计算量仅为上代模型的 1/20；prefilling 阶段超过 9 倍加速，decoding 阶段超过 15 倍加速；在 M3 的 head 配比下，算子比开源 Flash-Sparse-Attention、flash-moba 快 4 倍以上。

这组数字真正重要的地方不是“快了多少”，而是说明 MiniMax 把长上下文问题同时放在了两个层面解决：

算法层：减少不必要的注意力连接；
系统层：让剩下的连接更适合 GPU 执行。

图 2：稀疏注意力路线对比

1. 从固定稀疏到动态稀疏：国际前沿的共同方向

稀疏注意力不是新概念。Longformer、BigBird 这类早期方案通过滑动窗口、全局 token、随机连接等固定模式降低复杂度。它们证明了“不是所有 token 都必须互相关注”，但问题是固定模式很难适配真实任务。

代码仓库、论文、终端日志这类上下文没有稳定结构。关键 token 可能出现在几千行之前，也可能藏在某个工具输出里。固定窗口容易漏掉远距离依赖。

因此，近年的前沿方向明显转向动态稀疏：让模型或检索模块根据输入内容决定应该看哪里。

DeepSeek 的 DSA、Moonshot / Kimi 相关工作中的 MoBA、以及更通用的 NSA、SeerAttention 等研究，都在探索“先筛选，再精算”的路线。M3 的 MSA 也处在这条技术主线上。

如上表，MSA 的差异化不是“稀疏”本身，而是两个更工程化的问题：

第一，稀疏之后到底能不能找准？如果筛选机制漏掉关键上下文，长窗口越长，模型越容易出现“看似读了很多，其实没看对”的问题。

第二，找准之后能不能高效算？稀疏注意力会带来不规则访存。如果实现方式让 GPU 频繁随机读取、重复加载 KV 块，理论计算量下降也未必转化成真实速度。

MSA 试图同时回答这两个问题：用更精确的 KV 分块解决有效覆盖，用 KV 外层聚合命中 query 的方式解决访存效率。

2、MSA 与 DeepSeek、Kimi 路线的共识与非共识

从公开资料来看，M3、DeepSeek、Kimi 等长上下文模型已经形成几个共识。

共识一：全注意力不适合无脑扩到百万级上下文。百万 token 下继续依赖全注意力，成本、延迟和显存都会失控。稀疏化是通向可用长上下文的主路线之一。

共识二：稀疏不能只是固定窗口。Agent 任务的关键依赖非常不规则。单纯滑窗或固定块很难处理跨文件引用、长日志回溯和多轮用户约束。

共识三：长上下文必须软硬结合。算法节省计算只是第一步，GPU 访存、kernel 调度、prefill/decode 分离优化，都会直接决定最终体验。

不同点在于，几条路线对“稀疏粒度”和“硬件执行顺序”的取舍不一样。

如果用一句话概括： DSA 更强调“选哪些 token / KV”，MoBA 更强调“选哪些块”，MSA 则把“怎么分块、怎么读块、怎么让 GPU 连续高效地算”放到了前台。

这正是 MSA 比较值得关注的地方。过去很多长上下文方案容易停留在算法叙事，但目前披露的MSA信息中，把算子层实现当成核心卖点。这更接近产业模型的真实需求：模型要被大量用户和 Agent 长时间调用，最终必须算得便宜、跑得稳定。

3、1M 上下文真正要测什么？

M3 的 1M 版本还未正式开放，因此不能提前下结论。但等上线后，真正应该测的不是“能不能塞进 1M token”，而是以下几类任务：

如果 M3 在这些任务上稳定，1M 上下文才不只是窗口参数，而是可被 Agent 真实使用的工作记忆。

原生多模态：不是“看图插件”，而是统一 token 空间

M3 的第二条技术主线是原生多模态。MiniMax 披露，M3 从 Step 0 开始做多模态混合训练，支持图片和视频输入，并能操作电脑桌面。

这和“文本大模型 + 外接视觉编码器”的思路不同。

外接式多模态通常是先训练一个强文本模型，再用视觉编码器、投影层或适配器把图像特征接进去。这条路线工程上高效，但模态之间的语义对齐更多发生在后期。

原生多模态则希望在训练早期就让文本、图像、视频等信息进入同一建模过程。模型不是先成为文本专家，再学习“看图”，而是一开始就学习混合模态序列中的规律。

图 3：原生多模态与后接式方案对比

M3 特别强调了interleaved data，也就是文本、图片等模态在同一序列中自然交错的数据。MiniMax 称，在重构数据管线后，训练数据 token 规模已可提升至 100 万亿量级。

这个判断与国际多模态研究的趋势一致。Flamingo、Chameleon、Emu3 等工作都在不同方向上证明，交错图文、早期融合、统一 next-token 建模对通用多模态能力有价值。

原生多模态对 Coding Agent 的意义很直接。

今天的开发任务不是纯文本。用户会给模型设计稿截图、控制台截图、论文曲线图、网页录屏、Excel 表格和桌面应用界面。模型如果只能把这些输入转成一段 caption，再交给文本模型推理，信息会在转换过程中损失。

M3 的论文复现案例就说明了这一点。复现一篇机器学习论文，不只是读 PDF 正文，还要理解图表趋势、公式关系、实验设置、代码实现和输出日志。长上下文让这些信息能放在同一线程里，原生多模态让模型有机会在同一语义空间里处理它们。

MiniMax 把一篇 ICLR 2025 Outstanding Paper Award 获奖论文扔给它，这篇论文研究的是大模型微调过程中的学习动力学。M3 自主运行了接近 12 小时，全程自主产出 18 次 commit 与 23 张实验图表，并跑通了核心实验：不仅成功吻合了 SFT 阶段的预测概率变化趋势，清晰观测到 DPO 实验重点讨论的squeezing 效应，还顺利验证了原论文提出的 Extend 缓解方法。

换句话说，原生多模态不是“模型能不能看图”的问题，而是 Agent 能不能理解真实工作现场的问题。

交互式用户模拟器：Coding SOTA 的训练范式变化

M3 第三条技术主线是 Coding / Agentic 能力。

官方给出的 M3 成绩包括：

但对技术受众来说，更值得关注的不是这些数字本身，而是 MiniMax 对 Coding 训练范式的判断。

当前大部分 Coding Benchmark 仍然偏单轮任务：给模型一个 issue 或需求，让它一次性修复。这个设定有价值，但和真实开发体验有距离。

真实开发通常是多轮协作：

用户先提出一个不完整需求；
Agent 需要读项目、提出方案、执行修改；
运行测试后发现新错误；
用户补充约束或改变优先级；
Agent 需要保留前文状态，重新规划任务；
多轮之后交付一个可运行结果。

MiniMax 因此构建了交互式用户模拟器框架，让模型在训练和评测阶段接触更接近生产环境的行为模式，包括需求补充、方案讨论、反馈修正、连续任务切换和复杂项目迭代。

图 4：交互式用户模拟器闭环

这代表了一个重要变化：Coding Agent 的训练目标正在从“生成正确代码”转向“完成长期协作任务”。为此，MiniMax 也用几道题目测试了它的实际表现。

FP8 矩阵乘（GEMM）是大模型推理中计算量最集中的环节之一，也是优化难度最高的之一。通常需要资深团队1-2 周的投入。

MiniMax 把这道题丢给 M3，起点只有一份任务描述、一个 benchmark 脚本、一个跑不起来的 Triton 骨架，没有任何 reference 高性能实现可供参考。但在随后约 24 小时的连续执行中，M3 共完成 147 次 benchmark 提交、1959 次工具调用，完全自主地走完了从 baseline 实现到生产级优化的全部路径。

最终M3 经过 6 轮标志性优化，将 Hopper FP8 硬件峰值利用率从首版 7.6% 推进至 71.3%，实现相较于原始版本的 9.4× 加速。

除此之外，MiniMax 还能自己训练模型。

MiniMax 在 PostTrainBench 上让它接手四个只完成预训练的 Base 模型，任务是在 12 小时内自主完成数据合成、训练、评测、迭代的全部流程，最终让这些模型在数学推理、工具调用、科学知识推理、代码生成等任务上具备基本能力。

整个流程全程无人干预，M3 需要自己决定合成什么样的数据、选择什么训练策略、如何根据评测结果调整下一轮方案。M3 最终得分 0.37，略低于 Opus 4.7（0.42）和 GPT-5.5（0.39），但明显领先其余模型。

以上几个长程案例都在说明，成功不取决于一次输出，而取决于长时间闭环：计划、执行、验证、修正，再继续执行。

这也是为什么 MSA 和交互式训练要放在一起看。没有长上下文，模型很难记住长程工具轨迹；没有真实交互式训练，长上下文也可能只是“更大的输入框，不会自动变成稳定协作能力。

M3 的下一步是做你的“AI同事？”

M3 这次发布同时更新了 MiniMax Code。MiniMax Code 被定位为专为 M3 设计、并与 M3 一起训练的 Agent 产品，目标是对标 Claude Code / Codex。

这点不只是产品信息，也解释了 M3 的技术取舍。

如果目标只是聊天，1M 上下文、原生视频输入、长期工具调用训练都不是最高优先级。但如果目标是 Coding Agent，三者就是刚需。

这也解释了为什么 M3 的成本结构值得关注。Agent 调用天然消耗大量 token：它要读仓库、扫日志、反复运行测试、生成 diff、总结失败原因。如果模型能力接近前沿，但调用成本仍然很高，就很难成为日常工具。

MiniMax 新 Token Plan 给出的价格是：

以 Max 套餐为例，每月 119 元可获得 18亿+ token，对比来看，Claude Max 套餐每月 100 美元（约合人民币 720 元）提供约 9 亿 token，同价位下 M3 的 Token 容量约为其 2 倍；而 DeepSeek API 按量计费的价格为每百万 Token 2 元（输入）/ 8 元（输出），M3 Max 套餐的均摊成本同样显著更低。

这样亲民的定价，让 1M 上下文更加普惠适用，更贴合开发者的真实需求。

这意味着 M3 的竞争策略不是只拼“最强模型”，而是拼一个更完整的工程组合：足够前沿的能力、足够长的上下文、足够低的 token 成本、以及专门适配模型的 Agent 产品。