Лимиты Gemini API в 2026 году: как найти причину 429 по проекту, уровню и режиму обработки

У Gemini API нет единого лимита для всех продуктов и аккаунтов. Для Developer API действующее ограничение зависит от проекта, модели, уровня использования, метрики и режима обработки; актуальное значение нужно проверять в AI Studio, а не считать публичную таблицу гарантированной емкостью.

При сбое сохраните HTTP-статус и полное тело ошибки до изменения кода или платежных настроек. 429 RESOURCE_EXHAUSTED относится к исчерпанному лимиту, а 503 UNAVAILABLE — к временной нехватке сервисной емкости. Повторный запрос не создаст дневную квоту, не пополнит предоплаченный баланс и не поднимет жесткий предел расходов.

Сначала определите продукт Google, который получил запрос

Название Gemini используется в потребительском приложении, API для разработчиков, Firebase и Google Cloud. Одинаковое имя модели не означает, что все четыре поверхности делят одну квоту. Надежные признаки — SDK, конечная точка, проект и способ аутентификации.

Такое разделение объясняет ситуации, которые выглядят противоречиво. Приложение Gemini может показать ограничение, хотя Developer API еще обслуживает запросы. Один пользователь Firebase может упереться в шлюз при свободной квоте модели. Vertex AI может вернуть 429 из-за Cloud-емкости, не оставив видимого сигнала в AI Studio.

Под Developer API здесь понимаются запросы с API-ключом по контракту ai.google.dev. Firebase и Vertex AI добавляют собственные платформенные уровни. Их нельзя диагностировать только по названию модели.

Контракт Developer API: метрика, проект, модель и уровень

В официальном описании лимитов Google выделяет три базовые метрики и прямо указывает: ограничения применяются к проекту, а не к отдельному API-ключу.

Превышение любой применяемой метрики может вызвать 429. Низкий RPM не исключает исчерпания входных TPM. Маленький промпт не исключает RPD. Фраза «я сделал всего несколько запросов» не учитывает production, ноутбуки, cron, тестовую среду и другие ключи того же проекта.

У отдельных моделей и модальностей бывают TPD, IPM и ограничения Batch. Это не универсальные числа Gemini, а значения конкретной модели и режима. Если исчерпан IPM генерации изображений, используйте отдельную диагностику Gemini Image 429.

Два правила снимают большую часть ошибок. Во-первых, несколько ключей одного проекта используют общий пул: ротация учетных данных не равна масштабированию. Во-вторых, публичная документация объясняет механику, а живое число принадлежит AI Studio. Google предупреждает, что опубликованные значения не гарантированы и фактическая емкость может отличаться.

Preview- и экспериментальные модели часто имеют более строгие пределы. Доступность модели на бесплатном и платном маршруте меняется отдельно. Если неясно, имеет ли проект право на нужную модель, сначала проверьте условия бесплатного уровня Gemini API, не смешивая доступ и остаток квоты.

Диагностика владельца лимита за одну минуту

Соберите пакет, который можно передать другой команде без потери контекста:

• поверхность и полный endpoint;
• ID проекта и принадлежность ключа, но не сам секрет;
• точная модель и режим обслуживания;
• HTTP-код, статус и полный текст ошибки;
• время с часовым поясом;
• размер входа, параллелизм и число недавних повторов;
• показания AI Studio или Cloud за тот же интервал.

Затем двигайтесь в фиксированном порядке:

1. Поверхность: приложение Gemini, Developer API, Firebase AI Logic или Vertex AI.
2. Статус: ограничение 429 или временная емкость 503.
3. Метрика: RPM, входные TPM, RPD, расходы, баланс, Priority или Batch.
4. Агрегация: какой проект или платежный аккаунт владеет контролем и какие нагрузки его делят.
5. Режим: Standard, Priority, Batch, шлюз Firebase или Vertex.
6. Консоль: совпадают ли ошибка и данные владельца в одно время.
7. Действие: измените минимальный параметр, способный повлиять на доказанного владельца.
8. Проверка: повторите представительскую нагрузку на том же проекте и модели.

Уровень, rolling spend, баланс и лимиты расходов — разные контроли

