Лимиты Gemini 3 Pro Image Preview: публичные правила, сброс квоты и исправление 429

По состоянию на 24 марта 2026 года самый безопасный ответ такой: gemini-3-pro-image-preview по-прежнему работает по публичным правилам Google, но полная таблица актуальных числовых лимитов больше не публикуется открыто. В официальной документации остаются ключевые для решений вещи: квоты считаются на уровне проекта, а не API-ключа; image-нагрузка может упираться в RPM, TPM, RPD и IPM; preview-модели обычно жёстче по лимитам; дневная квота RPD сбрасывается в полночь по Pacific Time. Если вам нужны точные текущие числа именно для вашего проекта, Google теперь отправляет в AI Studio, а не в публичную статичную таблицу.

Это выглядит менее удобно, чем старые посты со скриншотами лимитов, но с операционной точки зрения как раз полезнее. Когда «живые» значения ушли за логин, вопрос изменился с «какой лимит был в чьём-то блоге месяц назад?» на «что прямо сейчас показывает мой проект и какой именно bucket я выжигаю?». Если вы уже получаете 429, стандартный следующий шаг: проверить биллинг, посмотреть текущую квоту в AI Studio и понять, это burst-ограничение, дневной лимит или слишком низкий платный tier. Если прилетает 503, это уже проблема доступной мощности сервиса, а не квоты.

Эта статья нужна именно для решения, а не для определения терминов. Вы получите короткий рабочий ответ, таблицу для быстрой диагностики и порядок действий, который помогает убрать 429 без ложных шагов вроде ротации ключей в одном проекте.

Краткое содержание

Если нужна короткая версия, используйте эту таблицу.

Есть две оговорки, которые важнее любого скопированного скриншота.

Во-первых, Google по-прежнему публикует набор правил, но уже не публикует полную «живую» числовую таблицу для каждого проекта и модели. Поэтому старые статьи продолжают разносить точные числа, а актуальные официальные документы отправляют проверять лимиты в AI Studio.

Во-вторых, Gemini 3 Pro Image Preview всё ещё остаётся preview-моделью. Для preview-линий обычно характерны более жёсткие лимиты, более частые изменения и менее стабильное поведение по нагрузке по сравнению с зрелыми GA-маршрутами.

Что Google публично подтверждает о лимитах Gemini 3 Pro Image Preview

Публичный официальный ответ сейчас распределён по четырём страницам Google, а не по одной аккуратной матрице квот.

На актуальной странице rate limits Gemini API Google пишет, что лимиты считаются по requests per minute (RPM), tokens per minute (TPM) и requests per day (RPD), а для image-capable моделей также действует images per minute (IPM). Там же прямо сказано: лимиты применяются на уровне проекта, а не API-ключа, и RPD сбрасывается в полночь по Pacific Time. Отдельно отмечено, что preview-модели обычно более ограничены, чем стабильные.

Этого уже достаточно, чтобы закрыть три частые ошибки:

• новый API-ключ не создаёт новый пул квоты внутри того же проекта
• «дневной лимит сбрасывается в мою локальную полночь» — неверно, если вы не в Pacific Time
• preview image model нельзя планировать как долговременное обещание стабильного throughput

Следующий важный момент: Google больше не использует публичную документацию как полный источник «живых» чисел для online-лимитов. На странице rate limits разработчиков прямо просят смотреть активные лимиты в AI Studio. Иными словами, публичные документы всё ещё объясняют, как система устроена, но точные текущие числа для вашего проекта теперь живут в авторизованном интерфейсе.

Именно это изменение объясняет путаницу в выдаче. Некоторые статьи по-прежнему цитируют точные IPM/RPM для конкретных моделей как будто есть единая публичная таблица для всех. На деле официальный публичный слой сейчас аккуратнее: он задаёт измерения квот, логику tier и правила сброса, а за актуальными числами отправляет в AI Studio.

Цены добавляют ещё одно практическое ограничение. На актуальной странице цен Gemini Developer API gemini-3-pro-image-preview показан как paid-only маршрут. Это важно, потому что часть 429 на практике оказывается не «проблемой ретраев», а проблемой биллинга и tier.

