大模型 API 并发限制解析：开发者容量规划指南

一、从一个餐馆比喻说起

理解 API 并发限制，最直观的方式是想象一家餐馆。

餐馆一天能卖多少饭，取决于客流量和营业时长，是个不确定的值；但同一时刻能出多少道菜，却受限于厨子和灶眼的数量，是个确定的上限。你向服务员下单后，只要菜还没上齐，这张单就会一直占用厨房的一份处理能力——哪怕厨子只是在等汤炖好，灶眼也不能让给别人。

大模型 API 的并发限制，遵循的是完全相同的逻辑。从你发出请求的那一刻起，到模型完整返回答案之前，这整个时间段都算作一个”并发”。请求没有结束，它就一直在占用服务端的一个处理位置。

二、并发不等于吞吐：一个关键的换算关系

很多开发者第一次接触并发限制时，会下意识地把它等同于”每秒能发多少请求”。这两者其实不是一回事。

并发数描述的是”同时正在处理中的请求数量”，吞吐量描述的才是”单位时间内完成的请求数量”。 二者之间通过一个中间变量联系起来：单个请求的平均处理时长。

用公式表达就是：

稳定吞吐（QPS） ≈ 并发上限 ÷ 平均请求耗时（秒）

举一组具体的数字来感受一下。假设某个模型的账号级并发上限是 500：

平均请求耗时	稳定吞吐（约）
20 秒	25 请求/秒
40 秒	12.5 请求/秒
60 秒	8 请求/秒

可以看到，并发上限没变，但因为请求耗时变长了，实际能承载的吞吐量下降了三分之二。这一点对容量规划至关重要：同一个账号，跑短对话和跑长文总结，能支撑的业务量可能相差数倍。

哪些场景会让请求耗时显著拉长？常见的有：

• 长文总结：输入动辄数万 token，模型需要先”读完”再”归纳”；
• 复杂推理：思维链式的多步推理会生成大量中间 token；
• 代码生成：输出长度大，且往往需要更长的上下文；
• 长上下文对话：历史消息累积，每轮都要重新处理。

如果业务里混合了这些场景，用单一的平均耗时去估算容量是不准确的，更稳妥的做法是按场景分别统计耗时分布，再做加权。

三、”账号级”三个字的重量

在官方文档中，并发限制前面通常有个限定词：账号级。

这三个字直接决定了容量规划的边界。它的含义是：并发额度按账号统计，与你在该账号下创建了多少个 API Key 无关。

换句话说：

• 一个账号开 1 个 Key，额度是 N；
• 一个账号开 10 个 Key，额度仍然是 N，而不是 10N。

这一点容易被误解。有些团队为了”分摊压力”，习惯给每个微服务、每个环境各分配一个 Key，以为这样能绕开限制。实际上，这只是把同一池水舀进了不同的杯子，池子的总量并没有变化。多 Key 的真正价值在于权限隔离、用量归因和密钥轮换，而不是扩容。

因此，在做架构设计时，应当把”账号”作为容量的基本单位来对待。如果多个业务线共用同一个账号，它们就在共享同一份并发额度，彼此之间会互相挤占。这一点必须在容量评估阶段就明确下来。

四、超出限制时会发生什么

当请求数超过并发上限，服务端不会无限排队，而是会直接拒绝——返回 HTTP 429 状态码。

429 的语义是”Too Many Requests”，即请求频率超过了服务端愿意接受的范围。它和 500、503 这类错误有本质区别：

• 429：请求本身没问题，只是”现在太挤了”，稍后重试大概率能成功；
• 503：服务暂时不可用，可能是过载、维护或故障；
• 500：服务端处理时出了错。

对开发者而言，429 是一个可预期、可处理的信号。正确的应对方式是把它纳入正常的错误处理流程，而不是当作异常崩溃。

一个典型的带退避的重试逻辑大致如下：

import time
import random
def call_with_backoff(client, payload, max_retries=5):
    for attempt in range(max_retries):
        resp = client.invoke(payload)
        if resp.status_code == 200:
            return resp
        if resp.status_code == 429:
            # 指数退避 + 随机抖动，避免重试风暴
            wait = min(2 ** attempt, 30) + random.uniform(0, 1)
            time.sleep(wait)
            continue
        # 其他错误直接抛出，交给上层处理
        resp.raise_for_status()
    raise RuntimeError("重试次数用尽，仍未成功")

几个实践要点：

