MiniMax模型价格怎么算？计费逻辑与成本控制实战

上周一个做AI客服的朋友半夜给我发消息，说他们团队用MiniMax M2跑了两个月，账单从预估的800块涨到了2400块。他怀疑是minimax模型价格偷偷涨价了，问我是不是被坑了。

我打开他们的调用日志看了一圈，发现问题压根不在价格表上——他们把缓存全关了，还把每轮对话的完整历史都塞进去重算了一遍。这就像打车明明可以拼车，你非要每次单独叫一辆。

核心结论摘要： MiniMax模型价格采用"输入/输出分离 + 缓存折扣"的阶梯计费模式。M2的输入价格约为¥2.1/百万tokens，输出约¥8.4/百万tokens，缓存命中可再降约90%。对多数应用来说，成本超支的主因不是单价，而是上下文管理策略。

我把这两年踩过的坑和实测数据整理出来，希望能帮你少交点学费。

MiniMax模型家族：先搞清楚你在为哪个"引擎"付费

本节要点：MiniMax目前主流API模型分为轻量、通用、长上下文和推理四条产品线，不同产品线的计价逻辑差异很大。

MiniMax的模型线这两年迭代挺快，从早年的abab系列一路走到现在的M2。如果你还停留在"abab6.5"的印象里，可能会漏掉不少性价比选项。

根据MiniMax开放平台2025年10月更新的模型文档，当前主力模型大致可以分为这几类：

| 模型 | 激活参数 | 上下文长度 | 定位 | 大致价格（元/百万tokens） | |------|---------|-----------|------|--------------------------| | abab6.5s | 未公开 | 245K | 轻量高频调用 | 输入≈1，输出≈1 | | MiniMax-Text-01 | 45.9B | 4M | 超长文档处理 | 输入≈1，输出≈8 | | MiniMax M1 | 45.9B | 1M | 推理/数学 | 输入≈4，输出≈16 | | MiniMax M2 | 10B | 204K | Agent/通用开发 | 输入≈2.1，输出≈8.4 | | 海螺02（视频） | — | — | 视频生成 | 按条/按秒计费 |

注：价格随官方调整浮动，上线前请以MiniMax开放平台最新文档为准。

有意思的是M2的设计思路。它总参数230B，但每次推理只激活10B——这种MoE稀疏激活架构是它能把价格压到海外同级模型十分之一左右的关键。我去年用某海外模型跑同样的Agent任务，一个月花了将近3000美元，换成M2之后账单直接掉到300美元以内。当然，效果上确实有些取舍，后面细说。

想了解完整的模型参数和场景适配，可以参考VergeX模型库的MiniMax系列条目，里面按任务类型做了对比。

MiniMax模型价格到底怎么算？拆开计费公式看

本节要点：API费用 = 输入token × 输入单价 + 输出token × 输出单价 - 缓存节省。输出token是成本大头，缓存是最大的省钱杠杆。

很多人第一次看MiniMax的价目表会觉得"这么便宜"，结果月底一看账单傻眼。原因在于一个反直觉的事实：输出token比输入token贵3到4倍。

具体到M2：

• 输入：¥2.1 / 百万 tokens
• 输出：¥8.4 / 百万 tokens
• 缓存读取：约 ¥0.21 / 百万 tokens（约为输入价的10%）

假设你做一个客服机器人，系统提示词2000 tokens，用户问题50 tokens，模型回答100 tokens。单次调用成本大概是：

输入：(2000 + 50) / 1,000,000 × 2.1 ≈ ¥0.0043 输出：100 / 1,000,000 × 8.4 = ¥0.00084 合计：约 ¥0.005

看起来不多对吧？但如果这个系统每天跑5万次对话，一天就是250块，一个月7500。而其中绝大部分成本都花在那2000 tokens的重复系统提示词上。

这就是缓存存在的意义。开启缓存后，重复的那部分按0.21计价，成本立刻降到原来的十分之一。我那个朋友的问题恰恰出在这里——他觉得"缓存配置麻烦"就关了，结果每个月多花一千多。

一段可运行的计费估算脚本，改参数就能用：

