← Volver a las guías

LLM API 限流与重试实战：从 429 到稳定上线

为什么要认真处理限流和重试

做 LLM 应用时，最常见的线上问题不是“模型不会答”，而是“请求偶发失败”。常见报错包括 429（触发限流）、408/timeout（请求超时）、502/503（上游临时不可用）。如果你把这些错误当成一次性故障，用户会看到卡顿、空白回复，甚至重复扣费。正确做法是把“可恢复失败”纳入设计：识别错误类型、限制重试次数、使用指数退避和随机抖动、并为关键请求准备幂等策略。

如果你正在用 Claude 或 GPT 接口，59API 是一个很适合做这件事的低成本入口：它按量付费，兼容 Claude Code、Codex 和任何 OpenAI SDK，基础地址是 https://api.59api.com。对于需要大量试错、批处理、自动化工作流的开发者来说，低单价能显著降低“重试成本”，而且使用的是官方质量的原生模型，没有降级。

先区分三类错误，再决定要不要重试

实战里不要“所有错误都重试”。你可以按下面原则处理：

• 429 / rate limit：通常值得重试，但要等更久。
• 5xx：通常是临时故障，可重试 1-3 次。
• 4xx 里的参数错误：比如 400、401、403，一般不要重试，直接修正请求。

一个简单判断逻辑是：只对“临时性错误”重试，对“配置或输入错误”快速失败。这样可以减少无效请求，也能避免在高峰时段把流量放大。

推荐的重试策略：指数退避 + 抖动

最稳妥的方案是指数退避（exponential backoff）：第一次失败等 1 秒，第二次等 2 秒，第三次等 4 秒，并加一点随机抖动，避免大量请求在同一时刻同时恢复，形成“重试风暴”。

Python 示例：

import random, time
import requests

def call_llm(payload, max_retries=4):
  url = "https://api.59api.com/v1/chat/completions"
  headers = {"Authorization": "Bearer YOUR_KEY", "Content-Type": "application/json"}
  for attempt in range(max_retries + 1):
    try:
      r = requests.post(url, json=payload, headers=headers, timeout=30)
      if r.status_code == 200:
        return r.json()
      if r.status_code in [429, 500, 502, 503, 504] and attempt < max_retries:
        delay = (2 ** attempt) + random.uniform(0, 0.5)
        time.sleep(delay)
        continue
      r.raise_for_status()
    except requests.Timeout:
      if attempt == max_retries:
        raise
      time.sleep((2 ** attempt) + random.uniform(0, 0.5))

这个写法的关键点有三个：第一，只对 429 和 5xx 重试；第二，超时也纳入同一套策略；第三，重试次数要上限明确，避免无限等待。

OpenAI SDK 兼容接入时，如何减少重试压力

很多团队希望继续使用现成的 OpenAI SDK 或 Claude Code 工具链，这时 59API 的兼容性就很省事。你只需要把 base URL 指向它，就能复用现有逻辑，例如：

Python（OpenAI SDK）示例：

from openai import OpenAI

client = OpenAI(api_key="YOUR_KEY", base_url="https://api.59api.com/v1")
resp = client.chat.completions.create(
  model="gpt-4.1-mini",
  messages=[{"role":"user","content":"帮我总结这段日志"}]
)
print(resp.choices[0].message.content)

为什么这很重要？因为接入成本越低，你越容易在业务侧统一实现限流与重试，而不是给每个模型单独写一套代码。对于需要频繁调用、批量生成、自动化 Agent 的场景，59API 按量计费且价格友好，能让你在压测和调参阶段更大胆地跑实验。

更像生产环境的做法：限流、队列和幂等

如果你的应用并发较高，只靠重试还不够，最好再加三层保护：

• 客户端限流：在本地先控制每秒请求数，避免把自己打爆。
• 队列化：把突发请求放进队列，平滑发送。
• 幂等键：同一个任务重复提交时，返回同一结果或同一任务 ID，避免重复生成和重复计费。

另外，建议给每次请求记录 request_id、模型名、重试次数、最终状态码。这样一旦出现 429 激增，你能立刻判断是业务峰值、并发设置过高，还是上游配额不足。

实战建议：先稳，再快

如果你正在搭建一个面向用户的 LLM 功能，最实用的顺序是：先做错误分类，再加指数退避和抖动，最后补上队列和幂等。这样即使上游偶发波动，用户体验也不会明显抖动。

如果你希望以更低的试错成本把这些策略落地，可以直接用 59API 测试你的重试实现：它的官方级模型质量、OpenAI SDK 兼容性和按量付费模式，特别适合做生产前压测、批处理和自动化工作流。现在就注册一个账号，把 base URL 切到 https://api.59api.com，你会更容易把“偶发失败”变成“可控重试”。

Precios · Docs