Исправление ошибки RESOURCE_EXHAUSTED в Nano Banana Pro: полное руководство 2026 года с рабочим кодом

Ошибка RESOURCE_EXHAUSTED в Nano Banana Pro — это самая распространённая проблема, с которой сталкиваются разработчики при создании приложений для генерации изображений на основе Gemini API от Google. Она составляет примерно 70% всех ошибок Nano Banana API. Код состояния HTTP 429 означает, что ваше приложение превысило один или несколько лимитов — будь то количество запросов в минуту (RPM), токенов в минуту (TPM) или запросов в день (RPD). Хорошая новость: эта ошибка полностью устранима при правильном сочетании логики повторных запросов, управления тарифными уровнями и архитектурных паттернов. В этом руководстве вы найдёте всё необходимое — от быстрых исправлений за 30 секунд до готового продакшен-кода на Python и Node.js.

Краткое содержание — Справочник по быстрому исправлению

Если ваше приложение на базе Nano Banana Pro прямо сейчас выдаёт ошибки RESOURCE_EXHAUSTED, вот самый быстрый путь к решению. Начните с определения точного типа ошибки, а затем примените соответствующее исправление.

Чек-лист быстрого исправления за 30 секунд:

1. Проверьте ответ ошибки — это 429 или 503? Они требуют разных решений.
2. Если 429: откройте панель использования Google AI Studio и проверьте, какой лимит превышен (RPM, TPM или RPD).
3. Если RPM/TPM: добавьте time.sleep(1) между запросами. Одно это устраняет большинство ошибок 429.
4. Если RPD: вы достигли дневного лимита. Подождите до полуночи по тихоокеанскому времени или включите биллинг для разблокировки лимитов, увеличенных в 60 раз.
5. Если 503: это проблема инфраструктуры Google, а не ваша. Реализуйте повторные запросы с задержкой 30–60 секунд.

Шпаргалка по лимитам (бесплатный уровень → Tier 1):

Самое значимое изменение, которое вы можете внести, — это включение биллинга в вашем проекте Google Cloud. Это мгновенно повышает вас с бесплатного уровня до Tier 1, разблокируя значительно более высокие лимиты без предоплаты — вы платите только за фактическое использование.

Что вызывает RESOURCE_EXHAUSTED в Nano Banana Pro

Понимание первопричины вашей конкретной ошибки критически важно, потому что применение неправильного исправления тратит время и не решает проблему. Ошибка RESOURCE_EXHAUSTED в Nano Banana Pro (официально Gemini 3 Pro Image Preview) имеет три принципиально разные причины, каждая из которых требует своего подхода к решению.

429 RESOURCE_EXHAUSTED — превышение квоты. Это наиболее распространённый вариант, возникающий, когда ваш проект превышает выделенный лимит в любом измерении. Google применяет лимиты на уровне проекта (а не на уровне API-ключа), что означает: если у вас несколько приложений или API-ключей в рамках одного проекта Google Cloud, они все используют один пул квот. Фактический ответ с ошибкой выглядит так:

json
{
  "error": {
    "code": 429,
    "message": "Resource has been exhausted (e.g. check quota).",
    "status": "RESOURCE_EXHAUSTED"
  }
}

Особенно запутывающим эту ошибку делает то, что вы можете укладываться в лимит RPM, но превышать лимит TPM, или быть в рамках и RPM, и TPM, но исчерпать дневную квоту RPD. Каждое измерение оценивается независимо, и превышение любого из них вызывает ошибку. Именно поэтому разработчики на форуме Google AI Developers Forum сообщают об ошибках 429, несмотря на уверенность, что они укладываются в лимиты — зачастую они просто смотрят не на ту метрику.

503 Service Unavailable — исчерпание серверных мощностей. Эта ошибка принципиально отличается от 429, потому что отражает перегрузку инфраструктуры Google, а не превышение вашей конкретной квоты. Даже клиенты уровня Tier 3 с максимальными квотами получают ошибки 503 в периоды пиковых нагрузок. Причина кроется в распределении вычислительных ресурсов Google: Nano Banana Pro работает на серии Gemini 3, которая всё ещё находится в статусе Pre-GA (Pre-General Availability), то есть Google выделил ограниченные мощности TPU v7 для этих моделей. Когда глобальный спрос превышает доступные вычислительные ресурсы, все получают ошибки 503 вне зависимости от тарифного уровня.

