查 Gemini API 速率限制时，先别问“Gemini 每分钟到底能请求多少次”。更有用的问题是：哪个入口、哪个项目、哪个模型、哪一项计数、哪个重置窗口正在限制这次请求？ 同一个固定数字无法同时回答 Gemini Developer API、Gemini 应用、Firebase AI Logic 和 Vertex AI。
对 Developer API，真正适用于你的值在 Google AI Studio 的速率限制页面里，而且必须看准确的 Google Cloud 项目与模型行。把下面五项先记下来，才能判断自己碰到了什么：
- 使用入口：Developer API、Gemini 应用、Firebase AI Logic，还是 Vertex AI；
- 归属对象：Google Cloud 项目、消费账号或 Firebase 项目；
- 准确模型或功能：不要只写“Flash”或“Pro”；
- 限制项或处理通道：RPM、输入 TPM、RPD、IPM、TPD、支出窗口、Priority 或 Batch；
- 重置方式或现场证据：分钟窗口、太平洋时间午夜、滚动窗口、响应头或控制台状态。
| 你实际使用的入口 | 去哪里看当前证据 | 第一动作 |
|---|---|---|
| Gemini Developer API | AI Studio 中准确项目与模型的速率限制行 | 找出先耗尽的是 RPM、输入 TPM、RPD、支出、Priority 还是 Batch |
| Gemini 应用 | 应用内的“设置 → 使用限额” | 看当前功能限额和页面显示的恢复时间 |
| Firebase AI Logic | Firebase 的每用户设置，加上上游模型提供方配额 | 两层都查，较低的一层先限制请求 |
| Vertex AI | Google Cloud 的共享容量或 Provisioned Throughput 页面 | 把共享容量竞争和固定项目配额分开处理 |
停止线：不要先轮换 API Key，也不要让程序无限重试。429 RESOURCE_EXHAUSTED 应该先查配额、频率、每日计数或支出准入；503 UNAVAILABLE 应该先查临时过载与服务容量。两个状态都可能短暂恢复，但证据和长期修复不是一回事。
当前项目行才是答案，不是网上复制的模型表
Gemini API 官方速率限制文档负责解释规则，AI Studio负责显示某个项目、模型和层级当前适用的值。公开网页里的静态表格最多能帮助理解术语，不能替代已经登录的项目页面。
原因并不复杂：两个开发者可能使用同名模型，但项目层级、计费账号状态、模型是否预览、账号信誉、所在处理通道和当前可用容量不同。旧文章还可能保留已调整或已经退役的模型行。把旧表当上线预算，会让一次偶然成功的测试变成错误的容量承诺。
Developer API 最常见的三项计数彼此独立：
- RPM（每分钟请求数）计算调用次数。很多短请求可能先碰到 RPM；
- 输入 TPM（每分钟输入 token）计算提示词与上下文。少量超长请求也可能先耗尽它；
- RPD（每日请求数）只在当前项目行列出时适用。当前官方规则下，它在太平洋时间午夜重置。
某些模型或功能还会列出 IPM（每分钟图片数）或 TPD（每日 token）。只要任一适用维度先达到上限，请求就可能被拒绝。预览或实验模型通常更严格，所以事故记录里要抄准确模型 ID，不能只写模型家族。
配额按项目共享，不按 Key 单独发放
Google 当前文档明确说明，Developer API 的速率限制按 Google Cloud 项目生效，不是按 API Key 生效。同一项目创建两个 Key，只是多了两个凭据，RPM、TPM 和 RPD 仍从同一个池里扣。
因此，轮换 Key 适合凭据轮换、权限隔离或服务拆分，不适合“增加配额”。用多个项目规避限制也不是正常扩容方法；只有当项目确实代表不同环境、账单、安全边界或组织归属时，才应该分项目，并且要记录路由、成本和故障隔离规则。
如果你看到的是 AI Studio 聊天界面的具体提示，而不是代码返回的 API 状态，请走更窄的 Google AI Studio 速率限制恢复指南。界面冷却和 API 项目配额不能靠同一条结论处理。
付费层级和支出条件会变化
截至 2026 年 7 月 15 日，Google 公共页面列出的资格条件如下。这些条件只代表该日期的状态，不是永久承诺：
| 层级 | 当前公共资格条件 | 仍要在账号中确认什么 |
|---|---|---|
| Free | 有效项目或免费试用状态 | 当前项目开放哪些模型以及实际行值 |
| Tier 1 | 关联有效的结算账号 | 结算生效后项目显示的层级与模型行 |
| Tier 2 | 已支付至少 100 美元，且距离首次成功付款至少 3 天 | 账号状态与 Google 实际显示层级 |
| Tier 3 | 已支付至少 1,000 美元，且距离首次成功付款至少 30 天 | 账号状态与 Google 实际显示层级 |
同一页面当前还描述了按滚动 10 分钟评估的支出限制：Tier 1 为 10 美元，Tier 2 与 Tier 3 为 200 美元。上线或压测前应重新查官方页面和当前项目，因为金额、资格和适用范围都可能调整。
绑定结算账号只会改变层级资格，不会消灭所有限制。付费项目仍可能耗尽 RPM、输入 TPM、RPD、支出窗口、Batch 或其他准入条件。某个模型是否仍可免费用，属于 Gemini API 免费层指南 的问题，不要在这里凭一张旧配额表推断。
压测前先拆开时间窗口和处理通道
一分钟内没有超限，不代表全天或支出窗口也安全。Standard、Priority 和 Batch 也不是同一份额度的三个名字，而是需要分别观察的处理方式。
| 计数或通道 | 它控制什么 | 现场应保存的证据 | 常见误判 |
|---|---|---|---|
| RPM | 每分钟在线调用次数 | 请求时间分布和当前 RPM 行 | 只看平均 RPS，忽略瞬时突发 |
| 输入 TPM | 每分钟输入 token | 输入长度分位数，而非只看请求数 | 假设所有请求大小一样 |
| RPD | 有该限制时的每日请求数 | 当前 RPD 行与太平洋时间重置点 | 以为退避几秒能修复每日上限 |
| 支出窗口 | 指定滚动窗口内的支出准入 | 计费层级和当前官方规则 | 把它误当成月度预算 |
| Priority | 独立的优先处理限制 | 请求的 service tier 和返回的 x-gemini-service-tier | 认为 Priority 是无限额外容量 |
| Batch | 独立的异步配额池 | 并发任务、文件大小和排队 token | 把紧急交互请求塞进 Batch |
Priority inference 文档当前把默认 Priority 限制设为对应 Standard 模型与层级限制的 0.3 倍。当 Priority 容量耗尽时，请求可能转为 Standard 处理，而不是直接失败。如果延迟或价格依赖通道，就要记录返回的 x-gemini-service-tier，不能只记录请求时想要的通道。
Batch 适合非紧急任务，因为它与在线调用使用分开的配额池。截至 2026 年 7 月 15 日，Batch API 文档列出 100 个并发批处理请求、单个输入文件 2 GB、文件存储合计 20 GB，以及随模型与层级变化的排队 token 上限。这些数字同样要按日期复核。
一份可用的压测记录不应只写目标 RPS。至少还要有准确模型与项目、输入 token 的 p50/p95、突发倍数、请求通道、p95 延迟、每日总量、支出风险、重试比例，以及任务是否允许异步。
把当前配额换算成可运行的容量
找到当前项目行后，先计算每分钟哪个上限更早触发：
请求上限 = min（当前 RPM，当前输入 TPM ÷ 每次请求的平均输入 token）
这个结果只是计算起点，不是生产目标。输入大小会波动，流量会突发，失败重试会放大请求，服务容量也可能低于页面显示的上限。安全余量应根据真实波动和业务风险决定，Google 没有给所有应用统一的余量百分比。
一个带假设的计算例子
假设当前项目行显示 60 RPM 和 120,000 输入 TPM，而监控中每次请求平均输入 4,000 token：
- RPM 允许 60 次/分钟；
- 输入 TPM 允许 120,000 ÷ 4,000 = 30 次/分钟；
- 较小的数字先限制，所以预留余量前的上限是 30 次/分钟；
- 如果团队在这个示例里自行选择 20% 余量，初始运行目标为 24 次/分钟，即 0.4 RPS；
- 若实测 p95 延迟为 2 秒，稳态并发估算为 0.4 × 2 = 0.8，可以先从并发 1 开始，再观察队列、突发和重试。
这里的 20% 是演示用工程假设，不是 Google 建议。流量尖峰明显的消费产品可能需要更多余量；输入大小稳定、可排队的离线任务可能需要不同的余量。
还不能到此为止。24 次/分钟如果全天不停运行，理论上会尝试 34,560 次/日。要再与当前 RPD 行比较，并单独检查支出窗口。分钟预算能跑通十分钟，不代表能连续跑 24 小时。
输入大小变化明显时，不要只用平均数。至少同时看平均值、p95 和最大允许输入：
| 观察值 | 它帮助发现什么 |
|---|---|
| 平均输入 token | 稳态容量的初步估算 |
| p95 输入 token | 正常峰值是否先耗尽 TPM |
| 最大允许输入 | 单类超长请求是否能吃掉整分钟预算 |
| p95 延迟 | 把安全 RPS 换算成初始并发上限 |
| 重试率 | 部分失败期间的流量放大 |
| 缓存命中率 | 稳定重复上下文能否移出热路径 |
模型、提示词模板、上下文长度、工具调用、流量构成、层级或处理通道变化后，都要重算。容量规划是一组持续测量，不是一次除法。
收到 429 时先找耗尽项，再决定是否重试
官方故障排查页对 429 RESOURCE_EXHAUSTED 和 503 UNAVAILABLE 给出不同含义。两者都可能暂时恢复，也都可能允许带随机抖动的指数退避，但不能因此把它们当成同一种故障。
| 返回状态 | 第一判断 | 应查看的证据 | 合适动作 | 停止条件 |
|---|---|---|---|---|
429 RESOURCE_EXHAUSTED | 配额、频率、每日计数、支出或其他准入限制 | 完整错误体、响应头、Retry-After、项目/模型行和近期用量 | 排队、降速、缩短输入、等正确窗口或走官方配额路径 | 未知道耗尽维度与重置方式前，停止盲重试 |
503 UNAVAILABLE | 临时过载、容量或服务不可用 | 请求 ID、时间、端点或区域、模型和服务状态 | 有上限的退避、平滑流量、受支持的全局路由，再携证据升级 | 超过重试预算或影响持续时停止 |
分钟突发造成的 429 可能随窗口移动而解除；RPD 耗尽不会因为每几秒再试而恢复；支出窗口需要等正确滚动窗口或处理计费条件。持续 503 则可能需要查服务状态或容量路线，即使项目配额页面看起来还很健康。
重试策略必须写清边界
生产重试策略至少要定义：
- 哪些状态码允许重试，哪些必须立即停止；
- 操作是否幂等，重复执行会不会产生多次副作用；
- 最大尝试次数和总耗时预算；
- 指数退避与随机抖动；
- 响应给出
Retry-After时如何遵守； - 队列或熔断器如何阻止同步重试风暴；
- 原始调用和重试流量如何分开计数；
- 最终升级包如何记录请求 ID、准确模型、端点、时区时间、响应详情和影响，同时不泄露 Key。
轮换 Key 不能代替这些动作。配额归项目所有，换 Key 通常保留同一个限制，却会让现场更难追踪。也不要用跨项目分流规避限制；合法的多项目架构必须先有真实的账单、安全、环境或组织边界。
修真正卡住的限制，不要只压掉错误提示
最快且安全的动作取决于哪一项先达到上限：
| 卡住的限制 | 短期控制 | 长期设计 | 错误捷径 |
|---|---|---|---|
| RPM | 平滑突发、限制并发、排队 | 按工作负载设置准入与预算 | 同项目多建 Key |
| 输入 TPM | 缩短上下文、删除重复指令、减小单批输入 | 缓存稳定前缀，拆出超长任务 | 只数请求，不量 token |
| RPD | 删除非必要调用，适用时等太平洋时间重置 | 预测每日总量，评估合格层级 | 紧密循环重试 |
| 支出窗口 | 降低准入量并等适用滚动窗口 | 成本告警和成本感知准入 | 认为付费就没有支出限制 |
| Priority | 查看实际返回通道，决定是否接受 Standard 回退 | 只给延迟敏感任务使用并单独监控 | 把 Priority 当通用余量 |
| Batch 排队 token 或任务数 | 错峰提交、拆小任务 | 按当前 Batch 规则构建异步调度 | 把实时交互任务发到 Batch |
| 503 容量 | 有上限退避、平滑流量 | 合适时用全局端点、容量规划或 Provisioned Throughput | 没有配额证据却只追项目上限 |
缓存适合大量重复且稳定的上下文；队列适合允许等待的需求；Batch 适合不要求即时返回的任务。切换模型只有在新模型当前可用、质量满足任务、并且新行确实改善卡点时才有意义。旧配额表里的模型名不是备用方案。
申请更高层级或配额时，最好提供测量结果：当前项目与模型、流量分布、先耗尽的维度、增长预期、已经采用的缓解措施和业务影响。“我们需要更多 RPM”远不如这些证据有用。
不要把 Gemini 应用、Firebase 和 Vertex 的限制互相套用
“Gemini”同时出现在消费应用、Developer API、Firebase 和 Vertex AI 中，但它们的计数对象不同。
Gemini 应用是消费账号的使用限额
Gemini 应用的限制可能跟所选模型、功能、提示复杂度、文件和会话长度有关。截至 2026 年 7 月 15 日，Gemini 应用帮助说明，使用额度每五小时刷新，直到达到周限额；具体值可能随容量调整，当前恢复时间以“设置 → 使用限额”为准。
消费应用限额不会提高 Developer API 项目的 RPM、TPM 或 RPD。Google AI 订阅和带结算的 API 项目解决的是两件事，不要把应用里的提示次数复制到 API 容量表。
Firebase AI Logic 会叠加两层限制
Firebase AI Logic 可以在上游模型配额之前增加每用户网关限制。截至 2026 年 7 月 15 日，Firebase 文档列出的默认每用户限制是 100 RPM，上游 Gemini 项目与模型配额仍然有效。
最终可用上限取较低的一层。如果只有单个用户被挡而项目总体用量正常，先查 Firebase 网关；如果许多用户同时失败且 Gemini 项目行已耗尽，只改网关值不会修复上游限制。
Vertex AI 处理的是容量路径
对 Vertex AI PayGo 上较新的 Gemini 模型，Google Cloud 文档描述的是 Dynamic Shared Quota，不是一个可照搬的预定义项目 RPM。Vertex 返回 429 可能表示共享池竞争，所以流量平滑、适用的全局端点、有上限重试和 Provisioned Throughput 都是 Vertex 特有的容量选项。
不要把 Developer API 的 RPM/RPD 直接贴进 Vertex 计划。如果业务需要可预测的企业吞吐量，应把真实 PayGo 表现与 Provisioned Throughput 比较，而不是把共享容量当成保证值。
图像生成还可能增加 IPM、消费图片次数或 Vertex 图像容量。实际任务属于这些分支时，使用 Gemini 图像生成速率限制指南，不要让广义 API 页面吞掉图像专属问题。
上线前把限制依据写进运行记录
正式放量前，让运行记录能回答以下问题：
- 入口：流量到底走 Developer API、Gemini 应用、Firebase 还是 Vertex AI？
- 归属：哪个项目、结算账号、消费账号或 Firebase 项目负责？
- 模型：请求里的准确模型 ID 和当前状态是什么？
- 限制项：适用的是 RPM、输入 TPM、RPD、IPM、TPD、支出、Batch 还是 Priority？
- 窗口：计数何时重置或滚动，值在哪里复核？
- 流量形态：输入 token 的 p50/p95、p95 延迟、突发倍数、每日总量和重试率是多少？
- 准入控制：队列、并发上限、token 预算和丢弃规则怎样把流量保持在运行目标以内？
- 错误分支：429 与 503 是否分开统计，并各自有重试上限与停止线？
- 通道：Standard、Priority 和 Batch 是否分开观察？
- 升级证据：值班人员能否在不暴露凭据的情况下保存请求 ID、时区时间、模型、项目、响应与影响？
压测要用接近生产的输入长度，而不是只发“hello”。既测突发，也测持续时间；确认重试在监控里会增加流量；告警阈值应设在团队选定的运行目标之前，而不是等到公开上限才响。
真正有用的仪表盘不是一墙模型数字，而是一份小型运行记录：发生故障时，它能说清哪个入口负责、哪一个计数先满、最近什么变化，以及下一步哪种动作安全。
Gemini API 速率限制常见问题
Gemini API 速率限制按 API Key 计算吗？
不是。Developer API 当前按 Google Cloud 项目限制，同一项目的多个 Key 共享配额池。
Gemini API 有每日上限吗？
有些项目与模型行会列 RPD 或 TPD，但不存在所有模型通用的每日数字。RPD 适用时，当前规则在太平洋时间午夜重置，仍应查看准确 AI Studio 行。
为什么付费项目仍然返回 429？
付费会改变层级资格，不会清除 RPM、输入 TPM、RPD、支出窗口、Batch 或其他准入限制。429 是寻找卡点的证据，不等于结算一定失败。
429 后要等多久？
取决于耗尽的窗口。响应有 Retry-After 时先遵守，再结合错误体和当前项目行判断是分钟压力、每日上限还是支出窗口。适合 RPM 的短暂等待不会重置 RPD。
Batch API 的配额独立吗？
是。Batch 与交互请求使用独立配额池，并有并发任务、文件、存储和排队 token 限制。生产调度前要复核最新 Batch 文档。
Gemini 应用订阅会提高 API 配额吗？
不要这样假设。Gemini 应用限额属于消费账号与功能；Developer API 配额属于 Cloud 项目、模型、层级和当前 AI Studio 行。
Vertex AI 的 Gemini 限制和 Developer API 一样吗？
不一样。较新的 Vertex AI PayGo Gemini 流量使用 Dynamic Shared Quota，而 Provisioned Throughput 是购买容量的路线。应使用 Google Cloud 证据排查 Vertex，不要套用 Developer API 表格。
多个 Google Cloud 项目能增加容量吗？
项目可以有独立归属与限制，但只能为了真实的环境、账单、安全或组织边界拆分，不能用来规避配额。多项目架构还要明确路由、数据政策、成本与故障隔离。
向支持团队提交什么信息？
提交使用入口、可安全分享的项目标识、准确模型、端点或区域、带时区时间、请求 ID、完整错误码与详情、当前限制行、近期流量与 token 分布、重试行为和业务影响。绝不要提交 API Key 或其他凭据。
