AI API 预算告警与自动熔断
很多团队做了“预算上限”，却依然会在月底发现账单异常。原因通常不是没有上限，而是异常发生时没有足够早地被发现，也没有自动止损。当模型循环重试、某个租户突然放量、或者新版本把上下文长度悄悄放大时，如果系统只能等到“本月预算用完”才动作，实际上已经太晚了。
所以，预算治理不能只看“有没有 cap”，还要看告警是否提前、熔断是否分级、恢复是否可审计。本文专门讲这三件事。
一、预算告警的目标不是报表，而是争取处置时间
财务报表回答的是“已经花了多少钱”，预算告警回答的是“照这个速度继续跑，多久会出事”。两者看的是不同时间维度。
这也是为什么很多团队只做月累计成本，却没法及时处置异常：月累计适合结算，不适合实时防守。真正有价值的告警至少要覆盖下面三类信号：
| 信号 | 关注点 | 适合发现什么 |
|---|---|---|
| 累计占比 | 已用预算 / 总预算 | 长期超支趋势 |
| burn rate | 单位时间内的花钱速度 | 突发流量或循环失控 |
| 异常偏离 | 相比历史基线是否突然抬升 | 新版本、单租户异常、模型切换副作用 |
只盯累计占比，会错过“今天一小时烧掉三天预算”这种事故；只盯 burn rate，又会忽略长期慢性超支。预算告警必须是组合拳。
二、先按业务层级拆预算，再定义谁先被熔断
自动熔断真正难的不是技术实现，而是业务优先级。你不能把“用户登录后的核心问答”和“站内文章摘要预生成”用同一把刀切掉。比较稳的做法，是先把 AI 能力按层级分类：
| 级别 | 典型功能 | 预算吃紧时怎么处理 |
|---|---|---|
| P0 | 核心主链路，如付费问答、关键审核 | 保留，优先切便宜模型或缩短输出 |
| P1 | 重要但可降级功能，如报告润色 | 降级到小模型、减少上下文 |
| P2 | 后台增强功能，如批量打标签、离线摘要 | 暂停或延后执行 |
| P3 | 实验功能、内部工具 | 直接熔断 |
这一步必须在事故前决定，不能等告警响了再临场拍脑袋。否则工程上虽然做了熔断开关，业务上却没人知道该先停什么。
三、阈值设计要分“预警、限制、熔断”三层
预算控制最怕只有一个总阈值。因为到了 100% 才动作，留给人的只有背锅时间。更可操作的做法通常是三层：
- 预警层：例如达到月预算 60% 或 70%，通知值班人和业务负责人。
- 限制层：例如达到 85% 后，自动关闭高成本非核心功能，或者切换到低成本模型。
- 熔断层：例如达到 95% 或 burn rate 超过阈值时，直接暂停 P2/P3 能力。
这里有个关键点：累计比例和 burn rate 要并列判断。比如某天上午只用了本月预算的 35%，看起来还很安全；但如果过去 15 分钟的 burn rate 已经达到平时的 8 倍，说明系统正在进入事故状态，应该提前启动限制层，而不是继续等总预算接近上限。
一个简化的判定逻辑可以写成这样：
def budget_mode(month_ratio: float, burn_rate_ratio: float) -> str:
if month_ratio >= 0.95 or burn_rate_ratio >= 6:
return "circuit_open"
if month_ratio >= 0.85 or burn_rate_ratio >= 3:
return "restricted"
if month_ratio >= 0.70:
return "warning"
return "normal"这个函数本身不复杂，难点在于 burn rate 的口径要统一，例如都按“最近 15 分钟成本 / 过去 7 天同时间窗 P95 成本”来算，否则阈值没法稳定使用。
四、自动熔断不要只返回报错，要先做降级
很多团队把“熔断”理解成直接 503。对基础设施组件来说这没错，但对 AI 产品来说，完全失败通常不是第一选择。更稳的顺序往往是：
- 缩短输出上限
- 减少历史上下文或关闭高成本工具
- 切到更便宜或更快的模型
- 暂停后台异步任务
- 最后才是对低优先级功能直接返回不可用
换句话说，预算熔断不是单一开关，而是一套按成本敏感度排序的降级剧本。这和 AI Agent 降级与容错策略：生产级可靠性设计 的思路一致，只不过这里的触发条件从“下游故障”换成了“成本异常”。
五、监控指标别只看美元，要能定位是谁花掉了钱
如果你的监控面板只有“本月花费总额”，值班人收到告警后的第一反应一定是：钱到底花在哪了？所以预算告警要配套最少一组归因维度：
- 按模型看：是不是某个高价模型比例突然升高
- 按租户看：是不是单个客户异常放量
- 按功能看：是不是某个新上线能力漏了上限
- 按错误重试看：是不是 429/5xx 触发了重复调用
没有这些维度，告警只能提醒“出问题了”，却帮不了你快速止损。站内的 AI Agent 单会话成本监控实现 和 LLM Token 成本账本设计 更偏底层追踪；本文强调的是，把这些底层数据接进值班动作。
六、恢复策略要和熔断策略一起设计
自动熔断上线后，另一个常见问题是“怎么恢复”。如果恢复条件没有事先写清楚，系统要么一直关着，要么刚恢复又立刻被打爆。
比较稳的恢复方式通常是：
| 状态 | 动作 |
|---|---|
| 告警解除 | 人工确认根因是否已消失 |
| 半开（half-open） | 只恢复一小部分流量或单个租户 |
| 观察期 | 观察 15–30 分钟 burn rate 是否回到正常范围 |
| 全量恢复 | 再逐步放开 P1、P2、P3 功能 |
这套流程的目标不是“恢复得最快”，而是“恢复后不二次爆炸”。尤其在 AI 场景里，很多成本异常其实来自 prompt 改动、重试 bug、上下文暴涨这类软件问题，不是底层模型服务自己恢复就结束了。
七、结论：预算治理本质上是值班系统设计
AI API 预算告警与自动熔断，看起来像财务控制，实质上更接近 SRE 的值班系统设计。你需要的不只是一个“每月花费不能超过 X”的数字，而是一套能回答四个问题的机制：现在花钱速度正常吗、异常先影响哪些功能、系统会怎么自动止损、恢复时谁来放量。
把这四件事做清楚后，预算控制才不再是月底复盘 PPT 上的一张曲线，而会真正变成生产系统的保护层。对于规模还不大的团队，最值得先做的不是复杂算法，而是先把预算分层、告警分级、熔断顺序这三件事落成规则。
八、相关阅读
- AI API 预算上限自动化设计：防止账单爆炸的工程实践
- AI Agent 单会话成本监控实现：从零构建 Token 追踪系统
- AI Agent 降级与容错策略：生产级可靠性设计
- LLM Token 成本账本设计
如果你要先把多家模型调用统一接到一个入口，再在上层挂预算、告警和熔断逻辑，YoTradeApi 可以帮助你减少多供应商接入和计费口径不一致带来的工程复杂度。