接入 Gemini API 后，请求一多就出现 429、排队或超时，不一定是“并发额度不够”。请求频率、Token 吞吐、项目配额和中转网关限制，都可能成为瓶颈。对使用 API 中转或采购 Token 额度的团队，优化目标应是：在预算内获得可持续吞吐，而不是单纯增加并发。
并发、速率与 Token 配额不是一回事
并发是同时处理中的请求数量；RPM 通常表示每分钟请求数，TPM 表示每分钟 Token 吞吐，此外还可能存在其他周期或维度的限制。具体适用项应以所用模型、项目控制台及当前文档为准，不能把某个固定数字当作 Gemini API 的统一并发上限。
并发没满，不代表不会限流。长上下文请求可能先触及 Token 吞吐限制；大量短请求则可能先触及请求频率限制。中转接入还需区分上游模型配额与网关自身的队列、连接数、租户限额，避免把所有错误归因于 Gemini。
如何定位 429、超时与吞吐下降
- 保留状态码、错误正文、请求 ID、模型标识及时间戳，判断错误来自网关还是上游。
- 分别统计进行中请求数、每分钟请求量、输入与输出 Token、延迟和失败率，不只看平均响应时间。
- 用短文本、长上下文和受控输出长度分别压测，逐步增加负载，寻找吞吐不再增长的拐点。
- 检查多个应用、密钥或环境是否共享项目配额；新增密钥不应被视为扩容保证。
流式输出能改善首字等待体验，但连接可能持续占用资源，并不自动提升配额。超时也不等于上游没有执行，是否产生费用应结合用量记录核对。
用 Token 预算反推安全并发
可先用“目标每分钟请求量 × 单次平均 Token”估算吞吐需求，再依据该限制实际统计的 Token 类型校准。并发初值可参考“每秒请求量 × 平均处理秒数”，但这只是容量估算，仍需为长尾延迟和突发流量留出余量。
预算控制必须同时限制请求量与单次消耗。设置输出 Token 上限，裁剪无关历史消息，并为不同任务分配不同预算。成本预测应使用对应模型当前计价规则，区分输入、输出及适用的其他计费项；不要将总 Token 简单乘以单一价格，也不要把缓存优惠当成必然收益。
中转接入如何兼顾成本与稳定性
应用侧可配置有界队列、最大并发和租户日预算，队列满时明确返回繁忙提示。针对可重试错误，采用指数退避与随机抖动，设置重试次数及总等待上限；若响应提供重试等待信息，应结合接口说明处理。无上限重试会放大拥塞，也可能带来重复调用成本。
评估 API 中转方案时，应确认限流维度、余额扣费口径、失败请求计费方式、用量查询能力，以及路由变化是否影响模型行为。使用 openmagic.ai 接入时，也应以实际服务说明和账单记录核对这些项目，而非假定中转能够绕过上游限制。
上线后为余额、Token 消耗速率、429 比例和排队时间设置告警。接近预算阈值时，优先减少非必要任务或延后批处理。先分清配额瓶颈，再调整队列和预算，才能让 Gemini API 的扩容投入更可衡量。