Google Cloud открыла общий доступ к квотам на токены для генеративных функций BigQuery: четыре дневных лимита на проект и пользователя

Что объявили

Генеративные функции BigQuery (AI.GENERATE, AI.IF, AI.CLASSIFY, AI.SCORE и другие) заводят большие языковые модели прямо в SQL: один запрос может разметить миллионы обращений в поддержку или оценить тональность каждого отзыва о товаре. Плата при этом идёт по токенам, и при масштабировании на огромные наборы данных бюджет нужно контролировать заранее. Именно эту задачу и закрывает анонс: Google Cloud объявила об общей доступности управления стоимостью по токенам для генеративных функций BigQuery — дневных квот, которые администраторы выставляют самостоятельно как защитные рамки на потребление ИИ-токенов.

Материал подписан инженером-программистом Tushar Jaiswal и developer advocate Alicia Williams. Основная механика — не отчёт постфактум, а ограничение сверху: квоты живут в системе квот Google Cloud Identity and Access Management (IAM), то есть в том же месте, где администратор управляет остальными лимитами проекта.

Четыре квоты и их значения по умолчанию

Квот четыре, и они разведены по уровню проекта и по уровню пользователя. «Входные токены ИИ в день» — входные токены, использованные моделью: по умолчанию 200 млрд в день на проект. «Входные токены ИИ в день на пользователя» — 150 млрд в день на проект и на пользователя. «Выходные токены ИИ в день» — выходные и «размышляющие» токены (thinking tokens) модели: 20 млрд в день на проект. «Выходные токены ИИ в день на пользователя» — 15 млрд в день на проект и на пользователя. Пользовательские лимиты действуют внутри проекта, а не по всей организации.

Две детали, которые чаще всего путают. Квоты глобальные: расход суммируется по всем регионам, поэтому затраты не могут «накопиться незаметно» в регионе, который никто не смотрит. И выходные квоты включают токены рассуждений — reasoning-токены считаются в выходной лимит ровно так же, как они попадают в счёт за платформу Gemini.

Какие функции покрыты, а какие нет

Под квоты попадают генеративные функции, которые обращаются к языковой модели за генерацией: AI.GENERATE, AI.GENERATE_TABLE, AI.GENERATE_TEXT вместе с псевдонимом ML.GENERATE_TEXT, а также AI.CLASSIFY, AI.IF, AI.SCORE и AI.AGG. Функции эмбеддингов — AI.GENERATE_EMBEDDING он же ML.GENERATE_EMBEDDING, и AI.EMBED — под эти квоты не попадают: они работают на других, существенно более дешёвых моделях, и Google намеренно оставил их вне лимитов.

Как этим управлять

Выставлять квоты можно из консоли Google Cloud: раздел IAM & Admin → Quotas & System Limits, фильтр по сервису и выбор BigQuery API, затем сортировка по колонке Name, чтобы четыре ИИ-квоты оказались наверху, и правка нужного значения через меню. Понижение действует сразу и не требует одобрения; запрос на повышение отправляется с той же страницы, многие заявки одобряются автоматически, а крупные проходят короткую проверку. Прав не хватит без одной из ролей: Owner, Editor, Quota Administrator (roles/servicemanagement.quotaAdmin) или Service Usage Admin (roles/serviceusage.serviceUsageAdmin).

Для автоматизации Google предлагает Cloud Quotas API, CLI gcloud и Terraform — так одинаковые рамки можно разложить по множеству проектов. Та же страница квот показывает историческое потребление токенов и графики с выбираемым окном в 7, 14, 30 дней или произвольным диапазоном: по ним видно всплески и можно подогнать бюджет под реальные нагрузки и новые конвейеры данных.

Как именно срабатывает ограничение

Работа останавливается, а не «перетекает» за лимит. Запрос отклоняется сразу с ошибкой QuotaExceeded только в одном случае — если нужная квота уже исчерпана. Иначе запрос стартует, и если квота закончится в середине работы, BigQuery перестаёт отправлять новые вызовы модели. Дальше поведение зависит от функции: те, что поддерживают max_error_ratio (например, AI.IF), возвращают частичные результаты, если доля необработанных строк укладывается в заданное отношение, и в противном случае падают с ошибкой; универсальные функции вроде AI.GENERATE завершаются успешно, но у пропущенных строк нет сгенерированного значения, а их поле status содержит ту самую ошибку о превышении квоты.

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

Токены в деньги: пример на $100 в день

Google приводит рабочий расчёт для проекта, который хочет держать дневные расходы на ИИ около $100 на модели Gemini 3.1 Flash-Lite. При действующих ценах и пакетной обработке BigQuery (она даёт 50 % скидки) входные токены стоят $0.125 за 1 млн, выходные — ответ и рассуждения — $0.75 за 1 млн. Если пробный прогон на небольшой выборке показывает среднее соотношение входных токенов к выходным 100:1, то решение системы уравнений даёт примерно 754 млн входных и 7,54 млн выходных токенов в день: эти значения и надо поставить в квоты AI input tokens per day и AI output tokens per day, чтобы удерживать проект около $100 в сутки. Если в проекте несколько моделей с разными ценами, бюджет считают по каждой отдельно или смешивают ставки.

Чем это отличается от лимитов на расходы и что советуют

В Google Cloud есть второй защитный механизм — лимиты на расходы (spend caps) в Cloud Billing. Разница принципиальная: квоты на токены превентивны и специфичны для ИИ — BigQuery считает потребление токенов во время выполнения запроса и останавливает работу у самого лимита, отдельно на проект и на пользователя. Лимиты на расходы работают в долларах на уровне проекта и сервиса и могут автоматически блокировать использование при достижении порога, но это широкий финансовый «последний рубеж», а не точное управление: принуждение срабатывает не мгновенно, поэтому часть перерасхода всё же возникает. Вывод Google: квоты на токены — первая линия защиты от расходов на ИИ, а лимит на расходы — страховка на весь проект.

Рекомендации из публикации короткие: начинать с пользовательских квот, потому что именно они не дают одному пользователю или одному разогнавшемуся эксперименту выпить бюджет проекта; измерять до масштабирования — сначала AI.COUNT_TOKENS для входа, затем пробный прогон и график потребления, и только потом ставить пределы; помнить про выходную сторону, где токены дороже, и ограничивать длину генерации через max_output_tokens там, где функция его принимает; и пересматривать лимиты по мере изменения реального расхода и бюджета.