一句话总结
GregAPI 底层以「额度点」为整数记账单位，美元与人民币按固定汇率换算；按 token 计费的请求向上取整，这也是金额出现「除不尽」和「最低 1 点」的由来。额度点：平台的记账单位
平台所有余额和扣费底层以整数额度点（quota）记账。
使用整数账本的原因：模型调用高频、单笔金额极小，整数点入账累计值才能精确核对，避免小数金额反复累加误差。余额查询 API 中的
quota、used_quota 就是这个原始整数值。
美元与人民币的关系
记账锚定美元（上游模型厂商基本以美元报价），人民币按固定换算率 1:7 得出。7:1 是平台内部固定换算常数，不随市场汇率浮动。余额展示币种（默认人民币，个人资料可切美元）只影响显示，不影响原始额度点和实际扣费。 同一余额三种视角示例：原始额度点 1,000,000 = 美元 $2.000000（1,000,000÷500,000）= 人民币 ¥14.000000（美元×7）。展示金额四舍五入保留 6 位小数；日志导出 CSV 金额列同规则换算。一次请求如何扣费
按 token 计费分三步：示例：可以用计算器验算
输入 ¥3.5/百万Token、输出 ¥17.5/百万Token，输入 1,234 token、输出 567 token： 每 token 点数 0.25 / 1.25；精确点数 1,234×0.25 + 567×1.25 = 1,017.25 点 →ceil = 1,018 点 = ¥0.014252（精确应为 ¥0.0142415，多计 0.75 点 ≈ ¥0.0000105）。
按次 / 按张计费的模型
图片、视频等按次/按张计费不走 token 公式，用四舍五入：单次点数 = 四舍五入(单价 ÷ 0.000014)，按张计费再乘张数。 例：¥0.8/次 → 57,142.857 → 57,143 点 ≈ ¥0.800002（略多）；¥0.6/次 → 42,857.14 → 42,857 点 ≈ ¥0.599998（略少）。偏差不足 1 点，同单价每次扣费点数一致。为什么额度会向上取整
账本为整数，token 计费选择向上取整是为了保证不足 1 点的正费用不被记成 0（0.3 点向下取整会变 0 免费）。这也是「最低 1 点」的由来——按 token 计费、输入单价非零的模型，只要产生有效 token，单次至少记 1 点（¥0.000014）。每次向上取整最多多计不足 1 点，100 万次 token 请求全踩最大偏差合计也不超过 ¥14。为什么会出现”除不尽”
- 来源一：人民币换额度点要除以 7，1 元 = 71,428.5714… 点无限循环，人民币”整”金额换算几乎都除不尽。例：¥0.01 → 714.2857… 点 → 向上取整 715 点 → 反算 ¥0.01001（差 ¥0.00001）。美元金额基本能整除（1=500,000 点整）。
- 来源二：单价按”每百万 token”报价，摊到单 token 是小数（如 ¥2/百万Token → 2÷14 = 0.142857… 点）。
常见问题
- 相同 token 用量扣费是否相同？ 是，确定性计费无随机。
- 6 位小数对不平怎么办？ 金额列是额度点精确换算，差异来自取整，单笔不足 1 点。
- 7:1 会随汇率调整吗？ 不会自动浮动；调整会出价目公告，不追溯已发生扣费。
- 向上取整会不会多付很多？ 每次多计不足 1 点（¥0.000014），一天 10 万次全踩偏差也不到 ¥1.4。
- 切换 CNY/USD 影响计费吗？ 不影响，只改显示口径。