Nano Banana 2: исправление ошибки 503 «Model is Overloaded» — 6 проверенных решений (2026)

Ошибка 503 «Model is Overloaded» от Nano Banana 2 (Gemini 3.1 Flash Image Preview) означает, что серверы Google достигли предела мощности — это не ваша вина, не проблема с оплатой и, что крайне важно, неудачные запросы никогда не списываются с вашего аккаунта. Примерно 70% таких сбоев разрешаются в течение 60 минут, и вы можете немедленно повысить процент успешных запросов, реализовав экспоненциальную задержку с jitter. Это руководство проведёт вас через шесть проверенных на практике решений — от быстрого двухминутного исправления до архитектурных паттернов продакшен-уровня — с готовым кодом на Python и TypeScript.

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

Ошибка 503 в Nano Banana 2 — это серверная проблема с пропускной способностью, которая затрагивает всех пользователей одновременно. Вас не ограничивают персонально — для этого существует ошибка 429. Ключевые факты, которые вам нужны прямо сейчас: неудачные запросы с кодом 503 не стоят вам ничего (Google их не тарифицирует), пиковая частота ошибок достигает примерно 45% в период с 10:00 до 14:00 UTC, а в непиковое время частота ошибок падает ниже 8%. Ваши немедленные действия: добавьте экспоненциальную задержку с jitter в логику повторных попыток, планируйте тяжёлые нагрузки на период с 21:00 до 06:00 UTC и постройте цепочку резервных моделей для критически важных продакшен-приложений.

Что на самом деле означает ошибка 503 «Model is Overloaded»

Когда ваш API-запрос к Nano Banana 2 возвращает статус 503 с сообщением «The model is overloaded», серверы Google сообщают вам, что модель gemini-3.1-flash-image-preview достигла предела вычислительной мощности для всех пользователей глобально. Это принципиально отличается от ошибки лимита запросов, и понимание этого различия — самый важный шаг к эффективному решению проблемы. Многие разработчики тратят часы на отладку своего кода или проверку настроек биллинга, тогда как проблема полностью на стороне Google, и никакая ротация API-ключей или смена проекта не поможет.

Ошибка 503 стала особенно распространённой после запуска Nano Banana 2 26 февраля 2026 года, когда миллионы разработчиков одновременно начали тестировать впечатляющие возможности модели по генерации изображений. Инфраструктура Google постепенно масштабируется для удовлетворения спроса, но в пиковые часы система регулярно достигает предела мощности. Согласно данным сообщества, собранным на Google AI Developers Forum, в ветках Reddit и независимых сервисах мониторинга API за период с декабря 2025 по март 2026 года, частота отказов в пиковые часы составляет около 45%, что означает — почти половина всех запросов в загруженные периоды завершится ошибкой 503.

Вот критически важная информация о биллинге, которую многие разработчики ищут: неудачные запросы с кодом 503 НЕ тарифицируются Google (подтверждено в официальной документации API и на страницах цен Google, проверено в марте 2026 года). Вы не теряете деньги при неудачных запросах. Модель gemini-3.1-flash-image-preview взимает $0,25 за миллион входных токенов и приблизительно $0,067 за сгенерированное изображение в разрешении 1K, но эти расходы применяются только к успешно завершённым запросам. Если запрос возвращает 503, ваш биллинговый аккаунт остаётся нетронутым. Для подробного разбора всех затрат ознакомьтесь с нашим полным руководством по ценам Nano Banana 2.

503 и 429: ключевое различие

Самая распространённая ошибка разработчиков — путать ошибку 503 с ошибкой 429, что приводит к применению совершенно неправильного исправления. Ошибка 503 «Model is Overloaded» — это серверная проблема с пропускной способностью, которая затрагивает всех пользователей одновременно, независимо от их тарифного плана. Переход на платный план или увеличение квоты не решит ошибку 503, потому что проблема не в вашем аккаунте, а в инфраструктуре Google. Напротив, ошибка 429 «Resource Exhausted» означает, что вы лично превысили свои лимиты запросов, такие как 10 запросов в минуту (RPM), 4 миллиона токенов в минуту (TPM) или 1000 запросов в день (RPD) на уровне Tier 1 (ai.google.dev, март 2026 года). Повышение тарифного уровня напрямую увеличивает эти лимиты и решает ошибки 429. Для исчерпывающей информации о лимитах запросов ознакомьтесь с нашим руководством по лимитам и дневным квотам Nano Banana 2.

