多人同时调用 API，怎么控制并发？RPM、TPM 与共享队列预算
多人应用不能只设置“最多同时跑几个请求”。 需要先核对共享的请求与 token 限额，再让所有 worker 共同安排发起速率，同时限制在途请求和队列等待。新增服务器或多建几个 Key，不会自动增加服务商允许的容量。
本文解决“一个应用服务多位用户，怎样安排模型请求”的任务。官方资料核对日期为 2026 年 11 月 5 日；排队设计与算例是规划建议，没有进行真实压测。云岚API的具体限额尚未在本文确认，应按实际账号、模型和渠道核对。
并发、RPM 和 TPM 分别管什么？
| 指标 | 衡量什么 | 单独控制它有什么遗漏 |
|---|---|---|
| 在途并发 | 某一时刻尚未结束的请求数 | 请求很快时，仍可在一分钟内发出太多次 |
| RPM | 每分钟请求数限制 | 少量长请求也可能耗尽 token 额度 |
| TPM | 每分钟 token 限制 | 大量短请求仍可能先达到请求数限制 |
| 队列等待 | 从进入队列到获准发起的时间 | 等待过长时，用户任务可能已经失去时效 |
OpenAI 当前还可能有按天、图像等维度的限制，哪个先达到都会影响请求；本文的 RPM/TPM 算例只简化讨论文本任务，不覆盖全部接口。官方速率限制定义
例如，一个请求只执行很短时间，保持低并发也可能不断发起新请求。相反，生成长内容时，在途数升高不一定意味着每分钟发起次数变多。因此速率许可和并发槽位要分开记录。
先找出哪些请求共享同一个限额
以 OpenAI 为例，限制作用于组织和项目，而非每个用户；部分模型还共享同一限额。不能把三个 worker 各自读取到的限额相加，也不能认定换模型名称就一定换了桶。组织、项目与共享模型范围
建议先登记“服务商—组织或账号—项目—共享模型组—接口”的对应关系，再标出同时适用的各层限制。真实请求必须通过全部适用限制；用户自己的公平配额是应用额外设置的一层。
Key 台账记录负责人和用途，容量台账记录共享范围，两者互相引用即可。凭证安排可看团队 API Key 管理。不要通过轮换多 Key 绕过平台限制；若容量不足，应调整任务、排队或申请平台允许的额度。
一个完全假设的容量怎么算？
假设某服务的有效限额如下，这些数值不是 OpenAI 或云岚API套餐，也不是实测数据：
| 规划量 | 假设值 |
|---|---|
| 请求上限 | 120 请求/分钟 |
| token 上限 | 60,000 token/分钟 |
| 按该服务限流规则估计的单次预留 | 2,000 token/请求 |
| 从发起到结束的平均耗时 | 8 秒/请求，不含排队 |
只考虑这两个分钟限额时，规划上界为：
min(120 请求/分钟, 60000 token/分钟 ÷ 2000 token/请求)
= 30 请求/分钟
若能稳定达到该速率，平均在途数约为：
30 请求/分钟 ÷ 60 秒/分钟 × 8 秒 = 4 个请求
4 是稳定条件下的平均在途估算，不是应当设置的固定并发，也不是容量保证。 它没有包含其他业务、突发、长尾耗时、重试和其他限制。实际规划应留出余量，并根据低负载观测逐步调整。
这里的 2,000 是单次限流预留假设，不能直接抄账单里的 usage。官方指南中的 token 估算会涉及请求长度和输出设置；不同模型、接口和供应商的计法需另核。完成后发现账单 token 较少，也不能据此立即把服务商限流额度“退回”。官方 token 估算说明
多个 worker 怎样共享请求和 token 预算？
下面是应用侧调度建议，不是平台自动提供的功能：
- 任务进入持久队列时，记录用户、任务 ID、输入版本、目标模型、预估 token 和总截止时间。
- 调度器检查适用的请求桶、token 桶与可用并发槽位，在共享存储中原子申请本次许可。
- 条件不足时留在队列中，按下一可发时间安排；不要让每个 worker 各自睡一会再同时冲出。
- 请求结束后释放并发槽位，记录实际尝试；速率预算按目标服务的规则与窗口恢复。
一个进程内的计数器无法协调多个副本。还要定义 worker 崩溃、共享存储故障和许可过期后的恢复方式；状态未知时先核对，不因本地清空计数就重新满速发送。已有请求的执行结果未知，继续按超时与重复请求排查处理。
服务可能返回剩余请求、token 与重置时间等头，但不是所有响应或渠道都会提供；它们也会被其他并行调用改变，不能代替自己的共享调度。响应头字段与适用范围
有了分钟预算，为什么还要平滑发起？
不要在每分钟开始时把全部许可一次用光。把发起分散到时间轴上，并在扩大流量时逐步提升。OpenAI 的 slow_down 可在 RPM/TPM 尚未耗尽时出现，表示流量增长过快；实际处理还要依据状态、错误码和等待提示。部署检查中的流量增长说明
长短任务混跑时，可分队列并设置轮询或权重，让短任务不被长任务全部挡住；同时保留长任务的最低服务份额或等待时长提升优先级，防止它们一直排不到。各子队列仍要经过共同的总预算，不能各自独占一整份上游限额。
排队与重试必须算进同一个截止时间
用户能接受的等待，应从任务进入应用时开始计算，而不是拿到并发槽位后重新计时。排队、尝试和退避都消耗这个时间；剩余时间不足时，按业务规则拒绝、过期或转入用户已知的异步流程，不无限积压。
重试也是新的 HTTP 尝试，应重新申请共享预算。OpenAI 说明失败请求也可能消耗分钟限制；SDK 内部自动重试若绕过调度器，会让应用低估实际发起次数。应统一尝试的安排与记录，不能每层各自重试。官方重试提醒
队列需要容量上限。达到上限时给调用方明确状态；已经过期的任务不再自动发起。遇到 429 先区分速率与额度等原因，详情见报错分诊，不要把所有错误都继续排队重试。
怎样验证这套安排是否有效？
从小请求开始，分别观察单用户、多用户、长短任务混合、增加 worker 和重试场景。每次只改变一个条件，记录同一观测窗口中的发起次数、预算预留、在途数、排队等待、拒绝、过期和成功数。
通过条件应包括：增加 worker 后没有突破共享预算；少数用户不能占满所有槽位；长任务仍能获得处理；过期任务不再发起；统计能区分原始任务和重复尝试。没有 429 只是一项观察，不能证明队列等待和业务结果都合格。
下载 API 容量预算台账。文件含上面的假设计算，实际限额、观测和证据栏留空，不是压测结果。若任务本来不要求即时响应，再评估目标服务是否提供适用的批处理方式，结果核对见Batch 验收。
准备使用云岚API接入自建应用时，先核对当前模型与协议以及实际账号限制，再注册云岚API，按入门教程验证一条基础请求。确认返回与日志后再接共享队列；已有账号可直接进入控制台。