MiniMax M3深度测评：1M上下文与59% SWE-Bench能力解析

2026 年 6 月 1 日，MiniMax 正式推出新一代旗舰语言模型 M3。

翻阅官方博客与技术报告，一组数据格外扎眼：SWE-Bench Pro 评测 59.0%，超越 GPT-5.5 与 Gemini 3.1 Pro；在 1M tokens 上下文窗口条件下，每 token 计算量仅为上代模型二十分之一；原生多模态从预训练第一天起就采用混合训练策略。

客观来说，这三个方向任意一个都有模型表现不错。但能将 Coding & Agentic 能力、超长上下文、原生多模态整合进单一模型，且各项指标均达前沿水平——此前仅有极少数闭源模型做到。M3 能否支撑这一定位？下面逐项剖析。

1. MSA 架构：让 1M 上下文真正落地

痛点在哪

标准 Transformer 的全注意力机制存在先天缺陷：计算量随上下文长度呈平方级增长。100K tokens 尚可支撑，一旦达到 1M tokens，计算开销就会急剧膨胀。

业界主流方案多围绕稀疏注意力展开——不计算所有 token 的注意力，而是筛选关键 token 计算。但关键在于：如何筛选？筛选精度如何？筛选之后计算性能如何？

MSA 的双阶段设计

MiniMax 的答案是 MSA（MiniMax Sparse Attention），一种两阶段稀疏注意力架构：

第一阶段：Index Attention。使用轻量索引 query，对 KV 缓存执行 Block Max Pooling，从海量 KV 块中选出 Top-k 高相关性块。该阶段计算成本极低，因为索引 query 数量远少于实际 query 数量。

第二阶段：Sparse Attention。仅对选中的 Top-k 块执行完整稀疏注意力计算。相比全注意力方案，计算量大幅缩减。

与 DSA（Dynamic Sparse Attention）和 MoBA（Mixture of Block Attention）等方案对比，MSA 的核心差异在于 KV 分块策略更精细——基于同样的初筛思路，但能更精准地切分 KV 块，有效上下文覆盖率更高。

算子层优化：KV Outer Gather

架构设计仅是第一步，底层算子往往是真正的性能瓶颈。MSA 采取 KV Outer Gather Q 方式：以 KV 块为外层循环，聚合命中该块的 query，然后批量计算。这样带来的优势是：每块 KV 数据只读取一次，访存连续；在 M3 的 head 配比下，计算访存比显著优于通行方法；相比开源的 Flash-Sparse-Attention、Flash-MoBA，速度提升超过 4 倍。

实际性能收益

官方公布的对比数据相当抢眼：

官方强调，多个对照实验中 MSA 的绝大部分性能与全注意力持平。稀疏化未带来明显的能力衰减，这一点至关重要——注意力方案好不好，最终要看模型是否变笨。

为什么 Agent 场景尤其需要长上下文

如果只是聊天问答，4K 或 8K 上下文窗口绰绰有余。但 Agent 场景截然不同。一个 Agent 任务可能涉及：读取几十个源代码文件、执行多条命令并分析输出、维护持续增长的操作日志、在多轮工具调用之间保持状态一致性。

以 M3 完成的 CUDA 优化任务为例：1959 次工具调用意味着每次调用都需要在上下文中保留之前的执行历史、分析结果和决策依据。没有足够长的上下文窗口，Agent 就像每隔几分钟就会失忆的程序员——再聪明也无济于事。

这也是 M3 的 1M 上下文窗口不仅仅是堆参数，而是与 Agent 能力深度绑定的基础设施。MSA 将 1M 上下文的计算成本压下来，Agent 才能在长线程任务中持续工作。

2. Coding & Agent 能力：用评测数据说话

M3 在多个国际权威评测基准上的成绩如下：

评测成绩对比图表

图 2：MiniMax M3 与前沿模型评测成绩对比

几个值得关注的数字：

BrowseComp 83.5 vs Opus 4.7 的 79.3。BrowseComp 考验模型在真实网页环境下的信息检索与综合能力。M3 超越 Opus 4.7，对 Agent 场景而言是硬指标。

Claw-Eval 排名靠前。这是自主 Agent 端到端评测，模拟真实开发任务的完整工作流。名次靠前说明 M3 不仅单步推理强，多步规划、工具调用、错误恢复等 Agent 核心能力均能胜任。

SWE-Bench Pro 59.0%。排在 Opus 4.7 之后，但超越 GPT-5.5 和 Gemini 3.1 Pro。SWE-Bench Pro 是业界公认的软件工程能力标杆，59% 的通过率意味着 M3 在真实 GitHub issue 修复场景中已经能产出有效结果。

