接入 OpenAI、Claude 或 Gemini 模型时，请求变慢、排队或出现 429，不一定是余额不足，也可能是 API 中转并发限制、上游速率配额或本地连接池触顶。对按 Token 计费的业务，盲目增加并发还可能放大重试和预算波动。排查时，应把同时处理的请求数、单位时间 Token 用量与费用分开观察。
并发限制与 Token 配额有什么区别？
并发指同一时刻正在处理的请求数量；RPM 通常表示每分钟请求数，TPM 通常表示每分钟 Token 数。三者可能同时生效，中转网关也可能按账号、密钥或模型设置独立限制。余额充足不代表并发和速率配额没有上限，购买 Token 额度前应确认这些限制的作用范围。
长上下文、较长输出和流式响应会延长请求占用时间。即使请求频率不高，也可能因旧请求尚未结束而堆满并发槽位。可用“平均每秒请求数 × 平均处理秒数”粗估在途请求量，再通过压测验证；平均值不能替代高峰与长尾延迟数据。
如何判断限流发生在哪一层？
先记录请求时间、模型、请求 ID、状态码、排队时长、首 Token 延迟和总耗时。429 常与限流有关，但需结合响应体及网关日志判断；连接超时和 5xx 也不能直接归因于并发不足。避免把含密钥或敏感提示词的完整请求写入日志。
- 检查应用侧：工作线程、连接池、任务队列是否先达到上限。
- 检查中转侧：确认账号总并发、单模型并发及共享额度规则。
- 检查上游侧：核对模型速率限制，以及响应中的限流信息。
- 检查重试侧：统计同一业务任务触发了多少次实际调用。
不要把所有失败都立即重试。对可重试错误采用有上限的指数退避与随机抖动，服务返回 Retry-After 时按其指示处理；余额不足、参数错误或鉴权失败，应先修复原因。失败或超时请求是否计费，要以实际用量记录和服务规则为准。
怎样设置并发，才能控制 Token 成本？
先测量单次任务的平均输入、输出 Token 和处理时间，再用当前适用单价估算成本。单次成本可按“输入 Token × 输入单价＋输出 Token × 输出单价”计算，并统一计价单位。缓存、工具调用等项目需按实际账单另行核对，不要假设所有模型采用相同口径。
- 从较低并发开始，逐步增加，观察成功率、尾部延迟和每个成功任务的成本。
- 分别设置输入长度、最大输出 Token、队列长度及等待超时，防止任务无限积压。
- 按项目设置日预算和预警阈值；需要硬限额时，在发起请求前预留费用空间。
- 将批处理与在线交互分开限流，避免后台任务占满交互请求的资源。
并发限制是调度手段，不是费用封顶机制。多个在途请求仍可能同时产生费用，用量回传也可能存在延迟，因此预算控制应为在途请求预留余量，并定期对账。
购买中转额度前应确认什么？
评估 API 中转或 Token 批发方案时，除了单价，还应确认并发是否共享、额度有效期、计费口径、用量查询方式和限流后的处理行为。接入 openmagic.ai 或其他中转服务时，先用目标模型和真实负载小规模验证，再决定是否增加额度或申请更高并发。以可核对的成功任务成本判断方案，比只看标称并发更有参考价值。