Маршрутизатор моделей на GCP: один керований API перед кількома відкритими LLM
Схема, що відв'язує корпоративні застосунки від конкретних LLM: логічні задачі, вибір моделі за обмеженнями, ланцюжки резервування, vLLM і стабільний API у стилі OpenAI на GCP.
Більшість корпоративних 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
Кожна модель стає замінною інфраструктурою, і для архітектури корпоративного ШІ це може важити більше, ніж те, яку модель оберуть.