Система квот для Gemini-моделей на Vertex AI (aiplatform.googleapis.com). Ключевой факт: для Vertex AI Gemini-инференса Google перешёл с традиционной per-project RPM/TPM модели на spend-based tier system (бывший “Dynamic Shared Quota” / DSQ — переименован в Standard PayGo). Это меняет и то, как смотреть на квоты, и то, как их увеличивать.

Эта страница — только про Vertex квоты: тиры, лимиты, как мерить, что делать с 429. Кто из наших сервисов ходит через Vertex (а кто нет) — отдельно в llm-routing. Compliance причины почему мы переезжаем на Vertex — часть legacy-stack-migration § «LLM access».

Consumption options (5 вариантов)

OptionОписаниеЦена
Provisioned ThroughputГарантированная ёмкость с commitment (1 нед / 1 мес / 3 мес / 1 год). Единицы — GSUs (Generative AI Scale Units).Фиксированная
Standard PayGoPay-per-use, no commitment. Spend-based tier system (DSQ). Наш основной вариант.Стандартная
Priority PayGoПовышенный приоритет, ramp limits. Header: X-Vertex-AI-LLM-Shared-Request-Type: priority. Только global endpoint.1.8× стандарта
Flex PayGoLatency-tolerant workloads.0.5× стандарта
Batch InferenceAsync, high-volume.0.5× стандарта

Standard PayGo — тиры по расходу

Тир определяется rolling 30-day spend организации на eligible Vertex AI services. Никаких заявок, автоматически. Таблицы ниже официально перечислены в docs как применимые к Gemini 2.5 (Pro / Flash / Flash-Lite). Для Gemini 3.x (3-flash-preview, 3.1-pro-preview и т.д.) — preview-модели, docs прямо excludes: «Note that these tiers don’t apply to preview models». См. Открытые вопросы ниже.

Gemini 2.5 Pro:

Тир30-дневный расходBaseline TPM
Tier 1250500,000
Tier 22,0001,000,000
Tier 3>$2,0002,000,000

Gemini 2.5 Flash / Flash-Lite:

Тир30-дневный расходBaseline TPM
Tier 12502,000,000
Tier 22,0004,000,000
Tier 3>$2,00010,000,000

Gemini 3.x (preview-модели — мы их реально используем):

Docs: «Note that these tiers don’t apply to preview models». Эффективные лимиты для 3.x — не опубликованы.

Косвенный сигнал из gcloud (проверено gcloud alpha services quota list --consumer=projects/bg-prod-general 12 мая 2026):

  • gemini-3.1-flash-lite-qcd (суффикс -qcd — внутренний механизм Google “Quota Custom Delivery”) — explicit per-project cap 25M input TPM на global endpoint. В 2.5× больше чем Gemini 2.5 Flash Tier 3 (10M).
  • Для gemini-2.5-* и gemini-3.x-* без -qcd суффикса — effectiveLimit: -1 (нет per-project cap, applies org-level Standard PayGo).
  • Default fallback RPM = 5 per project per model на global endpoint для моделей без explicit override. Для gemini-1.5 — 200 RPM. Для gemini-2.5/3.x explicit нет — потенциально 5 RPM по умолчанию (требует verification).

RPM и burst behaviour

RPM: отдельного per-tier RPM лимита нет. Системный лимит — 30,000 RPM per model per region (для всех тиров).

Baseline TPM — это предсказуемый пол, не потолок. Docs прямо говорят:

«Your traffic isn’t strictly capped at the Baseline Throughput limit. Vertex AI lets traffic burst beyond this limit on a best-effort basis.» — Vertex AI Standard PayGo docs

При высокой нагрузке на платформу excess burst может деградировать.

Про RPM там же:

«There’s no separate requests-per-minute (RPM) limit for each tier. However, the system limit of 30,000 RPM per model per region applies.»

Caveat: docs называют это «Traffic TPM (Org-Level)» без явного указания input-only vs input+output. Для apples-to-apples сравнения с другими источниками (например, AI Studio paid tier колонкой «GenerateContent input token count limit») это важно учитывать.

Открытый вопрос — grant-кредиты vs tier qualification

