Gemini API 速率限制 2026：完整开发者指南（含所有层级）

Gemini API 通过四个维度执行速率限制：RPM（每分钟请求数）、TPM（每分钟令牌数）、RPD（每日请求数）和 IPM（每分钟图片数）。截至 2026 年 2 月，免费层用户可获得 5-15 RPM（取决于模型），而 Tier 1 付费用户可获得 150-300 RPM。本指南涵盖所有层级和模型的完整限制、2025 年 12 月配额变更、429 错误处理，以及与 OpenAI 和 Claude API 的对比。

要点速览

在深入细节之前，以下是你现在需要了解的关键信息：

免费版：5-15 RPM，250K TPM，100-1,000 RPD（无需信用卡）

Tier 1(付费)：150-300 RPM，1M TPM，1,500 RPD（启用计费 = 即时升级）

Tier 2：500-1,500 RPM，2M TPM，10,000 RPD（需要 $250 累计消费 + 30 天）

Tier 3(企业)：1,000-4,000+ RPM，自定义限制（需要 $1,000 消费或联系销售）

重要提醒：2025 年 12 月的变更将免费层配额削减了 50-92%。Flash 模型从 250 RPD 降至 20 RPD。

理解 Gemini API 速率限制

速率限制是 Google 对 Gemini API 使用设置的护栏，用于确保公平访问和系统稳定性。与简单的"每天 X 个请求"限制不同，Gemini 使用复杂的四维限制系统，同时测量多个指标的使用情况。

你需要理解的四个维度是 RPM（每分钟请求数）、TPM（每分钟令牌数）、RPD（每日请求数）和 IPM（每分钟图片数）。超过任何单一维度都会触发速率限制，即使其他维度远低于限制。这意味着单个消耗 500K 令牌的大请求可能会耗尽你的 TPM 配额，即使你只发出了 2 个请求。

Google 使用令牌桶算法实现这些限制，允许突发流量同时保持平均速率合规。实际上，这意味着如果你一直低于配额使用，可以短暂超过规定的 RPM，但持续过度使用将迅速触发 429 错误。

一个经常让开发者困惑的关键细节是：速率限制按 Google Cloud 项目应用，而非按 API 密钥。在同一项目中创建多个 API 密钥不会增加配额——所有密钥共享同一个池。如果需要真正独立的配额，你需要单独的项目，每个都有自己的计费账户和层级资格。

RPD（每日请求数）配额在太平洋时间（PT）午夜重置。对于全球应用程序，这意味着你的"一天"可能与用户的预期不一致。欧洲开发者经常在早晨时段达到每日限制，因为重置发生在中欧时间上午 8-9 点左右。

理解这四个维度如何相互作用对于容量规划至关重要。考虑一个文档处理应用程序：你可能每小时处理 10 个大型文档，远低于任何 RPM 限制。但如果每个文档消耗 100K 令牌，你每小时消耗 1M 令牌——可能在较低层级上耗尽 TPM 限制。维度之间的交互意味着你需要针对特定用例建模，而不是假设单一指标决定你的需求。

2025 年 12 月配额变更：发生了什么？

2025 年 12 月 7 日，Google 悄然实施了对 Gemini API 配额的重大变更，让开发者社区措手不及。在没有事先公告、博客文章或电子邮件通知的情况下，免费层限制被削减了 50-92%，具体取决于模型。

最严重的削减影响了 Gemini Flash 用户。免费层 RPD 从每天 250 个请求降至仅 20 个——92% 的削减立即导致依赖之前慷慨配额的生产应用程序崩溃。开发者是在应用程序开始抛出意外的 429 错误时发现这一变化的，而不是从任何官方通信中得知。

社区反应迅速且充满挫败感。在 Google 的 AI 开发者论坛上，一个广泛分享的帖子标题是"他们真的以为我们不会注意到 92% 的免费层配额削减吗？"积累了数百条回复。开发者批评的不是削减本身，而是缺乏透明度——没有提前警告，没有迁移期，最初甚至没有对变更的确认。

Google 的 Logan Kilpatrick 最终回应说，公司需要"为 Gemini 3 需求重新配置计算资源"，但开发者质疑为什么不能主动沟通。这一事件损害了对免费层作为可靠开发环境的信任，许多开发者现在将其视为仅用于测试而非任何生产用途。

