AI API 预算经常不是公式算错，而是假设漏了。团队预测了用户可见请求，却忘了输出 token 增长、重试、fallback、评测流量、批处理任务、Agent 多轮调用和缓存命中率不稳定，最后账单自然高于预算。
如果你已经做了 AI API 成本预测 或 AI API 成本预算表，这篇可以作为上线前的诊断清单，专门检查哪些地方最容易低估。
成本预测错误通常是假设错误
预测不是为了给出一个看起来精确的数字，而是为了暴露假设。
| 预测输入 | 常见错误 | 后果 |
|---|---|---|
| 请求量 | 只用上线第一周流量 | 第二个月成本突然变高 |
| token 大小 | 只看平均 token | 长尾请求拉高账单 |
| 缓存命中率 | 没有日志就假设会省钱 | 预算过低 |
| 重试率 | 忽略失败调用 | 计费调用多于可见任务 |
| Agent 步数 | 把一个任务当一次模型请求 | 单次成功任务成本被低估 |
| 评测流量 | 忘记离线测试 | 工程流量变成意外成本 |
| 批处理 | 藏在用户流量里 | 产品增长和自动化成本混在一起 |
好的预测不是永远准确，而是能让团队知道哪个假设变了。
错误一：只看平均请求成本
平均请求成本会掩盖高成本尾部。
一个客服机器人平均看起来很便宜，但少数请求可能带有很长历史、RAG 检索内容、工具 schema 或长回答。平均值看不出 P95 / P99 请求贡献了多少成本。
至少要看：
| 指标 | 为什么重要 |
|---|---|
| 平均输入 token | 基准上下文大小 |
| P95 输入 token | 长 prompt、RAG chunk、工具 schema |
| 平均输出 token | 正常回答长度 |
| P95 输出 token | 长报告、冗长 JSON、重复回答 |
| 单次成功任务成本 | 比单次调用成本更有意义 |
如果 P95 成本远高于平均成本，优先做输入截断、输出上限、chunk 控制和高成本告警，不要一开始就只想着换便宜模型。
错误二：忽略输出 token 增长
很多团队认真估输入 token，却低估输出 token。Prompt 一变，输出长度就可能悄悄上涨。
常见原因：
- 短答 prompt 变成“详细报告”；
- JSON 输出字段越来越多；
- 摘要开始包含长引用；
- 要求模型解释更多步骤；
- 用户频繁点重新生成或展开。
预测时给输出长度做三种场景：
| 场景 | 输出假设 |
|---|---|
| 基准 | 当前平均输出长度 |
| 增长 | 上线后回答变长 25%-50% |
| 压力 | P95 输出长度或最大允许长度 |
每周把实际输出 token 和预测对比。
错误三：过早假设缓存收益
Prompt caching 确实可能省钱，但只有真实命中才有意义。
不要因为系统“支持缓存”，就直接写一个乐观命中率。先检查 prompt 前缀是否稳定：时间戳、用户 ID、随机排序的上下文、动态工具说明、每次变化的策略文本，都会破坏缓存。
建议三种缓存场景：
| 缓存场景 | 适用情况 |
|---|---|
| 0% 命中 | 上线前保守预测 |
| 低命中 | 早期生产环境，日志还不稳定 |
| 已验证命中 | 只有真实日志证明后才使用 |
更多预算假设可以接 Prompt Caching 预算检查清单。
错误四：漏算重试和 fallback
用户看到一个成功任务，背后可能有多次计费调用。
一次成功任务可能包括：
- 首次模型调用；
- schema 修正重试；
- timeout 重试；
- fallback 到更贵模型；
- 最终格式化调用；
- 日志或评测调用。
预测时至少写：
计费调用 = 可见任务 × (1 + 重试率 + fallback 比例)这个公式不完美，但比假设每个任务一次成功更接近真实成本。
错误五：把评测和批处理混进用户流量
评测和批处理应该单独预算。
| 工作负载 | 为什么要分开 |
|---|---|
| Prompt eval | 质量优化时会增加 |
| 回归测试 | 没有用户增长也会跑 |
| 夜间总结 | 跟数据量有关，不跟会话数完全同步 |
| 内容分类 | 规则变化后可能重跑 |
| 日志重放 | 排查问题时可能突然增加 |
如果这些都混进用户流量，团队会误以为产品需求增长，实际可能是后台自动化变贵。
错误六：把 Agent 当成一次请求预测
Agent 工作流要按“成功任务”预测，而不是按一次模型请求预测。
要看：
| Agent 指标 | 为什么重要 |
|---|---|
| 每任务步骤数 | 模型轮数会放大成本 |
| 每任务工具调用数 | 工具观察会带来更多模型调用 |
| 重复工具调用 | 暴露循环和浪费 |
| 失败恢复调用 | 隐藏成本来源 |
| 人工确认比例 | 高风险任务是否该停下来 |
公式可以写成：
Agent 任务成本 = 平均步骤成本 × 每成功任务步骤数 + 工具相关模型调用 + 重试成本如果 Agent 是主要成本来源，建议单独看 Agent 工具调用成本规划。
错误七：不每周对比预测和实际值
不对账的预测只是猜测。
每周至少对比：
| 假设 | 实际指标 | 动作 |
|---|---|---|
| 请求量 | request_count | 更新流量场景 |
| 平均输入 token | avg_input_tokens | 更新上下文假设 |
| P95 输入 token | p95_input_tokens | 增加输入控制 |
| 输出长度 | avg / P95 output_tokens | 调整回答格式 |
| 重试率 | retry_count 占比 | 修错误处理或 schema |
| 缓存命中率 | cache_hit_tokens 占比 | 稳定缓存前缀 |
| Agent 步数 | steps_per_task | 加最大步数和循环检测 |
| 评测调用 | eval_calls | 单独设评测预算 |
不要只改最终预算金额，要改那个失效的假设。
预测复查清单
批准预测前，逐项问：
- 是否包含 P95 token 场景？
- 是否分开输入和输出 token？
- 是否包含重试和 fallback？
- 是否把评测流量单独列出？
- 是否把批处理任务单独列出？
- 是否按成功任务预测 Agent？
- 缓存收益是否来自真实日志？
- 每个功能是否有 owner？
- 是否有预算耗尽前的告警阈值？
- 是否每周做实际值对比？
如果多数答案是否定的，预测大概率偏乐观。
FAQ
AI API 成本预测要加多少安全系数？
不要只加一个固定比例。更好的做法是建立基准、增长和压力三种场景。压力场景应该包含长尾 token、低缓存命中、高重试和 Agent 循环。
应该按供应商预测还是按功能预测？
先按功能预测。供应商总额适合财务，但产品团队需要知道哪个功能在花钱。
没有 token 日志怎么办？
先用典型请求样本测算，并给 P95 留保守估计。同时把 token 日志列为上线前必须补齐的监控项。
每月复盘够吗？
稳定产品可以每月复盘。新功能、模型切换、Agent 工作流和发布活动期间，建议每周对比预测和实际值。
总结
AI API 用量预测最容易低估的，不是模型价格，而是隐藏用量：长尾 token、输出增长、缓存不确定、重试、fallback、评测、批处理和 Agent 步数。把这些拆开，每周对比实际值，预测即使不完美，也足够帮助团队提前避开大额账单。