★ FEATURED ARTICLE 赶工到一半窗口里突然跳出一行英文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 判断问题归属是本端还是服务端碰到任何报错先别急着乱点。花十秒钟判断问题归属能省掉后面一小时的折腾。我一般按这个顺序排查这个报错是只在某一个设备上出现还是所有设备都有——只有一台设备有优先怀疑本端报错信息里是否包含capacityserverlimit这类服务端词汇——包含大概率服务端问题去服务商的状态页看看有没有相关公告——有公告实锤服务端问题安心等待换个网络环境重试——换了就好那是网络问题和模型容量无关。5.3 一套可以复用的排查顺序最后把我个人沉淀下来的通用排查流程给你这段是我踩坑后养成的肌肉记忆不慌先判断是偶发还是持续偶发大多忍一忍就过去了换新会话把当前问题复制到空白会话里重发一次排除会话过长因素降梯队按第一梯队到第三梯队的顺序逐级换模型等窗口设置30秒、1分钟、5分钟的三档等待计划到点再试查状态页去官方状态页确认是否范围性故障走备用通道换端口、换平台、走API什么能用用什么复盘记录把这个时段、这个模型、这个报错记下来下次就能预判。这套顺序适用于所有模型不可用类问题不只是at capacity这一种。我个人实际操作中还有一个很小的习惯分享给你我在备忘录里维护着一张列表写着第一梯队、第二梯队、第三梯队、备用平台、API方案这五个备选入口。遇到报错时我不再临时找方案而是像看菜单一样直接往下走。就是这么朴素的一个小本子让我从被at capacity支配的焦虑里彻底解脱了出来。容量问题说到底就是资源稀缺问题稀缺的时刻总会过去你需要做的只是让自己在稀缺到来时有路可走。
阅读完成 · 觉得有帮助？
