接入 OpenAI、Claude 或 Gemini 等模型 API 时，增加并发可以缩短批量任务耗时，却也可能放大 Token 消耗和失败重试成本。遇到 API 中转并发限制，不应只考虑购买更高额度，而要先区分限制来源，再确定业务能够承受的吞吐与支出。
并发限制与 Token 额度不是一回事
并发通常指同时处理的请求数；RPM 是每分钟请求数，TPM 是每分钟 Token 数，余额则决定账户能否继续支付。它们可能同时约束调用：即使并发不高，长上下文请求也可能触及 TPM；余额充足，也不代表拥有更高并发权限。
限制可能来自应用自身、API 中转网关或上游模型服务。购买 Token 额度不等于自动提高并发上限。采购前应确认限制按 API Key、账户、模型还是渠道统计，以及是否存在共享配额，不能仅根据一次压测判断长期容量。
如何估算并发对应的 Token 预算
先从真实业务采样，记录单次请求的输入 Token、输出 Token 和耗时。若一分钟完成 N 次请求，平均每次输入 I、输出 O，则该分钟 Token 用量约为 N×（I＋O）。费用应按实际模型的输入、输出及适用计费项目分别核算，不能直接将总 Token 乘以同一个单价。
同样的并发数下，响应越快，单位时间完成的请求可能越多，预算消耗也越快。并发上限是稳定性护栏，不是完整的费用上限。建议另外设置每日预算、单任务最大输出和队列长度；预算接近阈值时暂停低优先级任务，而不是等到余额耗尽后被动中断。
用分层限流减少拥堵与重复支出
- 按模型设置并发池：避免慢速长任务占满全部连接，影响交互请求。
- 同时限制请求数与 Token 速率：按预估用量预留容量，完成后依据实际用量校正。
- 为排队设置超时：超过业务等待时间后取消，避免过期任务继续消耗预算。
- 限制重试次数：使用指数退避和随机抖动；若返回 Retry-After，应结合接口说明处理。
- 单独管理流式请求：连接可能持续较久，不能把收到首个片段当作请求已结束。
重试尤其需要谨慎。客户端超时不一定代表上游未执行，直接重发可能造成重复生成和额外费用。可用业务任务 ID 做应用侧去重，并确认接口是否支持幂等机制；不要假定所有模型端点都支持相同的幂等参数。
出现 429 或超时，先排查什么
遇到 429 时，结合响应体、响应头与网关日志确认具体限额；不能仅凭状态码认定是并发不足。出现 5xx 或超时，则需排查上游错误、网络链路、网关排队及超时配置。保留请求 ID、模型名、耗时、用量与重试次数，但应避免记录完整密钥和敏感提示词。
调整时先小幅降低并发，观察成功率、P95 延迟、队列长度和单位成功任务成本，再逐步放量。比较 API 中转方案时，应重点核实限流口径、用量查询、账单对账和故障定位能力。对 openmagic.ai 的接入规划，也应以实际套餐说明与测试结果为依据，让扩容对应明确的业务收益，而不是用更高预算掩盖调用设计问题。