Маршрутизатор моделей на GCP: один управляемый API перед несколькими открытыми LLM

Большинство корпоративных LLM-проектов начинаются с одного вопроса: какую модель должно вызывать приложение? Когда в организации работает несколько моделей, этот вопрос превращается в проблему. Модели различаются сильными сторонами, задержкой, потребностью в ресурсах и доступностью. Если жёстко прописать модель в каждом приложении-потребителе, эти решения уходят не на тот уровень системы.

Правило почище такое: приложения запрашивают ИИ-возможность, а ИИ-инфраструктура решает, какая модель её выполнит. В схеме, построенной для интеграции Workato с открытыми LLM на GCP, маршрутизатор моделей стоит перед четырьмя моделями с открытыми весами и предоставляет их через единый управляемый API. Маршрутизатор в итоге оказался интереснее, чем само развёртывание моделей.

От интеграции моделей к их абстрагированию

Привычная схема — прямая линия:

Application
    │
    ▼
Specific LLM

Добавьте ещё моделей, и она распадается на отдельную проводку для каждого приложения:

Application A ──► Model A
Application B ──► Model B
Application C ──► Model C

Теперь каждое приложение должно знать имена моделей, эндпоинты, аутентификацию, возможности, доступность, резервные модели и, вероятно, параметры инференса. Лучше развернуть эти отношения наоборот:

┌──► Model A
                    │
Enterprise          ├──► Model B
Application ─► Router
                    ├──► Model C
                    │
                    └──► Model D

Со стороны приложения есть единственный ИИ-сервис. Лишь маршрутизатор знает, что за ним стоит целый портфель моделей. Всё остальное в схеме держится на этой разделительной линии.

Общая архитектура

Снаружи схема остаётся простой:

Enterprise Consumers
                 │
       Workato / Applications
                 │
                 ▼
          GCP API Gateway
                 │
                 ▼
           Model Router
                 │
       ┌─────────┼─────────┐
       │         │         │
       ▼         ▼         ▼
    Model A   Model B   Model C   Model D
       │         │         │         │
       └─────────┴─────────┴─────────┘
                    │
               GPU Inference

Под ней лежат GCP, контейнеризированный инференс и vLLM. Для эксплуатации они важны, но интересной схему делают не они. Ценность ей придаёт шаг маршрутизации, стоящий между публичным контрактом API и движками, которые выполняют инференс.

Что на самом деле делает маршрутизатор

Маршрутизатор — больше, чем обратный прокси. Прокси решает, куда отправить HTTP-запрос. Маршрутизатор моделей решает, какая модель должна выполнить ИИ-нагрузку. Каждый запрос проходит четыре этапа:

Request
   │
   ▼
1. Validation
   │
   ▼
2. Workload classification
   │
   ▼
3. Candidate model selection
   │
   ▼
4. Execution + fallback
   │
   ▼
Normalized response

Благодаря этому клиентам не нужно называть физическое развёртывание. Вместо такого payload:

{
  "model": "physical-model-name",
  "prompt": "..."
}

публичный контракт может описывать логическую возможность:

{
  "task": "general_generation",
  "messages": [...]
}

Внутри платформы эта возможность разворачивается в ту модель, которую выберут:

general_generation
        │
        ▼
     Router
   /    |    \
  ▼     ▼     ▼
M1     M2     M3
        │
        ▼
selected model

Имена моделей становятся деталью инфраструктуры и перестают быть заботой приложения.

Выбор — это задача с ограничениями

Round-robin для этой работы не годится, потому что LLM — не взаимозаменяемые копии одного сервиса. Первый этап — отбор допустимых. Из всех развёрнутых моделей маршрутизатор выделяет подмножество, которое правомерно может обслужить запрос, исходя из таких факторов, как:

• работает ли модель
• поддерживает ли она запрошенную задачу
• нужная длина контекста
• свободная мощность инфраструктуры
• характер нагрузки

Только после этого начинается ранжирование. Общая функция оценки сочетает ожидаемую пригодность для задачи, ожидаемую задержку, стоимость инференса или нагрузку на ресурсы и текущую доступность, каждую из которых умножают на вес, выражающий её важность. Конкретные коэффициенты — вопрос политики реализации. Архитектурно важно, что выбор модели становится явной политикой и перестаёт быть случайностью конфигурации приложения.

Пример с четырьмя моделями

Представьте четыре модели с разными задачами:

Model A → general-purpose generation
Model B → stronger reasoning workload
Model C → lightweight / low-latency requests
Model D → alternate or fallback capability

Короткому запросу на классификацию или преобразование самая большая модель не нужна:

Short deterministic task
        │
        ▼
     Router
        │
        ▼
 Lightweight model

Запрос посложнее идёт другим маршрутом:

Complex reasoning task
        │
        ▼
     Router
        │
        ▼
 Higher-capability model

Это ещё и предотвращает знакомый антипаттерн — гонять самую дорогую модель на всём подряд просто потому, что она есть.

Резервирование — дело маршрутизатора

