大模型容量报错全解析：从重试降级到多模型路由的实战方案

1. 这个报错到底在说什么第一次看到Selected model is at capacity. Please try a different model.这条提示的时候很多人第一反应是“我账号是不是被封了”或者“是不是网络出问题了”。其实都不是。这句话翻译过来就一个意思你当前选中的那个模型此刻的并发处理能力已经被占满了服务端暂时腾不出资源来接你的请求。它和“模型不存在”“权限不足”“余额不够”是完全不同性质的错误。后面这几种是硬性拒绝你怎么重试都没用而“at capacity”是软性的、临时性的资源挤兑本质上跟你去热门餐厅吃饭被告知“现在满座了要么等位要么换一家”是一个道理。餐厅没倒闭你也没被拉黑只是这个时间点人太多了。这个提示通常出现在你调用大模型接口、使用在线AI对话工具、或者在某个集成了模型服务的应用里发起请求的时候。触发它的核心条件只有一个目标模型在当前时刻的可用并发槽位已经分配完了。注意是“当前时刻”可能几秒钟之后就恢复了也可能高峰期持续十几分钟。哪些人最容易碰到这个问题我观察下来有这么几类一是做批量任务、短时间内高频调用接口的开发者二是使用热门新模型、大家都挤着去试的那批用户三是在业务高峰期跑自动化流程的团队。如果你只是偶尔手动聊两句就遇到这个提示那说明你选的模型确实太抢手了。理解了这个报错的本质解决思路就清晰了要么等资源释放要么换一个还有余量的模型要么从架构层面让自己不那么依赖单一模型。下面我按从简单到复杂的顺序把几种经过实测的方案逐一拆开讲。2. 最省事的做法换模型与错峰重试2.1 换一个“同级别但没那么挤”的模型遇到容量报错最直接的动作就是换模型。但换模型不是随便换你得知道往哪个方向换。通常同一个服务商会提供多个能力相近但资源池不同的模型。比如旗舰级模型往往最拥挤而次旗舰或者轻量级模型在大多数场景下够用容量也宽松得多。我的经验是建立一个“降级梯队”。以常见的文本生成场景为例你可以这样排优先级模型定位适用场景容量紧张程度1旗舰大模型复杂推理、长文写作最紧张2标准模型日常问答、代码辅助中等3轻量模型分类、摘要、简单对话较宽松4备用服务商模型兜底方案取决于服务商当第一梯队报 capacity 的时候自动切到第二梯队而不是傻等着。这个逻辑写在代码里就是一个简单的 fallback 机制。手动操作的话就是在界面上把模型下拉框换一个再发一次。注意换模型之后输出风格和质量可能会有差异。如果你的任务对格式要求很严格比如必须输出特定结构的 JSON换模型后要重新验证一下输出是否符合预期。2.2 重试的节奏比次数更重要很多人遇到报错就疯狂点重试一秒点五次。这种做法不仅没用还可能让你的请求被限流系统盯上。正确的重试策略是指数退避第一次等 1 秒第二次等 2 秒第三次等 4 秒以此类推加上一点随机抖动。为什么加随机抖动假设有一千个人同时遇到容量报错如果大家都按 1 秒、2 秒、4 秒的固定节奏重试那这些请求还是会撞在一起形成新的峰值。加了随机量之后请求就分散开了成功率明显提升。用 Python 写一个简单的重试逻辑大概长这样import time import random def call_with_retry(client, model, messages, max_retries5): for attempt in range(max_retries): try: return client.chat(modelmodel, messagesmessages) except CapacityError: if attempt max_retries - 1: raise wait (2 ** attempt) random.uniform(0, 1) time.sleep(wait)这段代码的核心就是2 ** attempt加上随机数。实测下来大部分容量报错在 3 次重试之内就能成功因为服务端的槽位释放通常很快。2.3 错峰调用把任务挪到不挤的时间段如果你做的是批量任务比如一次性要处理几千条数据那就没必要跟大家在高峰期抢。观察一下你所用服务的负载规律通常工作日的白天尤其是上午十点到下午四点是请求最密集的时段而清晨、深夜、周末相对宽松。我做过一个对比测试同样的 500 条请求在下午三点跑容量报错率大概在 12% 左右挪到凌晨两点跑报错率降到 1% 以下。当然不是所有人都有条件半夜跑任务但如果你的任务不是实时性的加一个“延迟队列”把非紧急请求排到低峰期执行效果立竿见影。3. 从代码层面把“容量报错”变成可控事件3.1 识别错误类型别把所有异常混在一起很多人的代码里只有一个笼统的except Exception这会导致容量报错和真正的逻辑错误混在一起排查起来非常痛苦。你需要根据服务端返回的错误码或错误信息把容量类错误单独识别出来。不同服务商的错误标识不一样有的返回 HTTP 429有的返回 503有的在响应体里带一个特定的 error type 字段。你得先查清楚你用的那个服务是怎么标记容量问题的。识别出来之后单独走重试或降级逻辑而不是直接让整个程序崩掉。def classify_error(response): if response.status_code 429: return rate_limit if response.status_code 503: return capacity if at capacity in response.text.lower(): return capacity return unknown把错误分类做好之后你的程序就能针对不同情况做不同处理容量问题就重试或换模型权限问题就报警参数问题就直接报错给用户看。3.2 用队列和信号量控制并发量容量报错的本质是“你想要的资源超过了当前可用的量”。如果你自己这边能控制住并发数就能大幅降低撞上容量限制的概率。具体做法是引入一个信号量或者请求队列限制同时发出的请求数量。举个例子假设你开了 50 个线程同时调接口那这 50 个请求会一起冲过去很容易触发容量限制。如果你用一个大小为 5 的信号量控制住同时只有 5 个请求在飞其他的排队等着整体吞吐量反而更稳定。import threading semaphore threading.Semaphore(5) def worker(task): with semaphore: return call_model(task)这个思路在批量处理场景下特别有效。你可能觉得限制并发会降低速度但实际上因为减少了重试和报错处理的时间总完成时间往往是缩短的。3.3 多模型路由让请求自动找到有空位的模型这是我认为最值得投入精力去做的一个方案。核心思想是维护一个模型列表每次请求的时候按优先级依次尝试哪个能用就用哪个。这样即使某个模型满了请求也能自动落到其他模型上对上层业务完全透明。一个简单的路由逻辑可以这样设计MODEL_PRIORITY [model-a, model-b, model-c] def route_request(messages): for model in MODEL_PRIORITY: try: return call_model(model, messages) except CapacityError: continue raise AllModelsBusyError(所有模型都满了稍后再试)进阶一点的做法是给每个模型维护一个“健康分数”记录它最近的成功率和响应时间动态调整优先级。某个模型频繁报容量错误就自动把它降权过一段时间再恢复。这样整个系统就有了自适应能力。提示多模型路由要注意不同模型的输入输出格式可能不完全一致。如果你的业务对输出格式有严格要求需要在路由层做一层适配转换否则会出现“换了模型之后解析失败”的问题。4. 那些我踩过的坑和容易忽略的细节4.1 以为换了模型就万事大吉结果输出格式全乱了有一次我做一个结构化信息抽取的任务原本用的是模型 A输出稳定的 JSON。后来模型 A 容量满了我顺手切到模型 B结果模型 B 返回的是带 markdown 代码块包裹的 JSON还多了一段解释文字。我的解析代码直接崩了。这个坑的教训是降级方案必须提前测试。你不能等到出问题了才第一次尝试备用模型那时候你根本没时间处理格式差异。正确的做法是在系统上线前就把每个备选模型都跑一遍你的典型任务确认输出格式在可接受范围内必要时写好格式适配层。4.2 重试次数设太多反而拖垮了整个流程指数退避是个好策略但如果你把最大重试次数设成 10 次甚至 20 次那就过头了。假设每次等待时间翻倍第 10 次重试要等 1024 秒将近 17 分钟。你的程序就卡在那里干等用户早就跑了。我的建议是最大重试 3 到 5 次总等待时间控制在 30 秒以内。超过这个时间还没成功就应该走降级路径或者直接告诉用户“当前服务繁忙请稍后再试”。快速失败比慢速成功更有价值。4.3 忽略了“容量报错”背后的用量监控容量报错频繁出现往往说明你的调用模式有问题。可能是你的请求量突然增长了可能是你用的模型最近太火了也可能是你的重试策略本身在制造额外的流量。不管哪种情况你都应该有一个监控面板能看到单位时间内的请求数、成功率、容量报错占比这些指标。我自己的做法是每天看一次容量报错率。如果某天突然从 2% 涨到 15%那就说明有问题需要处理了。可能是需要调整模型优先级可能是需要跟服务商沟通配额也可能是自己的代码出了 bug 在疯狂重试。没有监控你就只能被动地等用户来投诉。4.4 把容量报错当成“网络问题”来处理有些人看到报错就加代理、换网络环境这完全是南辕北辙。容量报错是服务端资源调度的问题跟你本地的网络状况没有半点关系。你在家里还是在公司用的是 WiFi 还是有线结果都一样。把时间花在排查网络上纯属浪费。正确的排查顺序是先确认错误信息确实是 capacity 相关然后检查自己的并发量是否过高接着尝试换模型或错峰重试最后才考虑是不是服务商那边整体资源紧张。这个顺序能帮你最快定位到真正的原因。5. 长期策略让自己不再被单一模型卡脖子5.1 建立模型抽象层把“用哪个模型”变成配置项如果你在代码里到处硬编码了模型名称那每次换模型都要改很多地方容易漏改还容易出错。更好的做法是加一层抽象把模型调用封装成一个统一的接口具体用哪个模型通过配置来决定。class ModelClient: def __init__(self, config): self.primary config[primary_model] self.fallbacks config.get(fallback_models, []) def chat(self, messages): models [self.primary] self.fallbacks for m in models: try: return self._call(m, messages) except CapacityError: continue raise ServiceUnavailable()这样你只需要改配置文件就能调整模型优先级不用动业务代码。而且当新的模型出来时你只需要把它加到 fallback 列表里就行扩展成本极低。5.2 对非实时任务采用“提交-轮询”模式如果你做的不是实时对话而是批处理任务那可以考虑把同步调用改成异步模式。具体来说就是先把任务提交到一个队列里然后由后台 worker 慢慢消费。worker 可以根据当前各模型的容量情况动态调整消费速度遇到容量报错就自动等待或切换。这种模式的好处是把“请求时刻”和“处理时刻”解耦了。用户提交任务的时候不需要等待模型可用系统会在后台找合适的时机执行。对于大批量任务来说这是最稳妥的方案。5.3 保留一个“最低可用”的兜底模型不管你的主力模型多强大都应该保留一个容量极其宽松、几乎不会报 capacity 的兜底模型。这个模型可能能力弱一些但胜在稳定。当所有主力模型都不可用时至少还能给用户一个“能用但不够好”的结果而不是直接报错。这个兜底模型的选择标准很简单便宜、快、容量大。它不需要处理复杂任务只需要在极端情况下保证服务不中断。很多服务商都提供这种轻量级模型成本极低但关键时刻能救命。6. 几个实际场景下的处理示范6.1 个人开发者做 side project 的场景如果你只是自己写个小工具偶尔调用一下模型接口那最简单的方案就是捕获容量错误等 2 秒重试一次重试 3 次还不行就提示用户“当前模型繁忙请稍后重试或切换模型”。不需要搞复杂的路由和队列够用就行。手动操作的话就是在界面上给用户一个模型选择下拉框默认选一个报错了让用户自己换。这种“人肉路由”在用户量小的时候完全够用别过度设计。6.2 小团队做内部工具的场景团队内部用的工具用户量不大但也不能动不动就报错。这时候可以加一个简单的自动降级主模型报容量错误时自动切到备用模型同时在日志里记录一次降级事件。每周 review 一下降级频率如果太频繁就考虑调整模型配额或者优化调用逻辑。这个阶段不需要上消息队列但建议把重试和降级逻辑封装成独立的模块方便后续复用和调整。6.3 面向外部用户的产品场景如果你的产品直接面向外部用户那容量报错的处理就必须做得足够优雅。用户不应该看到“at capacity”这种技术术语而应该看到“当前请求较多正在为您切换线路”之类的友好提示。同时后台要有多层降级先重试再换模型再排队最后才提示用户稍后再试。这个场景下监控和告警是必须的。容量报错率超过阈值就要通知到人否则等用户投诉就晚了。另外建议做一个状态页面让用户能看到当前各模型的可用情况管理好用户预期。6.4 批量数据处理场景批量任务最怕的就是跑到一半因为容量报错中断了。我的做法是把任务拆成小批次每批处理完之后记录进度遇到容量报错就暂停当前批次等一段时间后从断点继续。这样即使中途出现问题也不需要从头再来。另外批量任务一定要设置合理的并发上限。我一般从并发 3 开始试观察报错率如果很低就慢慢往上加找到那个“刚好不触发容量限制”的平衡点。这个值因服务商和时段而异需要实际测试才能确定。7. 关于这个报错我最后想说的几点体会处理了这么多次容量报错之后我最大的体会是不要把容量报错当成异常而要把它当成常态来设计。只要你依赖的是共享的云端资源就一定会遇到资源紧张的时候。与其每次出问题临时救火不如一开始就把降级、重试、路由这些机制做进去。另一个体会是简单的方案往往比复杂的方案更可靠。我见过有人为了处理容量报错搞了一套非常复杂的调度系统结果系统本身的 bug 比容量报错还多。其实大多数场景下一个带指数退避的重试加上一个备用模型就能解决 90% 的问题。还有一点就是遇到问题先看错误信息别瞎猜。Selected model is at capacity这句话已经把原因说得很清楚了不需要过度解读。按照“换模型、等一等、控并发、做降级”这个顺序去处理基本都能搞定。最后分享一个小技巧如果你经常遇到某个特定模型容量报错可以在本地维护一个简单的记录记下每次报错的时间和持续时长。积累一段时间之后你就能看出这个模型的繁忙规律从而更精准地安排调用时间。这个习惯帮我省了很多无谓的重试等待。