Периоды повышенного риска ошибок 503 совпадают с окнами пиковой нагрузки: примерно 00:00–02:00 UTC (вечер в США), 09:00–11:00 UTC (рабочие часы в Азии) и 20:00–23:00 UTC (вечер в Европе). Планирование пакетных задач генерации за пределами этих окон может значительно снизить количество ошибок 503.

Сокращение квот в декабре 2025 года. В декабре 2025 года Google незаметно уменьшил квоты бесплатного уровня, застав врасплох тысячи разработчиков. Приложения, стабильно работавшие месяцами, внезапно начали выдавать ошибки 429. RPM для Gemini 2.5 Pro был снижен с 10 до 5 (сокращение на 50%), а некоторые разработчики сообщали о падении эффективного RPD с 250 до 20 — ошеломляющее сокращение на 92%. Google также ужесточил алгоритмы контроля, превратив ранее мягко применяемые квоты в жёсткие лимиты. Если ваше приложение сломалось «без причины» примерно 7 декабря 2025 года, то почти наверняка причина именно в этом.

Полный справочник по лимитам — все уровни, все модели

Лимиты Nano Banana Pro зависят от тарифного уровня вашего проекта, который определяется статусом биллинга и совокупными расходами в Google Cloud. Понимание этих уровней необходимо для планирования мощностей генерации изображений и предотвращения ошибок RESOURCE_EXHAUSTED. Следующие данные взяты из официальной документации Google по лимитам (последнее обновление — 22 января 2026 года) и сверены с нашим полным справочником по лимитам Gemini API.

Требования и условия для каждого уровня:

Лимиты применяются на уровне проекта, а не API-ключа. Квота RPD сбрасывается в полночь по тихоокеанскому времени (00:00 PT). Эти лимиты также применяются к Batch API отдельно — пакетные запросы имеют собственный пул квот и не расходуют ваши лимиты реального времени.

Полная таблица лимитов по моделям и уровням:

Nano Banana Pro (Gemini 3 Pro Image Preview) следует структуре лимитов Gemini 3 Pro. Кроме того, модели генерации изображений имеют лимит IPM (Images Per Minute — изображений в минуту), который работает аналогично TPM. Точное значение IPM зависит от уровня и доступно в панели использования Google AI Studio.

Сравнение «до и после» декабря 2025 года:

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

Для запроса увеличения лимитов сверх текущего уровня отправьте запрос через официальную форму Google. Google заявляет, что «не даёт гарантий увеличения лимитов», но рассмотрит запросы. Для предсказуемых потребностей в высокой пропускной способности рассмотрите вариант Provisioned Throughput, который резервирует выделенные мощности для вашего проекта.

Рабочие решения на Python и Node.js

Наиболее эффективный способ обработки ошибок RESOURCE_EXHAUSTED — реализация правильной логики повторных запросов с экспоненциальным откатом и случайным разбросом. Ключевой момент: разные типы ошибок требуют разных стратегий повторных запросов. Ошибки 429 следует повторять быстро с нарастающей задержкой, а ошибки 503 требуют более длительных начальных задержек.

Решение на Python с библиотекой Tenacity:

python
import time
import random
from google import genai
from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception

client = genai.Client(api_key="YOUR_API_KEY")

def is_retryable(exception):
    """Only retry on 429 and 503 errors."""
    if hasattr(exception, 'code'):
        return exception.code in [429, 503]
    return False

@retry(
    stop=stop_after_attempt(5),
    wait=wait_exponential(multiplier=1, min=2, max=60),
    retry=retry_if_exception(is_retryable),
    before_sleep=lambda retry_state: print(
        f"Retry {retry_state.attempt_number}/5 "
        f"in {retry_state.next_action.sleep:.1f}s..."
    )
)
def generate_image(prompt, resolution="1024x1024"):
    """Generate image with automatic retry on rate limit errors."""
    response = client.models.generate_content(
        model="gemini-3-pro-image",
        contents=prompt,
        config={
            "response_modalities": ["IMAGE"],
            "image_resolution": resolution
        }
    )
    return response


def batch_generate(prompts, delay=1.0):
    """Generate multiple images with rate limiting."""
    results = []
    for i, prompt in enumerate(prompts):
        try:
            result = generate_image(prompt)
            results.append(result)
            if i < len(prompts) - 1:
                time.sleep(delay + random.uniform(0, 0.5))
        except Exception as e:
            print(f"Failed after retries: {e}")
            results.append(None)
    return results

