← 返回 Blog
UseAIAPIAI API3min

撞了三天429 Quota Exceeded后我把Gemini Free Tier拆明白了：RPM/TPM/RPD三把锁，你到底被哪把卡住？附队列化模板

在 AI 开发实践中，不少开发者都曾遭遇过令人头疼的 429 资源耗尽错误。近日，笔者运行学术论文摘要爬取脚本时，仅不到二十分钟就遇到了连续的 429 RESOURCE_EXHAUSTED 报错。在接下来的三天里，笔者查阅了 Google AI Studio 设置页面和开发者论坛中所有相关技术帖，甚至一度怀疑 IP 被列入黑名单，直到彻底厘清 Gemini API 免费层的三重限流机制，问题才迎刃而解。

GeminiGemini APIGemini Free Tier

连挂三天 429 Quota Exhausted 以后，我把 Gemini Free Tier 的「三把锁」拆透了：RPM/TPM/RPD，你到底是卡在哪一关？附可用队列模板

在 AI 开发实践中，不少开发者都曾遭遇过令人头疼的 429 资源耗尽错误。近日，笔者运行学术论文摘要爬取脚本时，仅不到二十分钟就遇到了连续的 429 RESOURCE_EXHAUSTED 报错。在接下来的三天里，笔者查阅了 Google AI Studio 设置页面和开发者论坛中所有相关技术帖，甚至一度怀疑 IP 被列入黑名单，直到彻底厘清 Gemini API 免费层的三重限流机制，问题才迎刃而解。

Gemini API 免费层：不是 "无限自助餐"，而是三重独立硬上限

很多开发者误以为 Gemini API 免费层是简单的 "总请求数一刀切"，实际上它的调用限制由三把彼此独立的 "锁" 共同控制，任何一把锁触发都会返回 429 错误。

表格

缩写全称核心含义易触发原因
RPMRequests Per Minute每分钟请求数上限脚本并发控制不当，短时间内发送大量请求
TPMTokens Per Minute每分钟 Token 消耗上限单次请求包含长上下文或大段文本，即使请求数少也会超标
RPDRequests Per Day每日总请求数上限单日累计请求量达到阈值，最隐蔽且影响时间最长

需要特别注意的是，Gemini API 的速率限制是按 Google Cloud 项目生效，而非单个 API 密钥；同时，每日请求数（RPD）的重置时间为美国太平洋时间午夜。换算为北京时间，夏令时（PDT）约为每日 15:00，冬令时（PST）约为每日 16:00，具体时间可在 AI Studio 账号面板的 "下次重置时间" 中精确查看。

第一把锁：RPM—— 最易触发的瞬时并发限制

根据官方公布及全球开发者实测数据，Gemini API 免费层各模型的 RPM 限制大致为：

  • Gemini 2.5 Pro：约 5 次 / 分钟
  • Gemini 2.5 Flash：约 10 次 / 分钟
  • Gemini 2.5 Flash-Lite：约 15 次 / 分钟

这意味着，如果在脚本中使用简单的 for 循环，10 秒内连续发送 6 次请求，就会立即触发 RPM 限制返回 429 错误，与当日累计请求量完全无关。

第二把锁：TPM—— 长上下文的 "隐形杀手"

很多开发者会有这样的疑惑："我今天才发了几条请求，怎么就被限流了？" 问题往往不在于请求的 "数量"，而在于请求的 "体量"。

免费层的 TPM 限制通常在 250,000 tokens / 分钟左右（不同模型和版本可能有所调整）。由于 Gemini 支持最高 1M tokens 的超大上下文窗口，一旦将几十页论文、完整财报或超长对话历史一次性传入请求，单次请求就可能消耗几十万 tokens，导致 TPM 先于 RPM 触发限流。

这种情况的典型表现是：请求频率并不高，但在处理大体积内容时会集中出现 429 错误。

第三把锁：RPD—— 最隐蔽的每日总量陷阱

RPD 是每日总请求数的上限，各模型对应的大致限额为：

  • Gemini 2.5 Pro：约 100 次 / 天
  • Gemini 2.5 Flash：约 250 次 / 天（不同时期和地区可能有所浮动）
  • Gemini 2.5 Flash-Lite：约 1000 次 / 天

系统会同时监测 RPM、TPM 和 RPD 三项指标，任何一项超标都会返回 429 错误。一旦当日 RPD 额度耗尽，在太平洋时间午夜重置前，该项目将无法再发起任何 API 请求。

笔者的学术论文爬取脚本正是栽在了这把锁上：使用 Gemini 2.5 Pro 模型，仅跑了四五批次数据就耗尽了 100 次 / 天的限额，上一秒还在正常返回结果，下一秒就全线报错，且当天无法恢复。

快速诊断：你被哪把锁卡住了？

通过以下典型症状，可以快速定位当前触发的限流机制：

表格

