大模型token计费标准

第一次接大模型 API，最容易懵的不是代码，而是账单：明明只调了几百次，为什么费用和自己心算的差一截？通常是计费口径没对齐——输入输出分开算、按什么单位算、哪些部分不计费，各家的写法都不一样。这篇不背价格表，而是把口径讲清、把估算步骤拆开，让你在写代码前就能算出一个八九不离十的区间，并在月底能对得上账。

第一次接大模型 API，最容易懵的不是代码，而是账单：明明只调了几百次，费用和自己心算的差一截。问题通常出在计费口径——输入输出分开算、按什么单位标价、哪些部分不计费，各家写法都不一样。下面不背价格表，而是把「大模型token计费标准」这件事拆成能自己动手的估算流程，让你在写代码前算出八九不离十的区间，月底对账时也知道差在哪。

先说清一个前提：这篇给的是方法和判断标准，不替任何平台下结论。所有会变动的数字，都要到站内对应页面核对当时的版本。方法本身不会过时，数字会。

先搞清「按什么算钱」：计费单位与口径

大部分平台把输入和输出分开计价，两边的单价通常不一样，这也是新手最容易踩的坑：拿一个均价去乘总 token 数，算出来的结果既不是账单也不是估算，只是巧合。动手之前，先把你要用的平台口径抄成一张小卡，后面每次估算都对着这张卡做。

Token 到底怎么数：中文、英文与代码的差异

token 不等于字数。中文一个字经常要拆成不止一个 token，英文一个单词也可能被切成几段，标点和空格同样占位。同一个平台上，一段中文说明书和一段等长的英文技术文档，token 数就不会一样；换成 JSON 或代码，密度还会再高一些。

• 中文正文：按字符数估会明显偏低，实算往往更高
• 英文与数字：短单词可能一个 token，长单词会被拆开
• 代码和 JSON：括号、引号、缩进都在计 token，别只看行数
• 别背固定系数，把真实请求样本拿去站内 token 换算工具跑一遍更准
• 同一段文本换模型族后计数也会变，估算要绑定你实际调用的那个模型

最省事的做法：从线上日志或测试用例里抽十条真实请求，逐条量出 token 数，取平均和最大值。这比找任何「换算口诀」都靠谱，因为量的就是你自己的文本分布。

一次请求由哪几块 token 组成

很多人估算时只算了用户那句话，忽略了前面还挂着一大坨。一次请求的输入侧，通常包含系统提示词、历史对话、当轮问题、外部参考资料；输出侧只有模型生成的那部分。把这几块分开量，你才知道钱花在哪。

系统提示词

每次请求都会带，本身可能很长，属于固定成本

历史对话

多轮场景下会反复带入，轮次越多输入侧膨胀越明显

当轮问题

用户这一句，通常占比不大但别漏算

外部参考资料

塞进上下文的知识片段，长度完全由你控制

输出侧

只有模型生成部分，长度受最大输出设置约束

一个常见误区：以为省钱靠换模型，其实先看输入侧。系统提示词砍掉一半、历史只带最近几轮、参考资料按需检索而不是整篇塞入，这些动作对账单的影响往往比换模型更直接，而且不影响效果太多。

估算四步法：从用量假设到费用区间

到这一步，你已经知道单价口径和 token 构成，可以开始算了。重点是把「一个数」改成「一个区间」，因为调用量、输入长度本身就有波动，给单点值只会让后面核对时更被动。

1. 定任务量写出每天调用次数、每次输入和输出的大致 token 区间，例如「每天几百次，输入几百到上千 token，输出几十到几百 token」，不要拍一个精确值。
2. 查单价到站内官方 API 价格页按当时的数字取值，确认对应模型的输入、输出两个单价，同时核对单位与币种。
3. 分项相乘再求和输入总量乘输入单价，输出总量乘输出单价，相加得到基础费用；缓存、批量等特殊口径单独列一行，别混进基础项。
4. 加波动系数把重试率、上下文增长、输出变长都折成一个上浮比例，得出费用上限；下限用最理想的调用量估。上下限之间的区间，才是可以拿去汇报的数字。

这四步做完，你会得到一个月度费用的区间。它的价值不在于精确，而在于让你提前知道「这个功能大概在什么量级」，以及哪一项一旦失控会最先炸。

把总量换算成「一次任务多少钱」

月度总量对工程同学不直观，对业务同学更不直观。换成「一次任务多少钱」就好沟通多了：一次客服问答、一份文档总结、一轮代码补全，各自花多少。这个换算只对输入输出长度相对固定的任务成立，长度忽长忽短的任务不适用，硬算会误导判断。

换算出单次成本之后，再横向对比不同模型就有意义了。差距出现在哪一环——是输入侧的系统提示词太重，还是输出侧生成太长——一眼能看出来。这时再去决定要不要换模型、要不要压缩上下文，依据就具体了。

上线前必须留哪些用量记录

估算做得再好，没有记录也没法验证。上线前先想清楚要记什么，否则月底只能对着账单猜，估算能力永远停在原地。记录粒度建议到单次调用，聚合之后的平均数据没法倒推是哪一步超支。

• 请求时间：用于按天聚合，看趋势而不是只看总数
• 模型标识：同一功能可能切过模型，混在一起算不准
• 输入 token 与输出 token：分开记，对应两个单价
• 是否命中缓存或走批量：独立计费口径要能单独统计
• 是否重试、是否失败：重复消耗往往藏在这里
• 请求耗时与状态码：异常请求可能也计费，需要单独对账

如果平台侧只提供聚合用量，那就自己在中转层或日志里补记。哪怕先记时间和 token 两列，也比什么都没有强。记录的目的是让每一次估算都有反馈，估算和实际越对越近，这个循环才有意义。

月末核对：账单和估算对不上的排查顺序

对不上很正常，关键是按固定顺序排查，而不是东看一眼西看一眼。下面的顺序从最常见、最容易犯的错开始，多数差异在前两步就能定位。

1. 查单位与币种先确认单价的单位是千还是百万，币种和结算币种是否一致；这类错会让结果差出好几个量级。
2. 查独立计费口径核对缓存、批量、工具调用等是否有单独计价，是否被漏算或重复算进基础项。
3. 查重复消耗看重试、超时重发、失败重放的比例；重试一次就是一次完整计费，容易积少成多。
4. 查长度漂移对比上线前后的输入长度，看上下文是否在悄悄变长、系统提示词是否被加料。
5. 回写估算模型找到差异原因后，把对应参数改回估算表，下一次估算才会更准。

排查时别急着下结论说「平台算错了」。先把自己的用量记录和账单逐项对齐，差异通常来自自己的调用行为和假设偏差，而不是计费系统。

哪些情况下这套估算不成立

这套方法有明确边界，用错场景会得出错误的安心感。下面几种情况，不能直接用 token 单价乘总量。

• 按次计费或订阅制套餐：不看 token，看调用次数或席位，估算逻辑完全不同
• 有阶梯价或活动折扣：实际扣费随用量档位变化，要用分段函数而不是单一单价
• 赠送额度与试用期：这段时间的账面消耗不代表长期成本，对账时要把赠送部分剥离
• 流式输出中断或被限速截断：计费口径各家不同，得按平台说明确认实际计入多少
• 输入输出长度剧烈波动的任务：单次成本换算失效，只能按月总量做区间估计

遇到这些情况，处理办法是回到平台说明逐条确认口径，并在估算表里单独开一行，不要硬套通用公式。口径本身就是标准的一部分，把它当例外而不是特例，账才算得清。

计费标准的核心不是记住数字，而是知道每个数字的口径、边界和更新位置。