Параметр wait_exponential с multiplier=1, min=2, max=60 означает, что первый повторный запрос ждёт 2 секунды, затем 4, 8, 16, до максимума в 60 секунд. Добавление случайного разброса (random.uniform(0, 0.5) в batch_generate) предотвращает проблему «грохочущего стада» (thundering herd), когда несколько клиентов повторяют запросы одновременно и снова перегружают API.

Решение на Node.js/TypeScript:

typescript
import { GoogleGenAI } from "@google/genai";

const client = new GoogleGenAI({ apiKey: "YOUR_API_KEY" });

async function sleep(ms: number): Promise<void> {
  return new Promise(resolve => setTimeout(resolve, ms));
}

async function generateWithRetry(
  prompt: string,
  maxRetries = 5,
  baseDelay = 2000
): Promise<any> {
  for (let attempt = 1; attempt <= maxRetries; attempt++) {
    try {
      const response = await client.models.generateContent({
        model: "gemini-3-pro-image",
        contents: prompt,
        config: {
          responseModalities: ["IMAGE"],
          imageResolution: "1024x1024"
        }
      });
      return response;
    } catch (error: any) {
      const code = error?.status || error?.code;

      if (code === 429 || code === 503) {
        if (attempt === maxRetries) throw error;

        const delay = Math.min(
          baseDelay * Math.pow(2, attempt - 1),
          60000
        );
        const jitter = Math.random() * 1000;

        console.log(
          `Attempt ${attempt}/${maxRetries} failed (${code}). ` +
          `Retrying in ${((delay + jitter) / 1000).toFixed(1)}s...`
        );

        await sleep(delay + jitter);
      } else {
        throw error; // Non-retryable error
      }
    }
  }
}

// Batch generation with rate limiting
async function batchGenerate(
  prompts: string[],
  delayMs = 1000
): Promise<any[]> {
  const results: any[] = [];
  for (const [i, prompt] of prompts.entries()) {
    try {
      const result = await generateWithRetry(prompt);
      results.push(result);
      if (i < prompts.length - 1) {
        await sleep(delayMs + Math.random() * 500);
      }
    } catch (error) {
      console.error(`Failed: ${error}`);
      results.push(null);
    }
  }
  return results;
}

Обе реализации используют один и тот же базовый паттерн: экспоненциальный откат со случайным разбросом, максимальное количество повторных попыток и фильтрацию по типу ошибки, чтобы не повторять неустранимые ошибки вроде 400 (неверный запрос) или 403 (ошибка аутентификации). Ключевое архитектурное решение — разделение обработки 429 (короткий откат, быстрое повторение) и 503 (более длинные задержки, потенциально ожидание минуты).

Обработка ошибок в зависимости от типа:

Для продакшен-систем необходимо разбирать ответ об ошибке, чтобы применять оптимальную стратегию повторных запросов:

python
def get_retry_delay(error, attempt):
    """Calculate retry delay based on error type."""
    if hasattr(error, 'code'):
        if error.code == 429:
            # Quota error: short exponential backoff
            return min(2 ** attempt + random.uniform(0, 1), 30)
        elif error.code == 503:
            # Server overload: longer delays
            return min(10 * (2 ** attempt) + random.uniform(0, 5), 120)
    return 5  # Default

Продвинутые стратегии для продакшена

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

Цепочка переключения моделей. Когда Nano Banana Pro стабильно возвращает ошибки, лучший вариант — не ждать, а перенаправить запрос на альтернативную модель. Google предлагает несколько моделей генерации изображений с разными ценами и уровнями надёжности. Грамотно спроектированная цепочка переключения перебирает модели в порядке предпочтения, пока одна из них не выполнит запрос:

python
FALLBACK_CHAIN = [
    {"model": "gemini-3-pro-image", "name": "Nano Banana Pro", "cost": 0.134},
    {"model": "gemini-2.5-flash-image", "name": "Flash Image", "cost": 0.039},
    {"model": "imagen-4-fast", "name": "Imagen 4 Fast", "cost": 0.02},
]

async def generate_with_fallback(prompt):
    """Try each model in the fallback chain."""
    for model_config in FALLBACK_CHAIN:
        try:
            result = await generate_with_retry(
                prompt,
                model=model_config["model"],
                max_retries=2  # Fewer retries per model
            )
            return {
                "result": result,
                "model_used": model_config["name"],
                "cost": model_config["cost"]
            }
        except Exception as e:
            print(f"{model_config['name']} failed: {e}")
            continue
    raise Exception("All models in fallback chain exhausted")

