Поддерживает ли gemini-3.1-flash-lite-image режим рассуждений? Объяснение использования thinkingLevel на основе 3 наборов реальных тестовых данных

“gemini-3.1-flash-lite-image 到底支不支持推理模式？”是最近在 API 调用群里被问得最多的问题之一。答案是肯定的，而且这不是猜测——我们结合 Google 官方文档，通过 APIYI 网关做了三组对照实验，拿到了真实的 token 消耗和延迟数据。本文将从参数结构、实测数据、计费规则三个角度，把 thinkingLevel 这个开关讲透。

核心价值: 读完本文，你会明确 gemini-3.1-flash-lite-image 的推理模式怎么开、开了之后多花多少 token、以及什么场景值得为这份延迟买单。

gemini-3.1-flash-lite-image 推理模式核心结论

先给结论，再讲细节。Google 官方文档明确写道，借助 gemini-3.1-flash-image 和 gemini-3.1-flash-lite-image，开发者可以控制模型使用的思考量，这意味着 flash-lite 这一档同样内置了推理能力，并非只有旗舰模型才有。但并不是所有图片模型都支持这个参数，下表是三款主流 Gemini 图片模型的支持情况对比。

需要特别说明的是，thinkingLevel 只有两档可选，不是像文本模型那样支持连续调节的思考预算。官方原文提到“minimal 思考并不代表模型完全不思考”，也就是说即便是默认档位，模型内部也会做一定量的基础推理，只是不会像 high 档那样进行多轮构图校验。

这也是一个值得关注的行业信号。在更早一代的图片生成模型里，无论是 nano banana 还是初版 flash-image，官方接口都没有暴露过思考等级这类参数，模型要么按固定策略出图，要么完全靠提示词工程去补偿构图缺陷。到了 3.1 这一代，Google 把“先规划、再生成”的推理机制开放给了 flash 系列，本质上是把此前只在文本模型里验证过的思考范式，迁移到了图片生成场景。理解这个背景，有助于判断未来其他厂商的图片模型是否也会走上同样的路线。

🎯 Техническая рекомендация: если вы вызываете модели Gemini для изображений через APIYI apiyi.com, сначала запустите бизнес-процесс на стандартном уровне minimal, а потом уже по качеству результата решайте, нужно ли переключаться на high. Платформа даёт единый интерфейс, так что gemini-3.1-flash-image, flash-lite-image и pro-image можно вызывать через один и тот же код, что удобно для A/B-сравнения.

Подробный разбор параметра thinkingLevel и способа вызова

thinkingLevel — это не самостоятельный параметр, а объект thinkingConfig, вложенный в generationConfig, и используется он вместе с includeThoughts. includeThoughts определяет, возвращать ли вызывающей стороне сводку размышлений модели, а thinkingLevel — насколько «сильно» модель будет думать. Это два независимых переключателя, не путайте их.

В таблице ниже собраны тип и диапазон значений двух ключевых полей внутри объекта thinkingConfig.

При реальном вызове структура для трёх основных языков абсолютно одинаковая: в config просто добавляется объект thinkingConfig. Например, на Python это выглядит так:

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # Вызов через единый шлюз APIYI
)

response = client.chat.completions.create(
    model="gemini-3.1-flash-lite-image",
    messages=[{"role": "user", "content": "Нарисуй кота, который пьёт кофе на фоне заснеженных гор"}],
    extra_body={
        "thinkingConfig": {
            "thinkingLevel": "high",
            "includeThoughts": True
        }
    }
)
print(response.choices[0].message.content)

{
  "contents": [{"parts": [{"text": "Нарисуй кота, который пьёт кофе на фоне заснеженных гор"}]}],
  "generationConfig": {
    "responseModalities": ["IMAGE"],
    "thinkingConfig": {
      "thinkingLevel": "high",
      "includeThoughts": true
    }
  }
}

Совет: через APIYI apiyi.com можно получить бесплатный тестовый лимит и сразу проверить, корректно ли thinkingConfig проходит через шлюз. Это обычно проще, чем отдельно получать официальный ключ и отлаживать всё на своей стороне.

Данные APIYI в реальных тестах: как thinkingLevel влияет на token и задержку

Как ни подробно описывай параметры в документации, реальные замеры всё равно нагляднее. Мы взяли один и тот же промпт и на изображении 1K, через шлюз APIYI, отдельно протестировали gemini-3.1-flash-image в режимах minimal и high, а также случай, когда в gemini-3-pro-image принудительно передаётся high.

Из этих данных видно три важных вещи. Во-первых, когда thinkingLevel переключается на high, thoughtsTokenCount вырастает с нуля по сути до диапазона 700–800; в ответе в режиме по умолчанию этого поля вообще нет. Общий расход токенов увеличивается почти на 50%, а задержка ответа растёт с 12–13 секунд до 18–23 секунд. То есть на «размышления» действительно уходит и время, и деньги.

Во-вторых, независимо от того, minimal это или high, число токенов самой картинки остаётся 1120. Значит, thinkingLevel влияет только на то, как модель «думает», но не меняет ни разрешение изображения, ни его стоимость.

В-третьих, если передать high в gemini-3-pro-image, ошибка не возникнет, но значение thoughtsTokenCount остаётся в диапазоне 181–214 и почти не отличается от режима по умолчанию. Это подтверждает вывод из официальной документации: у pro-image поведение размышлений фиксировано, внешняя настройка на него не влияет.

То есть если в вашей бизнес-логике один и тот же thinkingConfig массово отправляется в flash, flash-lite и pro, то pro-image просто молча проигнорирует этот параметр. Ошибки не будет, но и ожидаемого изменения глубины размышлений тоже не произойдёт.

