OpenAI 报 model is at capacity：是风控还是容量不足？排查与解决
桌面端和命令行里切换模型都提示 Selected model is at capacity，很容易被当成账号被风控。这句报错本身不区分原因，既可能是模型真的排队，也可能是账号限流、配额不足或请求链路异常。文章给出分类判断方法、可直接执行的排查清单、重试与模型回退方案，并说明换网络、换账号这类做法的风险与取舍。
在桌面客户端或命令行工具里切换模型，屏幕上始终只有一句 Selected model is at capacity. Please try a different model.，换到另一个模型照样弹同样的提示——这种时候很容易怀疑账号被“风控”了。但这句提示字面意思是“所选模型容量已满”，它并不区分究竟是服务端真的在排队、账号触发了速率限制，还是请求链路上的某个中间环节出了问题。
同一句文案对应好几种完全不同的原因，也正因为如此，围观者的经验常常互相矛盾：有人放几天自己好了，有人换了个网络环境就能用，也有人直接判定没救。下面把这类报错拆开看：怎么判断自己属于哪一种，按什么顺序排查，哪些做法有风险，以及怎样让日常使用不被一次限流打断。
这句报错到底在说什么
“at capacity” 是服务端返回的容量类提示，属于可重试的临时状态，但它的文案粒度很粗。以下几种情况都可能返回相同或极为相似的一句话：
- 模型侧排队：某个热门模型在高峰时段资源紧张，其他模型正常，隔一段时间恢复。
- 账号侧限制：触发了速率限制、并发上限、用量额度或账单问题，请求在路由层就被拦下。
- 组织/项目配置：API Key 所属的项目没有开通对应模型的权限，或项目级额度已用尽。
- 请求链路异常：本地网络抖动、代理或中转服务在多个上游之间来回切换，导致请求被反复重试后落到一个不可用的通道。
- 客户端自身问题：客户端版本过旧、缓存了旧的模型标识、重试逻辑把错误放大。
判断的关键不是看文案，而是看复现范围和返回状态码。只影响单个模型、所有客户端一致、几小时内自愈的，多半是容量问题；所有模型全挂、换设备也一样、持续数天的，更可能是账号或链路问题。
五分钟排查清单
按下面的顺序走一遍，基本能定位到类别。
1. 绕开客户端，直接发一次请求
# 先看 Key 本身是否可用，以及返回码
curl -sS -o /dev/null -w "%{http_code}\n" https://api.openai.com/v1/models \
-H "Authorization: Bearer $OPENAI_API_KEY"
# 再针对具体模型发一次最小请求，看响应体和错误类型
curl -sS https://api.openai.com/v1/chat/completions \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"<你的主模型>","messages":[{"role":"user","content":"ping"}],"max_tokens":16}'
重点看：
- 返回 429：限流或额度类问题，与账号/用量相关。
- 返回 5xx：服务端或链路问题，属于可重试范围。
- 返回 401/403：Key 或项目权限问题，和“容量”无关。
- 只有某个模型报错、其他模型正常：模型侧容量或权限。
2. 做三组对照
| 对照项 | 说明 |
|---|---|
| 换模型 | 只有主模型失败 → 模型侧问题；全部失败 → 账号或链路 |
| 换 Key / 换项目 | 同一组织下新建 Key 仍失败 → 组织级限制 |
| 换网络出口 | 换到手机热点仍失败 → 与本地网络无关；只有某条链路失败 → 链路问题 |
3. 检查用量与账单
- 控制台的用量面板是否在报错当天有明显尖峰或触顶；
- 是否存在并发请求数超限（批处理脚本、多个客户端同时跑最容易踩到）；
- 账单是否处于欠费、支付方式失效状态；
- 项目级、组织级额度是否分别设置过上限。
4. 清理客户端侧的干扰
- 关掉代理、中转、加速类工具，直连对比一次；
- 客户端升级到当前稳定版本，清除模型选择缓存后重选；
- 查看客户端日志，确认报错是服务端返回的还是本地重试包装出来的；
- 如果你同时挂了多个工具（编辑器插件 + 命令行 + 桌面端），先只留一个再测。
5. 记录时间规律
连续两三天在同一时段复现，说明大概率是容量高峰；毫无规律、随时失败，则偏向账号或链路。这份记录在后续提工单时也用得上。
观点分歧：等一等、换网络，还是换号
围绕这类报错，常见三种态度，各有适用场景。
“放几天自己会好”——适用于只影响单个模型、状态码是 5xx、其他模型正常的情况。容量类问题本来就有自愈特性，短期先切到备选模型，观察两三天即可。
“换个网络环境就行”——有人在换出口后确实恢复了，但这更可能说明原链路存在中转、共享出口或频繁切换的问题，而不代表账号状态被改变。需要提醒的是，刻意变换出口地区去规避服务的地域限制，通常违反平台条款，可能导致账号被进一步限制甚至封停，因此这里不展开具体做法。合规的替代思路是：确认自己的使用方式符合服务条款，优先使用官方支持的地区与正规企业账号；如果问题确实出在本地网络不稳定，就换一条干净、固定的网络出口，而不是反复横跳。
“黑号了，换号吧”——最不建议。购买、租用或与他人共享账号，既无法保证账号来源合规，也会把对话内容、API Key 和账单信息暴露给第三方，一旦触发风控往往是整批账号一起失效。真需要更高配额，走官方的用量提升申请或企业方案，比换号稳妥得多。
还有一种情况值得单独说：在 Windows 上通过第三方中转接入、频繁切换服务地址的用户，出问题的概率明显更高。中转服务本身可能不稳定，也可能在你不了解的情况下改变请求来源，排查时先把这一层摘掉再判断。
让使用不被一次限流打断的做法
比起纠结“是不是被风控”，工程上更实际的是让工具在报错时能自己扛过去。
- 加指数退避重试：对 429 和 5xx 做重试，间隔按 1s、2s、4s、8s 递增并加随机抖动，最多 3–5 次，避免把限流放大成雪崩。
- 配置模型回退链：主模型失败后自动降级到备选模型，而不是直接把错误抛给用户。命令行工具和编辑器插件大多支持配置备用模型，值得花十分钟设好。
- 设置合理的超时：长任务把单次请求超时调长，批量任务改成小并发串行，减少同时打到速率上限的概率。
- 把长任务放到常驻环境：需要连续跑几小时的 AI 编程或批处理任务时，本地机器休眠、网络切换都会中断会话并触发重试风暴。一种可选做法是租用一台位于官方支持地区的云端 Mac 常驻运行，远程连接使用，网络出口稳定、不休眠；它解决的是运行环境稳定性，不能改变账号本身的合规状态，账号该有的限制照样存在。
- 做可用性监控：把每次失败的状态码和模型名记录下来，连续失败超过阈值时告警，比事后凭印象判断可靠。
小结
Selected model is at capacity 不等于“账号被封”。先按状态码和复现范围把问题分成容量、账号、链路三类，再决定是等待、调配置还是提工单。短期用模型回退和退避重试保住工作流，长期把出口网络和运行环境稳定下来。涉及变换地区、买卖或共享账号的做法不要碰，风险远大于收益；平台的具体规则和配额政策会调整，实际操作以官方最新说明为准。
