Google Cloud API Gateway model routing: spec-first routing и важное ограничение по host

Google Cloud API Gateway model routing вышел в Public Preview 4 августа. Для платформенных команд это означает serverless-способ выставить один OpenAI-compatible endpoint и маршрутизировать запросы к Gemini, Claude или OpenAI OSS-GPT за Vertex AI. Самая важная деталь не в том, что Google добавил router. Важно, где он находится: внутри OpenAPI 3.x specification, в расширении Google x-google-api-management, где выбор модели описывается конфигурацией, а не кодом gateway.

Для команд, которые уже стандартизируют model calls на Vertex AI, это аккуратный путь миграции. Для команд, которые смешивают Vertex с DashScope, прямым Anthropic API или другими provider hosts, у preview есть жесткая граница. Ее лучше увидеть до того, как кто-то пообещает один универсальный router.

Google Cloud API Gateway model routing переносит routing в OpenAPI

Preview позволяет операторам описывать model routers прямо в OpenAPI document. У router есть defaultModel и массив rules[], а каждая model указывает на named backend. В опубликованном примере virtual model names вроде claude-opus-4-7 сопоставляются с Vertex AI backend paths, например с Anthropic publisher endpoint на aiplatform.googleapis.com.

Такой дизайн меняет границу между application team и platform team. Раньше clients часто хардкодили полный Vertex AI path вроде https://aiplatform.googleapis.com/v1/projects/... для каждой модели. После миграции команда может выставить стабильный endpoint вроде /v1/chat/gemini-claude, оставить client знакомый OpenAI-style body с "model": "claude-opus-4-7", а mapping backend paths держать в API spec.

Google также оставляет client authentication на границе Gateway. Clients проходят auth в API Gateway, а не у каждого model provider. Rate limiting и token tracking тоже находятся в managed layer. Это привлекательно, если команда хочет меньше proxy-процессов, которые надо патчить, масштабировать и наблюдать.

Google Cloud API Gateway model routing имеет границу общего host

Ограничение стоит вынести в engineering review. Google указывает, что все backends, на которые ссылается один router, должны иметь один и тот же host, например aiplatform.googleapis.com. Routing выбирает другую model и path на этом общем Agent Platform host. Он не маршрутизирует между разными hosts.

Практический вывод прямой. Нельзя положить Vertex-hosted Gemini backend, прямой Anthropic API и DashScope в один Google API Gateway router. Если команде нужен такой provider mix, ей нужны отдельные gateways или code-level proxy перед Google API Gateway, который примет cross-host decision раньше.

В конфигурации это можно проверять в конкретном месте: x-google-api-management.ai.models.routing.routers.<name>.defaultModel.backend. Если этот backend находится в router, где другие models не делят тот же host, дизайн уже выходит за форму текущего preview.

Spec-first routing против code-level proxy routing

Подход Google хорошо показывает spec-first AI gateway design. Routing policy живет рядом с HTTP contract. Platform team может ревьюить его как configuration, применять обычные controls API Gateway и не запускать еще один open-source proxy tier.

Это другой компромисс, чем code-level router вроде LiteLLM или custom TheRouter-style gateway. Code-level routing может принимать решения между provider hosts, совмещать Vertex и direct APIs, добавлять custom fallback logic и нормализовать нестандартное поведение responses. За это команда платит владением service, deployment, rate-limit behavior и failure modes.

Azure API Management Unified Model API ближе к той же spec-first группе, но его cross-provider story шире. Google preview более opinionated. Вы получаете managed serverless router, если ваш backend universe уже находится на Vertex AI.

Такая позиция может быть полезной. Она сокращает operational surface area. Но она же делает architecture менее portable. Правильный выбор зависит от того, решаете ли вы model selection внутри Vertex или provider selection между clouds и vendors.

Что TheRouter operators стоит изменить сейчас

Если ваша команда уже пропускает model calls через Vertex AI, preview стоит проверить за не критичным route. Начните с одного low-risk chat endpoint, сопоставьте две Vertex-hosted models и сравните token tracking, latency и error reporting с вашим текущим gateway. Общая TheRouter documentation полезна как checklist по provider identity, model names и client compatibility перед изменением production traffic.

Если architecture проходит через несколько provider hosts, считайте shared-host constraint Google входным параметром дизайна, а не сноской. Cross-provider policy должен оставаться в router layer, который действительно видит каждого provider. API Gateway можно использовать как managed edge для Vertex-hosted traffic или как один hop внутри более крупной routing system.

Ближайший migration pattern прост:

• Перевести clients с hardcoded Vertex model URLs на один стабильный Gateway path.
• Сохранить virtual model names стабильными в client payloads.
• Держать Vertex backend paths в OpenAPI spec, а не в application code.
• Оставить cross-host routing вне этого preview, пока Google не расширит host model.

Последний пункт лучше всего объясняет значение анонса. Google Cloud API Gateway model routing является полезным managed primitive, но не универсальным multi-provider router. Для команд, которые недавно следили за более широкой Vertex AI Agent Platform migration, направление знакомое: больше agent и model traffic уходит в managed Google infrastructure, а затем команда отдельно решает, где open routing все еще должен оставаться снаружи.