AI API 成本控制实战手册：预算、限额、日志、缓存和模型分层
AI API 成本失控，通常不是因为某一个模型“太贵”，而是因为团队没有把它当成一个真实的生产资源来管理。
数据库有慢查询，云服务器有配额，短信有发送频率，支付有风控规则。AI API 也一样：每一次调用都有 token、模型、重试、缓存、用户、业务入口和最终账单。如果这些东西没有被记录和约束，成本问题迟早会从“感觉有点贵”变成“这个月为什么突然翻倍”。
如果你还不熟悉 token 账单，可以先看 AI API 怎么计费？输入 token、输出 token、倍率和余额一次讲清楚。这篇更偏工程落地：一个团队应该怎样把 AI API 成本控制做成日常机制。
先把预算拆到业务入口
只设一个全局月预算，意义有限。它能告诉你“总共不能花太多”，但不能告诉你哪条业务线正在吃掉成本。
更实用的做法是把预算拆到几个层级：
| 层级 | 例子 | 目的 |
|---|---|---|
| 产品预算 | 客服助手、代码审查、内容生成 | 判断哪个产品功能消耗最多 |
| 环境预算 | dev、staging、production | 避免测试环境误烧生产额度 |
| 用户或租户预算 | 企业客户、内部团队、个人账号 | 防止单个主体拖垮整体成本 |
| 任务预算 | 批量总结、导入解析、agent 自动执行 | 控制长任务和自动化任务 |
预算不是只给财务看的数字。它应该进入系统设计：当某个租户接近月度额度，系统应该降级、提示、排队或拒绝，而不是继续无感调用。
一个常见的分层策略是：
- 70% 以下：正常运行。
- 70% 到 90%：开始提醒负责人，展示高消耗入口。
- 90% 到 100%：限制非关键功能，批处理任务进入排队。
- 超过 100%：默认拒绝高成本请求，只保留必要的低成本路径。
这些比例只是示例，真正阈值要结合业务价值和用户承诺来定。重点是提前定义行为，不要等账单异常后临时关开关。
限额要比预算更靠近请求
预算回答“这个月最多花多少”，限额回答“这一类请求现在能不能继续发”。
建议至少做四类限额：
- 每用户限额：防止单个用户循环触发高成本任务。
- 每租户限额：SaaS 场景下避免一个客户影响全部客户。
- 每接口限额：批量导入、长文分析、agent 执行这类入口必须单独限流。
- 每模型限额：高价模型要有更严格的调用门槛。
限额不要只按请求次数算。AI API 的真正成本和 token 相关，所以更可靠的方式是记录“估算 token”和“实际 token”：
请求前：按输入长度、历史消息、候选模型估算成本
请求后：用服务商返回的 usage 字段修正实际成本
请求前估算可以拦住明显超预算的任务。请求后修正可以让账本逐渐接近真实情况。两者都需要，因为只做请求后统计，等你发现异常时钱已经花出去了；只做请求前估算，又会因为缓存、输出长度和 tokenizer 差异产生偏差。
日志里必须有能对账的字段
成本控制最怕“账单很高，但不知道谁花的”。所以每一次 AI API 调用都应该形成可追踪的用量记录。
最低限度建议记录：
- request id 或 trace id
- 用户、租户、环境和业务入口
- 模型名称和供应商
- 输入 token、输出 token、缓存命中字段
- 请求前估算成本和请求后实际成本
- 调用耗时、状态码、错误类型
- 是否重试、重试次数、最终是否成功
这些字段不一定都要打在普通应用日志里，也可以写入专门的 usage 表、数据仓库或可观测平台。但它们必须能关联起来。没有 request id，后续分析会非常痛苦。
如果你准备给 AI agent 做更完整的追踪，可以继续看 给 AI agent 做可观测性：日志、trace、token 和错误分类。成本控制和可观测性不是两件事，token、错误、重试和链路信息本来就应该在同一条请求路径上。
缓存应该从重复输入开始，而不是从“所有回答缓存”开始
很多人一提成本优化就想到缓存答案。但 AI 场景里，直接缓存最终回答有时并不合适：用户问题略有不同、上下文变化、权限不同、时间敏感信息变化，都可能让旧答案不再可靠。
更稳的优先级是：
- 缓存固定系统提示词和长前缀。
- 缓存 RAG 检索结果或文档切片。
- 缓存工具调用结果，比如数据库只读查询、网页抓取、配置读取。
- 对确定性很强的任务缓存最终结果，比如分类、格式转换、重复摘要。
缓存还要有边界。涉及权限、个人数据、订单状态、实时库存、账户余额的内容，不能因为“省钱”就跨用户复用。缓存键里至少要考虑用户或租户、输入内容、模型版本、提示词版本和权限范围。
不要把缓存命中率写进预算里的刚性前提。更现实的做法是先按无缓存成本估算，再把缓存节省当成优化收益。
模型分层：不是所有请求都需要最强模型
成本控制里最有效的动作之一，是把模型按任务分层。
可以先把任务分成几类：
| 任务类型 | 推荐策略 |
|---|---|
| 分类、打标、路由 | 优先用便宜、快速、稳定的小模型 |
| 摘要、提取、改写 | 默认用中等模型，失败或低置信度再升级 |
| 复杂推理、代码审查、长上下文分析 | 允许使用强模型，但需要预算和日志 |
| 用户可见的关键输出 | 质量优先，必要时用强模型加人工审核 |
模型分层不是简单地“能用小模型就用小模型”。真正的目标是让每一类任务有合适的质量和成本。便宜模型如果导致更多重试、更多人工修正、更多用户投诉，最后未必便宜。
一个实用模式是“先低后高”：
小模型先处理 -> 判断置信度或校验结果 -> 失败时升级到强模型
例如 JSON 提取任务可以先用中等模型生成，再用 schema 校验。如果格式正确、字段完整，就不需要升级。如果校验失败，再换更强模型重试一次。这样比所有请求默认走最高档模型更可控。
控制输出长度，通常比压缩输入更直接
输入 token 很重要，但输出 token 经常更贵，也更容易失控。
在提示词里明确输出边界很有必要：
- 要求只返回 JSON，不要解释。
- 要求摘要不超过固定段落或字数。
- 要求列表最多返回 N 项。
- 要求没有证据时返回空数组，而不是编故事。
- 对长文生成任务设置最大输出 token。
这不是为了让回答变短而牺牲质量，而是避免模型把简单任务写成文章。尤其是后台批处理、分类、提取、审核这类任务，输出越结构化，成本越稳定，后续处理也越容易。
重试和 agent 循环要单独治理
很多成本异常来自失败重试和 agent 循环。
一次 API 调用失败后，系统如果立即重试三次，看起来只是“容错”。但如果失败发生在模型已经开始处理之后，每次都可能产生部分用量。agent 更危险：它可能在工具调用、反思、再次调用模型之间循环，直到达到最大步数。
建议给自动化任务设置几条硬规则：
- 每个用户请求最多允许多少次模型调用。
- 每个 agent run 最多允许多少步。
- 每次工具失败后是否允许重试，最多重试几次。
- 出现权限错误、参数错误、配额错误时不要盲目重试。
- 每次 run 结束后记录总 token、总成本和失败原因。
这部分和普通接口限流不同，因为 agent 的一次用户请求内部可能包含多次模型调用。只看入口 QPS，很容易低估真实消耗。
月度复盘看趋势，不只看总额
月底看一眼总账单，只能知道花了多少钱。真正有用的是趋势和结构。
建议每月复盘这些问题：
- 哪些业务入口消耗最多？
- 哪些模型的单位价值最低？
- 失败请求和重试消耗了多少？
- 缓存命中节省是否真实存在？
- 哪些用户或租户异常高消耗？
- 哪些任务可以批处理、降级或改成离线执行？
- 新功能上线后成本曲线是否符合预期？
成本控制不是一次性优化，而是一个运营动作。随着模型价格、产品功能、用户行为和质量要求变化，最优策略也会变。不要把某一次调参当成长期答案。
结论
AI API 成本控制的核心不是“少用 AI”，而是让每一次调用都可解释、可追踪、可限制、可复盘。
先把预算拆到业务入口，再用限额保护请求路径；用日志和 request id 对账；从重复输入、工具结果和确定性任务开始做缓存；按任务选择模型；控制输出长度；最后把重试和 agent 循环纳入同一套账本。
做到这些之后，成本不一定最低，但会变得可管理。这比事后盯着账单猜原因要可靠得多。