MiniMax M3 正式发布：1M 上下文、多模态、Coding Agent 与 Sparse Attention 到底意味着什么？
写作时间：2026 年 6 月 1 日
关键词：MiniMax M3、MSA、Sparse Attention、1M Context、Coding Agent、Open-weight、Claude Code、MiniMax Code
TL;DR
MiniMax M3 是 MiniMax 在 2026 年 6 月 1 日正式发布的新一代 M 系列语言模型。它的核心卖点可以压缩成三句话：
第一，M3 面向 Coding 和 Agent 场景，重点不是普通聊天，而是长任务执行、代码库理解、工具调用、多轮协作和自动化工作流。
第二，M3 支持最高 1M tokens 上下文，官方称 512K tokens 为保证下限，1M 上下文主要服务于大代码仓库、长文档、长视频理解和长期 Agent 任务。
第三，M3 引入了 MiniMax Sparse Attention，也就是 MSA。它试图解决传统 full attention 在超长上下文下计算成本爆炸的问题，让模型在百万级上下文里仍然具备较好的速度和可用性。
更准确地说，M3 不是"又一个聊天模型"，而是 MiniMax 试图把"长上下文 + 多模态 + Coding Agent + 工具调用 + 可开放权重"打包到一个模型体系里。
不过也要把话说清楚：截至 2026 年 6 月 1 日，M3 的 API 已经可用，官方也称它是 open-weight 模型，并表示接下来会发布技术报告和开放权重。但对于开发者来说，真正判断它是否"开源"，不能只看宣传语，还要等权重文件、许可证条款、商用限制、部署要求全部落地后再判断。
一、MiniMax 是开源模型吗？
这个问题不能简单回答"是"或者"不是"。
MiniMax 是一家模型公司，不是一个单一模型。它旗下有视频、语音、音乐、图像、语言模型，也有 MiniMax Agent、MiniMax Code、Hailuo 等产品。不同模型的开放程度并不一样。
以 MiniMax-M2.7 为例，它确实提供了 GitHub、Hugging Face、ModelScope 等本地部署入口，可以使用 vLLM、SGLang、Transformers 等方式运行。从这个角度看，它属于"权重可用"或"open-weight"。
但 M2.7 的许可证不是 Apache-2.0、MIT、BSD 这类传统宽松开源许可证。它明确写着非商业用途可用，商业用途需要 MiniMax 事先书面授权。因此，严格说 M2.7 不是完全自由开源模型，而是"非商业开放权重模型"。
M3 的情况更进一步。MiniMax 官方在 M3 发布页中称其为第一个同时具备前沿 Coding 能力、百万级上下文和原生多模态能力的 open-weight 模型。同时，官方也写到未来 10 天会发布技术报告并开放对应模型权重。
所以，当前更稳妥的表述是：
MiniMax M3 已经作为 API 模型正式发布，官方称其将开放权重；但是否能被称为严格意义上的"开源模型"，还需要等权重和许可证正式发布后再判断。尤其是商用场景，必须看许可证，而不能只看"open-weight"这个词。
这点非常关键。很多人会把"能调用 API""能下载权重""能本地跑""能商用改造""完全开源"混为一谈。实际上它们是五个层级：
- API 可用：你可以调用模型，但不能拿到权重。
- 权重开放：你可以下载权重并本地部署。
- 非商业开放：个人、研究、教育可用，但商业受限。
- 商业授权开放：满足一定条件可以用于商业。
- 真正自由开源：可自由使用、修改、分发、商用，限制较少。
M3 当前最值得关注的点是：它可能把前沿 Coding Agent 能力带到 open-weight 阵营，但最终开放程度要看后续许可证。
二、M3 到底发布了什么？
MiniMax M3 的发布重点集中在三类能力上。
1. Coding 与 Agent 能力
M3 首先是一个面向 Coding 和 Agent 的模型。它不是只强调"会写代码"，而是强调"能在工具环境中持续执行任务"。
传统代码模型的典型能力是：给它一个函数需求，它返回一段代码。更强一些的模型可以解释报错、修复 bug、生成单元测试、做重构建议。
而 Agentic Coding 模型要处理的是另一类问题：它需要读代码仓库、理解需求、拆解任务、调用终端、修改文件、运行测试、根据报错继续修复，并在多轮过程中保持目标一致。
这类任务的难点不只是"代码补全"，而是工程闭环。模型要能处理不完整信息、长上下文、工具反馈、失败重试、版本变更、用户临时追加要求，以及多个文件之间的依赖关系。
MiniMax 官方给出的 M3 Benchmark 包括 SWE-Bench Pro、Terminal-Bench、KernelBench、MCP Atlas 等，核心都指向同一个方向：让模型更适合真实工程环境，而不是只在短题目里生成代码片段。
2. 1M tokens 长上下文
M3 支持最高 1M tokens 的上下文窗口，并且官方称 512K tokens 是保证下限。
这件事的意义不只是"可以塞更多文本"。长上下文真正有价值的场景主要有四类：
第一，大代码仓库理解。以前模型只能看几个文件，现在可以一次性塞入更多仓库结构、依赖关系、README、接口文档、日志和测试结果。
第二，长文档分析。比如合同、论文、技术规范、项目归档、会议纪要、产品需求文档，可以减少切片丢失上下文的问题。
第三，长视频和多模态理解。M3 支持图像和视频输入，长上下文可以承载更多帧、字幕、OCR、视觉描述和推理链路。
第四，长周期 Agent 任务。Agent 在执行过程中会产生大量工具调用记录、错误日志、修改记录、测试结果和中间计划。上下文越短，越容易丢失早期决策；上下文越长，越可能维持任务连续性。
不过，1M 上下文不是魔法。它不等于模型一定能精准记住所有信息，也不等于可以无脑塞垃圾上下文。长上下文真正有效，需要清晰的目录、分隔符、索引、任务说明和上下文压缩策略。否则模型只是"看得多"，不一定"用得准"。
3. 原生多模态
M3 的第三个重点是原生多模态。官方说法是，它不是后加一个视觉模块，而是从训练早期就混合多模态数据，让文本、图片、视频等模态在语义空间里更深地对齐。
这和 Coding Agent 的结合很重要。未来的开发任务并不只来自文字需求。很多时候，输入可能是：
一张产品原型图； 一段录屏； 一个 UI 截图； 一份带表格和图示的 PDF； 一个报错截图； 一段用户操作视频； 一张设计稿； 一组实验曲线。
如果模型只能读文本，它就需要 OCR、VLM、截图分析等外部工具层层转接。如果模型天然支持图像和视频输入，那么 Agent 可以更直接地理解"界面长什么样""图表表达了什么""用户操作哪里失败了"。
这对前端开发、自动化测试、桌面操作、视觉调试、文档解析都有实际价值。
三、M3 的核心原理：MiniMax Sparse Attention
M3 最值得讲的技术点是 MSA，也就是 MiniMax Sparse Attention。
要理解 MSA，先要理解传统 attention 的问题。
Transformer 的核心机制是 attention。简单说，当模型生成一个 token 时，它需要判断当前 token 应该关注前文哪些 token。上下文越长，需要比较和读取的信息越多。
如果是 full attention，理论上每个 token 都可能关注所有其他 token。上下文长度从 10K 增加到 100K，再增加到 1M，计算和显存压力会急剧上升。长上下文的难点不只是"显存装不装得下"，还包括 prefill 阶段的输入处理成本、decode 阶段的逐 token 生成成本，以及 KV Cache 的读取带宽压力。
这就是为什么很多模型虽然标称长上下文，但在真实使用中会出现延迟高、成本高、吞吐低的问题。
MSA 的基本思路是：不要让模型每次都完整扫描所有历史上下文，而是先用更便宜的方法判断哪些上下文块更重要，再只对这些块进行真正的 attention 计算。
可以把它理解为两步：
第一步，先做低成本索引。模型把超长上下文切成多个 blocks，然后通过一个 Index Branch 对这些 blocks 做快速打分，判断哪些块可能和当前 query 相关。
第二步，再做稀疏 attention。模型只拿被选中的 KV blocks 进入真正的 attention 计算，而不是让每个 query 都对全量上下文做 full attention。
这个设计的关键不在于"少看信息"，而在于"先筛选，再精读"。如果筛选机制足够准，模型就可以在保留长程信息访问能力的同时，大幅降低计算成本。
这和人读资料很像。面对一整本书，我们通常不会每回答一个问题都逐字重读全书，而是先看目录、索引、标题、关键词，定位相关章节，再精读具体段落。MSA 做的是类似的事情，只不过它发生在模型内部的 attention 计算层面。
四、MSA 和 MoE、MLA、普通滑窗注意力有什么区别？
M3 的 MSA 容易和其他概念混在一起，尤其是 MoE、MLA、Sliding Window Attention。
1. MSA 不是 MoE
MoE 解决的是"参数激活效率"问题。
一个 MoE 模型可能有几千亿总参数，但每个 token 只激活其中一部分专家。这样模型总容量很大，但单次推理成本不会等同于全量参数。
MSA 解决的是"长上下文 attention 成本"问题。
它关注的是：当上下文很长时，模型每次生成 token 到底要看多少历史 KV。也就是说，MoE 是在 FFN/专家层面做稀疏激活，MSA 是在 attention 层面对上下文访问做稀疏化。
两者可以共存，但不是一回事。
2. MSA 不是简单滑窗
Sliding Window Attention 的思路是只看附近一段上下文，比如只看最近 4K、8K、32K tokens。它的优势是简单、稳定、成本低；缺点也明显：如果关键信息在很远的位置，模型可能看不到。
Agent 任务经常需要远距离引用。比如用户最初提出的约束在 20 万 tokens 之前，中间模型执行了大量工具调用，最后修改代码时仍然要遵守这个约束。纯滑窗很容易丢掉这种远距离信息。
MSA 的重点是动态选择相关块，而不是只看最近窗口。理论上，只要索引分支能命中，远处的上下文块也可以被访问。
3. MSA 和 MLA 也不同
MLA 的代表是 DeepSeek 系列使用的 Multi-head Latent Attention。MLA 重点是把 KV 压缩到低维 latent 表示，从而降低 KV Cache 成本。
MSA 的社区解读更接近：它仍然在标准 GQA 框架下运行，先进行 block-level selection，再对真实的、未压缩的 K/V 块执行 attention。也就是说，它更强调"选哪些块"，而不是主要靠"压缩所有块"。
这类设计的潜在好处是减少压缩带来的信息损失，同时保留 prefix caching 等工程能力。但它的挑战也很明确：索引分支必须足够准，否则模型可能漏掉关键上下文。
五、为什么 M3 对 Coding Agent 很重要？
Coding Agent 的瓶颈不只是模型会不会写代码，而是模型能否在复杂工程环境里持续工作。
以一个真实任务为例：你让 Agent 给一个 Next.js 项目增加监控面板。它可能需要做这些事：
读取项目结构； 理解路由和组件组织； 查找现有 UI 规范； 新增页面； 接入 API； 修改类型定义； 增加 loading 和 error 状态； 运行 lint； 修复 TypeScript 报错； 检查构建结果； 根据用户反馈继续调整。
这个过程会产生大量上下文。每一次工具调用都会带来输出，每一次报错都会带来日志，每一次修改都会改变代码状态。模型如果上下文太短，很容易出现三类问题：
第一，忘记原始需求。做着做着偏离目标。
第二，忘记历史修改。重复改同一个问题，或者覆盖自己之前的正确修改。
第三，无法理解全局依赖。只修当前文件，不知道其他文件被影响。
M3 的长上下文和 MSA，就是为这类问题服务的。它让模型有机会在更长的执行链路中保留更多任务状态，同时通过稀疏注意力降低处理成本。
官方给出的几个案例也体现了这个方向。比如 M3 独立复现 ICLR 论文，连续运行近 12 小时，产出 18 次 commits 和 23 张实验图；又比如 CUDA Kernel 优化任务，模型连续进行了 147 次 benchmark submission 和 1959 次工具调用，最终把 Hopper FP8 GEMM 的硬件峰值利用率从 7.6% 推到 71.3%。
这些案例当然还需要独立评测进一步验证，但它们至少说明 MiniMax 对 M3 的定位非常明确：不是短问答模型，而是长程任务执行模型。
六、M3 和 Claude Code、Codex、Cursor、OpenClaw 的关系
M3 本身是模型，不是完整开发工具。真正落地时，它需要运行在 Agent Harness 里。
所谓 Harness，可以理解为模型外面的执行框架。它负责文件读写、终端命令、工具调用、权限控制、上下文压缩、任务状态管理、错误恢复和用户交互。
Claude Code、Codex CLI、Cursor、OpenClaw、Cline、Roo Code、Hermes Agent 等都属于不同形态的 Agent 工具或开发环境。模型只是"大脑"，Harness 是"身体"和"操作系统"。
MiniMax 官方已经给出在 Claude Code、Cursor、OpenClaw、Hermes Agent 等工具中使用 M3 的文档。尤其是 Claude Code 兼容方式，本质上是让 Claude Code 的 Anthropic-compatible API 指向 MiniMax 的 API endpoint，并把模型名配置成 MiniMax-M3。
一个简化版配置思路如下：
json
{
"env": {
"ANTHROPIC_BASE_URL": "https://api.minimax.io/anthropic",
"ANTHROPIC_AUTH_TOKEN": "<MINIMAX_API_KEY>",
"ANTHROPIC_MODEL": "MiniMax-M3",
"ANTHROPIC_DEFAULT_SONNET_MODEL": "MiniMax-M3",
"ANTHROPIC_DEFAULT_OPUS_MODEL": "MiniMax-M3",
"ANTHROPIC_DEFAULT_HAIKU_MODEL": "MiniMax-M3"
}
}中国区用户通常要根据官方文档使用对应的 api.minimaxi.com 入口。
这里有一个实际注意点：Anthropic-compatible 并不等于 100% Anthropic 原生能力。官方文档已经写明，一些参数可能只支持部分能力，某些参数会被忽略。开发者接入时不能只复制 Claude 的配置，还要实际测试工具调用、thinking blocks、图像/视频输入、多轮上下文保留等行为。
七、M3 的 API 和 Token Plan 有什么变化？
M3 发布后，MiniMax 的 API 与 Token Plan 也一起更新。
官方给出的 Token Plan 分为 Plus、Max、Ultra 三档。发布页中写到，Plus 每月约 1.7B tokens，Max 每月约 5.1B tokens，Ultra 每月约 9.8B tokens。这个额度对 Coding Agent 用户很有吸引力，因为 Agent 工具的 token 消耗通常远高于普通聊天。
不过，开发者要注意三个问题。
第一，Token 额度高不等于无限使用。官方文档中提到了 5 小时滚动窗口和周窗口，也就是说它仍然会有节流和配额机制。
第二，API 计费和 Token Plan 计费不是一回事。Subscription Key、Pay-As-You-Go API Key、Credit 的适用范围要分清。
第三，长上下文可能分段计费。官方发布页提到，输入小于等于 512K tokens 的调用按标准价格覆盖大多数对话和 coding 场景；超过 512K tokens 的调用会按更高的长上下文价格计费，更适合超长文档解析和完整代码库理解这类高负载场景。
此外，M3 支持 thinking 开关。thinking 打开时更适合复杂推理、Agent 任务和长程协作；thinking 关闭时响应更快，更适合延迟敏感的对话和代码补全。这个设计很实用，因为并不是所有请求都需要深度推理。
八、M3 对开发者的实际意义
从开发者角度看，M3 最大的价值不在"又多了一个模型"，而在于它把几个趋势汇合到一起。
1. 长上下文开始进入日常开发
过去长上下文更多是演示功能。真正开发时，很多模型虽然标称支持长上下文，但成本和速度都不理想。M3 如果能把 1M 上下文的可用性做扎实，大代码库分析会变得更现实。
比如一个 Java Spring Cloud 项目、一个 Next.js 全栈项目、一个 Kubernetes 部署仓库、一个包含文档和脚本的 AI 项目，以后可以更自然地交给 Agent 做全局分析，而不是人工拆成很多小片段。
2. Coding Agent 的竞争从"会写代码"转向"会做工程"
未来模型之间的差距，不只是 LeetCode、函数补全、单文件修复，而是：
能不能跑完整任务； 能不能持续调用工具； 能不能读懂日志； 能不能自己验证； 能不能长期保持目标； 能不能遇到失败继续探索； 能不能在用户中途介入后调整计划。
M3 的官方案例都在强调长程执行，这说明 MiniMax 已经把竞争点放到了"工程任务闭环"上。
3. 多模态会改变软件开发入口
未来很多开发任务不是文字描述，而是"看图做页面""看视频复现 bug""看截图修 UI""看表格生成系统""看论文复现实验"。
M3 支持图像和视频输入，意味着它可以在更多非结构化输入中理解需求。对于前端、测试、数据分析、自动化办公和桌面 Agent，这会很重要。
4. Open-weight 阵营可能继续压缩闭源模型优势
如果 M3 后续真的开放权重，并且许可证相对友好，它会给本地部署、私有化部署、企业内网 Agent、代码安全敏感场景带来更大选择空间。
但这也取决于硬件要求。一个百万上下文、多模态、强 Coding Agent 模型，即使权重开放，也不代表普通消费级显卡可以轻松跑满能力。开发者还要等待量化方案、vLLM/SGLang 支持、推理吞吐测试、显存需求、上下文长度限制等实际数据。
九、M3 目前仍然需要警惕什么？
任何模型发布当天，都应该保持冷静。
第一，官方 benchmark 需要独立验证。发布页中的 SWE-Bench Pro、Terminal-Bench、KernelBench、BrowseComp、Claw-Eval 等成绩很亮眼，但其中不少评测是在内部基础设施、特定 scaffolding 和特定设置下完成的。真正使用体验还要看第三方复现。
第二，open-weight 不等于无条件商用。M2.7 已经证明 MiniMax 可以开放权重但限制商业使用。M3 后续许可证需要单独看，不能提前假设它是 Apache-2.0。
第三，1M 上下文不等于 1M 精准记忆。长上下文模型仍然会受到注意力分配、检索干扰、位置偏差、上下文污染、无关信息稀释等问题影响。工程上仍然需要索引、摘要、分块、目录和任务状态管理。
第四，API 兼容层不等于完全兼容。Claude Code 能接入 M3，不代表所有 Claude 原生参数、MCP 行为、上下文管理能力都完全一致。接入后必须做实际验证。
第五，Agent 工具的风险更高。模型一旦拥有文件系统、终端、浏览器、桌面操作能力，就不只是"回答问题"，而是在执行动作。权限控制、沙箱、命令审计、密钥保护、仓库备份、自动提交限制都必须做好。
十、M3 是否适合替代你现有的模型？
这个问题要按场景分。
如果你只是普通聊天，M3 不一定是最优选择。它的核心优势不是闲聊，而是 coding、agentic reasoning、tool use、多模态和长上下文。
如果你做代码生成、仓库分析、Claude Code、Cursor、OpenClaw、Hermes Agent、Cline 这类工作流，M3 很值得测试。尤其是大仓库、多文件、多轮修改、长期任务执行，正好命中它的优势区间。
如果你做私有化部署，现在还不能直接下结论。要等权重、许可证、推理框架支持、量化方案、显存要求和第三方压测结果。
如果你做实时语音助手，M3 不是 STT/TTS 的替代品。它可以作为云端 LLM/Agent 编排层，但不能替代语音识别模型，也不能替代实时 TTS 模型。语音系统的关键仍然是端到端延迟、流式能力、打断能力、VAD、音频播放和工具调用编排。
如果你做企业 Agent，M3 值得重点关注。它的 1M 上下文、多模态、工具调用和 Coding Agent 能力，都适合文档问答、研发助手、自动化办公、报表处理、代码审查、桌面操作和长期任务代理。
十一、我的判断：M3 真正代表的是 Agent 模型的新方向
M3 的意义不只是 MiniMax 发布了一个新模型，而是说明大模型竞争正在从"单轮回答能力"转向"长期任务能力"。
过去模型竞争主要看：谁知识多、谁推理强、谁写作好、谁代码题分数高。
现在模型竞争开始看：谁能在真实工作流里连续执行，谁能读完整代码库，谁能操作工具，谁能处理多模态输入，谁能在失败后继续尝试，谁能把长任务做完。
这就是 Agent 模型的核心。
M3 的路线很清楚：用 MSA 解决长上下文成本，用原生多模态扩展输入范围，用 Coding/Agent 数据和训练方式提升工具执行能力，再通过 MiniMax Code、Claude Code 兼容层、API 和 Token Plan 进入开发者日常工作流。
这条路线是合理的。因为未来真正有价值的模型，不只是回答"怎么做"，而是能进入环境里"做完它"。
但最终成败不取决于发布页，而取决于四件事：
第一，开放权重后实际许可证是否友好。
第二，第三方 benchmark 和真实开发任务能否复现官方表现。
第三，推理成本是否真的足够低，尤其是 512K 到 1M 上下文区间。
第四，MiniMax Code 和生态工具能否稳定承载长期 Agent 任务。
结语
MiniMax M3 是 2026 年 6 月一个值得重点关注的模型发布。
它把 Coding Agent、1M 上下文、原生多模态和 Sparse Attention 放到同一个模型叙事里，也试图把 open-weight 模型推到更接近闭源前沿模型的位置。
对普通用户来说，它可能只是又一个强模型。
对开发者来说，它更像是一个信号：AI 编程工具正在从"代码补全"进入"任务执行"，从"单文件生成"进入"代码库协作"，从"聊天窗口"进入"工具环境"，从"短上下文问答"进入"长程 Agent 工作流"。
如果 M3 后续开放权重和第三方测试表现稳定，那么它会成为 2026 年 Agent 模型竞争中非常重要的一张牌。
但现在最理性的态度不是盲目吹捧，也不是提前否定，而是把它放进真实工作流里测试：
让它读一个真实仓库； 让它修一个真实 bug； 让它跑一次测试； 让它处理一次长文档； 让它接入一次 Claude Code 或 Cursor； 让它连续执行一个小时以上的任务； 看它是否能稳定闭环。
模型发布页给的是方向，真实任务给的是答案。