别只比单价：模型平台的成本结构该怎么对比

数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。

定价页第一行的那个单价，是六家平台里最容易比、也最没用的一项。真正决定月底账单的是它下面四层：计量单位到底是 token 还是字符、秒、张、小时；长上下文要不要整体切到更高一档；缓存优惠从哪一段扣、有没有额外的写入或存储费；以及工具调用这种由模型自己决定次数的开销挂在谁头上。这四层里随便一层对不上，两家的”每百万 token 单价”就没有可比性。一个已经被官方文档写死的例子：Grok 定价页在长上下文档位下面注明，prompt token 达到所列阈值的请求，该请求内的全部 token 都按更高一档计价；而 Kimi 官方在账号与财务 FAQ 里对 K3 的说法是”计费不按上下文长度分段”，输入输出各按统一单价。同一份长文负载放到这两家，成本曲线的形状是不一样的。下面这七节，按你真正会踩到的顺序，把六家官方文档里与成本结构相关的条款摆到一起对照。

一、先对齐计量单位，否则后面全白比

六家的文本模型都按 token 计费，但只要业务里出现多模态，计量单位立刻分叉。

智谱在费用问题 FAQ 里写得最直白：图像模型、视频模型、搜索模型按次收费，不消耗 tokens，所以这些调用的响应里也不会返回 token 消耗——官方在费用问题 FAQ 里专门立了”图像模型怎么不返回 tokens 消耗？“这一条来回答它。阶跃星辰在计费介绍里说明，多模态大模型的图片输入会按固定 token 数核算后并入总用量（换算系数以官方文档为准），也就是说图片最终还是回到 token 口径；它的语音模型则完全另起一套，文本转语音按字符计价，语音识别按音频时长计价。MiniMax 更极端，语音按字符数计费，并且官方明确了汉字与字母、标点、空格各自计作几个字符；视频生成按秒计费并区分分辨率，输入素材里的图片超出免费张数后按张计费，音频输入免费。

所以”每百万 token 多少钱”这个比法，只在纯文本负载上成立。业务里一旦有图片、语音、视频，你得先把各家的计量单位换算到同一个口径——通常是换算成”每次业务动作的成本”，而不是”每百万 token 的成本”。

还有两处容易被忽略的入账口径：智谱明确体验中心的计费规则与 API 调用一致（在网页控制台里点着玩也是要付钱的）；Kimi 则说明文件内容抽取与文件存储接口限时免费，但抽取出来的文档内容一旦作为输入传给模型，这部分内容照常按量计费。

二、长上下文是不是分档，差出的是一整档

这一节是六家里差异最大、也最影响长文与 Agent 场景预算的一处。

Grok 定价页对长上下文的说明是：列出两行价格的模型采用长上下文计价，请求的 prompt token 达到所列阈值时，该请求内所有 token 都按更高一档计费。注意是”所有 token”，不是”超出部分”——这是个阶跃式的成本跳变，不是线性增长。MiniMax 的按量计费页同样把语言模型分成两档，按输入 token 是否超过某个长度切换档位，缓存读取价也跟着切换。

Kimi 走的是另一条路。官方在账号与财务页里对 K3 的表述是：上下文长度为 1M tokens，计费不按上下文长度分段，所有用量均按量付费，输入（区分缓存命中与未命中）与输出分别按统一单价计费。

这个差别落到成本估算方法上：对分档的平台，你不能用”月总 token 数 × 单价”估算，必须先看请求的长度分布——少量超长请求就能把整月成本抬到另一个量级；对不分档的平台，总量估算才是成立的。选型时如果你的负载是”大部分请求短、偶尔灌一份超长文档”，分档规则的杀伤力比单价差异大得多。

三、缓存优惠扣在哪一段，各家不一样

六家都提供前缀缓存、都说命中部分按更低价格计费，但优惠的作用位置和附加成本项各不相同。

