MiniMax大模型价格表

你要接 MiniMax 的接口，看到几家渠道给的价格表数字都不一样，不知道该信哪张，也不知道同一条请求在不同版本上差在哪。这篇不替你背数字，而是把「一张 MiniMax 价格表该看哪几列、去哪儿看当期数字、怎么换算成自己业务的单价」讲清楚，给一套可照着做的比价顺序和核对清单。

你要接 MiniMax 的接口，打开几家渠道的价格表一看，数字各不相同，每张表的结构也不一样，根本不知道信哪张。更麻烦的是，同一条请求换一个版本，账单差在哪你都说不清。这篇不讲具体数字，而是把「一张 MiniMax 价格表该看哪几列、去哪里看当期数字、怎么换算成你自己业务的单价」讲清楚，给你一套能照着做的比价顺序和核对清单。

先把预期放平：MiniMax 的模型分成文本对话、语音合成与转写、图像视频几条线，每条线的计价单位和计费主体都可能不同，把它们塞进同一列比大小是没意义的。所以下面所有方法都围绕一件事——先对齐口径，再谈贵不贵。当期单价一律到站内 API 价格资料库核对，别用别人转发的截图。

一张 MiniMax 价格表里到底有哪几列

拿到任何一张表，先别急着看数字，先看它有没有下面这几列。列不全的表，比出来的结果基本不可用——你以为是同一个东西，其实一个按 token 算、一个按字符算，量纲都不一样，再比较就是白费功夫。

• 模型族：文本对话、语音合成与转写、图像视频是三条独立计价线，先确认这张表覆盖的是哪一族，跨族比价没有意义。
• 输入与输出分开列：同一模型两段单价通常不对等，写代码、做长文总结这类任务输出占比很高，只看输入价会严重低估。
• 计价单位写全：按百万 token、按千字符、按秒、按张，单位不统一就先换算再比，别拿两个不同量纲的数字直接排高低。
• 版本字段只当唯一标识：用它区分档位就行，具体每档的数值去站内当期页面取，别在正文里记死。

看表先看三件事

计费主体

是官方直连、云厂商托管还是聚合渠道，主体不同单价不能横排

计价单位

这条线是按 token 还是按字符、按秒、按张算，量纲先对齐

档位结构

是单一价还是分阶梯、有没有缓存或批量折扣，折扣价和原价要分栏看

横向比价的四个对齐口径

比价最容易翻车的地方，不是算错乘法，而是拿两种不同条件的价格直接对比。下面这张对照表把常见的错位情形列出来，右边一列是处理动作。遇到表里没有的信息，就去站内价格追踪页看当时的口径说明，不要脑补。

还有两个容易忽略的口径。一是汇率与结算币种，外币牌价换成本币之后，差额可能比两个模型本身的价格差还大，换算基准要写清楚。二是限速与并发，便宜但被严格限速的档位，对高频调用的业务来说实际单位成本并不低——你得多开几条通道或者接受排队。

用自己用量倒推，而不是死记价格

记价格表没意义，数字会变；记方法才有用。正确做法是先从你自己的日志里量出真实用量，再去站内价格页取当期单价相乘，得到的是你的业务单价，而不是一张通用表上的排名。具体按下面几步走。

1. 先量一次典型任务从日志里挑一个高频任务，统计它的输入与输出 token 量或字符量，记录一个中位数而不是极值，避免被单次长请求带偏。
2. 按任务类型分档把业务里的活拆成短问答、长文处理、语音、出图几类，每一类套它自己那条线的计价单位，不要把语音的秒和文本的 token 混在一起算。
3. 去站内取当期单价到站内 API 价格资料库查当期的分档单价与折扣条件，用你量出来的用量相乘，得到自己业务口径下的单次成本。
4. 留出波动带再估总账重试、长上下文、多轮工具调用都会让实际花费高于纸面测算，先按一个保守系数放大，上线后按周复盘修正。

这一步的关键是「先量再算」。如果你连自己一次典型请求的输入输出比例都不知道，那不管看哪张表都会判断失误——输出占比高的任务，对输入单价的敏感度其实很低。

接入前的核对清单与常见坑

测算做完，签约前还有几项要逐条确认。下面这份清单建议直接照着过一遍，任何一条答不上来就先别充值，把问题抛给渠道方问清楚。判断标准是「能不能写进合同或文档」，口头承诺不算。

• 价格页的更新时间：老表格、老截图一律不作为依据，只认站内当期页面。
• 免费额度与付费额度的混用扣费顺序：先扣哪个决定你的预算判断会不会错位。
• 调用失败、超时重试是否计费：这直接决定你的实际单价，尤其在有重试逻辑的服务里。
• 渠道加价倍率：中转渠道的价格要换算回官方口径再比，可信度判断标准见站内检测页面。
• 限速与并发上限：写清楚你这条通道能跑多少并发，别只看单价。

最后补一句，上面这套方法不适用于一种情况：你只是偶尔跑几个实验性请求，用量小到波动可以忽略，那这时候纠结单价意义不大，直接选接入最省事、文档最清楚的通道就行。

价格表是用来对齐口径的，不是用来背数字的；口径没对齐，比出来的高低都是假象。