1. 问题现象与核心症结拆解1.1 这个报错到底在说什么用过 Codex 这类 AI 编程辅助工具的人大概率都撞见过这么一行提示Selected model is at capacity. Please try a different model.直译过来就是你选的模型容量满了换个模型试试。很多人第一反应是网络卡了、账号出问题了甚至怀疑是不是自己哪里配置错了。其实都不是——这句话的本质是服务端的算力资源调度问题跟你本地环境、网络质量、账号状态基本没关系。打个生活化的比方这就像你常去的那家热门餐厅中午十二点去服务员告诉你大厅坐满了您要么等位要么去隔壁那家分店。菜还是那些菜厨师还是那些厨师只是同一时间想用这个模型的人太多了服务端的推理资源被占满了系统只能把新来的请求挡在门外或者引导你去用别的模型。Codex 背后挂载的模型不是无限扩容的。每个模型实例都有固定的并发处理上限当同时在线的请求数、或者单位时间内的 token 消耗量触顶调度层就会开始劝退新请求。这个机制本身是合理的是为了保证已经在处理的请求不被拖垮但对使用者来说体验就很割裂——上一秒还能用下一秒就报错。1.2 为什么偏偏是你频繁遇到同样是报这个错有人一天撞三五次有人一周都碰不上一回。差异主要来自几个变量我把它拆成一张表方便你对照自己的情况影响因素高频触发场景低频触发场景使用时段工作日白天、晚间高峰凌晨、清晨、周末深夜模型选择热门旗舰模型轻量/冷门模型请求频率连续快速提交、批量任务间隔提交、单次交互任务体量超长上下文、大文件分析短问答、小片段补全账号层级免费或基础档高优先级档看这张表就能明白报错频率高不高很大程度上取决于你有没有踩在资源竞争最激烈的时间点和模型上。这不是玄学是资源调度的必然结果。理解了这一点后面的所有缓解手段才有落脚点——我们要做的不是去修复一个不存在的故障而是在资源紧张的环境里聪明地绕开拥堵、错峰使用、降低单次消耗。1.3 缓解思路的总框架在动手之前先把整体思路理清楚避免东一榔头西一棒子。我把缓解手段分成四个层次从最省事到最彻底依次递进第一层换模型——报错时立刻切到备用模型这是最快见效的应急手段。第二层错峰与降频——调整使用习惯避开高峰、控制提交节奏。第三层优化请求——精简上下文、拆分任务降低单次请求的资源占用。第四层配置兜底——通过工具配置实现自动重试、模型轮换把人工干预降到最低。这四层不是互斥的实际用起来往往是组合拳。下面我逐层展开每一层都会讲清楚为什么这么做和具体怎么做。2. 模型切换策略最快见效的应急手段2.1 别死磕一个模型备用清单要提前备好报错信息里那句Please try a different model其实已经把答案给你了——换个模型。但问题在于很多人根本不知道自己能用哪些模型报错时手忙脚乱随便点一个发现还是满的来回折腾几分钟思路全断了。我的做法是提前维护一份模型备用清单按优先级排好序报错时按顺序往下切。这份清单要满足两个条件一是这些模型你都有权限访问二是它们的资源池相对独立不会一起满。具体怎么排我的经验是这样主力模型你平时用得最顺、效果最好的那个放在第一位。同级别备选能力接近但资源池不同的模型放第二、第三位。轻量模型响应快、资源占用小的模型放最后兜底适合处理简单任务。本地或离线方案如果条件允许准备一个本地可跑的小模型作为终极保底。提示备用清单不要临时现查最好写在你常用的配置里或者记在便签上。报错时人的耐心是有限的能少点一次鼠标就少点一次。2.2 切换模型的实操细节不同工具切换模型的方式不一样但核心逻辑相通。以常见的配置型工具为例通常有两种切换路径路径一交互式切换。在对话界面或命令面板里直接选择模型。这种方式适合临时切换缺点是每次都要手动操作。路径二配置文件切换。把模型名称写在配置文件里改完重启或热加载生效。这种方式适合固定策略比如白天用轻量模型晚上用旗舰模型。我实测下来把常用模型写成配置项、配合环境变量控制是最灵活的。比如你可以设一个默认模型再设一个降级模型当主模型报错时自动切到降级模型。下面是一个配置结构的示意具体字段名以你所用工具为准{ default_model: 主力模型名称, fallback_models: [ 备选模型A, 备选模型B, 轻量模型C ], retry_on_capacity_error: true, max_retries: 3 }这里的关键是fallback_models这个数组——它定义了一个降级链条。当主模型报容量错误时系统按顺序尝试备选直到有一个能用。max_retries控制重试次数避免无限循环。2.3 切换时容易踩的坑切换模型看着简单但有几个坑我踩过提前给你标出来坑一备选模型能力差距太大。有些轻量模型处理复杂代码任务时质量断崖式下跌切过去反而更浪费时间。所以备用清单里同级别备选要放在轻量模型前面。坑二上下文不兼容。不同模型的上下文窗口大小不同从大窗口模型切到小窗口模型时超长的对话历史可能被截断导致模型失忆。切换前最好确认一下目标模型的上下文限制。坑三切换后没重置状态。有些工具切换模型后之前的对话上下文还挂着新模型可能因为格式不匹配而报错。稳妥的做法是切换后开一个新会话。3. 错峰使用与请求节奏控制3.1 摸清资源高峰的时间规律模型容量满不满跟现实世界的作息高度相关。根据我长期的观察和记录AI 编程工具的使用高峰大致有这么几个时段工作日上午 9:30 到 11:30大家上班后开始处理任务请求量快速爬升。工作日下午 14:00 到 17:00午后到傍晚的持续高峰。工作日晚间 20:00 到 23:00个人开发者、学生群体的活跃时段。相对的低谷时段通常是凌晨 0:00 到早上 7:00、工作日的午休时段12:00 到 13:30 相对缓和、周末的白天反而比工作日晚上要松一些。这不是让你非得半夜爬起来写代码而是说如果你的任务不紧急可以主动往低谷时段挪。比如一些批量的代码重构、文档生成任务完全可以挂到晚上睡前提交第二天早上看结果。3.2 控制提交频率别做请求轰炸机我见过不少人用 AI 工具的习惯是一个问题接一个问题地快速提交中间几乎不留间隔。这种用法在资源宽松时没问题但在高峰期高频请求会显著提高你撞上容量限制的概率。原因很简单服务端的限流和调度是按时间窗口算的。你在短时间内提交大量请求等于把自己推到了竞争队列的前排一旦资源池满你首当其冲。我的建议是给请求之间留出合理的间隔。具体多长合适我的经验值是简单问答类间隔 2 到 5 秒。代码生成类等上一次结果完全返回、你确认无误后再提交下一次。批量任务用队列串行处理不要并发轰炸。如果你确实有大量任务要跑用脚本做串行队列 自动重试比手动狂点要稳得多。下面是一个简单的串行处理思路伪代码tasks [任务1, 任务2, 任务3, ...] for task in tasks: success False retries 0 while not success and retries 3: try: result call_model(task) success True except CapacityError: retries 1 sleep(backoff_time(retries)) # 退避等待 switch_to_fallback_model() save_result(result)这里的backoff_time是退避等待重试次数越多等得越久避免密集重试加剧拥堵。3.3 退避策略的参数怎么定退避等待的时间不是随便拍的太短没效果太长浪费时间。我常用的是一套指数退避参数重试次数等待时间说明第 1 次3 秒轻微等待多数瞬时拥堵能缓解第 2 次8 秒中等等待同时切换备选模型第 3 次20 秒较长等待基本能避开短时高峰第 4 次60 秒兜底等待仍失败则转人工处理这套参数是我反复调整后觉得比较平衡的既不会因为等太久而拖慢整体进度又能有效避开大部分瞬时拥堵。你可以根据自己的任务紧急程度微调紧急任务把等待时间砍半非紧急任务可以拉长。注意退避期间不要反复手动重试。手动重试会打乱退避节奏等于白等。交给脚本或工具自动处理。4. 请求体量优化从源头降低资源占用4.1 上下文越长越容易撞墙这一点很多人没意识到你单次请求消耗的资源跟上下文长度是强相关的。上下文越长模型需要处理的 token 越多占用的推理资源越大在资源紧张时越容易被拒。我做过一个粗略的对比测试同样是让模型改一段代码只贴相关函数约 200 行和贴整个文件约 2000 行前者几乎没报过错后者在高峰期报错率明显上升。原因就在于后者单次请求的 token 量是前者的十倍左右。所以精简上下文是降低报错率的硬手段。具体怎么做只贴相关代码不要整个文件往里扔把出问题的函数、相关的类型定义挑出来。清理无关历史长对话里早期的、已经解决的内容可以手动清理或开新会话。用摘要代替全文如果必须提供大背景先用一段话概括而不是贴原始材料。4.2 任务拆分大任务切成小步骤除了精简上下文把大任务拆成小步骤也是有效手段。一个帮我重构整个模块的请求和十个帮我改这个函数的请求虽然总工作量差不多但前者单次资源占用高、容易撞限流后者每次都很轻、成功率高。拆分的粒度怎么把握我的经验是以一次能说清楚、模型一次能返回完整结果为单位。比如不要帮我优化这个项目的性能。而要帮我看看这个函数的循环能不能优化 → 帮我看看这个数据库查询能不能加索引 → 帮我看看这个缓存策略合不合理。这样拆下来每个请求都很轻即使某个请求撞上容量限制重试成本也低不会影响整体进度。4.3 输出长度也要控制很多人只关注输入忽略了输出长度同样消耗资源。你让模型生成一个 5000 行的完整文件和让它生成一个 50 行的函数资源占用天差地别。控制输出的技巧明确要求简洁在提示里加一句只返回修改的部分不要重复未改动代码。分段生成大文件分多次生成每次一个模块。用 diff 而非全量让模型返回差异而不是完整文件。这些技巧不仅降低报错率还能让结果更聚焦、更容易 review一举两得。5. 自动化兜底配置把人工干预降到最低5.1 自动重试与模型轮换的实现思路前面讲的都是手动应对但真正高频使用的人需要的是自动化兜底——报错了自动重试、自动换模型人不用管。这需要在你使用的工具或自己写的调用层里做文章。核心逻辑就三步捕获容量错误 → 等待退避 → 切换模型重试。前面 3.2 节的伪代码已经展示了这个流程。这里补充几个实操要点错误识别要准不同工具报错文案可能略有差异但关键词通常是 capacity、at capacity、try a different model。用关键词匹配即可不要写死整句。模型轮换要有序按备用清单顺序切切到最后一个还失败才判定为彻底不可用。状态要隔离切换模型后如果上下文格式不兼容要能自动开新会话或重置上下文。5.2 一个可参考的配置模板下面这份配置模板是我自己用的结构字段名你可以按实际工具调整但结构逻辑可以直接抄model_strategy: primary: 主力模型 fallbacks: - 备选模型A - 备选模型B - 轻量模型C switch_on_error: true retry_policy: max_retries: 4 backoff_seconds: [3, 8, 20, 60] retry_on: - capacity - at capacity - try a different model context_policy: max_context_tokens: 8000 auto_truncate: true summarize_on_overflow: true这份配置里model_strategy管模型切换retry_policy管重试节奏context_policy管上下文控制。三者配合基本能覆盖大部分容量报错场景。5.3 监控与日志知道什么时候在堵如果你用得比较重建议加一层简单的日志记录记录每次报错的时间、模型、重试次数、最终是否成功。积累一两周你就能看出规律——哪个时段最容易堵、哪个模型最稳、你的平均重试次数是多少。有了这些数据优化就有方向了。比如发现每天下午三点必堵那就把批量任务挪到别的时段发现某个备选模型从来没失败过就把它提到备用清单第一位。日志不用搞得很复杂一个 CSV 文件、几列关键字段就够了时间请求模型是否报错重试次数最终模型结果14:23主力模型是2备选A成功14:25主力模型否0主力模型成功6. 常见问题与排查技巧实录6.1 报错排查速查表实际使用中容量报错往往和其他问题混在一起容易误判。我整理了一张速查表帮你快速定位现象可能原因排查动作报容量错误换模型后正常单纯资源拥堵无需处理继续用备选所有模型都报容量错误账号层级限流或全局高峰错峰使用检查账号状态报容量错误但换模型后报格式错误上下文不兼容开新会话精简上下文频繁报错且间隔很短请求频率过高被限流降低提交频率加退避只有长请求报错单次 token 量过大拆分任务精简上下文特定时段必报错踩中资源高峰调整任务时间这张表覆盖了我遇到过的绝大多数情况。核心判断逻辑是先换模型换完还错就查频率和体量都正常就查时段和账号。6.2 几个反直觉的坑有几个坑比较反直觉单独拎出来说坑一重试太快反而更糟。很多人一报错就立刻重试结果连续撞墙。正确做法是等一等再试给服务端喘息时间。我前面给的退避参数就是干这个的。坑二换模型不一定换资源池。有些工具里看似不同的模型其实共享同一个后端资源池换了个名字但没换池子照样满。这种情况要换到架构上真正独立的模型。坑三免费额度用完后报错变多。部分服务在免费额度耗尽后会把你降到低优先级队列容量报错率上升。这时候要么升级要么接受更频繁的错峰使用。坑四网络抖动会被误判为容量错误。偶尔网络不稳也会触发类似报错但本质不同。区分方法容量错误换模型能解决网络问题换模型也没用且通常伴随超时。6.3 我的独家避坑心得最后分享几条我自己总结的、文档里不会写的心得养成报错即切换的肌肉记忆。别犹豫、别分析先切了再说切完继续干活事后再复盘。犹豫的每一秒都是浪费。备用模型要定期轮换测试。别等到主模型挂了才发现备选也不能用。每周挑个时间主动用一下备选模型确认它们还活着、效果还能接受。把最耗资源的任务安排在低谷。批量重构、大文件分析这类重活尽量挪到凌晨或周末成功率能高一大截。别把鸡蛋放一个篮子。如果你对 AI 编程工具依赖很重最好同时熟悉两三个不同平台的工具一个堵了立刻换另一个而不是干等。这套方法我用了挺长时间容量报错的困扰基本降到了可以忽略的程度。核心就一句话别跟资源拥堵硬刚学会绕、学会等、学会拆。工具是为人服务的摸清它的脾气用起来就顺了。 
长河君 · 2026/10/20 15:14:27 · 阅读 1.2k Codex模型容量报错全解析：从原因到自动化兜底策略
1. 问题现象与核心症结拆解1.1 这个报错到底在说什么用过 Codex 这类 AI 编程辅助工具的人大概率都撞见过这么一行提示Selected model is at capacity. Please try a different model.直译过来就是你选的模型容量满了换个模型试试。很多人第一反应是网络卡了、账号出问题了甚至怀疑是不是自己哪里配置错了。其实都不是——这句话的本质是服务端的算力资源调度问题跟你本地环境、网络质量、账号状态基本没关系。打个生活化的比方这就像你常去的那家热门餐厅中午十二点去服务员告诉你大厅坐满了您要么等位要么去隔壁那家分店。菜还是那些菜厨师还是那些厨师只是同一时间想用这个模型的人太多了服务端的推理资源被占满了系统只能把新来的请求挡在门外或者引导你去用别的模型。Codex 背后挂载的模型不是无限扩容的。每个模型实例都有固定的并发处理上限当同时在线的请求数、或者单位时间内的 token 消耗量触顶调度层就会开始劝退新请求。这个机制本身是合理的是为了保证已经在处理的请求不被拖垮但对使用者来说体验就很割裂——上一秒还能用下一秒就报错。1.2 为什么偏偏是你频繁遇到同样是报这个错有人一天撞三五次有人一周都碰不上一回。差异主要来自几个变量我把它拆成一张表方便你对照自己的情况影响因素高频触发场景低频触发场景使用时段工作日白天、晚间高峰凌晨、清晨、周末深夜模型选择热门旗舰模型轻量/冷门模型请求频率连续快速提交、批量任务间隔提交、单次交互任务体量超长上下文、大文件分析短问答、小片段补全账号层级免费或基础档高优先级档看这张表就能明白报错频率高不高很大程度上取决于你有没有踩在资源竞争最激烈的时间点和模型上。这不是玄学是资源调度的必然结果。理解了这一点后面的所有缓解手段才有落脚点——我们要做的不是去修复一个不存在的故障而是在资源紧张的环境里聪明地绕开拥堵、错峰使用、降低单次消耗。1.3 缓解思路的总框架在动手之前先把整体思路理清楚避免东一榔头西一棒子。我把缓解手段分成四个层次从最省事到最彻底依次递进第一层换模型——报错时立刻切到备用模型这是最快见效的应急手段。第二层错峰与降频——调整使用习惯避开高峰、控制提交节奏。第三层优化请求——精简上下文、拆分任务降低单次请求的资源占用。第四层配置兜底——通过工具配置实现自动重试、模型轮换把人工干预降到最低。这四层不是互斥的实际用起来往往是组合拳。下面我逐层展开每一层都会讲清楚为什么这么做和具体怎么做。2. 模型切换策略最快见效的应急手段2.1 别死磕一个模型备用清单要提前备好报错信息里那句Please try a different model其实已经把答案给你了——换个模型。但问题在于很多人根本不知道自己能用哪些模型报错时手忙脚乱随便点一个发现还是满的来回折腾几分钟思路全断了。我的做法是提前维护一份模型备用清单按优先级排好序报错时按顺序往下切。这份清单要满足两个条件一是这些模型你都有权限访问二是它们的资源池相对独立不会一起满。具体怎么排我的经验是这样主力模型你平时用得最顺、效果最好的那个放在第一位。同级别备选能力接近但资源池不同的模型放第二、第三位。轻量模型响应快、资源占用小的模型放最后兜底适合处理简单任务。本地或离线方案如果条件允许准备一个本地可跑的小模型作为终极保底。提示备用清单不要临时现查最好写在你常用的配置里或者记在便签上。报错时人的耐心是有限的能少点一次鼠标就少点一次。2.2 切换模型的实操细节不同工具切换模型的方式不一样但核心逻辑相通。以常见的配置型工具为例通常有两种切换路径路径一交互式切换。在对话界面或命令面板里直接选择模型。这种方式适合临时切换缺点是每次都要手动操作。路径二配置文件切换。把模型名称写在配置文件里改完重启或热加载生效。这种方式适合固定策略比如白天用轻量模型晚上用旗舰模型。我实测下来把常用模型写成配置项、配合环境变量控制是最灵活的。比如你可以设一个默认模型再设一个降级模型当主模型报错时自动切到降级模型。下面是一个配置结构的示意具体字段名以你所用工具为准{ default_model: 主力模型名称, fallback_models: [ 备选模型A, 备选模型B, 轻量模型C ], retry_on_capacity_error: true, max_retries: 3 }这里的关键是fallback_models这个数组——它定义了一个降级链条。当主模型报容量错误时系统按顺序尝试备选直到有一个能用。max_retries控制重试次数避免无限循环。2.3 切换时容易踩的坑切换模型看着简单但有几个坑我踩过提前给你标出来坑一备选模型能力差距太大。有些轻量模型处理复杂代码任务时质量断崖式下跌切过去反而更浪费时间。所以备用清单里同级别备选要放在轻量模型前面。坑二上下文不兼容。不同模型的上下文窗口大小不同从大窗口模型切到小窗口模型时超长的对话历史可能被截断导致模型失忆。切换前最好确认一下目标模型的上下文限制。坑三切换后没重置状态。有些工具切换模型后之前的对话上下文还挂着新模型可能因为格式不匹配而报错。稳妥的做法是切换后开一个新会话。3. 错峰使用与请求节奏控制3.1 摸清资源高峰的时间规律模型容量满不满跟现实世界的作息高度相关。根据我长期的观察和记录AI 编程工具的使用高峰大致有这么几个时段工作日上午 9:30 到 11:30大家上班后开始处理任务请求量快速爬升。工作日下午 14:00 到 17:00午后到傍晚的持续高峰。工作日晚间 20:00 到 23:00个人开发者、学生群体的活跃时段。相对的低谷时段通常是凌晨 0:00 到早上 7:00、工作日的午休时段12:00 到 13:30 相对缓和、周末的白天反而比工作日晚上要松一些。这不是让你非得半夜爬起来写代码而是说如果你的任务不紧急可以主动往低谷时段挪。比如一些批量的代码重构、文档生成任务完全可以挂到晚上睡前提交第二天早上看结果。3.2 控制提交频率别做请求轰炸机我见过不少人用 AI 工具的习惯是一个问题接一个问题地快速提交中间几乎不留间隔。这种用法在资源宽松时没问题但在高峰期高频请求会显著提高你撞上容量限制的概率。原因很简单服务端的限流和调度是按时间窗口算的。你在短时间内提交大量请求等于把自己推到了竞争队列的前排一旦资源池满你首当其冲。我的建议是给请求之间留出合理的间隔。具体多长合适我的经验值是简单问答类间隔 2 到 5 秒。代码生成类等上一次结果完全返回、你确认无误后再提交下一次。批量任务用队列串行处理不要并发轰炸。如果你确实有大量任务要跑用脚本做串行队列 自动重试比手动狂点要稳得多。下面是一个简单的串行处理思路伪代码tasks [任务1, 任务2, 任务3, ...] for task in tasks: success False retries 0 while not success and retries 3: try: result call_model(task) success True except CapacityError: retries 1 sleep(backoff_time(retries)) # 退避等待 switch_to_fallback_model() save_result(result)这里的backoff_time是退避等待重试次数越多等得越久避免密集重试加剧拥堵。3.3 退避策略的参数怎么定退避等待的时间不是随便拍的太短没效果太长浪费时间。我常用的是一套指数退避参数重试次数等待时间说明第 1 次3 秒轻微等待多数瞬时拥堵能缓解第 2 次8 秒中等等待同时切换备选模型第 3 次20 秒较长等待基本能避开短时高峰第 4 次60 秒兜底等待仍失败则转人工处理这套参数是我反复调整后觉得比较平衡的既不会因为等太久而拖慢整体进度又能有效避开大部分瞬时拥堵。你可以根据自己的任务紧急程度微调紧急任务把等待时间砍半非紧急任务可以拉长。注意退避期间不要反复手动重试。手动重试会打乱退避节奏等于白等。交给脚本或工具自动处理。4. 请求体量优化从源头降低资源占用4.1 上下文越长越容易撞墙这一点很多人没意识到你单次请求消耗的资源跟上下文长度是强相关的。上下文越长模型需要处理的 token 越多占用的推理资源越大在资源紧张时越容易被拒。我做过一个粗略的对比测试同样是让模型改一段代码只贴相关函数约 200 行和贴整个文件约 2000 行前者几乎没报过错后者在高峰期报错率明显上升。原因就在于后者单次请求的 token 量是前者的十倍左右。所以精简上下文是降低报错率的硬手段。具体怎么做只贴相关代码不要整个文件往里扔把出问题的函数、相关的类型定义挑出来。清理无关历史长对话里早期的、已经解决的内容可以手动清理或开新会话。用摘要代替全文如果必须提供大背景先用一段话概括而不是贴原始材料。4.2 任务拆分大任务切成小步骤除了精简上下文把大任务拆成小步骤也是有效手段。一个帮我重构整个模块的请求和十个帮我改这个函数的请求虽然总工作量差不多但前者单次资源占用高、容易撞限流后者每次都很轻、成功率高。拆分的粒度怎么把握我的经验是以一次能说清楚、模型一次能返回完整结果为单位。比如不要帮我优化这个项目的性能。而要帮我看看这个函数的循环能不能优化 → 帮我看看这个数据库查询能不能加索引 → 帮我看看这个缓存策略合不合理。这样拆下来每个请求都很轻即使某个请求撞上容量限制重试成本也低不会影响整体进度。4.3 输出长度也要控制很多人只关注输入忽略了输出长度同样消耗资源。你让模型生成一个 5000 行的完整文件和让它生成一个 50 行的函数资源占用天差地别。控制输出的技巧明确要求简洁在提示里加一句只返回修改的部分不要重复未改动代码。分段生成大文件分多次生成每次一个模块。用 diff 而非全量让模型返回差异而不是完整文件。这些技巧不仅降低报错率还能让结果更聚焦、更容易 review一举两得。5. 自动化兜底配置把人工干预降到最低5.1 自动重试与模型轮换的实现思路前面讲的都是手动应对但真正高频使用的人需要的是自动化兜底——报错了自动重试、自动换模型人不用管。这需要在你使用的工具或自己写的调用层里做文章。核心逻辑就三步捕获容量错误 → 等待退避 → 切换模型重试。前面 3.2 节的伪代码已经展示了这个流程。这里补充几个实操要点错误识别要准不同工具报错文案可能略有差异但关键词通常是 capacity、at capacity、try a different model。用关键词匹配即可不要写死整句。模型轮换要有序按备用清单顺序切切到最后一个还失败才判定为彻底不可用。状态要隔离切换模型后如果上下文格式不兼容要能自动开新会话或重置上下文。5.2 一个可参考的配置模板下面这份配置模板是我自己用的结构字段名你可以按实际工具调整但结构逻辑可以直接抄model_strategy: primary: 主力模型 fallbacks: - 备选模型A - 备选模型B - 轻量模型C switch_on_error: true retry_policy: max_retries: 4 backoff_seconds: [3, 8, 20, 60] retry_on: - capacity - at capacity - try a different model context_policy: max_context_tokens: 8000 auto_truncate: true summarize_on_overflow: true这份配置里model_strategy管模型切换retry_policy管重试节奏context_policy管上下文控制。三者配合基本能覆盖大部分容量报错场景。5.3 监控与日志知道什么时候在堵如果你用得比较重建议加一层简单的日志记录记录每次报错的时间、模型、重试次数、最终是否成功。积累一两周你就能看出规律——哪个时段最容易堵、哪个模型最稳、你的平均重试次数是多少。有了这些数据优化就有方向了。比如发现每天下午三点必堵那就把批量任务挪到别的时段发现某个备选模型从来没失败过就把它提到备用清单第一位。日志不用搞得很复杂一个 CSV 文件、几列关键字段就够了时间请求模型是否报错重试次数最终模型结果14:23主力模型是2备选A成功14:25主力模型否0主力模型成功6. 常见问题与排查技巧实录6.1 报错排查速查表实际使用中容量报错往往和其他问题混在一起容易误判。我整理了一张速查表帮你快速定位现象可能原因排查动作报容量错误换模型后正常单纯资源拥堵无需处理继续用备选所有模型都报容量错误账号层级限流或全局高峰错峰使用检查账号状态报容量错误但换模型后报格式错误上下文不兼容开新会话精简上下文频繁报错且间隔很短请求频率过高被限流降低提交频率加退避只有长请求报错单次 token 量过大拆分任务精简上下文特定时段必报错踩中资源高峰调整任务时间这张表覆盖了我遇到过的绝大多数情况。核心判断逻辑是先换模型换完还错就查频率和体量都正常就查时段和账号。6.2 几个反直觉的坑有几个坑比较反直觉单独拎出来说坑一重试太快反而更糟。很多人一报错就立刻重试结果连续撞墙。正确做法是等一等再试给服务端喘息时间。我前面给的退避参数就是干这个的。坑二换模型不一定换资源池。有些工具里看似不同的模型其实共享同一个后端资源池换了个名字但没换池子照样满。这种情况要换到架构上真正独立的模型。坑三免费额度用完后报错变多。部分服务在免费额度耗尽后会把你降到低优先级队列容量报错率上升。这时候要么升级要么接受更频繁的错峰使用。坑四网络抖动会被误判为容量错误。偶尔网络不稳也会触发类似报错但本质不同。区分方法容量错误换模型能解决网络问题换模型也没用且通常伴随超时。6.3 我的独家避坑心得最后分享几条我自己总结的、文档里不会写的心得养成报错即切换的肌肉记忆。别犹豫、别分析先切了再说切完继续干活事后再复盘。犹豫的每一秒都是浪费。备用模型要定期轮换测试。别等到主模型挂了才发现备选也不能用。每周挑个时间主动用一下备选模型确认它们还活着、效果还能接受。把最耗资源的任务安排在低谷。批量重构、大文件分析这类重活尽量挪到凌晨或周末成功率能高一大截。别把鸡蛋放一个篮子。如果你对 AI 编程工具依赖很重最好同时熟悉两三个不同平台的工具一个堵了立刻换另一个而不是干等。这套方法我用了挺长时间容量报错的困扰基本降到了可以忽略的程度。核心就一句话别跟资源拥堵硬刚学会绕、学会等、学会拆。工具是为人服务的摸清它的脾气用起来就顺了。