Tryb routera serwera Llama – dynamiczne przełączanie modeli bez restartu

Przez długi czas llama.cpp miał wyraźną wadę: można było obsługiwać tylko jeden model na proces, a przeladowanie wymagało restartu.

Ta era dobiegła końca.

Ostatnie aktualizacje wprowadziły tryb routera w llama-server, oferując coś bliższego temu, czego oczekuje się od nowoczesnych lokalnych środowisk uruchomieniowych LLM:

• dynamiczne ładowanie modeli
• odładowywanie na żądanie
• przełączanie modeli na poziomie żądania
• brak konieczności restartowania procesu

Innymi słowy: zachowanie podobne do Ollamy, ale bez szkoleń.

Jeśli nadal wahasz się między lokalnymi środowiskami uruchomieniowymi, interfejsami API chmurowymi, a samodzielnie hostowaną infrastrukturą, przegląd hostowania LLM to dobre miejsce na start.

Wymagania wstępne

Tryb routera wymaga nowszej wersji llama-server — mniej więcej z okresu po połowie 2024 roku. Starsze wersje nie posiadają flag --models-preset ani --models-dir.

Informacje na temat opcji instalacji (menedżer pakietów, gotowe binaria lub pełna kompilacja ze źródła z CUDA) znajdziesz w przewodniku szybkiego startu llama.cpp.

Gdy już masz llama-server, upewnij się, że Twoja wersja obsługuje tryb routera:

llama-server --help | grep -i models

Jeśli pojawią się --models-preset lub --models-dir, wszystko jest w porządku. Jeśli ich brak, zaktualizuj do nowszej wersji.

Mój aktualny wynik dotyczący pomocy dla modeli:

-cl,   --cache-list                     show list of models in cache
                                        Prefix/Suffix/Middle) as some models prefer this. (default: disabled)
                                        models with dynamic resolution (default: read from model)
                                        models with dynamic resolution (default: read from model)
                                        embedding models (default: disabled)
--models-dir PATH                       directory containing models for the router server (default: disabled)
                                        (env: LLAMA_ARG_MODELS_DIR)
--models-preset PATH                    path to INI file containing model presets for the router server
                                        (env: LLAMA_ARG_MODELS_PRESET)
--models-max N                          for router server, maximum number of models to load simultaneously
                                        (env: LLAMA_ARG_MODELS_MAX)
