AI API 月度成本复盘不是看一眼总账单有没有超预算，而是把账单拆回到功能、模型、Token、重试、缓存和 Agent 工具调用这些可行动的变量。只有找到“为什么变贵”，下个月的预算、路由和告警才有调整依据。
如果你已经建立了 AI 成本治理 Playbook、AI API 成本预算表 和 AI API 成本告警，月度复盘就是把这些机制闭环起来：预算负责预测，告警负责发现异常，复盘负责修正假设。
月度复盘要回答的 5 个问题
一次有效的 AI API 成本复盘，至少要回答五个问题：
- 本月真实成本和预算差多少？
- 偏差来自流量增长、输出变长、模型升级、重试、缓存失效，还是 Agent 多轮调用？
- 哪些功能的单次成功成本最高？
- 哪些成本增长是业务需要，哪些是浪费？
- 下个月要改预算、路由、上限、告警还是产品交互？
不要只写“本月成本上涨 20%”。这个结论没有用。你需要把上涨拆成可修改的原因。
先准备这些数据字段
复盘前，先确认日志或账单导出里能拿到这些字段。没有全部字段也可以开始，但缺失字段要记录为治理改进项。
| 字段 | 用途 | 如果缺失会怎样 |
|---|---|---|
| feature | 按功能归因成本 | 只能看到总账单，无法找到 owner |
| model | 对比模型路由成本 | 不知道是否高价模型使用过多 |
| input_tokens | 判断上下文是否膨胀 | 无法解释输入成本增长 |
| output_tokens | 判断回答是否过长 | 无法定位输出成本主因 |
| retry_count | 识别失败成本 | 会把失败重试当成正常流量 |
| cache_hit_tokens | 评估缓存命中率 | 无法确认 prompt caching 是否有效 |
| tool_call_count | 识别 Agent 放大成本 | 看不到多轮工具循环 |
| status | 区分成功、失败、fallback | 无法计算单次成功成本 |
| estimated_cost | 做请求级排序 | 只能看供应商汇总账单 |
如果你还没有请求级日志，先参考 如何核对 AI API 账单和模型价格 做最小账单核对，再逐步补字段。
第一步：总账单只做入口，不做结论
总账单适合回答“有没有异常”，不适合回答“为什么异常”。建议先做一张总览表：
| 指标 | 本月 | 上月 | 变化 | 是否需要拆解 |
|---|---|---|---|---|
| 总成本 | - | - | - | 是 |
| 总请求量 | - | - | - | 是 |
| 平均单次请求成本 | - | - | - | 是 |
| 成功任务成本 | - | - | - | 是 |
| 失败/重试成本占比 | - | - | - | 是 |
| Agent 任务成本占比 | - | - | - | 是 |
这里不要急着下判断。比如总成本上涨，可能是用户增长，也可能是一次 prompt 改动让输出翻倍。只有拆到功能和请求级别，才能知道该优化哪里。
第二步：按功能拆成本
功能级复盘比模型级复盘更重要。业务团队关心的是“客服问答、文档总结、代码审查、Agent 自动化分别花了多少”，而不是单纯“Claude 花了多少、OpenAI 花了多少”。
建议复盘表这样设计：
| 功能 | 成本占比 | 请求占比 | 单次成功成本 | 环比变化 | 初步判断 |
|---|---|---|---|---|---|
| support_answer | - | - | - | - | 看输出长度 |
| rag_faq | - | - | - | - | 看检索 chunk |
| code_review | - | - | - | - | 看模型路由 |
| batch_classify | - | - | - | - | 看批处理和重跑 |
| agent_workflow | - | - | - | - | 看工具调用轮数 |
如果某个功能的成本占比远高于请求占比，优先排查这个功能。它可能输入长、输出长、重试多、模型贵，或者一次用户操作背后触发多次调用。
第三步：拆 Token，而不是只看请求量
AI API 成本经常不是请求量涨了，而是每次请求变重了。
重点看四组指标：
| 指标 | 说明 | 常见原因 |
|---|---|---|
| 平均输入 token | 每次请求带入多少上下文 | 历史消息变长、RAG chunk 增多、工具 schema 变大 |
| P95 输入 token | 高成本请求的输入上限 | 少数长文档或异常用户拉高成本 |
| 平均输出 token | 模型平均生成长度 | prompt 要求变成长报告、JSON 太冗余 |
| P95 输出 token | 长输出尾部风险 | 失败重试、无限续写、报告模板过长 |
如果平均值正常但 P95 很高，说明不是全局问题，而是少数请求失控。此时不要盲目降模型，先加输入截断、输出上限或高成本请求告警。
第四步：检查重试和失败成本
重试成本很容易被隐藏，因为账单只看调用，不管调用是否成功。
复盘时至少统计：
重试成本占比 = 重试请求成本 / 总成本
失败成本占比 = 失败请求成本 / 总成本
成功任务成本 = 总成本 / 成功任务数如果成功任务成本上涨，但请求量没有明显增长，常见原因是：
- JSON 输出格式不稳定，导致自动重试；
- 工具参数错误，Agent 重复调用；
- 上游 timeout 后重跑整批任务；
- fallback 到更贵模型比例升高；
- 用户前端重复点击触发多次生成。
这类问题不应该只靠“换便宜模型”解决。更有效的是修错误处理、限制重试、做幂等键，并把失败类型写进复盘表。
第五步：复盘缓存命中率
提示词缓存、上下文缓存或供应商缓存机制只有在真实命中时才省钱。月度复盘要把缓存假设和实际命中率对齐。
| 缓存指标 | 要看什么 |
|---|---|
| cache_hit_rate | 本月真实命中率是否接近预算假设 |
| cacheable_tokens | 哪些 token 理论上可缓存 |
| dynamic_prefix_rate | 固定前缀里是否混入动态字段 |
| cache_savings_estimate | 实际节省是否足以支撑实现复杂度 |
如果缓存命中率低，不要只怪模型供应商。先检查 system prompt、工具说明、日期、用户 ID、随机排序的上下文是否破坏了稳定前缀。可以结合 Prompt Caching 预算检查清单 调整。
第六步：单独复盘 Agent 和批处理
Agent 和批处理不能和普通聊天混在一起复盘。它们的成本结构不同。
Agent 复盘字段
| 字段 | 为什么要看 |
|---|---|
| steps_per_task | 一次任务用了多少模型轮次 |
| tool_calls_per_task | 工具调用是否过多 |
| repeated_tool_calls | 是否出现循环或重复读取 |
| human_confirmation_rate | 高风险动作是否有人工确认 |
| cost_per_successful_task | 比单次请求成本更真实 |
如果 Agent 成本变高，优先看停止条件和工具调用上限。更多规划方法可以参考 Agent 工具调用成本规划。
批处理复盘字段
| 字段 | 为什么要看 |
|---|---|
| batch_size | 批量大小是否导致超长上下文 |
| rerun_count | 是否因为少量失败重跑整批 |
| idempotency_key | 是否能避免重复处理 |
| low_value_model_ratio | 低价值任务是否用了高价模型 |
批处理成本失控时，通常不是单次调用太贵，而是失败重跑和并发放大。
第七步：把复盘结论转成下月动作
复盘报告不要只写现象，要写动作。建议每条结论都落到一个治理项：
| 发现 | 下月动作 | Owner |
|---|---|---|
| RAG 输入 P95 过高 | 限制 top_k 和单 chunk 长度 | 产品/工程 |
| 输出 token 占比升高 | 为报告类功能设置默认短版 | 产品 |
| 重试率超过 10% | 修 JSON schema 和错误分类 | 工程 |
| Agent 工具调用过多 | 设置 max_steps 和重复工具告警 | 工程 |
| 缓存命中率低于预算 | 稳定 system prompt 前缀 | 工程 |
| 某功能持续亏损 | 调整额度、定价或关闭免费入口 | 业务 |
如果动作没有 owner 和验证方式，下个月复盘还会看到同样的问题。
月度 AI 成本复盘模板
可以复制下面的模板：
AI API 月度成本复盘
1. 总览
- 本月总成本：
- 相比预算：
- 相比上月：
- 是否触发告警：
2. 功能拆解
- 成本最高功能：
- 增长最快功能：
- 单次成功成本最高功能：
3. 成本驱动因素
- 请求量变化：
- 输入 token 变化：
- 输出 token 变化：
- 重试/失败成本：
- 缓存命中率：
- Agent / 批处理成本：
4. 结论
- 合理增长：
- 浪费或异常：
- 数据缺口：
5. 下月动作
- 预算调整：
- 路由调整：
- 上限/告警调整：
- 产品或交互调整：
- Owner 和验证方式：常见错误
只按供应商看账单
供应商维度适合财务对账，但不适合产品治理。你需要知道哪个功能在花钱，而不是只知道哪个模型厂商收费。
把用户增长和成本浪费混在一起
成本上涨不一定是坏事。如果成功任务增长更快、单次成功成本下降，说明效率可能更好。复盘要看单位经济，而不是只看总额。
忽略失败请求
失败请求也会计费。任何复盘都应该把失败、重试和 fallback 单独列出来。
复盘后不更新预算表
预算表不是一次性文档。每次月度复盘后，都应该更新请求量、token、重试率、缓存命中率和峰值系数假设。
FAQ
AI API 成本复盘多久做一次？
线上产品建议每月做一次完整复盘，每周做一次轻量检查。刚上线或成本波动大的功能，可以按周复盘。
没有请求级日志还能复盘吗？
可以先从供应商账单、功能调用量和应用日志开始，但要把“缺少请求级 estimated_cost”列为治理改进项。没有请求级日志，很多成本原因只能猜。
成本超预算时第一步是降模型吗？
不一定。先判断原因。如果是重试、长输出、RAG chunk 或 Agent 循环导致，降模型可能只会降低质量，不能解决根因。
总结
AI API 月度成本复盘的目标不是责备某个模型太贵，而是把账单数字翻译成可执行的工程和产品动作。按功能拆成本，按 token、重试、缓存和 Agent 调用找原因，再把结论更新到预算、告警和上线评审里，AI 成本治理才会越做越稳。