1. 这个报错到底在说什么“Selected model is at capacity. Please try a different model”——这句话翻译成人话就是你当前选中的那个模型服务端已经满负荷了暂时接不了新的请求让你换一个模型再试。它跟你的代码写得对不对、配置有没有问题、账号有没有欠费基本没关系。这是服务端资源调度层面的反馈不是客户端错误。我第一次遇到这个提示的时候正在跑一个批量代码审查任务前面几十个请求都好好的突然就开始连续报这个。当时第一反应是怀疑自己的 API Key 出了问题换了 Key 还是一样又怀疑是网络波动重试了十几次偶尔能成功一次大部分时候还是这个提示。后来才想明白这就是典型的“模型侧容量打满”场景。这个报错在 Codex 这类代码辅助工具的使用过程中出现频率不低尤其是当你用的是热门模型、又赶上使用高峰期的时候。它可能出现在几个不同的位置命令行工具直接返回、IDE 插件弹窗提示、或者日志里以error running remote compact task的形式出现。不管以什么形式出现核心含义是一致的——你请求的那个模型此刻没有多余的算力来接你的活。适合谁来参考这篇内容如果你正在用 Codex 做代码补全、代码审查、重构建议或者把它接进了自己的 CI 流程、本地代理层然后被这个提示卡住了那这篇就是写给你的。哪怕你刚装好 Codex 还没怎么用过提前了解这个报错的来龙去脉也能少走不少弯路。2. 为什么会出现“模型容量已满”2.1 容量限制的本质是什么大模型服务的背后是一整套推理集群。每个模型实例能同时处理的请求数是有上限的这个上限由 GPU 显存、批处理策略、并发调度算法共同决定。当某个模型在某一时刻收到的请求数超过了它能承载的并发量新的请求就会被拒绝返回的就是“at capacity”这类提示。你可以把它想象成一家很火的餐厅。餐厅座位就那么多坐满了之后门口的服务员只能告诉你“现在没位置了要不您换一家”。模型服务也是一样的道理只不过“座位”变成了推理槽位“服务员”变成了 API 网关的限流层。这里有个关键点容量限制通常是按模型维度隔离的。也就是说模型 A 满了不代表模型 B 也满了。这正是报错提示里让你“try a different model”的原因——换一个当前负载较低的模型请求大概率就能通。2.2 哪些情况容易触发这个报错根据我自己的使用记录和社区里其他开发者的反馈以下几种场景最容易撞上这个提示高峰时段集中使用工作日的白天尤其是上午十点到下午四点这个区间全球开发者都在用热门模型的容量被抢得很快。批量任务并发过高如果你写了个脚本一次性发几十上百个请求或者 CI 流程里多个 job 同时调用同一个模型很容易把并发打满。长时间对话累积Codex 的某些使用模式下对话上下文会越来越长单次请求占用的资源也越来越多间接降低了服务端能同时服务的请求数。特定模型本身容量就小有些新发布的模型或者实验性模型部署的实例数量有限容量天花板本来就低稍微有点流量就满了。注意这个报错和“模型不存在”“模型不支持”是两码事。前者是容量问题后者是配置或权限问题。排查的时候要先分清楚别把方向搞错了。2.3 它和上下文超限的区别很多人容易把“at capacity”和“maximum context length”搞混。这两个报错虽然都跟模型有关但性质完全不同。上下文超限比如this models maximum context length is 1048576 tokens说的是你发过去的内容太长了超过了模型能处理的最大 token 数。这是客户端侧的问题你需要做的是精简输入、拆分任务、或者换一个上下文窗口更大的模型。而“at capacity”是服务端侧的问题跟你发的内容长短没关系纯粹是服务端此刻接不了。你发一个字的请求该满还是满。分清楚这一点很重要因为解决思路完全不一样。上下文超限要改的是你的输入策略容量已满要改的是你的调用策略。3. 遇到这个报错时的应对策略3.1 最直接的办法换模型报错信息本身就给了解法——换一个模型。这是成本最低、见效最快的操作。具体怎么换取决于你用的是哪种接入方式。如果你用的是 Codex CLI通常在配置文件里改model字段就行。如果你是通过 IDE 插件用的一般在设置界面里能直接切换模型。如果你是在代码里硬编码了模型名称那就改代码重新跑。换模型的时候有几个原则可以参考优先换同系列里负载较低的版本。比如你原来用的是某个高配版本可以试试标准版或者轻量版。如果任务对模型能力要求不高比如只是做简单的代码格式化建议直接换一个小模型又快又不容易满。如果任务确实需要强模型那就换一个同级别但不同供应商的模型作为备选。我自己的习惯是提前配好两到三个可用的模型主模型满了就切备选备选也满了再切第三个。这样基本不会因为单个模型容量问题卡住整个流程。3.2 重试机制加退避别硬刚如果你不想换模型或者任务必须用某个特定模型那就只能重试。但重试不是让你疯狂按回车那样只会让情况更糟。正确的做法是加指数退避。简单说就是第一次失败后等 1 秒重试第二次失败后等 2 秒第三次等 4 秒以此类推直到达到一个上限比如 30 秒或 60 秒。这样既能给服务端喘息的时间又不会因为重试太密集而被判定为异常流量。下面是一个简单的重试逻辑示例用 Python 写的import time import random def call_model_with_retry(client, prompt, max_retries5): base_delay 1 for attempt in range(max_retries): try: response client.complete(prompt) return response except CapacityError: if attempt max_retries - 1: raise delay base_delay * (2 ** attempt) random.uniform(0, 1) time.sleep(delay) return None这里加了一个随机抖动random.uniform(0, 1)是为了避免多个客户端在同一时刻同时重试造成“惊群效应”。这个技巧在高并发场景下特别有用。3.3 错峰使用把任务挪到低峰期如果你的任务不是必须实时完成那最简单的办法就是错峰。根据我的观察模型服务的使用低谷通常在这些时段深夜到凌晨北京时间凌晨两点到六点周末的白天重大节假日期间把批量任务、CI 流程、代码扫描这类不要求即时反馈的工作安排到这些时段跑遇到容量问题的概率会大幅降低。我有个做代码审查自动化的朋友原来把任务放在每天上午十点跑十次有三次会撞上容量报错。后来改到凌晨三点跑连续跑了一个月一次都没出过问题。这就是错峰的价值。3.4 降并发别把所有请求一次性打出去如果你是在跑批量任务检查一下并发数是不是设得太高了。很多人为了追求速度会把并发开到几十甚至上百这在服务端看来就是一波流量洪峰很容易触发限流。一个比较稳妥的做法是把并发控制在 3 到 5 之间然后根据实际成功率动态调整。如果连续成功可以适当加一点一旦出现容量报错立刻降下来。下面这个表格可以作为并发调整的参考并发数适用场景风险等级1-2调试、单次任务极低3-5常规批量任务低6-10对时效有要求的批量任务中10 以上不推荐除非有特殊配额高提示并发数不是越高越好。很多时候低并发加上合理的重试策略总完成时间反而比高并发频繁失败要短。4. 从配置层面减少容量报错的概率4.1 配好备选模型链与其等报错了再手忙脚乱地换模型不如提前把备选模型配好。很多 Codex 的接入层支持配置多个模型按优先级排列主模型不可用时自动降级到下一个。配置的时候注意几点备选模型的能力要能满足你的最低要求别主模型是强模型备选直接掉到很弱的模型结果输出质量差太多没法用。备选模型最好来自不同的服务通道避免主备同时挂掉。定期测试备选模型是否可用别等到真需要的时候才发现备选也早就失效了。4.2 检查 base_url 和 provider 配置热词里有一条配置错误: codex provider 缺少 base_url 配置这个虽然和容量报错不是同一个问题但配置错误确实会间接导致你频繁遇到各种异常。如果你用的是本地代理层比如某些转发工具一定要确认base_url指向正确provider配置完整。配置不对的时候请求可能被发到一个根本不存在的端点或者被路由到错误的模型上表现出的症状可能五花八门容量报错只是其中之一。我踩过的一个坑是代理配置里模型名称写的是 A但实际路由到了 B结果 B 容量满了报错信息里显示的却是 A 的名字排查了半天才找到原因。所以配置一定要仔细核对别想当然。4.3 控制单次请求的上下文长度虽然上下文长度和容量不是直接因果关系但上下文越长单次请求占用的推理资源越多服务端能同时处理的请求数就越少。在容量紧张的时候长上下文请求更容易被拒绝。所以养成精简上下文的习惯是有好处的不要把整个代码库都塞进去只放相关的文件和片段。定期清理对话历史别让无关的旧消息一直占着位置。如果任务可以拆分就拆成多个小请求而不是一个巨型请求。4.4 设置合理的超时和重试参数超时设得太短请求还没到服务端就被你掐断了设得太长遇到容量问题时你会等很久才收到失败反馈。重试次数设得太少偶尔的容量波动就把任务搞失败了设得太多又可能陷入无休止的重试循环。我的经验值是超时设在 30 到 60 秒之间重试次数 3 到 5 次配合指数退避。这个组合在大多数场景下都能兼顾成功率和响应速度。5. 常见问题速查与排查思路5.1 报错信息对照表不同的报错信息指向不同的问题下面这张表可以帮你快速定位报错信息含义处理方向Selected model is at capacity模型容量已满换模型、重试、错峰Model is not supported模型不支持当前接入方式检查账号类型和模型权限Maximum context length exceeded输入太长精简上下文或换大窗口模型Model does not exist模型名称错误或未开通核对模型名称和权限Provider 缺少 base_url代理配置不完整补全配置项Auth token is unavailable认证信息缺失重新登录或检查凭证5.2 排查顺序建议遇到报错别慌按这个顺序排查基本能覆盖大部分情况看报错原文先确认到底是容量问题还是配置问题别搞错方向。换模型试一次如果换模型能通那就是容量问题按容量问题的思路处理。检查配置如果换模型也不行检查 base_url、provider、模型名称这些配置项。检查认证确认登录状态和凭证是否有效。看服务端状态如果以上都没问题可能是服务端整体异常等一段时间再试。5.3 几个容易踩的坑坑一把容量报错当成代码 bug。有些人看到报错就以为是自己的代码写错了反复调试代码其实代码没问题就是服务端满了。判断方法很简单同样的代码换个时间或换个模型能跑通那就不是代码问题。坑二无限重试不设上限。写了个while True循环一直重试结果把账号的请求配额耗光了还触发了更严格的限流。重试一定要设上限并且加退避。坑三忽略代理层的配置。如果你用了本地代理转发代理层的配置错误可能产生各种奇怪的报错容量报错只是表象。定期检查代理配置确保和上游服务的要求一致。坑四在高峰期跑大批量任务。这个前面说过了但还是要强调一遍。批量任务尽量安排在低峰期能省掉很多麻烦。6. 实操心得与经验总结6.1 我的模型切换策略我目前的做法是维护一个模型优先级列表主模型放在第一位后面跟两个备选。每次请求先走主模型遇到容量报错自动切到备选一备选一也满了切备选二。切换过程对上层任务透明不需要人工干预。这个策略的关键在于备选模型的选择。我的原则是备选一和主模型能力接近保证输出质量不会断崖式下降备选二可以稍微弱一点但胜在稳定作为最后的兜底。6.2 批量任务的调度技巧跑批量任务的时候我会把任务分成小批次每批之间加一个短暂的间隔。这样即使某一批遇到了容量问题也不会影响已经完成的部分重试的时候只需要重跑失败的那一批。另外我会记录每个批次的成功率和耗时如果发现某个时段成功率明显下降就自动把后续批次延后执行。这个动态调整的逻辑用简单的脚本就能实现效果比固定时间跑要好很多。6.3 关于“换个模型”的再思考报错提示说“try a different model”但换模型不是无脑换。有些任务对模型能力有硬性要求换到弱模型上虽然能跑通但输出质量不达标等于白跑。所以换模型之前要想清楚这个任务对模型能力的最低要求是什么备选模型能不能满足如果不能满足那宁可等一等重试也不要为了跑通而牺牲质量。我一般会把任务分成两类一类是“能力敏感型”必须用强模型遇到容量问题就重试或错峰另一类是“能力不敏感型”随便什么模型都能干遇到容量问题直接切备选。分类之后处理起来就清晰多了。6.4 长期视角把容量问题纳入架构设计如果你是在做产品或者长期维护的项目别把容量报错当成偶发事件来处理而要把它纳入架构设计。具体来说在调用层封装统一的模型切换和重试逻辑不要让每个业务模块自己处理。监控各模型的成功率和响应时间及时发现容量趋势。准备至少两个不同来源的模型通道避免单点依赖。对非实时任务采用队列机制遇到容量问题自动排队等待而不是直接失败。这些措施看起来麻烦但一旦搭好后续遇到容量问题基本就是无感的系统自己就消化掉了。6.5 一个真实案例的复盘最后分享一个我印象比较深的案例。有一次我帮一个团队排查他们的 CI 流程为什么经常失败日志里全是“Selected model is at capacity”。他们的流程是每次代码提交都触发一次全量代码审查并发数设了 20而且只在工作时间跑。问题很明显高并发加高峰期不撞容量才怪。我给他们改了三处并发降到 5加了指数退避重试把非紧急的审查任务挪到凌晨跑。改完之后连续两周没有出现过容量报错CI 成功率从原来的七成多提升到了接近百分之百。这个案例说明容量问题很多时候不是靠“等”解决的而是靠合理的调度和配置来规避的。花点时间把调用策略理顺比每次遇到报错就手动重试要划算得多。代码辅助工具的使用体验很大程度上取决于你怎么管理模型调用。模型容量是服务端的客观限制我们改变不了但可以通过换模型、加退避、错峰、降并发这些手段把影响降到最低。把这些策略固化到你的工作流里后面基本就不用再为这个报错操心了。