Фраза «я уже включил оплату» не закрывает финансовую ветку. По состоянию на 14 июля 2026 года официальные страницы лимитов и биллинга Gemini API разделяют как минимум четыре механизма.

Квалификация уровня рассчитывается на платежном аккаунте, а запросы Developer API агрегируются на проекте. Два связанных проекта могут иметь один уровень, но не становятся одним пулом запросов. И наоборот, высокий финансовый cap не возвращает исчерпанный RPD.

Эти числа нестабильны. Перед производственным изменением откройте текущий раздел usage tiers и spend limits и живые значения проекта. История платежей, состояние аккаунта, задержка зачисления и задержка отчетности меняют результат.

Пример: у проекта Tier 2 низкий RPM, но 429 продолжаются. Если дорогие запросы превысили десятиминутный spend limit, больше параллелизма лишь ускорит отказ. Если rolling spend нормален, но Prepay равен нулю, минута ожидания не поможет. Если оба контрола в порядке, а RPD исчерпан, дополнительный платеж тоже не тот рычаг.

Standard, Priority и Batch — три разных режима

Режим обработки входит в контракт емкости до сбоя.

Документация Batch API допускает время выполнения до 24 часов и предупреждает: создание job не идемпотентно. Создайте постоянный клиентский ID, сохраните имя возвращенной задачи и не подавайте дубликат только потому, что запрос создания завершился таймаутом.

Batch не является «еще одним местом для повторов». Он освобождает интерактивную емкость для работ, которые могут ждать. Priority тоже не дает автоматическую прибавку каждому проекту: нужны право доступа, собственный запас и общий interactive headroom.

Повторяйте только тогда, когда время может изменить владельца

Официальное устранение неполадок разводит 429 и 503 до применения retry.

Функция ниже требует явной классификации временного 429. Универсальный wrapper не получает права атаковать жесткий предел.

javascript
const sleep = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

export async function withGeminiRetry(run, {
  maxAttempts = 5,
  baseDelayMs = 750,
  maxDelayMs = 20_000,
  isTransient429 = () => false,
  onRetry = () => {},
} = {}) {
  let lastError;
  for (let attempt = 1; attempt <= maxAttempts; attempt += 1) {
    try {
      return await run();
    } catch (error) {
      lastError = error;
      const status = Number(error?.status ?? error?.code ?? 0);
      const retryable = status === 500 || status === 503 || status === 504 ||
        (status === 429 && isTransient429(error));
      if (!retryable || attempt === maxAttempts) throw error;

      const ceiling = Math.min(
        maxDelayMs,
        baseDelayMs * 2 ** (attempt - 1),
      );
      const delayMs = Math.floor(Math.random() * ceiling);
      onRetry({ attempt, status, delayMs, message: error?.message });
      await sleep(delayMs);
    }
  }
  throw lastError;
}

Снаружи нужен ограничитель параллелизма по проекту и модели. Иначе десять worker-процессов проснутся одновременно и создадут новый пик. Используйте ключи идемпотентности там, где операция это допускает, кэшируйте дубли и ограничивайте суммарное время повторов бюджетом ожидания пользователя.

isTransient429 возвращает true только при доказанном кратком RPM-всплеске или похожем состоянии, которое изменит время. Исчерпанный RPD, нулевой Prepay, spend cap, отклоненный запрос на квоту и требующая настройки граница возвращают false.

Firebase AI Logic добавляет пользовательский шлюз

Firebase не отменяет квоту поставщика модели. Документация Firebase говорит, что provider quota сохраняется и имеет приоритет, а шлюз добавляет настраиваемый предел на пользователя. На 14 июля 2026 года документированное значение по умолчанию — 100 RPM на пользователя.

Много пользователей могут по отдельности оставаться ниже Firebase-предела, но вместе исчерпать проект поставщика. Один ошибочный клиент, наоборот, может удариться в user limit при свободной модели. Сопоставьте слой Firebase, идентичность App Check и provider usage одного запроса.

Повышение user limit не увеличивает provider capacity. Увеличение provider quota не удаляет намеренно низкий защитный предел клиента. Меняйте только слой, указанный доказательствами.

Vertex AI использует Cloud-контракт 429

