AI 大模型故障：重试退避策略怎么写：指数退避加抖动，别用固定间隔硬刚

一、为什么固定间隔重试必然失败

先看一个真实场景。某团队调用大模型API，遇到429限流后写了个循环：for i in range(5): try; except: sleep(1)。上线后监控显示，限流不但没缓解，反而在流量高峰时演变成大面积超时。原因很简单：当一百个并发请求同时被限流，它们会在同一秒集体重试，形成脉冲式流量，把刚恢复的配额瞬间打满。

这就是固定间隔重试的根本缺陷——它假设失败是独立事件，忽略了失败的同步性。分布式系统中的失败往往具有时间相关性：一次网关抖动、一次配额耗尽、一次模型推理集群过载，会让大量请求在同一时刻失败。固定间隔让这些请求在同一时刻重试，形成"重试共振"。

1.1 重试共振的量化直觉

假设服务端容量为C，正常负载为0.7C，一次抖动导致瞬时失败率上升到30%。若所有失败请求在固定1秒后重试，则第1秒的瞬时负载会达到 0.7C + 0.3C = 1.0C 的临界点；若抖动持续两轮，负载会突破容量，触发更多失败，进入正反馈。AWS在其架构博客中多次强调这一现象，并把它归为"重试风暴（Retry Storm）"的典型成因（来源：AWS Architecture Blog, "Exponential Backoff And Jitter", 2015，至今仍是该主题被引用最多的工程文献之一）。

本文评述：固定间隔的问题不在于"间隔"本身，而在于"固定"——它剥夺了系统在时间维度上分散压力的能力。退避的本质，是把同步的失败转化为异步的恢复尝试。

1.2 大模型API失败的典型分布

大模型服务的失败模式与传统微服务既有重叠又有区别。根据OpenAI、Anthropic、Google Vertex AI等公开文档整理的常见错误码，可以归纳为下表。需要说明的是，各厂商错误码命名不完全一致，下表为整合分类，具体以各厂商最新官方文档为准。

错误类型	典型状态码	是否可重试	建议策略
限流	429	是	退避+抖动，尊重Retry-After
服务端错误	500/502/503	是	指数退避，限制最大次数
超时	—	视情况	短退避，注意幂等
上下文超长	400	否	截断或换模型，重试无意义
鉴权失败	401/403	否	修复凭证，重试只会浪费预算
内容审核	400	否	修改输入，不可原样重试
流式中断	连接断开	部分	需断点续传或整体重生成

这张表的关键洞察是：可重试性（Retryability）必须先于重试策略被判定。把不可重试的错误扔进退避循环，是最常见的工程浪费。本文评述：很多团队的重试代码之所以"看起来在工作"，是因为重试了本不该重试的错误，恰好偶尔成功，掩盖了逻辑缺陷。

二、失败预算：贯穿全文的分析主线

本文提出"失败预算"作为分析主线。它的定义是：在给定时间窗口内，系统允许因重试而额外消耗的请求量、延迟与成本的总和。这个约束把重试从"能重就重"的局部决策，变成全局资源分配问题。

失败预算有三个维度：

• 请求预算：重试产生的额外QPS不能超过服务端配额与自身容量的余量。
• 延迟预算：重试带来的总延迟必须落在用户可接受范围内（如首token延迟、总响应时间SLO）。
• 成本预算：每次重试都产生token计费，重试率×单价不能突破成本上限。

本文评述：把重试纳入失败预算，能解释很多"教科书没讲"的现象。比如为什么流式请求的重试要格外谨慎——它消耗的延迟预算远高于非流式；为什么Agent多步调用不能简单套用单次调用的退避——它的请求预算被放大了一个数量级。

2.1 失败预算的量化框架

设正常请求速率为R，平均失败率为p，最大重试次数为n，退避策略决定了重试的时间分布。一个粗略的额外请求量上界为：

额外请求量 ≈ R × p × (1 + p + p² + ... + p^(n-1))
           = R × p × (1 - p^n) / (1 - p)   (p < 1)

当 p 较小（如 0.05）时，额外请求量 ≈ R × p
当 p 接近 1 时，额外请求量 ≈ R × n   ← 危险区

这个公式给出一个重要结论：当失败率接近1时，重试次数n直接线性放大负载。这正是服务端全面故障时，客户端重试会加速雪崩的数学原因。Google SRE Book（Beyer et al., 2016）在"Handling Overload"章节中明确指出，客户端重试在服务端过载时会形成正反馈，建议配合重试预算（Retry Budget）使用。本文评述：重试预算本质是失败预算的工程实现，它把"最多重试几次"从固定值改为动态配额。

三、指数退避的数学基础与推导

