额度用尽那天：限流、超额和备用通道怎么配

三种限制别混为一谈

每分钟请求数：限制你调多少次，不管每次多长。批量小请求最容易撞这条。

每分钟 token 数：限制吞吐量。一次贴五万字，一个请求就可能把额度占满。

日额度或月额度：总量限制。跑批任务最容易在这里出问题，白天没事，晚上跑批直接打穿。

三条限制对应三种处理方式。撞第一条要排队，撞第二条要拆请求，撞第三条要提前分配预算。

还有一个容易混的：并发数限制。它和每分钟请求数不是一回事，四个并发跑满，第五个请求直接排队，和频率无关。

看到 429 就重试，是最常见的错误。立刻重试只会继续撞墙，还可能把限制时间拉长。

正确做法是指数退避加抖动：第一次等一秒，第二次两秒，第三次四秒，上限三十秒。加随机抖动，避免所有客户端同时重试。

重试要有上限，比如五次。超过就记失败，进队列等下一轮，别无限重试把线程占满。

还要区分是不是真的限流。有些 429 是并发超了，有些是余额不足，看返回内容里的错误码，别一概而论。

把错误码和处理方式做成一张表写进代码，比每次现查快。

最简单的是第二个供应商，同一个任务有两套提示词。切换时注意格式差异，别直接搬。

第二简单的是降级到小模型。质量会掉，但服务不断。适合非关键路径。

第三是排队。把非实时请求放进队列，等额度恢复再跑。适合批处理。

三种可以叠加：主通道限流，先降级，再排队。关键是切换要自动，等人手动切，故障时间就是人的响应时间。

设两个阈值：日花费到八成提醒，到十成自动停或降级。只提醒不停，等于没设。

提醒要发给具体的人，不是发到群里。群里没人认领，等于没发。

还有一种更隐蔽的：单次请求异常大。一条请求花了平时一百倍的钱，多半是材料贴错或者循环失控。按单次成本设上限，比按总额更早发现问题。

补充一句月初跑一次容量估算：这个月计划跑多少量，按当前单价要多少钱，和预算差多少。这个动作十分钟，能避免月底停服。

重试几次合适？

五次以内。再多次，说明问题不在瞬时波动，继续重试只是拖延。

降级到小模型用户能感觉到吗？

能。回答变短、格式变乱、偶尔答非所问。关键路径降级要告知，别默默降。

额度能临时提吗？

多数平台可以申请，需要时间。别等打穿了才申请，提前一周估。