Nano Banana Pro API: официальный ID модели, цены, лимиты и быстрый старт

По состоянию на 27 марта 2026 года Nano Banana Pro API означает Google-модель gemini-3-pro-image-preview. Если вы строите новую интеграцию, безопасный дефолтный выбор — начать с нативного Gemini-маршрута генерации изображений, а не с чужого алиаса и не с OpenAI-совместимого слоя Gemini по умолчанию. Слой совместимости имеет смысл тогда, когда у вас уже есть OpenAI-подобный клиент и главная задача — сократить объём переписывания.

Это правильный порядок потому, что SERP по этому запросу всё ещё очень фрагментирован. Страницы на первой странице охотно ставят в заголовок Nano Banana Pro API, цены и короткие curl-примеры, но часто не объясняют официальный ID модели, требование к paid tier и то, где именно смотреть ваши реальные лимиты. У Google более надёжный ответ, но он размазан между документацией по image generation, документацией по OpenAI compatibility, страницей pricing и страницей rate limits.

Поэтому самый безопасный способ работать с этим запросом — сначала решить вопрос маршрута. Подтвердите официальное имя модели, выберите правильную поверхность API, затем проверьте биллинг и реальные лимиты проекта. Только после этого имеет смысл сравнивать relay-провайдеров или копировать пример из чужого playground.

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

Если следующий вопрос у вас уже не про маршрут, а про цену, переходите к Nano Banana Pro API Pricing. Если важнее получить ключ доступа, используйте Nano Banana Pro API Key. Если нужен более общий нативный REST-маршрут, пригодится Gemini Image Generation REST API.

Nano Banana Pro API — это публичное имя, а не официальный ID модели Google

Первое, что нужно исправить в этом запросе, — путаница в названиях. Nano Banana Pro — это публичный продуктовый nickname для премиальной image-линии Gemini 3, но официальный API ID модели — gemini-3-pro-image-preview. В текущей документации по image generation Google явно даёт такую карту:

• Nano Banana 2 = gemini-3.1-flash-image-preview
• Nano Banana Pro = gemini-3-pro-image-preview
• Nano Banana = gemini-2.5-flash-image

На вид это маленькая деталь, но именно из-за неё люди неверно читают почти каждую страницу в топе. Многие провайдеры используют собственные алиасы вроде nano-banana-pro, и внутри их шлюза это может работать. Но это не каноническая строка модели Google. Если вы вставите такой алиас в прямой запрос к Google, то начнёте отладку не с того уровня.

Текущий changelog у Google говорит, что gemini-3-pro-image-preview был выпущен 20 ноября 2025 года. Эта дата важна, потому что множество старых страниц до сих пор смешивают ранние названия, legacy image-линии 2.5 и расплывчатые формулировки вроде Gemini 3.0 Pro.

Важно и то, как Google сам позиционирует модель. Страница DeepMind описывает Nano Banana Pro как image-модель Gemini 3 для студийной точности и контроля. Документация по image generation добавляет, что модель рассчитана на профессиональное производство визуальных активов и сложные инструкции, а семейство Gemini 3 image умеет смешивать до 14 reference images, причём точные ограничения по объектам и персонажам зависят от модели. Google также прямо говорит, что все сгенерированные изображения получают SynthID.

Итоговая ментальная модель должна быть такой:

• Nano Banana Pro — это product-facing nickname.
• gemini-3-pro-image-preview — это строка, которую нужно использовать в официальной API-работе.
• Сторонние страницы могут показывать другие алиасы, но это wrapper-уровень, а не каноническое имя первой стороны.

Когда это прояснено, следующий практический вопрос становится очевидным: по какому API-маршруту вам реально стоит идти?

С какого API-маршрута лучше начинать?

Для большинства читателей ответ простой: начинайте с нативного Gemini API-маршрута. Это лучший дефолт, если вы только знакомитесь с моделью, работаете с raw HTTP, идёте по официальной документации или пытаетесь получить первый успешный ответ.

Причина здесь не в идеологии, а в ясности. Текущее руководство по image generation учит выдаче изображений через нативный контракт Gemini generateContent. Именно там наиболее прямо объяснены mapping модели, размеры изображения, aspect ratio и текущие image-линии Gemini 3. Если вам нужен кратчайший путь от “я ввёл запрос в поиск” до “я отправил корректный запрос Google”, это самая чистая поверхность.

