接入 Gemini API 时，请求变慢、排队或出现 429，不一定是账户余额不足，也不能简单归因于“并发太高”。模型、项目、账户层级及接入路径可能对应不同限制。对使用 API 中转的团队，还要区分上游配额与网关自身限流，才能避免一边加重试、一边扩大成本。
并发限制与 Token 配额有什么区别？
并发数不等于每分钟请求数，也不等于 Token 吞吐量。并发描述同一时刻正在处理的请求数量；请求频率描述时间窗口内的调用次数；Token 吞吐则与输入、输出规模有关。具体限制应以当前官方文档、项目控制台及服务商说明为准，不宜套用固定数值。
例如，短问答虽然单次消耗少，但瞬间集中提交仍可能触发请求频率限制；长文档分析即便请求不多，也可能占满 Token 预算。流式输出会延长连接占用时间，因此连接数高并不必然代表单位时间消耗更高，仍需结合实际用量判断。
遇到 429，先定位限制来自哪里
Gemini API 经中转网关调用时，错误可能来自上游，也可能由中转层的套餐规则、共享通道或队列容量触发。不要把所有 429 都当成可以立即重试的瞬时故障。应查看响应体、错误类型、请求标识，以及存在时的重试提示，再决定是否等待、降速或调整配额。
- 记录模型名称、请求时间、耗时、状态码及实际返回的用量字段，避免记录敏感正文。
- 分别统计在途请求数、请求频率和 Token 吞吐，定位哪个维度先触顶。
- 核对项目可用配额、中转账户余额与网关限流配置，避免混淆额度不足和速率限制。
- 对照业务高峰与错误分布，判断是持续超限，还是短时突发流量。
用队列与预算约束控制放大成本
更稳妥的方案是将业务请求先放入有界队列，再通过并发信号量和速率控制器发往上游。初始并发应保守设置，根据延迟、超限比例和成功吞吐逐步调整，而不是追求连接数最大化。队列还应设置超时与长度上限，避免流量高峰转化为无限等待。
对于适合重试的错误，可采用指数退避与随机抖动，同时限制重试次数和总等待时间。重试也要纳入预算，失败请求是否计费需按具体服务规则核对。若上游已处理而客户端仅因超时断开，直接重发可能造成重复生成；应结合业务去重和结果状态检查降低风险。
Token 预算可拆成单次请求、用户日预算和项目月预算。请求前估算输入规模，并使用所选模型支持的参数约束输出；请求后以实际用量校准。长上下文优先裁剪重复历史、提取必要片段，缓存仅在适用且确认计费规则后启用。预算接近阈值时，可暂停非紧急任务或要求人工确认。
选择 Gemini API 中转时要核对什么？
评估 Token 批发或中转方案，不应只看单价，还应核对模型标识、计费单位、用量明细、限流维度、排队策略及错误透传能力。中转层能帮助管理流量，但不代表可以绕过上游配额。在 openmagic.ai 规划接入时，建议先用真实业务样本压测，再按成功请求成本、尾延迟和预算消耗评估方案，避免仅凭峰值并发做采购判断。