AI API 成本追踪：Token 与模型分组

AI API 成本追踪最有价值的状态，是每一笔费用都能对应到一条请求、一个模型、一个模型分组和一组真实计量数据。月度总额可以说明费用发生了变化，单请求记录才能解释为什么变化。

Modelflare 把模型价格、真实用量、分组策略和请求日志关联起来，避免用户只根据屏幕上看到的文字估算成本。

一条请求费用的四个层次

1. 模型价格

每个模型都有自己的计价基础。很多文本模型区分输入和输出 Token，图片、音频、Rerank 等 API 则可能使用不同计量单位。无法用一组固定 Token 单价表达的能力，还可能使用版本化的复杂计价规则。

应用不应把价格复制进代码，应以模型与价格中的实时模型和 API 格式为准。

2. 请求的真实用量

网关记录已完成请求返回或推导出的 Usage。对于按 Token 计价的文本模型，输入和输出会分别保留，因为两者单价可能不同。

终端里可见的流式文字并不是可靠的费用 Oracle。工具项、推理、缓存输入、标准化 Token 或供应商私有 Usage，都可能影响结算，却不会全部表现为普通 Assistant 文本。

3. 模型分组倍率

最终选中的路由分组可以在基础用量费用上应用销售倍率。例如分组 Ratio 为 0.9，意味着该请求按基础模型费用的 90% 计算。

这个倍率只属于请求用量计费，不会改变充值时实际增加的余额。

4. 最终请求记录

用量日志把结算结果与模型、分组、状态、Token、时序及其他安全运维元数据关联起来。失败或取消请求可能走不同结算路径，因此持久化后的结果比客户端估算更权威。

在用量日志中比较什么

费用变化时，可以沿这些维度对比：

• 模型： 是否切换到输入、输出或特性价格不同的模型；
• 分组： 主分组或回退分组是否使用不同倍率；
• 协议： Chat Completions 与 Responses 的 Usage 结构是否不同；
• 输入规模： 提示词、检索上下文、文件或工具结果是否变大；
• 输出规模： Completion 限制或 Agent 循环是否产生更多输出；
• 状态与重试： 失败是否带来额外的已完成尝试；
• 时序： 更长的生成时间是否真的对应更多输出，而不只是排队。

最好通过固定 Request ID 或专用 API Key 隔离工作负载，不要把账户里互不相关的请求混在一起比较。

建立实际成本边界

按工作负载拆分 API Key

生产、开发、自动化和个人工具分别使用不同 Key。每个 Key 可以有独立名称、有效期、分组策略，以及有限或无限 Quota。

有意识地选择分组

不要只根据分组名称选择。应同时检查实时模型能力、分组倍率、访问条件、RPM 和回退策略。一个价格更低、回退明确的主分组，往往比难以解释的隐式路由更可控。

先控制输入，再控制输出

大段 System Prompt、重复对话历史、检索文档和工具结果经常占据主要输入用量。删除已经不影响答案的上下文，并避免在客户端可以安全引用或缓存时反复发送不变数据。

检查 Agent 循环

一次用户操作可能产生多条模型请求。成本分析要分别追踪每轮工具调用与重试，不能把最终看到的一段回答当成唯一一次 API 调用。

为什么客户端估算会漂移

本地 Tokenizer 或字符数可以用于规划，但可能与最终费用不同，因为：

• 供应商的标准化和计数方式可能不同；
• 缓存、推理、图片、音频或工具单位可能采用独立价格；
• 网关按真实选中的模型与分组结算；
• 失败请求和退款取决于实际请求生命周期；
• 价格可以变化，但历史请求保留自己的记录结果。

财务核对应该综合持久化用量和钱包记录，而不是只根据一个展示字段反推账户余额。

一套可重复的检查流程

1. 把用量日志过滤到一个 API Key 和时间范围；
2. 按模型和最终分组归类请求；
3. 比较每条请求的输入、输出、状态和费用；
4. 检查异常值是否来自重试、长上下文、工具循环或回退；
5. 修改路由前确认实时价格与分组策略；
6. 工作负载需要硬性边界时，为 Key 设置有限 Quota；
7. 修改后用相同指标重新检查。

成本控制的起点是归因。只要模型、分组、用量和请求结果仍然保持关联，团队就能优化真正的费用来源，而不是根据汇总数字猜测。