Gemini OpenAI-compatible route существует и документирован Google на странице OpenAI compatibility. Через client.images.generate можно генерировать изображения моделью gemini-3-pro-image-preview, и это удобно, когда у вас уже есть приложение с OpenAI-подобным клиентом и вы не хотите разматывать существующие SDK-привычки. Но как дефолт для новой интеграции этот путь хуже, потому что он прячет нативный контракт Gemini за слоем совместимости.

Надёжное разделение выглядит так:

• Начинайте с нативного Gemini, если вы учите официальный маршрут, строите интеграцию с нуля или дебажите сырые запросы.
• Начинайте с Gemini OpenAI compatibility, если главным требованием является сохранение OpenAI-формы клиента.
• Переходите к relay или provider gateway только после того, как понимаете официальную модель, официальную цену и биллинговую поверхность, которую вы абстрагируете.

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

Где на самом деле находятся биллинг, цены и лимиты

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

На странице billing Google пишет, что новые аккаунты Gemini API стартуют с Free Tier, а переход на Paid Tier требует привязки billing account и предоплаты минимум $10. Там же зафиксировано временное состояние prepay-to-postpay migration, начавшееся 23 марта 2026 года. Практический вывод прямой: нельзя считать получение API key полной настройкой. Даже если маршрут у вас правильный, изображение может не заработать или вести себя иначе, если биллинг проекта не приведён в нужное состояние.

Текущая официальная база цен со страницы pricing такая:

Именно эти числа нужно заякорить первыми, потому что почти каждая провайдерская страница на первой странице хочет, чтобы вы думали в терминах её обёрточного pricing ещё до того, как увидели официальный baseline Google. Как только у вас есть официальная база, сравнение relay становится осмысленным. Если ваш реальный следующий вопрос — “есть ли путь дешевле”, лучше сразу перейти к дешёвому API Nano Banana Pro, а не пытаться уместить весь decision tree в этой хаб-статье.

С лимитами больше всего вредят устаревшие страницы. Страница rate limits у Google не даёт одного универсального RPM, который подходит всем и навсегда. Вместо этого Google пишет:

• лимиты применяются per project
• requests per day сбрасываются в полночь по тихоокеанскому времени
• preview-модели имеют более жёсткие ограничения
• реальные живые лимиты нужно смотреть в AI Studio

Именно поэтому в этой статье нет фиксированного “универсального RPM”. Многие страницы до сих пор повторяют такое число, но собственное руководство Google формулирует ситуацию как условную и проектно-зависимую. Единственный безопасный дефолт — считать AI Studio местом, где подтверждаются ваши живые лимиты.

Быстрый старт: сделайте первый корректный вызов Nano Banana Pro API

Самый безопасный первый тест — один официальный запрос Google, один правильный ID модели и одна успешно возвращённая картинка. Если первая цель — просто доказать, что маршрут работает, не начинайте с relay, batch-пайплайна или чужого провайдерского алиаса.

Нативный маршрут Gemini

bash
curl -s -X POST \
  "https://generativelanguage.googleapis.com/v1beta/models/gemini-3-pro-image-preview:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [{
      "parts": [
        {
          "text": "Create a clean 16:9 product hero image of a matte black travel mug on a light concrete surface with soft studio lighting and premium ecommerce styling."
        }
      ]
    }],
    "generationConfig": {
      "responseModalities": ["IMAGE"],
      "imageConfig": {
        "aspectRatio": "16:9",
        "imageSize": "2K"
      }
    }
  }'

Этот запрос напрямую доказывает, что официальный маршрут жив. Он использует каноническую строку модели Google, актуальный нативный контракт Gemini и image-specific поля конфигурации, которые Google документирует для Gemini 3 image generation.

На нативном маршруте вы обычно получаете байты изображения внутри содержимого ответа, а не дружелюбную hosted URL. И это ещё одна причина, почему именно нативный контракт лучше как первый proof. Когда вы видите реальную форму ответа, становится понятно, вы дебажите доступ, выбор модели или собственную логику сохранения, а не гадаете, на каком абстрактном слое что-то сломалось.

Gemini OpenAI-compatible route

Если у вас уже есть OpenAI-shaped client и совместимость нужна осознанно, то Google документирует и этот путь:

python
from openai import OpenAI

client = OpenAI(
    api_key="GEMINI_API_KEY",
    base_url="https://generativelanguage.googleapis.com/v1beta/openai/",
)

result = client.images.generate(
    model="gemini-3-pro-image-preview",
    prompt="Create a clean 16:9 product hero image of a matte black travel mug on a light concrete surface with soft studio lighting and premium ecommerce styling.",
    size="2K",
    n=1,
)

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