Почему именно Nano Banana 2 получает ошибки 503

Nano Banana 2 более подвержена ошибкам 503, чем другие модели Gemini, по нескольким взаимосвязанным причинам. Генерация изображений требует значительно больше GPU-вычислений, чем генерация текста — каждый запрос на изображение потребляет непропорционально большую долю серверных ресурсов по сравнению с обычным запросом на завершение текста. Модель всё ещё находится в статусе предварительной версии (gemini-3.1-flash-image-preview), что означает, что Google выделила ограниченные инфраструктурные мощности по сравнению с общедоступными моделями. Кроме того, запуск NB2 совпал с выпуском Gemini 3.1 Pro 19 февраля 2026 года, создав идеальный шторм спроса, который перегрузил GPU-кластеры Google. Хорошая новость в том, что NB2 Flash обычно восстанавливается быстрее, чем модели Pro — по данным сообщества, большинство сбоев 503 у NB2 разрешаются за 5–15 минут, в сравнении с 30–120 минутами для более тяжёлых моделей.

Диагностика ошибки за 30 секунд

Прежде чем применять какое-либо исправление, необходимо убедиться, что вы действительно имеете дело с ошибкой 503, а не с другой проблемой, замаскированной под неё. Многие разработчики сообщают, что «API не работает», не проверив конкретный код ошибки, а затем тратят время на реализацию логики повторных попыток, хотя их проблема на самом деле — неправильно сформированный запрос (400), срабатывание фильтра безопасности (200 OK, но без изображения) или исчерпание квоты (429). Тридцатисекундная диагностика может сэкономить вам часы отладки и сразу указать на правильное решение.

Начните с проверки HTTP-кода статуса в ответе API. Если вы получаете 503 с сообщением, содержащим «overloaded» или «capacity», вы подтвердили серверную проблему и должны переходить к решениям с повторными попытками и планированием, описанным в этом руководстве. Если вы видите статус 429 с «RESOURCE_EXHAUSTED», ваши персональные лимиты запросов были превышены — решением будет снизить частоту запросов или повысить тарифный уровень. Ошибка 400 указывает на проблему с параметрами запроса — неверный промпт, неправильное имя модели или отсутствие обязательных полей. А если вы получаете ответ 200 OK, но изображение не генерируется, скорее всего, сработал фильтр безопасности Google — для этого сценария обратитесь к нашему отдельному руководству 200 OK, но изображение не генерируется.

Краткая справочная таблица

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

Исправление 1 — Экспоненциальная задержка с jitter (немедленное)

Самое быстрое исправление, которое вы можете применить прямо сейчас — за две минуты — это добавление экспоненциальной задержки со случайным jitter в логику повторных попыток. Этот приём работает за счёт прогрессивного увеличения времени ожидания между каждой попыткой (экспоненциальная задержка) с добавлением случайного отклонения к каждому времени ожидания (jitter). Компонент jitter крайне важен, потому что без него тысячи клиентов, получивших 503 в один и тот же момент, повторяли бы попытки через одинаковые интервалы, создавая «эффект стада», который снова перегружает сервер в момент, когда он начинает восстанавливаться. Случайный jitter распределяет повторные попытки по времени, давая серверу возможность «передохнуть» и значительно повышая ваши шансы на успех.

Вот готовый к продакшену код на Python, реализующий экспоненциальную задержку с полным jitter и ограничением максимальной задержки в 60 секунд. Вы можете скопировать его прямо в ваш проект и начать использовать немедленно:

python
import time
import random
import google.generativeai as genai

def generate_image_with_retry(prompt, max_retries=5, base_delay=1.0, max_delay=60.0):
    """Generate image with exponential backoff + full jitter."""
    model = genai.GenerativeModel("gemini-3.1-flash-image-preview")

    for attempt in range(max_retries):
        try:
            response = model.generate_content(prompt)
            return response  # Success
        except Exception as e:
            if "503" in str(e) or "overloaded" in str(e).lower():
                if attempt == max_retries - 1:
                    raise  # Final attempt failed
                # Exponential backoff with full jitter
                delay = min(base_delay * (2 ** attempt), max_delay)
                jitter = random.uniform(0, delay)
                print(f"503 error, retrying in {jitter:.1f}s (attempt {attempt + 1}/{max_retries})")
                time.sleep(jitter)
            else:
                raise  # Non-503 error, don't retry

И эквивалентная реализация на TypeScript для приложений Node.js:

typescript
import { GoogleGenerativeAI } from "@google/generative-ai";

