MiniMax M3 正式发布1M 上下文、多模态、Coding Agent 与 Sparse Attention 到底意味着什么写作时间2026 年 6 月 1 日关键词MiniMax M3、MSA、Sparse Attention、1M Context、Coding Agent、Open-weight、Claude Code、MiniMax CodeTL;DRMiniMax 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 AttentionM3 最值得讲的技术点是 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 不是 MoEMoE 解决的是“参数激活效率”问题。一个 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。一个简化版配置思路如下{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 tokensMax 每月约 5.1B tokensUltra 每月约 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、音频播放和工具调用编排。如果你做企业 AgentM3 值得重点关注。它的 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让它连续执行一个小时以上的任务看它是否能稳定闭环。模型发布页给的是方向真实任务给的是答案。