--models-autoload, --no-models-autoload
                                        for router server, whether to automatically load models (default:
                                        (env: LLAMA_ARG_MODELS_AUTOLOAD)

Co właściwie robi tryb routera

Tryb routera zamienia llama-server w dyspozytor modeli.

Zamiast wiązać się z jednym modelem poprzez -m, serwer:

• startuje bez załadowanego modelu
• otrzymuje żądanie wskazujące nazwę modelu
• ładuje ten model, jeśli nie znajduje się już w pamięci
• wykonuje wnioskowanie
• opcjonalnie odładowuje model po odpowiedzi lub utrzymuje go w pamięci pod kolejne żądanie

Kluczowa koncepcja

Nie uruchamiasz już:

./llama-server -m model.gguf

Uruchamiasz:

./llama-server --models-preset models.ini --port 8080

I pozwalasz serwerowi zdecydować co i kiedy załadować, w oparciu o to, co faktycznie żąda klient.

Ma to znaczenie, ponieważ oznacza, że jeden trwały proces może obsługiwać całą flotę modeli, a klienci wybierają odpowiedni model do danego zadania — model do kodowania, model do czatu, model do streszczania — bez konieczności dodatkowej koordynacji po Twojej stronie.

Konfiguracja: definiowanie modeli

To jest obszar, który nadal jest nieco surowy.

Nie ma jeszcze w pełni stabilnego, oficjalnego formatu, ale obecne wersje obsługują definicje modeli w stylu INI poprzez plik konfiguracyjny.

Przykładowy models.ini

[llama3]
model = /opt/models/llama-3-8b-instruct.Q5_K_M.gguf
ctx-size = 8192
ngl = 35
threads = 8

[mistral]
model = /opt/models/mistral-7b-instruct-v0.3.Q4_K_M.gguf
ctx-size = 4096
ngl = 20
threads = 8

[qwen]
model = /opt/models/qwen2.5-coder-7b-instruct.Q5_K_M.gguf
ctx-size = 16384
ngl = 35
threads = 8

Każda nazwa sekcji staje się identyfikatorem modelu, którego klienci używają w polu "model" swoich żądań API.

Kluczowe parametry konfiguracji

Wybór odpowiedniej wartości ngl zależy od dostępnej VRAM na karcie graficznej — przy wyborze GPU i ekonomii sprzętu, przewodnik po sprzęcie obliczeniowym to przydatne źródło. Aby obserwować zużycie VRAM na żywo podczas konfiguracji, zobacz narzędzia monitoringu GPU dla Linux.

Uruchamianie serwera z konfiguracją

./llama-server --models-preset /opt/llama.cpp/models.ini --port 8080

Potwierdź poprawne uruchomienie serwera:

curl http://localhost:8080/v1/models | jq '.data[].id'

Powinieneś zobaczyć każdą nazwę sekcji z Twojego models.ini wymienioną jako ID modelu.

Uwaga dotycząca stabilności

Interfejs konfiguracji INI nadal ewoluuje:

• flagi mogą się zmieniać między commitami
• niektóre parametry są rozpoznawane tylko przez określone konfiguracje kompilacji
• dokumentacja nie nadąża za implementacją

Jeśli potrzebujesz powtarzalności przy restartach, przypnij się do konkretnego commita llama.cpp.

Użycie API: przełączanie modeli na żądanie

Gdy serwer już działa, przełączanie modeli odbywa się przez standardowe, zgodne z OpenAI API. Wystarczy ustawić pole "model".

Lista zarejestrowanych modeli

curl http://localhost:8080/v1/models

Żądanie uzupełnienia — pierwszy model

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3",
    "messages": [
      {"role": "user", "content": "Explain router mode in one paragraph"}
    ]
  }'

Przełączenie na inny model — ten sam endpoint, ten sam port

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen",
    "messages": [
      {"role": "user", "content": "Write a Python function that reads a CSV file"}
    ]
  }'

Serwer obsługuje cykl odładowania/ładowania w sposób przezroczysty. Twój kod klienta się nie zmienia — zmienia się tylko pole model.

Przykład w Pythonie

Jeśli używasz klienta Python openai:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8080/v1", api_key="not-needed")

# Use the coding model
response = client.chat.completions.create(
    model="qwen",
    messages=[{"role": "user", "content": "Write a Go HTTP handler"}],
)
print(response.choices[0].message.content)

# Switch to the chat model — same client, different model name
response = client.chat.completions.create(
    model="llama3",
    messages=[{"role": "user", "content": "What is the capital of Australia?"}],
)
print(response.choices[0].message.content)

Co dzieje się wewnątrz

Gdy przychodzi żądanie dla qwen, a llama3 jest obecnie załadowany:

1. llama3 jest odładowany z VRAM
2. Wagi qwen są odczytywane z dysku i ładowane do VRAM
3. wykonuje się wnioskowanie
4. kolejne żądanie decyduje, czy utrzymać qwen w pamięci, czy ponownie przeładować

To bezpośrednio odpowiada na powszechne pytanie:

Jak serwer LLM lokalny może przełączać modele bez restartu?

Przez dynamiczne ładowanie modeli na żądanie, a nie wiązanie się z nimi przy starcie.

Usługa Systemd: gotowe na produkcję ustawienie

Tworzenie dedykowanego użytkownika i katalogów

sudo useradd --system --shell /usr/sbin/nologin --home-dir /opt/llama.cpp llm
sudo mkdir -p /opt/llama.cpp/models
sudo chown -R llm:llm /opt/llama.cpp

Skopiuj swój plik binarny i konfigurację modeli w odpowiednie miejsce:

sudo cp build/bin/llama-server /opt/llama.cpp/
sudo cp models.ini /opt/llama.cpp/

/etc/systemd/system/llama-server.service

[Unit]
Description=Llama.cpp Router Server
After=network.target

