1. 这个报错到底在说什么第一次看到Selected model is at capacity. Please try a different model.这条提示的人十有八九会愣一下模型又不是服务器怎么还有容量一说我当初也这么想直到自己连续踩了几次坑才把这句话背后的逻辑摸清楚。先把结论摆出来这不是你的账号出了问题也不是网络故障更不是提示词写错了。它是一条服务端的资源调度反馈——你当前选中的那个模型此刻的并发处理能力已经被占满了系统没法再给你分配算力于是让你换一个模型再试。打个生活化的比方。你去一家很火的餐厅吃饭前台告诉你大厅满了您要么等位要么去隔壁那家分店。模型服务也是这个道理每个模型背后都挂着一组算力资源能同时处理的请求数是有限的。当同一时刻涌进来的请求超过这个上限后来的请求就会被挡在门外返回这条提示。这条报错在近一两年变得特别常见原因也很直白——用的人多了。尤其是那些热门的大语言模型白天高峰期几乎天天能看到。所以理解它、绕过它、甚至从根上减少它出现的概率是每个重度使用者迟早要面对的功课。这篇文章我打算把这件事讲透它为什么会发生、不同场景下网页端、API 调用、本地部署、第三方客户端分别怎么处理、有哪些立竿见影的应急手段、又有哪些能长期降低触发率的工程化做法。不管你是刚上手的新手还是已经在写自动化脚本的老手都能从里面找到能直接抄作业的部分。提示这条报错和模型不存在权限不足额度用尽是完全不同的四类问题排查时千万别混为一谈否则会浪费大量时间在错误的方向上。2. 报错背后的运行机制拆解2.1 模型容量到底是什么很多人误以为容量指的是模型文件大小或者显存占用其实不是。这里的容量指的是服务端为某个模型预留的并发处理槽位。一个模型对外提供服务时背后通常是一组推理服务器。每台服务器能同时处理的请求数是有上限的这个上限由显存大小、批处理策略、单次请求的平均长度共同决定。把所有服务器的并发槽位加起来就是这个模型此刻的总容量。当请求量超过总容量多出来的请求有两个去处要么排队等待要么直接被拒。返回at capacity这条提示说明系统选择了后者——直接拒绝让你换模型。这么做的好处是避免请求堆积导致整体响应变慢坏处就是用户体验上会突然撞墙。2.2 为什么偏偏是这个模型满了你可能会问为什么同一个平台有的模型能用有的就满了关键在于模型之间的资源是隔离的。热门模型通常是能力最强、口碑最好的那几个会吸引绝大多数请求它们的槽位长期处于饱和状态而一些冷门模型、老版本模型、专用模型用的人少槽位常年空闲。这就解释了为什么报错信息里特意强调try a different model——系统知道别的模型还有余量只是你选的那个太抢手了。从平台的角度看这是一种负载均衡的引导策略从用户的角度看这是一次被迫的降级或换道。2.3 触发这条报错的几种典型场景我把实际遇到的情况归了归类大致有这么几种场景典型表现触发原因网页端手动对话高峰期频繁出现刷新后偶尔能进热门模型并发饱和API 批量调用脚本跑一半突然大批量失败瞬时并发超过配额第三方客户端换模型后恢复正常客户端默认锁定了热门模型本地部署提示类似但措辞不同本地显存/内存不足属于另一类问题自动化工作流定时任务在固定时段失败恰好撞上平台高峰看清楚这张表很重要。因为只有前三种是真正的服务端容量问题本地部署那条其实是资源不足排查方向完全不同。很多人一看到capacity就往服务端想结果在本地环境里绕了半天圈子。2.4 容量限制和配额限制的区别这里必须单独拎出来讲因为混淆这两者是新手最容易犯的错。容量限制是瞬时的、动态的。它取决于此刻有多少人在用下一秒可能就恢复了。你刷新一下、等几分钟、换个模型往往就好了。配额限制是累计的、静态的。它取决于你的账户等级、付费情况、单位时间内的调用总量。一旦触顶通常要等到下一个计费周期才能恢复换模型也没用。区分方法很简单如果换模型能解决那就是容量问题如果换什么模型都报错那大概率是配额或者账号问题。记住这个判断口诀能帮你省下大量排查时间。3. 应急处理五分钟内让请求跑起来3.1 最直接的办法换模型既然报错信息都明说了try a different model那就照做。这是成本最低、见效最快的一招。具体怎么换取决于你用的入口网页端通常在对话框上方或设置里有个模型下拉菜单选一个当前不那么热门的即可。一般来说能力稍弱一档的模型、或者带miniliteturbo后缀的版本空闲率会高很多。API 调用把请求体里的model字段改成另一个模型名。这一步在代码里就是改一个字符串几秒钟的事。第三方客户端进设置页找到模型配置项切换默认模型。我实测下来的经验是同一家的旗舰模型和轻量模型之间切换成功率差异非常明显。高峰期旗舰模型十次有七八次撞墙轻量模型基本随叫随到。如果你的任务对模型能力要求没那么极致日常用轻量版完全够用。3.2 错峰使用把请求挪到低谷时段如果任务不紧急最省心的办法就是避开高峰。根据我长期的观察模型服务的使用高峰大致集中在工作日的白天尤其是上午十点到下午五点这段。深夜和清晨是明显的低谷这时候几乎不会遇到容量报错。对于能延迟执行的任务比如批量翻译、文档总结、数据清洗完全可以挂到深夜跑。我自己有个习惯把不着急的批处理任务写成脚本用系统的定时功能安排在凌晨执行一年下来几乎没再见过这条报错。3.3 重试机制给请求加一层缓冲对于程序化调用光靠换模型和错峰还不够因为网络请求本身就有随机性。这时候需要给代码加自动重试。一个稳妥的重试策略应该包含三个要素指数退避第一次失败等 1 秒第二次等 2 秒第三次等 4 秒依次翻倍。这样能避免短时间内反复冲击已经饱和的服务。随机抖动在等待时间上加一点随机量防止大量请求在同一时刻集体重试形成惊群。模型降级重试若干次仍失败就自动切换到备用模型。下面是一段可以直接参考的伪代码逻辑import time import random def call_with_retry(primary_model, fallback_model, max_retries3): models [primary_model, fallback_model] for attempt in range(max_retries): current_model models[min(attempt, len(models) - 1)] try: return do_request(current_model) except CapacityError: wait (2 ** attempt) random.uniform(0, 1) time.sleep(wait) raise Exception(所有模型均不可用请稍后再试)这段逻辑的核心思想是先试主力模型失败就退避等待再失败就降级到备用模型。三层保险叠下来绝大多数瞬时容量问题都能被自动消化掉不需要人工干预。注意重试次数不要设太多。设成十次八次一旦服务真的长时间不可用你的脚本会卡在那里很久。三次左右是比较合理的平衡点。3.4 检查是不是自己打太猛了有时候问题不在服务端而在你自己。如果你在短时间内发起了大量并发请求很容易把自己的配额瞬间打满表现出来就像是模型满了。排查方法看看你的代码里有没有循环里直接发请求、有没有开几十个线程同时调用。如果有把并发数降下来加上请求间隔问题往往就消失了。我见过一个典型的反面案例有人写了个脚本用多线程一次性提交几百个请求结果全部报容量错误还以为是平台的问题。实际上是他自己的并发策略太激进把瞬时压力拉满了。改成串行加小间隔之后一次都没再报错。4. 不同使用场景的针对性方案4.1 网页端用户的处理思路网页端是最简单的场景因为你能做的操作有限但恰恰也最省心。遇到报错时按这个顺序试先刷新页面有时候只是瞬时抖动。刷新无效就换模型从下拉菜单里挑一个别的。换模型还不行就等几分钟再回来。如果一整天都这样那可能是平台整体负载高换个时间段再来。网页端有个小技巧把常用的几个模型都试一遍记住哪个在高峰期最稳。时间长了你就有一套自己的备用模型清单遇到报错直接切过去不用现找。4.2 API 开发者的工程化处理对写代码的人来说处理这条报错不能只靠手动得把它变成程序的一部分。第一层请求层重试。上面讲的指数退避加重试封装成一个通用的请求函数所有调用都走它。第二层模型池。不要只配一个模型配一组。按能力排序主模型失败就往下顺延。这样即使某个模型长期饱和你的服务也不会中断。第三层监控告警。记录每次容量报错的时间、模型、重试次数。如果某个模型连续多天在固定时段报错说明它长期过载可以考虑把它从主力位置换下来。第四层队列削峰。如果业务允许异步把请求丢进消息队列由消费者按可控速率慢慢处理。这样即使上游瞬时压力大也不会直接打到模型服务上。这四层叠起来基本能做到用户无感知。我自己维护的几个自动化流程加了这套机制之后容量报错从每天几十次降到了几乎为零。4.3 第三方客户端的配置要点第三方客户端的问题在于它们往往有自己的默认配置你可能根本没注意到它锁定了哪个模型。处理步骤进设置找到模型相关的配置项确认当前默认模型是什么。如果默认是热门旗舰模型改成轻量版或者备用模型。看看有没有自动切换模型之类的选项有就打开。部分客户端支持配置多个模型做故障转移这个功能强烈建议开启。有个坑要提醒有些客户端把模型配置藏在比较深的地方或者需要手动编辑配置文件。改之前先备份改完记得重启客户端让配置生效。4.4 本地部署场景的辨析前面提过本地部署如果出现类似提示性质完全不同。本地没有服务端容量这回事报错通常意味着你的硬件资源不够。常见原因和对策现象可能原因解决方向加载模型就失败显存/内存不足换更小的量化版本运行中突然中断显存被占满降低上下文长度、减小批大小提示并发超限本地服务并发配置过低调整服务启动参数响应极慢后报错硬件性能瓶颈换更小的模型或升级硬件判断方法本地报错时先看任务管理器或显卡监控确认是不是资源打满了。如果是那就是硬件问题跟服务端容量无关别往错的方向排查。5. 从根上降低触发概率的长期策略5.1 建立自己的模型梯队不要把所有任务都压在同一个模型上。我的做法是建一个梯队第一梯队能力最强用于复杂推理、高质量写作接受它偶尔不可用。第二梯队能力均衡用于日常问答、常规处理作为主力。第三梯队轻量快速用于格式转换、简单分类几乎不会饱和。任务来了先判断复杂度再决定用哪一档。这样既保证了效果又分散了压力。实测下来整体成功率能提升一大截。5.2 缓存重复请求很多人的调用其实是重复的——同样的提示词、同样的输入反复问。这种完全可以缓存。做法很简单把模型名 提示词 输入内容拼成一个键请求前先查缓存命中就直接返回不命中再调模型。对于问答类、模板类任务缓存命中率能到相当高的水平等于变相减少了对模型服务的压力。5.3 批处理合并请求如果你要处理大量小任务别一个一个发。能合并的合并成一次请求能批量的走批量接口。举个例子要翻译一百条短句逐条调用就是一百次请求合并成一次批量调用就只占一个槽位。请求数降下来撞上容量限制的概率自然就低了。5.4 关注平台的状态和公告主流平台通常会有服务状态页面或者公告渠道会提前告知维护、扩容、限流等信息。养成偶尔看一眼的习惯能帮你提前避开一些已知的高峰时段。另外平台调整模型可用性、下线旧模型、上线新模型这些信息也会影响你的模型选择策略。保持关注及时调整配置。6. 常见问题速查与避坑经验6.1 高频问题速查表问题判断依据处理方式换模型能好换一个就正常确认是容量问题配置模型池换模型也不行所有模型都报错查配额、账号、网络只在特定时段报错每天固定时间错峰执行或加重试本地部署报错资源监控打满换小模型、调参数报错后一直不恢复持续数小时可能平台故障等待或换平台偶发一两次无规律正常抖动重试即可6.2 我踩过的几个坑坑一把容量问题当成账号问题。有次我连续报错第一反应是账号被封了折腾半天查设置最后发现只是高峰期。教训是先换模型试一下一秒就能排除大半可能。坑二重试没有退避。早期我写的重试是失败立刻重发结果越重发越失败因为服务本来就满你还猛冲。加上指数退避之后成功率立刻上来了。坑三忽略上下文长度的影响。长上下文请求占用的资源更多更容易触发容量限制。后来我把超长文档拆成几段分别处理报错明显减少。坑四第三方客户端默认模型没改。用了很久才发现客户端一直锁着最热门的模型难怪天天报错。进设置改一下世界清净了。6.3 几条实用的避坑建议永远准备一个备用模型别把鸡蛋放一个篮子里。重试一定要带退避和抖动这是工程常识。记录报错日志时间长了能看出规律帮你优化策略。别在高峰期跑大批量任务能挪就挪。本地部署和云端调用分开排查别混着来。定期检查客户端和服务配置防止默认值坑你。7. 一个完整的处理流程示例把前面所有内容串起来遇到这条报错时我通常按这个流程走第一步看报错出现的场景。是网页端、API 还是本地先定位大类。第二步如果是网页端或 API立刻换一个模型试。能通就说明是容量问题继续往下不能通就查配额和账号。第三步确认是容量问题后给请求加上重试和模型降级逻辑让它以后能自动处理。第四步评估任务紧急程度。不紧急就错峰紧急就靠模型池硬扛。第五步长期优化建模型梯队、加缓存、合并批量请求、监控报错规律。这套流程我用了很久基本覆盖了所有能遇到的情况。刚开始可能觉得步骤多熟练之后就是条件反射几秒钟就能判断该走哪条路。说到底Selected model is at capacity这条报错本身不可怕它只是服务端在告诉你现在有点挤。真正重要的是理解它背后的机制然后建立一套能自动应对的体系。手动换模型只能救急工程化的处理才能一劳永逸。我个人在实际操作中的体会是与其每次报错都手忙脚乱不如花半天时间把重试、降级、缓存这几件事做扎实。做完之后你会发现这条曾经让人头疼的提示慢慢就从你的日常里消失了。