Уровень рассуждений Nano Banana 2: как настроить Minimal и High

У Nano Banana 2, то есть Gemini 3.1 Flash Image, доступны два документированных уровня рассуждений: minimal и high. По умолчанию используется minimal. Для нового запроса через Interactions API уровень задаётся в generation_config.thinking_level; актуальный идентификатор модели — gemini-3.1-flash-image. Эти сведения проверены по документации Google 8 сентября 2026 года. Описание модели, настройка рассуждений.

Начинать удобно с minimal: он даёт исходный результат, с которым можно сравнить high. Повышенный уровень стоит пробовать, когда картинка выглядит убедительно, но не выполняет важные условия задания: перепутаны отношения между объектами, потеряны детали из референса или нарушена сложная композиция. Это повод для сравнения, а не обещание, что High обязательно устранит ошибку.

Почему встречается Dynamic и что можно передавать в API

В материалах о запуске Nano Banana 2 Google использовала формулировку High/Dynamic для сложных запросов. В некоторых обзорах её превратили в третий режим рядом с Minimal и High. Но текущие инструкции по генерации изображений перечисляют именно два допустимых значения: minimal и high. Из названия в анонсе нельзя сделать вывод, что API принимает строку dynamic. Анонс Google, текущая инструкция API.

minimal не означает «рассуждения полностью выключены». Google отдельно поясняет это в инструкции для generateContent. Поэтому отсутствие видимого текста размышлений тоже ничего не говорит о том, сколько рассуждений было выполнено. Документация generateContent.

Если настройка находится в стороннем приложении или узле рабочего процесса, сначала выясните, какое значение отправляет сама интеграция. Надпись High/Dynamic в меню ещё не доказывает наличие отдельного режима в Google API. Для настройки через собственный код полезнее смотреть на фактическое тело запроса, чем на название переключателя.

Рабочий запрос через Interactions API

В Interactions используется плоский параметр внутри generation_config. Ниже пример REST-запроса с high. API-ключ заранее задаётся в переменной окружения GEMINI_API_KEY; в файл с запросом его помещать не нужно.

bash
curl --fail-with-body \
  'https://generativelanguage.googleapis.com/v1beta/interactions' \
  -H "x-goog-api-key: ${GEMINI_API_KEY}" \
  -H 'Content-Type: application/json' \
  --data-binary @- > interaction.json <<'JSON'
{
  "model": "gemini-3.1-flash-image",
  "input": "Создай рекламный натюрморт: синяя чашка стоит на закрытой жёлтой книге, справа лежит одна серебряная ложка. Вид сверху, светлый фон, без надписей.",
  "generation_config": {
    "thinking_level": "high"
  }
}
JSON

Для сравнения замените только "high" на "minimal". В этом примере намеренно есть проверяемые отношения: чашка стоит на книге, ложка находится справа и присутствует в единственном экземпляре. Такой запрос позволяет оценить выполнение условий, а не только общее впечатление от красивой картинки.

Это пример по документированной схеме запроса, а не отчёт о выполненном вызове. Названия модели и параметров соответствуют текущему руководству Google по Interactions.

Как понять, что получено готовое изображение

Успешный HTTP-ответ — первый этап. Следующий — проверить содержимое. В примерах SDK Google готовое изображение доступно через interaction.output_image.data в виде base64. Перед сохранением нужно убедиться, что изображение действительно присутствует, поле данных непустое, а MIME-тип соответствует изображению. Затем данные декодируют и проверяют, открывается ли полученный файл. Получение изображения в Interactions.

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

Формат Interactions не следует разбирать как ответ generateContent. Если готовая обёртка ищет только candidates[].content.parts, переход на другой API потребует изменения обработчика ответа, даже если запрос успешно принят.

Если приложение уже использует generateContent

В generateContent уровень расположен глубже. Для REST используется путь generationConfig.thinkingConfig.thinkingLevel, а не generation_config.thinking_level. Вот отдельный пример тела запроса для POST /v1/models/gemini-3.1-flash-image:generateContent:

json
{
  "contents": [{
    "parts": [{
      "text": "Создай рекламный натюрморт: синяя чашка стоит на закрытой жёлтой книге, справа лежит одна серебряная ложка. Вид сверху, светлый фон, без надписей."
    }]
  }],
  "generationConfig": {
    "responseModalities": ["IMAGE"],
    "thinkingConfig": {
      "thinkingLevel": "high"
    }
  }
}

