通过 API 中转接入 OpenAI、Claude 或 Gemini 时，请求变慢、排队或返回 429，不一定是余额不足，也可能触发并发、请求频率或 Token 吞吐限制。排查 API 中转并发限制，应先确认瓶颈所在，再调整调用策略；单纯增加额度或反复重试，可能既无法提速，又扩大预算消耗。
并发限制与 Token 额度有什么区别？
并发通常指同一时刻尚未完成的请求数量，RPM 表示单位时间请求数，TPM 则衡量单位时间的 Token 吞吐。余额和预算决定费用边界，不等于请求处理能力。账户有余额，不代表高并发请求一定能够通过。实际约束还可能来自模型、渠道、项目或上游账户，需以接口文档和返回信息为准。
长上下文、大输出和持续时间较长的流式响应，会延长请求占用连接的时间。即使每分钟请求数不高，也可能出现并发积压。部分服务还会根据最大输出配置估算限流占用，因此不能只看最终生成了多少 Token。
出现 429 或超时，先定位哪一层受限
- 记录状态码、错误正文、请求 ID、模型、耗时及返回的限流相关响应头；429 的具体含义应结合错误说明判断。
- 检查中转账户、API Key、项目与模型是否分别设有限额，确认是否与其他业务共享资源。
- 区分连接超时、网关超时与上游限流，避免把所有失败都归因于并发不足。
- 用少量请求逐步增加负载，观察成功率、延迟和 Token 吞吐，不要直接用生产流量进行冲击测试。
建议同时记录“进行中请求数”和“等待队列长度”。如果队列持续增长而完成速度不变，说明当前流入速度超过处理能力，应降低入口速率，而不是继续堆积任务。
如何同时控制并发与 Token 成本？
优先采用有界队列、并发信号量和请求速率限制。并发上限应依据实测延迟、业务容忍度和账户约束设置，并非越高越好。交互请求与批量任务可使用独立队列，给在线业务预留处理空间；批处理则适合错峰执行。
Token 预算需要单独治理：裁剪重复历史消息，按任务设置合理的最大输出长度，为长文档分段，并在质量验证后将简单任务分配给成本更合适的模型。预算估算应拆分输入、输出及缓存等可能的计费项，按实际渠道账单规则计算，不宜套用统一单价。
设置日预算、任务预算和接近阈值告警。预算告警不等于硬性停机，如需强制止损，应在应用侧检查预算，并为尚未结算的进行中请求预留空间。具体用量以服务返回的 usage 和账单核对结果为准。
重试与采购时应注意什么？
对可重试错误采用指数退避和随机抖动，并在返回 Retry-After 时参考其指示，同时限制重试次数。超时后先判断任务是否已经执行，避免重复提交；失败请求是否产生费用，应核对实际处理结果与计费规则。无限重试会放大拥塞，也可能增加支出。
选购 API 中转或 Token 批发服务时，应询问目标模型的并发口径、共享资源情况、限流响应、用量明细及预算控制能力。在 openmagic.ai 规划接入时，也应先明确峰值请求量与输入输出规模，再核实适用方案，通过小规模压测验证，不将购买额度视为稳定性保证。