遇到Codex提示“Selected model is at capacity”怎么办？原因解析与替代方案

最近在折腾一些代码生成或者自动补全工具的时候，有不少朋友反馈遇到了一个让人头秃的报错提示：“Selected model is at capacity. Please try a different model”。

这个错误通常出现在使用 OpenAI 的 Codex 模型（或者基于其封装的第三方工具）时。明明刚才还用得好好的，突然就罢工了，这是怎么回事？今天我们就以此为契机，简单聊聊这个报错的底层逻辑，以及遇到这种情况该怎么优雅地解决，而不仅仅是盯着屏幕发呆。

为什么会报错？

首先，别慌，这大概率不是你本地代码写错了，也不是账号被封了。

这句话直译过来就是“选定的模型已达到容量上限”。简单来说，就是后端服务器太忙了，或者是官方对你的这个API Key分配的并发资源暂时用光了。

这就像早高峰去挤地铁，车还在，但是核载人数已经满了，门口的闸机就不放人了。对于 Codex 或者其他大语言模型服务来说，GPU 资源是非常昂贵的。为了保证服务稳定性，提供商通常会设置一个“并发限制”（Rate Limit）或者“排队机制”。当同一时间请求该模型的人数激增，或者你的请求频率过高触发了限制，系统就会直接抛出这个错误，拒绝处理新的请求。

解决方案有哪些？

既然知道了原理，我们就能对症下药。以下是几个实用度很高的解决思路，按操作难易度排序：

OpenAI API 遇到容量限制时的报错界面

1. 最简单粗暴法：稍等重试

如果是由于后端瞬时流量过大导致的拥堵，通常过几分钟就会缓解。

• 操作： 等待 30 秒到 1 分钟，然后刷新页面或者重新提交请求。
• 适用场景： 偶发性报错，不急于这一时半刻。

2. 切换模型版本

报错信息其实已经给出了提示：“Please try a different model”。很多时候，高配版本的模型（如 code-davinci-002 等）资源更紧张，而低配版本或者轻量级模型可能还有余量。

• 操作： 在你的 API 调用参数或者设置面板中，将 model 参数切换为其他可用的 code 编程模型。例如，如果你在用 code-cushman-001，可以尝试切回基础版或者寻找官方推荐的替代型号。
• 适用场景： 对代码生成的精准度要求不是极端苛刻，或者刚好有多个模型可供选择的情况。

3. 检查并发请求与速率限制

服务端并发限制与流量拥堵示意图

如果你是在编写自动化脚本或者高并发应用，这个报错可能是因为你的请求发送得太快了。

• 操作： 在代码中引入“指数退避”机制。也就是第一次报错后等 1 秒重试，第二次报错等 2 秒，第三次等 4 秒，以此类推。同时检查你的程序是否有循环过快导致请求堆积。
• 适用场景： 开发者调试阶段，或者需要长期稳定运行的后端服务。

4. 寻找平替与镜像服务

如果官方渠道实在排队严重，这也是技术圈常玩的套路。目前市面上有不少提供兼容 OpenAI 格式的 API 中转服务，或者是其他的开源 Code LLM（如 CodeLlama, StarCoder 等）。

• 操作： 更换 API 的 Base URL，指向那些资源相对充裕的中转服务；或者尝试部署本地的小模型来解决简单的代码补全需求。
• 适用场景： 对延迟敏感，或者需要大量调用 API 的商业项目。

总结

“模型容量已满”虽然恼人，但本质上是资源供需矛盾。对于个人用户来说，“换”（换模型、换服务商）和**“等”**（等待重试）是最快的恢复手段。对于开发者而言，加上完善的错误处理和重试机制，才能让我们的应用在面对这种突发状况时更加健壮。

希望这篇小文能帮到正在抓狂的你，下次再见到这个提示，就知道该怎么办了！