典型症状大概率触发的限流机制
脚本运行几分钟内就密集出现 429 错误，当日累计请求量很少RPM：瞬时并发过高，未设置合理的请求间隔
运行中途开始频繁报错，且在处理长文档或大上下文时更为明显TPM：单次请求体量过大，或总 Token 吞吐量超标
前期运行正常，某个时刻突然全线 429，短时间等待后仍无法恢复RPD：每日请求额度耗尽，需等待太平洋时间午夜重置

对症下药：三招提升免费层有效利用率

方案一：指数退避 + 随机抖动重试机制

遇到 429 错误时，盲目重试只会加剧限流问题。正确的做法是采用指数退避算法，失败后逐步拉长等待时间，并加入随机抖动避免多个线程同时恢复导致的 "雷群效应"。

以下是一段可直接使用的 Python 风格伪代码，可轻松集成到现有脚本中：

python

运行

import time, random, math

def call_with_backoff(fn, max_retries=6, base_delay=1.0):
    """
    fn(): 你的 generate_content / POST 调用封装
    返回 (result, None) 或 (None, err_reason)
    """
    for attempt in range(max_retries):
        try:
            return fn(), None
        except Exception as e:
            if is_rate_limit_error(e):          # 你按实际 SDK 判断 429 / RESOURCE_EXHAUSTED
                if attempt == max_retries - 1:
                    raise
                delay = base_delay * (2 ** attempt) + random.uniform(0, 1.0)
                print(f"[rate-limit] 429 hit, backoff {delay:.2f}s (attempt {attempt+1}/{max_retries})")
                time.sleep(delay)
            else:
                raise  # 非 429 的错不该被吞掉
    return None, "exhausted retries"

封装好重试逻辑后，大多数因 "节奏不对" 导致的 429 错误都能得到解决，脚本的有效运行率通常可从 30% 提升至 95% 以上。

方案二：合理选型模型，采用分层路由策略

免费层的额度有限，不应将所有请求都交给性能最强但额度最紧张的 Gemini 2.5 Pro 处理。根据任务难度选择合适的模型，能大幅提升单日总处理量：

  • Gemini 2.5 Flash-Lite：适用于简单分类、摘要生成、文本改写、模板填充等轻量任务，可充分利用其 15 RPM+1000 RPD 的高额度
  • Gemini 2.5 Flash：作为主力模型，处理日常对话、通用生成、中等复杂度代码编写等任务
  • Gemini 2.5 Pro：仅用于需要深度推理、长上下文分析、关键代码生成等高价值请求

通过 "Lite/Flash 扛量 + Pro 精准补刀" 的分层策略，同样的每日总额度能完成的工作量往往能提升数倍。

方案三：实现请求队列与滑动窗口限速

为了从根本上避免触发瞬时限流，建议实现一个令牌桶或滑动窗口限速器，将请求速率严格控制在 RPM 限制的安全范围内。

以下是一个基于 asyncio 的 RateLimiter 类实现，可直接复制使用：

python

运行

import time, asyncio

class RateLimiter:
    def __init__(self, rpm: int, bucket_seconds: float = 60.0, margin: float = 0.85):
        self.interval = bucket_seconds
        self.max_tokens = max(1, int(rpm * margin))
        self.tokens = self.max_tokens
        self.last_refill = time.monotonic()

    async def acquire(self, n: int = 1):
        while True:
            now = time.monotonic()
            elapsed = now - self.last_refill
            if elapsed >= self.interval:
                self.tokens = self.max_tokens
                self.last_refill = now
            if self.tokens >= n:
                self.tokens -= n
                return
            # 等到下一个窗口开始（保守写法）
            await asyncio.sleep(0.05)

# 用法示例：针对 Flash-Lite 15 RPM，margin=0.8 → 相当于目标 ~12 RPM 的安全线
rl = RateLimiter(rpm=15, margin=0.8)

async def safe_call(prompt):
    await rl.acquire(1)
    return your_generate_content_call(prompt)

配合 RPD 粗粒度保护（通过本地计数器或 Redis 记录当日请求量，接近上限时主动停止工作），就能彻底解决脚本因限流而崩溃的问题，实现稳定运行。

结语

Google AI Studio 提供了直观的 Rate Limit Dashboard，开发者可以在其中查看当前项目的各项限制和实时用量。每次修改脚本前花 30 秒查看一下自己的用量情况，比遇到问题后再花大量时间调试要高效得多。

对于有更高 API 调用需求的企业和开发者来说，免费层的额度往往难以满足生产环境的要求。此时，选择一个稳定可靠、价格优惠的 API 服务平台就显得尤为重要。UseAIAPI 作为专业的全球 AI 大模型 API 服务提供商，整合了 Gemini、Claude、ChatGPT、DeepSeek 等全球主流最新 AI 大模型，提供稳定高效的接入服务和企业级定制化解决方案。特别值得一提的是，平台目前推出了力度空前的优惠活动，所有 API 服务价格最低可达官方定价的 50%，能够帮助企业和开发者大幅降低 AI 使用成本，无需再为高强度内容生成带来的高额消耗而担忧。