指数退避（Exponential Backoff）的思想可追溯到以太网CSMA/CD协议中的二进制指数退避（Binary Exponential Backoff），用于解决多节点共享信道时的冲突重传。Metcalfe与Boggs在1976年的经典论文中描述了这一机制（来源：Metcalfe & Boggs, "Ethernet: Distributed Packet Switching for Local Computer Networks", Communications of the ACM, 1976）。本文评述：把以太网的冲突退避思想迁移到分布式API调用，是工程史上一次成功的跨域类比——两者都面对"多个独立主体竞争有限资源"的核心矛盾。

3.1 基本公式

最常见的指数退避形式为：

delay(k) = min(cap, base × 2^k)

其中：
  k     = 第k次重试（从0开始）
  base  = 基础延迟（如 0.5s）
  cap   = 延迟上限（如 30s）

base=0.5s、cap=30s时，延迟序列为：0.5, 1, 2, 4, 8, 16, 30, 30...。cap的存在至关重要——没有cap，第10次重试要等512秒，用户体验和连接资源都无法承受。

3.2 为什么是指数而非线性

线性退避（每次+固定值）在失败率低时表现尚可，但在持续故障下，重试间隔增长太慢，无法有效降低重试密度。指数退避的合理性来自一个假设：故障持续时间越长，其恢复所需时间越可能也越长。这符合重尾分布（Heavy-tailed Distribution）的直觉——短故障频繁，长故障罕见但影响大。指数增长让重试间隔快速拉开，给服务端足够的恢复窗口。

本文评述：指数退避并非普适最优。对于"瞬时抖动"型失败（如网络丢包），线性或小步退避反而更快恢复；对于"容量耗尽"型失败，指数退避才体现优势。因此工程上应先做失败归因，再选退避曲线。这一点在Marc Brooker关于抖动与退避的系列文章中也有类似论述（来源：Marc Brooker, "Exponential Backoff and Jitter", AWS Blog, 2015；以及其后续关于队列与重试的讨论）。

3.3 退避曲线的对比

策略	第1~5次延迟(s)	优点	缺点
固定间隔	1,1,1,1,1	实现简单	重试共振，易雪崩
线性退避	1,2,3,4,5	增长平缓	长故障下密度仍高
指数退避	1,2,4,8,16	快速拉开间隔	无抖动时仍同步
指数+抖动	随机化	打散同步，最优	实现稍复杂

需要强调：指数退避单独使用仍会同步。因为所有客户端用同样的base和cap，第k次重试的时间点仍然对齐。这就是抖动（Jitter）必须登场的原因。

四、抖动策略：Full / Equal / Decorrelated

AWS的那篇经典博客对比了三种抖动策略，并用仿真展示了它们在"客户端数量多、失败同步"场景下的差异。本文在此基础上结合大模型场景做延伸评述。

4.1 Full Jitter（全抖动）

delay = random(0, min(cap, base × 2^k))

Full Jitter在[0, 指数上界]区间内均匀取值。它的特点是重试时间完全打散，总请求数（完成时间）表现最优，代价是部分请求可能很快重试（延迟小），部分很慢。AWS仿真显示，在大量客户端竞争场景下，Full Jitter的总完成时间显著优于无抖动方案。

4.2 Equal Jitter（等量抖动）

temp = min(cap, base × 2^k)
delay = temp/2 + random(0, temp/2)

Equal Jitter保证至少等待一半的指数延迟，再叠加随机。它牺牲了一部分打散效果，换取更稳定的最小等待时间。适合"不希望重试过快、但又需要打散"的场景。

4.3 Decorrelated Jitter（去相关抖动）

delay = min(cap, random(base, prev_delay × 3))

去相关抖动让下一次延迟依赖上一次延迟，形成随机游走。它在AWS仿真中表现接近Full Jitter，且延迟分布更平滑。本文评述：Decorrelated Jitter的"记忆性"在长连接、长会话场景下更友好，因为它避免了Full Jitter偶尔出现的"连续快速重试"。

4.4 三种抖动对比

策略	公式	打散强度	适用场景
Full Jitter	rand(0, exp)	最强	高并发、限流场景
Equal Jitter	exp/2+rand(0,exp/2)	中等	需保证最小等待
Decorrelated	rand(base, prev×3)	强且平滑	长会话、流式

本文评述：抖动策略的选择不应只看"平均表现"，而要看尾部行为。Full Jitter的P99完成时间可能优于Equal Jitter，但Equal Jitter的P50更稳定。对延迟敏感的在线服务，Equal或Decorrelated更合适；对吞吐敏感的批处理，Full Jitter更优。

五、大模型场景的特殊性

把通用退避策略直接套到大模型调用上，会踩到几个特有的坑。这一章逐一拆解。

5.1 流式响应：重试的代价不对称

非流式请求失败，重试就是重新发一次，代价是延迟和token。流式请求（SSE）失败可能发生在生成中途——已经吐出了500个token，此时连接断开。如果整体重试，用户会看到内容"重头再来"，体验极差；而且已经消耗的token无法退回。

