AI API 预算最容易算错的地方，是把价格表当成账单。价格表只告诉你每百万 token 的单价，不能告诉你一次真实请求会带多少历史消息、检索片段、工具返回、失败重试和长输出。上线后真正烧钱的，往往不是模型单价本身，而是产品没有给输入、输出和调用次数设边界。

这篇文章给你一套可以直接落地的估算流程：先取 token 样本，再拆请求类型，最后把预算结果变成上线限额。目标不是算出一个永远准确的数字，而是在上线前知道哪类请求最危险、哪个变量最该限制、什么时候该降级模型。

先定义“要估算的请求”，不要估整个产品

不要一开始就问“我们的 AI 功能一个月多少钱”。这个问题太大，因为一个产品里可能同时有短问答、长文总结、RAG 检索、代码解释、报告生成和 Agent 多步任务。它们的 token 结构完全不同。

先把功能拆成独立请求类型：

请求类型输入主要来自输出主要是什么预算风险
普通问答system prompt + 用户问题短回答调用频率高
RAG 问答用户问题 + 检索片段带引用回答检索片段过长
长文总结文档正文摘要或结构化报告输入大、输出长
代码解释代码片段 + 错误日志分析和修改建议上下文不稳定
Agent 任务多轮指令 + 工具返回多步骤结果调用次数不可控

每种请求单独估算，才知道该优化哪里。如果把所有功能混成一个平均值，很容易出现“平均成本还能接受，但某个长文功能一上线就爆预算”的情况。

建三档 token 样本：平均、P90、合法上限

只算平均请求没有意义。你至少要准备三档样本：

样本用途怎么取
平均样本判断日常成本从测试日志或典型用户输入取中位场景
P90 样本判断常见长请求风险取偏长但仍会经常出现的请求
合法上限样本判断最坏账单边界按产品允许的最大输入、最大输出、最大历史轮数计算

以“文档问答”为例，可以这样拆：

字段平均P90合法上限
system prompt700700700
用户问题1204001,000
检索片段2,0005,00010,000
历史消息4001,2003,000
预期输出5001,2002,500

如果你现在没有日志，就用产品限制倒推：一次允许上传多少字、保留几轮历史、检索几段内容、每段多长、输出最多多少。没有这些限制，预算估算本身就不成立。

把输入拆成固定、动态和可缓存三类

很多成本估算会把所有输入 token 混在一起，但上线优化时你需要知道它们来自哪里。

输入类型示例预算处理
固定输入system prompt、工具说明、固定格式要求可评估缓存收益，但先按未缓存估算
动态输入用户问题、历史消息、检索片段通常按普通输入计算
工具返回搜索结果、数据库记录、API 响应要单独设长度上限

最保守的做法是先假设没有缓存命中。这样你能知道“即使缓存失效，预算是否还能承受”。如果后续确实使用 prompt caching，再把固定前缀单独计算为收益项，而不是把缓存当成预算成立的前提。

如果你已经在做 Claude API 成本控制，可以把这一步和 Claude API 成本控制指南 里的限额、日志和告警一起设计。成本估算不能停留在表格里，必须能落到运行时边界。

月预算公式要包含重试率和安全余量

单次成本不能直接乘请求量，因为真实系统会有失败、超时、用户重复点击、后台重跑和模型 fallback。至少用下面这个结构：

月预算 = 单次成本 × 每日请求量 × 30 × (1 + 重试率) × 安全余量

建议初期这样取值：

变量保守值说明
重试率5%-15%包含超时、失败重试、用户重新生成
安全余量1.3x-2x覆盖流量波动和样本误差
上线观察期7 天用真实账单校正估算

不要为了让预算好看，把重试率写成 0。AI 功能越复杂，越容易出现用户反复生成、长任务中断、Agent 步骤重跑和后台批处理重复执行。

预算表要按模型和请求类型交叉展开

对比 Claude、GPT、Gemini 或其他模型时，不要只看谁单价低。你需要把请求类型、质量要求和失败成本放在同一张表里。

请求类型默认模型升级模型降级动作验收标准
短问答低成本模型更强通用模型缩短输出、减少历史回答准确且成本稳定
长文总结长上下文模型高质量模型分块摘要、异步处理不遗漏关键约束
代码解释代码能力强的模型人工审查辅助限制文件数量结果能运行或能复现
RAG 问答平衡型模型高质量模型减少检索片段引用来源可核验
Agent 任务低成本步骤模型关键步骤升级限制最大步骤数不进入无限循环