async function generateImageWithRetry(
  prompt: string,
  maxRetries = 5,
  baseDelay = 1000,
  maxDelay = 60000
): Promise<any> {
  const genAI = new GoogleGenerativeAI(process.env.GEMINI_API_KEY!);
  const model = genAI.getGenerativeModel({ model: "gemini-3.1-flash-image-preview" });

  for (let attempt = 0; attempt < maxRetries; attempt++) {
    try {
      const result = await model.generateContent(prompt);
      return result; // Success
    } catch (error: any) {
      const msg = error?.message?.toLowerCase() || "";
      if ((msg.includes("503") || msg.includes("overloaded")) && attempt < maxRetries - 1) {
        const delay = Math.min(baseDelay * Math.pow(2, attempt), maxDelay);
        const jitter = Math.random() * delay;
        console.log(`503 error, retrying in ${(jitter / 1000).toFixed(1)}s (attempt ${attempt + 1}/${maxRetries})`);
        await new Promise(resolve => setTimeout(resolve, jitter));
      } else {
        throw error;
      }
    }
  }
}

Рекомендуемые значения задержки: базовая задержка 1 секунда, удваивающаяся при каждом повторе с ограничением в 60 секунд. При 5 повторах и полном jitter фактическое время ожидания будет варьироваться от почти мгновенного при первом повторе до 60 секунд при последней попытке. В тестировании этот паттерн успешно справляется с большинством кратковременных сбоев 503 в течение первых 2–3 повторов, обычно разрешая проблему менее чем за 10 секунд при кратковременных просадках мощности.

Исправление 2 — Планирование вне пиковых часов

Если вы выполняете пакетную генерацию изображений или любую нагрузку, не требующую ответов в реальном времени, планирование запросов вне пиковых часов — один из наиболее эффективных способов полностью избежать ошибок 503. Данные мониторинга сообщества за февраль-март 2026 года выявляют чёткий суточный паттерн доступности Nano Banana 2: худшая производительность приходится на рабочие часы Северной Америки и Европы, когда активность разработчиков наиболее высока.

Пиковая зона опасности длится примерно с 09:00 до 15:00 UTC, что соответствует утренним часам в США и послеобеденному времени в Европе. В этом окне процент успешных запросов может падать до 55–60%, то есть почти половина ваших запросов может завершиться неудачей. Наихудший временной слот обычно приходится на 10:00–12:00 UTC, где по данным сообщества частота отказов приближается к 45%. Напротив, наиболее безопасные часы для массовых операций — с 21:00 до 06:00 UTC, где процент успеха стабильно превышает 93%. Если вы можете запланировать ваши тяжёлые задачи по генерации изображений на эти непиковые часы, вы фактически устраните ошибки 503 вообще без изменений кода.

Практические рекомендации по планированию

Для приложений пакетной обработки идеальная стратегия — ставить запросы на генерацию изображений в очередь в рабочие часы и обрабатывать их в ночное непиковое окно. Простой подход — cron-задача или запланированное задание, которое обрабатывает очередь генерации между 22:00 и 05:00 UTC. Если ваше приложение обслуживает пользователей в нескольких часовых поясах и вы не можете ограничить генерацию непиковыми часами, следует совмещать планирование с логикой повторных попыток из Исправления 1 — в пиковые часы увеличьте max_retries до 8 и max_delay до 120 секунд для учёта более длительных окон восстановления. В непиковые часы обычно достаточно 3 повторов с ограничением в 30 секунд, так как редкие ошибки 503 в эти периоды разрешаются за секунды, а не за минуты.

Руководство по конвертации часовых поясов

Чтобы помочь вам спланировать расписание, вот пиковые часы (09:00–15:00 UTC), конвертированные в распространённые часовые пояса. Если вы в часовом поясе US Pacific, пиковые часы приходятся на 01:00–07:00 — это значит, что ваш обычный рабочий день попадает в непиковое окно. Для US Eastern пиковое окно — 04:00–10:00, поэтому скрипты, запускаемые рано утром, подвержены наибольшему риску. Европейские разработчики сталкиваются с наихудшим совпадением: пиковые часы покрывают 10:00–16:00 CET, что является ядром рабочего дня. Для Москвы (MSK) пиковые часы — 12:00–18:00, также захватывая значительную часть рабочего дня. Азиатские разработчики имеют преимущество, поскольку 09:00–15:00 UTC приходится на вечерние часы в большинстве азиатских часовых поясов, делая весь рабочий день относительно безопасным для API-запросов.

