Skip to main content

Карточки моделей

Для полного сравнения цен, а также различий между оплатой за запрос и тарификацией на основе token, и рекомендаций по выбору token см. Тарификация серии Nano Banana.

Управление размером

  • Сохраняйте соотношение сторон исходного изображения: просто опустите aspectRatio; в сценариях редактирования с несколькими изображениями приоритет имеет размер последнего изображения
  • Разрешение imageSize: поддерживает 1K / 2K / 4K
    • Nano Banana (Gen 1) поддерживает только 1K
    • Nano Banana 2 добавляет 512px
    • Nano Banana 2 Lite поддерживает только 1K (без 2K/4K/512px)
При использовании одного и того же кода для вызова gemini-2.5-flash-image первого поколения вы должны удалить параметр imageSize (он не поддерживает 2K / 4K), иначе вызов завершится ошибкой.

Как интегрировать

Официальная документация

  • Официальная документация Google: ai.google.dev/gemini-api/docs/image-generation
  • Чтобы интегрироваться с APIYI, просто замените URL запроса + KEY на APIYI; все остальные параметры идентичны официальным

Проверка официального статуса (диагностика проблем на стороне upstream)

Серия Nano Banana работает поверх AIStudio / Gemini API от Google. В редких случаях размытый результат или сбой вывода 2K / 4K может быть проблемой на стороне Google, а не на уровне интеграции — вы можете проверить официальную страницу статуса Google (скопируйте ссылку и откройте её сами): aistudio.google.com/status. Например, 19 июня 2026 года на этой странице было указано «Проблемы с Nano Banana»: у Nano Banana 2 / Pro в Gemini API и AI Studio возникали проблемы при разрешении 2K или 4K. Когда вы видите похожие симптомы, сначала сравните их с официальной страницей статуса, чтобы быстро определить, не является ли это сбоем у upstream.
APIYI использует серию Nano Banana через двойные каналы AIStudio + Vertex для отказоустойчивости: когда на одном официальном канале возникают проблемы, другой может взять на себя обслуживание, чтобы сервис оставался доступным.

Поддержка эндпоинтов

  • Рекомендуемый эндпоинт (нативный Gemini): https://api.apiyi.com/v1beta/models/gemini-3-pro-image-preview:generateContent
  • Поддерживает вызовы в режиме, совместимом с OpenAI (примечание: загрузка через URL не поддерживается, используйте вместо этого Base64)
  • Не поддерживает /v1/image/generations

Формат разработки (рекомендуется по умолчанию)

  • [Рекомендуется] Используйте формат нативного эндпоинта Google
  • Изображения: загружайте как Base64, скачивайте и размещайте у себя заново
  • Способ вызова: синхронные многопоточные вызовы; асинхронные вызовы пока не поддерживаются

Требования к входным изображениям

  • Одно изображение не может превышать 7MB (правило Google); если импорт выполняется через Google Cloud Storage, лимит на каждый файл составляет 30MB
  • До 14 изображений на prompt
  • Поддерживаемые типы MIME: image/png, image/jpeg, image/webp, image/heic, image/heif (формат jpg уже поддерживается APIYI)
  • Увеличение размера при кодировании в Base64: преобразование изображения в Base64 увеличивает его размер примерно на 33.3% (изображение размером 7MB становится примерно 9.3MB)
  • Лимит APIYI: общий объем изображений, загруженных в одном запросе, должен быть менее 100MB — все вызовы являются синхронными, а слишком большие payload могут вызвать резкий рост потребления памяти
Официальная таблица технических характеристик Google Gemini 3 Pro Image: лимит на одно изображение — 7MB, до 14 изображений на prompt, поддерживаемые соотношения сторон и типы MIME

Google official technical specs: inline / console upload per-file limit is 7MB, supporting png/jpeg/webp/heic/heif

Расчет размера Base64: исходное изображение 7MB после кодирования с коэффициентом 4/3 составляет примерно 9.33MB

Base64 encoding increases size by about 33.3%: a 7MB image is roughly equal to 9.3MB

