API 用量监控与告警：把"账单惊喜"变成"预算内运行"
作者：夸父
模型 API 按量计费的最大风险是"账单失控"——异常重试、被刷、配置错误都可能在半夜烧钱。本文给一套三层监控告警方案：平台侧、应用侧、账单侧。
三层监控的分工
第一层：平台侧告警（必配，十分钟）。每个模型平台的管理台都有用量告警与预算上限——为每个 Key 配两条：日用量阈值（正常日均值 × 1.5）与月预算上限（硬顶）。这一层是"最后防线"：超了直接停，杜绝无限损失。
第二层：应用侧统计（逐日 AI 内置）。用量按项目/能力维度记录在系统里（每个切片的模型调用都有账），批量的费用预估在提交前可见。应用侧的价值是归因：账单异常时能定位到哪个项目哪个环节——这是平台账单给不了的。
第三层：账单对账（每月例行）。平台账单与应用侧统计对一次账：差异大就查（通常是重试风暴或限流补偿的计费口径差异）。每月一次，10 分钟。
告警的阈值怎么定
拍脑袋的阈值会沦为垃圾信息。用基线法：跑两周的正常生产，记录日用量分布——告警线 = 正常日均值 × 1.5，严重线 = × 3。周均与月度同样按倍数设。阈值随业务量调整，每季度复核一次。
异常的第一响应
收到告警后的动作顺序：先止损（暂停批量任务/临时禁用可疑 Key）→ 再定位（应用侧用量统计找异常项目）→ 后修复（对照 API 报错排查找根因）。顺序别反——先查原因的团队经常在查询期间又烧了一半。
常见问题
最常见的账单失控原因是什么？
前三名：Key 泄漏被外部滥用（见 Key 安全管理）、批量任务的错误配置导致无限重试循环、以及多团队共用 Key 无用量归属。三个都靠监控第一时间发现。
各平台的告警能力够用吗？
主流平台（阿里云/DashScope）都有用量告警与预算设置——够用，但分散在每个平台。跨平台的统一监控建议在应用侧做：逐日 AI 的用量统计按项目/能力维度记录，配阈值告警即可。