接入 Gemini API 时，请求变慢、排队或出现 429，不一定是并发连接过多。请求频率、Token 吞吐、项目配额和中转网关限制，都可能影响调用。企业采购 API 中转或 Token 额度时，应把并发、吞吐与预算分开核算，避免余额充足却无法稳定调用。
Gemini API 并发限制：先确认限制在哪一层
并发表示同一时刻正在处理的请求数量，RPM 表示每分钟请求数，TPM 表示每分钟 Token 吞吐，三者不能互相替代。长文本或长输出会延长请求占用时间，即使请求频率不高，也可能积累大量在途任务。
具体限制应以当前模型、项目及账户对应的官方控制台和文档为准，不宜套用统一数字。经 API 中转调用时，还要确认网关是否设置了独立的每密钥并发、用户限流或队列长度；增加中转余额并不等于提升上游配额。
- 上游层：核查模型对应的请求与 Token 配额，以及适用的统计范围。
- 网关层：核查并发上限、排队超时和共享资源规则。
- 应用层：核查连接池、任务队列、请求超时与自动重试配置。
Token 消耗如何转化为预算
成本评估不能只看调用次数。输入上下文、历史消息、输出长度以及工具调用产生的后续请求，都可能增加消耗。长会话若每轮重复发送全部历史，输入 Token 会持续增长，应按业务需要压缩上下文。
可用“预计请求数 × 单次平均输入及输出消耗”估算用量，再按所选模型当前适用的计费规则换算金额。输入、输出及其他计费项目应分别核算；中转采购则需确认模型映射、扣费单位和账单明细。不要把套餐标称 Token 数直接视为所有模型通用的实际消耗。
预算控制宜设置单次输出上限、用户日预算和项目月预算。接近阈值时先告警，再限制低优先级任务；余额不足时明确返回错误，避免任务不断重试。超时与取消后的计费结果应对照账单核验，不能默认客户端未收到响应就没有费用。
遇到 429，怎样兼顾稳定性与成本
遇到 429 时，应记录错误体、模型名、请求时间和请求标识，判断是频率、Token 配额还是网关限流。若响应包含重试提示，应优先遵循；否则采用带随机抖动的指数退避，并设置最大重试次数与总等待时间。
不要用无限重试对抗限流。持续重发会放大拥堵；对已经生成部分内容或处理状态不明的请求，还可能造成重复执行与额外消耗。建议通过有界队列平滑突发流量，并按交互请求、批处理任务分配优先级。
采购中转额度前，先做可观测压测
测试时逐步增加并发，同时记录成功率、429 比例、首字响应时间、总耗时、Token 用量和账单变化。流式响应可以改善等待体验，但不能视为绕过配额或降低 Token 成本的方法。
在 openmagic.ai 规划 Gemini API 接入时，应先明确模型、峰值请求量、平均上下文及输出长度，再核对可提供的网关限制与计费口径。以小流量验证单位成功请求成本与稳定吞吐后再扩大采购，比单纯追求更高并发更有利于控制预算。