预算告警怎么设：把跑飞限制在一晚以内的 5 道闸

最常见的翻车不是模型贵，而是没人设上限：夜里跑了个循环，早上起来额度见底。这篇不讨论单价，只讲怎么把「单次失控」的影响范围压到可接受的程度。五道闸按从外到内排列，每道都写清配置在哪一层、怎么验证它真的生效、没生效时用什么兜底。

最常见的翻车不是模型贵，而是没人设上限：夜里跑了个循环，早上起来额度见底。这篇不聊单价，只讲怎么把单次失控的影响范围压到可接受的程度。五道闸按从外到内排列，每道都写清配置在哪一层、怎么验证它真的生效、没生效时拿什么兜底。

判断标准一句话：一个会自己反复调用的任务，至少要跨两层设限，只靠单层等于没设。如果你不确定任务最长跑多久，别去猜，按「你能接受的最坏一晚」倒推步数和总超时，两个都写死。

先搞清五道闸分别拦在哪一层

闸门从外到内是：账号总预算、Key 级上限、单次请求输出上限、应用层步数上限、异常告警与自动停用。越靠外的闸越粗，管的是钱；越靠内的闸越早触发，管的是行为。粗闸拦不住细的失控，细闸也护不住整账号，所以是叠加关系，不是选一个。

账号总预算

平台侧的总闸，兜底用，触发时通常已经烧掉不少

Key 级上限

按 Key 隔离，生产 Key 和试验 Key 分开放，是性价比最高的一道

单次输出上限

请求体里写死 max_tokens，防的是单次回答跑满

步数上限

代码里给循环设最大轮数和总超时，防的是反复调用

告警与熔断

让系统半夜自己停下来，而不是靠人醒着盯

• 交互式一问一答、每次都由人点一下才发请求的场景，重点放在 Key 上限和单次输出上限即可，不必强上熔断。
• 定时批量任务、Agent 循环、多轮自动重试，必须跨两层以上设限。
• 把每一层的当前值记在一张表里，改一次记一次；配置散落在平台后台、环境变量和代码三处，不记下来等于不清楚自己到底有没有闸。
• 换过模型或渠道之后要重新核对一遍，别假设旧配置还适用。

五道闸怎么配：位置、验证、兜底

Key 上限的要点是分离：把生产 Key 和试验 Key 分成两个，试验那个额度给小一点，跑飞了也只伤试验那一个。项目级预算按环境分，预算周期设成比账单周期更短的一档，这样你能更早看到异常。真正的消耗口径和计价项，到 /price-watch 核对当时的数字，别拿自己脑补的公式对账。

1. 先定最坏一晚能接受多少拿一个具体数字当上限依据，别用「越少越好」；这个数字决定后面所有步数和超时的取值。
2. 写死单次输出上限请求体里显式传 max_tokens，不要吃默认值；验证方式是发一个明显会诱导长输出的提示词，确认返回被截断。
3. 给循环加两道刹车最大轮数和总超时同时设，取先到的那个。验证时故意造一个不收敛的任务，看它是否在预期步数停住。
4. 算兜底计数器平台不支持 Key 上限时，在调用方本地累加每次调用的估算消耗，超过阈值直接抛错退出，宁可任务失败也别继续烧。

告警与熔断：让它在半夜自己停

告警只有提醒没有停用，人睡着了照样跑飞。所以要分两档：一档是「消耗速度异常」的提醒，一档是「已到硬阈值」必须停。硬阈值那档的触发条件建议用速率而不是绝对额度，单位时间内的请求数或 token 数超过基线若干倍就停，这样不会把正常高峰误杀。

• 熔断动作要实测：把阈值临时调低到一定会触发，跑一次，确认 Key 被禁、进程退出、告警发出，三件事至少发生一件。
• 自动化流水线里的关键任务不适合直接硬停，改成降级到更小批量或排队，否则会连带业务中断。
• 触发后是等人工确认还是自动恢复，提前写进值班说明，避免凌晨起来乱改配置。
• 把「谁被叫醒、怎么恢复」当成配置的一部分，不是附加文档。

上线前的核查清单

• 每个 Key 是否设了独立上限，生产与试验是否分开。
• 每个项目或环境是否有独立预算，周期是否短于账单周期。
• 每个请求是否显式带 max_tokens，而不是靠默认值。
• 每个循环是否有步数上限和总超时，两者是否取先到。
• 是否有两档告警，其中一档会真的停用。
• 熔断动作是否实测过，恢复流程是否写明。

模型、任务规模和渠道都会变，闸门的值要跟着调，别设一次就不管。每次改动用量结构之后重跑一遍上面的验证。想先搞清楚各家中转与官方的可信度和计费差异，到 /sites 看当时的检测记录，再决定手上这套配置该松还是该紧。