计费总览（必须先读）

这页是 MagicCore Fuel 的计费总规则。你需要对账、控成本、做预算，先读这里就够。

计费的对象是什么？

Fuel 的计费对象不是“账号本身”，而是 API Key 发起的请求用量。

你可以理解为：

• 你每发一次模型请求，就会产生一次用量记录
• 用量记录会折算为成本（按模型/通道定价）
• 成本会从你的余额里扣除（或落到你的账单明细里）

一条请求最终怎么变成扣费金额（可对账口径）

不管你用的是 Chat Completions 还是 Responses，本质都可以抽象成同一条公式：

实际扣费 = 基础成本 × 综合倍率

其中：

• 基础成本（total_cost）：按价格表把输入/输出/缓存/图片等分别计价后相加的“原价”
• 综合倍率：把会员折扣等因素叠加后的倍率（你可以用 actual_cost / total_cost 直接算出来）

这套口径的好处是：你只要拿到「用量明细里的 token 数 + 价格表里的单价」，就能 手算复核 到最终扣费。

记住一句话：对账看“实际扣费”，预算看“价格表”。

Token 计费：可手算的拆分公式（完成态口径）

当一个模型的计费模式是 token（按 token 计费）时，一条请求通常会拆成 5 部分成本：

• 输入成本（InputCost）
• 文本输出成本（OutputCost）
• 图片输出 token 成本（ImageOutputCost，只有多模态输出才会出现）
• 缓存创建成本（CacheCreationCost，常见于 prompt caching / cache write）
• 缓存读取成本（CacheReadCost，常见于 cache read / cached tokens）

第 1 步：从用量明细取出 token 数

• input_tokens
• output_tokens
• cache_creation_tokens（以及可选的 cache_creation_5m_tokens、cache_creation_1h_tokens）
• cache_read_tokens
• image_output_tokens（可选）

第 2 步：确定本条请求用的基础单价（Official Price）

你需要的是“基础单价”（不含 VIP/SVIP 与模型倍率），通常来自定价页/模型价格表：

• price_input：输入每 token 价格（USD / token）
• price_output：输出每 token 价格（USD / token）
• price_cache_write：缓存创建每 token 价格（USD / token）
• price_cache_read：缓存读取每 token 价格（USD / token）
• price_image_output：图片输出 token 价格（USD / token，可为空；为空则回退为 price_output）

控制台若展示的是 “每 1M tokens 价格”，先换算：USD/token = (USD / 1_000_000 tokens) / 1_000_000。对账时你也可以直接用 “每 1M tokens” 算，不影响本质。

第 3 步：先算出基础成本（total_cost）

• text_output_tokens = max(output_tokens - image_output_tokens, 0)
• InputCost = input_tokens * price_input
• OutputCost = text_output_tokens * price_output
• ImageOutputCost = image_output_tokens * price_image_output（若 price_image_output=0 则用 price_output）
• CacheReadCost = cache_read_tokens * price_cache_read

缓存创建成本有两种口径（看平台是否开启 5m/1h 细分）：

• 若有细分：
  • CacheCreationCost = cache_creation_5m_tokens * price_cache_write_5m + cache_creation_1h_tokens * price_cache_write_1h
  • 如果明细没返回 5m/1h，但 cache_creation_tokens > 0：按 5m 单价兜底计算
• 若无细分：
  • CacheCreationCost = cache_creation_tokens * price_cache_write

最后：

• total_cost = InputCost + OutputCost + ImageOutputCost + CacheCreationCost + CacheReadCost

第 4 步：确认是否启用了 Service Tier（可选，但对账必须知道）

Fuel 支持 service_tier（常见：priority / flex / 空）。它通常会在“基础单价层”影响 total_cost。

• 如果你的价格表提供了对应的 service tier 单价：用对应单价复算
• 如果价格表没有单独列出：以控制台/用量明细的口径为准（此时建议直接用 total_cost 做对账，不必反推 service tier 的系数）

对账上最容易踩坑的点：你以为只变了“VIP”，其实是 service_tier 变了，导致 total_cost 的口径已经不同。

第 5 步：套用综合倍率，得到实际扣费（actual_cost）

对账时你只需要认准三个结论：

• 实际扣费看 actual_cost
• 基础成本看 total_cost
• 会员折扣通常能在 rate_multiplier 里看到（若控制台展示）

最终：

• actual_cost = total_cost × 综合倍率
• 综合倍率 = actual_cost / total_cost

如果你同时拿得到 rate_multiplier，那么通常有：

• 综合倍率 = rate_multiplier × 其他折算（如有）

实际对账时，你可以直接拿用量明细里的 total_cost 与 actual_cost 对比；如果两者差异与你的会员折扣/折算预期一致，基本就是一致的。

Per-request 计费（按次）与 Image 计费（按张）

Fuel 的计费模式不只有 token，还可能出现：

• per_request：按次计费（支持按上下文大小分层）
• image：图片生成按张计费（支持按分辨率 1K/2K/4K 分层）

它们的对账口径更简单：先确定“单价”，再乘以次数，再乘以会员折扣。

• total_cost = unit_price * request_count
• actual_cost = total_cost * rate_multiplier

其中：

• request_count：默认 1；图片生成通常等于 image_count
• unit_price：
  • 如果指定了 tier_label（例如图片的 1K/2K/4K）就优先用对应层级价格
  • 否则按上下文 token（input_tokens + cache_read_tokens）匹配一个区间的按次价格
  • 再否则回退到“默认按次价格”

关键点：在 per_request / image 模式下，通常仍然遵循“基础成本 → 实际扣费”的结构；用 actual_cost / total_cost 看综合倍率最稳。

计费的三个核心要素

1. 模型单价：不同模型不同价（还可能分 Official vs Final）
2. 计费口径：token / per_request / image 三种模式
3. 价格等级：默认 / VIP / SVIP（对应不同价格列，或不同 rate_multiplier）

钱从哪里来？

通常是 钱包余额：

• 你先充值
• 后续按用量扣费

平台也可能提供兑换码、活动赠送等“非现金余额来源”（以控制台实际功能为准）。

VIP / SVIP 会带来什么变化？

VIP/SVIP 不是“多给你一个 API 端点”，而是影响 你的价格等级与权益，常见影响包括：

• 更低的模型单价（同一模型在 VIP/SVIP 价格更低）
• 更高的并发/速率上限（如果平台开启）
• 更优先的通道（如果平台开启）

建议的对账方式（最实用）

1. 用量明细：按时间/Key/模型筛异常
2. 余额变动：核对每次充值与每次扣费
3. 订单/发票：留存财务凭证（如平台提供）

对账 Checklist（照着做就能定位问题）

当你怀疑“扣费不对 / 余额掉得太快”，按这个顺序排查通常最快：

1. 锁定时间段：先圈定异常发生的 10~30 分钟范围
2. 按 Key 聚合：看是否集中在某个 Key（Key 泄露/误用最常见）
3. 按模型聚合：看是否切换到了更贵的模型，或某模型输出 token 特别长
4. 看重试/并发：客户端超时后重试，会让“你以为一次请求”变成多次扣费
5. 抽样复算：抽 1~3 条用量记录，用价格表 + token 数手算一遍（对齐口径）

后面几页会把这些口径拆开写清楚。