接入 Gemini API 时，请求增加后出现排队、429 或超时，不一定是并发数触顶，也可能与请求速率、Token 吞吐或项目配额有关。企业通过 API 中转站接入时，还要核对网关自身的限流规则。排查重点不是盲目购买更多额度，而是找出限制所在，再控制调用成本。
Gemini API 并发限制与 Token 额度有什么区别？
并发表示同时处理中的请求数；RPM 表示每分钟请求量；TPM 表示每分钟 Token 吞吐。三者相关，但不能互相替代：长上下文可能在请求量不高时触及吞吐限制，生成耗时较长则会持续占用连接。账户余额充足，不代表请求速率和并发容量充足。
具体限制应以当前模型、项目、接入方式及控制台显示为准，不宜套用网上的固定数值。通过 openmagic.ai 等中转入口接入时，应分别确认上游配额、网关限流与账户权限；不要把中转可接受的连接数直接当作上游可处理的容量。
先做容量估算，再配置预算
可用“每秒请求数 × 平均请求耗时”估算平均在途请求量，再结合峰值流量和尾部延迟压测。这个结果只是容量规划起点，不是官方并发额度。Token 预算则应分别记录输入、输出及接口支持的其他计量项，按实际模型计费规则核算。
- 按业务拆分预算：客服、批处理、长文生成分别设置日预算和告警线。
- 限制单次消耗：裁剪无关历史、检索后再组装上下文，并设置合理输出上限。
- 控制突发流量：配置并发信号量、限速器和有界队列，避免瞬间放大请求。
- 定期对账：对比接口返回的用量字段、中转账单和业务请求记录。
预算控制应覆盖已完成消耗与在途请求的预估消耗。只在余额扣减后拦截，可能让大量已发出的请求继续产生费用。预估值可用于预占预算，完成后再按实际用量结算；是否计费仍须依据具体服务规则，不能假定失败请求一律免费。
429、超时与重试：怎样避免越重试越贵？
遇到 429，先检查错误响应、请求标识和限流提示，区分上游配额不足与网关限流。如响应提供 Retry-After，应结合该提示等待；否则采用带随机抖动的指数退避，并设置最大重试次数与总时限。鉴权失败、参数错误等通常不应无条件重试。
超时也不等于生成未发生。尤其是流式输出中断后，重新提交可能重复计算。重试必须受预算、截止时间和业务去重机制约束。对于非实时任务，可进入延迟队列；对于交互任务，应明确提示稍后重试，避免静默循环。
采购 Gemini API 中转服务前核对什么？
评估 Token 批发或 API 中转方案时，不要只比较单价。应核对模型标识、用量统计口径、限流维度、超时设置、错误透传和账单明细；若有备用路由，还要确认是否改变模型、数据处理路径及成本。较低单价不必然代表较低的有效任务成本。
上线前先用小流量记录成功率、P95 延迟、429 占比和单任务 Token 消耗，再逐步增加并发。以可观测数据决定扩容，而不是靠增加重试维持表面成功率。这样才能同时管理 Gemini API 的接入成本、预算风险与服务稳定性。