Gemini Provisioned Throughput теперь поддерживает очередь из 7 заказов: что GA-релиз мультизаказов меняет для команд маршрутизации

1 июля 2026 года Google перевёл поддержку нескольких ожидающих заказов Provisioned Throughput (PT) в статус GA на Gemini Enterprise Agent Platform. Теперь можно одновременно ставить в очередь до 7 стандартных заказов на одну модель и регион, не дожидаясь активации предыдущего. Для инженерных команд, маршрутизирующих значительный трафик через Gemini-модели на GCP, это устраняет ключевой планировочный bottleneck: последовательный 10-рабочий-дневный цикл ожидания между заказами.

Что произошло

Provisioned Throughput на Gemini Enterprise Agent Platform позволяет резервировать выделенные мощности вместо конкуренции за общие ресурсы. До 1 июля процесс оформления заказов был последовательным: отправил заказ, дождался активации (обычно до 10 рабочих дней), затем подал следующий. Для планирования наращивания мощностей под ожидаемый рост трафика требовалось заблаговременное планирование на месяцы вперёд с ручным инициированием каждого шага.

GA-релиз 1 июля изменил эту схему. Теперь можно одновременно поставить в очередь до 7 стандартных PT-заказов на одну модель и регион Google. Заказы обрабатываются и активируются последовательно в порядке очереди на условиях коммерчески разумных усилий, но управлять процессом вручную уже не нужно: оформил всю цепочку заказов сразу — очередь выполняется автоматически.

Функция доступна через Google Cloud Console в разделе управления Provisioned Throughput Gemini Enterprise Agent Platform. Требуются разрешения aiplatform.provisionedThroughputs.create и .update в рамках роли roles/aiplatform.provisionedThroughputAdmin.

Почему это важно для AI-инженерных команд

Provisioned Throughput — главный инструмент против ошибок 429 (resource exhausted) при работе с Gemini-моделями на масштабе. Команды, уже перешедшие с pay-as-you-go на PT, хорошо знают: задержка активации — главная точка трения. Сегодняшний заказ не гарантирует мощности на завтра. Очередь из нескольких заказов меняет это уравнение.

Наращивание мощностей без ручного сопровождения. Если план предусматривает рост с 10 тыс. до 30 тыс. QPM за три месяца, теперь можно сразу подать три последовательных заказа — на 10k, 20k и 30k GSU — каждый настроен активироваться после предыдущего. Плановое масштабирование больше не требует напоминаний в календаре и ручного переоформления запросов в GCP.

Перекрывающиеся заказы для миграции моделей. PT-заказ привязан к конкретной модели в рамках одного издателя. Можно переназначить существующий PT с Gemini 3.1 Flash на Gemini 3.5 Flash, но нельзя с Google-модели на Anthropic. Несколько ожидающих заказов делают поэтапную миграцию с перекрывающимися PT-резервами практичной: держи активным PT для старой модели, пока PT для новой модели стоит в очереди.

Предсказуемость для команд биллинга. PT — это обязательство: заказ нельзя отменить посреди срока. Несколько ожидающих заказов дают командам биллинга и FinOps единственный цикл согласования: один закупочный процесс авторизует весь план наращивания, вместо повторного согласования на каждом шаге активации.

Взгляд оператора маршрутизации

Для routing-команд ключевое изменение — в подходе к планированию мощностей Gemini:

До 1 июля: PT воспринимался как разовое обязательство. Для резерва использовался pay-as-you-go с принятием риска 429 или избыточный крупный заказ.

После 1 июля: Можно подавать план наращивания в виде очереди. Для команд, использующих Gemini как одну из целей в стратегии multi-provider routing, это означает возможность заблаговременно зафиксировать мощности GCP и использовать PT как надёжный уровень, а не fallback.

Превышение объёма активного PT по-прежнему тарифицируется по схеме pay-as-you-go. Это значит, что routing-fallback с PT → pay-as-you-go остаётся неизменным; несколько ожидающих заказов просто позволяют сужать это окно fallback по мере роста трафика.

Что проверить в политике маршрутизации:

• Убедитесь, что активный PT-квота покрывает базовый трафик: Ожидающий заказ — не активная мощность. В гарантию пропускной способности засчитывается только текущий активированный заказ.
• Single Zone PT по-прежнему требует прямого обращения к представителю GCP: Поддержка нескольких ожидающих заказов — только для стандартного PT. Single Zone Provisioned Throughput остаётся ручным процессом через продажи.
• Смена модели требует истечения текущего срока или ручного изменения заказа: Переназначение модели в PT-заказе вступает в силу при следующем продлении или через запрос на изменение, не мгновенно.

На что обратить внимание пользователям TheRouter

Если вы маршрутизируете трафик на Gemini 3.1 Pro, Gemini 3.5 Flash или любую модель Google через API gateway, изменение PT-очереди напрямую касается планирования уровней мощностей. Команды, уже использующие PT, теперь могут зафиксировать весь план наращивания за один раз. Команды на pay-as-you-go, откладывавшие переход на PT из-за сложности активационного окна, теперь имеют значительно меньшие координационные издержки.

Подробнее: Semantic Governance Policies для Gemini Enterprise Agent Platform — релиз управления политиками от 29 июня, вышедший одновременно с PT-обновлениями, и Gemini Model Armor Agent Gateway GA — уровень контентной безопасности для всего трафика через GCP Agent Gateway.