先直接说结论：看到 "Selected model is at capacity. Please try a different model." 这个提示，说明你选的模型在当前时刻已经被大量用户占满了，服务器暂时分不出计算资源给你。这既不是账号问题，也不是网络问题，更不是你的提示词写得有问题，纯粹是模型侧的容量压力。这篇文章我会从现象、原理到排查路径，把我分别在 ChatGPT 网页端、桌面客户端和 API 接口里遇到这个问题的处理经验完整拆一遍，包括哪些操作是真有用的，哪些只是心理安慰。

这个报错我碰到过太多次了，尤其是在 GPT-4o、o1、GPT-5 这类热门模型上，高峰期几乎每分钟都有人中招。它不区分你是免费用户还是 Plus 订阅，也不会因为你退出登录再登进去就自动消失，处理逻辑完全不一样。这篇文章适合两类人：一是在网页端或客户端被这个提示卡住、想快速恢复干活的普通用户；二是用 OpenAI API 做产品，需要让程序在模型容量不足时还能稳定跑起来的开发者。两类场景的处理思路不同，我会分开讲。

1. 先搞明白：这个报错到底在说什么

1.1 报错的本质：模型被"挤爆"了

OpenAI 的模型是跑在共享计算资源池里的，不是你一个人单独租了一台服务器。你可以把模型理解成一个热门餐厅，餐厅里有固定数量的座位（GPU 算力），高峰期客人太多，座位不够了，后到的客人就只能在外面等。这时候餐厅服务员会告诉你"客满，请换一家餐厅试试"——OpenAI 的提示就是这个意思，只不过原文是 "Selected model is at capacity. Please try a different model."

容量错误（capacity error）和限流错误（rate limit error）是两码事，很多人搞混。限流是你个人在一定时间窗口内发请求太多，触发的是每分钟/每小时的配额限制；而容量错误是模型整体负载太高，不管你是谁、额度多少，只要是这个模型的请求都被拒。从 HTTP 状态码来看，限流通常是 429，容量问题往往是 503 Service Unavailable 或者类似的服务器端错误。如果你在 API 里收到了 429，可以检查一下响应头里的 retry-after，如果是 503 或者带 capacity 字样的消息，那大概率是容量问题。

官方给出的处理建议——"try a different model"——背后其实是一个很朴素的原理：不同模型的资源池是独立的，GPT-5 负载高不代表 GPT-4o 也负载高。AI 公司通常会对热门模型做优先级调度，冷门模型或者参数规模小的模型会有大量闲置算力，切换到这些模型往往能立刻解决问题。

1.2 什么时候最容易遇到这个提示

结合我自己的使用经历，这个报错的出现有明显的时间规律和场景规律：

• 新模型刚发布的一到两周。每次 OpenAI 发新版模型，比如之前 o1 发布、GPT-5 系列上线，大家都会涌过去尝鲜，容量必然告急，这是最典型的触发窗口。
• 工作日的中午到晚上，尤其是美国时区的白天。OpenAI 的用户基数很大，全球各地的人集中在同一时段干活，算力分配就容易紧张。这个时段你要是开着 GPT-5 的长上下文对话，挂的概率很高。
• 你的对话上下文特别长的时候。长上下文会显著占用显存和推理资源，模型容量本来紧张的情况下，长对话更容易被优先拒掉。同一个模型，单轮短对话可能没事，但一个 10 万 token 的长会话却报容量错误，这种情况我遇到过不止一次。
• 在 Codex、ChatGPT 这类编码智能体工具里选模型的时候。Codex 这类工具背后是多模型组合调用，主模型容量满的时候就会在界面上直接弹这个提示。

2. 面向普通用户：最快见效的四条出路

2.1 先试"等一等再重试"：容量错误的分钟级规律

先说最简单的方案——等待。容量错误有个特点：它不像账号封禁那样是持续的，而是瞬时的、交替出现的。同一个热门模型可能这一分钟全部告警，下一分钟就恢复一大半。这是因为 OpenAI 的调度系统是动态伸缩的，算力池会根据实时负载做调整，也会不断有用户结束会话释放资源。