После первого успешного ответа следующий шаг зависит от того, что осталось неясным:

• Если узкое место — биллинг, переходите к Nano Banana Pro Google AI Studio Billing (англ.).
• Если проблема — получение API key, переходите к Nano Banana Pro API Key.
• Если нужен пошаговый setup, переходите к Nano Banana Pro API Setup (англ.).
• Если нужен более общий REST-маршрут для image generation, переходите к Gemini Image Generation REST API.

Типовые ошибки после настройки

Сразу после первого кода этот запрос часто превращается в support-вопрос. Поэтому этот раздел полезнее ещё одного общего списка “возможностей модели”.

Официальная документация Google объясняет, где живут биллинг и лимиты, но реальные паттерны трения лучше видно в обсуждениях реализации. В треде Google Developers Forum описаны ошибки IMAGE_OTHER, которые воспроизводятся в AWS Lambda, но не воспроизводятся локально. Широко обсуждавшийся тред на Reddit показывает, как часто пользователи путают исчерпание лимита с проблемой сервисной ёмкости.

Самая полезная таблица первичной диагностики выглядит так:

Самая полезная привычка — дебажить по слоям. Сначала доказать правильность official model ID. Потом доказать правильность billing. Потом доказать правильность маршрута. И только затем сравнивать compatibility layer или provider gateway, если он вам всё ещё нужен. Такой порядок экономит больше времени, чем ещё одна страница абстрактных советов.

Когда вообще стоит использовать relay или provider page?

После того как официальный маршрут понятен, relay-страницы вполне могут иметь смысл. Они не “плохие по определению”, и первая страница полна ими не просто так. Обычно они помогают в четырёх случаях:

• вам нужен один OpenAI-style gateway сразу для нескольких image-моделей
• вы хотите объединить billing у нескольких вендоров
• вам нужен провайдерский price plan, лучше подходящий под ваш трафик
• вам нужен коммерческий onboarding быстрее, чем прямой Google billing

Но они не должны заменять понимание официального baseline. Если страница провайдера использует nano-banana-pro вместо gemini-3-pro-image-preview, или выводит на первый план только свои credits, вы всё равно должны понимать, какая официальная модель стоит снизу, сколько Google берёт напрямую и откуда на самом деле берётся поведение по лимитам.

Именно поэтому эта хаб-страница построена по принципу official-first. Сравнивать relay после этого нормально. Начинать с них, не понимая Google surface, — ошибка.

Если ваш реальный следующий шаг — выбрать более дешёвый или более простой gateway, переходите к:

• Дешёвый API Nano Banana Pro
• How to Call Nano Banana Pro via API (англ.)
• Nano Banana Pro API Pricing

FAQ

Какой официальный ID модели Google соответствует Nano Banana Pro API?

Официальная строка модели — gemini-3-pro-image-preview. Nano Banana Pro — это nickname, а не канонический API model name.

Нужно ли обязательно использовать нативный Gemini API, или можно взять OpenAI-совместимый клиент?

Оба пути возможны. Нативный маршрут Gemini — самый безопасный дефолт для новой интеграции. Gemini OpenAI-compatible route лучше подходит тогда, когда главная цель — сохранить существующую форму OpenAI-клиента.

Где смотреть реальные текущие лимиты?

Текущая страница rate limits у Google говорит, что активные live limits нужно смотреть в AI Studio. Публичная документация объясняет правила, но состояние вашего проекта видно именно там.

Нужен ли биллинг для серьёзного использования Nano Banana Pro API?

Да. В billing docs Google сказано, что переход на Paid Tier требует привязки billing account и предоплаты минимум $10. API key сам по себе не гарантирует доступ к нужному production-маршруту.

Есть ли SynthID у сгенерированных изображений?

Да. В image-generation docs Google указано, что сгенерированные изображения получают SynthID watermarking.

Вывод

Nano Banana Pro API — это не загадочный сторонний продукт. Это Google-модель gemini-3-pro-image-preview.

Если вы начинаете с нуля, сначала используйте нативный Gemini-маршрут. Если у вас уже есть OpenAI-shaped client и важнее всего сократить объём миграции, используйте Gemini OpenAI-compatible layer осознанно. В обоих случаях сначала опирайтесь на официальные страницы Google по цене, биллингу и лимитам, а уже потом позволяйте провайдерским лендингам влиять на решение.