Критично для BloodGPT (на май 2026): Billing Reports на нашем BloodGPT Billing account (017EE6-A9042C-3BFCA4) показывают:

  • May 1–11, 2026 на bg-prod-general: spent -€0.00 / saved -€1,457.20 (grant-кредиты Google полностью offset Vertex consumption)

Open question для Google rep: Standard PayGo tier qualification считает gross spend (до credits) или net (после)?

  • Если net — мы потенциально застряли в нижнем тире несмотря на usage; объясняет 429-затор не как «shared paygo capacity», а как нашу персональную низкую ёмкость пока credits hide spend от tier-counting механизма.
  • Если gross — нужно понять конкретное число и сравнить с порогами (2,000).

Параллельный сценарий другого кастомера: discuss.google.dev forum post — «Vertex AI Standard PayGo tier not recognized — Billing shows US$0 despite active Gemini usage». Без официального Google ответа в треде — known pattern, не наш уникальный edge case.

Priority PayGo — ramp limits

Не spend-тиры, а ramp limits на org-уровне. Разница:

  • Spend tier (Standard PayGo) — лимит растёт автоматически по мере роста 30-day spend организации; каждые 2,000 → следующий тир. Как узнать наш текущий тир — см. секцию «Как проверить свой тир» ниже.
  • Ramp limit (Priority PayGo) — начальный лимит, который растёт прямо от sustained трафика, независимо от потраченной суммы. Платить надо больше за токен (1.8×), но capacity ramp-ит быстро.

Supported models (на май 2026): gemini-3.1-flash-lite, gemini-3.1-pro-preview, gemini-3-flash-preview, gemini-2.5-pro, gemini-2.5-flash, gemini-2.5-flash-lite. Все 6 моделей подчиняются одной ramp-схеме (Pro / Flash старты различаются — таблица ниже).

СемействоСтартовый TPMРост
Pro1,000,000+50% каждые 10 мин sustained usage (потолок в docs не указан — см. вопросы ниже)
Flash4,000,000+50% каждые 10 мин sustained usage

Цена: 1.8× Standard PayGo. Проверено на pricing-странице — Gemini 2.5 Pro input 2.25/M (1.25 = 1.8). Применимо к Gemini 2.5 Pro / 2.5 Flash / 2.5 Flash-Lite / 3.x.

Если запрос превышает ramp limit при высокой нагрузке — downgrade до Standard PayGo (с соответствующей ценой).

Открытые вопросы — для следующего sync с Google rep на #bloodgpt-gcp

Готовые формулировки чтобы спросить (docs молчат):

  1. Потолок ramp. Priority PayGo Flash стартует с 4M TPM и каждые 10 мин sustained usage растёт на 50%. Через час это ≈45M, через два — ≈520M. Это реально так работает или есть hard cap? Если есть — какой, и от чего зависит?
  2. Decay при падении трафика. Что происходит с ramp limit когда трафик падает? Сбрасывается обратно к стартовому уровню (4M Flash / 1M Pro)? С какой скоростью decay’ит?
  3. Definition of “sustained”. Как формально определяется “sustained usage” — какой % текущего ramp limit нужно держать, чтобы он рос? Что считается за 10-минутное окно — непрерывная нагрузка или какое-то усреднение?
  4. Programmatic tier detection. Есть ли API / gcloud команда / Console widget чтобы узнать текущий Standard PayGo tier нашей организации без прокидывания через Billing Reports? gcloud services quota list на project-уровне для Gemini 2.5/3.x возвращает effectiveLimit: -1 — tier на org-уровне невидим из project-scope (проверено 12 мая 2026).
  5. Grant credits → tier qualification. Standard PayGo tier qualification считает gross spend (до credits) или net (после)? У нас Google grant полностью offset Vertex consumption → Billing showing €0 несмотря на usage. Это критично — определяет реальный tier для нашей org. (Подробнее в Open Question грант vs тир.)
  6. Gemini 3.x tier numbers. Docs explicitly excludes preview models from tier framework. Какие effective limits для gemini-3.1-pro-preview, gemini-3-flash-preview, gemini-3.1-flash-lite? Что значит -qcd суффикс для gemini-3.1-flash-lite-qcd с 25M TPM в нашем project quota — это allocated нашей org или generic baseline?

