API 成本透明化：为什么你的 AI 账单总比预算高 3 倍

一个普遍的困惑

很多团队的 AI 预算是这样定的：估算日均调用量 × 单次成本 × 30 天。月底一对比，实际支出往往是预算的 2–3 倍。

问题通常不在估算公式，而在于你看不到的成本来源。成本失控，本质是可观测性缺失。

成本黑洞的四个来源

来源一：重试与失败重跑

一次调用失败重试三次，成本就是三倍。而失败可能来自超时、格式校验不通过、限流——这些在账单上和正常调用长得一模一样。

如果统计里不区分成功与失败，你会以为成本就是”正常用量”，实际上有相当比例花在了失败上。

来源二：上下文重复传输

多轮对话中，每一轮都要把此前所有历史重新发一遍。一个 20 轮的对话，最早的几条内容被传了 20 次。

长对话的成本是超线性增长的，但按”对话数”估算时完全看不出来。

来源三：隐藏的后台调用

一次用户操作，背后可能是：主模型调用 + 检索 + 重排序 + 模型裁判评分 + 摘要生成。用户看到”一次点击”，账单上是五次调用。

Agent 和 RAG 场景的成本，通常远高于团队的心理预期。

来源四：缓存缺失

固定的系统提示、长时间不变的知识文档，如果每次都重传，等于重复付费。支持缓存的接口没用上，是纯浪费。

可观测性：先看得见，才谈得上优化

要控成本，第一步是把成本拆到可归因的粒度。至少记录：

• 任务类型：这次调用是干什么的（分类 / 生成 / 检索 / 评分）
• 模型与版本：走的哪个模型
• Token 用量：输入、输出、缓存命中分别多少
• 状态：成功 / 失败 / 重试第几次
• 触发来源：哪个功能、哪个用户、哪个租户

有了这几项，你才能回答关键问题：哪个功能最烧钱？失败率多高？谁在用？

成本归因的三种视角

按功能看

把成本摊到功能上，会发现通常只有两三个功能吃掉了大部分成本。优化这几个，杠杆最大。

按租户看

多租户产品必须算单租户毛利。否则会出现”整体在赚，个别客户在巨亏”的情况。

按成功任务看

这是最关键的指标：单位成功任务成本 = 总成本 / 成功完成的任务数。

它把重试、失败、后处理的成本全部纳入，比”每百万 Token 单价”真实得多。

四个控成本的具体动作

动作一：设置预算与熔断 给每个功能、每个租户设月度预算。超阈值自动降级（换便宜模型）或告警，避免月底才发现。

动作二：把失败成本单独统计 失败重试要单独打标。这类成本的优化空间往往最大——先修失败率，比砍模型单价更有效。

动作三：用上下文缓存 固定部分走缓存，能显著降低长对话和 RAG 场景的成本。

动作四：做模型路由 简单任务走小模型，困难任务才上旗舰模型。详见成本优化专题。

一个反面提醒：别只看钱

过度压缩成本会反噬：

• 用太弱的模型 → 输出质量下降 → 返工成本更高
• 砍掉评测和监控 → 静默退化 → 用户流失
• 设置过紧的限流 → 体验受损

成本优化的目标是”单位价值成本最低”，不是”总支出最低”。

小结

AI 账单超预期，根因通常是四个看不见的黑洞：重试、上下文重复、后台调用、缓存缺失。

解法分两步：先建立可观测性（按任务、模型、状态、来源打标），再做归因与预算控制（按功能、租户、成功任务看成本）。

一句话：你看不见的成本，就控制不住；而看得见之后，能省的钱往往超出预期。