AI API 成本预测不是把上个月账单复制一遍，而是在功能上线或流量增长前，提前估算下个月可能花多少钱。它要考虑用户量、请求次数、输入输出 token、模型路由、重试、缓存、评测流量、Agent 工具调用和批处理任务。
如果你已经有 AI API 成本预算表 和 AI API 月度成本复盘，这篇文章就是中间层：预算表定义模型，复盘修正假设，预测用这些假设提前看风险。
成本预测和账单复盘有什么不同
账单复盘解释已经发生的事，成本预测判断接下来可能发生什么。
| 问题 | 账单复盘 | 成本预测 |
|---|---|---|
| 时间范围 | 上周或上月 | 下周或下月 |
| 主要输入 | 实际账单和日志 | 用量假设和增长场景 |
| 输出结果 | 偏差原因和根因 | 预算区间和风险触发点 |
| 适合用途 | 解释异常 | 提前防止异常 |
两者都需要。复盘让预测更准，预测让团队不必等账单出来才发现问题。
预测前需要哪些输入
先准备一组能解释大部分 AI API 成本的字段。
| 输入 | 要估什么 | 为什么重要 |
|---|---|---|
| feature | 客服、RAG、总结、Agent 自动化 | 按产品价值预测，而不是只按供应商 |
| active_users | 预计活跃用户或账号数 | 决定请求量基础 |
| requests_per_user | 每个用户平均调用次数 | 把用户数转成流量 |
| model_mix | 哪些任务用哪些模型 | 影响单次成本和质量 |
| avg_input_tokens | prompt、历史、检索内容、工具 schema | 输入成本经常被低估 |
| avg_output_tokens | 回答、报告、JSON、代码 | 输出可能成为主要成本 |
| retry_rate | 失败或重复调用比例 | 把可见请求放大成计费请求 |
| cache_hit_rate | 稳定上下文命中率 | 只有真实命中才会省钱 |
| eval_traffic | 离线评测和回归测试 | 上线后常被漏算 |
| batch_jobs | 后台批处理任务 | 不依赖用户访问也会花钱 |
| agent_steps | 每个成功任务的模型轮数 | 一个用户任务可能包含多次调用 |
价格字段必须来自官方价格页、站内价格表或用户确认数据。不要用记忆里的旧价格。可以先用 文本模型计算器 估典型请求，再到 价格页 核对模型。
核心公式：从功能预测成本
一个最小可用公式是：
预测成本 = 请求量 × 单次成功任务成本 × 场景系数 + 隐藏工作负载成本其中：
请求量 = 活跃用户 × 人均请求数
单次成功任务成本 = 包含重试、fallback、工具调用后的平均成本
隐藏工作负载成本 = 评测 + 批处理 + 后台 Agent + 日志重放这里故意按功能预测，而不是按模型供应商预测。因为产品团队真正要决定的是：哪个功能要限额、哪个功能要降级、哪个功能值得继续投入。
建三种场景：基准、增长、压力
不要只给一个数字。预测应该是一组区间。
| 场景 | 适用情况 | 假设方式 |
|---|---|---|
| 基准场景 | 正常月度规划 | 当前流量、当前 token、当前重试率 |
| 增长场景 | 发布、营销、功能扩容 | 请求量上升，部分功能使用变多 |
| 压力场景 | 风险预案 | P95 token、更高重试、更低缓存命中、更高 fallback |
可以用这样的表：
| 功能 | 基准 | 增长 | 压力 | 重点观察 |
|---|---|---|---|---|
| 客服问答 | - | - | - | 输出长度和重试 |
| RAG FAQ | - | - | - | 检索 chunk 和历史轮数 |
| 文档总结 | - | - | - | 输入 token 和批处理 |
| Agent 自动化 | - | - | - | 步数和工具循环 |
| 离线评测 | - | - | - | 样本数和每样本调用次数 |
压力场景不是预测一定会发生，而是告诉你：如果多个假设同时失效，账单会到哪里。
按功能预测，不要只按供应商预测
供应商维度适合财务对账，但不适合产品决策。
| 弱预测 | 更好的预测 |
|---|---|
| “Claude 预算 500 美元” | “代码审查功能：200 个成功任务 × 单次成功任务成本 × 安全系数” |
| “OpenAI 预算 300 美元” | “客服机器人：会话数 × 平均轮次 × 平均 token × 重试系数” |
| “Gemini 预算 200 美元” | “文档总结：文件数 × 平均长度 × 批处理重跑风险” |
按功能预测之后，团队才能知道该怎么改：缩短输出、限制 RAG chunk、调整免费额度、把低风险任务切到低成本模型，还是推迟高成本功能。
这也和 AI 成本治理 Playbook 一致：每笔成本都应该能归因到功能、owner 和预期价值。
加上隐藏放大项
很多 AI API 预测偏低，是因为只算了用户可见请求。
重试和失败
如果 10% 请求会重试一次，计费请求就不是用户看到的请求数。
要单独估：
- JSON 或 schema 重试率；
- timeout 重试率；
- fallback 到更贵模型的比例；
- 前端重复提交或重新生成比例。
评测和回归测试
上线后，团队通常会增加测试集、prompt 对比和回归检查。
公式：
评测成本 = 样本数 × 每样本调用次数 × 每周期运行次数 × 平均单次成本Agent 循环
Agent 工作流要按“成功任务”预测，而不是按一次模型请求预测。
要估：
- 每任务平均步骤数；
- 每任务工具调用数；
- 重复工具调用数；
- 失败恢复调用；
- 最终总结调用。
如果 Agent 是主要成本来源，可以结合 Agent 工具调用成本规划 单独拆表。
批处理任务
批处理成本不一定跟用户量同步。常见来源包括夜间总结、内容处理、数据补全、日志重放和离线分类。
批处理最好单独列，不要藏在前台用户请求里。
每周对比预测和实际值
预测不是写完就归档。每周至少对比这些假设：
| 预测假设 | 实际指标 | 偏离后怎么处理 |
|---|---|---|
| 请求量 | request_count | 更新增长场景 |
| 平均输入 token | avg / P95 input_tokens | 增加截断或 chunk 限制 |
| 平均输出 token | avg / P95 output_tokens | 设置更短默认输出 |
| 重试率 | retry_count > 0 占比 | 修错误处理或 schema |
| 缓存命中率 | cache_hit_tokens / cacheable_tokens | 稳定 prompt 前缀 |
| Agent 步数 | steps_per_successful_task | 增加最大步数和循环检测 |
| 评测流量 | eval_calls_per_week | 单独设评测预算 |
如果实际值和预测不一致，不要只改最终金额，要改那个失效的假设。
AI API 成本预测模板
可以复制下面这份模板：
AI API 成本预测
功能：
Owner：
预测周期：
1. 用量假设
- 活跃用户：
- 人均请求数：
- 周期请求量：
- 预期增长：
2. Token 假设
- 平均输入 token：
- P95 输入 token：
- 平均输出 token：
- P95 输出 token：
- 缓存命中率：
3. 工作流假设
- 模型路由：
- 重试率：
- fallback 比例：
- 每任务 Agent 步数：
- 批处理任务：
- 评测调用：
4. 场景
- 基准：
- 增长：
- 压力：
5. 控制措施
- 预算阈值：
- 告警阈值：
- 降级动作：
- Owner：
- 复盘日期：模板不用复杂，关键是让假设可见、可更新、可追责。
常见错误
只按平均请求预测
平均值会掩盖 P95 / P99 请求。长文档、长回答和 Agent 循环通常都在尾部。
过早假设缓存收益
没有日志证明前，不要把高缓存命中率写进默认预算。先做无缓存或低缓存场景。
混在一起算用户请求和后台任务
用户请求、评测、批处理应该分行。否则后台任务增长会被误判成产品增长。
只按供应商做预算
供应商总额不能告诉产品团队该改哪里。先按功能预测，再汇总到供应商维度。
FAQ
AI API 成本预测多久更新一次？
上线期或增长期建议每周更新；稳定后可以每月更新。任何 prompt、模型、路由或功能变化，都应该触发一次预测更新。
预测要不要用最新模型价格？
要，但只能使用官方价格页、内部价格表或维护过的计算器数据。不要用旧笔记或记忆里的价格。
成本预算表和成本预测有什么区别？
预算表定义计算模型；成本预测把模型应用到未来周期，并加入流量、token、重试、缓存和增长假设。
预测错了怎么办？
预测错很正常。重点不是完美预测，而是找出哪个变量变了：请求量、token、重试、缓存、Agent 步数还是批处理。下次更新这个假设即可。
总结
AI API 成本预测是一种习惯，不是一张一次性表格。按功能预测，建立基准、增长和压力场景，加入隐藏工作负载，每周对比实际值并更新假设，团队才能从“被账单吓到”变成“提前规划账单”。