接入 Gemini API 时，请求增多后出现排队、429 或费用上涨，不一定是“并发额度不够”。请求频率、Token 速率、模型差异与客户端重试，都可能影响吞吐。通过 API 中转调用时，还需区分上游模型限制与中转网关限制，避免盲目增加额度却没有改善稳定性。
Gemini API 并发限制：先确认瓶颈在哪一层
并发数不等于每分钟请求数，也不等于 Token 额度。并发描述同时处理的请求数量，RPM 描述单位时间请求数，TPM 则约束 Token 吞吐。实际适用的限制维度和数值，应以所用模型、项目及当前官方控制台或服务商说明为准，不能套用统一数字。
当平均响应耗时变长，即使请求频率不变，在途请求也会增加。长上下文、较大的输出上限以及流式连接持续占用，都可能让客户端连接池或网关队列先达到瓶颈。因此，排查时应同时记录请求开始时间、首 Token 延迟、总耗时与在途数量。
- 上游层：核查模型对应的速率限制、项目配额及错误详情。
- 中转层：确认限流按账号、密钥还是模型计算，以及是否存在排队上限。
- 客户端层：检查连接池、超时、工作线程与重试逻辑。
- 业务层：区分短问答、长文生成与批量任务，避免共用同一队列。
用 Token 消耗估算预算，而不是只看调用次数
同样一百次调用，输入长度与实际输出不同，成本可能相差很大。预算估算应分别汇总输入 Token 与输出 Token，再按所用模型及渠道的有效单价计算；缓存、多模态等计量项目如有适用，也应单独核对。不要把余额充足理解为速率限制已经解除。
预算控制应同时设置单请求、单任务与每日上限。单请求限制上下文长度和最大输出；单任务限制总调用次数与重试次数；每日上限则约束整体支出。可在业务侧用历史平均用量预估费用，并在请求结束后以返回的用量信息或账单记录校准。输出上限不是实际输出量，也不应直接当成最终计费数量。
遇到 429，怎样避免重试放大费用与拥堵
429 通常提示速率或配额相关问题，但不能仅凭状态码判断原因。应结合响应正文、响应头和中转日志，确认错误来自上游还是网关。若返回 Retry-After，可据此安排等待；否则采用带随机抖动的指数退避，并限定尝试次数和总等待时间。
不要让所有失败请求立即同时重试。对流式请求或连接中断后的请求，还应判断是否已经生成部分内容，避免重复执行与潜在的重复成本。对明确的余额不足、参数错误或权限问题，不应持续自动重试。
采购中转额度前，核对哪些稳定性条件
评估 Gemini API 中转服务时，应将价格、限流规则和计费口径一起比较。确认模型标识是否明确、用量是否可查询、失败请求如何计费，以及是否支持按密钥分配预算。低单价若伴随频繁超时和重复调用，实际任务成本未必更低。
在 openmagic.ai 规划接入时，可先用代表性任务做小规模压测，逐步提高并发，观察成功率、延迟和单位任务 Token 消耗。再按峰值需求设置队列、预算预警与降载策略。以可观测的吞吐和实际任务成本做决策，比单独追求更高并发更可靠。