你在项目中用过类似的 Agent 方案吗？欢迎在评论区分享体验。

3. 三个实战任务：不止于刷榜

基准测试是一回事，实际任务表现是另一回事。官方提供三个具体案例，信息量远超评测分数。

论文独立复现：12 小时跑通核心实验

任务：独立复现 ICLR 2025 Outstanding Paper Award 获奖论文《Learning Dynamics of LLM Finetuning》。

过程：M3 自主运行接近 12 小时，产出 18 次 commit 与 23 张实验图表。

结果：跑通核心实验，验证了 SFT 阶段预测概率变化趋势、DPO 的 squeezing 效应、Extend 缓解方法。

该任务的难度在于需要三项能力同时在线：多模态看懂论文中的图表和公式，长上下文容纳论文全文 + 代码 + 运行日志，编程与 Agent 能力驱动整个 12 小时的长线程执行。缺一不可。

拆解来看：先理解论文的数学推导与实验设计（多模态理解），将方法转化为可运行代码（编程能力），运行实验并对比结果（Agent + 长上下文），结果不理想时分析原因并修正（持续推理）。全程由 M3 自主完成，23 张实验图表验证复现正确性——它不只是写代码，更像一名研究助理在干活。

CUDA 算子优化：从 7.6% 到 71.3%

这是三个案例中说服力最强的一个。

任务：在 NVIDIA Hopper 架构上优化 FP8 GEMM kernel。

起点：仅有一份任务描述、一个 benchmark 脚本、一个无法运行的 Triton 骨架代码。没有参考实现，没有现成答案。

过程：约 24 小时，147 次 benchmark 提交，1959 次工具调用，经历了 6 轮标志性优化迭代。

结果：硬件峰值利用率从 7.6% 提升到 71.3%，实现 9.4 倍加速。

CUDA 优化过程可视化

图 3：CUDA 算子优化历程 - 硬件峰值利用率从 7.6% 到 71.3%

有个细节值得注意：最佳结果出现在第 145 次提交。据官方数据，其他参评模型大多在前 30 次内就停滞了。M3 不仅代码能力强，更关键的是具备持续迭代的耐力——在 Agent 场景中，这个特质比单次推理能力重要得多。

PostTrainBench：让 M3 自己训练模型

任务：向 M3 提供四个 Base 模型，要求在 12 小时内自主完成数据合成→训练→评测→迭代的全流程。

这个任务考验的不是编程能力，而是判断力：自行决定合成什么数据、选择什么训练策略、根据评测结果调整方案。本质上是在让模型扮演 AI 研究员。

得分：0.37，排名第三，仅次于 Opus 4.7（0.42）和 GPT-5.5（0.39）。在 AI 训 AI 的闭环任务中，这个成绩并不差。

4. 原生多模态：从 Day 1 起步

为什么原生训练至关重要

大多数多模态模型的做法是：先训练一个纯文本模型，再将视觉编码器嫁接上去。效率高、实现简单，但文本与视觉的语义空间天然存在缝隙。

M3 不走这条路——从预训练的 Day 1（官方原文为 Step 0）就开始多模态混合训练。文本与视觉的语义空间从一开始就对齐。

代价是训练流程更复杂，需要重构整个数据管线，预训练数据规模扩充到百 T 量级。但回报同样明确：在理解图表、公式、曲线图等需要跨模态推理的任务上，表现更加自然。

Interleaved Data 的关键作用

MiniMax 做了大量实验，发现一项重要结论：Interleaved Data（交错数据）对模型性能的提升比预期要大得多。

所谓 Interleaved Data，是指文本和图像在序列中交替自然排列的数据——例如一篇包含图片说明的文档，而非将文本块与图片块分开堆叠。

这一发现背后的逻辑是：模型不仅要会看图、读文字，还得理解图文之间的交替逻辑关系。论文理解、文档分析、网页浏览，均依赖这种能力。

从数据工程角度看，Interleaved Data 的准备成本远高于普通图文对。原始文档（论文、网页、教程）需保持自然格式，文本和图像交替排列，不能粗暴地拆成独立的文本数据和图像数据。MiniMax 为适配这种训练方式重构了整个数据管线，预训练数据规模拉到了百 T 量级。

这笔投入不小。但回头看论文复现任务中 M3 对图表和公式的理解能力，这笔投入确实产生了回报。

多模态应用场景

从官方披露的信息来看，M3 的多模态能力覆盖了以下场景：

• 论文中的图表、公式、曲线图理解（论文复现任务已验证）
• 视频输入理解
• Computer Use - 直接操作电脑桌面完成跨应用操作

5. 交互式用户模拟器：下一代 Agent 训练范式