我的建议是先等 30 秒到 1 分钟，然后重新点发送按钮。如果连续重试三次以上仍然报同样的错误，就别干等了，因为你可能正好撞在一个持续性的负载高峰上。这时候试试下面的切换方案。另外提醒一句：等待的时候不要一遍一遍疯狂点击发送，每次都重新触发完整请求，反而会加重模型侧的压力，也不会让你排到更靠前的位置。

2.2 手动切换模型：从热门切到冷门

普通用户在界面上看到这个报错时，最直接的办法是打开模型选择器，换一个模型。我在 ChatGPT 网页端的实际操作顺序是这样的：

1. 如果当前用的是 GPT-5 这类新款旗舰模型，先切回 GPT-4o 或者 GPT-4.1。这两款的部署容量要大得多，负载也相对分散。
2. 如果还是满，切到带 mini 后缀的轻量型号。mini 系列的计算需求小，正常情况下的可用容量最充足。
3. 如果上面都不行，说明这一波容量高峰波及面很大，那就把当前对话的模型切换作为最后手段，配合第 2.3 节的新会话方案一起用。

切换模型时要留意一点：不同模型的能力差异会影响结果质量，尤其是一些复杂的代码生成任务，从 GPT-5 降级到 mini 系列，输出质量的下降是肉眼可见的。我会把这种方法定位成"应急恢复手段"——先保证能继续工作，卡点过去了再切回原来的模型。

2.3 新开一个会话：上下文对容量的影响比你想象的大

这个方法很容易被忽略。我一开始也不理解为什么开个新对话就能绕过容量错误，后来想明白了：模型处理请求时，上下文长度直接决定计算量。你的历史对话越长，推理的成本越高，相当于你一个人占了多个"座位"。当资源紧张时，调度系统会优先保障短请求，长请求的失败率会明显上升。

所以遇到容量错误时，正确的操作是新建一个对话，把核心需求重新描述一遍，而不是在原来的长会话里继续追问。我实测下来，同样是在负载高峰，一个全新的空会话往往一次就能成功发送，而一个几千 token 的长对话会反复报错。特别是你在 Codex 里处理大型代码库的时候，整个仓库扫描一遍上下文就可能好几万 token，这时候模型容量错误几乎是必现的——优先试着把任务拆小、分文件提问，而不是让工具一次吞下整个项目。

2.4 换个入口试试：网页端、桌面端和移动端的容量差异

不同接入方式背后的模型路由不完全一样。我之前遇到一个情况：网页端选中 GPT-5 时报容量错误，换成 macOS 桌面客户端同一个账号同一个模型却正常响应。这说明客户端和网页版走的可能是不同的网关或者不同的资源调度策略。

所以多一个选择就多一条路。建议的尝试顺序是：桌面客户端（如果有）→ 网页端 → iOS / Android 官方应用。特别是临时急需用的时候，换入口的成本最低。也顺带说一句，网上有些人建议换浏览器或者开无痕模式，这其实是没用的——容量错误和会话数据、请求协议无关，换浏览器只是换了皮，后端看到的还是同一个模型请求。

3. API 开发者视角：让程序在容量抖动时也能稳定运行

3.1 先看懂错误码和响应头

在 API 场景里，容量错误会以不同的形态出现。我自己在接入 openai-python 库的过程中，遇到过这样几种典型的失败响应：

开发时很容易犯的错是把所有报错都当成限流来处理。实际上，429 和 503/500 的处理策略应该不一样。限流通常是等几秒钟就能恢复，容量错误可能需要更长的退避时间，而且最佳策略往往不是等，而是切换模型。

3.2 指数退避 + 重试：扛过瞬时峰值

对于短时间的容量抖动，用重试机制就能解决。关键在于重试间隔要做指数退避，而不是固定间隔。最简单的方式是前几次重试间隔短（1 秒、2 秒、4 秒），随着失败次数增加逐步拉长（8 秒、16 秒、30 秒封顶），并且设置最大重试次数，降到 5 次左右，避免无限循环把账户请求额度打爆。

OpenAI 官方的 Python SDK 其实已经内置了重试机制，默认会通过max_retries参数控制重试次数。但我发现默认配置并不完全适合容量错误的场景——SDK 对 503 的重试处理是有的，但对"capacity"这种特定错误提示，最好还是自己在上层实现更精细的控制逻辑。

3.3 模型降级路由：给每个请求准备 Plan B

