> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xuwuai.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 额度计费原理

> 底层额度点体系、美元/人民币换算、向上取整与除不尽的由来

## 一句话总结

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

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

余额、扣费、消费日志的原始记录都使用同一个单位——额度点。它是一个整数，与货币的换算关系固定：

| 单位    | 换算                                |
| ----- | --------------------------------- |
| 1 美元  | 500,000 点                         |
| 1 人民币 | 500,000 ÷ 7 ≈ 71,428.5714… 点（除不尽） |
| 1 点   | 0.000002 美元 = 0.000014 人民币        |

平台使用整数账本而不是直接记金额，是因为模型调用是高频、单笔金额极小的扣费场景：每一笔都以整数点入账，累计值才能精确核对，不会产生小数金额反复累加带来的误差。你在[账号余额查询 API](/guide/balance-api) 中拿到的 `quota`、`used_quota` 就是这个原始整数值。

## 美元与人民币的关系

记账体系锚定美元（上游模型厂商基本以美元报价），人民币是在美元基准上按 **固定换算率 1 : 7** 得出的。需要注意：

* 这个 7 : 1 是平台内部的**固定换算常数**，不随市场汇率浮动。人民币价目表已按该换算率定价，不存在"今天汇率变了导致扣费变化"的情况。
* 余额展示币种（默认人民币，可在「个人资料」切换为美元）**只影响显示**，不影响原始额度点和实际扣费。

同一个余额的三种视角：

| 视角    | 值          | 说明                  |
| ----- | ---------- | ------------------- |
| 原始额度点 | 1,000,000  | 账本真实记录，整数           |
| 美元展示  | \$2.000000 | 1,000,000 ÷ 500,000 |
| 人民币展示 | ¥14.000000 | 美元 × 7              |

展示金额统一四舍五入保留 6 位小数；日志导出（CSV）中的金额列同样按此规则换算。

## 一次请求如何扣费

以按 token 计费的模型为例，扣费分三步：

```
第一步：把人民币单价换算成"每 token 多少点"
        每 token 点数 = 人民币单价(元/百万Token) ÷ 14
        （÷14 的来历：¥1 ≈ 71,428.57 点，摊到每百万 token 就是 ÷14）

第二步：按用量精确计算（结果通常带小数）
        精确点数 = 输入Token × 输入每token点数 + 输出Token × 输出每token点数

第三步：向上取整为整数，从余额扣除
        实际扣费 = ceil(精确点数)
```

<Note>缓存命中、缓存写入、推理等分项 token 会先按各自单价折算并入输入/输出，再进入第二步求和——**这些 token 分项合并后只做一次向上取整**，不是每个分项各取整一次。（按次附加项如 Claude Web Search 是例外，它单独取整后再计入，见下文按次计费小节。）分项公式见[计费对账](/guide/billing-reconciliation)。</Note>

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

假设某模型输入单价 ¥3.5/百万Token、输出单价 ¥17.5/百万Token，一次请求消耗输入 1,234 token、输出 567 token：

```
每 token 点数：输入 3.5 ÷ 14 = 0.25 点，输出 17.5 ÷ 14 = 1.25 点

精确点数：1,234 × 0.25 + 567 × 1.25
        = 308.5 + 708.75
        = 1,017.25 点

实际扣费：ceil(1,017.25) = 1,018 点
        = ¥0.014252（1,018 × 0.000014）

精确金额本应是 ¥0.0142415，取整多计 0.75 点 = ¥0.0000105
```

<Note>示例里带 6 位以上小数的是**数学精确值**（如 ¥0.0142415），用于展示取整前后的差异；账单和余额上显示的是取整后额度点对应的金额（¥0.014252）。对账请以后者、或直接以额度点为准。</Note>

### 按次 / 按张计费的模型

图片、视频等按次计费的模型不走 token 公式，单次费用为固定点数。注意这里用的是**四舍五入**（结果可能略高、也可能略低），与 token 计费的向上取整不同：

```
单次点数 = 四舍五入(单价 ÷ 0.000014)，按张计费时再乘以出图张数
```

例如单价 ¥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 点整）。

```
例：¥0.01 应扣多少点？
0.01 ÷ 0.000014 = 714.2857… 点  → 向上取整 715 点
715 点反算 = ¥0.01001（差 ¥0.00001）
```

**来源二：单价按"每百万 token"报价，摊到单个 token 是小数。** 例如 ¥2/百万Token 的单价，换算成每 token 点数是 2 ÷ 14 = 0.142857…点，也是循环小数。它再乘上任意 token 数，结果通常仍带小数，最终靠整单一次向上取整落到整数。

<Tip>如果希望对账做到零误差，直接以**额度点**为核对基准（日志导出中的原始额度列），点数是精确整数；金额列只是点数的换算展示。以金额核对时，单笔允许 ¥0.0001 以内的尾差即可，详见[计费对账](/guide/billing-reconciliation)的精度说明。</Tip>

## 常见问题

<AccordionGroup>
  <Accordion title="两笔 token 用量完全相同的请求，扣费会不同吗？">
    不会。计费是确定性的：同一模型、同一价目、相同的 token 分项用量，算出的额度点完全一致。取整规则是固定的数学运算，不含随机因素。
  </Accordion>

  <Accordion title="为什么金额都显示 6 位小数？和我手工算的对不平怎么办？">
    1 点 = \$0.000002 = ¥0.000014，6 位小数刚好能精确表达任意整数点数对应的金额，所以平台的金额列是额度点的**精确换算**，显示本身不引入误差。手工按"token × 单价"算出的金额与账单的差异来自扣费时的向上取整（见上文），单笔不足 1 点。需要零误差核对时，直接比对原始额度点整数值。
  </Accordion>

  <Accordion title="7:1 的换算率会随市场汇率调整吗？">
    不会自动浮动。它是平台计费体系的固定换算常数，人民币价目表以它为基准制定。若未来调整会通过价目更新公告，不会追溯已发生的扣费。
  </Accordion>

  <Accordion title="向上取整会不会让我多付很多钱？">
    不会。每次请求通常只取整一次（含按次附加项时每个附加项各一次），每次多计不足 1 点，即不足 ¥0.000014。即使按一天 10 万次请求、每次都踩到最大偏差估算，一天合计也不到 ¥1.4，实际偏差远小于此。
  </Accordion>

  <Accordion title="切换余额展示币种（CNY/USD）会影响计费吗？">
    不会。展示币种只改变余额和日志里金额字段的显示口径，原始额度点、模型单价和扣费逻辑完全不变。详见[账号余额查询 API](/guide/balance-api) 的字段说明。
  </Accordion>
</AccordionGroup>