Selected model is at capacity”报错：原因与处理

正在处理任务时，界面突然提示 Selected model is at capacity. Please try a different model.，第一反应往往是被风控、封号或订阅降级。尤其是付费较高的套餐用户，看到 capacity 很容易联想到自己被打上标记。其实这句话的意思很直接：当前选择的模型容量已满，建议换一个模型。它描述的是服务端某个模型的可用算力，不是对账号身份的判决。

这类报错常常集中出现：同一时间段内，不同套餐、不同地区的用户都遇到；换账号未必消失，过一阵又恢复。多数情况下，等容量恢复或改用非热门模型即可。下面按“先判断、再处理、后预防”的顺序说明。

先分清：容量不足、限流和账号问题

不同客户端对错误的包装不一样，不要只看一句提示就下结论。把 HTTP 状态码、响应体和发生时间一起记录下来，判断会准确得多。

如果错误里明确写了模型名和 capacity，优先按模型容量处理；如果所有模型都报错，再怀疑整体服务故障或本地网络。

常见原因

1. 服务端整体过载。 高峰时段或官方事故期间，容量会优先变得紧张，付费套餐通常也不能保证每个模型随时有空闲算力。
2. 单个模型太热门。 新模型、推理模型或高级模型最容易遇到。客户端默认选中了它，就会反复弹同一条提示。
3. 并发和重试放大问题。 脚本、插件或批量任务同时发很多请求，失败后又立刻重试，会让原本临时的容量问题持续更久。
4. 把额度限制误认为容量不足。 有些客户端会把 429、额度耗尽等错误显示成类似文案，需要看原始响应。
5. 网络抖动导致超时重试。 网络问题通常表现为连接失败、超时或 5xx，一般不直接产生这条 capacity 提示，但会加重重试。

可操作的排查与处理

1. 先查官方状态页

打开 OpenAI 官方状态页，看当前是否有 incident，尤其是与模型可用性、API、ChatGPT 相关的条目。若状态页同时出现事故记录，基本可以确认不是个人账号问题。记录报错时间、模型名、HTTP 状态码和请求 ID，后续排查或联系支持都用得上。

2. 换一个模型做对照

在客户端里切换到另一个模型再试。如果备用模型正常，只有原模型报 capacity，说明是模型级容量问题；如果所有模型都失败，优先等待服务恢复。关键业务流程可以准备一个备用模型，把模型名做成配置，而不是硬编码在代码里。

3. 用退避重试代替连续点击

不要一秒点多次，也不要在脚本里无间隔重试。可以采用指数退避加随机抖动，例如：

import random
import time

for attempt in range(5):
    try:
        result = call_model()
        break
    except CapacityError:
        delay = (2 ** attempt) + random.uniform(0, 1)
        time.sleep(delay)
else:
    fallback_to_another_model()

重试次数要有上限，失败后进入备用模型或队列，避免请求堆积。

4. 降低并发，给任务排队

批量任务把并发降下来，例如从高并发改为个位数并发，并在请求之间加短暂间隔。长任务要保存检查点，失败后从上次进度继续，而不是全部重跑。这样即使遇到短时容量波动，也不会浪费已完成的调用。

5. 再检查账号和订阅状态

如果连续较长时间、多个模型都失败，再检查登录状态、账单、额度和权限。不要在短时间内反复退出登录、切换节点或更换账号，这些动作既不能增加服务端容量，还可能触发额外的安全验证。

6. 需要时联系官方支持

准备好时间、模型、错误码、请求 ID 和复现步骤。只描述“用不了”很难定位；带上完整信息，支持人员才能判断是容量、限流还是账号权限问题。

不建议的做法

• 买卖、共享或租用账号来绕过限制。 这类做法违反服务条款，可能导致账号被封、数据丢失，出了问题也很难申诉。
• 频繁切换代理节点或地区来“绕开”容量限制。 容量在服务端，换出口通常不解决问题，反而增加登录异常和风控风险。
• 把“降智”当成确定结论。 模型表现、路由和限流策略可能变化，但仅凭一次报错无法证明账号被降级；以官方状态和实际错误码为准。
• 无限重试。 这会把临时故障变成持续压力，也容易让本地任务卡死。

检查清单

• 官方状态页是否有进行中的事故
• 错误原文、HTTP 状态码、模型名、时间是否记录
• 换一个模型是否恢复
• 是否只有高并发或批量脚本才出现
• 是否伴随 429、503、额度或账单提示
• 重试是否有上限、退避和备用模型
• 是否排除了账号共享、异常登录等合规风险

小结

Selected model is at capacity 更像一条服务端容量信号，而不是封号通知。先查状态页，再用换模型做对照，接着退避重试、降低并发；只有多模型、长时间持续失败时，才重点检查账号、订阅和权限。订阅权益、模型可用性和限流规则可能调整，具体以官方最新说明为准。