Лучшая практика: применяйте без потерь сжатие к изображениям перед отправкой в API, чтобы избежать слишком больших разрешений, замедляющих выполнение запросов. Ссылка на официальную спецификацию Google (пожалуйста, скопируйте и перейдите по ней самостоятельно): docs.cloud.google.com/vertex-ai/generative-ai/docs/models/gemini/3-pro-image

Ввод изображений по URL

Помимо Base64, нативный endpoint Gemini также поддерживает передачу URL изображений (image hosts / OSS-адресов) напрямую через fileData.fileUri, устраняя необходимость локального кодирования.
Загрузка по URL предъявляет строгие требования к image hosts и OSS-адресам: если адрес не находится на глобальном CDN (например, Tencent Cloud Object Storage по умолчанию использует CDN только для Китая), серверам Google, скорее всего, не удастся получить доступ к изображению, из-за чего запрос завершится ошибкой (типичный симптом: изображение не упоминается в выводе).Если возможно, отдавайте предпочтение загрузке через Base64 для большей стабильности — с точки зрения платформы, это самый отлаженный и наиболее надежный путь.
Загрузка по URL работает только в нативном endpoint Gemini; режим, совместимый с OpenAI, не поддерживает загрузку по URL и требует Base64.

Пример Curl (fileUri)

Пример Python (fileUri)

fileData, mimeType и fileUri должны быть в camelCase (а не file_data / file_uri); иначе параметры будут проигнорированы, и изображение не будет связано.

Основы тарификации (Важно)

  • Длительность синхронного вызова: Pro / 2 при 4K требуют разумного времени генерации примерно 30–150s
  • Отключение при тайм-ауте всё равно влечёт начисление платы: например, если генерация занимает 120s, но клиент задаёт тайм-аут 100s и отключается, с вас всё равно взимается плата
  • 429 / 503 не тарифицируются: за неудачные запросы плата не взимается (мы стараемся не заставлять клиентов ждать или оставаться без изображения)
  • Отказы из-за политики безопасности контента всё равно влекут начисление платы: когда во входных данных клиента есть проблемы с безопасностью контента и Google отказывает в генерации изображения, за код статуса 200 всё равно взимается плата — см. обработку ошибок и план гарантии ниже

Google Search grounding is charged on top of the per-call price

Pro supports the googleSearch tool (grounding triggered in 3/3 test runs, returning full groundingMetadata), useful for weather cards, stock charts, and anything else that needs live information. But the search call fee is added on top of the $0.09 per-call price, not included in it:
The model decides how many searches to run; you cannot set it in advance. In testing, a single image request issued 1–3 queries on its own, so once this tool is enabled the per-call cost becomes a range ($0.104–$0.132) rather than a fixed $0.09. Budget against the upper bound.
Image Search grounding (searchTypes.imageSearch) does not work on Pro — 0/2 runs triggered it, and imageSearchQueries never appeared in groundingMetadata. It is exclusive to Nano Banana 2 (gemini-3.1-flash-image); see Nano Banana 2 · Three parameters that affect billing.

thinkingLevel не влияет на Pro — не копируйте его из NB2

generationConfig.thinkingConfig.thinkingLevel предназначен исключительно для серии Nano Banana 2. Передача high в Pro:
  • Не вызывает ошибку — запрос нормально возвращает 200
  • Но не влияет: измеренные значения thoughtsTokenCount находились в диапазоне 108–156, полностью перекрывая диапазон 130–159, наблюдаемый без параметра
  • Рассуждение в Pro всегда включено и не подлежит настройке, как прямо указано в документации Google
Кроме того, Pro тарифицируется по фиксированной ставке за каждый вызов, поэтому рассуждение никогда не попадает в счет — настройка этого параметра в Pro не дает ни эффекта, ни экономического смысла. Чтобы управлять накладными расходами на рассуждение, используйте вместо этого тарификацию по потреблению в Nano Banana 2.

Настройки таймаута (Важно)

Генерация изображений 4K занимает больше времени в целом, включая такие этапы, как загрузка изображения, обработка API и скачивание изображения Base64 (наш backend выставляет тарификацию по времени обработки API). В обычных условиях 4K занимает около 50s (без учета polling), но если клиент задаст timeout слишком коротким, он разорвёт соединение преждевременно до завершения генерации и вернёт ошибку:
Журналы вызовов: time-to-first-byte для генерации gemini-3-pro 4K составляет от 43 до 61 секунд

