接入 Gemini API 后，请求增多就出现 429、超时或账单上涨，未必只是“并发不够”。请求频率、Token 吞吐、输出长度和重试策略都会影响成本与稳定性。使用 API 中转时，还需区分业务端、网关和上游模型的限制，避免购买更多额度后，吞吐依然没有改善。
Gemini API 并发限制：先区分三种瓶颈
并发是同时处理的请求数量，RPM 是单位时间请求数，TPM 是单位时间 Token 吞吐，两者不能互换。具体限制应以所用模型、项目层级及当前控制台说明为准，不宜套用固定数值。中转平台也可能设置独立的并发、速率与余额规则。
- 短请求密集触发限制：检查请求频率，以及多个 API Key 是否共享上游配额。
- 长上下文请求容易失败：检查 Token 吞吐，不能仅根据请求数量判断负载。
- 请求耗时越长、积压越多：检查输出长度、网关超时和客户端连接池。
- 充值后仍无法调用：核对余额、模型权限与速率限制，三者并非同一概念。
余额代表支付能力，不代表可用并发。排查时保留时间戳、模型标识、错误响应及请求 ID，并区分错误来自中转网关还是上游服务。429 需要结合错误详情判断，不能直接认定为账户欠费。
Token 消耗怎样放大并发成本
长提示词、重复发送历史消息，以及未限制输出长度，都会增加单次调用成本。处理时间变长还会占用更多在途连接，推高排队时延。多模态输入、缓存和其他计费用量的口径可能不同，应以具体模型及账单说明为准。
预算可先按“请求量 × 平均输入与输出用量 × 对应单价”估算，再单列重试和异常消耗。不要把失败请求一律视为零成本。超时只说明客户端未及时收到结果，上游是否完成生成、是否计费，仍需核对用量记录。
控制预算与稳定性的四步配置
- 设置业务级并发池与有界队列。先小流量压测，观察成功率、延迟和 Token 吞吐，再逐步提高并发。
- 按任务限制输出预算。摘要、分类等任务使用适当的输出上限，裁剪无关历史，避免无限扩展上下文。
- 对可重试错误采用带随机抖动的指数退避，限制次数与总时长；参数错误、权限错误不要盲目重试。
- 设置日预算告警与应用侧停用阈值，按项目、Key 和模型记录用量，给关键业务保留资源。
重试时还应避免重复执行写库、付款等业务操作。提高并发前，先确认重试没有形成流量放大。对于非实时任务，可通过异步队列削峰，降低瞬时压力。
选择 Gemini API 中转时核对什么
评估中转接入方案，应询问并发是否共享、限流发生在哪一层、Token 统计口径、失败计费规则，以及是否提供可核对的用量明细。SDK 即便兼容，也需验证模型名称、流式响应、超时和错误映射，不能只替换地址就直接上线。
在 openmagic.ai 规划接入时，建议先用代表性请求验证链路，再根据实测吞吐配置预算。采购应比较有效成功请求的成本，而不只是表面单价；配额、排队、计费与可观测性清楚，才便于判断是否适合业务。