---
title: 429 与调用频率
description: 识别 429 的常见原因，降低连续请求和并发，并为自动程序配置有上限的退避重试。
---

为了保障调用稳定性并隔离突发流量，Infistar 会根据客户范围、API Token、模型和模型类型应用当前生效的调用策略。不同模型或企业方案可能具有不同限制；实际命中结果以接口响应头为准。

平台不会把请求放进不透明的长时间队列。达到正式限制时，请求会立即返回 `429 Too Many Requests` 和建议重试时间；上游供应商临时繁忙时，Infistar 会在安全范围内尝试其它可用供应，所有供应都暂时受限时同样返回明确的 429。

## 限制指标

- **RPM（Requests Per Minute）**：持续每分钟请求速率。
- **突发量（Burst）**：允许在很短时间内集中提交的请求数量。
- **并发数**：同一时刻仍在执行的同步、流式或实时请求数量。
- **输入 / 输出 TPM（Tokens Per Minute）**：每分钟允许处理的输入和输出 Token。
- **活动异步任务**：仍未进入成功、失败、取消或过期终态的图片、视频等任务数量。

图片、视频等无法用 Token 准确表达的任务主要使用 RPM、并发和活动任务数量。任务状态查询和结果读取不重复占用生成请求额度，但仍受普通 API 防刷规则保护。

## 429 响应

```json
{
  "error": {
    "message": "模型 gpt-5.6-sol 触发 rpm 限流，请在 10 秒后重试",
    "type": "new_api_error",
    "code": "rate_limit_exceeded"
  }
}
```

响应可能包含：

- `Retry-After`：建议等待的秒数。
- `x-ratelimit-limit-requests`：当前请求速率上限。
- `x-ratelimit-remaining-requests`：当前可用请求数量。
- `x-ratelimit-reset-requests`：下一次可用额度预计恢复时间。
- 对并发和 Token 指标，对应返回 `concurrent-requests`、`input-tokens` 或 `output-tokens` 后缀。

这些字段只解释客户侧调用限制，不会暴露内部供应商、渠道、账号或采购额度。

## 客户端处理建议

1. 收到 429 后优先遵循 `Retry-After`，不要立即循环重试。
2. 没有 `Retry-After` 时使用带随机抖动的指数退避，例如 1、2、4、8 秒。
3. 流式或实时请求结束后及时关闭连接，避免继续占用并发。
4. 批处理任务应控制本地工作队列和最大并发，不要一次创建大量线程。
5. 同一业务使用多个 Token 并不一定增加额度；策略可能按用户共享，也可能按 Token 独立。

## 仍然频繁出现

如果单个请求也持续返回 429，请前往[联系我们](/contact-feedback/contact-feedback)，提供出现时间、模型 ID、报错截图和 Request ID。高频业务需要更高并发时，也应先确认实际调用量和目标模型，再沟通对应方案。

其它状态码与基础配置问题请返回[常见报错与解决方法](/troubleshooting/http-status-troubleshooting)。

如果业务需要确定的专属吞吐、独立 Token 策略或更高并发，请通过 [联系我们](/contact-feedback/contact-feedback) 提供目标模型、峰值 RPM、TPM、并发和预计调用时段。最终限制以双方确认并已经发布的策略为准。