1. 加入随机抖动（jitter）：如果大量客户端在同一时刻被限流，又同时按相同节奏重试，会形成”重试风暴”，反复撞墙。随机抖动可以打散重试时间。
2. 限制最大重试次数：无上限重试会拖垮调用方自己。
3. 区分幂等性：重试前要确认该请求是否可以安全重放，避免重复计费或重复写入。
4. 监控 429 比例：429 占比持续升高，说明容量已经接近瓶颈，是扩容的信号。

对于交互式产品，除了重试，还应在客户端做体验兜底——比如排队提示、渐进式加载、允许用户取消，而不是让界面一直转圈直到超时。

五、为什么平台要设置并发限制

从平台侧看，设置并发限制的核心动机是稳定性。

大模型的一次推理请求，资源开销远高于普通的 Web 接口。它需要占用显存、算力、KV Cache 等资源，而长上下文、长输出、深度推理模式还会进一步放大这些占用。如果一个请求要跑几十秒，那么在这几十秒里，它占用的那部分资源就无法被其他请求使用。

如果没有并发控制，会出现什么情况？

少数高强度调用者可以在短时间内发起海量请求，把服务端的处理资源全部占满。此时其他用户虽然不会立刻收到 429（因为限流还没触发），但他们的请求会排在队列里，迟迟得不到处理，最终表现为长时间等待甚至超时。这种”劣币驱逐良币”的局面，对平台和绝大多数用户都是伤害。

并发限制的作用，相当于给每个账号划定车道：你可以跑得快，也可以申请更多车道，但不能把所有车道都堵死。对平台来说，主动限流比被动过载后大面积返回 503 更可控；对开发者来说，明确的容量边界反而让产品规划有了可依据的锚点。

六、对普通开发者的实际影响

坦率地说，对于大多数中小规模应用，并发限制在日常情况下不会成为瓶颈。个人开发者、内部工具、低频调用的业务系统，通常离上限还有很大距离。

风险主要出现在两类时刻：

一是突发流量。 某个接入大模型 API 的应用突然走红，用户量在短时间内激增，此时并发请求会迅速逼近上限，表现为部分用户看到持续加载或收到 429。

二是批量任务。 离线数据处理、批量内容生成这类场景，如果代码里没有做并发控制，很容易一次性打出成百上千个请求，直接撞上限流。

针对这两类情况，工程上可以采取的措施包括：

• 客户端限流：用信号量或令牌桶控制自身并发数，主动把压力控制在额度之内；
• 任务队列：把批量任务投递到消息队列，由固定数量的消费者匀速处理；
• 分级降级：在容量紧张时，优先保障核心链路，非关键请求延后或降级；
• 错峰调度：把非实时的批量任务安排到业务低峰期执行。

七、容量评估与扩容的正确姿势

容量规划的本质，是回答一个问题：我的账号能稳定支撑多少业务量？

一个可操作的评估流程如下：

1. 测平均耗时：按业务场景分别统计请求的 P50 和 P99 耗时，不要只看平均值，长尾往往才是压垮容量的那根稻草。
2. 算理论吞吐：用”并发上限 ÷ 平均耗时”估算稳定吞吐，并留出安全余量（通常建议按 60%～70% 折算）。
3. 压测验证：在接近真实流量的条件下做压测，观察 429 比例和延迟变化，验证估算是否准确。
4. 持续监控：上线后监控 QPS、并发数、429 比例、P99 延迟，建立容量水位告警。

如果在合理优化之后，容量确实不够用，正规的做法是走官方的扩容申请渠道，按实际业务需求说明情况。据公开文档说明，这类扩容通常按业务实际需求匹配，且不额外收费。相比自行拆分账号、拼接多把 Key 这类”偏方”，走正规渠道更稳定，也更便于后续的容量管理和问题排查。

需要强调的是，扩容不是万能药。在申请扩容之前，先确认几件事：

• 是否已经做了客户端限流和任务队列？
• 是否存在可以合并的重复请求？
• 是否有缓存的可能（相同输入复用结果）？
• 是否把非实时任务错峰了？

把工程侧的优化做足，往往能用更低的成本换到更大的有效容量。

八、小结

并发限制不是一个需要恐惧的机制，而是分布式系统资源治理的常规手段。理解它，关键在于抓住三点：

• 并发 ≠ 吞吐：吞吐 = 并发 ÷ 平均耗时，长耗时任务会显著压低实际吞吐；
• 额度按账号计：多 Key 不扩容，账号才是容量的基本单位；
• 429 是可处理信号：退避重试、客户端限流、任务队列是标准应对组合。

把这三条落实到架构设计和容量评估中，开发者就能在明确的边界内，把大模型能力稳定地交付给最终用户。真正的工程能力，不在于把请求打得多满，而在于知道边界在哪里，并为边界之内的每一次调用负责。