# OpenAI 接口报 429 Too Many Requests：限流规则与降速办法 - 源头网

429里带rate\_limit字样的是限流不是没钱：你单位时间打得太快或令牌吞吐太高，先用退避重试和队列把速度降下来，长期不够再去提等级和限额。

## 先和额度不足分清

**现象：**同样是429，有时等一会就好，有时等一天也不好。

**原因：**限流的错误码写的是请求频率超限，过一分钟配额就回来了；额度不足写的是配额问题，是钱包和上限的事，等多久都不会自愈。

**怎么办：**先看报错里的类型字样再动手，是限流就按本文降速，是配额就去查余额和绑卡，两件事不要混治。

## 它同时卡请求数和令牌数

**现象：**每分钟请求数明明不多，还是被限流。

**原因：**限額是双指标的，除了每分钟请求数，还有每分钟令牌数，长提示词加长输出，几次调用就能把令牌那条线打满。

**怎么办：**去限额页面把自己这个模型的两个上限都记下来，估算时用单次平均令牌乘以并发量，两边都留两成余量，不要只盯请求条数。

## 新账号的上限天生低

**现象：**刚接接口，稍微并发一点就满屏429。

**原因：**用量按等级发放，新账号在最低档，每分钟的请求和令牌上限都很小，正常消费和付款记录攒够了才会自动升档。

**怎么办：**起步阶段按低配设计程序，并发先压到个位数，随着真实消费稳定增长再逐步放开，不要第一天就按成品的量级压测。

## 没有退避的重试最伤

**现象：**一次限流之后，报错像雪崩一样越来越多。

**原因：**很多程序一失败就立刻原速重试，多台机器同时重试等于在限流口上继续加压，还会把刚恢复的配额瞬间打空。

**怎么办：**改成指数退避加随机抖动，第一次等一两秒，后面成倍拉长，并给重试设总次数上限；优先读响应头里的剩余量和建议等待时间，按它给的节奏来。

## 给请求排队削峰

**现象：**业务一到高峰时段就必然触发限流。

**原因：**流量是尖峰型的，一秒涌进来的量远超每分钟均摊的上限，平均值看着明明没超。

**怎么办：**在调用前加一层队列和令牌桶，把并发数设成固定值匀速放行，急的请求走实时队列，不急的攒一批延后处理，峰削平了，429自然就少了。

## 从令牌侧省额度

**现象：**请求数压下来了，令牌那条还是先到顶。

**原因：**超长上下文每次全量重发、输出不设上限，令牌消耗比请求数涨得快得多。

**怎么办：**给输出长度设明确上限，长对话只带必要的摘要，重复的前缀内容用缓存，批量又不急的任务走批处理通道，既慢不了大事，还能把实时额度让给前台请求。

## 长期不够就提限额

**现象：**降速和省量都做了，正常业务量还是天天贴着上限跑。

**原因：**这说明是真不够用，不是程序问题，等级和限额需要靠消费记录和申请往上提。

**怎么办：**在限额页面确认当前等级，消费达标会自动升档仍不够的，按页面入口提交提额申请，理由写清业务场景和增长量；等审批期间继续用队列顶住，不要硬闯。

## 常见问答

### 429会持续多久？

按分钟计算的限额滚动恢复，通常几十秒到一分钟就回血，前提是这期间别继续猛打。

### 多建几个密钥轮着用能绕吗？

不能，限额按组织和模型算不按密钥算，轮密钥只会把程序搞复杂，官方也可能判定为规避限额。

### 升档要多久？

看累计消费和付款时长是否达标，以限额页面的等级说明为准，达标后自动生效，不需要人工催。

[全部商品与价格](https://yuantou.one/pricing/)（实时，库存实时）