Такой подход означает, что пользователи никогда не увидят ошибку 429 — даже если Nano Banana Pro полностью ограничен лимитами, они всё равно получат изображение от Flash Image или Imagen 4 за считанные секунды. Компромисс заключается в качестве: Nano Banana Pro обеспечивает наивысшее качество, Flash Image быстрее, но с меньшим разрешением (максимум 1024x1024), а Imagen 4 Fast — самый дешёвый, но лишён контекстного понимания моделей Gemini.

Проактивный мониторинг с порогом оповещения 70%. Лучший способ обработки ошибок лимитов — их предотвращение. Отслеживая использование API в реальном времени и оповещая при достижении 70% квоты, вы получаете окно предупреждения для принятия мер до фактического возникновения ошибок:

python
import threading

class QuotaTracker:
    def __init__(self, rpm_limit, rpd_limit):
        self.rpm_limit = rpm_limit
        self.rpd_limit = rpd_limit
        self.minute_requests = 0
        self.daily_requests = 0
        self.lock = threading.Lock()

    def record_request(self):
        with self.lock:
            self.minute_requests += 1
            self.daily_requests += 1

            rpm_usage = self.minute_requests / self.rpm_limit
            rpd_usage = self.daily_requests / self.rpd_limit

            if rpm_usage >= 0.7:
                self.alert(f"RPM at {rpm_usage:.0%}")
            if rpd_usage >= 0.7:
                self.alert(f"RPD at {rpd_usage:.0%}")

    def alert(self, message):
        print(f"QUOTA WARNING: {message}")
        # Send Slack/email notification

Архитектура на основе очередей для пакетной обработки. Для приложений, генерирующих изображения массово (изображения товаров для электронной коммерции, маркетинговые материалы, пакетное создание контента), архитектура на основе очередей отделяет пользовательские запросы от вызовов API, позволяя точно контролировать частоту запросов. Кроме того, Batch API от Google работает в отдельном пуле квот с более высокими лимитами — до 100 параллельных пакетных запросов и до 3 миллионов токенов в очереди на модель для пользователей Tier 1.

Оптимизация затрат — когда повышать уровень, менять модель или использовать прокси

Понимание истинной стоимости ошибок RESOURCE_EXHAUSTED выходит за рамки цен на API — оно включает время разработчика на отладку, ухудшение пользовательского опыта и упущенные возможности, когда ваше приложение не работает. В этом разделе представлены конкретные расчёты затрат, которые помогут вам принять правильное инфраструктурное решение в зависимости от объёма.

Прямое сравнение стоимости API (за 1 000 изображений, февраль 2026):

Для разработчиков, которые часто упираются в лимиты бесплатного уровня, самый экономичный первый шаг — просто включить биллинг. Переход с бесплатного уровня на Tier 1 не требует предоплаты и мгновенно увеличивает лимиты в 30–60 раз. Вы платите только за фактическое использование API, и при стоимости $0,134 за изображение для Nano Banana Pro даже 100 изображений в месяц обойдутся всего в $13,40. Сравните это с часами, потраченными на отладку ошибок RESOURCE_EXHAUSTED, — платный уровень окупается за счёт сэкономленных нервов разработчика.

Для высоконагруженных приложений, генерирующих тысячи изображений ежемесячно, сторонние API-прокси предлагают альтернативный подход. Такие сервисы, как laozhang.ai, предоставляют доступ к той же модели Nano Banana Pro через унифицированный API с более высокими лимитами и без региональных ограничений, зачастую со значительной экономией за изображение для крупных объёмов. Этот подход особенно ценен, когда ваша основная задача — устранение ограничений лимитов, а не минимизация цены за изображение.

Прогноз затрат по объёмам:

При выборе между повышением тарифного уровня, сменой модели или использованием прокси учитывайте свои приоритеты. Если качество изображений первостепенно и вам нужно контекстное понимание Nano Banana Pro (редактирование существующих изображений, сохранение идентичности), повышение до Tier 2 (совокупные расходы $250) даст вам 1 000 RPM и 10 000 RPD. Если вам нужен большой объём при меньших затратах и вы готовы принять немного более низкое качество, Gemini 2.5 Flash Image по $0,039/изображение предлагает отличное соотношение цены и качества. Для команд, которым нужна гарантированная доступность без проблем с лимитами, наше руководство по доступным вариантам генерации изображений через Gemini рассматривает все доступные пути, а руководство по бесплатному уровню Gemini API поможет максимально использовать бесплатную квоту перед переходом на платный тариф.

