为了保障调用稳定性并隔离突发流量，Infistar 会根据客户范围、API Token、模型和模型类型应用当前生效的调用策略。不同模型或企业方案可能具有不同限制；实际命中结果以接口响应头为准。 平台不会把请求放进不透明的长时间队列。达到正式限制时，请求会立即返回 429 Too Many Requests 和建议重试时间；上游供应商临时繁忙时，Infistar 会在安全范围内尝试其它可用供应，所有供应都暂时受限时同样返回明确的 429。

​
限制指标

  • RPM（Requests Per Minute）：持续每分钟请求速率。
  • 突发量（Burst）：允许在很短时间内集中提交的请求数量。
  • 并发数：同一时刻仍在执行的同步、流式或实时请求数量。
  • 输入 / 输出 TPM（Tokens Per Minute）：每分钟允许处理的输入和输出 Token。
  • 活动异步任务：仍未进入成功、失败、取消或过期终态的图片、视频等任务数量。
图片、视频等无法用 Token 准确表达的任务主要使用 RPM、并发和活动任务数量。任务状态查询和结果读取不重复占用生成请求额度，但仍受普通 API 防刷规则保护。

​
429 响应

{
  "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，请前往联系我们，提供出现时间、模型 ID、报错截图和 Request ID。高频业务需要更高并发时，也应先确认实际调用量和目标模型，再沟通对应方案。 其它状态码与基础配置问题请返回常见报错与解决方法。 如果业务需要确定的专属吞吐、独立 Token 策略或更高并发，请通过 联系我们 提供目标模型、峰值 RPM、TPM、并发和预计调用时段。最终限制以双方确认并已经发布的策略为准。