Названия в SDK также отличаются: в Python это thinking_config и thinking_level, в JavaScript — thinkingConfig и thinkingLevel. Переносить объект конфигурации между интерфейсами без изменения вложенности нельзя. Примеры generateContent для изображений.

В ответе generateContent нужно просматривать части сообщения. Части с признаком thought относятся к рассуждениям; их пропускают при выдаче финального изображения пользователю. Для готовой картинки проверяют данные изображения в остальных частях, а не сохраняют первую попавшуюся часть как конечный результат.

Параметр includeThoughts управляет возвратом рассуждений в ответе. Его отключение не выключает оплату рассуждений. В многошаговом редактировании также важно сохранять и передавать обратно thoughtSignature без изменений, как предписывает используемый интерфейс. Это отдельный механизм продолжения взаимодействия, а не регулятор уровня. Рассуждения и подписи в generateContent.

Когда High оправдывает задержку и расходы

Универсального ответа «High всегда лучше» здесь нет. Для простого изображения оба уровня могут выполнить задачу. Для более сложного запроса дополнительные рассуждения могут оказаться полезны, но величину выигрыша следует оценивать по собственным результатам. Приведённый ниже порядок — предлагаемый способ проверки; сравнительные API-вызовы и замеры для этой статьи не проводились.

Возьмите несколько характерных для вашей работы заданий: предметную картинку, композицию с несколькими объектами, редактирование по референсу. До генерации запишите, что делает каждый результат пригодным: все ли объекты присутствуют, верны ли их отношения, сохранены ли нужные детали. Формулировка «нравится больше» может дополнять эти критерии, но плохо объясняет, зачем платить за другой режим.

Сравнивайте уровни при одинаковых условиях:

1. Оставьте неизменными текст запроса, референсы, разрешение, соотношение сторон и настройку поиска.
2. Выполните несколько повторов на каждом уровне, меняя только thinking_level. Один удачный результат не показывает устойчивость поведения.
3. Измерьте время от отправки запроса до получения пригодного для сохранения изображения.
4. Запишите фактическое использование и начисленную стоимость, число выполненных условий и необходимость повторной генерации.
5. Сравните расходы на пригодный результат и время его получения.

Для расчёта удобно использовать суммарные расходы на серию, делённые на число пригодных изображений. В числитель включайте все реально начисленные расходы этой серии, в том числе за оплаченные попытки, которые не подошли. Если пригодных результатов нет, стоимость одного результата не определена — серию следует разбирать как неуспешную.

Так видно, когда более дорогой отдельный запрос уменьшает количество переделок. Возможен и обратный результат: High занимает больше времени, а доля пригодных изображений остаётся прежней. В таком случае у него нет подтверждённого преимущества именно для этой задачи.

Сколько стоят дополнительные рассуждения

На 8 сентября 2026 года стандартная таблица Google для Gemini 3.1 Flash Image указывает $3 за миллион выходных текстовых токенов и токенов рассуждений. Поэтому дополнительные 1000 токенов рассуждений соответствуют $0.003. Это арифметический пример, а не типичный расход High и не фиксированная доплата за включение режима. Тарифы Google.

Полный запрос включает несколько составляющих:

$0.067 за 1K — не полная фиксированная цена запроса. Помимо самой картинки могут оплачиваться вход, текст, рассуждения и используемые инструменты. Это тарифы стандартного Google API в долларах США, а не цена подписки в приложении или условия стороннего сервиса. Подробности расчёта разных составляющих есть в разборе стоимости Nano Banana 2.

Настройка не работает: что проверить

Если API отклоняет уровень, начните с трёх конкретных вещей: идентификатор модели, название интерфейса и вложенность параметра. Для Nano Banana 2 используйте gemini-3.1-flash-image; для Interactions — generation_config.thinking_level; для REST generateContent — generationConfig.thinkingConfig.thinkingLevel. Возьмите значение из инструкции именно к этому интерфейсу и не добавляйте dynamic из стороннего обзора.

Если запрос принимается, но результат не меняется, сначала убедитесь, что ваше приложение действительно передаёт параметр. Затем сравните несколько повторов по заранее выбранным условиям задачи. Одинаково хороший результат при обоих уровнях вполне возможен и сам по себе не доказывает, что настройка проигнорирована.

Если в ответе нет видимых рассуждений, проверьте способ их возврата и обработки. Отсутствие сводки не доказывает нулевое использование токенов. А если нет финального изображения, выясняйте причину по содержимому ответа до подсчёта успешных генераций.

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