🧑💻 面试官：晚高峰大量请求打到模型接口，开始出现 429。你会怎么处理？
🙋♂️ 我：先控制入口并发和请求预算，区分必须即时返回的交互请求与可以排队的批任务。不能让每个请求都立刻自己重试。
🧑💻 面试官：指数退避不是标准做法吗？
🙋♂️ 我：是重要的一环，但要有限次数、加抖动，并考虑整体超时。否则一批请求同时退避、同时醒来，还是会冲击下游。
🧑💻 面试官：队列满了怎么办？
🙋♂️ 我：明确降级或拒绝，并告知用户稍后重试。不能悄悄把交互请求排半小时，最后再返回一个已经过时的答案。
限流题考的不是会不会写重试，而是能不能让入口流量、等待时间和下游配额相互匹配。
面试速答（60 秒版）
遇到模型接口限流，我会先在入口控制并发、请求量和 Token 预算，避免把所有流量都推给供应商。可以延迟的批处理进入有上限的队列；交互请求则设置短等待预算，超出就明确降级或失败。
对可重试的 429，按服务返回的提示或指数退避加抖动，在总时限内有限重试。失败请求也可能消耗限额，所以不能让每个请求无限重试。若容量持续不足，可以降低非关键任务优先级、缩短不必要的上下文、切换经评测可用的模型，或让部分任务异步完成。
监控不只看 429 次数，还要看排队时间、请求超时、重试放大倍数、不同租户占用和用户最终成功率。
知识点详解：把高峰请求放进容量预算里
为什么直接重试会制造更大的高峰
假设每秒来了 100 个请求，下游只能接 60 个。剩下的 40 个如果每隔一秒重试三次，下一秒新请求还没处理完，旧请求又回来了。流量会被重试放大，排队和 429 一起增加。
正确的第一步是入口限流：按用户、租户和业务优先级限制请求与 Token 消耗，并控制同时在飞的请求数。不同供应商的限额维度可能不同，不能只盯每分钟请求数。
队列要有上限和截止时间
报告生成、批量标注可以异步排队。聊天请求对等待时间敏感，排队太久时，即使最后成功也可能失去价值。队列要设置最大长度和任务截止时间，到期后明确终止，而不是无限积压。
对 429 可以退避，但同一批请求若同时醒来，会再次撞上限额。加入抖动能分散重试时刻。每次重试还要检查剩余时间预算；已经没有足够时间完成的任务，不该再盲目排一次。
降级要事先定义，不要故障时临时猜
可以优先保住核心场景，暂停低优先级批任务；也可以对经过任务集验证的简单请求切轻模型。若模型能力不够，宁可清楚告诉用户暂时无法处理，也不要把复杂高风险问题强行丢给低能力模型。
上线后要看端到端指标：用户等了多久、最终成功多少、队列积压多少、重试增加了多少调用。供应商限额只是外部约束，用户体验取决于整个调度链路。
面试官继续追问
把所有请求都入队，就不会收到 429 了吗？
队列只能平滑流量，不能凭空增加容量。若长期进入速度大于处理速度，队列仍会越积越长。
429 后什么时候不该重试？
总时限不足、重试预算用尽、请求不可安全重放，或服务明确要求更晚再试时，都应停止当前同步重试。
如何避免一个大客户占满额度？
按租户设置独立配额与并发上限，必要时给核心业务保留容量，并监测租户级排队和成功率。
面试速记卡
- 入口：先控请求、Token 和并发。
- 队列：有长度上限和截止时间。
- 重试：有限次、退避加抖动，并受总预算约束。
- 降级：事先验证可用范围，别让高风险题硬走弱模型。
- 指标：看最终成功率和等待时间，不只看 429。