2025 年 12 月的变更还影响了图像生成功能。免费层用户完全失去了对某些图像生成功能的访问权限，而其他用户看到他们的 IPM（每分钟图片数）配额大幅削减。构建视觉内容生成应用程序的开发者受到的影响尤为严重，许多人需要立即升级到付费层以维持功能。

对于你的应用程序，教训很明确：永远不要依赖免费层配额用于生产工作负载。即使你当前的使用量在免费限制内，单一政策变更可能在一夜之间破坏你的应用程序。为任何面向客户的功能至少预算 Tier 1。

各层级完整速率限制（2026）

了解每个层级的精确限制对于容量规划至关重要。以下是截至 2026 年 2 月的全面细分，涵盖所有当前模型，包括 Gemini 2.5 Pro、Flash 和 Flash-Lite。

免费层限制

免费层无需信用卡，为测试和原型开发提供真正的访问权限。然而，2025 年 12 月后的变更使其不适合大多数生产场景。

尽管有限制，免费层包括完整的 100 万令牌上下文窗口和多模态支持。250K TPM 限制实际上相当慷慨——足以在每个请求中处理大量文档，只是请求数量不多。

Tier 1（付费）限制

启用 Cloud Billing 会立即将你升级到 Tier 1，容量比免费层多 10-30 倍。这是大多数中小型应用程序的最佳选择。

Tier 1 还解锁上下文缓存（重复提示节省 75% 成本）、批处理（50% 折扣），并保证你的数据不会用于模型训练。启用计费后立即升级——无需审批流程。

Tier 2 限制

Tier 2 针对具有大量使用需求的成长型应用程序。达到此层级需要满足两个条件：$250 的累计 Google Cloud 消费（跨任何服务，不仅仅是 Gemini API）以及首次成功付款后 30 天。

满足两个要求后，升级通常在 24-48 小时内完成。注意，Google Cloud 免费信用额度不计入 $250 门槛——只有对付款方式的实际收费才算数。

Tier 3（企业）限制

Tier 3 为企业应用程序提供最高限制。资格要求 $1,000 累计消费加 30 天，或直接与 Google Cloud 销售团队接洽。

企业销售流程通常需要 2-4 周，包括技术审查、安全评估和合同谈判。限制根据你的具体用例和预计用量协商确定。

在评估需要哪个层级时，不仅要考虑当前使用量，还要考虑增长轨迹和流量模式。客服聊天机器人可能平均每小时 50 个请求，但在产品发布或事故期间飙升至 500 个。了解你的峰值需求可确保你不会在关键时期不断遭遇速率限制。

如何升级 API 层级

在层级之间移动涉及不同的流程和时间表。以下是每种转换的具体操作步骤。

免费到 Tier 1：即时升级

这是最简单的升级。导航到 Google Cloud Console，选择你的项目，进入计费，并使用有效的付款方式启用 Cloud Billing。你的项目立即获得 Tier 1 配额——无需等待期，无需审批流程。你可以在 AI Studio 使用页面验证升级。

Tier 1 到 Tier 2：$250 + 30 天

必须同时满足两个要求。首先，在计费账户上累计 $250 的 Google Cloud 服务总消费（不仅仅是 Gemini API）。其次，自首次成功付款以来保持活跃计费账户至少 30 天。满足两个条件后，升级通常在 24-48 小时内处理。如果需要更快达到 Tier 2，可以加速其他 Google Cloud 服务（如 Compute Engine 或 Cloud Storage）的消费。

Tier 2 到 Tier 3：$1,000 或销售接洽

你有两条路径。消费路径需要 $1,000 累计消费加 30 天——与 Tier 1 到 Tier 2 相同的机制。或者，你可以直接联系 Google Cloud 销售进行自定义企业安排。如果需要超出标准 Tier 3 产品的限制或需要特定 SLA，建议使用销售路径。

层级选择的战略考虑

在规划层级策略时，考虑这些超出原始配额数字的因素。Tier 1 解锁上下文缓存，对于具有重复提示或稳定系统指令的应用程序，可将成本降低高达 75%。如果你的应用程序经常发送相似的上下文，上下文缓存带来的成本节省可能抵消计费要求。

