接入 Gemini API 后，请求变多就出现 429、延迟升高或账单超预期，不一定是“并发额度不足”。请求速率、Token 吞吐、排队时间与重试策略可能共同形成瓶颈。无论直连还是通过 API 中转站调用，都应先确认限制发生在哪一层，再调整并发与预算，避免只加线程却放大成本。
Gemini API 并发限制，先分清限制对象
并发数不等于每分钟请求数，也不等于 Token 配额。并发描述同一时刻正在处理的请求数量；请求速率限制单位时间内的调用次数；Token 吞吐则与输入、输出长度有关。具体限制可能随模型、项目和服务层级变化，应以实际控制台、响应信息及当前文档为准，不能套用固定数字。
使用中转服务时，还可能叠加网关并发、账户额度与上游限制。中转账户有余额，并不代表上游请求一定可接受；提高本地并发，也不会自动提高上游配额。
- 低并发仍报错：检查请求速率、Token 吞吐、账户状态与错误详情。
- 短请求正常、长文本失败：检查上下文长度、输出上限和请求超时。
- 高峰期延迟明显增加：观察网关排队、上游响应和客户端连接池。
- 更换模型后表现不同：按模型分别统计，避免混用容量结论。
Token 消耗如何转化为预算护栏
预算应按完整任务估算，而不只按一次成功请求计算。输入历史、系统提示、检索材料与生成内容都可能影响用量；失败重试是否产生费用，需要结合失败阶段、实际 usage 和服务商账单核对，不能假定全部免费或全部收费。
可先用代表性样本测量单任务的平均输入、输出与重试次数，再依据实际计价规则估算成本。若涉及多模态、缓存或不同 Token 类型，应分别核算。模型用量与中转账单需区分记录，确认计费单位和倍率后再做预算。
为每个业务设置输出上限、重试上限和每日预算阈值；超长历史先裁剪，重复资料按任务需要精简。临近预算阈值时，可暂停非紧急批处理、缩短输出，或在验证效果后切换成本更合适的模型。
遇到 429，怎样兼顾吞吐与稳定性
先记录 HTTP 状态码、错误正文、请求标识、模型、耗时和用量，确认是上游限流还是中转网关拒绝。429 不应触发无限重试。若响应提供等待提示，优先遵循；否则使用带随机抖动的指数退避，并限制重试次数与总等待时间。
客户端宜同时设置有界队列、并发信号量与速率控制器，从较低负载逐步压测，观察成功率、尾延迟及单位成功任务成本。流式响应虽然能改善首字等待体验，但不代表请求立即释放容量，应按连接生命周期管理并发。
采购 Gemini API 中转服务，要核对什么
评估 openmagic.ai 等中转接入方案时，应核对模型标识、接口兼容范围、限流层级、余额扣费口径和用量查询方式，不应仅比较标称单价。若业务需要稳定吞吐，还需确认队列超时、错误透传和故障定位所需日志是否满足要求。
上线前用接近真实长度的请求做小规模验证，再逐步放量。以单位成功任务成本衡量接入效果，将失败、重试和排队纳入评估，比单看每 Token 报价更能判断方案是否适合生产业务。