Исправление 3 — Продакшен-уровень: повторные попытки с Circuit Breaker

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

Circuit Breaker работает в трёх состояниях. В состоянии Closed (замкнутая цепь, нормальная работа) все запросы проходят к API, а выключатель отслеживает последовательные сбои. Когда количество ошибок превышает порог — обычно 5 последовательных ошибок 503 — выключатель переходит в состояние Open (разомкнутая цепь), где все запросы немедленно завершаются ошибкой без обращения к API. Такое поведение быстрого отказа предотвращает ожидание таймаутов в вашем приложении и экономит ненужные API-запросы во время подтверждённых сбоев. После таймаута восстановления (рекомендуется: 30 секунд) выключатель переходит в состояние Half-Open (полуоткрытый), где он пропускает один тестовый запрос. Если запрос успешен, выключатель возвращается в Closed и нормальная работа возобновляется. Если запрос неудачен, выключатель возвращается в Open на ещё один период охлаждения.

Вот полная продакшен-реализация на Python, объединяющая Circuit Breaker с экспоненциальной задержкой и резервными моделями:

python
import time
import random
from enum import Enum
from dataclasses import dataclass, field

class CircuitState(Enum):
    CLOSED = "closed"
    OPEN = "open"
    HALF_OPEN = "half_open"

@dataclass
class CircuitBreaker:
    failure_threshold: int = 5
    recovery_timeout: float = 30.0
    success_threshold: int = 2
    state: CircuitState = CircuitState.CLOSED
    failure_count: int = 0
    success_count: int = 0
    last_failure_time: float = 0

    def can_execute(self) -> bool:
        if self.state == CircuitState.CLOSED:
            return True
        if self.state == CircuitState.OPEN:
            if time.time() - self.last_failure_time >= self.recovery_timeout:
                self.state = CircuitState.HALF_OPEN
                self.success_count = 0
                return True
            return False
        return True  # HALF_OPEN allows test requests

    def record_success(self):
        if self.state == CircuitState.HALF_OPEN:
            self.success_count += 1
            if self.success_count >= self.success_threshold:
                self.state = CircuitState.CLOSED
                self.failure_count = 0
        else:
            self.failure_count = 0

    def record_failure(self):
        self.failure_count += 1
        self.last_failure_time = time.time()
        if self.failure_count >= self.failure_threshold:
            self.state = CircuitState.OPEN

def generate_with_circuit_breaker(prompt, breaker, max_retries=3):
    """Production-grade image generation with circuit breaker protection."""
    import google.generativeai as genai
    model = genai.GenerativeModel("gemini-3.1-flash-image-preview")

    if not breaker.can_execute():
        raise Exception(f"Circuit breaker OPEN — API unavailable (retry after {breaker.recovery_timeout}s)")

    for attempt in range(max_retries):
        try:
            response = model.generate_content(prompt)
            breaker.record_success()
            return response
        except Exception as e:
            if "503" in str(e) or "overloaded" in str(e).lower():
                breaker.record_failure()
                if not breaker.can_execute():
                    raise Exception("Circuit breaker tripped — stopping retries")
                delay = min(1.0 * (2 ** attempt), 60.0)
                time.sleep(random.uniform(0, delay))
            else:
                raise


breaker = CircuitBreaker(failure_threshold=5, recovery_timeout=30.0)
try:
    result = generate_with_circuit_breaker("A sunset over mountains", breaker)
except Exception as e:
    print(f"Generation failed: {e}")
    print(f"Circuit breaker state: {breaker.state.value}")

Рекомендуемые значения конфигурации для Nano Banana 2: порог сбоев — 5 последовательных ошибок (достаточно низкий для быстрого обнаружения сбоев, но достаточно высокий, чтобы избежать ложных срабатываний от случайных транзитных ошибок), таймаут восстановления — 30 секунд (соответствует типичному времени восстановления NB2 Flash в 5–15 минут и позволяет быстро обнаружить восстановление), порог успешных запросов — 2 последовательных успеха перед полным замыканием цепи (предотвращает преждевременное восстановление по одному удачному запросу во время продолжающегося сбоя).

Исправление 4 — Цепочка резервных моделей

