计费体系
平台采用预付费、按 token 计费的模式。本页从管理员视角说明计费如何运作，以及哪些参数可调。
计费时机
- 每次请求在上游返回后，网关解析其 usage（各类 token 数）；
- 按命中的真实模型价格与倍率计算费用；
- 从用户余额扣费，并写入一条 用量日志（TokenLog）；
- 流式与非流式一致，网关会从流中解析 usage。
费用构成
1. 基础 token 费用
按模型的各维度单价（每百万 token）分别计算后求和：
基础费用 = Σ ( token_数[维度] × 单价[维度] / 1,000,000 )维度包括：输入、输出、缓存输入、缓存写入（含 1h）、图像输入/输出、音频输入/输出。各维度可独立定价，也可配置阶梯价格——按累计量或条件选择区间单价。
2. 倍率叠加
最终费用 = 基础费用 × 有效分组倍率 × 用户渠道倍率- 有效分组倍率：用户多分组时按
group_multiplier_mode（min/max）合并，覆盖优先级为「模型配置级 > 渠道级 > 分组默认」，详见 分组与倍率； - 用户渠道倍率：命中的用户渠道的倍率（默认 1）。
阶梯价格（Price Tiers）
每个价格维度都可配置阶梯列表（PriceTierList，JSON 存储）。常见用法：
- 按累计 token 量分档：用得越多单价越低（或越高）；
- 条件阶梯：根据请求的某些指标选择单价。
结算时网关按命中的阶梯取价。配置时确保区间衔接，避免空档导致取价异常。
余额与额度的关系
扣费要同时满足两道约束：
- 用户余额 足够；
- 若请求使用的 API 密钥 设了额度上限（
QuotaLimit），其累计消费不能超限。
任一不满足，请求被拒。
邀请返佣对计费的影响
如果开启邀请返佣，被邀请人产生消费时，平台会按 referral_commission_rate 把一部分金额返还给邀请人余额，并记录到返佣明细（ReferralCommissionLog）。返佣是额外发放给邀请人的，不改变被邀请人本次的扣费金额。
相关系统设置
| 设置键 | 默认 | 说明 |
|---|---|---|
group_multiplier_mode | min | 多分组倍率合并方式 |
referral_commission_rate | 0 | 邀请返佣比例 |
pricing_endpoint_enabled | false | 是否开放公开定价端点 GET /api/pricing |
payment_currency_display_name | $ | 余额显示符号 |
对账建议
- 全平台日志：
GET /api/logs；统计：GET /api/stats、GET /api/channel-usage； - 把日志按模型/渠道/时间聚合，与上游账单核对；
- 关注阶梯价命中分布与倍率配置，确认实际毛利符合预期。