def estimate_cost(input_tokens, output_tokens, cache_hit_tokens=0): """ 估算 MiniMax M2 单次调用的成本（人民币） 价格单位：元/百万 tokens """ PRICE_INPUT = 2.1 # 输入单价 PRICE_OUTPUT = 8.4 # 输出单价 PRICE_CACHE = 0.21 # 缓存命中的输入单价

命中的部分按缓存价，未命中的按标准输入价

cost_input = (input_tokens - cache_hit_tokens) / 1e6 PRICE_INPUT cost_cache = cache_hit_tokens / 1e6 PRICE_CACHE cost_output = output_tokens / 1e6 * PRICE_OUTPUT

total = cost_input + cost_cache + cost_output return { "输入成本": round(cost_input, 6), "缓存成本": round(cost_cache, 6), "输出成本": round(cost_output, 6), "总计": round(total, 6) }

场景：2050 token输入，其中1800命中缓存，输出100 token

print(estimate_cost(input_tokens=2050, output_tokens=100, cache_hit_tokens=1800))

跑一下你会看到缓存那部分直接把输入成本砍掉大半。这个函数我放在自己的监控脚本里，每天定时拉账单数据做对比，偏差超过15%就会触发告警。

实战场景：三种典型业务的成本差异

本节要点：同一套模型和价格，不同业务的token结构差异能造成10倍以上的成本差距。

过去半年我在三个不同类型的项目里用了MiniMax的API，成本表现差别很大，整理出来供参考。

场景一：文档摘要批处理

这是一个法规文档处理工具，输入是几千字的PDF文本，输出是300字左右的摘要。输入输出比大概20:1，成本几乎全压在输入侧。好在MiniMax-Text-01的输入价格很便宜，而且4M上下文一次塞下整份合同没问题。

实测：处理1万份平均5000字的文档，总成本约65元。这个数字比用某海外模型便宜了将近一个数量级。

场景二：多轮对话客服

就是前面说的那种。输入输出比接近5:1，但因为系统提示词长、对话轮次多，token消耗量巨大。

关键优化点只有一个：把固定不变的部分（角色设定、产品知识库摘要、few-shot示例）全部标记为可缓存，只让变动的对话历史走标准计费。

优化后单次对话平均成本从¥0.018降到¥0.006，降幅66%。

场景三：Agent自动化任务

这是最烧钱也最难预估的一类。我搭过一个自动做竞品调研的Agent，它会自己规划步骤、调用搜索工具、读取网页、最后写报告。

这类任务的特点是输出token占比很高——模型的思考过程和工具调用参数都算输出，而且经常出现"绕远路"的情况。

坦白讲，M2在Agent场景下的工具调用准确率比我预期好，但在复杂任务上偶尔会陷入循环重试。我加了一个最大步数限制（15步）之后，成本才稳定下来。

如果你在做类似的Agent应用，建议同步看看大模型推理成本优化指南，里面关于上下文压缩的部分对我帮助很大。

几个容易踩的坑，以及我的应对方式

本节要点：成本失控通常不是单价问题，而是工程细节问题。下面四个坑我至少踩过三个。

坑一：以为关掉流式输出能省钱

完全相反。流式输出不影响计费，但能让你更早发现模型跑偏、及时掐断。我现在的做法是设一个输出token上限，超了就中断请求。

坑二：忽略缓存的有效期

MiniMax的缓存不是永久有效的，具体过期策略官方文档有说明。如果你的提示词几小时才用一次，缓存命中率会很低。高频场景才值得认真做缓存设计。

坑三：拿M2跑所有任务

M2便宜，但它在复杂数学推理上确实不如M1。我的策略是分级调度：简单分类和抽取用abab6.5s，通用对话和Agent用M2，需要深度推理的才切到M1。这样整体成本能再降30%左右。

坑四：不做token预计算

调API之前先用tokenizer算一下。如果发现某次请求输入超过阈值（比如5000 tokens），就该考虑分块或摘要压缩了。这个习惯帮我避免了好几次意外的大额消费。

总结：MiniMax模型价格的本质是什么

说到底，MiniMax模型价格的优势不在于单价低，而在于它给了你足够多的杠杆——缓存折扣、分级模型、超长上下文，这些都是可以主动调控的变量。

我见过太多团队把模型选型和成本优化当成两件事，其实它们是一件事。选错模型，优化到死也省不了多少；选对模型加对策略，账单能砍掉七成。

未来半年我