重试解决不了根本问题，只在瞬时抖动时有效。如果你的产品对响应成功率有硬性要求，那就必须做模型降级，也就是"主模型失败了，自动用备选模型顶上"。

我的做法是维护一个模型优先级列表：

models = [ "gpt-5", # 首选，效果好 "gpt-4o", # 次选，效果略降但容量更大 "gpt-4o-mini", # 兜底，容量最充足 ] for model in models: try: response = client.chat.completions.create( model=model, messages=messages, temperature=0.7, ) return response.choices[0].message.content except openai.APIError as e: if "at capacity" in str(e) or e.status_code == 503: print(f"模型 {model} 容量不足，尝试降级...") continue raise

这套流程里最需要想清楚的是"该不该降级"。如果一次对话的效果直接决定用户体验，比如医疗问答、法律文书生成，那降级带来的质量损失可能比"稍后再试"更严重。我一般的处理是：判断当前任务的关键程度，对普通任务直接走降级路由，对高价值任务返回提示让用户选择是否等待。

另外有个小技巧：在对延迟不敏感的批量任务里，与其实时请求不如做成异步队列。把请求丢到队列里，消费者检测到容量错误时就把任务重新排到队尾，延迟个几分钟再执行。这样既不牺牲模型质量，又能平滑掉容量高峰。我维护的一个批量处理服务就是这么干的，实测一天下来因为容量错误导致的失败率从 7% 降到了 0.3%。

3.4 处理提醒：不要忽略 Retry-After 响应头

无论遇到哪种错误，响应头里的Retry-After字段都值得看一眼。它告诉你过多少秒再发起重试是合理的。有些情况下 API 返回的是 429，但响应头里的retry-after可能只有几百毫秒，这时候等太久反而是浪费。反之，如果字段给出的秒数很大，说明后端压力很大，硬等也没有意义。

在代码里读取这个值也不复杂：

import time import openai try: resp = client.chat.completions.create(model=..., messages=...) except openai.APIError as e: retry_after = e.response.headers.get("retry-after") delay = float(retry_after) if retry_after else 2.0 time.sleep(min(delay, 30))

这样配合指数退避，能够在"快速恢复"和"避免频繁冲击服务器"之间取得平衡。

4. 实操体验：一套完整的处理流程实例

4.1 我个人的标准处理路径

这套流程在我日常使用中已经形成了肌肉记忆，写在这里给有同样问题的读者参考：

• 第一步，确认报错范围。先判断是所有模型都报容量错误，还是只有某一个选中的模型报错。如果只有主模型报错，切模型是最优解。
• 第二步，如果是长上下文会话报错，先开新会话再尝试。开新会话的同时，我会把上次对话的关键结论复制到记事本里，避免丢信息。
• 第三步，新会话依然失败，走模型降级。短任务直接从当前模型切到 mini，长任务切到次一级的旗舰模型。
• 第四步，上面全失败，等 2 到 5 分钟再做一次尝试。这时通常容量高峰已经过去了。
• 第五步，如果是在 API 场景，检查自己代码里有无写死模型名的地方——尤其是把模型名做成配置文件里的常量时，要改成从配置中心动态读取，方便在紧急情况下热切换。

我单独说一下 Codex 场景下的处理。Codex 这类编码智能体在扫描代码库时会一次性传入大量文件内容，模型负载极重，所以容量错误出现的概率比普通聊天高很多。我的经验是：先在界面里手动把任务拆成几个独立的子任务，每个子任务只涉及少数文件，让它逐个处理。这样既绕开了单次请求的长上下文问题，也让最终结果更可控。如果子任务仍然报容量错误，那就切到下一级模型，Codex 支持在任务开始时选择底层模型，别在任务中途改——中途切换可能会丢掉当前的执行上下文，得重来。

4.2 一个更完整的上游封装示例

给开发者再多提供一点现成的思路。我的建议是不要直接在业务代码里到处写重试逻辑，而是统一封装成一个带重试、降级、日志的调用模块。下面这个简化版是我在项目里的常用骨架：

import time import logging from typing import Optional, Union import openai logger = logging.getLogger(__name__) class ModelRouter: def __init__(self, primary_model: str, fallback_models: list[str]): self.primary_model = primary_model self.fallback_models = fallback_models def complete(self, messages, max_retries: int = 5): model_pool = [self.primary_model] + self.fallback_models last_error = None for model in model_pool: for attempt in range(max_retries): try: response = openai.chat.completions.create( model=model, messages=messages, ) logger.info(f"请求成功，使用模型: {model}") return response.choices[0].message.content except openai.APIError as e: last_error = e is_capacity = ( isinstance(e, openai.RateLimitError) or e.status_code in (500, 503) or "capacity" in str(e) ) if not is_capacity: raise backoff = min(2 ** attempt + 1, 30) logger.warning(f"{model} 容量异常，第 {attempt+1} 次重试，等待 {backoff}s") time.sleep(backoff) raise RuntimeError(f"所有模型均不可用，最后一次错误: {last_error}")

说几个我在实际运行中总结的要领：

• 日志一定要打全。谁在什么时候降级了、重试了几次、最终用了哪个模型，这些信息在复盘故障时极其有用，别为了省事只记一个"请求失败"。
• 不要在轮询里把降级当成唯一的恢复方式。有些场景下，等 30 秒后原来的主模型其实已经恢复了，如果想追求最高质量，可以在降级失败后加一个"稍后重试主模型"的分支。
• 把max_retries和降级模型列表做成环境变量配置，不要写死在代码里。上次线上出问题的时候，我就是靠改环境变量临时调整降级顺序，省了一次发版。

4.3 监控容量错误的曲线：提前发现高峰

容量错误跟其他错误一样，是可以做监控的。以前我懒得关注，直到有一次凌晨系统报警，才发现某个自动化任务在容量高峰时段连续失败了半小时，影响了当时的报表生成。

现在我在项目里做了三件事：一是把"capacity"字样作为单独的错误标签收集，统计它在所有错误里的占比；二是给占比设了阈值，超过 20% 就报警，说明当前进入容量紧张期；三是在日志告警里附带模型名称，这样能精准定位到具体是哪个模型资源紧张。这套监控建起来之后，容量问题不再是被动踩雷，而是可以提前预处理。

5. 容易踩的坑和新手常见误区

5.1 误区一：反复刷新页面会更快恢复

刷新页面不会让你插队，也没有"换一个人少的路由"这种说法。更糟糕的是，刷新会丢弃当前页面未发送的消息，要是你那段很长的提示词没复制下来，刷新就白打了。正确做法是保留当前页面，直接重试发送，或者切换模型/新开会话。

5.2 误区二：以为账号被封了

容量错误和账号被封从提示语上很容易区分。容量错误会明确提到 "model is at capacity"；封号提示通常涉及的是服务条款、支付失败、异常行为等措辞，一般不会让你"换一个模型"。我之前就看到有用户因为误以为被封号去找客服申诉，白白浪费了时间。

5.3 误区三：充值或者升级订阅就能绕过容量错误

容量错误不区分订阅等级，免费用户、Plus、Pro 只是共享同一个模型池的不同待遇——如果你用的是同一容量池子，该满还是满。付费用户的优势主要体现在限流配额更高、响应优先级略高，但绝对没有"独占通道"。如果你真的经常因为容量问题影响工作，我能想到的缓解办法只有两个：错峰使用，以及尽量切换到冷门模型，把热门模型留给关键时刻。

5.4 常见问题速查

5.5 一个容易被忽略的小细节：请求内容越"重"，越容易触发容量错误

除了上下文长度，请求里如果带了多张图片、多个文件附件、或者指定的输出格式特别复杂（比如强制 JSON 加若干约束），也会明显增加单次请求的资源占用。这个维度在官方文档里不会讲得太细，但实测影响巨大。我在多模态任务里遇到过很多次：同一时间点，纯文本请求正常响应，带两张图片的请求反复报容量错误。所以能做到"轻量化请求"的，尽量把图片压缩、把任务拆小，效果立竿见影。

说到底，"Selected model is at capacity" 和"服务器崩溃"不一样，它更像是高峰期的临时拥堵，是有明确应对策略的。我自己的习惯是：先把最顺手的模型用在关键任务上，简单任务统一交给 mini 系列，批量任务全部走异步队列，新模型忍住不第一时间尝鲜——这三条做好之后，容量错误对我的实际影响其实很小了。希望这篇文章里的思路对你有帮助。