AI API 成本预算表：从单次调用到月度预测

AI API 成本预算表不是把模型单价复制到 Excel 里，而是把一次调用拆成可验证的变量：输入 token、输出 token、请求量、缓存命中率、失败重试、评测调用和峰值流量。只有这些字段齐了，单次调用成本才能可靠地换算成月度预算。

如果你已经读过如何规划每月 AI API 预算或 Token Cost Calculator：上线前估算 AI API 预算，这篇文章的重点会更进一步：把预算字段变成一张可以持续更新、可以和真实日志核对的表。

先明确：预算表要回答什么问题

一张好的 AI API 成本预算表，至少要回答四个问题：

单次成功任务大概要花多少钱？
每日请求量变成 3 倍、5 倍后，月度账单会到哪里？
哪些成本来自正常用户请求，哪些来自重试、评测、后台任务或 Agent 多轮调用？
上线后真实账单偏离预算时，能不能快速找到是哪一个字段错了？

如果预算表只能得到一个“本月预计 $X”的数字，它还不够。真正有用的是能解释这个数字从哪里来，以及哪些假设最容易失效。

成本预算表必须包含的字段

建议把预算表按“价格字段、用量字段、风险字段、复核字段”四组设计。

字段组	字段	为什么重要
价格字段	模型、输入单价、输出单价、缓存读取价、批处理价	不同计费项价格不同，不能只填一个总单价
用量字段	日请求量、平均输入 token、平均输出 token、月活跃天数	决定正常流量下的基础预算
风险字段	重试率、失败率、峰值系数、评测/日志调用量	解释为什么真实账单高于理想预算
复核字段	feature、user_tier、model、retry_count、estimated_cost	方便上线后和真实日志逐项对齐

价格字段要来自官方价格页、站内价格表或用户确认数据。不要在预算表里手填一个“印象价格”，否则后面所有计算都会失真。可以先在价格表中确认模型，再用文本模型计算器跑典型请求。

基础公式：从一次调用到月度预算

最小公式可以这样写：

单次请求成本 = 输入成本 + 输出成本 + 缓存相关成本
月度基础成本 = 单次请求成本 × 日请求量 × 30

其中：

输入成本 = 未缓存输入 token × 输入单价
缓存成本 = 缓存命中 token × 缓存读取单价
输出成本 = 输出 token × 输出单价

如果你暂时没有缓存，可以把缓存命中 token 填 0。不要把所有 token 混成一个“总 token”，因为输入、输出、缓存读取通常不是同一个价格维度。

加入缓存命中率

缓存命中率会明显影响长系统提示词、固定工具说明和重复上下文的成本，但不能写得过度乐观。

建议预算表至少保留三列：

缓存假设	用途
0% 命中	保守预算，适合上线前压力测试
50% 命中	中性预算，适合有部分固定 prompt 的产品
80% 命中	乐观预算，只适合已经用日志验证过的稳定前缀

如果实际命中率低于预算，常见原因是 prompt 中混入动态时间、用户 ID、随机排序的上下文或每次变化的工具描述。缓存假设可以参考提示词缓存能省多少？和缓存命中率成本规划进一步校准。

加入重试、失败和评测流量

很多 AI API 预算低估，不是因为模型变贵，而是预算表漏了“看不见的调用”。

建议加入这些字段：

字段	建议写法	作用
retry_rate	5%、10%、20% 三档	估算失败重试造成的放大
eval_calls	每日评测样本数 × 每样本调用次数	把离线评测纳入预算
background_jobs	每日后台批处理任务数	避免只算用户前台请求
fallback_rate	fallback 请求占比	估算升级到更贵模型的成本
peak_multiplier	1.3 / 1.5 / 2.0	给营销活动或流量峰值预留空间

可以把月度预算改成：

月度预算 = 基础成本 × (1 + 重试率) × 峰值系数 + 评测成本 + 后台任务成本

这个公式不一定完美，但比只算“日请求量 × 30”更接近真实账单。

示例 1：客服聊天机器人

客服聊天通常不是单轮短问答，预算表要单独记录历史对话和回答长度。

