Minimax m2.1 api价格

你准备把国产模型接进产品，翻到 MiniMax 这一档，发现版本名字多、价格页写得散，不确定该按哪个口径算钱，也不确定这个版本适合干哪种活。这篇不讲虚的，先把「去哪里看当时的数字」指清楚，再给一套判断这个版本该不该选的对照标准，最后说清什么情况下它并不划算。

你准备把国产模型接进产品，翻到 MiniMax 这一档，发现版本名字多、价格页写得散，不确定该按哪个口径算钱，也不确定这个版本适合干哪种活。这篇不讲虚的，先把「去哪里看当时的数字」指清楚，再给一套判断这个版本该不该选的对照标准，最后说清什么情况下它并不划算。

先说一个前提：任何写死的单价都会在你看到的时候可能已经失效，尤其是国产模型这一档，调价和改计费规则的频率并不低。所以这篇的重点不是给你一个数字，而是给你一条路径加一套动作，让你自己在站内查到当时的数字、算明白自己的账、再决定要不要接。

价格去哪儿查：别背数字，背路径

MiniMax 官方按量价格会调整，正确姿势是打开 /official-api 找厂商条目，再进 /official-api/providers/minimax 看接口兼容情况与指向官方价目表的入口。站内不替你缓存单价，但会把入口和口径整理好，省得你在官网翻半天找不到按量计费那一栏。

• 模型规格类信息（上下文长度、是否支持工具调用、多模态能力）到 /models 和 /multimodal 核对，别只看价格页的宣传语
• 想横向比同价位国产模型，用 /official-api/providers/zhipuai、/official-api/providers/deepseek、/official-api/providers/moonshotai 这几个基准页对齐口径
• 价格近期有没有动过，翻 /price-watch，比自己截图存档靠谱
• 如果关心的是接入后的实际表现而不是纸面参数，去 /benchmarks 和 /crowd-radar 看公开结果

算之前先对齐三件事：输入、输出、缓存

输入和输出是两个价，比例经常差好几倍，只问「多少钱」拿不到能算的答案，必须分别记下两个单价。很多开发者第一次算预算翻车，就是拿输入价乘以总 token 数，结果账单出来差一大截。

上下文超长的请求是否触发分段计价、是否有最低计费量，先确认再动手，不然预估和账单必然对不上。换算成「一次对话多少钱」比盯每百万 token 单价更有决策价值，可以用 /tools/token-price-calculator 和 /tools/model-cost-calculator 直接算。

这个版本适合什么活，不适合什么活

价格便宜不等于适合你。MiniMax 这一档在中文场景和吞吐上有它的位置，但如果你把它塞进一个需要长链条推理的活里，省下的单价很可能被返工和重跑吃掉。下面这张对照表是判断用的，不是结论。

判断方法很简单：拿同一批真实请求在两个候选模型上各跑一遍，比通过率再比花费，而不是先比单价。如果你的任务对输出格式稳定性要求极高，或者对某类专有知识依赖很重，价格便宜不代表总成本低。

接入前的成本动作清单

1. 定用量口径把输入 token、输出 token、调用次数分三列记，字段参照 /usage-log-fields 的思路，别等上线了才发现日志里没有可用的维度。
2. 做三档预估按预期日调用量做保守、中性、激进三档表，每档算月花费，模板可用 /ai-cost-estimate-template。三档都算，是为了看清最坏情况。
3. 设预算护栏预算告警和用量上限一起设，别等月底看账单才发现跑飞，参考 /budget-alert-setup-guide。
4. 首月复盘上线后第一个月把预估和实际差异拆开看，流程见 /monthly-usage-review-guide，差异大的时候先查是不是输入变长了，而不是急着换模型。

这四步做下来，你手里会有一张自己的成本表，而不是一个从别人文章里抄来的单价。下次调价或者换版本，你只需要更新单价那一列。

什么情况下不该为了低价换过来

现有模型已经稳定跑通、错误率低，而迁移要重写提示词和评测集，省下的单价可能抵不过人力，先算迁移成本再决定。这不是保守，是把隐性成本显性化。

• 调用量很小、还在验证期，换模型带来的绝对节省很有限，这个阶段的重点是验证质量而不是抠单价
• 合规或数据落地有硬要求时，价格不是第一位，/safety 相关条款先看清
• 对外承诺了响应质量或交付标准的场景，切换前留好回滚方案和旧模型的开关
• 如果你的业务量在增长，先算增长曲线下的花费，而不是按今天的量做决定

单价只是成本公式里的一个乘数，把调用量、重跑率和迁移人力一起放进去，才叫算成本。