接入 OpenAI、Claude、Gemini 等模型 API 后，请求变慢、出现 429 或余额消耗突然加快，不一定是模型故障，也可能是 API 中转并发限制、上游速率配额与应用重试相互叠加。对采购 Token 额度或使用模型网关的团队，目标不是盲目提高并发，而是让吞吐、预算和响应时间保持可控。
先分清并发、速率与 Token 额度
并发限制通常指同一时刻允许处理的请求数量；RPM 指单位时间请求数，TPM 指单位时间 Token 数。余额则关系到计费资源是否充足。提高并发不等于提高上游配额：即使中转入口允许更多连接，也可能因模型、项目或账户限额而遭遇限流。
流式输出尤其需要注意。请求可能持续占用连接直到生成结束，因此相同请求量下，长回答更容易耗尽并发槽位。选购 API 中转服务时，应确认限制按密钥、账户、模型还是共享资源池计算，以及排队和流式连接是否计入并发。
并发为什么会影响 Token 成本？
并发本身通常不是 Token 计费单位，但它会放大单位时间内的消费速度。粗略估算时，可用“每分钟成功请求数 × 单次平均计费成本”观察预算燃烧速度。输入、输出、缓存及不同模型的计费规则可能不同，应以实际账单为准。
最容易漏算的是重复请求和无效长输出。客户端超时后立即重试，原请求却可能仍在执行；过长历史上下文被反复发送，也会增加输入消耗。失败、取消或断连请求是否产生费用，需要结合中转记录与上游使用量核查，不能仅凭 HTTP 状态码判断。
用四步控制并发与预算
- 先测量，再设上限：按模型记录请求耗时、活跃连接数、Token 用量和错误率，从低并发逐级压测，观察延迟明显上升的位置。
- 设置有界队列：给交互请求和后台任务分配独立并发池，限制队列长度与等待时间，避免离线任务挤占在线服务。
- 控制单次消耗：按任务设置输出上限，裁剪无关上下文；能用较低成本模型完成的任务，先验证质量再分流。
- 分层管理预算：按项目或密钥设置日预算、预警线与消费速率阈值。若平台不支持硬限额，应在应用网关补充拦截逻辑。
429、超时与余额异常怎么排查？
出现 429 时，先读取错误正文和响应头，区分并发超限、RPM/TPM 限流或额度问题；平台错误映射可能不同，不能只看状态码。若返回 Retry-After，应按提示等待；否则使用带随机抖动的指数退避，并限制重试次数与总时长。
超时则要区分连接超时、首字节超时和生成过程断流。不要把所有超时都当成可立即重试的失败。为业务请求生成追踪标识，关联客户端、中转和上游日志；对有副作用的工具调用增加业务去重，防止重复执行。
采购或扩容前，向服务方核实模型级并发、共享池规则、限流提示、用量明细和预算控制能力。只有当监控显示瓶颈确实位于中转并发层时，增加并发额度才有意义；否则优先优化长请求、上下文与重试策略，通常更利于控制成本和稳定性。