\”Selected model is at capacity. Please try a different model.\” 这句英文报错，我这两年见过太多次了。做AI应用集成的人，几乎都撞过这个提示，尤其在工作日上午十点和下午两三点这种大家集中调API的时段，遇到它的概率会直线上升。很多人第一反应是\”代码是不是写崩了\”\”Key是不是被风控了\”，其实都不是。这句话翻译过来就是：你选的模型当前已经满载，请换一个模型再试。它告诉你的是\”这个模型现在很忙\”，而不是\”你被拉黑了\”。
这篇文章就干一件事：把这个报错从成因到解决方案彻底讲透。我会先带你理解容量报错背后的机制，再分普通用户和开发者两条线讲不同处理方式，最后给出一套我在真实项目里跑过多轮的多模型容错方案，里面包含重试算法、自动降级、队列削峰的完整写法。无论你是第一次在网页里看到这行字的新手，还是已经被它坑过很多次的集成老手，都能在里面找到能直接落地的做法。
1. 先搞懂报错本质：容量满负荷是怎么发生的
1.1 从请求发出到结果返回，中间经历了什么
一次模型请求的执行链路并不复杂，大致会路过这么几个环节：你的程序把文本请求发到服务商的网关，网关先做身份鉴权，检查账号有没有权限、余额够不够；请求随后进入排队区，等待算力调度器分配空闲的芯片资源；分到资源后模型才开始真正推理，最后把结果返回给你。
\”at capacity\”这个错误，就发生在排队和调度这一环。打一个生活化的比方：模型服务就像一家生意火爆的银行网点，柜员窗口就那么多，全开也接待不过来，后到的客户只能拿号排队，可当等候区也挤满人时，新进来的客户干脆就先劝回去，让你过段时间再来。你的请求就是那个被劝退的客户。服务端的看门逻辑看的是这个模型的实时负载，而不是针对你个人，所以它既不是你的参数写错了，也不是你的账号出了问题。
1.2 它和鉴权失败、限流不是一回事
很多人一看到报错就急着换Key、改网络配置，方向完全跑偏。先分清楚常见的几类错误，才不会乱操作：
| 鉴权失败 | 401 / 403 | Key无效、没有权限 | 无效，得修配置 |
| 限流 | 429 | 请求速率超过账号配额 | 短时有效，但需要降速 |
| 容量已满 | 503 / 529 | 模型服务端已过载、忙不过来 | 有效，但要退避和错峰 |
| 服务内部错误 | 500 | 系统本身出异常 | 偶发有效，需要看日志 |
判断方法其实很简单：如果错误信息里同时出现了\”rate limit\”\”quota\”\”permission\”这类词，那是配额或权限问题；如果出现的是\”capacity\”\”overloaded\”\”busy\”，那基本就是容量问题，别去动Key也别去折腾网络配置。另外，不同服务商对容量过载返回的状态码不完全一样，有的用503，有的用429，有的会扩展一个529之类的码，含义大同小异——核心是看错误信息里的关键词，而不是死记状态码。
1.3 为什么偏偏在这个时刻被弹出来
容量报错的出现原因，归纳下来无非这么几种，你可以对照自己的使用场景判断是哪一类：
