接入 Gemini API 时，业务同时发起多个请求后出现排队、429 或费用波动，不一定只是“并发数太高”。请求频率、Token 吞吐、模型配额和应用侧连接数都可能成为瓶颈。通过 API 中转接入时，还要区分上游限制与网关自身限流，才能判断该调整队列、优化 Token，还是评估额度方案。
并发限制与 Token 配额有什么区别？
并发数不等于每分钟请求数，也不等于 Token 吞吐量。并发描述同一时刻正在处理的请求数量；请求速率描述时间窗口内的调用次数；Token 指标则衡量输入、输出等用量。具体限制维度及统计口径，应以所用模型、项目的控制台和当前文档为准，不能套用一个固定数值。
长上下文、大输出和较慢的响应会延长连接占用时间。同样的请求频率下，响应越慢，在途请求往往越多。因此，遇到拥堵不能直接增加工作线程，否则可能让排队与重试同时放大。
如何估算并发与 Token 预算？
可以用“平均在途请求数≈每秒请求数×平均响应秒数”估算基础容量，再通过压测观察高峰和尾延迟。这个关系用于规划，不代表服务方允许的并发上限。流式返回能改善首字等待体验，但不代表总 Token 更少，也不意味着连接更早释放。
- 按任务记录输入 Token、输出 Token、响应时长与成功率，避免只看总请求数。
- 为短问答、长文档和批量任务分别设置队列，减少长任务挤占交互请求。
- 按当前计费口径估算单次成本；缓存、多模态等用量如有独立计费，应单独核算。
- 同时设置日预算、任务预算与单次输出上限，并在接近阈值时告警或暂停低优先级任务。
预算预留与实际扣费应分开管理。请求发出前按预估消耗预留预算，结束后按可获得的用量数据核对；超时或断流也要保留待核对记录，不能一律当作未产生费用。中转账户余额与上游项目额度也不是同一概念，余额充足不代表不会触发限流。
429、超时与重复计费风险怎么排查？
出现 429 时，先检查响应错误信息，确认属于短时速率限制、配额问题还是中转网关策略。若响应提供 Retry-After，可据此安排等待；否则使用带随机抖动的指数退避，并限制重试次数与总等待时间。重试也要纳入预算和并发控制，避免大量客户端同步重试造成二次拥堵。
超时不代表上游一定没有执行。对生成类调用，盲目重发可能产生重复任务和额外消耗。建议记录业务任务 ID、请求 ID、模型名称和时间戳，在应用侧做任务去重；不要默认所有接口或中转线路都支持幂等处理。
采购 Gemini API 中转额度前核对什么？
选择中转方案时，应核对限流作用于账户、密钥还是模型，是否有共享资源池，以及排队超时、失败请求、用量明细和余额告警如何处理。所谓“兼容 SDK”也应实测模型映射、流式响应与错误字段，不能只验证一次普通请求成功。
在 openmagic.ai 规划接入时，可先提供预计请求频率、上下文长度、输出长度与峰值持续时间，再评估额度和网关配置。先用小流量验证，再逐步放量，比仅依据低单价或高并发描述采购，更有利于控制实际成本与稳定性风险。