调试AI应用的时候，突然在日志里看到一句Selected model is at capacity. Please try a different model.，第一反应多半是以为密钥失效或者欠费了。查了一圈发现账户没问题、额度还在，但请求就是打不进去，卡在那一排红字上。这个报错我在本地调试、线上压测、帮朋友看脚本的时候都遇到过，属于那种“提示写得很明白、但很多人不知道该往哪使劲”的经典容量类错误。
这篇文章把这件事彻底讲透，从报错背后的容量机制、触发场景，到应急换模型的正确姿势，再到代码层面的重试降级、请求调度和架构层面的容量规划，一次性给全。不管你是刚接触AI接口的新手，还是正在维护调用量较大的AI应用，都能从这里找到可以直接落地的解决方案。
1. 先搞懂这个报错到底在说什么：容量机制与触发条件
很多人的误区是把它当成普通的报错去搜代码、查密钥，其实这行提示的本质是一句服务端负载状态通知。它告诉你的不是“你错了”，而是“你现在要用的这台模型实例，已经满载了”。
1.1 报错文字背后的三层含义
第一层含义：你选中的模型，当前所在的推理实例没有空闲资源了。服务商把同一型号的模型部署在一批GPU实例上，所有用户的请求共享这批算力。当某个时刻请求量突然增加，或者有用户提交了超长上下文的请求，实例的计算资源被打满，新的请求就只能排队或者被直接拒绝。
第二层含义：服务商在引导你做流量迁移。那句“Please try a different model”不是客套话，而是明确告诉你：换一个模型实例，或者换一个模型版本，就能绕开当前满载的节点。这跟高速公路堵车让你换路是一个意思，不是你的车出了问题，是这条路堵了。
第三层含义：这个报错多数情况下是临时的。容量是动态波动的，过几分钟同一个模型可能又空了。所以它不是永久性封禁，也不是密钥失效，跟计费、权限都没什么关系。
1.2 什么情况下最容易撞上容量限制
我把这些年踩过的触发场景整理了一下，基本逃不出这几类：
| 触发场景 | 具体表现 | 典型时间段 |
|---|---|---|
| 全民热门模型上线 | 新模型发布当天调用量暴增，实例扩容跟不上 | 发布后24~72小时内 |
| 工作时段高峰 | 上班时间集中调用，免费档和低档套餐的用户被限流 | 早9点~11点，下午2点~5点 |
| 长上下文请求爆炸 | 有人提交几十万token的文档分析，单个请求占住实例 | 随时可能发生 |
| 并发突发 | 你的脚本一次性发出几十个并发请求，自己把自己的连接打满 | 批量任务启动时 |
| 服务商主动控量 | 特权用户或付费更高的用户优先，低档用户被腾挪 | 高峰期持续存在 |
有一个特别容易忽略的点：长上下文请求对容量的消耗远超普通请求。一个处理5万token文档的请求，占用的显存和时间可能是普通对话的几十倍。这意味着即使总请求量不大，只要有几个重量级请求进来，实例一样会被打满。这也是为什么有时候你上午跑得好好的，下午突然就报capacity错误——因为你自己的请求变重了。
时间上也有明显规律。我观察到一个现象：很多国外模型服务在北美时区的白天高峰，以及国内用户集中使用工作时段，报错频率明显更高。如果你发现某个模型在固定时间段频繁提示容量不足，那基本可以断定是时区性的使用高峰，而不是你自己的配置问题。
2. 最快见效的解法：换模型与换实例的策略
既然报错本身就在建议你“try a different model”，那最直接的对应动作就是换模型。但“换”这个动作有讲究，不能随便换一个就完事，否则可能遇到输出质量下降、接口参数不兼容、功能缺失等新问题。
2.1 “换模型”不是一句废话，关键是怎么换
先说最朴素的换法：在调用代码里把模型名改掉。比如原来调用的是某个旗舰级模型，遇到容量报错后换成它的上一代版本，或者换成同一厂商的轻量版模型。这一步很简单，难点在于怎么快速判断该换到哪一个。
我自己的经验是建立一个“模型梯队”的概念。把你要用的模型按能力分成三个梯队：
- 第一梯队：旗舰模型，负责复杂推理、长文生成、代码编写这类高质量任务；
- 第二梯队：主力模型，均衡型和成本型，负责日常对话、结构化输出、大部分业务场景；
- 第三梯队：轻量模型，负责分类、抽取、打分、格式化这类简单任务。
遇到容量报错的瞬间，不要往下乱跳，而是按照“同梯队替换优先、跨梯队降级兜底”的顺序来。比如第一梯队满了，先试第二梯队里的主力版本；第二梯队也满了，再考虑第三梯队。这样能最大程度保证输出质量不掉太狠。
另一个细节是：留意服务商提供的模型名称后缀。很多厂商会在API文档里把同一模型分成不同上下文长度或不同量化精度的版本，名称上会有细微差别。这些版本被部署在不同的推理实例上，负载情况各不相同。高峰期大版本满了，小版本往往还能进。
2.2 利用请求参数实现自动降级
手改模型名只能应对“偶尔撞一次”的情况，如果你在跑自动化任务，不可能每报错一次就手动切一次。这时候需要把换模型变成配置项，甚至变成代码里的自动逻辑。
一种常见做法是在请求层做多模型路由。如果你使用的是带有网关层的API服务，通常可以在网关设置里配多个模型，网关会自动把请求分发到可用实例上。如果你用的是某个厂商的原生SDK，就得自己在代码里实现降级逻辑。思路很简单：
# -*- coding: utf-8 -*- MODEL_TIERS = { "tier1": [ "premium-flagship", "premium-prev-gen", ], "tier2": [ "main-sonnet", "main-haiku-lite", ], "tier3": [ "fast-tiny", "fast-micro", ], } def pick_model(task_type): """根据任务类型返回可尝试的模型列表""" if task_type == "complex": return MODEL_TIERS["tier1"] + MODEL_TIERS["tier2"] if task_type == "normal": return MODEL_TIERS["tier2"] + MODEL_TIERS["tier3"] return MODEL_TIERS["tier3"]然后在调用循环里逐个尝试，遇到容量报错就自动切到下一个模型。这里有一个很重要的坑：降级之后必须重新校验输出质量，尤其是做JSON结构化输出的朋友。不同模型的标点习惯、字段格式、甚至是否输出多余文字都会不一样。我的建议是降级方案里带上一个轻量的输出校验层，发现格式不对就再往下一个梯队切。
还有一个细节是调上下文长度。同一条请求，上下文越长，对实例的占用量越大，越容易被容量限制拒绝。遇到反复容量报错时，可以试试把请求里携带的历史消息精简一下。有时候只是日志里堆积了太多无意义的中间轮次，把这些修剪掉，请求占用的资源立刻降低，实例就能接住了。
提示：修剪上下文不仅是为了省钱，更是为了降低单请求的计算资源占用，这在高峰期对容量报错的缓解效果立竿见影。
2.3 换模型后的第一件事：验证输出协议
这块单独拿出来说，是因为我在实际项目里栽过跟头。有一次为了绕开容量报错，把请求从旗舰模型换到了轻量模型，结果下游的JSON解析直接崩了。排查了很久才发现，轻量模型返回的内容里多了一段解释文字，把原本严格的JSON格式污染了。
所以任何自动降级策略上线前，都要准备一组黄金测试用例。这组用例覆盖你业务里最核心的几种请求类型，比如“提取订单信息”“生成摘要标题”“分类用户反馈”。切换模型后先在这组用例上跑一遍，比对字段完整率、格式正确率和语义准确率，达标了再让降级逻辑全量生效。不要等到线上用户投诉了再回头排查。
3. 代码里防患于未然：超时、重试与退避机制
换模型是应急手段，而真正让系统稳定的，是在代码层面把“容量报错”当成一种可预期的异常来治理。这就像写网络请求必须处理超时和断网一样，调用大模型接口也必须处理容量不足和限流。
3.1 指数退避重试的正确写法
遇到容量报错时的第一反应是重试，这个方向没错，但重试的方式决定你是在解决问题还是在制造雪崩。
错误示范：报错之后延迟1秒立即重试，还不行就再延迟1秒，连续重试10次。这种做法的结果是：你的请求不断撞上还在满载的实例，既消耗自己的时间，还给服务端持续增加无效负载，可能把其他用户的请求也拖到一起排队。
正确做法是指数退避加上随机抖动。第一次重试等2秒，第二次等4秒，第三次等8秒，时间翻倍，并且每次加上一个随机偏移量。这样做的道理是：指数增长让重试窗口避开服务端的持续高峰期，而随机抖动则避免多个客户端在同一时刻同时重试造成二次峰值。
参考实现：
import time import random def call_with_retry(func, retries=6, base_delay=2): for attempt in range(retries): try: return func() except CapacityError as e: if attempt == retries - 1: raise delay = base_delay * (2 ** attempt) + random.uniform(0, 1) time.sleep(delay) return None实践中我建议重试上限控制在5到7次。低于5次可能等不到服务端恢复，高于7次则大部分情况下是在浪费时间。另外，重试前后最好记录一下请求耗时和报错上下文，这样你就能从日志里看出服务端到底多久才恢复。
3.2 超时设置：别让任务卡死在排队里
很多人忽略超时参数与容量报错的关系。容量满载的实例不一定立刻返回报错，有些服务端的表现是请求进入等待队列，一直挂着直到超时。如果你没有设置合理的超时时间，一个任务可能会卡上几十秒甚至几分钟，而用户那边早就等得不耐烦了。
我常用的逻辑是这样的：把超时时间设成三个层级。连接超时设置得短一些，比如3到5秒；写超时也是类似；读取超时根据任务复杂度来，普通对话设20秒，长文档处理可以放到2分钟以上。这样既保证简单请求快速失败，又不会误伤重量级任务。
这里有个细节值得注意：很多SDK默认的读取超时非常宽松。当容量报错发生后，请求不会立刻返回，而是会在服务端排队。如果你的读取超时设得很大，任务会一直阻塞在网络上，导致整个线程被拖死。所以我建议在重试之外，还要设计一个“总时间预算”。比如一个批量任务，规定每个请求最多花90秒，不管中间重试了多少次，到了总预算就放弃并记录失败。这样可以防止个别请求把整个批次的执行时间拖爆。
3.3 并发控制：不要一次性打满所有连接
容量报错跟自己的并发请求数量有直接关系。我的一个实际经历是：用脚本一次性发50个并发请求去处理一批文档，结果前几个请求成功，后面几十个全部返回capacity错误。原因很简单，我自己的并发已经超过了自己账号能同时占用的实例资源上限。
解决思路是引入信号量或令牌桶来控制并发数。Python里可以直接用asyncio.Semaphore或者threading.Semaphore来做。控制到什么程度合适？没有一个绝对的标准，先保守一点，比如并发控制在5到10之间，观察一段时间，再逐步调高。如果调高后发现capacity错误开始频繁出现，就回退到上一个稳定值。
import asyncio semaphore = asyncio.Semaphore(5) async def safe_call(client, config): async with semaphore: return await client.chat(config)批量任务还有一个技巧：分批提交。把一个大任务列表切成小块，每块10到20个请求，跑完一块等待几秒再跑下一块。这种方法在非实时场景下特别有效，虽然整体耗时变长了，但稳定性大幅提升。我在跑夜间批量任务时经常用到这个策略。
4. 从容量报错到容量规划：请求调度的进阶玩法
到了这个阶段，你已经能应对偶发报错了，但线上应用会不断增长，请求量只会越来越大。需要从架构和策略层面去治理容量问题，而不是每次都临时切模型。
4.1 多模型路由的优先级设计
进阶的第一件事，是把“换模型”从应急手段升级为常态机制，也就是建立一套完整的模型路由规则。核心思路是给每个请求打上标签，然后根据标签走不同的模型策略。
具体可以这样设计：
ROUTING_RULES = { "interactive": { "models": ["premium-flagship", "main-sonnet"], "max_tokens": 2000, "timeout": 30, }, "batch": { "models": ["fast-tiny", "main-haiku"], "max_tokens": 500, "timeout": 120, }, "internal": { "models": ["main-sonnet"], "max_tokens": 1000, "timeout": 30, } }“interactive”代表实时用户请求，优先保质量；“batch”代表后台非实时任务，优先保速度和成本；“internal”代表系统内部调用，中间态。每种请求都有独立的优先级和模型列表，遇到容量问题会自动降级。
这里的关键不是规则本身，而是你要清楚地知道每次降级影响的半径。如果是用户正在等结果的实时请求，降级到轻量模型可能导致体验明显下降，所以这类请求要多给几次重试机会、少降级。如果是后台批量任务，用户不会实时感知，那就优先保证完成率，多级降级是合理的。
4.2 语义缓存：有些请求根本不需要打到模型上
说到容量规划，很多人都忽略了一条省力的捷径：把重复的请求缓存下来。你的业务里一定存在大量相似甚至完全相同的请求。比如同一个商品描述多次请求生成摘要，同一篇文档反复做分类分析，这些高重复场景完全没必要每次都消耗模型算力。
做法是在模型调用前面加一层语义缓存。不要求用户输入一模一样才命中缓存，而是通过向量化方式计算相似度，相似度超过阈值就直接返回历史结果。这样做的收益有两个层面：第一层是成本大幅下降，因为模型调用次数减少了；第二层才是跟容量相关的——你的请求总量下降，撞上容量报错的概率自然就低了。
4.3 自托管方案的补充思路
如果你的业务长期、高频地调用某个模型，而且对延迟和容量稳定性要求很高，那可以考虑把一部分流量迁到私有部署的小模型上。比如说本地用量化后的开源小模型处理文本分类、情感分析、意图识别这类成熟任务，把复杂的生成任务继续交给云端大模型。
我见过不少团队走这条路线，初期投入不算低但收益稳定。配置一台带GPU的服务器，部署一个7B到13B量级的量化模型，吞吐量完全够支撑普通业务的中低频请求，而且不再受外部容量波动的影响。具体来说，用ollama或vLLM这类工具跑量化模型，然后用一套统一接口封装起来，当云端模型返回capacity错误时，自动把请求路由到本地模型兜底。
这个方案不适合所有人。如果你的任务需要极强推理能力、很长的上下文支持或复杂指令遵循，本地模型可能达不到及格线。更适合的做法是把简单任务的流量稳定打给本地模型，把复杂任务的流量留在云端，各司其职，互相兜底。
5. 我在实际排查中踩过的坑和总结的排查顺序
最后这部分直接上干货。我把过去半年在处理这个报错时踩过的坑和排查经验汇总一下，希望能帮你少走弯路。
5.1 几个容易误判的方向
第一个坑：把容量报错当密钥问题来排查。我见过有同事一看到Selected model is at capacity就去重置API密钥，换了一个新密钥发现还是同样报错，又去重置一遍，折腾了一小时才反应过来是服务端容量问题。密钥没问题，和容量报错之间没有因果关系。
第二个坑：随意把超时时间调到很大来“等它恢复”。这会造成两个问题：一是连接被长时间占用，并发能力被拖垮；二是用户等待时间过长，体验极差。我建议宁可快速失败、进入重试或降级流程，也不要闷头傻等。
第三个坑：只换模型不改参数。把模型名从旗舰版换成轻量版之后，采样参数还是旗舰版那套。轻量模型对温度、top_p这些参数的敏感度不同，直接沿用可能导致输出质量异常。建议每切换一个模型，就用黄金测试用例做一轮参数调整。
第四个坑：降级策略没有恢复机制。有些朋友做了自动降级，但模型降下去之后不知道什么时候切回来。结果就是高峰期之后，业务长期跑在低质量的轻量模型上，用户莫名其妙发现输出质量下降了。正确做法是隔一段时间用低成本探针请求测试一下旗舰模型是否恢复，恢复后自动切回。
5.2 一个可复用的排查清单
当Selected model is at capacity再次出现时，按这个顺序排查，基本能快速定位：
| 排查步骤 | 具体操作 | 判定结果 |
|---|---|---|
| 1. 确认时点 | 记录报错发生的时间点，对比服务端状态页 | 状态页显示高负载则等待恢复 |
| 2. 检查自己的并发 | 看是否有批量任务一次性大量提交 | 减少并发或分批提交 |
| 3. 检查请求上下文 | 看是否有超长文档请求挤占实例 | 精简上下文或限长 |
| 4. 临时切换模型 | 手动换上一个梯队模型测试 | 能通过则确认是单模型过载 |
| 5. 落地自动防御 | 部署重试、超时、降级路由逻辑 | 全链路自动化兜底 |
我个人的体会是，处理这类报错最核心的思想是不要跟容量硬抗，而是学会绕行。服务端的算力有限，高峰期撞上概率是客观存在的，你要做的是让业务在撞上之后仍然能流畅运转。能做到这一点，这套系统的健壮性就已经超过大多数应用了。
最后再分享一个小技巧：把所有模型名字都外部化为配置文件或环境变量，不要在代码里写死。一旦需要紧急切换模型，直接改配置重启服务即可，不需要改代码重新发布。这个习惯在容量紧急故障时能救你一次。
