接入 Gemini API 时，业务请求一多就出现排队、429 或费用波动，不一定是“并发数不够”。请求频率、Token 吞吐、账户配额与中转网关队列，都可能成为瓶颈。对批量生成、客服和长文分析业务，应把并发限制、Token 消耗与预算控制放在同一套监控中，而不是只增加重试次数。
先分清并发、速率与 Token 配额
并发是同一时刻未完成的请求数，RPM 是每分钟请求数，TPM 则关注每分钟处理的 Token。即使并发不高，单次输入很长也可能触及吞吐约束；短请求过于密集，也可能先碰到请求速率限制。具体限制应以对应模型、项目和账户实际展示的信息为准，不存在适用于所有 Gemini API 接入方式的固定并发值。
通过 API 中转接入时，还要区分上游配额与网关限制：入口允许接收请求，不代表上游可以立即处理。网关可能设置连接数、队列长度、租户限速和超时，这些参数不能直接等同于 Gemini 官方配额。
出现 429 或超时，按什么顺序排查？
- 记录模型名称、请求时间、状态码、错误正文与请求标识，确认错误由上游还是网关返回。
- 查看同一时间窗口内的请求数、输入输出 Token、在途请求数与队列等待时间，判断瓶颈所在。
- 使用短输入、较低输出上限做小规模测试，再逐步增加负载，不要直接全量压测。
- 核对项目配额、余额及网关规则；余额不足和限流不是同一问题，应按实际错误信息处理。
429 通常与限流或配额相关，但不能仅凭状态码判断是哪一层限制；超时也可能来自网络、排队或生成耗时。先定位限制来源，再调整并发，比盲目换模型或反复重发更有效。
用 Token 预算反推安全并发
容量规划应先统计真实业务的平均输入、输出 Token，以及高分位请求耗时。在稳定流量下，可用“目标每秒请求数×平均响应秒数”估算平均在途请求数，再结合突发流量和配额余量设置并发上限。这个估算不能替代实际压测，也不能绕过 RPM、TPM 等约束。
成本预算则应分别计算输入与输出用量，按当前适用计费规则估算，并计入重试、重复提交及其他适用费用。长对话应减少无关历史，批处理应拆分任务，并合理限制最大输出长度。缩短输出可能降低消耗，但也要检查截断是否影响结果可用性。
中转接入如何兼顾稳定性与费用？
网关侧建议组合使用租户限速、有界队列和并发信号量：限速控制请求进入节奏，队列吸收短时突发，并发上限保护处理资源。遇到可重试错误时采用指数退避加随机抖动；若响应包含有效的重试等待提示，应优先遵循，并设置最大次数与总时限，避免重试放大流量。
预算管理应设置日或月用量预警，并为不同业务配置独立额度或内部成本标签。达到内部阈值后，可暂停低优先级批任务，或在效果验证后使用成本更合适的模型。客户端超时不代表上游没有执行，重复提交前应评估重复生成和潜在计费风险。
为 openmagic.ai 等 API 中转接入方案做评估时，应核对计费口径、用量明细、错误透传、排队超时与租户隔离能力。可观测、可限流、可核账比笼统的“高并发”描述更有采购参考价值；上线前用业务样本验证成本与成功率，再逐步放量。