← Volver a las guías

LLM 调用重试、超时与退避：7 个实战技巧

1. 先把超时设短一点，别让请求拖死线程

LLM 调用不是越久越好。对于交互式请求，建议先从 10-30 秒 的总超时开始，视模型和上下文长度再调整。核心原则是：客户端要比用户更早知道失败，才能及时重试或降级。很多团队把超时设成几分钟，结果不是更稳，而是并发被占满、队列堆积、体验变差。

如果你用的是 59API，可以直接走 https://api.59api.com，兼容 Claude Code、Codex 和任何 OpenAI SDK。这样你不需要为不同模型单独改接入逻辑，只要把超时策略放在统一的调用层里即可。

2. 重试只针对“可恢复错误”

不是所有失败都该重试。适合重试的通常是网络抖动、连接超时、429 限流、502/503 这类临时性错误。不适合盲目重试的包括参数错误、鉴权失败、上下文超长、模型不支持的能力。把错误分层，能直接减少无效请求和费用浪费。

• 重试：超时、连接重置、429、5xx
• 不重试：401、403、400、422、上下文过长
• 先修正再发起：参数校验失败、消息格式错误

3. 退避用指数退避，再加随机抖动

LLM 服务在高峰期最怕“重试风暴”。正确做法是用指数退避，例如第一次等 500ms，第二次 1s，第三次 2s，第四次 4s，然后加一点随机抖动，避免所有客户端在同一时刻重新打过来。抖动可以是 0% 到 30% 的随机浮动，简单但有效。

一个实用上限是：最多重试 3 次，总等待时间控制在 5-10 秒 以内。对用户可见的请求，再多通常只是在消耗预算。

4. 区分“请求超时”和“整体超时”

很多实现只设一个 timeout，这不够。你需要同时考虑：

• 连接超时：多久连不上就放弃
• 首字节超时：多久收不到首个响应片段就判定异常
• 整体超时：整个请求最多允许跑多久

流式输出场景尤其重要。模型可能已经开始生成，但中间卡住了。对流式请求，建议对首包和空闲间隔单独设置保护，而不是只看总时长。

5. 给每次重试换一个 request id，日志要能追踪

真正排障时，最有价值的不是“失败了”，而是“第几次失败、在哪个环节失败、消耗了多少 token”。建议你记录每次调用的 request id、重试次数、错误码、模型名、耗时、输入输出 token。这样你才能判断问题到底是模型慢、网络抖，还是某个 prompt 本身把上下文撑爆了。

如果你通过 59API 调 Claude 或 GPT 模型，这种统一 relay 的方式也更容易把日志接到一个地方，减少跨供应商排查成本。

6. 成本敏感时，先重试便宜请求，再升级模型

在多模型策略里，别一上来就把重试堆到最贵模型。可以先用低成本模型做一次快速尝试，失败后再按条件升级，或者先缩短上下文再重试。对于大量自动化任务，便宜、稳定、兼容性好比单次极致输出更重要。59API 的优势就在这里：按量付费、价格低，而且接官方质量模型，不需要接受降级结果。

如果你的团队已经在用 OpenAI SDK 或 Claude Code，接入 59API 的迁移成本通常很低。对预算敏感的项目，这种组合能明显降低试错成本。

7. 把“最终失败”设计成产品动作，不是异常崩溃

即使有重试和退避，LLM 调用也不可能 100% 成功。好的系统会在最终失败时给出明确动作：提示用户稍后重试、自动切换到简化答案、降级到较短上下文、或把任务放进后台队列。别让失败直接变成空白页或报错栈。

最后给一个实用建议：先把默认超时、重试次数、退避上限写成配置项，再按场景微调。这样你可以在不改代码的情况下，快速适配高峰流量或更慢的模型。

结论

LLM 调用的稳定性，不靠“多试几次”，靠的是清晰的超时边界、只重试可恢复错误、指数退避加抖动、完整日志和合理降级。如果你正在找一个低成本、兼容现有 SDK、又能直接接 Claude 和 GPT 的入口，可以试试 59API，注册地址后就能用 https://api.59api.com 开始接入，并顺手拿到推荐返利。

Precios · Docs