接入 Gemini API 后，请求增多便出现排队、429 错误或账单增长，未必只是“并发不够”。请求频率、Token 吞吐、输出长度及重试策略会共同影响成本与稳定性。通过 API 中转或模型网关调用时，还要区分上游额度与中转侧限流，避免升级套餐后仍未解决瓶颈。
并发限制与 Token 额度有什么区别？
并发是同时在途的请求数，不等于每分钟可发请求数。请求处理越久，连接占用越久；即使请求频率不高，长输出也可能堆积大量在途任务。每分钟请求数、Token 吞吐及其他配额则属于不同约束，具体适用范围和数值应以对应模型、项目及当前官方控制台为准。
经由中转调用时，还可能叠加渠道并发、账户频率或余额校验。购买 Token 额度不能直接理解为获得更高吞吐；额度充足，也可能因短时突发被限流。评估 Gemini API 并发限制时，应先确认限制来自哪一层。
出现 429 或超时，先定位再重试
429 通常提示某种限流或配额问题，但仅凭状态码无法判断具体原因。应结合错误正文、响应头中可用的提示和网关日志排查；超时则还可能涉及网络、排队或生成耗时，不宜一概视为额度不足。
- 记录模型、请求时间、在途数量、输入与输出 Token，以及上游请求标识；日志中避免保存密钥和敏感正文。
- 低速发送少量请求，对比直连与中转表现，排除中转侧队列或渠道限制。
- 逐步增加并发，观察延迟、成功率和 Token 吞吐，避免直接高压测试。
- 核对项目配额、账户余额及中转规则，区分短时限流、配额耗尽和余额不足。
重试必须有上限，并使用指数退避与随机抖动。若响应提供重试等待提示，应按其处理；持续重发可能放大拥塞。超时也不代表上游未执行，重复提交可能增加消耗，需结合请求状态判断。
如何控制 Token 消耗与预算？
预算估算应拆分输入、输出以及适用的其他计费项，再按当前实际单价计算。不要用并发数直接推算账单：相同并发下，长上下文与长回答可能带来更高消耗。失败请求是否计费、缓存如何结算，应分别核对上游说明与中转账单规则。
先限制单次任务成本，再限制整体支出。可裁剪重复上下文，按任务设置合理输出上限，将简单任务分流至经验证满足要求的模型。网关侧设置用户级、项目级预算告警与可执行的支出阈值；请求前做估算，完成后按实际用量校正，并为在途请求预留预算余量。
选择 API 中转时，要核对哪些能力？
评估 Gemini API 中转服务，不应只看 Token 报价。还需确认是否展示上游错误、是否区分账户与渠道限流、是否提供用量明细，以及超时和重试是否可控。若接口采用兼容格式，也应实测所需参数与流式响应，不能把格式兼容等同于全部能力一致。
在 openmagic.ai 规划接入时，可先用真实业务样本建立低并发基线，再配置队列、速率控制与预算阈值。以成功率、尾部延迟和单位成功任务成本共同评估，通常比单纯追求更高并发更有利于稳定运行。