Источники: Vertex AI Priority PayGo docs, Vertex AI pricing.

DSQ — ребрендинг

Раньше система называлась Dynamic Shared Quota (DSQ), теперь — Standard PayGo. Это переименование, не смена механики.

Старая ссылка из доки .../dynamic-shared-quota всё ещё работает, но открывает уже новую страницу про Standard PayGo. В старых материалах термин DSQ означает то же самое.

Технические детали редиректа (проверено curl -sI 12 мая 2026):

GET cloud.google.com/.../dynamic-shared-quota → 301
Location: docs.cloud.google.com/.../dynamic-shared-quota

Меняется только host (cloud.google.comdocs.cloud.google.com), path тот же; на новом host’е страница уже содержит контент Standard PayGo.

Как проверить свой тир (Vertex AI)

Прямой “You are Tier X” UI в текущей консоли не нашёлся. Per docs: «To verify the usage tier for your organization, go to the Vertex AI Dashboard on the Google Cloud console» — но на май 2026 Cloud Console rebranded Vertex как “Agent Platform” (URL /agent-platform/ вместо /vertex-ai/), и явного tier-widget на Overview-странице не видно. Возможно widget в submenu, или ещё не появился после rebrand.

Косвенные методы — ниже. TL;DR: самый рабочий — Billing Reports.

Метод 1 — Billing Reports (через 30-day spend) — рабочий

URL: https://console.cloud.google.com/billing/<billing-account-id>/reports (для нас billing account = 017EE6-A9042C-3BFCA4).

Filters:

  • Service = “Vertex AI” (или “Agent Platform” если rebrand применился в SKU naming)
  • Time range = Last 30 days
  • Projects = расширить до всех BG-проектов (по умолчанию может быть только 1 с активностью)

Полученная “Usage cost” колонка (gross, до credits) → по таблице:

  • 10 → Free tier
  • 250 → Tier 1
  • 2,000 → Tier 2
  • $2,000 → Tier 3

⚠️ Открытый вопрос: считаются ли gross spend или net (после credits). См. секцию выше про grant credits. У нас net = €0 потому что credits offset всё.

Метод 2 — Quotas & System Limits в Cloud Console (НЕ работает для Gemini 2.5/3.x)

Console > IAM & Admin > Quotas & System Limits → фильтр “Vertex AI API”.

Verified ineffective for Gemini-inference tier detection (12 мая 2026):

  • Видны только traditional adjustable квоты (embedding TPM, RAG retrieval RPM)
  • Для gemini-2.5-* и gemini-3.x-* без -qcd суффикса — effectiveLimit: -1 (нет per-project cap)
  • Effective TPM live на org-уровне через Standard PayGo и недоступен из project-scope

Если кидаешь скриншот с грануларными per-model квотами вроде gemini-3-flash 20M input TPM — это Gemini API / AI Studio (generativelanguage.googleapis.com), не Vertex AI. См. llm-routing про разделение.

Метод 3 — gcloud CLI (verified ineffective для Gemini 2.5/3.x на project-scope)

gcloud alpha services quota list --service=aiplatform.googleapis.com \
  --consumer=projects/bg-prod-general

36k+ строк output. Для Gemini 2.5 / 3.x без -qcd суффикса — defaults -1 (org-level Standard PayGo применяется, project-scope её не видит).

Что видно явно (только legacy/preview-варианты): gemini-1.5-flash 4M TPM / 200 RPM; gemini-1.5-pro 4M / 60 RPM; gemini-3.1-flash-lite-qcd 25M / нет per-project RPM override; default RPM = 5 для моделей без override.

Метод 4 — Cloud Quotas API (org-scope требует разрешений)

curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "https://cloudquotas.googleapis.com/v1/organizations/851696520046/locations/global/services/aiplatform.googleapis.com/quotaInfos"

Verified 12 мая 2026 на org 851696520046: возвращает {} без org-level quota viewer перм. Нужен cloudquotas.viewer на org уровне (default user rights его не дают).

429 Too Many Requests

Корневая причина (от Google rep)

Capacity на каждом endpoint (region/global) — shared pool для всех PayGo customers, не персональная квота. Google rep ответил нам в нашем #bloodgpt-gcp канале1:

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