Call logs: time-to-first-byte for 4K generation is about 43–61s, so the default 120s timeout is too tight

Для большей безопасности рекомендуем задавать timeout в зависимости от разрешения:

Многоходовое разговорное редактирование (нативный режим поддерживает это; reverse-модели — нет)

Серия Nano Banana использует нативный формат Gemini и поддерживает настоящее многоходовое разговорное редактирование: добавляйте сгенерированное изображение каждого хода обратно в contents как role: "model" inlineData, затем отправляйте следующую инструкцию пользователя. Модель выполняет правки на основе полной истории разговора и накапливает изменения (например, сначала измените цвет дивана, затем добавьте аксессуар — предыдущее изменение сохранится). Это принципиально отличается от «reverse» image models — разберитесь в этом до интеграции:
Проверено: повторное добавление предыдущего изображения как хода с ролью model позволяет Nano Banana 2 (gemini-3.1-flash-image-preview) корректно продолжать редактирование и накапливать изменения; reverse model читает только reference image из последнего сообщения пользователя, поэтому сохранение истории разговора там не работает для многоходового сценария.
Минимальный пример (добавляйте каждый результат обратно в тот же contents):
Полные подробности (подходы history-backfill и re-feed, а также запуск многоходового сценария с существующего изображения) приведены в Image Editing API · Многоходовое разговорное редактирование.

Всегда перебирайте parts, чтобы получить изображение — никогда не индексируйте его

parts — это неоднородный массив: он может содержать только сегмент изображения или чередовать текстовые и сегменты изображения, и ни длина, ни порядок не гарантируются. Жёстко заданный доступ вроде parts[0] / parts[1] поэтому наверняка будет периодически приводить к сбоям. В ходе тестирования было замечено три варианта структуры: Текстовый сегмент может появиться по нескольким причинам: если включить TEXT в responseModalities, или если prompt просит модель объяснить саму себя, модель возвращает текст вместе с изображением — и то, окажется ли этот текст до изображения или после него, тоже не фиксировано. Поэтому индекс, на котором находится изображение, не является постоянным, и один и тот же код может получать разные структуры в разных запросах.
Два шаблона с жёстко заданным индексом взаимодополняют друг друга: изображение всегда оказывается либо на [0], либо на [1], так что какой бы вариант вы ни выбрали, часть запросов будет возвращаться без изображения. Переключение между [0] и [1] ничего не исправляет — стабильным является только выбор по форме поля.
Правильный подход — выбирать по форме поля, а не по позиции. Обратите внимание, что нужно брать последний inlineData, а не первый — сложные задачи возвращают несколько изображений, и последнее является финальной версией (см. следующий раздел):
Усиление надёжности: объявление responseModalities: ["IMAGE"] в generationConfig означает, что вы хотите только изображение, что уменьшает количество лишних текстовых сегментов.Это усиление надёжности, а не замена — фильтрация всё равно должна идти первой. Обратное неверно: передача ["TEXT","IMAGE"] не гарантирует текстовый сегмент; модель всё равно может вернуть только изображение.
Не задавайте mimeType жёстко тоже. Формат изображения в ответе непостоянен — встречаются и image/png, и image/jpeg. Запись файлов с фиксированным расширением .png приводит к файлам, у которых расширение противоречит их содержимому — всегда позволяйте mimeType ответа определять расширение.

Почему ответы иногда содержат несколько изображений