工程上的处理路径有三条：

• 断点续传：若服务端支持，携带已生成内容作为上下文继续。但多数大模型API不原生支持，需要应用层拼接。
• 整体重生成：适用于短输出。需在UI层做"重新生成"提示，而非静默重试。
• 降级为缓冲：先非流式获取完整结果再分块推送，牺牲首token延迟换取重试可控性。

本文评述：流式场景下，重试决策必须考虑"已消费的延迟预算"。如果用户已经等了3秒看到部分内容，再静默重试5秒，总延迟8秒可能已超出SLO。此时更合理的是提示用户或降级模型，而非硬重试。

5.2 Agent多步调用：重试的乘法效应

一个Agent任务可能包含10步工具调用+模型推理。若每步独立重试3次，最坏情况下总调用次数放大到30次。更麻烦的是，中间步骤的重试可能导致状态不一致——比如"下单"工具已执行成功但响应超时，重试会重复下单。

这要求Agent框架把重试与幂等键（Idempotency Key）绑定。OpenAI、Stripe等API均支持在请求头传入幂等键，服务端据此去重（来源：Stripe API Docs, "Idempotent requests"；OpenAI API Reference中关于请求ID与重试的说明）。本文评述：Agent场景的重试设计，本质是分布式事务问题——每一步都要可重放且幂等，否则退避策略再优雅也无济于事。

5.3 多供应商路由

很多生产系统同时接入多家大模型供应商，做故障转移。此时重试策略要分层：

• 同供应商内：指数退避+抖动，处理瞬时抖动。
• 跨供应商：快速切换，避免在单一供应商上耗尽失败预算。
• 全局：设置总超时，防止跨供应商重试累积过长延迟。

本文评述：多供应商路由把"重试"升级为"路由决策"。当某供应商持续失败，应触发熔断（Circuit Breaker）而非继续退避。熔断与退避是互补的：退避处理短暂失败，熔断处理持续故障。Netflix Hystrix与Resilience4j等库提供了成熟实现（来源：Resilience4j官方文档；Netflix Hystrix Wiki）。

六、可落地实现路径

理论讲完，给出可直接用的实现。以下代码为笔者基于通用实践编写，非引用特定库。

6.1 Python：带抖动的重试装饰器

import random, time, functools

RETRYABLE = {429, 500, 502, 503, 504}

def retry_with_backoff(
    max_retries=5, base=0.5, cap=30.0,
    jitter="full", retry_on=RETRYABLE
):
    def decorator(fn):
        @functools.wraps(fn)
        def wrapper(*args, **kwargs):
            attempt = 0
            while True:
                try:
                    return fn(*args, **kwargs)
                except Exception as e:
                    status = getattr(e, "status_code", None)
                    if status not in retry_on or attempt >= max_retries:
                        raise
                    exp = min(cap, base * (2 ** attempt))
                    if jitter == "full":
                        delay = random.uniform(0, exp)
                    elif jitter == "equal":
                        delay = exp / 2 + random.uniform(0, exp / 2)
                    else:  # decorrelated
                        prev = kwargs.get("_prev_delay", base)
                        delay = min(cap, random.uniform(base, prev * 3))
                        kwargs["_prev_delay"] = delay
                    # 尊重服务端 Retry-After
                    ra = getattr(e, "retry_after", None)
                    if ra:
                        delay = max(delay, float(ra))
                    time.sleep(delay)
                    attempt += 1
        return wrapper
    return decorator

关键点：尊重Retry-After头。当服务端明确告知"X秒后再试"，客户端应服从，而不是用自己的退避覆盖。这在与大模型API交互时尤为重要，因为服务端通常比客户端更清楚配额恢复时间。

6.2 Go：带上下文的退避

func DoWithBackoff(ctx context.Context, fn func() error) error {
    const (
        base = 500 * time.Millisecond
        cap  = 30 * time.Second
        max  = 5
    )
    var err error
    for attempt := 0; attempt <= max; attempt++ {
        if err = fn(); err == nil {
            return nil
        }
        if !isRetryable(err) {
            return err
        }
        exp := time.Duration(float64(base) * math.Pow(2, float64(attempt)))
        if exp > cap {
            exp = cap
        }
        delay := time.Duration(rand.Int63n(int64(exp)))
        select {
        case <-ctx.Done():
            return ctx.Err()
        case <-time.After(delay):
        }
    }
    return err
}

Go版本用select监听context，确保请求被取消时立即退出，不浪费失败预算。本文评述：context取消是Go重试实现中最容易被忽略的一环，很多实现用time.Sleep导致取消后仍阻塞。

6.3 参数选择速查

