调用 AI API 时突然返回 429，多半不是接口坏了，而是撞上了限流。想解决问题，先要分清 QPS、并发和 Token 三种限速分别卡在哪里。

下面这套 AI API 限流解决方案，按“先判断类型、再定位原因、最后落地改造”的顺序展开。文中提到的接口地址、模型名称、错误码含义和限额规则，请始终以你所使用平台的控制台页面与官方文档当前说明为准，因为不同厂商、不同模型、不同账号等级的规则并不相同。

一、先分清三种限速：QPS、并发与 Token

“限流”是一个笼统的说法。实际线上出问题时，往往是三种机制中的某一种先被触发，而它们的表现、触发条件、应对方式完全不同。分不清类型，改参数就是瞎改。

QPS 限速：单位时间内的请求次数

QPS（Queries Per Second）限制的是“每秒能发多少次请求”。典型特征是：短时间内密集发送后开始报错，停几秒又恢复正常，再发又报错，呈现明显的周期性。批量翻译、批量打标、批量生成标题这类任务，最容易先撞上 QPS 这一层。

并发限速：同时在途的请求数

并发限制看的是“同一时刻有多少个请求还没有返回”。它和 QPS 不是一回事：即使你每秒只发 5 次请求，如果每次响应需要 3 秒，同时在途的请求数也可能达到 15 个。长文本生成、推理型模型响应慢，更容易先撞并发墙，而此时 QPS 看上去并不高。

Token 限速：输入输出的总量配额

Token 限速通常按分钟或按天统计输入与输出 Token 总量。它的隐蔽性最强：请求次数不多，但单次请求塞进几万字上下文，一样会超限。典型表现是“请求数明明很低，却依然被拒绝”，或者一批小请求正常、少数长请求必然失败。

判断顺序建议：先看响应状态码与错误信息，再看单位时间的请求次数，然后看在途并发数，最后核对 Token 消耗量。顺序错了，很容易把 Token 超限误判成 QPS 超限，参数改了半天依旧无效。

二、四步排查法：从日志到参数

1. 补全日志字段：记录发起时间、模型名称、请求 ID、状态码、错误信息、输入输出 Token 估算值、响应耗时。没有这些字段，后面全靠猜。
2. 判断错误性质：429、并发超限、配额不足是限流；401、404 是鉴权或路径问题；5xx 通常是服务侧问题，不要和限流混在一起处理。
3. 画出时间分布：把失败请求按秒或按分钟聚合，看是“周期性尖峰型”还是“持续高位型”。前者多为 QPS，后者多为并发或 Token。
4. 单变量复现：固定模型和提示词，先用单线程跑通，再逐步提高并发，观察在第几个请求、第几秒开始失败，这样能大致摸到当前配额边界。

排查阶段可以先用最朴素的方式确认接口本身是否正常。下面的请求只做连通性与响应头观察，模型名称请替换为控制台实际提供的名称：

curl -i https://你的接口地址/v1/chat/completions \ -H "Authorization: Bearer $API_KEY" \ -H "Content-Type: application/json" \ -d '{"model":"以控制台显示为准","messages":[{"role":"user","content":"hi"}]}' # 重点观察：状态码、错误信息、限流相关响应头、响应耗时 # 若返回 429，先确认是次数型、并发型还是配额型限制

第三步容易被忽略的细节

很多团队只统计“失败次数”，不统计“失败与成功的比例分布”。实际上，限流排查更需要关注的是重试带来的二次放大：一次失败触发三次重试，等于在压力最大的时候把请求量又抬高了。建议给重试加上指数退避和随机抖动，并设置明确的重试上限。

三、在多模型中转平台上做限流配置与核对

当项目同时调用多个厂商、多个模型时，限流排查会变得更复杂：每个模型的上限不同，错误码格式也不完全一致。这时使用统一入口的 AI 聚合平台会省不少事。例如在 通联AI中转站 这类平台上，可以用一个 Base URL 接入多家厂商的模型，API Key 与调用入口统一管理，排查时不必在多个控制台之间来回切换。

具体操作上，建议按这个顺序确认：

• 接口地址：以控制台给出的 Base URL 为准，不要沿用旧项目的地址；迁移时先在小流量环境验证。
• 模型名称：以控制台或模型广场展示的名称为准，模型名称写错时返回的报错容易被误认为限流。
• 协议兼容：确认你使用的 SDK 与平台支持的兼容协议一致，避免因请求体格式差异导致异常。
• 配额与用量：在控制台查看余额、调用量与消耗说明，判断是配额耗尽还是瞬时超速。

需要查看模型列表、接入文档或计费说明时，可以直接访问 通联AI中转站官网 对照当前页面信息，再决定压测节奏与重试策略。本文不假设任何具体配额数值，实际限额请以控制台显示为准。

四、常见误区与工程侧缓解手段

误区一：把限流当成故障，直接加大重试

重试是放大器，不是解药。正确的做法是先降速、再退避、最后才考虑扩容配额。没有退避策略的循环重试，会让恢复时间被无限拉长。

误区二：只盯 QPS，忽略 Token 与并发

长文本场景里，Token 往往比次数更早触顶。把超长提示词压缩、把历史对话做摘要、把大任务拆成多个小任务，通常比申请更高配额更立即可行。

可落地的缓解手段

• 客户端做令牌桶限速，把峰值削平，让请求均匀分布。
• 使用有界队列加固定并发数，避免线程池无限膨胀。
• 失败请求进入延迟队列，采用指数退避加随机抖动重试。
• 为不同任务分配不同模型：简单任务走轻量模型，复杂任务才走高能力模型。
• 把限流指标纳入监控，提前预警而不是等业务方投诉。

整体来看，一套完整的 AI API 限流解决方案并不只是“加个重试”。它包含类型判断、日志埋点、并发控制、退避策略和配额核对五个环节。先把错误类型分清楚，再动手改代码，通常比盲目调参高效得多。