接入 Gemini API 后，业务并发一升高就出现限流、延迟增加或预算消耗过快，未必只是连接数不足。请求频率、Token 吞吐、模型配额和重试策略都可能形成瓶颈。通过 API 中转或模型网关接入时，还需要区分上游配额与中转侧限制，才能判断应该扩容、排队还是优化调用。
Gemini API 并发限制，不等于每分钟请求限制
并发是同一时刻尚未完成的请求数量，RPM 是每分钟请求数，TPM 是每分钟 Token 数，三者不能互相替代。具体限制及统计口径，应以当前模型、项目配置、官方控制台和接入渠道说明为准，不宜套用网上固定数字。
低并发也可能触发 Token 吞吐限制：少量长上下文请求就可能占用较多额度。反过来，大量短请求也可能先碰到请求频率限制。流式输出虽然能改善首字等待体验，却不意味着请求提前结束；连接持续时间变长，仍会增加在途请求数量。
出现 429 或超时，先定位哪一层受限
429 通常提示限流或配额问题，但不能仅凭状态码断定需要购买更高并发。中转链路可能包含客户端、网关和上游服务，应结合响应正文、请求 ID 与日志确认错误来源。超时也可能与排队、网络或生成耗时有关，不应全部归因于配额。
- 记录模型、请求时间、输入与输出 Token、延迟及状态码，观察失败是否集中在流量峰值。
- 检查网关的并发池、队列上限、请求超时与账户余额，区分本地拒绝和上游返回。
- 核对项目配额和使用量；如响应带有重试提示，再结合接口文档安排等待。
- 排查 SDK、业务服务和网关是否同时重试，避免一次失败被放大成多次调用。
用 Token 预算约束并发，而不是盲目加连接
并发扩容不会自动降低单次调用成本。预算估算可从“调用量×平均输入 Token×输入单价＋调用量×平均输出 Token×输出单价”开始；如涉及缓存、多模态或其他计费项目，应按实际规则单独核算。中转费用也应以明确的计费说明和账单为准。
建议分别设置单次输出上限、分钟级 Token 预算和日级费用阈值。长对话可以按任务裁剪历史、压缩重复背景，避免每轮无差别发送全部上下文。输出上限需要兼顾任务完整性，过低可能导致截断和重复调用，反而增加支出。
容量规划可用“目标每秒请求数×平均请求耗时”粗估在途请求量，再通过压测验证，并为耗时波动留出余量。队列应设等待上限，过载时返回可识别的繁忙提示，避免无限排队拖垮服务。
选择中转接入时，应核对哪些成本与稳定性指标
评估 Gemini API 中转方案，不能只比较 Token 标价，还应确认限流维度、额度共享范围、错误透传、用量查询和账单核对能力。中转不能绕过上游限制，也不能保证永不限流；可观测日志和清晰的计费口径，比笼统的高并发承诺更有价值。
在 openmagic.ai 规划接入时，可先整理目标模型、峰值请求数、平均上下文长度和月度预算，再依据实际配置做小流量验证。上线后使用有上限的指数退避与随机抖动，对不可重试错误及时停止；预算触线时执行告警、降级或暂停非关键任务，让成本与稳定性同时可控。