OpenAI 拆分了限流 429：'slow_down' 和 'server_is_overloaded' 对你的重试策略意味着什么

9 月 2 日，OpenAI 推送了一条看起来很普通的 changelog 更新，但它并不普通。这次改动将原本模糊的单一 HTTP 429 拆成了两种语义截然不同的错误响应——而这个拆分对网关重试逻辑和高负载下的流量路由影响很大。

以前的行为：两个完全不同的问题，共用一个错误码

在这次改动之前，API 调用返回 429 时，你根本不知道到底是触发了速率限制（你的请求速率太快），还是遇到了模型容量饱和（OpenAI 那边暂时过载）。两种情况返回相同的 HTTP 状态码和无差别的错误体。

这迫使大多数重试实现不论根因如何，一律走指数退避。因为超速而降低自身吞吐量？正确。因为 OpenAI 模型推理层短暂过载就降低自身速率，本该按原速重试的？那只会让你慢得不必要，还让工作在队列里积压更久。

实际上，几乎所有开源 AI 网关包装——LiteLLM、OpenAI Python SDK 内置重试、大多数自定义中间件——都在以完全相同的方式处理这两种情况。

拆分后的样子

429 + slow_down 码——你的请求发送速率上升过快。正确的处理方式是退避，并在一段有意义的时间内控制发包速率。如果响应包含 Retry-After 头，至少等待那么久。如果没有，使用指数退避。退避结束后不要立刻回到之前的发包速率——要逐步爬坡。

503 + server_is_overloaded 码——OpenAI 的推理基础设施暂时饱和。这是瞬时的，通常几秒到几分钟内恢复。正确的处理方式是短暂退避，预期重试成功后可以恢复到完整的请求速率。这不是你的流量发得太快。

两种响应都可能包含 Retry-After 头。有的话，这是硬下限——不要提前重试。没有的话，按你的退避曲线走。

现有重试代码中会出什么问题

问题在于，大多数网关重试实现只看 HTTP 状态码。看到 429 就退避，看到 5xx 要么快速失败，要么走和 429 相同的退避逻辑。新的 503 server_is_overloaded 情况需要短暂等待后重试——不是快速失败，也不是长时间限速。

你的重试层现在需要支撑的心智模型：

如果你的客户端目前把所有 429 当成"降速"、把所有 503 当成"失败或和 429 一样处理"，那这次改动之后你同时存在误报和漏报。

Anthropic 和 Google 怎么处理同样的问题——OpenAI 的拆分落在哪里

对比一下：Anthropic 对模型过载使用 529 状态码，在 HTTP 层面就与 429 速率限制完全分开。这更清晰——你的 HTTP 中间件不用解析 body 就能区分。代价是 529 不在 RFC 标准里，会让一些网关软件报警。

Google Gemini API 对配额和容量两种情况都返回 429 ResourceExhausted，但包含结构化的 @type: google.rpc.ErrorInfo body，其中有 reason 字段（RATE_LIMIT_EXCEEDED 或 CONCURRENCY_LIMIT_EXCEEDED）——前提是你能解析 gRPC 风格的错误体，大多数 REST 客户端并不会这样做。

DeepSeek V4 今年引入了峰谷计费，配额和容量限制都发 429 + too_many_requests 码，body 里没有进一步区分。

OpenAI 的新方式——速率限制保留 429，模型饱和升级为带具名 body 码的 503——是一个折中。比全部当 429 更正确，比 Anthropic 的 529 更符合标准，但仍然需要解析 body 才能区分 server_is_overloaded 和真正的 503 服务故障。

路由层的影响

如果你在用 TheRouter 或任何 AI 网关跨提供商路由流量，这改变了你应该在什么时候将某个响应识别为"切换流量"的信号。OpenAI 返回 slow_down 429 意味着你应该放慢发往 OpenAI 的请求。返回 server_is_overloaded 503 意味着 OpenAI 有容量瞬时问题——如果你的延迟预算不够等，这是将请求切到备用提供商的合理信号。

之前，两种情况在你的网关错误日志里看起来一模一样，你被迫选一种解释。现在你可以分开处理：

• slow_down → 遵守速率限制；继续路由到 OpenAI，但降速
• server_is_overloaded → 视情况切换到备用提供商或立即重试队列；不要降低你对 OpenAI 通道的速率配额

现在需要审计什么

1. 检查你的重试库对状态码的处理方式。 如果它对任何 503 都快速失败，那它现在会对 OpenAI 的瞬时容量抖动直接报错而不重试。

2. 检查你是否根本没有解析错误 body。 如果你的代码只看 response.status === 503 就抛异常，你永远不会看到 server_is_overloaded。

3. 如果你有基于 body 错误码的门控逻辑，把 server_is_overloaded 加入可重试条件，和现有 429 重试逻辑并列处理。

4. 在日志里同时记录状态码和错误码。 把"429 rate_limit"、"429 slow_down"、"503 server_is_overloaded"分别聚合，能让你在高负载期间得到清晰得多的问题定位信号。

OpenAI API changelog 把这条列为小更新。实际上，这是这两种情况第一次在 API 层面变得可观测，而在你已经处于高负载的时候，把重试逻辑写对才是最重要的。