这一节虽然不是 M3 模型本身的功能，但能看出 MiniMax 对 Agent 能力演进的思考。

问题定义

当前大多数代码 Agent 的训练建立在单轮任务假设上：用户提需求，Agent 完成，结束后即终止。但真实开发并非如此——用户会在同一个 session 中持续协作：补充需求、讨论方案、反馈修正、切换任务、迭代项目。

框架设计

MiniMax 提出一个交互式用户模拟器框架，模拟真实开发者的协作行为模式。具体来说，该框架覆盖了几种典型的协作行为：需求补充、方案讨论、反馈修正、连续任务切换、复杂项目迭代。

这使得 Agent 不再仅仅是被动执行指令，而是主动与用户协同完成任务。

这一方向背后隐含的判断是：下一代 Coding 能力的比拼，不只在于代码生成的准确率，更包括长期协作能力、规划能力以及人与 Agent 的协同效率。

坦白讲，这个方向比单纯刷 SWE-Bench 分数难得多。但从 Agent 落地的角度看，这恰恰是当前的关键瓶颈——真实开发并不是在跑 benchmark。

6. 接入方式与定价

API 接入

API 地址：https://api.minimaxi.com/v1/text/chatcompletion_v2

模型名：MiniMax-M3

兼容 OpenAI API 格式，支持自动 Cache。

两种思考模式

M3 提供 Thinking 和 Non-thinking 两种模式，采用同一套定价：

• Thinking 模式：适合复杂推理、Agentic 任务与长程协作。模型会输出中间推理过程。
• Non-thinking 模式：响应更快，适合对话、代码补全等延迟敏感场景。

两种模式可在请求时按需切换，无需更换模型。这个设计相当实用——同一端点，既能覆盖深度思考需求，也能满足快速响应场景。

服务等级

• 默认通道：适合常规请求
• 优先通道（service_tier=priority）：高并发场景下获得调度优先级与更稳定的响应时延

Token Plan 定价

定价对比信息图

图 4：MiniMax M3 Token Plan 定价方案

从 token 单价看，M3 走的是量大价低路线。Plus 档 ¥49/月提供 6 亿 token，日常开发额度非常充裕。

开发者工具支持

M3 支持 10+ 主流 AI Coding 工具接入：Claude Code、Roo Code、Kilo Code、Cline、Codex CLI、OpenCode、Droid、TRAE、Grok CLI、Cursor 等。基本上主流 AI 编程工具都已覆盖。

接入也很简单——M3 兼容 OpenAI API 格式，大多数工具只需修改 API endpoint 和 model name 即可。已经熟悉这些工具的开发者，切换到 M3 几乎零学习成本。

开源计划

M3 即将在 HuggingFace 和 GitHub 上开放源代码，支持私有集群部署与微调。官方表示技术报告与开源模型权重将在发布后 10 天内更新。

如果开源版本能保持与闭源版本相近的能力，对国内开发者来说将极具吸引力——在自己的基础设施上运行，无需担心里程碑计费和数据隐私问题。

7. MiniMax Code：配套 Agent 产品

MiniMax 还发布了专为 M3 设计的 Agent 产品 MiniMax Code，几个核心特性值得关注：

• Agent Team：将大型任务拆解为多阶段、可并发、可动态调整的 Workflow
• Producer + Verifier 对抗式 Harness 循环：可持续运行数天，反复验证输出质量
• Computer Use 能力：可操作电脑桌面完成跨应用操作
• 基于社区开源项目 OpenCode 和 Pi Agent 构建

其中 Producer + Verifier 的对抗式设计尤其有趣——并非一次生成后期待正确，而是通过持续的生成→验证→修正循环提升质量。这与前文 M3 在 CUDA 优化中跑 147 次 benchmark 的行为模式完全一致。

总结

翻完官方资料，对 M3 的整体印象：三项能力均不弱，无明显短板。

MSA 架构在稀疏注意力上实现了显著的效率提升，1M 上下文并非营销噱头，而是实际可用。Coding 和 Agent 能力在多个权威评测中进入前沿梯队。原生多模态从 Day 1 开始训练，成本更高但跨模态理解能力更自然。

当然也存在不确定性：评测成绩与实际体验之间的差距有多大？开源版本会保留多少能力？长期协作场景下稳定性如何？这些都需要在模型真正可用后才能验证。

不过从定价策略和开源计划来看，MiniMax 显然在走降低开发者试用门槛的路线。Plus 档 ¥49/月提供 6 亿 token，加上即将开源的模型权重，想体验国产前沿模型的开发者，试错成本极低。

如果你也在关注国产大模型的进展，M3 值得花时间实际跑一跑。评论区说说你最想用它来做什么？

来源：互联网