核心要点#

• 标准 API 服务等级不等于可用性承诺。 OpenAI 和 Anthropic 都没有在标准 API 档位提供 SLA；Anthropic 将其称为“尽力提供可用性”。两家的高级档位，正是为了在容量不足时优先保障流量。
• HTTP 200 并不保证调用成功。 Anthropic 流式传输中途的 overloaded_error、OpenAI Fast 模式的静默降级，以及流式传输中途的拒绝，都可能出现在 200 响应中。只看状态码的熔断器会漏掉它们。
• 重试只放在一层。 两家的官方 Go SDK 默认都已重试两次；额外叠加重试循环会让请求次数相乘。让熔断器观察 SDK 重试之后的最终失败。
• 回退顺序优先保持行为一致。 先选择其他云平台上的同一个模型，再考虑不同模型。更换模型会改变产品的实际表现。
• 降级方式要提前做产品决策。 缓存、排队、切换小模型，或明确关闭功能，都应在故障发生前定下来，不能等到凌晨两点状态页一片红时再临场发挥。

2024 年 12 月 11 日，OpenAI API 在太平洋时间下午 3:16 出现故障，服务受损持续了四个多小时：一次遥测系统发布压垮了其最大集群中的 Kubernetes 控制平面，进而破坏了数据平面的 DNS；DNS 缓存又在最初二十分钟掩盖了影响范围。[1]

所有依赖该 API 的聊天功能、智能体工作流和信息抽取流水线，都随之失效。重试循环撑不过四小时的故障，预案才可以。

TIP

先建立三层防线
熔断器识别 LLM 特有的失败信号 → 回退链按“其他平台的同一模型 → 不同模型 → 不使用模型”切换 → 降级模式兜底用户体验。恢复时还要用重试预算与随机抖动控制队列释放速度，避免服务刚恢复就再次被流量压垮。

01 · 决策表：根据失败信号路由#

下面的信号都有服务商文档依据。[2–5] 对所有错误、在所有层级都重试，只会把服务商糟糕的一小时变成你自己的事故。

429 的例外： OpenAI 折扣版 Flex 档位会用 429 表示容量不足。文档给出的处理方式，是以 service_tier: "auto" 重新提交；失败的 Flex 尝试不收费。[6]

02 · 故障记录是公开的#

两家服务商都没有把故障当成假设。按原文引用的 OpenAI 状态页统计，2026 年 5 月至 8 月 API 汇总可用率为 99.94%，折算成每月大约 26 分钟不可用；这些时间集中出现，不会均匀分布。[7] 2024 年 12 月的事故有完整的公开复盘；2025 年 6 月的一次错误率升高事件持续约十五小时，却没有公开披露根因。[1][8] 截至 2026 年 8 月中旬，Anthropic 状态页在此前三个半星期中记录了 25 起事件，并提供机器可读的状态接口。[9]

更深层的信号藏在定价页中。Anthropic 将标准档位描述为“尽力提供可用性”；Priority Tier 的目的，是“即使在高峰期，也尽量减少服务器过载错误”，其可用性目标为 99.5%。[10] OpenAI 则通过 Scale Tier 向企业客户提供 99.9% 可用性的 SLA。[11]

高级产品把“过载时优先分配容量”作为卖点，本身就在说明：对于你很可能正在使用的普通档位，过载是正常运行中需要考虑的情况。

LLM 服务商与其他依赖的区别在于故障相关性。数据库故障转移可能影响某一个服务；LLM 服务商性能下降时，跨多个服务的所有 AI 功能可能同时失败，而且你无法切到自己掌控的副本。故障域覆盖的是整个能力，这必须由你的错误预算承受。

还要保持克制：2025 年 9 月，Anthropic 复盘了三个叠加的基础设施缺陷，它们导致持续数周的回答质量下降，而非可用性下降。最严重的一小时，16% 的 Sonnet 4 请求受到影响。[12] 这些请求全部返回了 200。

WARNING

熔断器能观察错误和延迟，却无法判断答案是否正确。 回答质量问题属于输出评测的职责范围，这也限定了本文这些模式能够提供的保障。

03 · “不可用”究竟是什么样子#

1
event: error
2
data: {"type": "error", "error": {"type": "overloaded_error", "message": "Overloaded"}}

04 · 能理解 LLM 调用的熔断器#