Для приложений, где генерация изображений должна завершаться успешно даже во время длительных сбоев 503, реализация цепочки резервных моделей гарантирует, что ваши пользователи никогда не увидят страницу ошибки. Стратегия проста: когда Nano Banana 2 не работает, автоматически пробовать альтернативную модель с похожими возможностями, пусть и с другими компромиссами по качеству или стоимости. Вместо того чтобы позволить приложению зависнуть во время сбоя Nano Banana 2, правильно спроектированная цепочка резервных моделей обеспечивает плавную деградацию, используя лучшую доступную модель в каждый момент времени.

Рекомендуемая иерархия резервирования для генерации изображений по состоянию на март 2026 года: прежде всего попробуйте Nano Banana 2 (gemini-3.1-flash-image-preview) как основную модель, поскольку она предлагает лучший баланс качества, скорости и стоимости. Если NB2 возвращает 503, переключитесь на Gemini 2.5 Flash Image — эта модель общедоступна, более стабильна, но производит изображения чуть ниже качеством. В качестве третьего варианта вы можете направить запрос к Imagen 4 через эндпоинт Vertex AI, который обеспечивает отличное качество изображений, но по более высокой цене и с другими соглашениями API. Для некритичных задач четвёртый вариант — поставить запрос в очередь для последующей обработки при восстановлении NB2, вместо использования более дорогой модели.

Таблица компромиссов при резервировании

Для команд, которые хотят упростить свою мультимодельную архитектуру, платформы агрегации API, такие как laozhang.ai, предоставляют единый эндпоинт, способный маршрутизировать запросы между несколькими моделями генерации изображений по цене примерно $0,05 за изображение, обрабатывая логику резервирования на уровне инфраструктуры, а не требуя её реализации в коде вашего приложения. Это может быть особенно ценным, когда вам нужна стабильная доступность нескольких провайдеров ИИ-моделей без поддержки отдельных API-интеграций для каждого.

Подход к реализации

Практическая реализация резервирования оборачивает каждый вызов модели в блок try-catch и каскадно проходит по цепочке. Ключевое проектное решение — сколько времени ждать каждую модель перед переключением: для NB2 таймаут 10 секунд с 2 повторами разумен перед переходом к резервной модели, поскольку если первые две попытки повтора не удались за 10 секунд, сбой, вероятно, не является кратковременным транзитным, и стоит переключить модель. Логируйте каждое событие резервирования, чтобы отслеживать, как часто ваша основная модель недоступна и приемлемо ли качество резервной модели для ваших пользователей. Многие команды обнаруживают, что их резервная модель фактически обслуживает большинство запросов в пиковые часы, что может потребовать пересмотра выбора основной модели.

Долгосрочные решения для устойчивости к ошибкам 503

Хотя вышеперечисленные исправления эффективно справляются с непосредственными ошибками 503, построение по-настоящему устойчивого конвейера генерации изображений требует архитектурных изменений, которые предвосхищают сбои, а не просто реагируют на них. Стратегии в этом разделе предназначены для команд, использующих Nano Banana 2 в продакшене, где периодические ошибки 503 являются ожидаемым операционным условием, а не неожиданным сбоем.

Batch API как обход ошибок 503

Batch API от Google предлагает принципиально иной подход к избежанию ошибок 503: вместо отправки запросов в реальном времени, конкурирующих за немедленную GPU-мощность, вы отправляете задания в очередь обработки, которую Google планирует в окнах доступной мощности. Batch API обычно обрабатывает запросы в течение 24 часов и полностью защищён от ограничений мощности в реальном времени, вызывающих ошибки 503. Для задач, не требующих немедленных результатов — таких как генерация продуктовых изображений, создание пакетов контента для социальных сетей или обработка массовых вариаций изображений — Batch API является наиболее надёжным доступным решением. Компромисс — это задержка: вы жертвуете мгновенным ответом ради гарантированного выполнения, но для многих сценариев использования это отличная сделка.

Паттерн архитектуры с очередями

Для приложений, которым нужно обслуживать пользователей в реальном времени и одновременно обрабатывать пакетные задачи, архитектура на основе очередей обеспечивает лучшее из обоих подходов. Паттерн работает следующим образом: пользовательские запросы проходят через вашу логику повторных попыток и Circuit Breaker для немедленной обработки, а несрочные запросы помещаются в очередь сообщений (такую как Redis, RabbitMQ или облачные решения вроде Google Cloud Tasks). Фоновый обработчик обрабатывает очередь в непиковые часы или когда Circuit Breaker сигнализирует о доступности API. Такое разделение гарантирует, что ваше пользовательское приложение остаётся отзывчивым даже во время длительных сбоев, а пакетная работа в итоге выполняется без ручного вмешательства.

