接入 Gemini API 时，增加并发不一定提高有效吞吐量，反而可能造成限流、超时和重试放大。对通过 API 中转采购额度的团队，真正需要核算的是：单位时间能完成多少有效请求，以及这些请求消耗多少 Token。本文不预设固定额度，具体限制应以对应模型、项目、计费层级及中转渠道说明为准。
并发、速率与 Token 限额不是一回事
并发是同一时刻正在处理的请求数；速率限制关注单位时间的请求量；Token 限额则约束一定时间窗口内的处理量。并发数不等于每分钟请求额度。长提示词、大段输出或响应变慢，都可能让在途请求堆积，即使请求次数不多，也可能碰到其他资源限制。
排查 Gemini API 并发限制时，应记录模型标识、请求耗时、输入输出 Token、状态码及错误正文。429 通常提示限流或配额问题，但不能仅凭状态码认定是并发过高；还需结合错误详情、项目配额和中转网关日志判断。
先算 Token 预算，再决定放多少并发
预算可以拆成单请求、分钟和日级三层。单请求估算应覆盖输入与预期输出；若涉及缓存、多模态或其他计费项，需按实际计费规则单独核算。成本估算可采用“各计费项用量 × 对应单价”的求和方式，避免把不同模型或不同类型 Token 混用一个价格。
- 单请求：限制上下文长度和最大输出量，为长文档设置独立任务队列。
- 分钟级：同时控制请求速率、预估 Token 用量和最大在途请求数。
- 日级：配置预算告警与消费阈值，按业务优先级决定暂停或降级。
- 账单侧：对照网关记录与供应渠道账单，确认失败、重试及特殊计费项的处理方式。
余额充足不代表吞吐额度充足。采购 Token 或充值前，应分别确认余额、模型权限、速率限制和共享资源策略，不能把大额余额当作高并发保障。
用队列和退避重试减少成本放大
稳定方案是在业务入口设置有界队列，由工作池控制并发，再用速率限制器约束请求与 Token 消耗。并发起点可参考“目标每秒请求数 × 平均响应秒数”估算，随后通过压测调整；这只是容量规划方法，不是平台承诺额度。
遇到可重试的限流或临时故障，应采用带随机抖动的指数退避；若响应提供重试提示，则结合提示处理，并设置最大重试次数及总时限。鉴权失败、参数错误等问题不应盲目重试。重试也必须纳入预算与流量控制，否则故障期间可能出现请求风暴。超时不一定表示上游未执行，重复提交也可能产生额外消耗。
采购中转服务前要确认哪些条件？
评估 Gemini API 中转渠道时，重点询问额度属于独享还是共享、限制按账号还是模型生效、是否有网关额外限流，以及能否查询用量明细。接入 openmagic.ai 等中转服务前，应核实目标模型、接口格式、计费口径与错误透传方式，不默认所有渠道都完全兼容现有 SDK。
上线后持续观察成功率、尾部延迟、429 占比和每个成功任务的实际成本。采购判断应围绕有效吞吐量与可解释账单，而非只看单价；先以真实任务小流量验证，再逐步扩大并发，更容易兼顾成本与稳定性。