При вызове gemini-3-pro-image вы иногда можете увидеть несколько частей изображения в одном ответе (в ходе тестирования наблюдалось 2–10), что соответствует периодически возникающим записям об output-token 6000+ (и даже пятизначным значениям) в ваших логах. Это не аномалия: в официальной документации Google указано, что у image-моделей Gemini 3 «Thinking» включён по умолчанию (в API его нельзя отключить), модель создаёт промежуточные изображения для проверки композиции и логики, эти черновики появляются в parts вместе с финальной версией, а «последнее изображение внутри Thinking также является окончательно отрисованным изображением» (официальная документация: ai.google.dev/gemini-api/docs/image-generation). На основе наших тестов в июле 2026 года (нативный формат Google generateContent): Срабатывание определяется сложностью задачи в prompt, а не самим «редактированием изображения». Несколько изображений по-прежнему находятся в одном кандидате (а не в нескольких кандидатах), и каждое из них — это полноценное изображение: это последовательные черновики одного и того же дизайна в процессе рассуждения (одна и та же композиция, немного разные детали), а последняя часть — финальная версия. Эти черновики возвращаются как обычные части изображения (с полем thoughtSignature, без флага thought: true); в документации Google сказано, что Thinking создаёт максимум два промежуточных изображения, но на сложных задачах мы наблюдали до 10. Влияние на тарификацию: каждое изображение тарифицируется фиксированным количеством token (1120 token за изображение при разрешении 1K/2K, 2000 при 4K), поэтому output token растут строго линейно с количеством изображений. Периодическая запись 6000+ (вплоть до ~13,5k в крайних случаях) output-token в ваших логах — это просто ответ с 4–10 изображениями, а не аномалия тарификации. Рекомендуемый код для последующей обработки:
  • Всегда итерируйтесь по частям — не предполагайте, что на каждый ответ приходится одно изображение; любая логика подсчёта или сохранения по изображениям должна опираться на фактическое количество частей
  • Берите последнее изображение, если нужно только одно: более ранние черновики имеют незавершённые детали и немного более низкое качество, поэтому не выбирайте первое
  • Управление количеством изображений через prompt в основном неэффективно (в тестировании инструкции вроде «выведи только одно изображение» игнорировались) — обрабатывайте это в коде
  • Ответы с несколькими изображениями занимают 35–142 с (при разрешении 1K, дольше при большем числе изображений), заметно больше, чем ответы с одним изображением — сохраняйте рекомендации по тайм-ауту выше (≥ 5 минут)
Полную разбивку полей usageMetadata (разницу между деталями и итогами, особенность подсчёта в ответах с отказом и многое другое) см. в Поля Usage и объяснение вывода.

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

Руководство по обработке ошибок

Три ключевых индикатора для диагностики неудачных генераций, политик модерации контента и дружественных стратегий составления prompt

Обязательные к прочтению распространённые вопросы разработчика

Устранение неполадок при неудачных генерациях и ответы на распространённые вопросы

План гарантии при неудачной генерации

Для сбоев, не вызванных вашим вводом, кредиты возмещаются в соответствии с количеством неудачных запросов
Полный текст ошибки выглядит так:
Это обычно вызвано загрузкой изображений слишком большого размера — тело запроса становится слишком большим, и соединение обрывается. Следуйте этим рекомендациям:
  • Ограничьте количество изображений: соблюдайте официальные правила (не более 14 изображений на prompt — см. официальную спецификацию выше).
  • Ограничьте размер каждого изображения: держите каждое изображение меньше 5MB — официальный лимит на одно изображение составляет 7MB, а кодирование base64 увеличивает размер примерно на 1/3, поэтому оставляйте запас.
  • Сжимайте на frontend перед загрузкой: сжимайте изображения на frontend (или через серверный relay) перед отправкой в API — обычная практика заключается в ограничении длинной стороны, конвертации в JPEG/WebP и настройке параметра качества.
  • Переключитесь на ввод через URL: нативный формат Gemini поддерживает передачу image URL через fileData.fileUri, полностью обходя слишком большие base64-тела запроса — см. Ввод изображения по URL выше.

Сценарии использования

  • Клиенты AI-чатов: такие клиенты, как Cherry Studio, можно настроить для генерации изображений напрямую через APIYI
  • Проверка генерации: быстро проверьте производительность модели в чат-клиенте или в консоли

Дополнительные потребности

  • Хотите загружать изображения по URL? Нативный эндпоинт Gemini поддерживает передачу URL изображения через fileData.fileUri; однако режим, совместимый с OpenAI, не поддерживает загрузку по URL, поэтому используйте Base64. См. примеры кода и оговорки в Ввод изображения по URL выше.
  • Хотите напрямую получать URL для скачивания (вместо Base64)? Используйте группу NB-OSS — см. Группа Nano Banana OSS.