Выбор даёт обработке сбоев естественное место. Допустим, предпочтительный маршрут такой:

Request
   │
   ▼
Model B

Если эта модель нездорова, перегружена или пропала, сервису не обязательно сразу сдаваться. Таблица маршрутизации может задать цепочку альтернатив:

Preferred
   │
   ▼
Model B
   │
 failure
   ▼
Model A
   │
 failure
   ▼
Model D

Тогда маршрутизатор может различать две ситуации:

MODEL failure

и

AI SERVICE failure

Это не одно и то же, и различать их выгодно с открытыми моделями, где пробуют новые рантаймы или версии и ничто из этой нестабильности не должно доходить до корпоративных пользователей.

Стабильный контракт поверх меняющихся моделей

Самое ценное свойство — то, что остаётся неизменным. С точки зрения Workato этот эндпоинт никогда не меняется:

POST /v1/chat/completions

За ним картина со временем меняется. Вначале:

Today

затем примерно такая эволюция:

Router ──► Model A
LaterRouter ──► Model B
Later stillRouter ──► Models A/B/C/D
           selected dynamically

Бизнес-процесс не меняется совсем. Вот это и есть развязка на практике. ИИ-команда может свободно менять версии моделей, настройки рантайма, выделение GPU, правила маршрутизации, приоритеты резервирования и даже целое семейство моделей, не трогая ни одного корпоративного процесса.

Зачем интерфейс, совместимый с OpenAI

Слой инференса работает на vLLM, который предоставляет HTTP-интерфейс, совместимый с OpenAI. Польза не в зависимости от OpenAI. Просто такая форма API стала практическим стандартом совместимости. Поток выглядит так:

Client
   │
   │ standard request
   ▼
Router
   │
   │ model-specific decision
   ▼
Inference runtime
   │
   ▼
Open model

Ответы на обратном пути тоже можно нормализовать. Поэтому маршрутизатор изолирует два вида изменений:

Northbound
Stable enterprise API

──────── Router boundary ────────Southbound
Changing models and runtimes

Это та же работа, которую слой абстракции выполняет и в других распределённых системах.

Намеренно скучный слой GCP

Поддерживающая инфраструктура нарочно традиционна:

Workato
   │
   ▼
API Gateway
   │
   ▼
Containerized Router
   │
   ▼
vLLM inference
   │
   ▼
Open-weight models

Артефакты моделей могут лежать в Cloud Storage и монтироваться в среду инференса, так что их не нужно запекать в образы приложений. API Gateway обозначает внешнюю границу. Для proof of concept достаточно аутентификации по API-ключу, чтобы доказать путь интеграции. Продакшен-нагрузкам с чувствительными данными нужно больше: настоящий контроль идентичности, аутентифицированные сервисы, приватная сеть, квоты, централизованные логи и полноценное хранилище секретов.

Цель не в том, чтобы придумать новый шаблон развёртывания на GPU. А в том, чтобы всё под абстракцией маршрутизации оставалось заменяемым.

Workato как потребитель, а не рантайм

Это меняет зону ответственности Workato. Он должен понимать бизнес-процесс:

business event
     ↓
business workflow
     ↓
AI capability request

Ему не должно быть дела ни до чего из следующего:

GPU
model checkpoint
vLLM process
context limits
model health
fallback order
routing policy

Это забота ИИ-платформы. Интеграция сводится к простому вызову:

Workato Recipe
      │
      ▼
HTTP request
      │
      ▼
Governed AI API

Другие потребители могут пользоваться тем же шаблоном:

┌── Workato
                    │
AI Gateway ◄────────┼── Copilot / Agent
                    │
                    ├── Web application
                    │
                    └── Internal service

Значит, один портфель моделей обслуживает много платформ без новой интеграции инференса для каждой.

К внутренней плоскости управления ИИ

Проект, начавшийся как способ связать корпоративную автоматизацию с открытыми моделями, указывает на нечто большее:

Enterprise Layer
                       │
      ┌────────────────┼────────────────┐
      │                │                │
   Workato          Agents          Applications
      │                │                │
      └────────────────┼────────────────┘
                       │
                       ▼
                 AI API Gateway
                       │
                       ▼
                  Model Router
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
       Model A      Model B      Model C      Model D

Маршрутизатор — начало плоскости управления ИИ. Позже в политику можно добавить классификацию нагрузки, задержку, здоровье моделей, мощность, соответствие задаче, стоимость, требования приватности, оценки качества и со временем правила для отдельных арендаторов. Потребители остаются защищены от всего этого.

Главный урок

Исходный вопрос был в том, как подключить открытую LLM к Workato. После реализации оказалось, что это неверный уровень абстракции. Вопрос лучше — как корпоративным приложениям использовать ИИ, не привязываясь к отдельным моделям. Ответ — сочетание:

Stable API
    +
Model Router
    +
Explicit Selection Policy
    +
Multiple Open Models
    +
Fallback

Каждая модель становится заменяемой инфраструктурой, и для архитектуры корпоративного ИИ это может значить больше, чем то, какую модель выберут.