Vertex AI работает с Cloud-проектом, локацией, endpoint и емкостью. Руководство Vertex AI по 429 разделяет pay-as-you-go и Provisioned Throughput по сообщениям и действиям.

Для pay-as-you-go рассматривают global endpoint, если он поддерживается, сглаживание, ограниченные повторы, запрос квоты для quota-based моделей или изменение capacity plan. Для Provisioned Throughput нужно понять, попадает ли трафик в купленный throughput и как обрабатывается превышение. Сохраняйте сообщение, а не только число 429.

Не диагностируйте Vertex только по AI Studio. Начните с Cloud-проекта, endpoint, локации, Quotas и статуса Provisioned Throughput. Если задача превратилась в выбор платформы, отделите ее с помощью сравнения Gemini API и Vertex AI.

Меняйте емкость в порядке доказанного воздействия

Начинайте с минимального и обратимого шага:

1. Уберите потери: кэшируйте дубли, сокращайте повторный контекст, останавливайте рекурсивный retry, отменяйте ненужные запросы.
2. Сформируйте спрос: очереди, предел параллелизма по проекту/модели, резерв для interactive.
3. Выберите допустимый режим: офлайн в Batch; Priority только при подходящем контракте и запасе.
4. Измените форму работы: более легкая подходящая модель, разбиение входа, сокращение ненужного вывода.
5. Исправьте финансового владельца: баланс, правильный cap, ожидание квалификации уровня.
6. Получите емкость: запросите увеличение или используйте правильный Vertex-контракт, если нужны Cloud-контроли.
7. Диверсифицируйте после диагноза: multi-model fallback оправдан, когда концентрация у одного поставщика доказана как риск.

Для последнего случая можно оценить шлюз вроде laozhang.ai. Он не увеличивает квоту Google-проекта. До production проверьте эквивалентность модели, таймаут, переключение, идемпотентность, обработку данных, наблюдаемость и стоимость. Непроверенные цена, покрытие моделей, скорость и uptime не являются обещаниями.

После изменения измеряйте тот же контроль на том же проекте, модели и представительской нагрузке. Успех deploy не доказывает восстановление. Нужны снижение 429, стабильная задержка, отсутствие дублей и ожидаемые request/token metrics.

Часто задаваемые вопросы

Где посмотреть текущие лимиты Gemini API?

В AI Studio выберите тот же проект и модель. Публичные страницы объясняют RPM, входные TPM, RPD, уровни и режимы, но не гарантируют фактическое значение аккаунта.

Лимиты считаются по ключу или проекту?

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

Когда сбрасывается RPD?

По текущей документации — в полночь по тихоокеанскому времени. Сначала докажите, что исчерпан именно RPD: у RPM, TPM, spend, Firebase и Vertex другие окна.

Почему включение биллинга не убрало 429?

Потому что остаются RPM, входные TPM, RPD, rolling spend, два cap, Priority, модельная квота и Prepay balance. Их проверяют отдельно.

Priority всегда добавляет емкость?

Нет. Это отдельный допустимый контракт с собственным пределом, который также учитывается в interactive traffic. Проверьте оба живых запаса.

Batch обходит интерактивные ограничения?

У него отдельные пределы, но он не безлимитен. Есть concurrent jobs, файлы, хранилище и queued tokens; работа должна принимать асинхронность до 24 часов.

Нужно ли повторять любой 429?

Нет. Повтор полезен только тогда, когда ожидание или форма нагрузки изменит владельца. Он не создает RPD, деньги или квоту.

Что отправить поддержке при расхождении ошибки и usage?

Полное тело ответа, время и пояс, project ID, модель, endpoint, режим, размер входа, параллелизм и usage того же интервала. Удалите ключ и данные пользователей. Для других кодов используйте полную карту ошибок Gemini API.

Одно правило для эксплуатации

Назовите продукт, метрику, область агрегации, режим обработки и действие до изменения кода, оплаты или архитектуры. Проверьте живого владельца, измените один влияющий рычаг и повторите ту же нагрузку. Если жесткая граница осталась, прекратите retry: ждите правильный сброс, уменьшайте спрос, выбирайте допустимый режим или получайте емкость.