Skip to main content

​
一句话总结

平台所有余额和扣费在底层以整数额度点（quota）记账：1 美元 = 500,000 点，人民币按固定换算 1 美元 = 7 元 折算。每次请求先按单价精确计算费用，再取整为整数点扣除——按 token 计费用向上取整，按次/按张计费用四舍五入，两种方式单次取整偏差都不足 1 点（不足 ¥0.000014）。对账时看到的微小尾差和”除不尽”的数字，都来自这套整数账本，属于确定性的、可复算的规则，不是计费错误。

​
额度点：平台的记账单位

余额、扣费、消费日志的原始记录都使用同一个单位——额度点。它是一个整数，与货币的换算关系固定： 平台使用整数账本而不是直接记金额，是因为模型调用是高频、单笔金额极小的扣费场景：每一笔都以整数点入账，累计值才能精确核对，不会产生小数金额反复累加带来的误差。你在账号余额查询 API 中拿到的 quota、used_quota 就是这个原始整数值。

​
美元与人民币的关系

记账体系锚定美元（上游模型厂商基本以美元报价），人民币是在美元基准上按 固定换算率 1 : 7 得出的。需要注意：
  • 这个 7 : 1 是平台内部的固定换算常数，不随市场汇率浮动。人民币价目表已按该换算率定价，不存在”今天汇率变了导致扣费变化”的情况。
  • 余额展示币种（默认人民币，可在「个人资料」切换为美元）只影响显示，不影响原始额度点和实际扣费。
同一个余额的三种视角： 展示金额统一四舍五入保留 6 位小数；日志导出（CSV）中的金额列同样按此规则换算。

​
一次请求如何扣费

以按 token 计费的模型为例，扣费分三步：
缓存命中、缓存写入、推理等分项 token 会先按各自单价折算并入输入/输出，再进入第二步求和——这些 token 分项合并后只做一次向上取整，不是每个分项各取整一次。（按次附加项如 Claude Web Search 是例外，它单独取整后再计入，见下文按次计费小节。）分项公式见计费对账。

​
示例：可以用计算器验算

假设某模型输入单价 ¥3.5/百万Token、输出单价 ¥17.5/百万Token，一次请求消耗输入 1,234 token、输出 567 token：
示例里带 6 位以上小数的是数学精确值（如 ¥0.0142415），用于展示取整前后的差异；账单和余额上显示的是取整后额度点对应的金额（¥0.014252）。对账请以后者、或直接以额度点为准。

​
按次 / 按张计费的模型

图片、视频等按次计费的模型不走 token 公式，单次费用为固定点数。注意这里用的是四舍五入（结果可能略高、也可能略低），与 token 计费的向上取整不同：
例如单价 ¥0.8/次：0.8 ÷ 0.000014 = 57,142.857 → 四舍五入 57,143 点 ≈ ¥0.800002（这里进位，略微多计）。若某单价四舍五入后落在下方，则略微少计，例如 ¥0.6/次：0.6 ÷ 0.000014 = 42,857.14 → 42,857 点 ≈ ¥0.599998。两种情况偏差都不足 1 点，且同一单价每次调用的扣费点数完全一致。（其中 0.000014 就是上一节的「1 点 = ¥0.000014」。）使用了按次附加项（如 Claude Web Search）时，附加项单独取整后计入。

​
为什么额度会向上取整

这一节说的是按 token 计费的模型（按次/按张用四舍五入，见上一节）。账本是整数的，而精确费用几乎总是带小数，必须选择一个取整方向。平台对 token 计费选择向上取整，原因是： 保证不足 1 点的正费用不被记成 0。 一次调用如果算出来是 0.3 点，向下取整会变成 0（等于免费、账本上也不留痕迹）；向上取整则记为 1 点，让每一笔真实产生了费用的调用都在账本上留下记录。这也是「最低 1 点」的由来——对按 token 计费、输入单价不为零的模型，只要产生了有效 token，单次至少记 1 点（¥0.000014）。方向统一、规则公开，任何一笔 token 扣费都可以用上面的公式复算出完全相同的结果。 取整带来的偏差有严格上界：每一次向上取整最多多计不足 1 点，即不足 ¥0.000014。直观感受一下量级：即使 100 万次 token 请求全部踩到最大偏差，合计也不超过 ¥14。

​
为什么会出现”除不尽”

对账时看到 ¥0.014252、71,428.57 这类”不整”的数字，来源有两个，都是数学上的必然而不是精度丢失： 来源一：人民币换额度点要除以 7。 1 元 = 500,000 ÷ 7 = 71,428.5714…点，是无限循环小数（除不尽、小数点后无限循环）。所以人民币的”整”金额（¥0.01、¥1、¥100）换成额度点几乎都除不尽，落账时取整为整数点，反算回金额就与原金额差出不足 1 点。美元金额则基本都能整除（$0.01 = 5,000 点整，$1 = 500,000 点整）。
来源二：单价按”每百万 token”报价，摊到单个 token 是小数。 例如 ¥2/百万Token 的单价，换算成每 token 点数是 2 ÷ 14 = 0.142857…点，也是循环小数。它再乘上任意 token 数，结果通常仍带小数，最终靠整单一次向上取整落到整数。
如果希望对账做到零误差，直接以额度点为核对基准（日志导出中的原始额度列），点数是精确整数；金额列只是点数的换算展示。以金额核对时，单笔允许 ¥0.0001 以内的尾差即可，详见计费对账的精度说明。

​
常见问题

不会。计费是确定性的：同一模型、同一价目、相同的 token 分项用量，算出的额度点完全一致。取整规则是固定的数学运算，不含随机因素。
1 点 = $0.000002 = ¥0.000014，6 位小数刚好能精确表达任意整数点数对应的金额，所以平台的金额列是额度点的精确换算，显示本身不引入误差。手工按”token × 单价”算出的金额与账单的差异来自扣费时的向上取整（见上文），单笔不足 1 点。需要零误差核对时，直接比对原始额度点整数值。
不会自动浮动。它是平台计费体系的固定换算常数，人民币价目表以它为基准制定。若未来调整会通过价目更新公告，不会追溯已发生的扣费。
不会。每次请求通常只取整一次（含按次附加项时每个附加项各一次），每次多计不足 1 点，即不足 ¥0.000014。即使按一天 10 万次请求、每次都踩到最大偏差估算，一天合计也不到 ¥1.4，实际偏差远小于此。
不会。展示币种只改变余额和日志里金额字段的显示口径，原始额度点、模型单价和扣费逻辑完全不变。详见账号余额查询 API 的字段说明。