教科书里的三种状态仍然适用：关闭（closed）→ 打开（open）→ 半开（half-open）。不过，有四点需要重新考虑。

对于 sony/gobreaker v2，分类工作由 IsSuccessful 钩子完成，其余都是配置。原文给出的配置说明为：打开保持 60 秒、连续五次失败触发熔断、半开允许一次探测。[19] 下列 Provider、CompletionRequest、APIError 等类型，以及 Prometheus 指标注册，来自前篇的服务商抽象层。

1
import (
2
    "context"
3
    "errors"
4

5
    "github.com/sony/gobreaker/v2"
6
)
7

8
// 判断错误是否说明服务商出现问题。
9
// 调用方自身的问题不应打开熔断器。
10
func isTripSignal(err error) bool {
11
    var apiErr *APIError
12
    if errors.As(err, &apiErr) {
13
        switch apiErr.StatusCode {
14
        case 500, 502, 503, 504, 529:
15
            return true
16
        case 429:
17
            // 配额、计费或 Flex 容量问题：限流、排队、告警，
18
            // 或切换服务档位重新提交；不作为熔断信号。
19
            return false
20
        }
21
        // 流读取器将中途 SSE 错误转换为
22
        // APIError{StatusCode: 529}，见前文错误分类。
23
        return false
24
    }
25
    // 超时是 LLM 调用能产生的最强故障信号之一。
26
    return errors.Is(err, context.DeadlineExceeded)
27
}
28

29
func newProviderBreaker(name string) *gobreaker.CircuitBreaker[*CompletionResponse] {
30
    return gobreaker.NewCircuitBreaker[*CompletionResponse](gobreaker.Settings{
31
        Name:        name, // 如 "anthropic/claude-sonnet"
32
        MaxRequests: 1,    // 半开时只允许一次付费探测
33
        ReadyToTrip: func(c gobreaker.Counts) bool {
34
            return c.ConsecutiveFailures >= 5
35
        },
36
        IsSuccessful: func(err error) bool {
37
            return err == nil || !isTripSignal(err)
38
        },
39
        OnStateChange: func(name string, from, to gobreaker.State) {
40
            // 对状态迁移发出告警：熔断器打开就是故障告警，
41
            // 往往早于错误率仪表盘反映问题。
42
            breakerState.WithLabelValues(name).Set(float64(to))
43
        },
44
    })
45
}

OnStateChange 并不是装饰。“熔断器 anthropic/claude-sonnet 已打开”才是值班人员真正想要的告警：它在做出熔断决策时触发，并明确指出影响范围。

05 · 回退链：先考虑行为，再考虑成本#

熔断器打开之后，流量需要有地方可去。排序原则是：优先选择对产品行为改变最小的路径。

第一层往往不需要自己额外搭建，服务商已提供相应能力：Anthropic 的 service_tier: "auto" 在有优先容量时使用优先容量，否则自动回落标准档位，并在 usage.service_tier 中报告实际档位。[10] OpenAI 的 Flex 回退机制也采取类似思路。[6]

第二层是团队经常没有充分利用的选项。 同样的 Claude 模型可以通过 Claude API、Amazon Bedrock 和 Google Vertex AI 使用；它们有官方 SDK 支持，Messages API 也几乎相同。[20][21] Bedrock 还通过推理配置文件提供跨区域路由。[22] 你的提示词、输出解析器和评测基线都能保留下来，而第三层无法作出同样的承诺。

这些托管服务的底层系统确实不同，而这恰恰是价值所在：Anthropic 在 2025 年的路由缺陷，最严重时影响了官方 API 上 16% 的 Sonnet 4 请求，但 Bedrock 上的峰值仅为 0.18%。[12] 微软对 Azure OpenAI 的建议也相似：并不自动故障转移，参考架构是在具有熔断能力的网关后建立容量回退链。[23]

第三层看起来是基础设施决策，实质却是产品决策。不同模型会给出不同答案：格式会漂移、拒绝边界会移动，评测套件必须覆盖两个模型，回退才值得信任。要么有意识地采用这一层，要么不要使用。

1
type Target struct {
2
    Name     string // 指标和日志标签，如 "bedrock/claude-sonnet"
3
    Provider Provider
4
    Model    string
5
    Breaker  *gobreaker.CircuitBreaker[*CompletionResponse]
6
}
7

8
type FallbackChain struct {
9
    targets []Target
10
}
11

