彻底解决AI模型容量报错：从重试算法到多模型降级实战

"Selected model is at capacity. Please try a different model." 这句英文报错，我这两年见过太多次了。做AI应用集成的人，几乎都撞过这个提示，尤其在工作日上午十点和下午两三点这种大家集中调API的时段，遇到它的概率会直线上升。很多人第一反应是"代码是不是写崩了""Key是不是被风控了"，其实都不是。这句话翻译过来就是：你选的模型当前已经满载，请换一个模型再试。它告诉你的是"这个模型现在很忙"，而不是"你被拉黑了"。

这篇文章就干一件事：把这个报错从成因到解决方案彻底讲透。我会先带你理解容量报错背后的机制，再分普通用户和开发者两条线讲不同处理方式，最后给出一套我在真实项目里跑过多轮的多模型容错方案，里面包含重试算法、自动降级、队列削峰的完整写法。无论你是第一次在网页里看到这行字的新手，还是已经被它坑过很多次的集成老手，都能在里面找到能直接落地的做法。

1. 先搞懂报错本质：容量满负荷是怎么发生的

1.1 从请求发出到结果返回，中间经历了什么

一次模型请求的执行链路并不复杂，大致会路过这么几个环节：你的程序把文本请求发到服务商的网关，网关先做身份鉴权，检查账号有没有权限、余额够不够；请求随后进入排队区，等待算力调度器分配空闲的芯片资源；分到资源后模型才开始真正推理，最后把结果返回给你。

"at capacity"这个错误，就发生在排队和调度这一环。打一个生活化的比方：模型服务就像一家生意火爆的银行网点，柜员窗口就那么多，全开也接待不过来，后到的客户只能拿号排队，可当等候区也挤满人时，新进来的客户干脆就先劝回去，让你过段时间再来。你的请求就是那个被劝退的客户。服务端的看门逻辑看的是这个模型的实时负载，而不是针对你个人，所以它既不是你的参数写错了，也不是你的账号出了问题。

1.2 它和鉴权失败、限流不是一回事

很多人一看到报错就急着换Key、改网络配置，方向完全跑偏。先分清楚常见的几类错误，才不会乱操作：

常见状态码

一句话含义

重试是否有效

判断方法其实很简单：如果错误信息里同时出现了"rate limit""quota""permission"这类词，那是配额或权限问题；如果出现的是"capacity""overloaded""busy"，那基本就是容量问题，别去动Key也别去折腾网络配置。另外，不同服务商对容量过载返回的状态码不完全一样，有的用503，有的用429，有的会扩展一个529之类的码，含义大同小异——核心是看错误信息里的关键词，而不是死记状态码。

1.3 为什么偏偏在这个时刻被弹出来

容量报错的出现原因，归纳下来无非这么几种，你可以对照自己的使用场景判断是哪一类：

• 模型太热门。新模型上线、能力升级、社区讨论度暴涨的时间段，调用量会在几小时内翻几十倍，服务商扩容速度经常跟不上这个节奏。
• 时段性非常明显。早上10点到下午6点是全行业的调用高峰，凌晨和清晨的失败率会低得多。这个规律我验证过很多次，不是玄学。
• 请求本身偏重。上下文很长、单次生成token数量很大的请求，占用的算力是轻量请求的好几倍，同样一台机器能承载的数量自然更少，高峰时段更容易被挤掉。
• 接入点差异。同一个服务商的模型可能部署在多个区域，不同区域负载不一样，有的区已经满了，有的区还有余量。

理解了机制，后面所有对策就有了依据。解决问题的总体思路也就三条：要么让模型不那么忙，也就是错峰和减重；要么换一个空闲的窗口，也就是换模型或换接入点；要么自己排队，也就是异步、退避、削峰这三件事。

2. 分角色处理：先按身份对号入座

2.1 普通用户：在页面里遇到报错怎么办

如果你是在聊天类产品里遇到这个提示，不需要懂代码，按优先级做这几件事就行。

