MiniMax M3 发布：代码 Agent、1M 上下文和原生多模态

Mon, 01 Jun 2026 09:00:00 +0800

MiniMax 在 2026 年 6 月 1 日发布了 MiniMax M3。从官方介绍看，M3 的定位很清楚：面向代码、Agent 和长上下文任务，同时加入原生多模态能力。

这次发布最值得关注的不是单个跑分，而是 MiniMax 把三类能力放到同一个模型里：

代码与 Agent 任务能力；
最高 1M tokens 上下文窗口；
原生多模态，支持图像和视频输入；
计划开放权重，支持后续私有化部署和微调。

如果你正在关注国产模型在编程助手、自动化工作流、长文档处理和多模态理解上的进展，M3 值得单独看一下。

M3 的核心定位

MiniMax 对 M3 的表述是：代码与 Agent 前沿模型，1M 上下文，原生多模态。

这几个关键词对应的是实际使用里的几个痛点：

代码任务不只是补全函数，还需要读项目、改文件、运行工具、修复报错；
Agent 任务会产生大量工具调用记录、日志和中间结果；
长文档、长视频、完整代码库都需要更大的上下文窗口；
图表、截图、公式、视频帧等内容，不能只靠纯文本理解。

因此 M3 更像是给“长链路任务”准备的模型，而不是只面向普通聊天或短文本生成。

1M 上下文来自 MSA 架构

M3 使用 MiniMax 自研的 MSA，也就是 MiniMax Sparse Attention。官方解释里，MSA 的目标是解决传统全注意力在长上下文下计算复杂度快速膨胀的问题。

简单说，全注意力在上下文变长时成本上升很快。MSA 通过稀疏注意力和更适合硬件执行的 KV block 访问方式，让模型在长上下文场景下更容易扩展。

官方称，M3 API 支持最高 1M tokens 上下文，并保证最低 512K tokens。这对几类任务很有意义：

读取完整项目或大型模块；
处理长研究报告、合同、日志和知识库材料；
保留多轮 Agent 执行过程中的工具调用记录；
分析长视频或多模态材料。

不过要注意，长上下文并不等于所有任务都应该塞满上下文。实际使用时，检索、分块、缓存和任务拆分仍然重要。1M 上下文更像是给复杂任务提供上限，而不是替代工程设计。

代码和 Agent 是重点

官方报告里，M3 在多个代码与 Agent benchmark 上给出了成绩，包括：

Benchmark	官方公布成绩
SWE-Bench Pro	`59.0%`
Terminal-Bench 2.1	`66.0%`
SWE-fficiency	`34.8%`
KernelBench Hard	`28.8%`
MCP Atlas	`74.2%`

这些数字可以作为参考，但不建议只看榜单下结论。更值得注意的是 MiniMax 把 M3 的训练和评估重点放在更接近真实协作的 Agent 场景上。

真实的代码工作并不是“一句话生成一个函数”。它通常包括：

反复澄清需求；
阅读已有代码；
制定修改计划；
运行命令和测试；
根据报错继续修；
在多轮上下文里保留决策依据。

这也是 M3 和 MiniMax Code 绑定发布的原因。模型能力只是底层，真正能不能完成工程任务，还要看外层 Agent harness、工具调用、上下文管理和验证流程。

官方展示的几个长链路任务

MiniMax 在报告里列了几个更接近真实工作的案例。

第一个是论文复现。官方让 M3 独立复现一篇 ICLR 2025 Outstanding Paper。M3 连续运行接近 12 小时，产生 18 次 commit 和 23 张实验图，完成了核心实验复现。

这个案例的重点不是“会写论文摘要”，而是它同时用到了：

多模态能力，理解论文里的曲线、公式和图表；
长上下文，把论文、代码和实验日志放进同一任务链路；
代码与 Agent 能力，持续运行、实验、验证和修正。

第二个是 CUDA kernel 优化。官方让 M3 从一个不能直接运行的 Triton 骨架开始，优化 NVIDIA Hopper GPU 上的 FP8 GEMM kernel。M3 在约 24 小时里完成 147 次 benchmark submission 和 1,959 次工具调用，把硬件峰值利用率从 7.6% 提升到 71.3%，相当于 9.4x 加速。

这个案例说明 M3 更强调长时间自主迭代。普通代码生成模型往往在前几轮失败后就停住，而 Agent 型模型需要能持续根据反馈调整方向。

第三个是让 M3 自主训练模型。官方在 PostTrainBench 中给 M3 四个只完成预训练的 base model，让它在 12 小时内完成数据合成、训练、评估和迭代。最终 M3 得分 0.37，低于 Opus 4.7 和 GPT-5.5，但明显领先其他模型。

这些案例都来自 MiniMax 官方测试，不能直接等同于第三方独立评测结果。但它们能说明 M3 的产品方向：把模型放进长周期、可验证、有反馈的任务循环里。

原生多模态的意义

