Мережування самостійно розгорнутих LLM: один шлюз замість окремого хоста для кожної моделі

Самостійне розміщення моделей з відкритими вагами часто починається просто: одна модель, один ім’я хоста, один правильний шлях. Проблеми виникають, коли з’являються друга та третя моделі. Кожен новий файл з вагами зазвичай потребує додаткової налаштування мережі, взаємодії та конфігурації додатку — навіть якщо продукт просив лише ще один ідентифікатор моделі. Розміщення шлюзу перед бекендами дозволяє зберегти єдиний кінцевий пункт, тоді як моделі можуть з’являтися та зникати позаду нього. Урок полягає у архітектурних принципах, а не у специфіці продукту: припиніть навчати кожного клієнта топології кожної системи з GPU.

Усе почалося з однієї моделі

Чекпоїнт класу Qwen з відкритими вагами обслуговувався локально та був доступний через ім’я хоста:

llm.my-app.com

Додаток викликав цей кінцевий пункт, вказуючи назву моделі та решту даних запиту. Трафік працював; панелі керування виглядали нормально. Потім швидша інстанція Gemma потребувала власного слухача для шляхів, чутливих до затримок:

flash.llm.my-app.com

Це також спрацювало. Моделі зображень та копії для оцінки чекпоїнтів класу DeepSeek привабили ще більше хостів:

images.llm.my-app.com

deepseek-v4.llm.my-app.com

Продуктивна версія Qwen залишилась недоторканою, тоді як розробка була спрямована на експериментальний кінцевий пункт. Кожен крок був окремо обґрунтованим. Разом вони створили мережу базових URL-адрес, які міг запам’ятати лише той, хто їх налаштував.

Це спрацювало, але щось здавалося неправильним

Жоден з кроків не був складним — і саме в цьому полягала проблема. Кожна модель повторювала одну й ту саму послідовність дій: розгортання ваг, створення сервісу, налаштування мережі, з’єднання VPC для того, щоб приватні хости моделей могли підключитися до додатку, а потім навчання додатку нового базового URL. Усе це не є „моделлю“ — це просто стандартні технологічні процедури. Колег не можна було просто сказати „використовуйте наш сервіс LLM та оберіть цю модель“; їм потрібно було точне описання правильного хоста, і розмова починалася заново щоразу, коли з’являвся новий кінцевий пункт. Для інтеграції підрядника доводилося надсилати приватний глосарій імен хостів замість єдиного каталогу.

Експеримент DeepSeek зробив це очевидним

Оцінка окремої реалізації класу DeepSeek без впливу на продуктивну версію Qwen означала додавання ще одного кінцевого пункту підключення до середовища розробки. З технічної точки зору нічого не зламалося. Проте залишалося нагальне питання: чому для додавання моделі необхідно також додавати мережеве з’єднання? Змінювався лише ваговий файл моделі; інфраструктура додатку не повинна змінюватися одночасно. Якщо кожен експеримент змінює параметри DNS та мережевого підключення, процес експериментування сповільнюється до темпів обробки заявок на зміни мережі.

Як же великі постачальники розголошують моделі

Великі постачальники не створюють окремих публічних URL-адрес для кожної моделі. Користувачі не змушені керувати низкою хостів, таких як:

gpt-4.api.openai.com
gpt-5.api.openai.com
some-other-model.api.openai.com

Вони використовують один API та обирають модель усередині запиту. Якщо постачальники можуть працювати з десятками моделей через один інтерфейс, флоти з власним хостуванням можуть прагнути до такої ж структури. Контракт з клієнтом залишається стабільним; флот, який стоїть за ним, може змінюватися.

Ідея: розмістити проксі перед моделями

Додатки завжди повинні взаємодіяти з одним стабільним базовим елементом:

llm.my-app.com

та обирати модель у тілі запиту:

{
  model: "qwen-3.8",
  ...
}

{
  model: "gemma-3",
  ...
}

{
  model: "deepseek-v4",
  ...
}

Бекенди можуть переміщуватися між машинами, регіонами чи середовищами виконання; контракт з клієнтом залишається незмінним. Це та сама абстракція, яку вже пропонують постачальники хмарних послуг — лише спрямована на флоти з відкритим кодом під вашим контролем.

Створення проксі порівняно з використанням шлюзу

Наївний проксі — тобто модель, маршрутизація, повернення даних — здається простим, поки не стає необхідністю використання спільного сервісу. Тоді з’являються віртуальні ключі, облік використання, контроль доступу, налаштування моделі, обмеження швидкості, журналування та інтерфейс адміністратора. Це вже не іграшковий проксі; це шлюз LLM. Повторна реалізація цих механізмів з нуля означає необхідність врахування років накопичених специфічних ситуацій (обертання ключів, бюджети для кожної команди, журнали аудиту). LiteLLM орієнтується саме на цей рівень керування, щоб командам не доводилося це робити.

Чому підходить LiteLLM

Додатки залишаються з одним кінцевим пунктом:

llm.my-app.com

LiteLLM маршрутизує запити до різноманітних бекендів:

My Application
                        │
                        ▼
                 llm.my-app.com
                        │
                        ▼
                   LiteLLM
                  /   |    \
                 /    |     \
              Qwen  Gemma  DeepSeek

Додавання експериментальної моделі полягає у розгортанні її ваг, реєстрації їх у шлюзі та збереженні початкової URL додатку без змін. Імена хостів більше не потрапляють у код продукту. Розробники обирають моделі так само, як обирають температуру — прямо у запиті, а не шляхом редагування файлів середовища для кожного експерименту.

Розгортання було простим

LiteLLM постачається у вигляді образу Docker та зазвичай потребує PostgreSQL для зберігання стабільного стану, такого як ключі та дані про витрати:

LiteLLM container
        │
        ├── PostgreSQL
        │
        └── Open-weight model servers

Сервери моделей зосереджуються лише на обробці даних; шлюз керує всім процесом над ними. Пристрої з GPU більше не потребують прямого доступу з кожного мікросервісу. Взаємодія відбувається через шлюз, а не через мережу типу N-by-M між додатками та хостами моделей.

Те, що справді змінилося

До появи шлюза додавання моделі означало необхідність повторення всіх кроків налаштування мережі:

New model
   ↓
New deployment
   ↓
New networking
   ↓
New hostname
   ↓
Application changes

Після цього процес скоротився до реєстрації моделі у стабільному шлюзі:

New model
   ↓
Deploy it
   ↓
Register it with the gateway
   ↓
Use the existing endpoint

Важливий урок: додатки не повинні знати, де працює LLM — лише яку модель потрібно запитати. LiteLLM є одним із практичних способів забезпечення цього обмеження. Справжньою проблемою була не сама продуктова платформа, а друга модель. Як тільки ця закономірність стає очевидною, кожна наступна модель або посилює систему імен хостів, або сприяє створенню єдиного каталогу. Виберіть каталог.

Примітки щодо експлуатації, які варто зберегти

• Розглядайте реєстрацію моделей як процес керування змінами: хто може додавати бекенди, як ключі відповідають командам та як закінчується термін дії експериментів.
• Тримайте перевірки стану бекендів окремо від публічного кінцевого точки, щоб несправна модель не виглядала як повна перерва у роботі.
• Описуйте єдину базову URL у документації для початку роботи та відмовляйтесь публікувати додаткові імена хостів для команд додатків, якщо немає суворої вимоги до ізоляції.

Ці звички зберігають абстракцію, яку було створено за допомогою шлюза.