Gemini 图像生成的限制不是一个数字。你看到的“今天不能继续生成”“达到上限”或 429 RESOURCE_EXHAUSTED，首先要归到正确入口：Gemini Apps、Google AI Studio 里的 Gemini API，还是 Vertex AI。
最稳妥的判断顺序是：Gemini Apps 看套餐每日图片上限；Gemini API 看项目、模型和层级的实时配额；Vertex AI 看 Cloud 项目、区域、IAM 与配额。只有先确认入口，后面的等待、降载、排队、开通计费或申请扩容才不会走错方向。
先判断你撞到哪一种 Gemini 图像限制
同一句“Gemini 图像生成限额”在实际使用里可能指三套不同系统。消费者在网页或 App 里生成图片，开发者在 AI Studio 用 API key 调模型，企业团队在 Vertex AI 上跑 Cloud 项目，这三者不会共享一个公开数字，也不应该用同一套修复方法。
| 使用入口 | 限制控制什么 | 到哪里核对 | 第一动作 |
|---|---|---|---|
| Gemini Apps | 面向消费者的图片生成、编辑、重做次数，以及套餐功能可用性 | Gemini Apps Help 页面和产品内提示 | 等待每日重置，减少连续重做，确认当前套餐是否支持目标功能。 |
| Gemini API / Google AI Studio | 项目、模型、层级和容量维度的调用配额 | Gemini API rate limits 文档和 AI Studio 的实时配额页 | 查项目与模型，再按 RPM、TPM、RPD 或 IPM 做限流、排队、计费或扩容。 |
| Vertex AI | Google Cloud 项目、区域、IAM、治理、计费和配额 | Cloud Console 与 Vertex AI 图像生成限制文档 | 只有当 Cloud 项目治理、日志、权限或生产配额流程是硬需求时才切换。 |
这个分流很重要，因为 Gemini Apps 的每日图片上限不是 Gemini API 的项目配额。一个 API 项目可能正在返回 429，但同一个账号在 Gemini App 里仍然能生成图片；反过来，App 里达到每日上限，也不代表你的 API 项目已经没配额。多个 API key 如果属于同一 Google Cloud 或 AI Studio 项目，也不会凭空得到多份独立配额。
如果你只是想知道“今天还能生成几张图”，先看 Gemini Apps。若你在代码里调用模型、日志里有状态码、请求里有模型名和 API key，就看 Gemini API。若请求通过 Cloud 项目、区域、IAM、服务账号和企业日志体系运行，才按 Vertex AI 处理。
Gemini Apps 的每日图片上限怎么看
Gemini Apps 的官方口径属于消费者产品限制。Google Help 在 2026 年 5 月 3 日可见的表述里，把 Nano Banana 2 的图片生成与编辑，以及 Nano Banana Pro 的图片重做，按 Basic、Google AI Plus、Google AI Pro、Google AI Ultra 区分每日上限。页面同时提示，图像生成和编辑需求很高，限制可能频繁调整，并且每天重置。
| Gemini Apps 图片功能 | Basic | Google AI Plus | Google AI Pro | Google AI Ultra |
|---|---|---|---|---|
| Nano Banana 2 图片生成与编辑 | 最多 20 张/天 | 最多 50 张/天 | 最多 100 张/天 | 最多 1000 张/天 |
| Nano Banana Pro 图片重做 | 不可用 | 最多 50 张/天 | 最多 100 张/天 | 最多 1000 张/天 |
这些数字只能解释 Gemini Apps，不应直接搬到 Gemini API。消费者界面的提示通常是“今天不能继续创建图片”“已达到图片生成上限”或“功能暂时不可用”。这种情况下，API 文档里的 RPM、TPM、RPD、IPM 不能改变 App 里的每日上限。
正确动作也比较直接：等每日重置；减少连续重做和反复试同一提示词；确认当前套餐是否包含你要用的模型或重做功能；只有在 App 套餐上限确实是瓶颈时，才考虑升级。不要把“换 API key”“开新项目”“切到 Vertex AI”当作消费者 App 上限的默认解法，那会把简单等待问题变成复杂工程问题。
Gemini API 的图像配额在 AI Studio 里确认
Gemini Developer API 的限制属于项目和模型。Google 的 Gemini API rate limits 文档说明，限制按项目应用，而不是按单个 API key 应用；同时它把配额拆成不同维度，例如每分钟请求数、每分钟 token、每日请求数，以及图像能力模型相关的每分钟图像数。
排查 API 图像生成限制时，不要先找一张全网流传的“Gemini 图像生成限额表”。更可靠的操作是打开 Google AI Studio，切到拥有该 API key 的项目，找到你实际调用的模型，然后看当前层级下的实时配额。如果你的代码调用的是 preview image 模型，还要把容量波动和可用性变化纳入预期。
API 限制最常被误判的地方是把四种配额混在一起。小请求瞬间爆发，通常压到 RPM；提示词很长、带多模态输入或上下文很大，可能压到 TPM；一天内稳定高流量，可能用尽 RPD；真正图像输出相关的压力，才会更多落在 IPM 或模型容量上。
| API 现象 | 更可能的限制维度 | 处理方式 |
|---|---|---|
| 几秒内大量小图请求失败 | RPM 或短时容量 | 降并发、队列化、指数退避，加随机抖动。 |
| 大提示词、多图输入或长上下文更容易失败 | TPM 或请求体压力 | 缩短输入、拆分任务、缓存可复用上下文。 |
| 白天运行正常，晚上整天额度用尽 | RPD | 统计日消耗，限制非关键任务，申请更高日配额。 |
| 文本模型仍可用，图片生成特别容易失败 | IPM 或图像模型容量 | 给图像任务单独排队，减少重试放大，核对模型专属配额。 |
多个 API key 在同一项目里共享配额，因此轮换 key 不是合规的扩容方法。真正的生产修复应当是排队、限流、缓存、批处理、降低突发并发、补齐计费前提，并在工作量稳定且合理时提交官方配额提升申请。
价格、模型可用性和配额要分开判断
Gemini 图像生成讨论经常把三个问题混成一个答案：模型能不能生成图片，免费层或付费层能不能调用，当前项目到底有多少速率配额。这三个问题分别由不同证据负责。
Gemini API pricing 页面负责价格和免费/付费可用性；image-generation 文档负责调用方式、输入输出结构和模型能力；rate limits 文档与 AI Studio 负责当前项目、模型和层级的配额。一个模型出现在价格页，不等于你的项目已经有足够 IPM；一个模型是付费-only，也不等于所有 429 都是账单问题。
截至 2026 年 5 月 3 日，Google 的开发者价格表把 gemini-3-pro-image-preview 放在付费 API 行里。这个事实说明的是访问和计费边界，而不是所有项目的实时速率数字。preview 模型还要按更高波动处理：今天能跑的并发，不一定明天在同一时段仍然稳定。
上线前的检查清单应该是工程化的，而不是只问“是不是免费”：
- 代码实际调用的模型名是什么？
- 这个模型是否支持当前入口的图片生成或编辑？
- 模型是免费、付费、preview，还是有特殊可用性说明？
- API key 属于哪个项目，是否看错项目配额？
- AI Studio 里显示的 RPM、TPM、RPD、IPM 分别是多少？
- 错误响应里有没有
retryDelay、quota metric、request id 或更具体的错误详情？
这组问题能避免两个常见误判：把短时突发 429 当成未开通计费，把付费-only 访问失败当成普通速率限制。
出现“达到限制”时该怎么做
先看提示来自哪里。Gemini Apps 里的“达到上限”通常是套餐每日图片生成、编辑或重做次数用完。此时最有效的是等重置、减少重做循环、核对套餐功能，或者在确有必要时升级。不要用 API 的项目配额解释这个提示。
如果提示来自代码、网关日志或 API 响应，先打开 AI Studio。查看项目、模型和层级，确认是 RPM、TPM、RPD 还是 IPM。然后再决定动作：短时突发用限流和队列；大输入用压缩和拆分；日额度用流量预算；图像输出容量用单独队列、较低并发和更长退避。
如果这是持续的真实业务量，就把图像生成当作队列任务，而不是同步按钮。记录每个任务的项目、模型、quota metric、请求 id、重试次数和最终状态。前端可以给用户明确的排队或等待状态，后台则用幂等任务避免重复扣量。
如果响应已经是 429 RESOURCE_EXHAUSTED，进入 API 诊断分支。尊重 retryDelay，不要所有 worker 立即重试；用指数退避加 jitter；在日额度耗尽时停止紧密重试；如果有明确 quota metric 和稳定业务需求，再准备配额申请材料。更细的代码级处理可看相邻说明：Gemini 图像生成 429 修复指南。
API 429 和 App 每日上限不是同一类问题
App 每日上限是消费者功能限制；API 429 是项目、模型、层级或容量规则触发后的 API 错误。两者都可能被用户说成“Gemini 图片生成被限了”，但修复路径完全不同。
处理 429 前先保留证据。错误响应里如果有 retryDelay，客户端应按它等待，并加随机抖动防止多个 worker 同时恢复。quota metric 能告诉你是 RPM、TPM、RPD 还是 IPM；项目和模型能避免你在错误的 dashboard 上查配额；billing state 能解释访问资格或层级，但不能证明限制消失；request id 和错误详情则是后续排查、支持工单或配额申请的基础。
最危险的模式是 aggressive retry。一个任务失败后立即重试，十个 worker 失败后同时重试，队列会把本来短暂的配额问题放大成持续拥塞。更稳的架构是：限制并发、队列化图片任务、区分可重试和不可重试错误、缓存重复请求、对非关键图片任务降级，并把等待状态清楚地展示给用户。
如果 429 来自第三方封装或多模型网关，还要确认真正的上游模型名和项目归属。外层提示写着 Gemini，不代表你看的是正确 Google 项目；外层重试策略也可能把上游 retryDelay 吃掉。生产排查必须拿到原始错误细节或等价的结构化日志。
什么时候才该切到 Vertex AI
Vertex AI 不是绕过 Gemini 图像生成限额的捷径。它是 Google Cloud 路线，带来 Cloud 项目、区域、IAM、日志、计费、配额申请和组织治理。它的价值不是“没有限制”，而是让生产团队把模型调用放进已有 Cloud 运营体系。
如果你只是原型验证、个人工具、简单脚本或低频图片生成，Gemini Developer API 和 AI Studio 通常更轻。先用官方 API 记录真实请求量、模型名、失败率和配额维度，再决定是否需要更复杂的 Cloud 路线。
如果团队已经需要区域控制、服务账号、Cloud Logging、IAM 审计、企业支持、配额审批流程或统一账单，Vertex AI 可以成为正确入口。切换前要重新核对模型可用性、区域、输入限制、输出限制、安全策略和成本，不要假设 AI Studio 的行为会一比一迁移到 Vertex AI。
真正的问题不是“哪条路没有限额”，而是“哪条路拥有这个工作负载，并且我们能运营它的配额流程”。答案可能是继续用 Gemini API，也可能是上 Vertex AI，但不应该是为了逃避 App 每日上限而盲目迁移。
常见问题
Gemini 每天能生成多少张图片？
Gemini Apps 有按套餐区分的每日图片上限，Google Help 在 2026 年 5 月 3 日可见的说明里列出了 Basic、Google AI Plus、Google AI Pro 和 Google AI Ultra 的图片生成、编辑、重做上限。具体可用数字仍以当前 Help 页面和产品内提示为准，因为 Google 明确说限制可能频繁变化。
Gemini API 的图像生成速率限制是多少？
没有一个适用于所有项目的统一数字。Gemini API 的限制按项目、模型和层级生效，并且可能拆成 RPM、TPM、RPD、IPM。到 AI Studio 查看实际项目和实际模型的实时配额，比引用静态表更可靠。
每个 Gemini API key 都有自己的图片配额吗？
不是。Gemini API 文档说明速率限制按项目应用，而不是按 API key 应用。同一项目下创建多个 key，仍然共享同一项目配额池。
开通计费后就没有 Gemini 图像生成限制了吗？
不会。计费可能改变层级、解锁某些付费模型或让配额申请成为可能，但模型、项目、容量、安全和速率限制仍然存在。付费不是无限制。
Nano Banana Pro 图像生成免费吗？
要看入口。Gemini Apps 里是套餐功能和每日上限问题；Gemini API 里是价格页、模型可用性和项目配额问题。不要把 App 套餐的免费/付费说法直接当成 API 价格或 API 配额。
达到图片限制后要等多久？
Gemini Apps 通常按每日重置处理，具体看产品提示和 Google Help 当前说明。Gemini API 的 429 如果带 retryDelay，按响应等待并使用退避；如果是 RPD 用尽，短时间循环重试没有意义。
可以绕过 Gemini 图像生成限制吗？
不应该尝试绕过。安全做法是等待重置、降低并发、队列化任务、缓存重复输出、选择正确官方入口、补齐计费前提，或为真实工作负载申请配额提升。用 key 轮换或无控制重试逃避限制，通常会让稳定性更差。
什么时候该看 429 修复指南？
当 API 响应明确返回 429 RESOURCE_EXHAUSTED，或者日志里出现 quota metric、retry delay、request id 时，进入 429 诊断。先用上面的入口分流确认限制归属，再用 429 分支处理代码重试、排队、日志和扩容证据。