智谱的上下文缓存文档里有一条限定条件特别关键：缓存的差异化计费仅适用于标准 API 计费，不包括资源包和 GLM Coding Plan 套餐。也就是说，你如果是拿套餐或资源包在跑，缓存命中率再高也不体现在这条优惠上。命中量从 usage.prompt_tokens_details.cached_tokens 读。

阶跃星辰的定价表把缓存未命中与缓存命中的输入价格做成两列并排，缓存优惠直接体现在输入价这一列；它的 Prompt 缓存文档还说明缓存淘汰采用 LRU 策略，系统请求高峰期不使用的缓存更容易被逐出，低峰期缓存生命周期更长——这意味着同样的代码，在不同时段跑出来的实际成本可能不同。命中判据是响应 usage 里是否存在 cached_tokens 字段。

Kimi 的上下文缓存对所有模型请求自动启用，官方强调无需手动创建、无需引用缓存 ID、无需管理 TTL；但它有一条门槛：前一个请求的 prompt token 数低于官方给出的门槛时，该请求不会被缓存而是被丢弃（门槛数值以官方文档为准）。短 prompt 场景压根进不了缓存，这一点在估算优化空间时要先排除掉。

Grok 的缓存优惠有个顺序问题值得单独记：官方在优先级处理文档里写明，缓存优惠仍会在倍率生效之前应用到缓存输入 token 上。另外它的命中字段在两个 API 面上路径不同——Chat Completions 走 usage.prompt_tokens_details.cached_tokens，Responses API 走 usage.input_tokens_details.cached_tokens，监控代码照抄会读到空值。

MiniMax 的定价表里除了”缓存读取”还单列了”缓存写入”一项，也就是写入缓存这个动作本身就是一个独立的计费项：缓存读取按优惠价计费，首次写入需要额外计费，具体单价与相对关系见官方定价页。估算优化收益时，这一项要单独摊进去，只按”命中就省下一截”来算会偏乐观。Gemini 则更进一步：官方 FAQ 把计费依据列为输入 token 数、输出 token 数、缓存的 token 数、缓存 token 的存储时长四项，缓存的存储是单独计费的，长上下文文档里说明这部分按小时计。这跟只按命中量给优惠的国产平台是两种成本模型，六家横向对照的细节可以看六家缓存机制横评与缓存计费的通用机制。

四、工具调用是账单里最难预算的一块

只要你的应用带联网搜索或服务端工具，token 成本就不再由你的代码决定，而是由模型自己决定。

Kimi 的联网搜索计费逻辑写得非常具体：当你在 tools 里加入 $web_search 工具，并拿到一个 finish_reason = tool_calls 且工具名为 $web_search 的响应时，会收取一次工具调用费用；响应 finish_reason = stop 时不收。更要紧的是搜索结果的 token 去向——官方给的计费公式是 total_tokens = prompt_tokens + search_tokens + completions_tokens，而搜索结果占用的 token 会计入下一次调用 /chat/completions 的总 token 里，占用量可以从 tool_call.function.arguments 中取到。这意味着账单上那一笔膨胀的输入 token，对应的其实是上一轮的搜索结果。反过来，如果触发了工具调用却就此停止、不继续完成 tool_calls，官方说明只收工具调用费用，搜索内容占用的 token 不计费。

Grok 的服务端工具计费拆成两个部分：token 用量与工具调用次数。官方明确写着，由于 Agent 自主决定调用多少次工具，成本随查询复杂度增长；计入的 token 类型包括输入 token、推理 token、补全 token、图像 token 和缓存命中的 prompt token 五类。响应里可以读 server_side_tool_usage（xAI SDK）或 usage.num_server_side_tools_used 看这一轮到底调了几次工具。

Gemini 的接地（Grounding）也是单独计费项，官方特别注明一次客户请求可能触发多次 Google 搜索查询，而每次查询单独收费。

三家的官方措辞指向同一个结论：Agent 类应用的成本方差远大于普通对话应用，做预算时不能只算 token，得先估工具调用次数的分布。

