在使用 OpenAI、Claude、Gemini 等模型 API 时，很多团队会把“调用失败”简单归因于模型不稳定，但实际更常见的问题是API 中转并发限制没有规划好：请求同时涌入、队列堆积、重试过多，最终造成 Token 消耗失控、响应延迟上升，甚至触发上游限流。对于通过模型网关或 Token 中转站接入的业务来说，并发限制不是单纯的技术参数，而是成本、稳定性和用户体验之间的平衡点。
并发限制为什么会放大 Token 成本？
并发限制指同一时间允许发起或处理的请求数量。它与 QPS、RPM、TPM 不完全相同：QPS 更关注每秒请求数，TPM 关注每分钟 Token 量，而并发更关注“正在执行中的请求”。当长文本、复杂推理、多轮对话同时进入队列时，即使请求数不高，也可能因为单次输出时间长而占满并发。
成本放大的原因通常有三类。第一，客户端超时后重复提交，原请求可能仍在上游执行，导致重复计费风险。第二，失败重试没有区分错误码，把 429、超时、网络抖动都无脑重试，造成额外 Token 输入。第三，没有为不同业务设置预算池，测试任务、批处理任务和线上用户抢同一组额度，使高价值请求被低优先级任务挤占。
如何设计成本可控的并发策略？
建议先把模型调用拆成三层：入口限流、网关排队、上游模型调用。入口层限制用户或应用的提交速度，网关层控制每个模型、每个 Key、每个业务线的并发，上游层根据实际错误码和延迟动态调整。这样可以避免把所有压力直接推给模型 API。
- 按业务分配并发池：线上对话、后台批量总结、测试环境分别设置上限，避免互相抢占。
- 按模型设置 Token 预算：高成本模型用于复杂任务，常规任务优先走低成本模型或短上下文策略。
- 限制最大输入与输出：为 max_tokens、上下文长度、附件解析结果设置硬上限，防止单次请求吞掉大量余额。
- 重试要有退避机制：对 429、5xx、网络超时分别处理，加入指数退避和最大重试次数。
稳定性排查：从哪些指标看问题？
如果你怀疑 API 中转并发限制导致不稳定，可以先看四组指标：排队时长、上游响应时长、失败率、每分钟 Token 消耗。排队时长升高但上游正常，通常说明本地并发池太小或流量突增；上游响应变慢且 429 增多，说明可能触及上游速率或 Token 限制；失败率不高但余额消耗异常，则要重点排查重试、流式中断和重复提交。
在模型网关中，还应记录 request_id、用户 ID、模型名、输入 Token、输出 Token、错误码、重试次数和最终状态。没有这些字段，预算控制只能靠事后估算，很难定位哪类任务真正烧钱。对于企业内部应用，建议把日志与账单按项目维度聚合，形成日报或小时级告警。
预算控制的落地建议
一个实用做法是设置“软限制 + 硬限制”。软限制用于告警，例如某项目当天消耗达到预算 70% 时通知负责人；硬限制用于保护账户，例如达到 100% 后自动降级模型、停止低优先级批处理，或转入人工审批。这样既不会突然中断核心业务，也能避免预算被异常流量打穿。
同时，提示词也会影响并发与成本。过长的系统提示词、重复携带历史对话、未裁剪的检索结果，都会增加输入 Token，并拉长生成时间，从而占用更多并发槽位。优化提示词、压缩上下文、缓存常见结果，往往比单纯提高并发上限更有效。
总的来说，API 中转并发限制不是越高越好。合理的并发池、Token 预算、错误码策略和日志监控，才能在成本可控的前提下提升稳定性。如果你的业务正在接入多模型 API，中转层应优先解决额度隔离、并发治理、余额告警和失败重试，而不是只关注单次调用是否成功。