接入 OpenAI、Claude、Gemini 等模型 API 时，请求变慢或出现 429，不一定是余额不足，也可能是 API 中转并发限制、上游速率限制或应用重试共同造成的拥堵。对通过 openmagic.ai 等中转服务接入模型的团队，合理做法是先核对账户限制和计费规则，再按业务预算设置并发，而不是直接增加线程。
并发限制与 Token 额度有什么区别？
并发是同一时刻尚未完成的请求数量；RPM 通常表示每分钟请求数，TPM 表示每分钟 Token 数。余额决定能否继续付费，却不代表请求可以无限并行。限制可能来自中转账户、模型通道或上游供应商，具体口径应以服务说明与实际响应为准。
并发不直接决定单次调用的 Token 消耗，但会加快预算消耗速度。长上下文、大量输出和多轮历史会增加单次成本；流式响应仍可能持续占用连接与并发槽位，不能因为已经收到首个字符就认为请求结束。
如何从预算反推并发上限？
先按模型与任务统计平均输入、输出 Token，再结合当前适用单价估算单次成本。单次预估成本约等于输入 Token 费用加输出 Token 费用；缓存、工具调用等项目若单独计费，也需纳入。不要只用请求次数衡量成本。
- 设置日预算与小时预算，避免短时流量提前消耗全天余额。
- 记录平均耗时及高分位耗时，用目标吞吐量乘以请求耗时估算所需并发，统一时间单位。
- 将估算结果与账户并发、RPM、TPM 限制交叉校验，采用更保守的边界。
- 为超时、流量波动和重试预留余量，通过压测逐步调整，不直接跑满限制。
预算控制应在请求发出前执行。可依据输入长度与输出上限预占预算，完成后按实际用量结算。输出上限不等于实际消耗，也未必等于平台限流时采用的预估口径，需要分别核对。
429、超时与重试如何避免成本失控？
遇到 429，先查看错误正文、响应头和请求日志，区分并发超限、速率超限或额度问题。若响应提供 Retry-After，应参考其等待时间；否则采用带随机抖动的指数退避，并限制重试次数与总等待时长。余额不足、参数错误等问题不应盲目重试。
超时不代表上游没有执行，也不代表一定不计费。客户端重复提交可能带来额外生成成本。应记录业务任务标识与请求标识；只有接口明确支持幂等语义时，才依赖幂等机制避免重复执行。流式请求中断后，还应核对取消是否生效及最终用量。
接入模型网关时需要检查什么？
建议在网关侧统一设置并发信号量、限速器、有界队列和预算阈值，并按模型、租户或 API Key 隔离。关键在线请求与批处理任务分开排队，队列满时明确拒绝或延后处理，避免所有任务一起超时。
选择 API 中转或 Token 批发方案时，除单价外，还应确认并发限制口径、模型独立限额、用量查询方式及失败请求计费规则。持续观察成功率、排队时间、429 比例与单位任务成本，才能判断扩容是否必要，而非仅凭余额或宣传中的高并发做采购决策。