对于无法等待层级升级的即时高容量需求应用程序，考虑使用 API 聚合服务如 laozhang.ai，它提供对多个 AI API 的统一访问，具有不同的计费和速率限制结构。

像专业人士一样处理 429 错误

当你超过任何速率限制维度时，Gemini API 返回 429 状态码（RESOURCE_EXHAUSTED）。如何处理这些错误决定了你的应用程序是优雅恢复还是级联失败。

黄金标准方法是带抖动的指数退避。这种策略自动以逐渐延长的等待时间重试失败的请求，同时添加随机化以防止"惊群"问题——多个客户端同时重试。

以下是生产就绪的 Python 实现：

python
import time
import random
import logging
from typing import Callable, Any, Optional

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

class GeminiRateLimitHandler:
    def __init__(
        self,
        max_retries: int = 5,
        base_delay: float = 1.0,
        max_delay: float = 60.0
    ):
        self.max_retries = max_retries
        self.base_delay = base_delay
        self.max_delay = max_delay

    def call_with_retry(
        self,
        api_call: Callable,
        fallback: Optional[Callable] = None
    ) -> Any:
        """
        使用指数退避重试逻辑执行 API 调用。
        """
        for attempt in range(self.max_retries):
            try:
                response = api_call()
                logger.info(f"请求在第 {attempt + 1} 次尝试成功")
                return response

            except RateLimitError as e:
                if attempt == self.max_retries - 1:
                    logger.error(f"所有 {self.max_retries} 次重试已耗尽")
                    if fallback:
                        logger.info("执行备用策略")
                        return fallback()
                    raise

                # 检查 Retry-After 头
                retry_after = getattr(e, 'retry_after', None)
                if retry_after:
                    wait_time = float(retry_after)
                else:
                    # 带抖动的指数退避
                    wait_time = min(
                        self.base_delay * (2 ** attempt) + random.uniform(0, 1),
                        self.max_delay
                    )

                logger.warning(
                    f"第 {attempt + 1} 次尝试受限。"
                    f"等待 {wait_time:.2f} 秒后重试"
                )
                time.sleep(wait_time)

        return None

使其生产就绪的关键元素包括用于监控和调试的全面日志记录、对 API 提供的 Retry-After 头的支持、防止过长等待的最大延迟上限，以及用于优雅降级的备用机制。

在实现备用策略时，考虑模型切换（Pro 超限时切换到 Flash）、API 聚合服务实现无缝故障转移、请求排队以供稍后处理，以及在新鲜度不重要时提供缓存响应。

除了基本重试逻辑，生产应用程序应实现熔断器模式。当收到多个连续的 429 错误时，继续重试会浪费资源并延迟恢复。熔断器在达到失败阈值后"打开"，在冷却期内立即拒绝请求，然后谨慎测试服务是否已恢复。

Gemini vs OpenAI vs Claude：速率限制对比

在 AI API 之间做选择需要了解各提供商的速率限制对比。以下是截至 2026 年 2 月 Gemini 与 OpenAI 和 Anthropic Claude 的对比。

RPM(每分钟请求数)对比

OpenAI 在原始请求吞吐量方面领先，Tier 1 提供 500-10,000 RPM，而 Gemini 为 150-300 RPM。Claude 采取更保守的方法，为 50-100 RPM，反映了他们对质量而非数量的关注。

对于需要许多小请求的应用程序（聊天机器人、实时助手），OpenAI 更高的 RPM 可能更有优势。然而，如果你的用例涉及更少但更大的请求，这种差异就不那么重要了。

TPM(每分钟令牌数)对比

Gemini 在这里占主导地位，Tier 1 拥有 1,000,000 TPM——是 OpenAI 200,000 TPM 的五倍，是 Claude 80,000 TPM 的十二倍。这使得 Gemini 成为文档处理、代码分析和其他需要大型上下文的用例的明确选择。

免费层对比

Gemini 提供最慷慨的免费层——无需信用卡即可真正使用。OpenAI 从一开始就需要付款。Claude 提供 $5 初始信用额度但需要卡注册。

定价对比(每百万令牌)

