大模型API报错排查：429、500、超时、截断与乱码实战指南

关注

VIP免费原创最新推荐文章于 2026-09-23 11:57:16 发布 470 阅读 AI 写同款· GEO 优化 ›

Codex 报错 429 too many requests？一行配置解决限流难题 HTTP 429 是服务端限流的标准响应，代表客户端请求频率超出了配额限制。在 AI 编程工具 Codex 中，由于一次请求可能消耗数千 Token，且自动重试策略有限，极易触发 'exceeded retry limit' 错误。理解限流机制与重试策略，是解决此类问题的基础。实际排查发现，大多数 429 并非网络问题，而是模型配置与接入点不匹配导致的路由失败。通过调整 config.toml 中的 model 与 model_provider 参数，对齐第三方兼容服务的 wire_api 类型，即可有效绕阅读详情

上周帮同事排查了一个线上问题，日志里全是一模一样的报错： exceeded retry limit, last status: 429 too many requests, request id: xxxx 。客户端在疯狂重试，服务端在拼命限流，两边都觉得自己没错，最后发现是调用方把重试策略写成了固定间隔 1 秒，一并发上来直接把模型服务打到限流阈值。这种事在接入大模型接口时太常见了。

做 AI 应用开发这两年，我几乎把大模型接口的报错都踩了一遍：429、500、超时、上下文截断、流式乱码。这几个问题看着简单，实际上每一条背后都藏着一堆细节，排查起来非常容易走弯路。这篇文章我把自己的排查思路整理出来，尤其是那些日志里不会直接告诉你的坑，按错误类型拆开讲，适合正在接大模型 API、做 Agent 应用、或者自己部署推理服务的开发者参考。

1. 五种报错的共同底层逻辑，先理清再动手

1.1 报错是症状，不是病因

很多人一看到 429 就以为是并发太高，一看到 500 就跑去问服务商，看到超时就想着调大 timeout。这些动作不能说错，但如果只盯着状态码和报错文案，很容易把问题带偏。

大模型接口调用链路是很长的：你的业务服务 → API 网关（如果用了）→ 推理服务 → 模型加载与计算 → token 生成 → 流式返回。任何一个环节出问题，最终到客户端可能都表现为同一个状态码。比如 500 可能是推理进程崩溃，也可能是网关的 Web 框架在处理某个请求格式时报错，还可能是上游数据库或鉴权服务抽风。同样是 500，排查方向完全不同。

所以我现在的习惯是：拿到一条报错，先不急着改代码，而是先确认“这个错误是哪个环节报出来的”。状态码是服务端给客户端的最终答复，但只有把这条答复还原到完整链路上，才能找到真正的病根。

1.2 一套通用的排查顺序

接触过的项目多了，我总结出一套比较通用的排查顺序，不管什么报错都先按这个走一遍：

第一梯队：看客户端日志里的完整 request id 或 trace id，这是关联服务端日志的唯一线索。
第二梯队：确认请求是否真的到了服务端。很多所谓“超时”，其实请求根本没发出去。
第三梯队：看服务端日志。自己部署的看 inference server 日志，用云厂商的看控制台监控。
第四梯队：复现现场，减小请求体、关掉流式、换短文本，逐步逼近最小复现。

这套顺序看起来很笨，但效率其实最高。因为大模型接口的报错经常是组合因素造成的，比如上下文太长导致推理变慢，推理变慢导致读超时，客户端重试又触发限流，最后你看到的可能是三种报错混在一起。先把层级分清楚，后面才好拆解。

2. 429：限流不是洪水猛兽，是保护机制在报警

2.1 429 背后的三段限流策略

429 全称是 Too Many Requests，含义是服务端不想处理你这个请求，原因是你来得太频繁或者太多，触发了限流。大模型接口的限流一般有三层：

账号维度限流：比如按每分钟请求数限制，或者按每分钟 token 数限制。这在 OpenAI、Anthropic 等云厂商 API 上最常见。
推理服务实例维度限流：自己部署 vLLM、llama-server、TGI 这类服务时，如果 qps 超过服务配置的最大并发，也会返回 429。
网关维度限流：在 API 网关统一配置了 rate limit，防止某个调用方把后端打爆。

关键点在于，你看到的 exceeded retry limit, last status: 429 too many requests 这种报错，通常已经是客户端 SDK 在经历多次 429 重试都失败之后抛出的最终错误。也就是说，429 本身不是最可怕的，最可怕的是你的重试逻辑在 429 面前变成了“放大器”，把限流越撞越死。

2.2 排查 429 时一定要看的几个字段

遇到 429，先别急着调大并发。我建议优先做这四步：

看响应头。云厂商 API 一般在返回 429 时会带上 Retry-After 、 x-ratelimit-limit 、 x-ratelimit-remaining 、 x-ratelimit-reset 这些字段。 Retry-After 告诉你多少秒后重试， x-ratelimit-remaining 告诉你额度还剩多少。
看错误信息里有没有 request id。有 request id 才能去服务端查日志，判断是账号维度限流还是服务端实例限流。
确认是单机超限还是全局超限。如果是多实例部署的客户端，单机 qps 不高，但集中打过来也可能触发限流，这时候要看总的并发曲线。
确认触发的是 token 限流还是请求限流。很多大模型 API 的限流是按 token 算的，你请求体里塞了很长的历史记录，一次请求可能抵好几次普通请求。