字段	应该怎么估
平均输入 token	系统提示词 + 用户问题 + 最近 N 轮历史
平均输出 token	统计 50-100 条真实回答，不要用理想短答
请求量	按用户会话数和每会话平均轮次拆开
风险字段	用户重复追问、失败重试、长回答

如果客服场景还接入知识库，就不要把它和普通聊天混在一行，应拆成 RAG 问答预算。

示例 2：RAG 知识库问答

RAG 成本的关键不是用户问题，而是检索片段和历史上下文。

预算表建议加入：

字段	说明
top_k	每次带入多少片段
avg_chunk_tokens	每个片段平均长度
history_tokens	历史对话是否进入请求
no_answer_rate	无答案时是否仍生成长回答
cacheable_tokens	固定系统提示词是否可以缓存

如果一次 RAG 请求带入 6,000 token 检索内容，即使用户只问一句话，输入成本也会明显高于普通聊天。可以参考如何估算 RAG 聊天机器人的 API 成本单独建一张 RAG 预算表。

示例 3：Agent 自动化任务

Agent 工作流不能只算一次模型调用。一次“任务”可能包含计划、工具调用、结果检查、失败重试和最终总结。

建议预算字段：

字段	作用
max_steps	限制单任务最大模型轮数
tool_calls	记录工具调用次数
repeated_tool_calls	发现循环或重复执行
retry_count	记录失败后重复调用
cost_per_successful_task	比单次请求成本更适合做预算

对于 Agent，预算单位最好从“请求”升级为“成功任务”。如果一个任务平均需要 5 次模型调用，预算表就要按 5 次调用估算，而不是只填一次。

七个最容易低估成本的变量

上线前重点检查这 7 个变量：

输出 token：长回答、报告、代码和 JSON 输出都会放大成本；
重试率：JSON 解析失败、timeout、工具参数错误会重复调用；
上下文膨胀：历史对话、RAG chunk、工具 schema 越堆越长；
缓存失效：动态字段让原本可缓存的 prompt 变成未命中；
多模型路由：fallback 或升级模型比例高于预期；
评测和调试调用：测试环境、回归评测、日志重放也会花钱；
峰值流量：发布、营销、爬虫或用户批量导入会把日成本放大。

这些变量最好都在预算表里有单独列，而不是写在备注里。

如何用预算表发现成本异常

预算表上线后不是归档，而是用来对照真实日志。建议每周核对：

预算字段	日志里对应字段
预计日请求量	request_count
平均输入 token	input_tokens 平均值 / P95
平均输出 token	output_tokens 平均值 / P95
缓存命中率	cache_hit_tokens / total_input_tokens
重试率	retry_count > 0 的请求占比
单次成功成本	successful_task_cost

如果发现真实值偏离预算，就回到如何核对 AI API 账单和模型价格逐项拆账。不要只看总金额，否则很难定位是流量增长、输出变长、缓存失效还是模型切换。

什么时候需要成本告警

预算表适合上线前估算和定期复盘，但它不能替代实时告警。出现下面情况时，就应该建立 AI API 成本告警：

日成本接近预算上限；
单请求成本 P95 持续升高；
重试率突然超过阈值；
Agent 工具调用次数异常增加；
缓存命中率突然下降；
某个功能的成本占比持续扩大。

简单说：预算表回答“应该花多少”，告警回答“现在是不是正在失控”。

一个可复制的预算表结构

可以先用下面的列作为模板：

feature
model
input_price
output_price
cache_read_price
daily_requests
avg_input_tokens
avg_cached_tokens
avg_output_tokens
retry_rate
eval_calls_per_day
background_jobs_per_day
peak_multiplier
estimated_cost_per_request
estimated_monthly_cost
actual_cost_last_7_days
variance_note

其中 actual_cost_last_7_days 和 variance_note 是上线后补充的复核字段。预算表不是一次性文档，而是一个随着真实日志调整的成本模型。

总结

AI API 成本预算表的核心，不是做一个漂亮表格，而是把价格、token、请求量、缓存、重试、评测和峰值流量拆成可以核对的字段。先用文本模型计算器估算典型请求，再把结果放入预算表，最后用日志和告警不断校准，才能把一次调用成本真正变成可管理的月度预算。