第一，直接切换模型。报错原文都建议你"try a different model"了，页面上通常有模型选择的入口，从旗舰模型切到轻量模型，成功率的提升立竿见影。第二，缩短上下文。把几十轮的闲聊对话收掉，开一个新会话再问；如果问题基于一份长文档，先只贴关键片段，不要整个文档一次性塞进去。第三，等几分钟再试。容量状态通常不是持续的，几分钟后窗口可能就空出来了。第四，错峰使用。不着急的事，尽量避开工作日上午和下午的高峰。第五，如果页面长期报同一个错，刷新页面、重新登录、清一下浏览器缓存，排除客户端会话层面的异常。

这里有个很多人忽略的细节：连续对话中的长上下文，会显著增加单次请求的算力消耗。同一个模型，一个只有5条消息的会话，和一个50条消息的会话，在服务端看来是两种重量级的请求。把历史记录清理掉再提问，不只是省token，也是在实实在在降低撞上容量报错的概率。别小看这一步，我见过不少"突然开始频繁报错"的案例，最后发现只是会话越聊越长导致的。

2.2 开发者：拿到报错后的标准排查流程

开发者的第一步不是改代码，而是把现场信息抓全。打开你的SDK日志或者直接看HTTP响应，把状态码、错误码、响应头里的Retry-After字段、Request ID都记录下来。Retry-After是服务商给你的一等情报，它直接告诉你建议等待多少秒，按它延时重试往往比你自己的猜测可靠得多。

第二步，去查服务状态页和账号控制台。看看是否有公告级别的大规模故障、账号配额是否耗尽、模型是否被禁用。我遇到过一次客户反馈"一直at capacity"，反复排查才发现他们套餐里根本没包含那个模型，服务商在错误层给套了一层掩码，表面看是容量问题，实际是权限问题。所以说，第二步排查的重要性不亚于代码本身。

第三步才是代码层面的处理。处理原则是这样：429和容量类错误都做退避重试，但重试次数必须有限制；每次失败都要打日志；同一时刻不要无限重发请求。重试不是无脑循环，而是一种有节奏的试探。另外记住一个铁律：鉴权类错误不要重试，重试一万次也不会把无效的Key变成有效的。

2.3 换模型不是随便换：先建立你的模型梯度

"换一个模型"说起来轻巧，但在生产环境里是要提前设计的。我的建议是，把账号下有权限的模型按能力分成三档，并明确每一档的适用任务：

• 旗舰模型：处理复杂推理、长文写作、关键业务逻辑，质量最高，价格也最贵。
• 标准模型：日常对话、摘要生成、内容分类，能覆盖八成常规场景。
• 轻量模型：关键词提取、格式转换、简单问答，延迟低、成本也低。

业务请求应当按"最低满足需求"的原则选档，简单任务就直接用轻量模型，不仅能省钱，还天然规避了旗舰模型的容量压力。每档模型报capacity时，再定义降级规则：旗舰切标准，标准切轻量，逐级往下走。注意，降级后输出质量会变化，对质量敏感的业务需要额外加校验逻辑，把不合格的输出识别出来并标记，而不是默默吞掉，这一点在自动化流程中尤其重要。

3. 代码层的硬核方案：重试、降级、削峰三板斧

3.1 指数退避加抖动：重试算法的正确写法

重试最忌讳的就是"立刻重试"。服务端已经过载的时候，立刻补刀等于在伤口上继续加压。正确的做法是指数退避：第一次失败等1秒，第二次等2秒，第三次等4秒，以此类推，并且还要叠加一个随机抖动。这个抖动非常关键，它能把所有客户端的重试时间点打散，防止大家在同一秒集体醒来，再把服务端打趴下。

import random
import time

class CapacityError(Exception):
"""业务里自定义的容量报错，根据实际SDK异常去捕获对应类型"""

def call_with_retry(func, max_retries=5, base_delay=1.0):
for attempt in range(max_retries):
try:
return func()
except CapacityError:
if attempt == max_retries – 1:
raise
# 指数退避 + 随机抖动
delay = base_delay * (2 ** attempt) + random.uniform(0, 0.5)
time.sleep(delay)
raise RuntimeError("unreachable")

