Google запустил единый API для маршрутизации запросов к разным нейросетям

Google Cloud API Gateway получил функцию маршрутизации моделей — теперь разработчики могут направлять запросы к Gemini, Claude или GPT через единый шлюз, не привязываясь жёстко к одному провайдеру.

Шлюз, который сам решает, какую нейросеть вызвать — это уже не мечта, а публичная бета от Google.

Представьте: вы пишете приложение с искусственным интеллектом и хотите, чтобы одни задачи решал Gemini, другие — Claude, а третьи — модель от OpenAI. Раньше это означало три разных эндпоинта, три ключа, три набора документации и головную боль при каждом изменении логики. Теперь Google предлагает всё это завернуть в один API-шлюз, который сам разберётся, куда отправить запрос.

Что именно запустили

Google Cloud API Gateway получил функцию model routing — маршрутизации запросов к разным языковым моделям. Функция пока в публичной бете, но уже работоспособна. Шлюз принимает запросы в формате, совместимым с OpenAI (то есть тот же самый API, который используют тысячи приложений по всему миру), и на лету перенаправляет их к нужной модели: Gemini, Claude от Anthropic или OpenAI OSS-GPT.

Главное удобство — разработчику не нужно хардкодить конкретные адреса серверов или поднимать прокси-серверы с открытым исходным кодом. Вся логика маршрутизации описывается прямо в спецификации API, и шлюз разбирается сам.

Зачем это нужно на практике

Каждая нейросеть хороша в своём. Gemini быстр и дешёв для массовых задач, Claude славится длинным контекстом и аккуратностью рассуждений, модели GPT проверены миллионами пользователей. Умный разработчик хочет использовать лучшее из каждого мира — и менять провайдера, когда это выгодно, без переписывания кода.

До этого инструмента выбор модели жёстко зашивался в приложение. Хочешь поменять — лезь в конфиги, переписывай эндпоинты, тестируй заново. С model routing всё проще: приложение отправляет запрос на единый адрес, а в теле запроса указывает, какую модель хочет использовать. Шлюз сам транслирует формат и перенаправляет туда, куда нужно.

Это похоже на то, как навигатор выбирает маршрут: вам всё равно, по какой улице ехать, — вы говорите «на вокзал», а приложение само решает, куда повернуть.

Как это устроено изнутри

Технически маршрутизация настраивается через специальный блок x-google-api-management в OpenAPI-спецификации версии 3.x. Там разработчик описывает два типа сущностей:

Бэкенды — конкретные адреса моделей. Каждому бэкенду сопоставляется виртуальное имя (например, gemini-35-flashlite или anthropic-claude-opus-47) и реальный URL на Vertex AI.

Роутеры — логика маршрутизации. У каждого роутера есть модель по умолчанию и набор правил: если в запросе указано имя «claude-opus-4-7», отправляй на Claude, если «gemini-3.5-flash-lite» — на Gemini, и так далее.

После деплоя конфигурации приложение просто шлёт стандартный POST-запрос на /v1/chat/gemini-claude — и шлюз сам понимает, куда направить обращение. Формат запроса не нужно менять: всё совместимо со стандартом OpenAI.

Ограничения, которые стоит учитывать

Есть важная деталь, которую Google упоминает мимоходом, но она существенна: все бэкенды внутри одного роутера должны находиться на одном хосте. В примере это aiplatform.googleapis.com. То есть шлюз маршрутизирует между разными моделями внутри Vertex AI, но не перекидывает запросы между принципиально разными инфраструктурами.

На практике это не так страшно — Vertex AI уже хостит и Gemini, и Claude, и модели OpenAI. Но если вы планировали направлять часть трафика напрямую к Anthropic или на собственные серверы, через этот шлюз так просто не получится.

Также стоит помнить: публичная бета означает, что API может меняться. Для продакшн-систем критически важных сервисов пока рано ставить на это всё.

Для кого это реально полезно

Прежде всего — для стартапов и небольших команд, которые экспериментируют с разными моделями. Если вы строите чат-бота и хотите протестировать, как Gemini справляется с короткими ответами, а Claude — с длинными аналитическими выкладками, model routing избавит вас от боли с переключением эндпоинтов.

Вторая аудитория — команды, использующие агентные платформы. Google предлагает связать API Gateway с Gemini Enterprise Agent Platform: агентные запросы проходят через Agent Gateway для безопасности, а потом API Gateway решает, какую модель задействовать. Схема изящная, но требует вендорной привязки к экосистеме Google.

Прагматичный взгляд

Google делает хитрый ход: предлагая единый шлюз, совместимый с OpenAI-форматом, они снижают порог входа для тысяч разработчиков, которые уже привыкли к этому стандарту. Фактически Google говорит: «Не хотите замыкаться на Gemini? Не надо. Вот шлюз — ставьте Claude и GPT тоже, но через нашу инфраструктуру».

Это одновременно и удобно, и прагматично со стороны Google. Ведь каждый запрос, проходящий через их шлюз — это точка контроля, логирования и потенциального мониторинга. Разумеется, Google декларирует поддержку rate limiting и трекинга токенов, но для кого-то этот уровень видимости со стороны облачного провайдера может быть неудобен.

Для простых пользователей ничего не меняется напрямую. Но для разработчиков, которые строят AI-продукты, это ещё один шаг к тому, чтобы нейросети стали взаимозаменяемым ресурсом — как электричество из розетки, где вам не важно, кто именно генерирует ток.