← सभी गाइड पर लौटें

LLM API调用实战：重试、超时与退避策略指南

为什么LLM调用需要可靠性策略

调用大语言模型并不总会立即成功。网络短暂抖动、服务限流、上游繁忙、长文本生成超时，都可能让一次请求失败。初学者常见做法是立刻无限重试，但这会放大流量、增加账单，并可能让同一个任务生成多次。可靠的方案应把超时、有限重试和退避等待组合起来，让程序在可恢复错误出现时自动恢复，在不可恢复错误出现时快速停止。

59API提供按量付费的Claude与GPT模型访问，兼容Claude Code、Codex及任意OpenAI SDK，基础地址为https://api.59api.com。对于需要同时控制可用性和预算的应用，使用官方质量模型并配合正确的调用策略，比盲目堆高并发更实际。

第一步：分别设置连接超时和总超时

超时不应只有一个数字。连接超时用于限制建立网络连接的等待时间，通常可设为5至10秒；总超时用于限制整个请求，包括模型排队和生成，短问答可从30秒开始，长上下文、结构化输出或较长回答可设为60至120秒。流式输出场景还应设置读取空闲超时：如果连续一段时间没有收到任何数据，再中止请求。

超时不是模型“回答太慢”就必须缩短的指标。先记录请求模型、输入长度、最大输出量、耗时和结果状态，再按真实分位数调整。若经常超时，可以减少max_tokens、拆分任务、使用更快的模型，或将同步任务改为后台队列。

第二步：只重试可恢复错误

适合重试的通常是网络连接失败、读取超时、HTTP 429限流，以及500、502、503、504等临时服务错误。对于429，应优先读取服务端返回的Retry-After等待时间。400参数错误、401认证失败、403权限问题和上下文过长等422类错误，重试不会改变结果，应直接记录原因并返回给调用方处理。

建议将最大重试次数设为2至4次，并为每次请求生成唯一请求ID。若业务会写入数据库、扣减额度或触发外部操作，应使用幂等键，避免第一次请求实际成功但客户端未收到响应时，第二次请求造成重复执行。对生成文本任务，可在重试前检查是否已经收到完整结果或有效的流式片段。

第三步：使用指数退避加随机抖动

固定每秒重试一次容易在服务恢复时形成“惊群”。更稳妥的方式是指数退避：第一次失败后等待约1秒，第二次约2秒，第三次约4秒，并设置最大等待上限，例如20秒。在每次等待中加入0到30%的随机抖动，使大量客户端不会同时再次发起请求。

一个实用规则是：等待时间等于基础等待时间乘以2的重试次数，再加入随机值；同时设置总重试时间预算，例如不超过45秒。超过预算后，将任务标记为待恢复或失败，而不是让用户界面一直转圈。交互式产品应尽快提示用户稍后重试；批处理任务则可进入延迟队列。

第四步：把成本和可观测性放进设计

每次重试都可能再次消耗输入和输出额度，因此不要对所有错误自动重试。记录模型名称、HTTP状态、重试次数、首字节耗时、总耗时和token用量，才能判断问题来自客户端网络、请求规模还是上游限流。还可以按模型和接口分别统计失败率，为不同任务设置不同超时与重试预算。

59API支持以较低成本按量调用Claude Opus、Sonnet、Haiku、Fable及GPT模型，适合先从小规模流量验证这些策略，再逐步扩展。注册59API后，可通过统一兼容的SDK配置接入，并利用推荐返利降低持续测试与生产调用的成本。

上线前检查清单

• 为连接、总请求和流式读取分别设置超时。
• 仅对网络错误、429和临时5xx错误重试。
• 限制重试次数、总等待时间，并采用指数退避和随机抖动。
• 为可能产生副作用的请求增加幂等键。
• 记录错误类型、延迟、token和重试结果，持续调整阈值。

मूल्य · दस्तावेज़