Многие люди уверены: если агент то зовёт дешёвую модель, то сильную — в коде неизбежно живут три разных клиента, ключи и домашний прокси. Им кажется, иначе никак.
Точнее, иначе уже можно. Google вынесла выбор модели из кода в управляемый шлюз — API Gateway. Один вход. Имя модели в настройках. Дальше шлюз сам решает, куда стукнуть.
Это ещё не «навсегда и для всех». Но смысл сдвига понятен: вместо своего процесса-посредника — управляемый край с одним адресом.
Почему всем сразу нужен зоопарк SDK в коде агента? Почему никто не хочет один вход и таблицу имён моделей сбоку? Почему хайп всегда про «какая модель умнее», а не про то, кто таскает ключи между окнами?
Ну … ключи таскаете вы. Пока выбор модели сидит в приложении, вы — курьер. Вынесли выбор в шлюз — курьер уже не вы.
Что именно пустили в шлюз
В начале августа Google открыла публичный предпросмотр маршрутизации запросов к языковым моделям в API Gateway. Анонс — в блоге для разработчиков, фиксация в заметках о релизе.
Вход принимает запрос в привычной форме чата OpenAI. На лету перекладывает его в схему бэкенда и отдаёт на модели внутри платформы агентов Google — Gemini, Claude или OpenAI OSS-GPT через Vertex / Model Garden.
В примерах документации бэкенды такие: google/gemini-3.5-flash-lite, anthropic/claude-opus-4-7, openai/gpt-oss-120b-maas. Всё на одном хосте aiplatform.googleapis.com (или одном региональном). Claude и OSS-GPT здесь идут через Vertex, не как «три чужих облака в одном роутере».
Независимые сводки той же недели — getaibook и AI Insiders — подтверждают дату и форму входа. Соседние релизы недели (балансировщик с сессиями, оценки агентов) — другие продукты. Герой этой статьи — только маршрутизация моделей.
Один вход, выбор по имени модели
Клиент шлёт обычный запрос с сообщениями — как к openai-совместимому чату. Шлюз сам перекладывает запрос в схему бэкенда и подставляет токен доступа платформы агентов.
Приложение логинится к Gateway, не к каждому поставщику моделей. Ротация секретов бэкенда — без правок клиента. Ну … это и бесило больше всего, когда ключи жили в трёх SDK сразу.
В публичном предпросмотре правило выбора одно: поле «model» в JSON. Нет совпадения в таблице роутера — уходит на запасной defaultModel. Маршрутизации «по цене» или «по задержке» пока нет: только имя модели в конфиге.
Сюрприз формата: вход говорит на схеме OpenAI; Gemini в примере — один из бэкендов рядом с Claude, не «нативный» запрос от клиента. Спрашивается — какой смысл тащить три клиента, если один формат уже приняли сами?
Все просто: пока выбор модели сидит в коде, вы — курьер между SDK. Вынесли в шлюз — курьер уже не вы.
Как это собирают в конфиге
Нужен OpenAPI 3.x с расширениями Google: backends плюс таблица роутеров моделей, а на операции POST — указатель роутера. Старый OpenAPI 2.0 / Swagger не поддерживаются. Поставить роутер на корень пути или на не-POST нельзя.
Все бэкенды одного роутера обязаны делить один hostname и одну схему. Это не маршрутизация на чужие облака вне Vertex / платформы агентов.
Жизненный цикл шлюза жёсткий. Нельзя «дописать» маршрутизацию моделей на уже задеплоенный gateway без неё. Нельзя снять роутинг с gateway, где он уже есть. Нужен новый конфиг API и новый экземпляр. В одной спецификации нельзя смешивать операции с роутером моделей и обычные бэкенды Google.
Адрес предпросмотра — на *.run.app; брать URL только после статуса ACTIVE. Для деплоя — роль администратора API Gateway; у сервисного аккаунта шлюза — право пользоваться AI Platform. Модели должны быть заранее выложены как открытые модели по запросу в Model Garden. Подробности: настройка и обзор.
Где предпросмотр ещё кусается
Статус — публичный предпросмотр: без гарантий уровня SLA; поверхность конфига может меняться. Так и пишут независимые разборы недели.
- Только текстовый JSON в openai-форме. Потоковая отдача ответа — да. Потоковая отправка запроса, gRPC, WebSockets и живой Gemini Live — нет. Максимальный таймаут шлюза — 3600 секунд.
- Контроль периметра VPC и Private Service Connect — не поддерживаются.
- Баг предпросмотра: если в теле запроса нет поля model, шлюз обрабатывает запрос криво вместо явной ошибки. Поле нужно слать всегда.
- В логах есть hostname бэкенда, но нет точной атрибуции «какая именно модель ответила» — все бэкенды на одном хосте. Структурированные логи решения роутера — «в будущем».
- Ошибки роутера в логах: model_router_application_error, _timeout, _upstream_error, _unavailable.
- Для openai-совместимого бэкенда подставить короткий alias вместо валидного id издателя (например openai/gpt-oss-120b-maas) — получить 400 Malformed publisher model.
Стек рядом: шлюз можно держать отдельно (лимит частоты + учёт токенов) или связать с Agent Gateway для контроля исходящего трафика, а API Gateway оставить под динамический роутинг. Apigee — соседний слой спектра, не синоним этой фичи.
Что сделать руками, если пробуете
- Не ждать, что роутинг «включат» на старом gateway — планировать новый конфиг API и новый экземпляр.
- Держать один hostname для всех бэкендов роутера; не смешивать роутинг моделей и обычные бэкенды в одном OpenAPI.
- Всегда слать model в JSON; запасной путь — defaultModel.
- Проверять, что нужные модели уже выложены в Model Garden; брать URL только после ACTIVE.
- Не рассчитывать на VPC-периметр, чужие облака вне одного хоста платформы агентов и на точную атрибуцию модели в логах — этого в предпросмотре нет.
Куда смотреть дальше
Ритм агентов, Make и Cursor — в канале Ковчег и в MAX. Если нужен каркас под автоматизацию с нейросетями без зоопарка SDK — обучение Cursor + Make + AI.
Первичный анонс: Google Developers Blog — unified API for AI model routing. Документация: обзор, настройка, заметки о релизе.