五、批量接口的便宜，是拿确定性换的

智谱、Kimi、Gemini、Grok 四家的官方文档里都写了比标准价更低的批量接口，但让渡的东西同样写在文档里，一条条读下去比看价格差更有用。

智谱的 Batch API 说明里，原有的 completion_window 时间参数已标注为废弃，新的调度策略按系统负载自动调整；如果批次未能及时完成，该批次会被标记为过期状态，未完成的请求被取消，而已完成的请求仍需付费——这一笔支出容易在做预算时被漏掉。Kimi 的批量推理页则说明 Batch API 支持的模型是有限的几个，任务需在指定的 completion_window 内完成，超时变为 expired 状态，且不受实时并发限制。Gemini 的 Batch API 按低于标准价计费，官方给出的目标周转时间是 24 小时（多数情况更快），并且限流完全独立于非批量调用，另有并发作业数、输入文件大小等一组独立约束；官方还注明 Batch API 目前仅适用于 generateContent API。

Grok 把这笔交换直接做成了一张实时接口与批量接口的对照表：响应时间从秒级立即返回变成通常 24 小时内，价格从标准定价换成更低的批量定价，限流那一栏写的是批量请求不计入速率限制，适用场景则从交互式实时调用换成后台处理与批量作业。表格下面那条注脚值得单独抄一遍——官方说明大多数批次会在 24 小时内完成，但处理时间会随系统负载与批次大小变化，完成时间属于尽力而为、不做保证。它的成本回读也跟着走批量路径：批量结果里带每个请求的费用，可以自行累加得到整批成本，也可以直接读 batch 对象上的 cost_breakdown 字段。

换句话说，批量接口的低价换来的是”完成时间不确定 + 失败也可能付费”。适合跑评估、数据预处理这类可以隔夜的任务，不适合放进有 SLA 的链路。批量与缓存两条降本路线怎么选，站内有缓存与批量的取舍一篇专门讲。

六、你的钱放在几个口袋里，决定了停机方式

这一层最容易被跳过，但它决定的是”什么时候会突然不能调用”。

智谱是资源包 + 现金余额双账户：调用时优先扣除满足模型适用场景的资源包余额，再扣现金余额；存在多个相同适用场景的资源包时，优先扣最快过期的那个；欠费状态下仍可使用有效期内的资源包；资源包过期后不支持延期、续费或重新激活。它还叠了一层积分权益体系——消耗现金余额或购买资源包可获得积分，积分决定并发权益等级（官方分四级），平台按最近三个月的最高积分确定当月等级。三条容易踩的细则：赠金账户的余额消耗不换算成积分；发生退款时积分同步扣减；参与优惠活动时按优惠前金额计算积分，以免因为优惠导致等级下滑。

Kimi 提供了一个可以直接调的余额接口 /v1/users/me/balance，返回 available_balance、voucher_balance、cash_balance 三个字段。官方对字段关系的说明值得抄进监控代码：cash_balance 可以为负值表示欠费，为负时 available_balance 等于 voucher_balance；available_balance 小于等于零时无法调用推理 API，此时调用返回 exceeded_current_quota_error。另外它的限速等级基于账户累计充值金额，而代金券不计入累计充值总额——用券和充值对限流的影响完全不同。

阶跃星辰的企业组织走 Credit 账户，规则写得最细：一次调用实际可扣减的 Credit 不超过账户余额、项目当期剩余上限、成员当期剩余上限三者中的最小值，超过该值时调用被拒绝且不产生扣费。项目上限之和可以超过账户余额，成员上限之和也可以超过项目上限，实际可用额度取最紧的一项。Credit 有有效期，到期未用自动失效且不可恢复，账户中存在多笔时按到期时间由近及远依次扣除。

