速率限制

平台在多层做速率保护，保证少数用户抖动不影响整体服务。

默认限制（用户级）

项目	默认值	说明
全局 RPS	180 req/s	单账户所有 Key 加起来的每秒请求上限
单 Key 并发	无	但受上游限制
Chat Completion Token/min	依上游	Anthropic / OpenAI 各自的 TPM 会限流

超限触发 429 rate_limit_exceeded。

上游限制会怎么表现

某些上游（尤其官方 Anthropic）对每分钟 tokens 有硬上限。触发时：

• 网关自动切换到下一条渠道（如果分组里还有可用渠道）
• 如果所有渠道都被限，才返回 429 给客户端

所以业务上遇到 429 的概率比直连官方低很多——多渠道冗余就是干这个的。

客户端重试策略建议

import time, random, requests

def with_retry(url, headers, json, max_attempts=5):
    for attempt in range(max_attempts):
        r = requests.post(url, headers=headers, json=json, timeout=180)
        if r.status_code < 500 and r.status_code != 429:
            return r
        wait = min(2 ** attempt + random.random(), 30)
        time.sleep(wait)
    return r  # 用尽次数返回最后一次响应

关键点：

• 只对 429 / 5xx 重试，别对 4xx 重试（你 Key 错就是错，重试没意义）
• 指数退避 + 抖动 (jitter) 防止群体同步重试
• 总上限 5 次足够，再多是网关问题
• 每次重试用同一个 request_id 或加 retry_count header，方便排查

需要更高限制？

联系管理员申请账号级配额提升。一般会问：

1. 应用场景（多少 QPS、平均什么模型）
2. 预付额度（用来支撑更高吞吐）
3. IP 段（用于给你的 Key 单独放高上限）

普通用户 180 RPS 已经够绝大部分业务。真到需要突破的量级（几百 QPS），可能需要走专线 / SLA 定制方案。