这段代码最需要关注的就是random.uniform(0, 0.5)。别小看这半秒钟的随机数，它的本质是把重试请求在时间轴上摊开。举个极端例子：假设10个客户端同时失败，没有抖动时它们会同时醒来重试，服务端刚恢复的入口瞬间又被填满，故障时间被拉长；加上抖动后，重试请求变成前后错开的10个小点，服务端才有余力消化存量排队。

如果服务商在响应头里明确给了Retry-After，优先把它作为基础延迟，再叠加上面的抖动。重试次数通常建议3到5次，太多的话调用总时长会变得不可控，同时也在给服务端添乱。还有一个忠告：不要把重试逻辑直接写在SDK的默认行为里，要写在你自己的调用工具层，这样才能统一控退避、控日志、控熔断。

3.2 多模型容错层：把"换模型"变成自动化能力

我处理过的稳定性最好的方案，是在业务代码和模型API之间加一个很薄的调用层。这个层不改变业务逻辑，只做三件事：维护可用模型列表、按优先级尝试调用、失败后自动降级。业务侧完全感知不到底层换过模型。

MODELS = [
("flagship", "旗舰模型"),
("standard", "标准模型"),
("light", "轻量模型"),
]

def call_with_fallback(prompt, prefer="flagship"):
errors = []
start_idx = next(
(i for i, (name, _) in enumerate(MODELS) if name == prefer), 0
)
for name, _ in MODELS[start_idx:]:
try:
return model_request(name, prompt)
except CapacityError as e:
errors.append((name, str(e)))
continue
raise RuntimeError(f"all models at capacity: {errors}")

这个容错层的设计有几个容易被忽略的细节。第一，优先列表应当按业务场景注入，不要写死在代码里，不同任务对质量的要求不一样。第二，错误类型要细分，只有容量类错误才触发降级，鉴权错误必须直接抛出，不要拿着一个无效的Key去浪费其他模型的调用配额。第三，每一次降级都要留下日志，记录从哪个模型切到了哪个模型，耗时多少，方便事后观察不同模型在什么时段不稳定。实践下来，给我的定时任务加上这层之后，周失败率从平均两次降到了不到一次，而且几乎不再需要人工介入。

3.3 异步队列削峰：把瞬时压力变成平稳流量

如果业务本来就能容忍一定延迟，就不要同步死等，把请求丢进队列，由worker按固定速率消费。队列在这里起两个作用：一是削峰，把瞬时涌入的高并发请求摊开到一段更长的时间窗口内处理；二是让重试变得更友好，失败的请求重新入队等待下一轮即可，不会一直堵住主流程。

选择队列组件要看请求量级。日请求量到上万条时才需要引入专用的消息队列组件；几百上千的量级，用线程池加一个任务队列就完全够用。这里还有一个极轻量的替代方案叫"错峰调度"：定时任务不要整点跑，给每次触发加一个随机的前移或后移。比如每天10点要跑的任务，可以调度到9点47分、9点53分这种随机时刻。整点是全行业定时任务集中启动的时刻，错开那几分钟，命中容量报错的概率会下降一大截，这个操作零成本、见效快，我强烈建议先做它。

4. 实战复盘：一个定时任务从天天失败到稳定运行

4.1 事故现场：连续三天在同一个时间点挂掉

之前我负责了一个内容摘要任务，每天上午10点整定时触发，对一批新文章批量生成AI摘要。上线第一天就收到报警，我打开日志一看，清一色的capacity报错。当时第一反应也是"换模型"，手动改成轻量模型后，上午高峰时段依然有零星失败，只是频率低了一些。更麻烦的是，这个任务是整点启动的，等于每天主动往全行业请求洪峰的正中心撞，一次都没躲过。

后来我做了三件事：把任务时间从10:00错开到09:47；调用层加入三级降级逻辑，旗舰失败切标准，标准失败切轻量；每次失败后随机等待90到150秒再重试，而不是立刻重试。改动总量不超过百行，但效果立竿见影——第二天这个任务零失败，之后连续一周都没再报警。

4.2 关键参数是怎么算出来的

给定时任务配重试参数，我的习惯是先把"最长等待时间"算清楚。按base_delay=1秒、max_retries=5来算，重试等待序列是1、2、4、8、16秒，累计31秒，再加上每轮的随机抖动，一次完整重试链路的等待不会超过35秒。如果业务能接受这个延迟，这个配置就是合适的；如果接受不了，有两个方向：减少重试次数，或者提前启用降级。但千万不要去缩短退避间隔，退避太短就失去了让服务端喘息的意义。