M3 不是在文本模型后面简单外挂视觉能力。官方称它从训练早期就进行混合模态训练，并重建了数据管线，把训练数据扩展到 100T+ 级别。

对开发者来说，多模态的价值主要在这些场景：

读取截图、图表、公式和设计稿；
分析 PDF、论文、报告和实验图；
理解长视频中的画面变化；
在桌面自动化任务中识别界面元素。

MiniMax Code 也围绕这一点做了产品化。官方提到，MiniMax Code 可以结合 M3 的多模态能力做 computer use，例如根据表格内容跨应用批量录入信息。

MiniMax Code 与 Agent Team

随着 M3 发布，MiniMax Code 也同步更新。官方把 MiniMax Code 定位为更适合 M3 的 Agent 产品，用来释放 M3 的长上下文、代码、Agent 和多模态能力。

MiniMax Code 的 Agent Team 可以把大任务拆成多阶段、并发、可动态调整的流程，并通过类似 Producer + Verifier 的对抗式循环持续产出、反思和修正。

这个方向和 Claude Code、Codex CLI、opencode 等工具处在同一大类：不是只让模型回答问题，而是让模型进入本地或云端开发环境，读文件、改文件、运行命令，再根据结果继续推进。

区别在于，MiniMax 更强调：

M3 的 1M 长上下文；
多模态和 computer use；
Agent Team 的长时间自主执行；
Token Plan 下的大额度使用。

Token Plan 和 API

MiniMax 这次也更新了 Token Plan。官方公布的三档额度是：

套餐	月费	M3 月额度
Plus	`$20/month`	约 `1.7B tokens`
Max	`$50/month`	约 `5.1B tokens`
Ultra	`$120/month`	约 `9.8B tokens`

这些额度看起来非常激进，适合高频代码助手、批处理、长文档处理和多模态任务。但实际是否划算，还要看可用地区、并发限制、速度、稳定性、上下文计费和任务成功率。

API 方面，M3 已经可用。官方说明里有几个点值得注意：

输入长度 <=512K tokens 按标准价格计费；
超过 512K tokens 会进入更高的长上下文价格；
支持开启或关闭 thinking；
thinking 开启时更适合复杂推理、Agent 和长周期协作；
thinking 关闭时响应更快，适合对话和代码补全；
支持 standard 和 priority 服务等级，priority 面向更高并发和更稳定延迟。

官方示例里的模型名是：

`1`	`"model": "MiniMax-M3"`

接口示例使用：

`1`	`https://api.minimax.io/v1/text/chatcompletion_v2`

如果你要把 M3 接入现有代码工具，重点要先确认三件事：OpenAI-compatible 兼容程度、流式输出支持、工具调用格式。

开放权重值得关注，但要等落地

MiniMax 称 M3 将在 Hugging Face 和 GitHub 上开源权重，支持私有集群部署和微调。这个点很重要。

如果权重真正开放，并且推理框架适配顺利，M3 可能会进入几类企业场景：

私有代码库助手；
内部知识库和文档分析；
高敏感数据场景；
政企和本地化部署；
低成本批量 Agent 工作流。

但这里还需要等具体信息落地，包括：

权重大小和许可证；
量化方案；
vLLM、SGLang、llama.cpp 等框架支持；
显存需求；
多模态和长上下文在本地部署时的实际成本；
是否开放完整训练或微调工具链。

所以现在可以关注，但不宜过早把“开源权重”当成已经可生产部署的事实。

适合谁先试

M3 更适合下面几类用户先试：

经常使用 AI coding agent 的开发者；
想用国产模型替代部分 Claude、GPT 或 Gemini 代码任务的团队；
有长文档、长代码库、长日志分析需求的人；
做自动化工作流、MCP、agent harness 的开发者；
需要大量 token 额度做批处理的人；
对本地化部署和开放权重有长期需求的团队。

如果只是普通聊天、短文本改写、简单问答，M3 未必是最需要优先尝试的模型。它的重点明显放在更重的 Agent 和工程任务上。

我的看法

MiniMax M3 这次发布，最有意思的是路线选择：不只和通用聊天模型比，而是直接把代码、Agent、长上下文和多模态打包成一个面向工程工作流的模型。

这条路线是对的。未来 AI 编程工具的竞争，不会只看模型能不能写一段代码，而会看它能不能在长时间任务里持续规划、执行、验证、纠错，并且把上下文成本控制住。

不过，真正决定 M3 能不能进入主力工作流的，还是几个更朴素的问题：

API 是否稳定；
长上下文价格是否可控；
MiniMax Code 的工具链是否成熟；
OpenAI-compatible 和主流 agent 工具适配是否顺畅；
开放权重能否及时落地；
第三方评测和真实项目体验是否能支撑官方说法。

如果这些问题后续表现不错，M3 会成为国产代码 Agent 模型里很值得关注的一支。

代码生成 on KnightLi的博客