接入 OpenAI、Claude、Gemini 等模型 API 时，遇到排队、429 或响应变慢，不一定是余额不足，也可能是 API 中转并发限制与上游限流共同作用。对通过 openmagic.ai 等中转入口接入的业务，排查重点应是：限制在哪一层、重试是否放大消耗，以及高峰请求能否进入预算。
并发限制与 Token 配额有什么区别？
并发数是同一时刻正在处理的请求数量；RPM 是每分钟请求数，TPM 是每分钟 Token 数，余额则决定还能支付多少用量。四者不能互相替代：账户有余额，不代表可以无限并发；请求数不多，长上下文也可能耗尽 Token 速率窗口。
实际吞吐取决于链路中最紧的限制。中转入口、账户、模型路由和上游服务都可能有限制。流式输出通常会持续占用连接，因此还要确认平台如何统计在途请求，不能把“已收到首个字”视为并发释放。
为什么提高并发可能让预算失控？
并发本身不是计费单位，但会让更多请求同时产生用量。若平均每次请求消耗 T 个 Token、每分钟完成 N 次，请求量级可按 T×N 估算；费用还需分别计算输入、输出及实际适用的其他计费项，不能只看总 Token 数。
超时后的立即重试尤其危险：客户端停止等待，并不一定代表上游已经停止生成。若原请求仍在执行，新请求又被提交，就可能形成重复工作。失败、取消及缓存用量如何结算，应以实际计费规则和账单为准。
- 记录输入、输出 Token 与单次请求成本分布，避免只看平均值。
- 为不同任务设置合理的最大输出长度，限制异常长生成。
- 将用户操作、异步任务和重试流量分组统计，识别消耗来源。
- 为日预算和月预算设置预警，并明确触发后的降级策略。
如何设置兼顾成本与稳定性的并发上限？
先用真实业务样本低并发压测，记录成功率、首 Token 延迟、总耗时及限流比例，再逐步增加并发。粗略估算时，并发需求约等于每秒请求数乘以平均处理秒数，但长文本和流式任务会拉长尾部耗时，必须保留余量。
把并发控制与速率控制分开做。用信号量限制在途请求，用速率限制器约束请求数与预计 Token 用量，再用有界队列吸收短时峰值。队列需要最大长度和等待超时，超出时明确拒绝或转为异步任务，避免无限等待。
预算控制也应分层：账户设总预算，业务设子预算，单次任务设输出边界。调用前可按预计用量预留预算，完成后按实际用量校正；本地估算不等于最终账单。高成本任务还可增加用户确认，避免批量误触发。
遇到 429、超时和余额异常怎么排查？
先保存请求 ID、时间、模型、状态码与错误正文，再结合响应头和平台日志判断来源。429 可能对应不同限流维度；超时也可能来自网络、队列或上游处理过慢，不能仅凭状态码认定需要购买更高并发。
重试应有退避、抖动和次数上限。若返回 Retry-After，可按其提示安排等待；余额不足、鉴权失败等问题不应盲目重试。是否允许自动重试，还需结合任务可重复性与平台支持能力判断。
选择 API 中转或 Token 批发方案时，应核对并发口径、模型级限制、用量明细和账单可追溯性，而非只比较单价。先定位瓶颈，再调整配额与预算，才能减少无效扩容和重复消耗。