Gemini 3.5 Flash API 一直报 429 RESOURCE_EXHAUSTED 怎么办？免费层和付费层配额计数规则不一样，别白等 60 秒-北京尧图网络

直接说结论Gemini 3.5 Flash 的 429 RESOURCE_EXHAUSTED 不一定是配额用完了它可能是 RPM每分钟请求数、TPM每分钟 Token 数、RPD每日请求数三种限制中的任意一种被触发。免费层按项目级计数付费层配额同样以 GCP 项目为单位统计并非单 Key 独立桶多 Key 不能线性叠加配额免费层与付费层的配额计数规则不同。你得先看报错 JSON 里的violations[].subject字段确认到底撞了哪面墙再决定是重试、降级模型还是升级套餐——盲目time.sleep(60)是最低效的做法。给一个内容聚合工具加 Gemini 3.5 Flash 做摘要提取跑了不到两分钟控制台就开始刷屏google.api_core.exceptions.ResourceExhausted: 429 Resource has been exhausted (e.g. check quota).第一反应是免费额度用完了吧充了钱切到付费层结果还是报。免费层和付费层的限流桶不是一套逻辑下面逐一拆解。先搞清楚 429 到底在说什么很多人看到 429 就觉得是钱不够或者今天的免费次数用光了。不是。Gemini API 的 429 RESOURCE_EXHAUSTED 背后有三种完全不同的配额限制。以下以 gemini-2.5-flash 为参考说明限制结构gemini-3.5-flash 的免费层限制结构类似配额类型免费层Free Tier付费层Pay-as-you-goRPM每分钟请求数见 Console 实际值示例仅供参考约 15见 Console 实际值示例仅供参考约 2000TPM每分钟 Token 数见 Console 实际值见 Console 实际值RPD每日请求数见 Console 实际值无硬限制⚠️ 上表数值为示例仅供参考价格与配额以 Google Cloud Console 当前显示为准。关键差异免费层的 RPM 按整个 GCP 项目计数同一个项目下的所有 Key 共享同一个 RPM 配额桶。付费层配额同样以 GCP 项目为单位统计项目内多个 Key 共享同一配额池并非每个 Key 独立享有完整配额多 Key 同样不能线性叠加配额上限。无论免费层还是付费层在同一个 GCP 项目下增加 Key 的数量都无法线性叠加配额上限。graph TD A[429 RESOURCE_EXHAUSTED] -- B{检查 violations.subject} B --|GenerateRequestsPerMinute| C[RPM 超限] B --|GenerateTokensPerMinute| D[TPM 超限] B --|GenerateRequestsPerDay| E[RPD 超限] C -- F[免费层: 降频至免费层 RPM 上限以下] C -- G[付费层: 申请配额提升或走聚合网关] D -- H[缩短 prompt / 拆分请求] E -- I[只有免费层有 RPD 限制]怎么判断你撞的是哪种限制不要猜看报错。最有诊断价值的是带details字段的完整响应。注意以下 JSON 为简化示意实际 Google API 错误响应中details数组的元素包含type字段如type: type.googleapis.com/google.rpc.QuotaFailure其下才有violations。{ error: { code: 429, status: RESOURCE_EXHAUSTED, details: [{ type: type.googleapis.com/google.rpc.QuotaFailure, violations: [{ subject: quota:GenerateRequestsPerMinute }] }] } }subject字段会直接告诉你是GenerateRequestsPerMinuteRPM还是GenerateTokensPerMinuteTPM。但坑的是不是所有 429 响应都带 details。如果你用 Python SDK 直接 catch 异常默认只能看到google.api_core.exceptions.ResourceExhausted: 429 Resource has been exhausted (e.g. check quota).有效信息很少。所以建议在 debug 阶段用 httpx 直接打 REST 接口把完整的 response body 打出来import httpx r httpx.post(url, jsonpayload, headersheaders) if r.status_code 429: print(r.json()) # 看完整 error.details方案一正确实现指数退避别自己瞎写 sleepGoogle 官方推荐的退避参数初始等待 1s最大等待 32s最多重试 5 次。但很多人的实现有两个致命问题问题 1没读 retryDelay 字段。报错响应里有时候会带一个retryDelay值可能是30s或60s。忽略这个值自己算退避时间可能等得不够长白白浪费一次重试也可能等太久。问题 2并发场景没加信号量。开了 10 个协程同时打每个都在独立退避重试结果重试的时候又同时发出去了继续撞墙。正确的实现应当优先读取响应中的retryDelay字段无该字段时再回落到指数退避import time import re from google.api_core.exceptions import ResourceExhausted def parse_retry_delay(exc: ResourceExhausted) - float | None: 尝试从异常的 details 中解析 retryDelay返回秒数解析失败返回 None。注意此函数适用于通过 REST 接口调用时 SDK 将响应解析为 dict 的场景。通过 gRPC 路径调用时exc.details 返回 protobuf 对象列表 isinstance(detail, dict) 判断为 False函数将静默返回 None 并回落到指数退避。建议结合实际 SDK 版本google-generativeai / google-cloud-aiplatform和调用路径REST/gRPC验证解析行为。 try: for detail in exc.details: if hasattr(detail, retry_delay): return detail.retry_delay.seconds # REST 响应有时以字符串形式携带如 30s if isinstance(detail, dict): delay_str detail.get(retryDelay, ) match re.match(r(\d)s, delay_str) if match: return float(match.group(1)) except Exception: pass return None def call_with_backoff(model, prompt, max_retries5): for attempt in range(max_retries): try: return model.generate_content(prompt) except ResourceExhausted as e: retry_delay parse_retry_delay(e) if retry_delay is not None: wait retry_delay else: wait min(2 ** attempt, 32) print(f[429] 重试 {attempt 1}/{max_retries}等 {wait}s) time.sleep(wait) raise Exception(重试耗尽)如果你有并发需求必须加信号量import asyncio sem asyncio.Semaphore(5) # 最多 5 个并发 async def safe_call(model, prompt): async with sem: return await call_with_backoff(model, prompt)google-api-core的 SDK 内置了 retry 机制但默认不对 429ResourceExhausted重试只对 503、500 等瞬时错误重试。你可以显式配置from google.api_core import retry response model.generate_content( Hello, request_options{retry: retry.Retry( predicateretry.if_transient_error )} )注意request_options参数的支持方式因 SDK 包google-generativeai与google-cloud-aiplatform及版本而异建议查阅你所使用的 SDK 对应版本文档确认用法。手动控制的好处是出了问题知道在哪。方案二降级到 flash-lite免费层 RPM 更高这个方案容易被忽视。gemini-3.5-flash-lite的免费层 RPM 通常高于gemini-3.5-flash。如果你的场景不需要特别强的推理能力比如文本分类、简单摘要、格式转换切 flash-lite 就能缓解限流压力且成本更低。对比项gemini-3.5-flashgemini-3.5-flash-lite免费层 RPM参考 Console 实际值通常高于 flash参考 Console 实际值免费层 RPD参考 Console 实际值参考 Console 实际值付费层 input 价格参考官方定价页低于 flash参考官方定价页付费层 output 价格参考官方定价页低于 flash参考官方定价页⚠️ Gemini 定价和配额调整频繁表中不列具体数值以 Google AI Studio 及 Google Cloud 定价页当前显示为准。付费层价格也更便宜。高频低复杂度场景这比直接升级付费层划算得多。方案三用聚合 API 网关分散限流压力如果确实需要高并发且免费层不够用还有一条路通过 API 聚合平台调用。像 ofox.io 这类网关后端对接多个 GCP 项目和多个 Key请求会被分散到不同的配额桶里单个用户感知到的 RPM 上限比自己一个项目高不少。改动很小换个 base_urlfrom openai import OpenAI client OpenAI( api_key你的聚合平台key, base_urlhttps://api.ofox.io/v1 )resp client.chat.completions.create( modelgemini-3.5-flash, messages[{role: user, content: Hello}] )好处是不用自己管 GCP 项目配额也不用折腾 billing 设置。OpenRouter 在模型官方价格基础上有一定加价具体以其官网当前公示为准。不过聚合平台本身也有自己的 rate limit不是无限的。量真的大到每分钟几千次老老实实开付费层并在 Cloud Console 申请配额提升才是根本解法。常见问题 FAQQ: 我已经开了付费层为什么还是 429付费层 RPM 参考值约为 2000以 Console 实际值为准但 TPM 同样有限制。如果你的 prompt 很长比如塞了一整篇文章进去几十个请求就可能把 TPM 打满。看报错里的violations[].subject是不是GenerateTokensPerMinute是的话需要缩短 prompt 或者拆分请求。也可以在 Google Cloud Console 里申请提升配额。Q: retryDelay 字段在哪里我的报错里没看到。不是所有 429 响应都带retryDelay。这个字段在error.details数组里有时候 Google 会返回有时候不返回。没有的话就用指数退避兜底1s → 2s → 4s → 8s → 16s最大 32s。Q: 免费层多搞几个 API Key 能不能绕过 RPM 限制不能。免费层的 RPM 按 GCP 项目级别计数同一个项目下不管建多少个 Key共享同一个配额桶。付费层同样按项目计数多 Key 同样不能叠加配额。如果需要更高配额正规途径是升级到付费层或在 Cloud Console 申请配额提升。Q: gemini-3.5-flash 和 gemini-2.5-flash 的限流规则一样吗结构一样都是 RPM TPM RPD 三层限制具体数值不同且 Google 会随模型版本调整配额。以你在 Cloud Console → IAM Admin → Quotas 页面看到的实际值为准官方文档有时候更新不及时。Q: 我用 Cline / Claude Code 调 Gemini 也会 429怎么处理这些工具底层走的也是同一套 API该撞的限流一样撞。如果在工具里配了 ofox.io 这类聚合网关的 base_url限流压力会小一些因为请求被分散到了网关后面的多个配额桶。但根本解法还是控制调用频率或者升级套餐。小结429 RESOURCE_EXHAUSTED 看着简单但免费层和付费层的计数逻辑差异确实容易踩坑。总结下来就三步先看 violations.subject 确认是 RPM、TPM 还是 RPD 超限——这步不做后面全是无效操作RPM 超限且量不大——指数退避优先读 retryDelay 信号量限并发或者降级到 flash-lite量确实大——开付费层并申请配额提升或者走聚合网关分散压力看到 429 不要无脑sleep(60)那是最浪费时间的做法。

Gemini 3.5 Flash API 一直报 429 RESOURCE_EXHAUSTED 怎么办？免费层和付费层配额计数规则不一样，别白等 60 秒

相关推荐

第8章 YOLO+DeepSORT：无人机视角下的目标跟踪

管道加热器材质选型：304/316L/Incoloy 800 对比与 Python 选材辅助

MCU上跑LLM：ESP32-P4推理速度从0.61到4.31 tok/s的7倍优化实战

更多资讯

《AI Agent 核心机制》第五篇：一个 Agent 不够用时：Multi-Agent 协作架构怎么设计

C语言指针超级进阶：字符与字符串数组、string 库函数原型、指针与二维数组

第一套行测真题做得一塌糊涂？先别急着放弃

机器人与机电一体化3D数字孪生机器-Day1

上下文注入时机：在对话中途插入新信息的技巧

零LLM开销调度：ainovel-cli的Route决策表与12万组合穷举测试怎么做

今日更新

Agent Skills 完全指南：原理、写法、安装与实战避坑

Agent Skills 实战：从 Genkit 定义到 GKE 部署与排查

Agent Skills 实战：从设计到调试的完整指南

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？