重试的退避是怎么算的？越等越久

大模型请求偶尔失败是常态，失败不可怕，可怕的是所有人同时重试。重试时如果立刻再发，撞上同一波拥堵只会雪上加霜，退避就是让每次重试越等越久的那套算法。把等待的账算明白，重试才不会帮倒忙。

第一次重试等多久

失败后先别急着重发，第一版退避给一个基础等待，比如几百毫秒。进来的是一次失败响应，发生的是按策略计算延时，出去的是定时器上的第一次重试时刻。

为什么不等长间隔？固定间隔的重试会同步：一批客户端在同一时刻失败、同一时刻重发，形成节拍一致的冲击波，服务端刚缓过来又被踩一遍。间隔错开才能把冲击摊平。

重试前还要确认失败属于暂时性故障：超时、限流、连接中断这类值得等，明确告知不可恢复的失败再试也是白试，重试策略要和错误类型配对。第一版等待也别太短：几百毫秒的等待对毫秒级抖动有效，对秒级拥堵无效，起点定多长要看故障的典型时长。

等待的选择权也在调用方：有的接口在拒绝响应里直接给出建议等待时长，照着等比拍脑袋准；没给的就把响应头里的限流信息记下来，作为下次的参考。

指数退避怎么翻倍

指数退避让等待按倍数增长：第一次半秒，第二次一秒，第三次两秒，以此类推。连续失败说明拥堵没缓解，越等越久给服务端留出恢复时间，也省下无意义的尝试。倍数一般取二，也可以取更小，翻得越陡放弃得越早，翻得越缓总等待越久，节奏按业务能忍的程度定。

翻倍并非无限：重试次数设上限，超过就放弃并把失败上报。对调用方来说，指数退避几乎不需要配置就能受益，默认参数已经够用。你在扣子（Coze）里编排工作流调用大模型接口时，失败自动再试的间隔逐渐拉长，就是指数退避在算账。退避节奏要和服务端恢复能力匹配：扩容要几分钟，十秒内连试五次纯属浪费，把重试间隔拉到和服务端恢复同一个量级，等待才花得值。

抖动和上限的刹车

纯指数也有节拍问题：大家的等待成比例增长，还是可能撞到一起。解决办法是加抖动，在计算出的延时附近随机偏移，把整齐的重试打散。抖动还有全量与等量两种做法，前者范围更大、打散更彻底，具体以所用框架的默认实现为准。

上限是另一道刹车：等待封顶在一个可接受的时长内，防止第十次重试等上十分钟。封顶值要结合业务容忍度定，等待超过用户耐心，重试成功也没意义。你在豆包、文心一言里偶发失败后自动恢复，多半是重试加退避在幕后兜底。每次重试的结果也值得记录：第几次成功、共等了多久，这些数据回头能帮你校准参数，默认值只是起点，真实流量才是标尺。退避参数调好后要压测验证：人为制造拥堵，看重试能否自动恢复、封顶是否合理，参数在演练里检验，别等事故才第一次生效。

重试撞车、猛试、同步、等太久，四组症状的成因与对策。

• 速查：固定间隔会同步撞车；指数退避按倍数拉长等待；抖动打散节拍；重试前先看错误类型；次数与封顶双刹车。

失败处理是一整条链路，思考模型的思考段是怎么生成的？标记切换决定了耗时形态，超时后的部分结果怎么处理？半截答案收拾中断现场，降级时的小模型是怎么顶上的？机制细节全梳理在重试救不回来时换挡，异步调用是怎么通知完成的？回调与轮询则把长等待挪到后台。

关于退避重试再多问三句

• 每种失败都值得重试吗？：要看失败类型，明确不可恢复的失败再试也白试，只重试暂时性故障。
• 等待期间请求算不算占用？：不算，定时器挂着而已，算力早已释放。
• 抖动会不会让等待更久？：上下浮动都有可能，换来的是重试时间错开，整体更稳。