Наконец, Google ясно указывает, что модель относительно новая и остаётся в preview-статусе. В официальных release notes запуск Gemini 3 Pro Image Preview отмечен датой 20 ноября 2025 года, а текущая страница моделей показывает Nano Banana Pro в актуальном image-preview семействе и отдельно предупреждает, что текстовая Gemini 3 Pro Preview была отключена 9 марта 2026 года. Это уточнение по неймингу критично: значительная часть путаницы в лимитах возникает из-за смешения закрытой text-модели и активной image-модели.

Что эти лимиты означают для реальной image-нагрузки

Названия лимитов простые. Их сбои в реальных image-системах уже не такие простые.

RPM понять легче всего: вы отправили слишком много запросов за короткое окно. Если одно действие пользователя запускает несколько image-вызовов, фронтенд-всплески могут выбить RPM намного раньше, чем дневная квота начнёт выглядеть тревожно. Поэтому команда может видеть «по дню ещё есть запас», пока пользователи уже получают 429. Дневной headroom ещё есть, но short-window bucket уже исчерпан.

TPM проще всего недооценить, пока вы не добавили более тяжёлые промпты, reference images или широкий мультимодальный контекст. В image-workflow Gemini не работает формула «одно изображение = один лёгкий запрос». Текст, входные медиа и текстовые части ответа вместе расходуют token-бюджет. Если pipeline строит тяжёлые промпты или делает многоэтапное редактирование, TPM может стать скрытым ограничителем даже при умеренном количестве запросов.

RPD обычно бьёт неожиданно на этапе прототипов и внутренних демо. Можно аккуратно вести минутную нагрузку и всё равно выжечь дневной потолок, если QA, дизайн и batch-процессы гоняют много генераций в одном проекте. А так как сброс идёт в полночь по Pacific Time, для вашей команды «конец дня» может наступать в середине локального рабочего дня.

IPM для image-нагрузки самый понятный и самый строгий параметр. По сути он отвечает на вопрос: сколько генераций проект может протолкнуть в коротком горизонте? Даже если Google не даёт полную публичную таблицу актуальных чисел, именно этот bucket команды чаще всего чувствуют первым. Если ваш сценарий строится вокруг очередей генерации, IPM обычно практичнее чистого RPM, потому что ближе к видимой для пользователя пропускной способности.

Поэтому главное правило планирования не в том, чтобы «запомнить одно число». Главное — проектировать систему вокруг bucket-а, который ваш продукт исчерпывает первым. Для большинства image-команд это значит:

• ставить запросы в очередь, а не стрелять параллельно всем сразу
• сглаживать bursts за счёт pacing у воркеров
• делать умные ретраи, а не мгновенные повторные штурмы
• отделять офлайн-генерацию от интерактивной

Если нагрузка не интерактивная, сама страница rate limits у Google даёт подсказку, что лучше переходить на Batch API. Google публикует отдельные batch-лимиты со своей логикой по запросам и токенам. Это прямой сигнал: не тратьте интерактивный quota-бюджет на массовые задачи, которые можно вынести в batch-конвейер.

Если нужна короткая рабочая модель, думайте так: публичные документы Google объясняют, какие buckets вообще существуют, AI Studio показывает, какого размера эти buckets сейчас для вашего проекта, а ваша архитектура определяет, в какой bucket вы упрётесь первым.

Почему 429 может оставаться даже после включения биллинга

Это самый болезненный участок темы, потому что после включения биллинга кажется, что проблема должна исчезнуть сразу.

Иногда так и происходит. Если проект был на очень ограниченном стартовом уровне, подключение биллинга действительно открывает более широкий лимитный контур. На публичной странице rate limits Google также объясняет текущую tier-логику: более высокие tiers требуют накопленных расходов и возраста аккаунта, и именно эти переходы по tiers постепенно увеличивают доступные лимиты.

Публичные правила по tiers стоит проговорить явно, потому что они влияют на решение сильнее, чем большинство страниц «как исправить 429»:

• Free: активный проект или free trial
• Tier 1: после настройки и привязки активного billing account
• Tier 2: сейчас требует $100 накопленных расходов и минимум 3 дня после первого успешного платежа
• Tier 3: сейчас требует $1,000 накопленных расходов и минимум 30 дней после первого успешного платежа

То есть фразы «я включил биллинг вчера» и «я уже на зрелом высоком tier» не равны. Много команд мысленно пропускают эту середину и ждут production-scale сразу после настройки оплаты.

Но биллинг не является магическим переключателем по трём причинам.

Во-первых, биллинг не меняет правило «квота считается на проект». Если один проект одновременно делят пять воркеров, несколько test-окружений и production-приложение, они делят и один quota pool. Платный проект тоже может упираться в лимит, если много нагрузок бьют в него одновременно.

Во-вторых, preview-модели по-прежнему обычно строже, чем стабильные. Даже на платном tier вы остаётесь в preview image-маршруте, где ограничения могут быть жёстче, чем ожидает команда. Публичная документация говорит об этом прямо, поэтому советы в стиле «просто апгрейднись и готово» быстро устаревают.

В-третьих, биллинг не лечит burst-паттерны. Если приложение отправляет много запросов одновременно, система может резать по short-window bucket, даже если месячный расход выглядит скромно. Иначе говоря, платный tier всё равно может падать на «шипастой» архитектуре.

Именно здесь к community-таблицам квот нужно относиться аккуратно. На форумах, в скриншотах и сторонних гайдах вы увидите конкретные IPM/RPM по tiers. Это может быть полезным контекстом, но это не равно живой официальной гарантии для вашего проекта. Надёжный workflow такой:

1. проверить статус биллинга
2. открыть AI Studio и прочитать актуальные лимиты проекта
3. определить, в чём реальная проблема: burst запросов, image throughput или дневной потолок
4. только после этого решать, нужен рост tier или архитектурные изменения

Если у вас основная проблема не квота, а стоимость, следующий шаг — наш гайд по ценам Gemini 3 Pro Image Preview и подробный разбор стоимости за одно изображение. Для этой модели решения по лимитам и по бюджету почти всегда связаны.

429 против 503: как отличить проблему квоты от проблемы мощности

Официальный гайд Google по troubleshooting формулирует разницу очень чётко:

• 429 RESOURCE_EXHAUSTED означает, что вы превысили rate limit
• 503 UNAVAILABLE означает временную перегрузку сервиса или недоступность мощности

Эта развилка должна сразу менять ваши следующие действия.

Когда приходит 429, спросите:

• какой именно bucket мы исчерпали
• на правильном ли billing tier находится проект
• не слишком ли резкие bursts мы отправляем
• не пытаемся ли использовать один проект как «безлимитный общий пул»

Когда приходит 503, спросите:

• не перегружен ли сервис временно
• нужно ли отступить (backoff) и повторить позже
• нужен ли fallback-маршрут через другую модель или другого провайдера

Самая дорогая ошибка — лечить оба статуса одинаково. Команды часто тратят время на запросы повышения квоты в ситуации, где на самом деле 503 и проблема в мощности, или же крутят бесконечные ретраи 429 в плотном цикле, будто ожидание само снимет лимит.

Для Gemini 3 Pro Image Preview путаница встречается особенно часто, потому что preview image-нагрузка может получать оба типа давления в одном временном окне. Пиковый трафик может загнать вас в 429, а глобальное сервисное окно перегрузки — дать 503 примерно в те же часы. Без раннего разделения статусов логи выглядят хаотично.

Используйте эту таблицу вместо догадок:

Если у вас в основном 503, сразу переходите к отдельному разбору Gemini 3 Pro Image 503 overloaded. Если ошибки шире одного кода статуса, полезнее общий гайд как исправлять Gemini API ошибки 429, 400 и 500-класса.

Что делать, если Gemini 3 Pro Image Preview слишком «узкий» для вашей нагрузки

Правильный ответ обычно скучнее, чем хочется. Почти никогда это не «секретный трюк». Обычно это «выбрать следующий шаг масштабирования в правильном порядке».

Начинайте так:

1. Подтвердите живую квоту в AI Studio. Не оптимизируйтесь по устаревшему скриншоту или сторонней таблице.
2. Проверьте биллинг и tier. Если проект ещё на стартовом уровне, следующим ограничением может быть рост tier, а не только код.
3. Сгладьте нагрузку. Очереди, ограничение конкурентности и exponential backoff вместо retry-штормов.
4. Вынесите неинтерактивные задачи из интерактивного маршрута. Для batch-генерации используйте batch-маршрут, а не интерактивный quota-бюджет.
5. Шардируйте проекты только после первых четырёх пунктов. Project-level sharding — архитектурный выбор, а не первая «заплатка».

Этот порядок важен, потому что популярный shortcut обычно самый вредный: создать больше API-ключей, добавить больше воркеров и надеяться, что всё само пройдёт. В рамках одного проекта это чаще делает давление только более хаотичным.

Если вы на раннем этапе продукта, полезно задать ещё один вопрос: действительно ли Gemini 3 Pro Image Preview должен быть базовым маршрутом именно для этой нагрузки? Если у вас high-volume, чувствительность к цене и меньшая зависимость от премиального text rendering или студийной компоновки, более лёгкие image-маршруты Gemini обычно масштабируются проще. Здесь полезен наш разбор бесплатных и недорогих маршрутов Gemini image API: многие проблемы «лимитов» на практике являются проблемами выбора модели.

Если же вы осознанно остаетесь на Gemini 3 Pro Image Preview, потому что задаче действительно нужен премиальный output, путь остаётся тем же:

• сглаживать трафик
• разделять интерактивную и офлайн-нагрузку
• мониторить реальный bottleneck-bucket
• считать preview-поведение текущей реальностью, а не «ошибкой ожиданий»

Звучит менее эффектно, чем «хак», но именно так production-системы перестают падать.

Проверочный список лимитов перед продакшен-запуском

Перед запуском этой модели в прод я бы проверил эти семь пунктов по порядку.

1. Точная живая квота зафиксирована из AI Studio, а не скопирована из поста.
Если число взято из скриншота недельной давности, для capacity-планирования оно уже слабое.

2. Команда понимает, что квота считается на проект.
Если несколько приложений, воркеров и окружений сидят в одном проекте, болевые точки у них тоже общие.

3. Команда учитывает timezone сброса.
Полночь по Pacific Time — это реальное продуктовое ограничение, а не примечание внизу.

4. Ретраи используют backoff и jitter.
Мгновенные повторы — самый быстрый способ превратить лимитную проблему в самоиндуцированный outage.

5. 429 и 503 обрабатываются как разные инциденты.
Исчерпание квоты и перегрузка сервиса не должны уходить в одну ветку «подождать и надеяться».

6. Интерактивная и неинтерактивная генерация разделены.
Массовая генерация должна идти отдельным маршрутом, а не тем же контуром, что user-facing задачи.

7. Выбор модели всё ещё соответствует нагрузке.
Если у вас в основном утилитарная массовая генерация, а не premium-ассеты, лучше ещё раз проверить, нужен ли Pro как основной маршрут.

Лучший результат после чтения этой статьи — не «я запомнил одну цифру лимита». Лучший результат — «я знаю, где брать живое число, какие правила официальные, что означает каждый код ошибки и какой следующий шаг действительно стоит делать».

Bottom line

Лимиты Gemini 3 Pro Image Preview не полностью закрыты, но и не полностью публичны. Google по-прежнему публикует правила, которых достаточно для корректных решений: квоты считаются на проект, preview-модели более ограничены, дневная квота сбрасывается в полночь по Pacific Time, 429 означает исчерпание квоты, а 503 — временную перегрузку сервиса. За точным активным числом именно вашего проекта теперь нужно идти в AI Studio — это основной источник.

Для практики в марте 2026 года этого достаточно. Если получаете 429, подтвердите биллинг и живую квоту в AI Studio, затем сглаживайте нагрузку или переходите на подходящий tier. Если получаете 503, применяйте backoff и трактуйте это как сервисное давление, а не как личный провал квоты. И если вы продолжаете искать одно универсальное статичное число «на память», вы решаете версию продукта из 2025 года, а не текущую модель 2026 года.