Selected model is at capacity 怎么处理

先判断错误来自哪一层

Selected model is at capacity. Please try a different model.

Sub2API 不主动生成这句固定文案。请求经过网关路由后，如果上游返回容量错误，客户端可能直接展示其中的消息；网关仍可能负责账号切换、状态码转换和 Request ID 记录。

五分钟内完成的复测

1. 记录错误发生的 CST 时间、模型、推理等级和 Request ID。
2. 新建空会话，用相同 Key、相同模型发送一个短请求。
3. 等待 2 秒、4 秒、8 秒做最多三次重试，避免并发重试风暴。
4. 用同一 Key 测试另一个已知可用模型，只用于判断范围，不要改写原业务模型。
5. 在平台用量记录中确认失败请求是否到达，以及后续短请求是否成功。

新会话成功而旧会话持续失败时，优先检查旧会话上下文、工具链或客户端状态；所有新请求都失败时，再判断模型容量或唯一可用账号状态。

不同现象对应什么

正确的重试策略

• 只重试临时容量错误、429 和部分 5xx。
• 使用指数退避并加入随机抖动，限制总次数和总时间。
• 同一会话不要同时启动多个自动重试。
• 需要最新模型时保留原模型名，不要静默映射为旧模型。
• 如果业务允许，降低并发比降低推理等级更直接；推理等级影响单次计算量，但不能保证绕过容量限制。

连续失败超过一分钟时，停止客户端高频重试并提交 Request ID。平台可以据此对照账号调度和上游响应。

哪些错误不是容量不足

401 通常是鉴权问题，400 通常是模型名、参数或上下文问题，余额和订阅限制也有独立错误。不要把所有 5xx 都归为“模型爆满”。

长上下文或压缩阶段报 502 时，参考 502 与上下文压缩排查；TTFT 明显变高但请求成功时，参考 首 Token 耗时分析。