接入 OpenAI、Claude、Gemini 等模型 API 时，请求增加后出现排队、429 或超时，不一定是余额不足，也可能触及 API 中转并发限制。对使用 Token 批发额度或统一模型网关的团队，关键不是把并发开到最大，而是让请求量、Token 消耗和预算相互匹配。
并发、速率与 Token 额度有什么区别？
并发限制控制同时处理的请求数量，不直接等于 Token 额度。RPM 通常表示每分钟请求数，TPM 表示每分钟 Token 数，余额则决定还能承担多少费用。这些约束可能同时存在，也可能按模型、账户或渠道分别计算，具体以服务说明为准。
例如，长文本生成持续占用连接，即使每分钟请求不多，也可能占满并发槽位。短请求集中突发则可能先触发速率限制。流式返回能改善首字等待体验，但不代表请求已经结束，更不代表不占并发。
怎样估算并发需求和 Token 预算？
可以用“每秒到达请求数 × 平均请求耗时”粗估平均在途请求，再根据高峰流量和长尾耗时预留空间。这个估算不能替代压测：上下文长度、输出长度、模型类型和网络波动都会影响结果。
- 记录输入与输出 Token，按模型分别统计，缓存等计费项按实际账单口径处理。
- 设置合理的输出长度上限，避免简单任务生成过长答案。
- 区分交互请求与批处理任务，给在线业务保留资源。
- 同时观察并发数、排队时间、请求耗时、错误率和单位成功任务成本。
提高并发通常改变费用发生的速度，而非单次调用的标价。但高并发若带来重复请求、失败重试或无效长输出，总支出仍会增加。预算测算应包含正常调用与可能的重试消耗，不能只看成功请求数量。
遇到 429 或超时，如何避免越重试越贵？
先检查响应正文、错误码、请求标识和网关日志，确认限制发生在客户端、中转网关还是上游模型侧。429 可能涉及速率、额度或其他限制，不能仅凭状态码判定并发不足；超时也可能来自连接、读取或排队环节。
重试应有退避、随机抖动和总次数上限。若服务提供 Retry-After，应结合其指引调整等待时间；持续失败时暂停重试并告警。还要核对 SDK 与网关是否各自启用重试，避免多层重试放大流量。请求超时后，上游任务是否终止、是否计费，需要查证，不能默认取消即免费。
采购中转额度时，应核对哪些条件？
评估 API 中转服务或 Token 批发方案时，应一起确认模型计费口径、并发限制、速率限制、余额查询方式与错误排查能力。特别要问清并发按账户、密钥还是模型计算，排队是否占用超时窗口，以及额度用尽后的处理方式。
落地时可在客户端设置限流器和有界队列，队列满时明确拒绝或延后任务；再设置日预算提醒、项目消耗上限和异常用量告警。先用代表性请求低并发压测，再逐步提升负载。以可接受的成功率、延迟和成本确定并发值，比单纯追求更大的并发额度更有意义。