高并发下的限流与重试：别把 429 变成雪崩

中转站的限流通常按账号与模型双维度生效，触发后返回 429。多数 SDK 的默认重试是「立即重试三次」，在上游已经排队的情况下，这等于给拥堵的路口再加三辆车。 我们的做法是三条：第一，指数退避加随机抖动，基数 1 秒、上限 30 秒，抖动幅度 30%，避免所有客户端同一时刻重试；第二，按模型分池，把旗舰模型与低价模型的并发配额分开，防止一个批量任务吃光全部额度；第三，熔断阈值写死，连续 10 次失败即暂停该模型 60 秒，期间请求直接走降级模型而不是继续重试。 上线前用压测确认三档并发（1、4、16）下的 p95 与错误率曲线，把拐点作为配额上限。真实业务里，稳定跑在拐点以下的吞吐，通常比贴着拐点跑高出两成有效产出。 最后一点：把重试次数与业务重要性绑定。查询类请求可以重试三次，写入类请求最多一次并落盘补偿队列；否则重试会把「一次失败」放大成「三次扣费加一次重复写入」。 压测时还要记录「被限流的请求占比」。如果 429 比例长期高于 3%，说明配额与实际需求不匹配，此时调低并发或提前申请提额，比事后排查超时更省时间。