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

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