LLM 调用的限流与重试：别让失败风暴扩大

AI API 调用失败很常见：网络抖动、超时、限流、上游错误、输出解析失败。可靠系统不能简单 while retry，否则可能把小故障放大成请求风暴。

OpenAI 错误码和限流相关文档说明了 API 错误处理与速率限制的存在，工程上需要配合重试和退避。[retry-001][retry-002]

先区分失败类型

• 解析失败：可能需要重新生成或走修复逻辑。
• 超时：可以重试，但要限制次数。
• 限流：应指数退避。
• 认证失败：不要重试。
• 工具副作用失败：先确认是否已经执行。

重试不是默认答案，幂等性和退避策略才是可靠性的基础。

概念策略：

{
  "max_retries": 3,
  "backoff": "exponential",
  "retry_on": ["timeout", "rate_limit", "server_error"],
  "do_not_retry_on": ["auth_error", "invalid_request"]
}

写操作要有幂等键

如果模型调用后会触发外部动作，重试前必须知道动作是否已经发生。创建订单、发邮件、写数据库都需要幂等键或事务记录。

综合 API 可靠性资料可以推断：AI 调用层应该像支付或消息队列一样设计失败路径，而不是只在 catch 里重试。

参考资料

1. [retry-001] OpenAI Platform, “Error codes”, https://platform.openai.com/docs/guides/error-codes
2. [retry-002] OpenAI Platform, “Rate limits”, https://platform.openai.com/docs/guides/rate-limits