И ещё один важный нюанс: приведённые выше данные — это не разовый замер. Для каждой настройки один и тот же промпт отправлялся несколько раз, а затем брался диапазон значений. Поэтому у high thoughtsTokenCount и получается таким, 700–792, а не одним фиксированным числом. У задач, связанных с размышлениями, есть определённая доля случайности: промежуточный путь рассуждений каждый раз немного отличается, поэтому и расход токенов чуть плавает. Но общий порядок величин и рост задержки воспроизводятся стабильно. Не бывает такого, чтобы high вдруг оказался быстрее minimal, или чтобы количество токенов размышлений внезапно улетело в несколько тысяч.

Токены для размышлений в image-моделях и правила тарификации

Многие разработчики, впервые увидев поле thoughtsTokenCount, по привычке сравнивают его с затратами на размышления у текстовых моделей. Но у image-моделей механизм размышления на самом деле разбит на две части, и это важно понимать для контроля бюджета.

В официальной документации отдельно подчёркивается: независимо от того, выставите вы includeThoughts в true или false, токены, потраченные на размышления, всё равно будут тарифицироваться как обычно. Мы это подтвердили и на практике — после включения includeThoughts структура ответа и общая сумма оплаты вообще не меняются, просто в ответе появляется текстовое резюме размышлений для отладки. Иначе говоря, includeThoughts — это переключатель «показывать или не показывать», а не «платить или не платить». Этот нюанс легко неправильно понять.

Ещё важнее другое: основная часть стоимости у image-модели сидит не в поле thoughtsTokenCount, а во временных изображениях компоновки, которые создаются в процессе рассуждения. В документации сказано, что на этапе размышления модель может сгенерировать максимум две временные картинки, чтобы проверить компоновку и логику. Эти наброски возвращаются как обычные image part и учитываются в candidatesTokenCount, то есть оплачиваются по стандартному тарифу для выходных изображений. Получается, что один запуск генерации с high может незаметно добавить одну-две «невидимые» картинки в чек, и при расчёте бюджета это легко упустить.

Если посчитать на пальцах, картина станет понятнее. Допустим, запрос на генерацию изображения в 1K-разрешении идёт в режиме high, текст размышлений расходует около 750 токенов, и модель действительно создаёт две временные наброски. Тогда вместе с финальным изображением получится три image part, а при цене примерно 1120 токенов и 0.0336 доллара за штуку стоимость только на изображения уже приближается к 0.1 доллара. Если добавить сюда ещё и текст размышлений, общий расход может оказаться в 2–3 раза выше, чем в minimal. При этом появятся ли две наброски на самом деле, зависит от того, как модель оценивает ваш промпт, так что high-режим не всегда генерирует полный набор из двух временных картинок. Именно поэтому в реальных тестах общий объём токенов плавает в диапазоне 2243–2375, а не удваивается строго по формуле.

💰 Оптимизация затрат: если ваша команда чувствительна к стоимости токенов, лучше сначала проверить реальный totalTokenCount в логах вызовов на платформе APIYI apiyi.com, а уже потом решать, стоит ли постоянно держать high включённым. Так вы не упустите расходы на наброски и не выйдете за рамки бюджета.

В каких сценариях выбирать high, а когда достаточно minimal

На основе практических тестов — простая схема принятия решения.

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

На практике самый надёжный вариант — сделать thinkingLevel настраиваемым параметром, а не жёстко прописывать его в коде. Например, можно автоматически маршрутизировать запросы по типу задачи: для пакетных операций оставлять minimal по умолчанию, а для запросов с точной вёрсткой или несколькими объектами в кадре переключаться на high. Так вы и среднюю стоимость удержите под контролем, и не будете жертвовать качеством в важных кейсах. Если же в команде одновременно используются flash, flash-lite и pro, лучше вынести обработку параметров в единый слой и передавать thinkingLevel только тем моделям, которые его поддерживают, чтобы не прокидывать лишние параметры в pro-image и потом не тратить время на отладку.

🚀 Быстрый старт: для прототипа удобно использовать платформу APIYI apiyi.com. Одна и та же base_url позволяет переключаться между minimal и high для сравнения, без отдельной настройки авторизации под каждый режим.

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

Итог

gemini-3.1-flash-lite-image действительно поддерживает режим вывода с рассуждением — это подтверждено и официальной документацией, и тестами команды APIYI. У thinkingLevel есть только два варианта — minimal и high; при включении high число токенов рассуждения вырастает до 700+ и общий отклик становится примерно на 5–10 секунд длиннее, но расход токенов на итоговое изображение не меняется. А вот gemini-3-pro-image, хотя и принимает этот параметр без ошибки, фактически его не использует. Понимание логики «текст размышлений идёт в thoughtsTokenCount, а набросок композиции — в candidatesTokenCount» — это ключ к контролю стоимости генерации изображений. Если нужно быстро переключаться между несколькими моделями Gemini Image и проверять их поведение, удобнее всего делать это через единый шлюз APIYI apiyi.com, чтобы не заводить отдельные API-ключи для каждой модели и не поддерживать лишний код вызова.

Данные в статье получены в ходе практических тестов технической команды APIYI. Если хотите обсудить детали вызова моделей Gemini Image, обращайтесь в техническую поддержку APIYI apiyi.com.

Справочные материалы

1. Официальная документация Gemini API — генерация изображений: описание параметра уровней размышления (thinking levels)
   • Ссылка: ai.google.dev/gemini-api/docs/generate-content/image-generation