Система принятия решений — ваш план действий

Принятие правильного решения о том, как обрабатывать ошибки RESOURCE_EXHAUSTED, зависит от трёх факторов: частоты ошибок, ежемесячного объёма и требований к качеству. Используйте эту систему для выбора оптимальной стратегии.

Шаг 1: Диагностика паттерна ошибок

Шаг 2: Выбор стратегии в зависимости от объёма

Для малого объёма (менее 100 изображений/месяц): включите биллинг, добавьте базовую логику повторных запросов, используйте задержку 1 секунду между запросами. Общие затраты на настройку: 30 минут плюс оплата по мере использования. Это устраняет 90% ошибок RESOURCE_EXHAUSTED.

Для среднего объёма (100–1 000 изображений/месяц): включите биллинг, реализуйте полный код повторных запросов из этого руководства, добавьте цепочку переключения моделей, настройте мониторинг квот. Общие затраты на настройку: 2–3 часа. Рассмотрите Tier 2, если вам нужна стабильная пропускная способность.

Для большого объёма (более 1 000 изображений/месяц): реализуйте полную продакшен-архитектуру (повторные запросы + переключение + очередь), подайте заявку на Tier 2 или Tier 3, рассмотрите Provisioned Throughput для гарантированной мощности, оцените сторонние прокси для обработки пиковых нагрузок. Общие затраты на настройку: 1–2 дня архитектурной работы. Для подробного сравнения Nano Banana Pro с другими API генерации изображений в таком масштабе ознакомьтесь с нашим полным сравнением Nano Banana Pro и FLUX.2.

Шаг 3: Чек-лист для быстрого принятия решения

FAQ

Почему я всё ещё получаю ошибки RESOURCE_EXHAUSTED на платном тарифе?

Платные уровни имеют более высокие лимиты, но они не безлимитные. Tier 1 обеспечивает 150–300 RPM в зависимости от модели, а это означает, что пакетная отправка 500 запросов за минуту всё равно вызовет ошибки 429. Кроме того, ошибки 503 затрагивают все уровни одинаково, поскольку отражают мощности инфраструктуры Google, а не вашу индивидуальную квоту. Решение — реализовать логику повторных запросов вне зависимости от тарифного уровня и рассмотреть Tier 2 или Tier 3, если вы стабильно упираетесь в лимиты Tier 1.

Как проверить, какой лимит я превысил?

Откройте Google AI Studio и перейдите на вкладку «Usage». Вы увидите потребление RPM, TPM и RPD. Превышенный лимит покажет 100% использования или красный индикатор. Помните, что лимиты привязаны к проекту — если у вас несколько API-ключей в рамках одного проекта, они используют одну и ту же квоту.

В чём разница между ошибками 429 и 503 для Nano Banana Pro?

Ошибка 429 означает, что ВАШ проект превысил выделенную квоту (RPM, TPM или RPD). Она специфична для вашего использования и может быть решена снижением частоты запросов или повышением тарифного уровня. Ошибка 503 означает, что СЕРВЕРЫ Google перегружены — весь сервис Nano Banana Pro испытывает высокую нагрузку. Никакое повышение уровня или снижение частоты запросов не исправит ошибку 503; нужно подождать, пока освободятся мощности, или переключиться на другую модель.

Могу ли я использовать Batch API для предотвращения ошибок RESOURCE_EXHAUSTED?

Да, частично. Batch API имеет собственный отдельный пул квот (до 100 параллельных пакетных запросов, 3–5 миллионов токенов в очереди для Tier 1), поэтому не расходует квоту вашего API реального времени. Однако Batch API предназначен для задач, не требующих мгновенного ответа — результаты обрабатываются асинхронно и могут занять от нескольких минут до часов. Он идеально подходит для фоновых задач генерации изображений, но не для интерактивных приложений, которым нужен немедленный отклик.

Увеличит ли Google лимиты Nano Banana Pro в будущем?

Google не объявлял конкретных сроков увеличения лимитов Nano Banana Pro. Модель в настоящее время находится в статусе Pre-GA (Pre-General Availability), что означает ограниченное выделение вычислительных мощностей. Отраслевой анализ предполагает, что улучшения могут прийти с завершением развёртывания TPU v7 (ожидается к середине 2026 года) и окончанием фаз обучения серии Gemini 3.0. В то же время стратегии из этого руководства — повышение тарифного уровня, логика повторных запросов, переключение моделей и сторонние прокси — обеспечивают надёжные обходные пути для текущих ограничений.