12
func (c *FallbackChain) Complete(ctx context.Context, req *CompletionRequest) (*CompletionResponse, error) {
13
    var lastErr error
14
    for _, t := range c.targets {
15
        reqCopy := *req
16
        reqCopy.Model = t.Model
17
        resp, err := t.Breaker.Execute(func() (*CompletionResponse, error) {
18
            return t.Provider.Complete(ctx, &reqCopy)
19
        })
20
        if err == nil {
21
            fallbackServes.WithLabelValues(t.Name).Inc()
22
            return resp, nil
23
        }
24
        lastErr = err
25
        // 熔断器已打开时立即返回 gobreaker.ErrOpenState，
26
        // 无需等待超时即可推进到下一个目标。
27
        // 如果调用方已取消或超时，则停止，避免浪费下游容量。
28
        if ctx.Err() != nil {
29
            return nil, ctx.Err()
30
        }
31
    }
32
    return nil, fmt.Errorf("all fallback targets failed: %w", lastErr)
33
}

06 · 降级模式：没有模型响应时，产品还能交付什么#

所有熔断器可能同时打开。接下来发生什么，是产品决策；唯一错误的选择，是在事故中临时决定。

SRE 一书将优雅降级定义为：减少每个请求执行的工作，例如用缓存回答，而非完成全部计算。[15] 对 LLM 功能，可以按成本从低到高建立下面的阶梯。

07 · 什么时候只用一家服务商才是正确选择#

前面的设计都有成本。以下是值得认真考虑的反例。

• 内部工具和批处理流水线未必需要回退链。 如果人可以等一小时，或任务可以今晚执行，一张表加一个定时任务构成的队列，就能吸收整场故障。
• 评测完整性可能比可用性更重要。 如果输出质量受到合同或监管约束，未经评测的备用模型可能比停机风险更大。“可以暂时不可用，但绝不输出错误”是一种合理立场。
• 每增加一跳回退，就增加一个依赖。 它有自己的鉴权、配额和失败方式，也需要自己的熔断器。Hystrix 十年前就明确了这一点：如果回退动作还要发起网络调用，它本身也必须由 command 包装。[27] 三家服务商意味着要维护三套健康的集成，评测矩阵也会扩大。
• 提示词维护工作会成倍增加。 采用第三层，就意味着每次提示词变更都要同时在两个模型上验证，否则其中一套会悄悄失效。

一个熔断器、一个队列和一个功能开关，即使完全不引入第二家服务商，也是一种站得住脚的生产方案。 真正站不住脚的，是把教程中的默认假设直接上线：无限期地相信 client.Complete() 总会返回。

08 · 生产上线检查清单#

• 每个“服务商 × 模型”拥有独立熔断器；5xx、529、超时和流中途错误触发熔断，你自身的配额类 429 不触发。
• 针对熔断器状态变化告警，而不仅监控错误率；打开事件就是事故通知。
• 每次调用都有 context 截止时间；按原文所述，openai-go 没有默认超时，遗漏截止时间可能带来 goroutine 泄漏和账单。
• 只保留一层重试，由 SDK 负责；业务层负责分类、熔断和回退链。
• 流读取器将 SSE 错误事件和拒绝，与 HTTP 失败纳入同一套错误分类。
• 回退顺序有文档、有评测；优先切换到其他平台的同一模型，第三层由产品质量负责人预先认可。
• 同一个幂等键贯穿全部目标；有副作用的调用在业务层去重。
• 成本熔断器覆盖整条回退链，而不只是主路径。
• 每个功能都有明确的降级模式：缓存、队列、小模型或关闭，并通过故障演练验证实际呈现。
• 恢复流量通过重试预算和带抖动的节奏控制释放，避免自己制造第二轮过载。

09 · 常见问题#

延伸阅读与参考资料#

原文还推荐以下主题，可通过原文的 Keep Reading 与 Sources 章节查看：

• Building Resilient Distributed Systems with Go：熔断器内部机制、舱壁隔离，以及慢依赖导致的级联故障。
• LLM API Integration Patterns：服务商抽象、重试、流式背压、token 预算和成本熔断器。
• Idempotency Patterns: Building Retry-Safe Distributed Systems：跨服务商重试为什么需要幂等键，以及队列通知背后的 Outbox 模式。

下面保留正文引用编号对应的资料名称。编号沿用原文，完整链接见原文参考资料列表。