算盘
Agent代码长上下文旗舰
输入价
¥4.20
每百万 tokens
输出价
¥16.80
每百万 tokens
缓存输入价
¥0.840
每百万 tokens
价格来源:MiniMax 官方定价页 ↗最后核对 2026-06-05监控中
上下文窗口
1M
最大输出
64K
模态
文本
智能指数
55

💰 成本速算

单次典型问答(输入 2000 + 输出 500 tokens)
¥0.017
按月 1 万次调用估算
¥168
粘你自己的文本精确估算 →
MiniMax M3 是 MiniMax 的旗舰模型,支持文本模态。API 输入价 ¥4.20、输出价 ¥16.80(每百万 tokens),在算盘收录的 42 个主流模型里输入价排名第 25 便宜,属于国产阵营的偏低价位。缓存命中后输入低至 ¥0.840,有大量重复上下文(RAG、客服、长 system prompt)时能进一步省钱。上下文窗口 1M,单次最大输出 64K。Artificial Analysis 智能指数 55(当前满分约 60)。尤其适合长链路 Agent、工具调用密集的自主任务。

MiniMax 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,这套优势体现不出来,就没必要为它买单。