赶工到一半，窗口里突然跳出一行英文：Selected model is at capacity. Please try a different model.不管怎么点重试，它都像复读机一样重复。如果你最近经常用各种大模型工具写东西、改代码，十有八九撞过这堵"隐形墙"。这行提示翻译过来就是：你选的模型现阶段容量已满，请换个模型试试。今天这篇不绕弯子，直接带你搞懂这句话背后的原因、完整的排查思路和一套能落地的解决办法。
这篇文章适合所有被这个报错卡过的人——不管是普通用户、内容创作者，还是把模型接进业务流程的技术人。文章前半部分讲原理和原因，后半部分是可直接照做的操作步骤，以及我踩过几次坑之后总结出的长期策略。
1. 这个报错到底在说什么：先弄懂"容量已满"的含义
1.1 表面意思与背后的服务端机制
"Selected model is at capacity"字面上说的是"当前选中的模型已满负荷"。这句话里的关键词是capacity——容量、吞吐能力。在大模型服务的架构里，所有用户请求都要被分配到具体的GPU推理节点上做计算，而每一块GPU能同时处理的并发请求数量是有限的。当某一时刻请求数量超过了节点能承载的上限，服务端就会返回这个提示，相当于告诉你：这个模型入口暂时挤不进去了。
你可以把它理解成一家热门餐厅。餐厅座位就那么多，来吃饭的人多了，门口就得排队，排不下时干脆挂出"客满"的牌子。模型容量已满，和餐厅客满是一回事——不是菜有问题、不是你的点单有问题，纯粹是同一时间想吃这家的人太多了。
1.2 为什么这件事和你自己的设备、网络关系不大
遇到这个报错，很多人的第一反应是：是不是我网络不好？是不是浏览器缓存有问题？是不是我的账号被限制了？我一开始也是这么想的，结果换手机、换电脑、换Wi-Fi、换浏览器，折腾一圈下来，错误依然原封不动地出现在屏幕上。
后来我慢慢摸清了规律：这是一条典型的服务端返回消息，不是客户端错误。换句话说，你本地做得再完美也没用，问题出在服务商的服务器一端。判断方法很简单——如果你换设备、换网络、换浏览器后错误依旧，而服务商的状态页（status page）上写着"部分模型降载"之类的公告，那基本可以确定是服务端容量告急，不是你的锅。
2. 为什么偏偏是你遇到：触发该提示的常见场景与深层原因
2.1 高峰期效应：全球用户一起赶同一趟车
容量问题最直接的影响因素就是并发量。大模型服务的用户遍布全球，但流量有非常明显的"潮汐"特征。以我观察到的规律为例：工作日的上午九点到十一点、下午两点到五点，以及晚上七点到十一点，是各平台访问量最大的窗口。尤其是一些新功能发布、媒体集中报道之后，短时间涌入的用户量可以轻松把容量池冲垮。
我有一次就撞在风口浪尖上：某个模型刚推出新版本，全网都在晒效果，我也想凑个热闹，结果连续两天打开都是"at capacity"。第三天凌晨两点再试，一路畅通无阻——高容量时段和低容量时段的体验差距，就是这么夸张。
2.2 免费档位与付费账号的"分车道"逻辑
另一个容易被忽略的原因是账号等级不同，拿到的容量资源也不同。大多数大模型平台在架构上是分层设计的：付费用户走独立的计算资源池，免费用户共享另一组相对小很多的资源池。当免费池被挤爆时，免费用户就会频繁看到容量提示；而付费用户在同一时刻可能完全无感。
这就像高速公路的收费车道和免费车道——大家都在排队，但收费车道因为数量少、车流分散，反而通行效率更高。平台这么做，一方面是为了保障付费用户体验，另一方面也是控制成本。所以，如果你长期在免费档位上被这个报错折磨，真不是你的设备出了毛病，大概率是"车道"本身容量就有限。
2.3 会话过长与上下文膨胀的隐形放大效应
这个点很容易被忽略，但它对容量消耗的影响非常大。一个持续了几个小时、塞满了历史消息和长文档的长对话，在服务端占用的显存空间，可能是新对话的好几倍。你一个长会话占用的资源，相当于别人几十个短会话。
我在实际使用中验证过这个逻辑：同样是热门时段，新建一个空白对话发同一个问题，能正常返回；但在一个已经贴了上万字资料、来回修改了二十多轮的旧会话里发同样的消息，就大概率触发"capacity"提示。这不是玄学，而是长上下文把每一轮请求的计算量推高了，服务端在容量吃紧时会优先拒绝重负载请求。遇到报错时，第一步往往不是"换个模型"，而是"换个新会话"。
2.4 服务商的容量规划黑盒：我们永远不知道的变量
老实说，服务商到底有多少GPU、怎么调度、什么条件下触发这个提示，对用户来说是个黑盒。有时候模型明明整体没崩，但某个地区的某个节点满载了；有时候平台刚上线新模型，旧模型被缩减资源，结果大家都挤旧模型，把旧模型又挤爆了。这些信息都藏在服务商的内部调度策略里，用户能看到的只有一句冷冰冰的"try a different model"。
明白这是黑盒，对我最大的帮助是少做无意义的折腾——比如反复刷新页面、重登账号。这些操作对客户端问题有用，对服务端容量问题基本无效。与其和黑盒较劲，不如把精力放在下面这套实际操作路径上。
3. 从按下重试到换模型：一份完整的解决路径清单
3.1 第一步：等待后退式重试，别疯狂刷新
遇到容量报错时，人的本能是立刻点重试。但我的实测经验是：连续快速重试大概率会加重排队，甚至延长等待时间。正确做法是"等待后撤式重试"——第一次失败后，先等30秒再试；还不行，延长到1分钟；再不行，等5分钟再来。全程不要超过三次，三次都失败就说明这个时段确实挤不进去，去做别的事，过半小时再回来看。
这背后的逻辑是服务端的限流机制：短时间内反复请求同一个模型，你的请求会被标记为"重试风暴"，调度系统出于保护会降低你的优先级。反而是"探一下，歇一下"的节奏更容易在缝隙里挤进去。
3.2 第二步：按能力梯队切换模型，而不是随便换
"Please try a different model"这句提示本身就是服务商给的方向——换模型。但换也要讲策略。我的习惯是给手上的模型排一个能力梯队：
| 梯队 | 用途 | 容量挤爆时的表现 |
|---|---|---|
| 第一梯队：旗舰模型 | 复杂推理、长文写作、代码生成 | 最容易爆，高峰几乎必现 |
| 第二梯队：均衡型模型 | 日常问答、中等难度任务 | 偶尔爆，恢复较快 |
| 第三梯队：轻量/快速模型 | 翻译、摘要、简单改写 | 很少爆，基本随时可用 |
遇到"at capacity"时，不要直接跳两级，而是先降到第二梯队。很多任务其实用不到旗舰模型的全部能力，第二梯队完全能扛住。只有第二梯队也不行了，再考虑第三梯队兜底。这样既保证了任务质量，又不会因为频繁换模型导致上下文风格突变。
3.3 第三步：新建会话、缩短上下文，给服务端"减负"
正如前文所说，长会话是容量消耗大户。当容量告急时，我的急救顺序是：
- 先把当前问题复制出来；
- 新建一个空白会话，粘贴必要的问题描述；
- 如果问题涉及长文档，只截取关键段落，而不是整篇贴进去。
这样做有三重好处：一是新会话请求的计算量小，更容易被调度系统接受；二是上下文干净了，模型输出的相关性反而可能更高；三是心理上也算洗牌重来，不用被前面二十轮的思路带偏。
3.4 第四步：换入口、换平台双保险
如果你在同一时间真的很急，还有两个入口级的操作值得试。
换入口：很多大模型服务同时提供网页端、桌面端、移动App和API接口。这四个入口背后的资源池有时候并不完全互通。我的经验是：网页端报容量，API接口偶尔还能通；App端报容量，网页端反而恢复了。概率不高，但值得一试。
换平台：手上最好有两个以上不同厂商的大模型服务。这不算什么高深的策略，纯粹是"鸡蛋不放一个篮子"的朴素真理。有备选平台时，遇到"at capacity"的焦虑感至少下降一半。
4. 治本之策：梯队切换、错峰使用与账户层面的优化
4.1 错峰使用：把重要任务排进"低峰窗口"
如果你和我一样，是那种几乎天天都要用大模型干活的人，靠"撞运气"式的重试不是长久之计。我的经验是把重要任务固定安排在低峰时段。从我这几个月的高频使用体感来看：
- 凌晨零点到早上六点：基本畅通无阻，适合跑批量任务；
- 早上七点到九点：人逐渐多起来，但还扛得住；
- 上午十点到下午四点：时好时坏的随机时段；
- 晚间七点到十二点：高峰中的高峰，能避开就避开。
当然，不同服务商的低峰窗口会有差异，你可以通过观察自己最容易撞报错的时段反推，然后给重要任务做时间排期。
4.2 订阅与套餐的容量优先级差异
再说一次免费和付费的差别，因为这直接决定了你的报错频率。如果你发现"capacity"提示频繁到影响工作了，认真考虑升级付费方案可能才是最省时间的决定。付费不只是解锁更多功能，更重要的是在容量紧张时优先获得推理资源。很多平台在容量吃紧时有一个"软性降级"机制：免费用户被引导去换模型，付费用户则被保留在原模型池里继续使用。
我的个人建议是：先试用一个月的付费档，观察报错频率是否明显下降。下降明显，证明你的工作流对容量敏感度很高，这笔钱花得值；下降不明显，再降回免费档也不亏——毕竟试用期给了你真实数据。
4.3 用API分流：接口调用和网页版是两套生态
网页版和个人账号绑定的是一个对话式交互系统，而API是另一套按token计费的独立服务。两者在很多平台上不仅计费方式不同，资源调度池也不同。我自己在大量内容生产场景里，更倾向于用API方式跑任务，因为API的用户基数远小于网页版，遇到"capacity"的概率低很多。
如果你有一定的技术基础，可以写一个简单的批量调用脚本，把文档处理类的任务都走API来完成。遇到网页版报错时，API照样能干活，这就形成了一道天然的业务护城河。
4.4 无解时刻的兜底方案：本地模型和备用工具
即便做了以上所有操作，总有一些极端时刻——平台全面故障、某个模型持续半天以上不可用。这种时候，我的兜底方案是本地模型和备用工具。
本地跑一个小规模的开源模型，处理摘要、分类、改写这类轻量任务完全够用；更重的任务等云端恢复后再继续。虽然本地模型的效果和旗舰模型有差距，但在"有"和"没有"之间，有总比没有强。备选工具的范围还可以更宽一些——比如字典、翻译工具、传统搜索引擎，它们有时候比一个卡住的AI模型更可靠。
5. 同类报错与通用排查思路：一次搞懂"模型不可用"家族
5.1 常见的"兄弟报错"清单
用多了大模型，你会发现"at capacity"不是一个孤立问题，它有一个亲戚家族。把这些报错放在一起看，排查思路能更清晰：
| 报错信息 | 含义 | 与"at capacity"的差异 | 主要解法 |
|---|---|---|---|
| Selected model is at capacity | 模型容量满 | 本文主题 | 等待、换模型、错峰 |
| Too many requests in current hour | 超出小时限额 | 和你的账号配额相关 | 等配额刷新或升级套餐 |
| The server is busy. Please try again | 服务器繁忙 | 范围更大，可能影响所有模型 | 稍后重试 |
| 429 Too Many Requests | 请求过于频繁 | 本地调用层面，API更常见 | 降低请求频率 |
| Model not found / not available | 模型不存在或已下架 | 配置或版本问题 | 检查模型名称、切换版本 |
5.2 判断问题归属：是本端还是服务端
碰到任何报错，先别急着乱点。花十秒钟判断问题归属，能省掉后面一小时的折腾。我一般按这个顺序排查：
- 这个报错是只在某一个设备上出现，还是所有设备都有？——只有一台设备有，优先怀疑本端；
- 报错信息里是否包含"capacity""server""limit"这类服务端词汇？——包含，大概率服务端问题；
- 去服务商的状态页看看有没有相关公告？——有公告，实锤服务端问题，安心等待；
- 换个网络环境重试？——换了就好，那是网络问题，和模型容量无关。
5.3 一套可以复用的排查顺序
最后把我个人沉淀下来的通用排查流程给你，这段是我踩坑后养成的肌肉记忆：
- 不慌：先判断是偶发还是持续，偶发大多忍一忍就过去了；
- 换新会话：把当前问题复制到空白会话里重发一次，排除会话过长因素；
- 降梯队：按第一梯队到第三梯队的顺序逐级换模型；
- 等窗口：设置30秒、1分钟、5分钟的三档等待计划，到点再试；
- 查状态页：去官方状态页确认是否范围性故障；
- 走备用通道：换端口、换平台、走API，什么能用用什么；
- 复盘记录：把这个时段、这个模型、这个报错记下来，下次就能预判。
这套顺序适用于所有"模型不可用"类问题，不只是"at capacity"这一种。
我个人实际操作中还有一个很小的习惯分享给你：我在备忘录里维护着一张列表，写着"第一梯队、第二梯队、第三梯队、备用平台、API方案"这五个备选入口。遇到报错时，我不再临时找方案，而是像看菜单一样直接往下走。就是这么朴素的一个小本子，让我从被"at capacity"支配的焦虑里彻底解脱了出来。容量问题说到底就是资源稀缺问题，稀缺的时刻总会过去，你需要做的，只是让自己在稀缺到来时有路可走。
