速率限制用于控制你在指定时间范围内可以向 Gemini API 发出的请求数。Google 官方技术文档给出的解释是：这些限制有助于维持公平使用，防范滥用行为，并帮助所有用户维持系统性能。但真正值得开发者注意的，是这套规则的计算方式——它按项目应用，而不是按 API 密钥应用。

这意味着什么？如果你在一个项目下生成了多把密钥分发给不同服务，它们共享同一份配额。任何一把密钥打满，整个项目一起触发错误。

打开网易新闻 查看精彩图片

三个维度，任意一项超限都会报错

Gemini API 的速率限制并非单一指标，而是从三个维度同时监控：每分钟请求数（RPM）、每分钟 token 数（TPM）、每日请求数（RPD）。超出任意一项，都会触发错误。

其中 RPD 配额会在太平洋时间午夜重置。这个细节对跨时区团队尤其重要——如果你的业务高峰落在太平洋时间的下午，重置节点可能正好卡在流量爬升期。

除了调用量，平台还引入了基于支出的速率限制。系统根据 10 分钟滚动窗口对付费层级设置支出上限，第 1、2、3 层级分别为 10、50、200 美元。超限将触发 429 RESOURCE_EXHAUSTED 错误。这条规则的设计意图很直接：防止意外扣费。

层级晋升不看申请，看账单

用户无需手动申请提额。系统根据项目在 Google Cloud 上的累计支出与账号时长，自动从免费层级晋级至第 1 至第 3 层级，对应更高的调用配额与批量处理容量。

门槛是硬性的。以第 2 级为例，需要累计支付 100 美元且满足首次付款满 3 天的要求，系统才会自动升级。支出和天数两个条件缺一不可。

这套机制把配额和真金白银绑在一起。对开发者来说，它意味着扩容路径是可预期的——花多少钱、等多少天，对应什么配额，规则写在明面上。

Batch API 走独立配额体系

批量处理不占用常规调用的额度池。Batch API 单独限制并发数（100）、文件大小（2GB）以及各模型的排队 Token 上限。优先级推理则默认限制为标准速率的 0.3 倍。

把批量任务和实时调用分开计量，避免了大文件批处理挤占在线请求的资源。如果你的业务同时有离线批处理和在线推理，这两套配额需要分别规划。

文档同时明确了人工申请提额的流程。自动晋级覆盖不到的场景，仍然可以走人工通道。

对正在做容量规划的团队，这套规则的核心提醒只有一条：先确认你的配额是按项目算的，再决定密钥怎么分发。