token计费怎么算

很多人第一次看账单会懵：明明只发了几句提示词，费用却比预期高；或者反过来，明明调用次数不少，账单看着还行。问题多半不在平台，而在你没弄清「输入」和「输出」是两条独立计价线，乘的又不是同一个数。这篇给一套能对着用量记录直接套的算法顺序，从单价、token 数、倍率一路算到最终金额，并说清哪些情况下这套算法会失真。

很多人第一次看账单会懵：明明只发了几句提示词，费用却比预期高；或者反过来，明明调用次数不少，账单看着还行。问题多半不在平台，而在你没弄清「输入」和「输出」是两条独立计价线，乘的又不是同一个数。这篇给一套能对着用量记录直接套的算法顺序，从单价、token 数、倍率一路算到最终金额。

整套思路就一句话：先把输入和输出分开，各自算出分项金额，再统一乘修正系数，最后累加跟账单对一遍。下面按这个顺序拆开讲，每一步都给你能直接做的动作。

先分清：输入和输出是两条独立计价线

最容易犯的错是用一个单价乘总 token 数。实际上输入和输出通常是两套价，输出一般更贵，理由也简单：输出是模型一个字一个字生成的，算力占用更长。你只要把用量记录拉出来看，输入和输出往往就是两列，先别合并它们。

输入 token

你发给模型的内容被切分后的计量数，包含提示词、历史对话、附加上下文

输出 token

模型生成返回给你的内容被切分后的计量数，通常单价高于输入

计价单位

常见是按每百万 token 报单价，换算时先归一化到同一单位再乘

修正系数

倍率、折扣、汇率、渠道加成等，乘在分项金额之后，不是乘在 token 数上

有些模型还有缓存写、缓存读、推理思考等分项。判断方法很直接：打开你的用量记录，看有没有这几栏。有就单独列出来参与计算，没有就当它不存在，不用硬套。各家具体单价和口径不一样，别记数字，到 /official-api 和 /price-watch 核对当时的数字。

一套能直接套的四步算法

下面四步按顺序做，中间别跳步。每一步都有验证动作，做完能立刻知道哪里对不上。

1. 第一步：分列加总把用量记录里的输入 token 数和输出 token 数分别加总，不要先合并成一个总数。验证：两个数加起来应该等于记录里的总量，不等说明有分项被漏掉。
2. 第二步：各自算分项金额输入 token 数除以计价单位再乘输入单价，输出同理，得到两个分项金额。验证：分项金额量级应该合理，如果某项明显偏高，先回头查那一类的调用日志。
3. 第三步：乘修正系数把两个分项相加，再乘倍率、折扣或汇率等修正系数。验证：系数来源要写清楚，渠道倍率到 /sites 查该渠道的说明，别用记忆里的旧数。
4. 第四步：累加对账把每轮结果累加，跟账单总额对一遍。验证：差额集中在哪一类调用，就去查那一类的用量日志，而不是全量重算。

算出来对不上，先查这四处

复算和账单不一致很常见，别急着怀疑平台。按下面顺序排查，命中率最高的是第一条。

• 缓存命中与否：命中缓存的输入往往按另一档计价，用量记录里可能单列一行，漏掉这行输入侧就会偏高或偏低。
• 重复计费：重试、限速退回后重发是否重复计入，看 /retry-billing-limits 的口径说明，别默认重试免费。
• 上下文累积：多轮对话每轮都把历史带上，输入 token 是滚雪球式增长的，轮次一多输入侧会远超你的直觉。
• 计量口径差异：中转站与官方对 token 的切分、倍率换算可能不同，先到 /sites 和 /rankings 查可信度再下结论。

这四条里，前两条属于「记录里就看得出来」的问题，后两条属于「要对比才看得出来」的问题。排查时先把前两条排掉，再去比对渠道口径，能省不少时间。

日常自查：两步就能兜住大部分偏差

你不需要每次都手工算全量账单，固定两个动作就够用。它们能挡住大部分异常，也不会占用太多时间。

1. 每周抽一次复算固定每周抽一次账单，按上面四步复算一遍总额，偏差超过一成就去翻用量日志定位。别每天算，频率太高坚持不下来。
2. 维护一张四数小卡把「输入单价、输出单价、倍率、计价单位」四个数记在一张纸上或表格里，换模型或换渠道时只改这几个数。单价数字到 /price-watch 核对，不要凭记忆。

什么情况下这套算法会失真？一是你的用量里存在平台未在记录中展示的内部分项，二是跨渠道比对时两边计价口径没对齐。遇到这两种情况，先对齐口径再算，别硬套。

账单对不上，九成不是平台算错，是你把两条计价线当成了一条。