Gemini 在所有层级中一致提供最低定价。对于成本敏感型应用程序，这可以在规模上转化为显著节省。

对于需要跨所有三个 API 灵活性的开发者，像 laozhang.ai 这样的服务通过单一接口提供统一访问，允许你将请求路由到最适合每个特定用例的 API，同时集中管理速率限制。如果你也在评估 OpenAI 的消费产品，可以了解更多关于 ChatGPT Plus 使用限制的信息。

最大化免费层使用

即使在 2025 年 12 月配额削减后，战略性使用免费层仍然可以支持大量开发和轻度生产工作负载。以下是如何从配额中榨取最大价值。

智能模型选择策略

并非所有请求都需要最强大的模型。根据任务复杂度实现智能路由。将 Flash-Lite（15 RPM，1,000 RPD）用于分类、摘要和格式转换等简单任务。将 Flash（10 RPM，250 RPD）保留用于标准对话和推理任务。将 Pro（5 RPM，100 RPD）留给复杂分析、创意写作和需要最大能力的任务。

请求批处理优化

将相关操作合并到单个请求中。不是进行五次单独的摘要调用，而是在一个请求中传递所有五个文档并适当提示。这减少了 RPM 消耗，同时保持在 TPM 限制内。

有效的批处理需要周到的提示设计。用清晰的分隔符和编号构建批处理请求，以便模型可以提供结构化、可分离的响应。

实施积极缓存

为相同或相似的查询缓存响应。对于有重复问题的应用程序（FAQ 机器人、文档助手），40-60% 的缓存命中率是可以实现的。这直接成倍增加你的有效配额。

实施语义缓存以获得更大的效果。使用嵌入来识别语义相似的查询，并在相似度超过阈值时提供缓存响应，而不是要求精确的查询匹配。

有关使用 Gemini 免费层的更详细策略，请查看我们的 Gemini API 免费层完整指南，其中涵盖了额外的优化技术和最佳实践。

常见问题与关键要点

真的有不需要信用卡的免费层吗？

是的。Google AI Studio 提供无需输入付款信息即可真正免费访问 Gemini API。你可以立即访问所有当前模型，享受上述免费层限制。这使 Gemini 与 OpenAI（需要付款）和 Claude（需要信用卡获取信用额度）区分开来。

每日限制(RPD)何时重置？

RPD 配额在太平洋时间（PT/PST）午夜重置。供参考：这是 GMT 上午 8:00，CET 上午 9:00，JST 下午 5:00。如果你有全球用户，请相应规划每日配额使用。

可以在不升级层级的情况下增加限制吗？

可以，你可以通过 Google Cloud Console 请求配额增加。导航到 IAM & Admin → Quotas，选择需要增加的特定配额，并提交带有理由的请求。批准不能保证，通常需要 2-5 个工作日。

Gemini 2.0 Flash 模型会发生什么？

Gemini 2.0 Flash 和 Flash-Lite 模型将于 2026 年 3 月 3 日退役。使用这些模型的应用程序必须在此日期之前迁移到 Gemini 2.5 Flash 或 Flash-Lite。迁移主要涉及更新 API 调用中的模型名称——输出格式和功能在很大程度上兼容。

多个 API 密钥会获得单独的配额吗？

不会。同一 Google Cloud 项目中的所有 API 密钥共享同一配额池。创建额外的密钥不会增加你的限制。要获得真正独立的配额，你需要具有自己计费账户的单独项目。

关键要点

理解 Gemini API 速率限制对于构建可靠应用程序至关重要。记住这些核心原则：限制按项目（而非按密钥）应用，四个维度（RPM、TPM、RPD、IPM）独立跟踪，2025 年 12 月大幅削减了免费层，通过启用计费可立即访问 Tier 1。

对于生产应用程序，始终实现带抖动的指数退避，至少规划 Tier 1 容量，并考虑 API 聚合服务以获得额外的灵活性。免费层仍然对开发和测试有价值，但生产工作负载应该预算付费层。

随着规模扩大，主动监控使用情况并在达到限制之前规划层级升级。通过适当的规划和实施，你可以构建能够优雅处理速率限制同时为用户提供一致性能的强大应用程序。