MiniMax M3
🇨🇳 MiniMaxMiniMax M3 是什么定位:长上下文 + Agent + 编码三合一
MiniMax M3 是 MiniMax M 系列在 M2.7 之后推出的旗舰模型,把三件过去往往要分开选模型才能凑齐的能力压进了同一套权重:百万级(约 1M tokens,官方称最低保证 512K)的超长上下文、面向自主任务的 Agent 编排能力,以及偏向工程实战的代码生成。它走的是开放权重路线,并且从预训练第一步就是多模态混合训练,原生支持文本、图像、视频输入,甚至覆盖桌面/计算机操作类任务——这点和那些先训文本、后期再贴视觉的模型有本质区别。
它最值得记住的工程特性是 MSA(MiniMax Sparse Attention)稀疏注意力架构。官方的说法是,在满 1M 上下文下,M3 的单 token 计算量相比上一代 M2 大幅下降,prefill 和 decode 都有数量级的提速。对开发者的直接含义是:把超长文档、整个代码仓库或一长串 Agent 历史塞进上下文,时延和成本的恶化没有传统全注意力模型那么剧烈,长上下文从「能用但很贵很慢」变成了「可以当成常规手段」。
所以 M3 的画像不是一个通用聊天模型,而是一个为「长链路、要调工具、要读大量上下文」的工程场景设计的主力。如果你的产品是 coding agent、需要跨多文件理解代码库、或者要跑十几步以上的自主任务,它正好踩在这个甜区上。
定价结构怎么读:缓存价是 M3 省钱的关键开关
看 M3 的成本,别只盯输入价和输出价(具体数字以本页上方价格表实时为准,会随官方调整和汇率波动)。M3 同时给了缓存输入价,而且本站收录的缓存价相对输入价折扣相当大——这是它在 Agent 和 RAG 场景里真正的省钱杠杆。原因在于这两类负载有大量重复前缀:固定的 system prompt、工具定义、检索回来的文档片段、以及多轮对话里不断累积却几乎不变的历史。命中缓存的部分按缓存价计费,省下的钱在长上下文下会被放大。
实际算账时要把三段拆开看。如果你的用例是「长输入、短输出」——比如长文档问答、代码审查、日志分析——成本主要由输入价(以及缓存命中率)决定,M3 的稀疏注意力让你敢喂更长的上下文。如果是「短输入、长输出」——比如让它一次写出大段代码或长篇方案——那输出价的权重更高,输出价通常是输入价的数倍,要重点盯。对典型的 Agent 循环(反复读取累积上下文 + 每步少量输出),缓存命中率往往是决定月度账单的第一变量,把可缓存的前缀设计稳定、不要每次都改动,是最直接的优化。
想要确切金额,直接用本页的成本速算,或到「粘你自己的文本精确估算」里贴真实 prompt——按你自己的输入/输出比例和调用量算,比看单价更靠谱。
最适合 vs 最不适合 M3 的任务
最适合 M3 的场景有几类共同特征:上下文长、需要工具调用、链路多步。具体包括 coding agent(跨文件读改、自动跑测试、多步修 bug)、整库或多文档的代码/资料理解、长链路自主任务(任务拆解 + 调工具 + 多步推理)、以及需要把长对话历史或大量检索结果一并喂进去的 RAG 系统。它对计算机/桌面操作类的 agent 任务也有原生支持,做这类自动化时是少数能正面接的国产开放权重选择。
最不适合用 M3 的是高频、低复杂度、上下文很短的请求:意图分类、关键词打标、固定模板的简短回复、批量短文本清洗。这些任务用旗舰级模型属于杀鸡用牛刀——你为不需要的长上下文能力和强推理付了溢价,而这些场景真正在意的是单价和吞吐。这类负载应该下放给更便宜的小模型或同厂的腰部型号。
还有一个边界要注意:如果你的上下文其实只有几千到几万 token,M3 那套为 1M 设计的稀疏注意力优势体现不出来,你只是在为「能扛长上下文」这件用不上的事买单。判断标准很简单——你是否真的经常需要塞进远超普通模型上下文窗口的内容,是否真的需要它自主调工具跑多步。两个都「否」,M3 大概率不是性价比最优解。
和 M2.7、其他梯队怎么选:升级降级的触发条件
同厂内部,M3 和 MiniMax M2.7 是最直接的对照。M2.7 是上一代、定价更低的性价比款,同样有 Agent 和代码标签、同样的百万级上下文窗口;M3 则在架构(MSA 带来的长上下文效率)、原生多模态、以及编码/Agent 能力上更进一步,定价也更高。选型逻辑应该是结果驱动而非默认拉满:先用 M2.7 把你的 Agent 或 RAG 流程跑通,如果在长链路任务上观察到推理掉链子、多步任务中途跑偏、或长上下文下质量明显下滑,再升级到 M3——这时你为更强的能力多付的钱才花在刀刃上。
反过来,如果你已经在用 M3,但发现实际任务既不长也不复杂,多数请求 M2.7 甚至更小的模型就能稳定完成,那就该把这部分流量降级下去,把 M3 留给真正吃它能力的高难度路径。一个常见且划算的架构是分级路由:简单/短请求走便宜模型,长上下文或多步 Agent 任务才升到 M3。
跨厂商比较时,M3 的差异化卖点是「开放权重 + 1M 上下文 + 原生多模态 + 强 Agent」这套组合,而不是单看某一项分数。如果你需要可私有部署/可控的开放权重、又要长上下文和 agent 能力,它是国产阵营里少有的同时满足的选择;如果你只要纯文本短任务的最低单价,或只要某一项闭源旗舰的峰值质量,那应该去价格表里横向对比,别因为名气默认选它。具体单价、缓存价和与竞品的高低,请以上方价格表为准。
常见问题
MiniMax M3 和 M2.7 主要差在哪,值得为它多付钱吗?
两者都是 MiniMax M 系列、都有约 1M 上下文和 Agent/代码定位,M2.7 是上一代、单价更低的性价比款。M3 的进步主要在 MSA 稀疏注意力带来的长上下文效率、原生多模态(文本/图像/视频一起从头训练)和更强的编码/Agent 能力,定价也更高。建议先用 M2.7 跑通流程,只有当你在长链路、多步或长上下文任务上观察到 M2.7 质量不够时再升级 M3。具体两者单价差多少,以本页上方价格表为准。
M3 的缓存价对实际成本影响有多大?
影响很大,尤其在 Agent 和 RAG 场景。本站收录的缓存输入价相对输入价折扣明显,而这两类负载有大量重复前缀(固定 system prompt、工具定义、检索文档、累积的对话历史)。命中缓存的部分按缓存价计费,长上下文下省下的金额会被放大。要吃到这个红利,关键是把可缓存的前缀设计稳定、别每次请求都改动。确切金额请用本页成本速算或精确估算工具。
什么情况下不该用 MiniMax M3?
当你的请求高频、低复杂度且上下文很短时不该用它,比如意图分类、关键词打标、固定模板短回复、批量短文本处理。这类任务真正在意单价和吞吐,用旗舰级 M3 是为用不上的长上下文和强推理付溢价。这部分流量应下放给更便宜的小模型或同厂腰部型号,把 M3 留给真正长、真正需要自主调工具多步的任务。
M3 的 1M 上下文和稀疏注意力对开发者意味着什么?
意味着你可以把超长文档、整个代码仓库或很长的 Agent 历史直接塞进上下文,而时延和成本的恶化比传统全注意力模型轻得多。官方称满 1M 上下文下 M3 单 token 计算量相比上代大幅下降、prefill 和 decode 有数量级提速。实践含义是长上下文从「能用但贵且慢」变成可常规使用的手段。但如果你的上下文其实只有几千到几万 token,这套优势体现不出来,就没必要为它买单。