Sieciowanie samodzielnie hostowanych modeli LLM: jeden bramkarz zamiast serwera dla każdego modelu

Samohostowanie modeli typu open-weight zazwyczaj zaczyna się prosto: jeden model, jedna nazwa hosta, jeden prosty schemat działania. Problemy pojawiają się, gdy dodaje się drugi i trzeci model. Każdy nowy plik z wagami wymaga dodatkowych ustawień sieciowych, konfiguracji peeringu oraz aplikacji – mimo że produkt prosił jedynie o kolejny identyfikator modelu. Umieszczenie bramy przed backendami pozwala przywrócić jeden endpoint, podczas gdy modele mogą być dodawane i usuwane za nią. Lekcja ta dotyczy architektury, a nie konkretnego produktu: należy przestać uczyć każdego klienta topologii każdej jednostki GPU.

Zaczęło się od jednego modelu

Checkpoint klasy Qwen o otwartych wagach był uruchamiany lokalnie i dostępny pod określoną nazwą hosta:

llm.my-app.com

Aplikacja wywoływała ten endpoint, podając nazwę modelu oraz pozostałą zawartość żądania. Ruch sieciowy funkcjonował poprawnie, a panele kontrolne wyglądały dobrze. Następnie szybsza instancja Gemma zażądała własnego odbiorcy sygnałów dla ścieżek wrażliwych na opóźnienia:

flash.llm.my-app.com

To też zadziałało. Modele obrazów oraz kopie oceniające punkty kontrolne klasy DeepSeek przyciągnęły jeszcze więcej hostów:

images.llm.my-app.com

deepseek-v4.llm.my-app.com

Wersja produkcyjna Qwen pozostała nietknięta, podczas gdy wersja rozwojowa była skierowana na endpoint eksperymentalny. Każdy krok był indywidualnie rozsądny. Razem tworzyły one sieć podstawowych adresów URL, które mógł zapamiętać tylko osoba, która je ustaliła.

Zadziałało, ale coś wydawało się nie tak

Eksperyment DeepSeek pokazał to wyraźnie

Ocena oddzielnego wdrożenia typu DeepSeek bez zakłócania pracy produkcji Qwen oznaczała dodanie kolejnego punktu końcowego do środowiska rozwojowego. Technicznie nic się nie zepsuło. Pozostawało jednak nurtujące pytanie: dlaczego dodawanie modelu musi wymagać dodawania elementów sieciowych? Zmienionym elementem były wagi modelu; infrastruktura aplikacji nie powinna zmieniać się w sposób synchroniczny. Jeśli każde doświadczenie wymaga modyfikacji DNS i połączeń peer-to-peer, eksperymentowanie spowalnia się do tempa zgłoszeń dotyczących zmian w sieci.

Jak zatem duzi dostawcy udostępniają modele

Główni dostawcy nie tworzą oddzielnych publicznych adresów bazowych dla każdego modelu. Korzystający nie muszą radzić sobie z różnymi rodzinami hostów takimi jak:

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

Utrzymują jedną API i wybierają model w ramach żądania. Jeśli dostawcy mogą oferować dziesiątki modeli za jedną interfejsem, floty self-hostowane mogą dążyć do podobnego rozwiązania. Umowa z klientem staje się stabilna, natomiast flota za nią może ulegać zmianom.

Idea: umieszczenie proxy przed modelami

Aplikacje powinny zawsze komunikować się z jedną stabilną bazą:

llm.my-app.com

i wybierać model w ciele żądania:

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

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

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

Backendy mogą być przenoszone między maszynami, regionami lub środowiskami działania; umowa z klientem pozostaje niezmieniona. To ta sama abstrakcja, którą już oferują dostawcy chmury — tylko skierowana do flot o otwartym kodzie pod twoją kontrolą.

Budowa proxy w porównaniu z wykorzystaniem bramy

Naiwny przewoźnik danych – czyli model, ścieżka przesyłania i powrotu – wydaje się prosty, dopóki nie musi stać się usługą współdzieloną. Wtedy pojawiają się wirtualne klucze, rozliczanie zużycia, kontrola dostępu, konfiguracja modelu, limity przepustowości, logowanie oraz interfejs administracyjny. To już nie jest zwykły proxy; to brama do LLM. Odbudowa tych mechanizmów od zera oznacza ponowne opracowanie lat doświadczeń związanych z różnymi przypadkami użycia (rotacja kluczy, budżety dla poszczególnych zespołów, logi audytowe). LiteLLM skupia się na tej warstwie sterującej, dzięki czemu zespoły nie muszą tego robić.

Dlaczego LiteLLM jest odpowiedni

Aplikacje zachowują jeden punkt końcowy:

llm.my-app.com

LiteLLM kieruje żądania do zróżnicowanych backendów:

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

Dodanie eksperymentalnego modelu polega teraz na zainstalowaniu jego wag, zarejestrowaniu ich w bramie oraz zachowaniu niezmienionej adresacji URL aplikacji. Nazwy hostów przestają przenikać do kodu produktu. Programiści wybierają modele w taki sam sposób, jak wybierają temperaturę – bezpośrednio w żądaniu – a nie poprzez edycję plików środowiskowych dla każdego eksperymentu.

Rozwój był prosty

LiteLLM dostarczany jest jako obraz Dockera i zazwyczaj wymaga PostgreSQL do przechowywania trwałych danych, takich jak klucze i wydatki:

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

Serwery modeli skupiają się wyłącznie na przetwarzaniu danych; brama kontrolna zarządza całą strukturą nad nimi. Urządzenia z GPU nie muszą już być dostępne bezpośrednio z każdego mikrosłużby. Połączenia skupiają się na warstwie bramy kontrolnej zamiast na sieci typu N przez M pomiędzy aplikacjami a hostami modeli.

To, co faktycznie się zmieniło

Przed wprowadzeniem bramy kontrolnej dodawanie modelu oznaczało konieczność powtarzania całego procesu konfiguracji sieci:

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

Po jej wprowadzeniu proces ten sprowadza się do rejestracji w stabilnej bramie wejściowej:

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

Podstawa, której należy przestrzegać: aplikacje nie powinny wiedzieć, gdzie działa LLM – wystarczy im wiedzieć, jaki model należy zażądać. LiteLLM to praktyczny sposób na egzekwowanie tej zasady. Początkowym problemem nie był produkt bramkowy, lecz drugi model. Gdy ten wzorzec stanie się widoczny, każdy kolejny model albo wzmacnia strukturę nazw hostów, albo opiera się na jednym katalogu. Wybierz katalog.

Uwagi operacyjne, które warto zachować

• Traktuj rejestrację modeli jako proces zarządzany zmianami: kto może dodawać backendy, jak klucze są przypisywane zespołom oraz kiedy eksperymenty wygasają.
• Zachowaj kontrolę stanu backendów oddzielnie od publicznego endpointu, aby modely niewłączone do pracy nie wyglądały na całkowicie niedostępne.
• Zdokumentuj jedyną podstawową adresację URL w dokumentacji wprowadzającej i odmawiaj publikowania dodatkowych nazw hostów dla zespołów aplikacyjnych, chyba że istnieje konieczność ścisłej izolacji.

Takie nawyki utrzymują abstrakcję, którą stworzono poprzez wprowadzenie bramy.