参数	推荐值	说明
base	0.2~1s	在线服务取小值
cap	10~60s	不超过用户SLO的1/3
max_retries	3~5	结合失败预算动态调整
jitter	full / decorrelated	高并发优先full
总超时	必设	防止累积延迟失控

七、重试风暴与雪崩防护

退避+抖动解决了"同步重试"问题，但还有更深的防护要做。

7.1 重试预算（Retry Budget）

Google SRE与Envoy等系统引入了重试预算：限制重试请求占总请求的比例（如10%）。当重试比例超限，新的重试被拒绝，直接返回失败。这防止了在服务端全面故障时，客户端重试把负载放大数倍。

Envoy的重试实现支持retry_budget配置，可设置min_retry_concurrency与budget_percent（来源：Envoy Proxy官方文档，Retry Budget章节）。本文评述：重试预算是失败预算最直接的工程落地，建议在网关层统一实施，而非散落在各业务代码里。

7.2 熔断与半开

熔断器三态（关闭/打开/半开）是持续故障的标准应对。当失败率超过阈值，熔断器打开，直接快速失败，不再消耗失败预算；经过冷却期进入半开，放少量请求探测恢复情况。

本文评述：退避与熔断的边界在于"故障持续时间"。短暂抖动（秒级）用退避；持续故障（分钟级）用熔断。两者配合，才能在失败预算约束下做出最优决策。

7.3 队列与背压

当上游失败率上升，与其无限重试，不如用队列缓冲+背压。请求进入队列，消费者按服务端实际容量拉取，天然实现了速率匹配。Kafka、RabbitMQ等消息队列配合死信队列（DLQ），可以把"重试"从同步阻塞变成异步处理，极大缓解失败预算压力。

八、幂等、去重与流式重试

8.1 幂等键的设计

幂等键应满足：全局唯一、与业务语义绑定、在重试间保持不变。常见做法是UUID+业务ID组合。对于大模型调用，幂等键可基于"会话ID+消息序号+模型版本"生成。

本文评述：幂等键的粒度决定了重试的安全性。粒度过粗（如整个会话一个键），会导致不同请求被误判为重复；粒度过细（如每次随机生成），则失去去重意义。

8.2 流式重试的工程方案

针对SSE流式中断，一个可行方案是"分段确认"：客户端记录已接收的token数与最后一个完整句子，重连时携带这些信息，服务端从断点继续。但多数大模型API不支持，因此更现实的是应用层做"结果缓存+重生成"。

本文评述：流式重试是当前大模型工程的一个开放问题。随着推理服务框架（如vLLM、TGI）对连续批处理与断点续传的支持增强，未来可能出现原生流式续传能力。

九、可观测性与参数调优

没有度量就没有优化。重试策略必须配套可观测性。

9.1 必埋的指标

• 重试率：重试请求/总请求，反映失败预算消耗速度。
• 重试成功率：重试后成功的比例，衡量退避有效性。
• 重试延迟分布：P50/P95/P99，判断是否超出SLO。
• 按错误码的重试分布：识别不可重试错误被误重试。
• 失败预算消耗率：自定义指标，接近上限时告警。

9.2 参数调优方法

推荐用A/B测试或影子流量对比不同退避参数。核心指标是"单位失败预算下的成功率"。本文评述：调优不应追求"最高重试成功率"，而应追求"最优失败预算效率"——有时降低重试次数反而提升整体可用性，因为省下的预算给了更值得的请求。

十、前沿研究与未来预判

10.1 自适应退避

固定参数的退避无法适应动态负载。自适应退避根据实时失败率、延迟、配额动态调整base与cap。学术上，AIMD（加性增乘性减）思想被引入重试控制，与TCP拥塞控制同源。本文评述：自适应退避是把"失败预算"从静态配置变为闭环控制，是未来方向，但需警惕震荡。

10.2 学习型重试

用强化学习或bandit算法决定"是否重试、等多久"。近期有研究将重试决策建模为多臂老虎机问题，在探索与利用间平衡（来源：相关分布式系统与MLSys会议论文，2022-2024）。本文评述：学习型重试的挑战在于样本效率与可解释性，短期内更适合离线调参而非在线决策。

10.3 服务端协同退避

服务端通过Retry-After、配额头等信号引导客户端退避，比客户端单方面猜测更高效。gRPC、HTTP/2的GOAWAY帧也用于优雅关闭与重连引导。本文评述：未来的重试协议应是"服务端主导、客户端配合"，把失败预算的分配权交给最了解全局状态的一方。

十一、工程检查清单

拓展学习资源

• AWS Architecture Blog, "Exponential Backoff And Jitter"：https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/
• Google SRE Book, "Handling Overload"：https://sre.google/sre-book/handling-overload/
• Envoy Retry Budget文档：https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/router_filter
• Resilience4j官方文档：https://resilience4j.readme.io/
• Stripe幂等请求文档：https://stripe.com/docs/api/idempotent_requests