成本记账

Sakana Fugu 编排 token 是额外工作,不是脚注

OpenAI 形状的字段名很容易让人以为 token_details 里的每一项都是已计入总额的拆分。对 cached_tokens 这确实成立——它就在 input_tokens 之内;但官方定价文档写明编排字段是额外真实用量,并按对应的输入、缓存或输出费率计费。

1. 存官方对象,不要猜子集

直播定价页和 Models 页公布了 Ultra(Models 页也对 Cyber)的这一形状:input_tokens 是发给第一个模型的用户输入总量,已包含缓存部分;cached_tokens 是其中命中缓存的那一部分(是子集,不是额外数量);orchestration_input_tokens 是编排输入合计,同样已包含其缓存部分;orchestration_input_cached_tokens 是该编排输入命中缓存的子集;output_tokens 是最终输出;orchestration_output_tokens 是在最终输出之外额外产生的编排输出;total_tokens 含编排。

两个 cached 字段沿用 OpenAI 的常规语义:各自是其所归属输入总量的子集,因此 cached_tokens ≤ input_tokens、orchestration_input_cached_tokens ≤ orchestration_input_tokens。只有编排字段是 input_tokens / output_tokens 之外的额外用量;普通输入总量本身已经包含其中的缓存部分。

usage
{
  "input_tokens": 120,
  "output_tokens": 80,
  "total_tokens": 200,
  "input_tokens_details": {
    "cached_tokens": 0,
    "orchestration_input_tokens": 0,
    "orchestration_input_cached_tokens": 0
  },
  "output_tokens_details": {
    "orchestration_output_tokens": 0
  }
}

2. 先减去各自缓存子集,再求和,最后乘费率

未缓存输入 = (input_tokens − cached_tokens) + (orchestration_input_tokens − orchestration_input_cached_tokens)

计费缓存输入 = cached_tokens + orchestration_input_cached_tokens

计费输出 = output_tokens + orchestration_output_tokens

估算 = 未缓存输入/1M × 输入费率 + 计费缓存输入/1M × 缓存费率 + 计费输出/1M × 输出费率

定价前先校验:每个缓存数必须小于或等于其归属的输入总量,普通输入总量必须包含其缓存子集。缓存数大于输入总量时应直接报错,而不是照常计算。把缓存 token 当成全价输入计费,或在已包含缓存的输入总量上再加一次缓存,是这套估算出现翻倍偏差最常见的原因。

编排总量仍是额外的:它们加在普通请求计数之上,而不是折进去。不同模型或 provider 可能返回不同的 envelope,不要用这个公式解析未经校验的 usage 对象。

2026 年 9 月 28 日 Ultra 标准费率仍是每百万 $5 / $0.50 / $30;上下文超过 272K 则为 $10 / $1.00 / $45。只有该次请求的上下文跨过阈值,才用高档。

3. 与计算器相同的工作示例

假设一个月的 Ultra 请求每次上下文都在标准档内,汇总后的原始总量为:用户输入 1,000,000(其中缓存 250,000),编排输入 2,000,000(其中缓存 500,000),最终输出 250,000,编排输出 500,000。每个缓存数都是其所归属输入总量的子集;这是很多次短请求的汇总,不是一次 1M 单请求,因此不会触发长上下文档。

未缓存输入 = (1,000,000 − 250,000) + (2,000,000 − 500,000) = 2,250,000 = $11.25;计费缓存输入 = 250,000 + 500,000 = 750,000 = $0.375;计费输出 = 250,000 + 500,000 = 750,000 = $22.50;合计 $34.125,显示为 $34.13。若忽略编排,你会记下 $11.375 再和财务争论。Ultra 与 Max 计算器就是把字段标清楚、并先减去缓存子集的这段算术。它仍然不能给标准 Fugu 或 Cyber 定价。

4. 避免第二次争论的运维规则

  • 原始 usage 对象、算出的金额、所用费率版本要一起保存。
  • 不要假设 total_tokens 按一个混合单价计费。
  • 应用输入费率前,先从各自的输入总量里减去缓存数,并保存你使用的未缓存数值。
  • 缓存数大于其输入总量的 usage 对象应直接拒绝,不要悄悄截断。
  • 不要把 Ultra 的 max_output_tokens 当成花费上限。
  • 272K 上下的流量要拆成两次计算。
  • 合作方若不返回这些字段,就不能在没有新证据时套用此公式。

即使算出的美元金额看起来整齐,也要留下原始 JSON。以后定价页再变,或发现漏加了编排缓存,从字段修比重画一张合计截图便宜。标准 Fugu 没有这张公开固定表,Cyber 的公开表也已撤回,所以不要把这段公式套到那两款模型上。

把 usage 和请求 ID、模型 ID、当时使用的费率版本放在同一条日志里。下一次对账时,你要回答的不是“大概花了多少”,而是“哪一次 Ultra 请求因为编排输出把费用抬上去了”。计算器只是同一套算术的界面,不能替代保存原始对象。完整方法论见 价格说明。没有原始对象就无法复盘。

本页不覆盖什么

这里不给标准 Fugu 编混合单价,也不恢复已撤回的 Cyber 公开表。公式只适用于官方仍公布固定费率、且返回编排字段的 Ultra 请求。合作方发票如果字段不同,需要另做证据,不能直接套用。

来源