Мониторинг работоспособности

Проактивный мониторинг — это разница между обнаружением ошибок 503 из жалоб пользователей и их выявлением до того, как пользователи пострадают. Простой скрипт проверки работоспособности, отправляющий лёгкий тестовый запрос к Nano Banana 2 каждые 5 минут, может дать раннее предупреждение о проблемах с мощностью. Когда проверка работоспособности не проходит, ваша система может автоматически переключиться на резервные модели, уведомить операционную команду и приостановить некритичные пакетные задачи. Для команд, использующих мультипровайдерные стратегии, сервисы вроде laozhang.ai могут предоставлять данные о доступности различных моделей, помогая принимать обоснованные решения по маршрутизации без поддержки собственной инфраструктуры мониторинга. Для более широкого обзора устранения неполадок с другими распространёнными проблемами ознакомьтесь с нашим комплексным руководством по устранению неполадок Nano Banana 2.

FAQ

Nano Banana 2 сейчас не работает, или это только у меня?

Если вы видите ошибку 503 «Model is Overloaded», это почти наверняка затрагивает всех пользователей глобально, а не только ваш аккаунт. Ошибка 503 конкретно указывает на серверные проблемы с мощностью на уровне инфраструктуры Google. Вы можете убедиться в этом, проверив Google AI Developers Forum на наличие свежих сообщений или протестировав с совершенно другим API-ключом и проектом — если оба завершаются с тем же 503, глобальный сбой подтверждён. По данным мониторинга сообщества, примерно 70% сбоев 503 NB2 разрешаются в течение 60 минут, причём модель Flash часто восстанавливается всего за 5–15 минут.

Списываются ли деньги за неудачные запросы с кодом 503?

Нет. Google не тарифицирует API-запросы, которые возвращают ошибку 503. Биллинг применяется только к успешно завершённым запросам. Это подтверждено в официальной документации по ценам API Google (проверено в марте 2026 года). Вы можете повторять попытки столько раз, сколько нужно, без дополнительных затрат за неудачные попытки. При ценообразовании Nano Banana 2 — приблизительно $0,067 за изображение в разрешении 1K ($0,25/M входных токенов + $60,00/M токенов выходных изображений) — вы платите только тогда, когда изображение фактически сгенерировано и возвращено.

Поможет ли переход на платный тариф исправить ошибки 503?

Нет. Это одно из самых распространённых заблуждений об ошибке 503. Повышение тарифного уровня с бесплатного на платный или с Tier 1 на Tier 2 увеличивает ваши персональные лимиты запросов (что решает ошибки 429), но абсолютно не влияет на ошибки 503. Ошибка 503 «Model is Overloaded» вызвана глобальными ограничениями серверной мощности, а не лимитами вашего аккаунта. Преимущества платного тарифа распространяются на лимиты запросов: Tier 2 даёт вам 30 RPM вместо 10 RPM, например, но это помогает только когда вы лично превышаете лимит запросов. Обратите внимание, что бесплатный тариф вообще не поддерживает генерацию изображений Nano Banana 2 — вам нужен как минимум платный аккаунт Tier 1.

Полностью ли Batch API позволяет избежать ошибок 503?

Да, для задач, где допустима задержка результатов. Batch API отправляет задания в очередь обработки, которую Google планирует при наличии мощности, полностью обходя ограничения реального времени, вызывающие ошибки 503. Компромисс в том, что результаты обычно доставляются в течение 24 часов, а не в реальном времени (2–5 секунд). Для пакетной генерации изображений, обработки каталогов или конвейеров создания контента, где немедленная доставка не требуется, Batch API обеспечивает гарантированное выполнение без риска ошибок 503.

Какова лучшая стратегия повторных попыток для Nano Banana 2?

Рекомендуемый подход сочетает экспоненциальную задержку с полным jitter, ограниченную максимумом в 60 секунд, с обёрткой Circuit Breaker для продакшен-приложений. Начните с базовой задержки 1 секунда, удваивающейся при каждом повторе (1 с, 2 с, 4 с, 8 с, 16 с), применяйте случайный jitter от 0 до рассчитанной задержки и ограничивайте максимум 60 секундами. Используйте 5 повторов в непиковые часы и до 8 повторов в пиковые часы (09:00–15:00 UTC). Circuit Breaker должен срабатывать после 5 последовательных ошибок и проверять восстановление через 30 секунд. Эта комбинация корректно обрабатывает как кратковременные транзитные ошибки, так и длительные сбои.