#限流与并发

可用并发和速率可能受到账户、分组、模型、上游 Provider 和实时容量影响，因此文档不提供一个适用于所有模型的固定 RPM/TPM 数字。

#客户端应控制什么

• 并发数：同时进行的请求数量；
• 请求速率：单位时间内新请求数量；
• Token 速率：长上下文和大输出会占用更多容量；
• 队列长度：避免流量高峰直接压垮客户端和上游；
• 重试预算：重试也会产生新流量，必须限制。

#推荐架构

业务请求 → 有界队列 → 并发控制器 → GetRouter
                         ↓
                    退避与重试

从较低并发开始，观察延迟、429、5xx 和使用记录后逐步提高。不要在收到 429 后立即让所有 Worker 同时重试。

#处理 429

1. 检查 Key 是否有余额和剩余额度；
2. 检查是否存在大量并发或失控循环；
3. 降低并发；
4. 使用带抖动的指数退避；
5. 如果响应包含 Retry-After，优先采用；
6. 达到重试上限后返回明确错误，而不是无限等待。

#Agent 与批处理

• 为每个无人值守 Agent 使用独立 Key 和额度；
• 设置单任务最大轮数、最大工具调用次数和总超时；
• 批处理使用有界队列，不一次性启动全部任务；
• 对失败任务设置死信队列或人工复核；
• 监控成本，不要只监控成功率。

#什么时候联系支持

如果在低并发、Key 有余额且请求格式正确的情况下持续收到 429，请准备时间、时区、模型 ID、Endpoint、Request ID 和脱敏后的错误响应。不要发送完整 API Key。