如果你使用 One API 或类似网关，可以把模型路由、额度和渠道拆开管理。相关配置思路可以参考 One API 使用指南，但预算策略仍然要按具体请求类型来设。

输出 token 通常是最容易被低估的成本

很多人只关注输入，因为长文档和 RAG 片段看起来很大。但实际账单里，输出 token 经常成为意外来源：报告、JSON、代码、邮件、PPT 大纲、表格和多轮解释都可能生成很长内容。

你需要给输出设三种限制：

  1. 默认输出长度：普通回答不要默认生成长报告。
  2. 长输出确认：超过一定长度前，让用户确认或切换异步任务。
  3. 结构化输出边界：JSON、Markdown 表格、代码块要限制字段数和条目数。

预算超标时，先看输出是否失控。很多场景不用换模型，只需要把“默认生成 3000 token”改成“先给摘要，再由用户点击生成完整报告”。

把预算结果变成上线限额

预算表没有进入产品和工程约束，就只是文档。至少把结果转成这些规则：

预算发现上线动作
P90 输入过高限制历史消息轮数、检索片段数量、上传字数
输出成本过高默认短回答，长报告二次确认
极端请求成本不可接受分块处理、异步队列、人工确认
重试成本高幂等键、按钮防连点、失败重试上限
高质量模型成本高只给高价值任务升级模型
缓存收益不稳定预算按无缓存成立，缓存只作为优化项

上线时还应配置告警：日成本、单用户成本、单请求 token、失败重试次数、模型 fallback 次数。只看月账单太晚，等你发现异常时，成本已经发生了。

预算复盘要看偏差，而不是只看总账单

上线后一周，拿真实日志和估算表对比：

  • 平均输入是否比样本更长。
  • P90 请求是否更频繁。
  • 输出长度是否超过预期。
  • 检索片段是否过多。
  • 重试率是否被低估。
  • 是否有后台任务重复跑。
  • 是否有用户用短问答入口处理长文档。
  • 是否有某个模型被 fallback 频繁触发。

如果账单偏离预算，不要直接说“模型太贵”。先定位是哪一类请求、哪个 token 字段、哪个产品入口导致的。这样才能决定是改 prompt、限输入、限输出、拆任务、调模型，还是改收费策略。

可复制的上线前检查表

上线 AI 功能前，至少保留下面这些证据：

  • 请求类型清单。
  • 平均、P90、合法上限三档 token 样本。
  • 每个字段的来源：system prompt、用户输入、历史消息、检索片段、工具返回、输出。
  • 每日请求量假设。
  • 单次成本和月预算计算方式。
  • 重试率和安全余量。
  • 模型路由规则。
  • 输入、输出、历史消息、检索片段上限。
  • 超预算时的降级动作。
  • 上线后一周复盘计划。

如果你还需要比较不同模型的单价维度，可以结合 2026 年 AI API 价格对比 看价格表；但真正决定账单的，仍然是你的请求结构和产品边界。

用 AICostNest 先做一次预算校验

如果你不想一开始就自己维护复杂表格，可以先用 AICostNest 做一次模型成本预估。它的价值不是替你决定模型，而是把文本、推理、图片、音频、视频等不同 AI API 成本拆到同一个计算流程里，帮助你快速看到单次请求、批量任务和月度预算之间的数量级差异。

更合理的用法是把 AICostNest 当成上线前的预算草稿工具：先输入你估算出的 token、请求量或多模态任务规模，得到一个初步成本区间；再回到自己的产品日志里，补充 P90 请求、重试率、安全余量、模型 fallback 和用户限额。这样既能避免手算漏项，也不会把计算器结果误当成真实账单。

对于团队内部评审，可以把 AICostNest 的计算结果作为讨论入口：哪些功能必须限流，哪些任务适合低成本模型，哪些长输出需要二次确认，哪些多模态任务应该单独计费。预算工具给出的是数字起点，真正要落地的仍然是本文前面提到的运行规则、告警和上线后一周复盘。

总结：预算不是截图，而是运行规则

AI API 预算的最终产物不应该是一张计算器截图，而是一组可执行规则：哪些请求能走高阶模型，哪些输入必须截断，哪些输出需要确认，哪些任务要异步，哪些用户行为要限频，什么时候告警，什么时候降级。

只要你先用三档 token 样本拆清楚成本结构，再把结果转成限额、路由和复盘机制，就能在上线前发现大部分账单风险。模型价格会变，但这套估算方法可以反复复用。