重试、退避，以及延迟图里的幽灵

LLM 调用的重试逻辑是那种你以为很显然，直到它差点搞挂一个服务的事情。模型 API 返回的 429 不等同于缓存查询返回的 429。模型生成异常变慢导致 30 秒后超时，不等同于网络抖动。把它们当一类处理，就是一次”上游 API 的五分钟事故”如何变成”你这边的四十分钟事故”。

朴素重试遮住了什么

经典反模式是没有 jitter、没有上限的指数退避。当上游限速时，每个客户端都按同一个时间表重试，第二波又撞上同一个限制，系统进入上游永远恢复不了的雪崩。你的延迟仪表盘看起来是一个干净的尖峰加上不消退的尾巴，原因看起来是模型 API，实际是你自己的重试策略。

实际有效的做法

交互式路径上限两次，后台路径上限三次。加 jitter——退避窗口里的均匀随机延迟。区分错误类别：限速、超时、内容策略拒绝、暂时性 5xx 都该用不同策略。按截止时间预算重试，而不是按次数——一个已经跑了 8 秒的请求，再重试 4 秒不会变得更好。

我复盘过的大多数生产 LLM 事故，主路径都是好的，挂掉的是重试路径。重试路径才是会咬到你的那个。