Сетевое взаимодействие самохостингованных 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 на 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 в документации по адаптации приложений и отказывайтесь публиковать дополнительные хост-имена для команд, разрабатывающих приложения, если нет строгой необходимости в изоляции.

Эти привычки сохраняют абстракцию, которую было создано с помощью шлюза.