Google добавила в Gemini API режимы Flex и Priority для баланса цены и надёжности

2 апреля 2026 года Google добавила в Gemini API два новых режима обслуживания — Flex и Priority, чтобы разработчики могли точнее управлять ценой, задержкой и надёжностью без усложнения архитектуры. Идея в том, что фоновые и критичные пользовательские запросы теперь можно разводить по разным уровням сервиса через один и тот же синхронный интерфейс, а не собирать отдельные контуры под Standard API и Batch API. Компания описывает проблему довольно приземлённо.

По мере того как AI-сценарии уходят от простых чат-ботов к агентам и составным рабочим процессам, у команд обычно появляются два класса нагрузки. Первый — фоновые задачи: массовое обогащение данных, длительные рассуждения модели, исследовательские прогоны, обновления CRM и другие процессы, где лишние секунды не критичны. Второй — интерактивные запросы: пользовательские чаты, копилоты, модерация в реальном времени, саппорт-боты и другие функции, где важны стабильный ответ и предсказуемая задержка.

Раньше для такого разделения часто приходилось комбинировать обычные синхронные запросы со стороны продукта и Batch API для дешёвой фоновой обработки. Это давало экономию, но добавляло накладные расходы: нужно было управлять асинхронными заданиями, файлами ввода и вывода, а также опросом статуса выполнения. В Google говорят, что Flex и Priority закрывают этот разрыв: обе опции работают через стандартные синхронные эндпоинты, а переключение идёт через параметр service_tier в запросе.

Flex — это новый экономичный режим для задач, которые терпят задержку и более низкий приоритет выполнения. Google обещает экономию до 50% по сравнению со Standard API, если разработчик готов пожертвовать частью надёжности и скорости ответа ради стоимости. Ключевой момент в том, что Flex не превращает работу в отдельный batch-процесс: это всё ещё синхронный запрос с привычной схемой интеграции.

Такой режим компания предлагает использовать для фоновых обновлений CRM, масштабных исследовательских симуляций и агентных сценариев, где модель может «думать» или «просматривать» информацию в фоне. По данным Google, Flex будет доступен на всех платных тарифах и поддерживается в запросах GenerateContent и Interactions API. Priority, наоборот, рассчитан на самый чувствительный трафик.

Это премиальный режим с максимальным уровнем гарантии, который должен помогать приложениям проходить пиковые нагрузки без вытеснения критичных запросов. Google прямо говорит, что такие запросы получают наивысший уровень критичности, а значит, выше шанс сохранить стабильную работу даже тогда, когда платформа загружена. Ещё одна важная деталь — механизм мягкого понижения: если приложение вышло за лимиты Priority, избыточные запросы не отваливаются с ошибкой, а автоматически обслуживаются в Standard.

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

Среди типовых кейсов компания называет ботов поддержки в реальном времени, конвейеры live-модерации и любые запросы, чувствительные ко времени. На старте Priority будет доступен для платных проектов уровней Tier 2 и Tier 3 в GenerateContent API и Interactions API. Для разработчиков это обновление важно не только из-за цен.

Google фактически пытается упростить инженерный выбор между «дёшево» и «надёжно», не заставляя продуктовые команды строить две разные модели интеграции. Если Flex действительно даст обещанные 50% экономии на фоне без перехода в batch-архитектуру, это может удешевить агентные сценарии и массовые пайплайны. А если Priority будет стабильно удерживать критичный трафик в часы пик, у Gemini API появится более сильный аргумент для пользовательских продуктов, где сбои напрямую бьют по выручке и пользовательскому опыту.

Главный вывод простой: Google превращает Gemini API из единого стандартного канала в более гибкую систему классов обслуживания. Для команд это означает возможность на одном и том же API осознанно разделять фоновую и критичную нагрузку, лучше считать юнит-экономику и мягче переживать пиковые периоды. Если подход приживётся, конкуренция между AI-платформами всё чаще будет идти не только по качеству моделей, но и по тому, насколько тонко провайдер умеет продавать производительность, надёжность и стоимость под разные продуктовые сценарии.