接入 Gemini API 时，请求变慢、排队或出现 429，不一定意味着“并发数不够”。请求频率、Token 吞吐、项目配额及中转网关策略，都可能成为瓶颈。对批量生成、客服和长文处理业务，先定位限流层级，再调整并发与预算，比直接扩容更有效。
Gemini API 并发限制：先区分三个指标
并发数不等于每分钟请求数，也不等于 Token 吞吐量。并发是同时在途的请求数；请求速率反映单位时间发起多少次调用；Token 吞吐则与输入长度、生成长度和请求密度有关。相同并发下，短问答与长文生成的资源占用差异很大。
实际限制可能随模型、项目、账户层级和接入方式变化，应以当前控制台、官方文档及网关配置为准。通过中转调用时，还要区分上游项目配额、网关限流和业务端连接池，不能将所有失败都归因于 Gemini 官方限制。
并发为什么会放大 Token 成本？
并发本身不会改变单次请求的 Token 单价，但会提高单位时间的消耗速度。上下文重复发送、输出过长、超时后重试，都可能放大费用。尤其在客户端超时而上游仍处理时，立即重发可能造成重复工作；是否产生费用应结合实际用量记录核查。
预算要按输入、输出和重试分别估算。可用“预计请求量 × 单次平均输入及输出 Token × 对应计费单价”做基础测算，再为流量波动预留空间。模型价格、缓存及其他计费项目，以所用渠道的明确说明为准，不宜套用统一数字。
- 按任务类型记录输入与输出 Token，避免仅看总调用次数。
- 设置合理的输出上限，减少无效长答案，但保留必要质量空间。
- 对重复任务做业务去重，缓存适合复用的结果。
- 设置日预算、租户预算和告警阈值，并验证停用机制是否生效。
出现 429 或超时，如何调整并发？
先保存错误码、错误正文、请求标识、模型名与时间，再对照网关和上游日志。429 通常与限流或配额有关，但具体原因需要看返回信息；超时也可能来自网络、排队或生成耗时。余额不足则应单独排查，不能靠重试解决。
优先采用有界队列、并发上限和带随机抖动的退避重试。从较低并发开始压测，观察成功率、延迟分位数和 Token 吞吐，再逐步提高。若响应提供可用的重试提示，应据此等待；同时限制重试次数和总耗时，避免高峰期形成重试风暴。
选择 API 中转时，重点核对什么？
采购 Gemini API 中转额度时，不只比较报价，还应确认模型映射、计费口径、用量查询、限流规则及错误透传能力。共享资源与独立资源的表现可能不同，需要通过自己的请求样本验证，不能将宣传并发直接视为可持续吞吐。
在 openmagic.ai 的接入评估中，可先整理峰值请求量、平均上下文长度、目标响应时间和月度预算，再核对支持模型与网关能力。以小规模压测和用量对账决定扩容，才能让成本、吞吐与稳定性形成闭环。