接入 Gemini API 时，请求变慢、出现 429 或任务积压，不一定是并发连接数过多，也可能是请求频率、Token 吞吐或其他配额触发限制。对通过 openmagic.ai 等 API 中转服务接入的业务，更应同时核对上游配额与网关约束，避免把限流误判为余额不足，或靠盲目重试放大成本。
先区分并发、速率与 Token 配额
并发是同时执行的请求数，不等于每分钟可发送的请求数。长文本生成占用连接时间更久，即使请求频率不高，也可能耗尽应用侧工作槽；短请求则可能在低并发下触发频率限制。Gemini API 的实际限制应以当前官方文档、项目配额页面及所用中转渠道说明为准，不宜套用固定数值。
- 请求维度：检查单位时间请求量、突发流量与队列长度。
- Token 维度：记录输入、输出及适用的其他计费用量，关注长上下文任务。
- 账户维度：核对项目、模型、渠道的配额范围，以及余额和预算设置。
- 网关维度：确认是否存在独立并发上限、超时、排队与请求体限制。
排查时保留状态码、错误正文、请求时间、模型标识与请求 ID。429 通常提示资源或速率相关问题，但不能只凭状态码确定原因；超时和 5xx 也应结合网关日志判断。
用排队与退避代替无限重试
应用侧应设置有界队列和并发信号量，把交互请求与批处理任务分开。先用小流量测量平均耗时和尾延迟，再逐步增加工作槽。以请求到达速率乘以平均处理时长，可粗估平均在途请求数，但不能将其当作服务方承诺的并发额度。
重试必须同时受次数、时间与预算约束。对可重试错误采用带随机抖动的指数退避，并在响应提供有效 Retry-After 时参考执行；鉴权失败、参数错误等问题应先修复。流式输出中断后重发，可能产生重复内容及额外用量，需记录任务状态并去重。
把 Token 预算放到请求发出之前
成本控制不能只看请求次数。建议根据适用模型与渠道计费规则，分别估算输入和预期输出成本；缓存或其他用量项目仅在实际适用时单独计算。提交前预留预算，完成后根据 usage 和账单口径结算，超时请求则进入待核对状态，避免直接视为零成本。
预算上限与并发上限应联动设置。为单次输出设置合理上限，裁剪无关历史记录，对重复上下文评估缓存适用性。业务侧可设置用户日预算、任务预算和项目告警；接近阈值时优先延后批量任务，而不是继续扩容并发。
选择 Gemini API 中转前核对什么
评估中转接入时，应确认模型标识、SDK 兼容范围、流式响应、错误透传和用量查询方式。不要默认更换接口地址就能绕过上游限制，也不要把账户余额等同于可用吞吐。批发额度或充值方案还需核对计费单位、有效期、退款条件与适用渠道。
上线前用代表性请求压测，观察成功率、尾延迟、429 比例和单位任务成本，再确定并发与预算阈值。稳定接入的关键不是无限提高并发，而是让排队、限流、用量核算和告警形成闭环。