То есть «в Vertex-консоли чисто, но 429 летят» — это не персональный лимит, это давка на shared endpoint в пик.

Mitigation hierarchy (от Google rep, 7 апреля 20262)

  1. Priority PayGo — самое быстрое решение, рекомендовано rep’ом явно3: «самое быстрое решение это использовать Priority Pay Go». Включается клиентом через header, не требует одобрений.
  2. Global Endpoint + при 429 на нём — временно переключаться на regional (или наоборот). Caps independent.
  3. Exponential Backoff на retry.
  4. Async UX — там где можно: например, generate-then-email вместо UI-ожидания.
  5. Caching: implicit активен by default, проверить explicit для known prompt-prefixes.
  6. Model Version Failover — fallback на другую модель если primary throws 429.
  7. Acceptable error rate <2% — заложен в SLA, не «всё всегда работает».

Что НЕ сработало

  • Custom Tier (повышенные org-level лимиты): запрос подан 20 марта 2026 07:354, SLA «5 business days», ответ пришёл 7 апреля 2026 11:495: «Custom Tier was not approved…». Денайл финальный, не pending.
  • Provisioned Throughput — rep3 сказал «не думаю что PT подойдёт» для нашего профиля; estimation tool показывает «заоблачные цены» (Артём, 25 марта6).
  • Spend ramp-up до следующего тира — chicken-and-egg на 19 марта 2026 (Артём7): «не можем переключиться, тк упираемся в 429 быстро, соответственно чек набить не сможем чтобы автоматически тир поднять». Current state на 12 мая 2026 — см. секцию routing observations в llm-routing (миграция частичная, .NET API ещё на AI Studio).

Контакты

Канал #bloodgpt-gcp (Slack C0AESA1QUM6). Google reps: U091G1AEQ1L, U0AEQ7VSB5J (tech evangelists, помогают с квотами и 429 mitigation). Из нашей команды по квотам обычно: Сергей (splotel) — quotas/account, Юрий — архитектор. От нас по квотам исторически — Артём (aevsai).

Источники

Google Cloud docs

Slack #bloodgpt-gcp (C0AESA1QUM6)

Сессии Claude (research)

  • Сессия 2026-04-07 (ff:search Vertex + #bloodgpt-gcp thread research) — /home/i/.claude/projects/-home-i-projects-fireflies-tool/f0967708-4385-43f2-b444-bdd8ee2fce09.jsonl
  • Сессия 2026-05-12 (verification pass + rewrite, routing audit) — chain 7cb6186b

Связано

  • llm-routing — какие сервисы реально ходят через Vertex (а кто нет)
  • legacy-stack-migration — общая миграция legacy-стэка, включая .NET → bifrost/Vertex routing’овый аспект

Сноски

Сноски

  1. Google rep, Slack #bloodgpt-gcp, 25 марта 2026 08:44 — https://realaicorp.slack.com/archives/C0AESA1QUM6/p1774428245220409

  2. Google rep, полный список mitigation’ов, Slack #bloodgpt-gcp, 7 апреля 2026 — https://realaicorp.slack.com/archives/C0AESA1QUM6/p1775562484448549

  3. Google rep, Slack #bloodgpt-gcp, 25 марта 2026 08:26 — https://realaicorp.slack.com/archives/C0AESA1QUM6/p1774427200084849 2

  4. Запрос Custom Tier подан, Google rep в Slack #bloodgpt-gcp, 20 марта 2026 07:35 — https://realaicorp.slack.com/archives/C0AESA1QUM6/p1773992129793889

  5. Денайл Custom Tier, Google rep в Slack #bloodgpt-gcp, 7 апреля 2026 11:49 — https://realaicorp.slack.com/archives/C0AESA1QUM6/p1775562595328079

  6. Артём (aevsai), Slack #bloodgpt-gcp, 25 марта 2026 07:45 — https://realaicorp.slack.com/archives/C0AESA1QUM6/p1774424701898679

  7. Артём (aevsai), Slack #bloodgpt-gcp, 19 марта 2026 11:50 — https://realaicorp.slack.com/archives/C0AESA1QUM6/p1773921050866729