[Service]
Type=simple
User=llm
WorkingDirectory=/opt/llama.cpp
ExecStart=/opt/llama.cpp/llama-server --models-preset /opt/llama.cpp/models.ini --port 8080
Restart=always
RestartSec=5

Environment=LLAMA_LOG_LEVEL=info

[Install]
WantedBy=multi-user.target

Włączanie i uruchamianie

sudo systemctl daemon-reload
sudo systemctl enable llama-server
sudo systemctl start llama-server

Weryfikacja i przegląd logów

sudo systemctl status llama-server

journalctl -u llama-server -f

Po udanym starcie zobaczysz linie wskazujące, że serwer nasłuchuje i rejestr modeli została załadowana. Szybka weryfikacja:

curl -s http://localhost:8080/v1/models | jq '.data[].id'

Teraz masz trwały serwis z automatycznym restartem i scentralizowanym przełączaniem modeli — bez konieczności ręcznego zarządzania procesami. Jeśli chcesz zastosować ten sam wzorzec do innych plików binarnych, hostowanie dowolnego wykonywalnego pliku jako usługi Linux omawia ogólne podejście.

Flaga --metrics w llama-server udostępnia endpoint zgodny z Prometheus. Aby uzyskać dalsze informacje dotyczące dashboardów specyficznych dla llama.cpp, zapytań PromQL oraz zasad alertingu, zobacz przewodnik po monitoringu wnioskowania LLM. W przypadku szerszego zestawu obserwacyjności, przewodnik po obserwacyjności omawia cały stos technologiczny.

Ograniczenia, które musisz zrozumieć

Tryb routera jest naprawdę przydatny, ale wiąże się z kompromisami, które powinieneś jasno zrozumieć przed oparciem na nim w produkcji.

Tylko jeden model w pamięci w danej chwili

Mimo że wiele modeli jest zdefiniowanych w models.ini, w danej chwili tylko jeden model rezyduje w VRAM na worker. Przełączanie oznacza pełny cykl odładowania i ponownego ładowania.

• przełączanie oznacza przeładowanie
• wzrost opóźnienia jest nieunikniony
• w przypadku typowego modelu 7B w Q5, przeładowanie może zająć 3–10 sekund w zależności od szybkości dysku i przepustowości VRAM

To odpowiada na kolejne kluczowe pytanie:

Czy llama.cpp obsługuje jednoczesną obsługę wielu modeli?

Nie do końca. Obsługuje wiele definicji, ale nie jednoczesną rezydencję. Jeśli potrzebujesz dwóch modeli faktycznie załadowanych równolegle, potrzebujesz dwóch procesów na dwóch osobnych kartach GPU.

Aby uzyskać zmierzone zużycie VRAM i liczbę tokenów na sekundę dla różnych rozmiarów modeli, benchmarki wydajności LLM przedstawiają pełny obraz. Aby zobaczyć liczby specyficzne dla llama.cpp na GPU 16 GB — modele dense i MoE przy różnych rozmiarach kontekstu — zobacz benchmarki llama.cpp na 16 GB VRAM.

Brak inteligentnego buforowania

W przeciwieństwie do Ollamy, która utrzymuje ciepły pulę i usuwa modele na podstawie świeżości:

• nie ma automatycznej strategii usuwania modeli
• nie ma tła pre-loadingu
• nie ma kolejki priorytetowej dla często używanych modeli

Jeśli wysyłasz naprzemiennie żądania dla llama3 i mistral, każde pojedyncze żądanie spowoduje przeładowanie. To jest fundamentalny koszt bycia bliżej „metalowych” komponentów.

Opóźnienie jest nieprzewidywalne przy mieszanych obciążeniach

Obciążenie, które konsekwentnie używa jednego modelu, będzie szybkie. Obciążenie, które przeplata wiele modeli, będzie wolne. Zaplanuj swoją logikę routingu klientów odpowiednio — grupuj żądania według modelu, gdzie to możliwe.

Konfiguracja nie jest stabilna

Obsługa INI istnieje i działa w najnowszych kompilacjach, ale nie jest w pełni ustandaryzowana. Flagi i nazwy parametrów zmieniały się między wersjami. Jeśli aktualizujesz llama-server, przetestuj swój plik models.ini z nową kompilacją przed wdrożeniem.