降级策略的优先级判断依据是任务类型。摘要任务对质量有一定要求，但没到不可妥协的程度，所以我定的规则是：旗舰模型连续失败不超过两次就切标准；标准模型再失败一次直接切轻量；轻量也失败就把任务置为失败并报警，转人工处理。这套规则的关键是"有限失败次数"，避免在一个模型上反复耗时间，也不至于无限降级导致输出质量跌破底线。

4.3 验证与监控：稳定性是"盯"出来的

改动上线后，我把三个指标加到了看板：任务失败率、模型降级率、单次调度总耗时。前两周的观察很有价值：高峰时段模型降级率大约在10%左右，任务失败率从15%降到了0.5%以内；单任务调度耗时因为重试和降级，平均增加了约20秒，但任务本身是异步执行的，这个成本根本感知不到。相比之下，收益远大于付出。

这套监控还带来一个额外好处：当某个模型连续多天在相近时段触发降级，就能反推出它的容量规律，进而把这个时段作为该模型的"已知繁忙期"写进调度策略，直接绕开。数据积累得越久，调度策略越聪明，这个正循环是手工人肉切换模型完全给不了的。

5. 常见问题速查与踩坑记录

5.1 等了很久再试还是报错，怎么回事

如果持续几个小时甚至一整天都在报capacity，基本可以排除单纯的瞬时过载了。按下面的顺序排查：去账号控制台看余额、配额、模型权限；看服务状态页有没有大规模故障公告；翻请求日志，确认错误码有没有悄悄变化。我就掉过一次坑：日志里前一天还是capacity，第二天变成了403，一查才知道是令牌过期了。问题早就不是容量，是我们还在用旧错误信息做判断。所以排查时不要只看第一次报错，要盯住错误状态的变化轨迹。

5.2 重试反而让故障时间变长了

这是我踩过最典型的一个坑。早期的实现里，每个worker收到错误后固定等30秒然后无限重试，结果容量恢复的那一刻，几十个worker同时发起重试，瞬间把入口再次打满，服务端的负载曲线被硬生生画出了第二个波峰。修复方法就是前文说的随机抖动加有限重试次数，再加上熔断器模式：连续失败超过阈值后，直接停止调用该模型一段时间，让服务端彻底喘口气。熔断和退避的区别在于，退避是单次请求的节奏，熔断是整个调用层对该模型的开关，二者配合才有完整的保护效果。

5.3 请求内容太长也会触发容量问题

同样模型、同一时间窗口，上下文5000 tokens的请求和50000 tokens的请求，后者的容量失败率会高出好几倍。这不是偶然，而是长上下文请求占用的显存和算力显著更高，在同一个容量池里能同时接纳的数量自然更少。优化方向包括：截断无用的历史对话、把长文档分片处理、限制最大输出长度。尽量让每个请求变轻——这个方向降低成本的效果也很明显，属于一箭双雕。

5.4 常见问题速查表

最可能的原因

优先处理动作

5.5 几条实打实的经验

最后把这几年的实践浓缩成几条建议放这里。第一，重试和降级逻辑要写进统一的工具层，不要散落在每个业务调用处，否则每次出问题都要改十几处代码。第二，出错时要记录上下文快照——用什么模型、上下文多长、请求体摘要、发生时段、Retry-After值，没有这些信息，事后排查基本靠猜。第三，容量报错是服务商"忙不过来"的信号，不是安全事件，别自己吓自己，更别瞎改代码。第四，官方状态页和响应头字段是第一手信息，比任何第三方渠道都靠谱。

处理这个报错，我个人的体会是：靠人肉去换模型，永远只能救急，不能治本。真正让问题消失的，是把"错峰、退避、降级、削峰"这四件事做成自动化流程。如果你的业务还经常在这个报错上栽跟头，不妨从成本最低的一项开始——先给定时任务加上随机错峰，把最频繁踩中的高峰时段避开。就这一小步，往往就能解决一大半问题。