MiniMax 是两套 Key 两套钱：按量计费用普通 API Key 扣账户余额，Token Plan 订阅与积分走专属的订阅 Key，官方明确两种 Key 不可互换。套餐额度的扣减口径也说清楚了——对已有按量计费价格的 API 端点，用量按对应的按量计费价格扣减套餐内额度，额度以固定小时窗口与周窗口两层计量。窗口用尽后官方给的四条路是：用已购积分自动补充、升级订阅或请团队管理员分配更高额度、把订阅 Key 换成按量计费 API Key 继续跑、或者等窗口重置。

Grok 分预付点数与月度账单两种，月度账单默认关闭需要联系销售开通。官方写明：当账单额度上限保持默认值时，xAI 只使用你的预付点数，预付点数耗尽后 API 请求会被自动拒绝；提高账单额度上限后会先用预付点数、余下部分月底从默认支付方式扣款。预付点数不支持退款（法律另有要求的地区除外），自动补充点数可以配置触发余额、每次补充量与每月上限。Gemini 那边最值得记的是一条运维风险：官方说明预付款余额归零时，该结算账号下所有项目的所有 API 密钥同时停止工作。

七、上限怎么设、账单怎么对

最后一层是可观测性，六家的成熟度差得很明显。

Grok 是唯一一家把单次请求的实际扣费直接放进响应的：官方说明每个推理响应的 usage 对象里都带 cost_in_usd_ticks 字段，值是整数 ticks（用整数是为了避免浮点舍入误差累积），代表这一次请求实际被收的钱——已经包含所有优惠、所有 token 成本和所有服务端工具调用成本，不需要事后去查账单。三处细节：这个值是单请求的，多轮对话要自己累加；流式调用走 OpenAI SDK 或 REST 时必须设 stream_options: {include_usage: true}，而且成本只出现在最后一个 chunk（choices 为空的那个）；官方还注明 Vercel AI SDK 当前不透出这个字段，要读只能用 OpenAI SDK 或裸 REST。

预算上限方面，Kimi 支持在项目设置里配置”项目日消费预算”，达到上限后系统自动拒绝该项目下所有 API 请求，官方同时提示由于计费延迟，限制生效存在分钟级的滞后。阶跃星辰的项目与成员月度上限按自然月统计、每月一号重置，月中启用按完整上限计算不按剩余天数摊，月中修改上限值时已用量不清零、周期也不重置，新上限直接减去已用量。它还有一处排查要点：额度上限与速率限制返回的状态码同为 429，必须靠错误标识区分——project_credit_limit_exceeded 与 member_project_credit_limit_exceeded 是额度问题，余额不足则是 402 配 insufficient_credit。Gemini 的支出上限分结算账号级与项目级两层，官方标注项目级为实验性且适用范围有限；同时官方列出了一串结算延迟，包括结算流水线本身的延迟（期间可能产生超额用量，批量模式与长时间运行的 Agent 任务尤其容易在系统停止前继续消耗），以及费用明细图表的更新延迟。这类延迟意味着”设了上限”不等于”花不超”。

估算侧还有一个坑：Grok 官方 FAQ 明确说明，推理端点会加入预定义的 token 来处理请求，因此实际的 prompt token 消耗会高于你用控制台 tokenizer 或 tokenize 接口算出来的数。Kimi 提供了 /v1/tokenizers/estimate-token-count 接口做事前估算。事前估算永远只是下界，真实用量以响应里的 usage 为准。

收尾：对比时按这七层填表，别按单价排序

真要做横向对比，把上面七节变成七行表格去填，比抄六家的单价有用得多：计量单位是什么、长上下文分不分档、缓存优惠作用在哪一段有没有附加费、工具调用怎么计、批量的失败是否付费、钱分几个口袋、单请求成本能不能从响应里读到。

最容易栽的坑是第二层和第四层：分档规则让”总量 × 单价”这种估算方法直接失效，而工具调用让成本从”你能控制的”变成”模型决定的”。这两条都不会出现在定价页的第一行。真正落地时，先把成本监控的字段读法在两家平台上都跑通，再谈换不换。