Llama.cpp vs Ollama: uczciwe porównanie

Subiektywna opinia

Wybierz tryb routera llama.cpp, gdy chcesz:

• maksymalnej kontroli nad parametrami środowiska uruchomieniowego dla każdego modelu
• minimalnego narzutu procesowego
• bezpośredniego dostępu do flag llama.cpp bez warstw abstrakcji
• hackowalnej bazy dla niestandardowych narzędzi

Wybierz Ollamę, gdy chcesz:

• stabilnego, polerowanego doświadczenia
• automatycznego pobierania modeli i wersjonowania
• inteligentnego utrzymywania w pamięci i usuwania bez konfiguracji
• kompletnego rozwiązania od pierwszego dnia

Żadne z rozwiązań nie jest błędne. Wybór zależy od tego, ile chesz zarządzać samemu.

Jeśli wybierzesz Ollamę, przewodnik po CLI Ollama omawia codzienne polecenia. Aby uzyskać szersze porównanie, które obejmuje również vLLM, LM Studio i LocalAI, zobacz jak porównują się różne lokalne środowiska uruchomieniowe w 2026 roku.

Llama.cpp vs llama-swap

llama-swap to zewnętrzny orkiestrator, który działa przed jednym lub wieloma instancjami llama-server:

• przechwytuje żądania i inspekcjonuje pole model
• uruchamia odpowiedni proces llama-server dla tego modelu
• zamyka bezczynne instancje po skonfigurowanym czasie wygaśnięcia
• przekazuje żądanie dalej, gdy model jest gotowy

Aby zobaczyć praktyczne ustawienie, zobacz przewodnik szybkiego startu llama-swap.

Kluczowa różnica

Kiedy używać llama-swap

llama-swap daje Ci izolację na poziomie procesu dla każdego modelu, co oznacza, że awaria jednej instancji modelu nie wpływa na inne. Pozwala także każdemu modelowi działać z całkowicie niezależnymi flagami llama-server.

Używaj go, jeśli potrzebujesz:

• lepszej kontroli nad cyklem życia i izolacji
• inteligentniejszej logiki przełączania z konfigurowalnymi czasami wygaśnięcia bezczynności
• bardziej przewidywalnego opóźnienia (każdy model ma ciepły proces po pierwszym ładowaniu)
• stabilności produkcyjnej dzisiaj, a nie „ewentualnie”

Kiedy natywny tryb routera wystarczy

Użyj wbudowanego routera, jeśli chcesz:

• zerowych zależności zewnętrznych
• jednego procesu do zarządzania
• prostszego wdrożenia (jeden binarny plik, jeden plik konfiguracyjny)
• minimalnego stosu dla rozwoju lub ustawień jednorazowych

Podsumowanie

Tryb routera to znaczący krok naprzód dla llama-server.

Odpowiada na długotrwałe żądanie:

Czym jest tryb routera w serwerze llama.cpp?

To brakująca warstwa, która zamienia statyczny plik binarny w dynamiczną usługę wnioskowania — jeden proces, który może obsługiwać żądania dla całego katalogu modeli.

Ale nie jest skończony.

Dziś jest:

• wystarczająco potężny do rzeczywistych obciążeń
• obiecujący jako fundament dla bardziej zaawansowanego routingu
• nieco surowy w krawędziach konfiguracji i stabilności

Jeśli Twoje obciążenie jest przewidywalne i możesz grupować żądania według modelu, tryb routera działa dobrze dzisiaj. Jeśli potrzebujesz stabilności produkcyjnej i izolacji dla każdego modelu, sięgnij po llama-swap, dopóki natywna implementacja nie dojrzeje.

Gdy musisz zwolnić VRAM bez restartu — dla testu benchmarkowego, okna konserwacyjnego lub czystego resetu deweloperskiego — skryptowalne podejście polega na wylistowaniu załadowanych modeli i wywołaniu endpointu odładowania dla każdego z nich. Pełny wzorzec curl-and-jq jest omówiony w Odładowanie wszystkich modeli routera llama.cpp bez restartu.

W każdym razie, otrzymujesz zachowanie podobne do Ollamy, bez ukrywania mechanizmów.