Rate Limits
限流
保护平台、保护你账户的双重防线。下面讲清楚默认上限、超限怎么处理、需要更高额度怎么联系。
默认配额
| 维度 | 起步 | 充值后 | 企业 |
|---|---|---|---|
| RPM（每分钟请求数） | 60 | 600 | 协商 |
| TPM（每分钟 tokens） | 40k | 400k | 协商 |
| 并发数 | 5 | 50 | 协商 |
| 视频生成并发任务 | 2 | 10 | 协商 |
充值即提额
首次充值 ¥10 立即升到「充值后」档位，无需申请。
响应 Header
每次成功响应都会附带配额信息：
httpHTTP/1.1 200 OK X-RateLimit-Limit-Requests: 600 X-RateLimit-Remaining-Requests: 587 X-RateLimit-Reset-Requests: 38s X-RateLimit-Limit-Tokens: 400000 X-RateLimit-Remaining-Tokens: 389234 X-RateLimit-Reset-Tokens: 12s
触发限流时返回 429，并附 Retry-After：
httpHTTP/1.1 429 Too Many Requests Retry-After: 12 { "error": { "type": "rate_limit_error", "code": "rate_limit_exceeded", "message": "Rate limit reached. Please retry after 12s." } }
如何处理 429
- **优先**：读
Retry-After，按它说的秒数等。 - **没有该头**：用指数退避
1s → 2s → 4s，加 ±20% 抖动。 - **别砸**：千万别在 catch 里立即重试——只会让 429 持续更久。
- **预防**：客户端侧设置自己的并发上限，比平台配额低 20%，避开瓶颈。
- **水平扩展**：把流量分散到多个 API Key，每把 Key 共享同一配额——所以**这不会绕过限流**，但便于审计哪个 Key 用得最猛。
企业提额
预期 RPM > 1000、TPM > 1M、或并发 > 100 的工作负载，请直接发邮件到 [email protected]，告诉我们：
- 预期峰值 RPM/TPM 是多少
- 主要用什么模型（不同模型有不同上游配额）
- 是否需要专线 / 私有部署 / SLA 99.95%+
通常 1 个工作日内回复方案。