Google перевела две модели в статус общей доступности: gemini-3.6-flash и gemini-3.5-flash-lite. Теперь это стабильные эндпоинты, а не превью-версии.

Что изменилось

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

Gemini 3.5 Flash-Lite позиционируется как низколатентный, экономичный вариант для подагентов — модель, которую вызывают тысячи раз внутри более крупной системы, а не та, с которой напрямую общается пользователь.

Обратно несовместимое изменение

Вместе с переходом в общий доступ вносится изменение, которое нарушит работу существующего кода: параметры выборки temperature, top_p и top_k объявлены устаревшими для обеих моделей. Код, который передаёт эти параметры, нужно пересмотреть. Это реальный сдвиг в подходе — эти три параметра были стандартом для генеративных API с самого начала, и их удаление означает, что модель сама определяет своё поведение при выборке.

Почему это важно

Отказ от контроля выборки означает обмен пользовательской настройки на контроль со стороны вендора. Для большинства приложений настройки по умолчанию и так были приемлемыми, а меньшее число параметров означает меньше способов неправильно настроить развёртывание. Для команд, которые потратили немало усилий на настройку temperature под конкретные сценарии использования, эта работа теперь устарела.

Заметно отсутствует в этом релизе Gemini 3.5 Pro, выход которой уже несколько раз откладывался сверх ожидаемых сроков. Google выпустила быстрый и дешёвый уровень моделей, оставив флагман на потом.

Что делать

Проверьте весь код, который задаёт temperature, top_p или top_k для этих двух моделей, и запланируйте его удаление. Устаревание параметра — это не немедленное удаление, но это обязательство, а незаметно игнорируемые параметры хуже, чем явные ошибки: вывод меняется, а причина остаётся неясной.

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

Общая тенденция среди вендоров

Google здесь не одинока. Индустрия постепенно отказывается от низкоуровневых настроек в пользу моделей, которые сами управляют своим поведением при инференсе, а reasoning-модели в любом случае сделали большинство настроек выборки бессмысленными. Стоит ожидать, что площадь поверхности этих API продолжит сокращаться.