部分模型可免费调用查看免费模型
免费开始

大模型 API 限流、超时、报错怎么处理：重试、降并发、备用模型

作者：LanoX 团队发布 更新 数据截至

LanoX 团队｜文中事实于 2026 年 11 月 3 日（迪拜时间）核对｜以 LanoX 为例，接别家 API 也是同样的思路。

调用失败先别急着重试，先把错误分成 2 类：Key 或参数错了，重试多少次都没用；临时性的服务问题，可以有限次重试。限流（HTTP 429）就降低并发、等一会儿再发；服务异常要给重试设上限，必要时切到已经测过的备用模型。图片和视频任务重发前先查原任务的状态，免得重复创建、重复扣费。

这是 LanoX 首页 FAQ 的意思，原话是：「先查看错误信息，区分密钥或参数问题与暂时性异常。限流时降低并发、延迟重试；服务异常时设置重试次数上限，必要时由应用切换到已验证的备选模型。图片和视频任务重发前先确认原任务状态，避免重复创建任务。」（2026-11-03 核对）

哪些错该重试，哪些不该？

错误类型例子重试吗怎么办
Key 或参数问题Key 填错或已撤销、模型 ID 不对、请求体不合法不重试改好 Key、模型 ID 或请求再发
限流HTTP 429 Too Many Requests等一会儿再试降并发，延迟重试
临时服务异常超时、服务端报错有限次重试设上限；必要时切到测过的备用模型
图片、视频异步任务超时后不知道任务有没有建成先别重发先查任务状态

截至 2026-11-03，LanoX 没有单独的错误码总表，但文档列了要处理的码。视频接口说明里写着：「还需处理 401、402、403/模型权限、404、429 和 5xx 类业务码，不能只看 HTTP 状态。」「调用方必须判断响应体中的 code。」（2026-11-03 核对）所以每次都要看响应体里的 code 和错误信息，不能只看 HTTP 状态码。429 是通用的 HTTP 状态码，MDN 的解释是：「表示在一定的时间内用户发送了太多的请求，即超出了“频次限制”。」（2026-11-03 核对）

撞上 429 以后等多久？

返回里有 Retry-After 首部就照它来。MDN 写明 429 响应「可以提供一个 Retry-After 首部来提示用户需要等待多长时间之后再发送新的请求」，值可以是日期，也可以是秒数，比如 Retry-After: 120（Retry-After 页，2026-11-03 核对）。

没有这个首部，就每失败一次多等一会儿，到固定次数就停。建议的起点是：最多重试 3 次，分别等 1、2、4 秒。这是我们给的建议起点，不是 LanoX 的官方规定，请按自己的应用调整。不管怎么设，都要有硬上限；限流的时候无限重试只会更堵。

自己的限额到底是多少？

别猜，直接问接口。在 LanoX，GET /v1/models 会给你这个 Key 能用的每个模型返回 rpm_limit（每分钟请求数）和 tpm_limit（每分钟 token 数）。文档写的是「仅配置为正整数时返回」，并且「返回内容按 API Key 权限过滤」（2026-11-03 核对）。

文档示例里 rpm_limit 是 60、tpm_limit 是 100000，这只是示例，不是 LanoX 的额度，以你自己 Key 的返回为准。应用的并发设得比它低一些，突发流量就不容易撞线。

什么时候切备用模型？

有限次重试都失败以后再切，而且只切到用真实请求测过的模型。切之前先过一遍：

检查项为什么
备用模型支持你的接口格式GET /v1/models 里的 supported_endpoint_types 会写 chat.completions、responses 或 messages
4 项核心功能测过流式、工具调用、图片输入、结构化输出，不同模型可能不一样
价格能接受看模型与价格
日志记下实际是哪个模型回答的以后对用量、对扣费用得上

换模型以后怎么测功能，见换到 OpenAI 兼容 API（待上线）。

图片、视频的报错为什么要另外处理？

图片、视频一般是异步任务：先创建任务，再查结果。lanox-image-2 文档写的是「创建任务后，通过任务 ID 轮询查询结果」，「建议每隔 2–5 秒轮询一次」（2026-11-03 核对）。任务有 4 种状态：

状态含义是否终态
queued已创建，等待执行否
processing正在处理否
succeeded成功，可读取图片地址是
failed失败，可读取错误信息是

创建任务那一步超时了，也别马上重新建。先拿原来的任务 ID 查一下：还在 queued 或 processing，说明任务还在跑，这时再提交就会多出一个任务。

找客服时要给什么？

给请求时间和请求编号。LanoX 文档 FAQ 02 写的是：「如果记录不一致，保留请求时间和请求编号联系支持，核查具体调用。」（2026-11-03 核对）可以发邮件到 support@lanox.ai，或在联系我们页提交支持工单。

发日志之前先把 Key 遮掉。安全与信任页写着：「排查问题时，也应先遮盖密钥再分享日志。」（2026-11-03 核对）

怎么判断一个 API 稳不稳，够不够上生产？

用自己的真实流量测。安全与信任 FAQ 02 原话：「用真实业务请求测试成功率、响应时间和高并发下的表现，再检查限流、错误信息、用量明细和支持渠道。对生产应用，还要确认服务保障和故障处理约定；一次成功调用或很低的报价，都不足以证明长期稳定。」（2026-11-03 核对）

要书面的可用性承诺，企业合作页写的是「可以在合同范围内约定可用性和响应机制」（2026-11-03 核对）。截至当天，LanoX 公开页面上没有可用性数字。

这篇不适合谁？

  • Codex、Claude Code 客户端里遇到专属报错的。 看 Codex 指南或 Claude Code 指南；本文只讲 2 类通用错误，不讲客户端界面。
  • 一定要一张单独错误码总表的。 截至 2026-11-03 没有单独的错误码总表，文档只写了要处理 401、402、403、404、429 和 5xx 类业务码；要看响应体里的 code 和错误信息，拿不准就找客服。
  • 一定要公开可用性数字的。 可用性只在企业合同里约定。
  • 手上没有测过的备用模型的。 先测 1 个，没测过的备用模型可能出新的问题。

常见问题

429 是什么意思？
一定时间内请求太多。降低并发，等一会儿（有 Retry-After 就照它），有限次重试。
所有报错都要重试吗？
不用。Key 错、模型 ID 错、请求不合法，重试还是一样的错。只重试临时问题，而且要设上限。
图片请求重试会不会扣两次钱？
可能会多建一个任务。先查原任务 ID，每 2–5 秒查一次，直到 succeeded 或 failed。
LanoX 公开限额吗？
限额按 Key 在 GET /v1/models 里返回（rpm_limit、tpm_limit，配置了才有），没有公开的默认数字。

资料来源