实时用量而非月报
按场景看每小时 token 消耗、请求数与缓存命中，而不是等月底看总账。为什么：成本事故多在数小时内发生，月报只能事后归因；实时看板能在异常扩散前触发告警，把损失控制在当天。
四类异常模式
单请求 token 突增、重试率上升、缓存命中骤降、某场景请求量异动。怎么做：把四类做成固定查询并设阈值，触发时先看最近的模板与配置变更；多数异常都能在变更记录里找到对应条目。
限额与降级联动
按场景设日限额与月预算，超额触发限流、切轻量模型或关闭非关键功能。为什么预先定义：事发时再讨论手段往往已过数小时；边界是降级动作要经过评测并与业务方书面约定，保留一键恢复。
版本管理与复盘
模板、模型与检索配置都要版本化，变更单要记录预期影响。做法是上线后观察一天再关闭变更单，月度复盘异常与改进项；边界是紧急修复可先处理后补记录，但要限定补录时限，否则复盘失真。
适用与不适用
适合谁
- 已接入计费接口、有值班制度的运维团队
- 多场景共用模型接口的平台方与部门
- 月度 token 支出已进入预算科目的企业
不适合谁
- 调用量极小、没有预算约束的项目
- 无法查看请求明细与账单的岗位人员
典型场景
一家在线教育平台的运维在开学前把日限额调到平时的七成，并预设超额后切轻量模型的顺序。开学首日答疑量翻倍，告警触发后自动降级，主链路稳定；第二天团队按看板调整了限额与缓存策略，并把结论写进手册。
可执行步骤
- 按场景搭实时用量看板，展示 token、请求数与命中率，按小时刷新
- 固化四类异常查询，设定阈值、通知渠道与值守人，定期校准阈值
- 按场景设日限额与月预算，明确超额后的动作顺序与恢复条件
- 模板与模型变更全部版本化，变更单记录预期影响，附回滚方式
- 每月复盘异常与改进项，更新阈值、动作与操作手册，形成闭环
常见坑
- 只看月度总账，异常发生在月中，等发现时已经超支，只能等下月收口，损失已发生。
- 告警只发消息不联动，值班人员不敢动生产，只能等白天处理，成本继续上涨。
- 模板改动没有版本记录，命中率骤降时无法对照，排查靠猜，恢复很慢，影响持续。
- 限额设得太死，正常促销也被限流，业务方要求整体关掉监控，治理前功尽弃。
自检与验收清单
- 是否按场景实时展示用量与命中率
- 四类异常查询是否固化并设定阈值
- 限额与降级动作是否与业务书面约定
- 模板、模型与配置是否全部版本化
- 月度复盘是否有改进项闭环与责任人
常见问题
实时监控会不会很占资源
采集本身开销很小，主要是存储与查询。建议只保留聚合指标与异常样本，原始请求按周期清理；确需留存的按数据分级管理。相比成本事故的损失，这点开销通常可以接受。
限额应该按什么定
按场景的历史用量加合理余量，并随业务节奏调整。促销与新功能上线前要临时提高，避免误伤；长期看应把限额与预算挂钩，由业务与财务共同确认，而不是技术单方设定。
降级后怎么恢复
预设恢复条件与检查项：用量回落到阈值以下、质量指标正常、告警解除。恢复动作要有人确认，不能完全自动来回切换，否则会在阈值附近反复抖动，反而影响体验。