Tryb Routera w Llama-Server – dynamiczna zmiana modelu bez konieczności ponownego uruchamiania

Długo czas llama.cpp miało oczywistą ograniczenie:
można było obsłużyć tylko jeden model na proces, a zmiana wymagała restartu.

Ta era dobiegła końca.

Ostatnie aktualizacje wprowadziły tryb routera w llama-server, oferując coś, co jest znacznie bliższego temu, czego ludzie oczekują od nowoczesnych środowisk uruchamiających lokalne LLM:

• dynamiczne ładowanie modeli
• odładowywanie na żądanie
• przełączanie przy każdym zapytaniu
• bez restartu procesu

Innymi słowy: zachowanie podobne do Ollama, ale bez kółek pomocniczych.

Jeśli wciąż wahasz się między środowiskami uruchamiającymi lokalnie, chmurą API a infrastrukturą self-hosted, ogólny przegląd hostingu LLM jest dobrym punktem wyjścia.

Wymagania wstępne

Tryb routera wymaga ostatniej wersji budowy llama-server — mniej więcej po połowie 2024 roku. Starsze budowania nie mają flagi --models.

Opcje instalacji (menadżer pakietów, gotowe binarne pliki lub pełne budowanie ze źródła z CUDA) znajdziesz w szybkim starcie llama.cpp.

Gdy już masz llama-server, potwierdź, że Twoja budowa obsługuje tryb routera:

llama-server --help | grep -i models

Jeśli flaga --models się pojawi, jesteś gotowy. Jeśli jej nie ma, zaktualizuj do nowszej budowy.

Moja bieżąca pomoc związana z modelami:

-cl,   --cache-list                     pokaż listę modeli w pamięci podręcznej
                                        Prefiks/Sufiks/Środek) jako niektóre modele preferują to. (domyślnie: wyłączone)
                                        modele z dynamiczną rozdzielczością (domyślnie: odczyt z modelu)
                                        modele z dynamiczną rozdzielczością (domyślnie: odczyt z modelu)
                                        modele do embeddingów (domyślnie: wyłączone)
--models-dir PATH                       katalog zawierający modele dla serwera routera (domyślnie: wyłączone)
                                        (env: LLAMA_ARG_MODELS_DIR)
--models-preset PATH                    ścieżka do pliku INI zawierającego predefiniowane ustawienia modeli dla serwera routera
                                        (env: LLAMA_ARG_MODELS_PRESET)
--models-max N                          dla serwera routera, maksymalna liczba modeli do załadowania jednocześnie
                                        (env: LLAMA_ARG_MODELS_MAX)
--models-autoload, --no-models-autoload
                                        dla serwera routera, czy automatycznie ładować modele (domyślnie:
                                        (env: LLAMA_ARG_MODELS_AUTOLOAD)

Co właściwie robi tryb routera

Tryb routera zamienia llama-server w dyspozytora modeli.

Zamiast wiązania się z pojedynczym modelem przez -m, serwer:

• startuje bez żadnego załadowanego modelu
• otrzymuje zapytanie z nazwą modelu
• ładuje ten model, jeśli nie jest już w pamięci
• uruchamia wnioskowanie
• opcjonalnie odładowuje model po odpowiedzi lub utrzymuje go w pamięci dla kolejnego zapytania

Kluczowy pomysł

Już nie uruchamiasz:

./llama-server -m model.gguf

Uruchamiasz:

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

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

To ma znaczenie, ponieważ oznacza to, że jeden proces może obsługiwać cały flotyl modeli, z klientami wybierającymi właściwy dla danego zadania — model do kodowania, model do czatu, model do podsumowań — bez żadnego nakładu na koordynację po Twojej stronie.

Konfiguracja: definiowanie modeli

Tutaj rzeczy są wciąż nieco surowe.

Nie ma jeszcze w pełni stabilnego oficjalnego formatu, ale obecne budowania wspierają 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 zapytań API.

Kluczowe parametry konfiguracyjne

Wybór właściwej wartości ngl zależy od dostępnej VRAM w Twojej karcie graficznej — dla wyboru GPU i ekonomii sprzętu, przewodnik po sprzęcie obliczeniowym jest użytecznym odniesieniem. Aby obserwować zużycie VRAM na żywo podczas dostosowywania, zobacz narzędzia monitoringu GPU dla Linuxa.

Rozruch serwera z konfiguracją

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

Potwierdź, że serwer uruchomił się poprawnie:

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

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

Uwaga na stabilność

Interfejs konfiguracji INI jest wciąż ewoluujący:

• flagi mogą się zmieniać między commitami
• niektóre parametry są rozpoznawane tylko przez określone konfiguracje budowy
• dokumentacja zalega za implementacją

Zatwierdź konkretny commit llama.cpp, jeśli potrzebujesz powtarzalności między restartami.

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

Gdy serwer działa, przełączanie modeli odbywa się przez standardowe API kompatybilne z OpenAI. Po prostu ustawiasz pole "model".

Lista zarejestrowanych modeli

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

Zapytanie o uzupełnienie — pierwszy model

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3",
    "messages": [
      {"role": "user", "content": "Wyjaśnij tryb routera w jednym akapicie"}
    ]
  }'

Przełącz 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": "Napisz funkcję Python, która czyta plik CSV"}
    ]
  }'

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

Przykład w Pythonie

Jeśli używasz klienta openai w Pythonie:

from openai import OpenAI

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

# Użyj modelu do kodowania
response = client.chat.completions.create(
    model="qwen",
    messages=[{"role": "user", "content": "Napisz handler HTTP w Go"}],
)
print(response.choices[0].message.content)

# Przełącz na model do czatu — ten sam klient, inna nazwa modelu
response = client.chat.completions.create(
    model="llama3",
    messages=[{"role": "user", "content": "Jaka jest stolica Australii?"}],
)
print(response.choices[0].message.content)

Co dzieje się wewnątrz

Gdy przychodzi zapytanie dla qwen, a llama3 jest obecnie załadowane:

1. llama3 jest odładowywane z VRAM
2. wagi qwen są odczytywane z dysku i ładowane do VRAM
3. działa wnioskowanie
4. kolejne zapytanie decyduje, czy utrzymać qwen załadowane, czy ponownie wymieniać

To bezpośrednio odpowiada na powszechne pytanie:

Jak serwer lokalny LLM może wymieniać modele bez restartu

Przez dynamiczne ładowanie modeli na zapytanie, nie przez wiązanie przy starcie.

Usługa Systemd: gotowe do produkcji ustawienie

Stwórz dedykowanego użytkownika i katalogi

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 na 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 /opt/llama.cpp/models.ini --port 8080
Restart=always
RestartSec=5

Environment=LLAMA_LOG_LEVEL=info

[Install]
WantedBy=multi-user.target

Włącz i uruchom

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

Zweryfikuj i zbadaj logi

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ł załadowany. 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 wykonania jako usługa w Linuxie omawia ogólne podejście.

Flaga --metrics w llama-server udostępnia endpoint kompatybilny z Prometheus. Dla dashboardów specyficznych dla llama.cpp, zapytań PromQL i reguł alertów, zobacz przewodnik po monitorowaniu wnioskowania LLM. Dla szerszego ustawienia obserwowalności, przewodnik po obserwowalności obejmuje cały stos.

Ograniczenia, które musisz zrozumieć

Tryb routera jest naprawdę użyteczny, ale niesie ze sobą kompromisy, o których powinieneś być świadomy przed poleganiem na nim w produkcji.

Tylko jeden model w pamięci w danym momencie

Mimo że wiele modeli jest zdefiniowanych w models.ini, tylko jeden jest obecny w VRAM na procesorze w danym momencie. Przełączanie oznacza pełny cykl odładowania i ponownego ładowania.

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

To odpowiada na kolejne kluczowe pytanie:

Czy llama.cpp obsługuje obsługę wielu modeli jednocześnie

Nie do końca. Obsługuje wiele definicji, nie jednoczesną obecność. Jeśli potrzebujesz dwóch modeli naprawdę załadowanych równolegle, potrzebujesz dwóch procesów na dwóch oddzielnych GPU.

Dla zmierzonych zużycia VRAM i tokenów na sekundę dla różnych rozmiarów modeli, testy wydajności LLM obejmują pełny obraz. Dla liczb specyficznych dla llama.cpp na GPU 16 GB — modele gęste i MoE w wielu rozmiarach kontekstu — zobacz testy llama.cpp dla VRAM 16 GB.

Brak inteligentnego cache’owania

W przeciwieństwie do Ollama, które utrzymuje ciepły pul i usuwa modele w oparciu o ostatniość:

• nie ma automatycznej strategii usuwania modeli
• nie ma wstępnego grzania w tle
• nie ma kolejki priorytetowej dla często używanych modeli

Jeśli wysyłasz naprzemienne zapytania dla llama3 i mistral, każde pojedyncze zapytanie wyzwala ponowne ładowanie. To jest fundamentalny koszt bycia bliżej metalu.

Opóźnienia są nieprzewidywalne dla mieszanych obciążeń

Dobrze zachowujące się obciążenie używające jednego modelu konsekwentnie będzie szybkie. Obciążenie przeplatające wiele modeli będzie wolne. Planuj logikę routingu klienta odpowiednio — grupuj zapytania według modelu, gdzie to możliwe.

Konfiguracja nie jest stabilna

Obsługa INI istnieje i działa w większości ostatnich budów, 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 models.ini z nową budową przed wdrożeniem.

Llama.cpp vs Ollama: szczere porównanie

Subiektywna opinia

Wybierz tryb routera llama.cpp, jeśli chcesz:

• maksymalnej kontroli nad parametrami środowiska uruchomieniowego dla każdego modelu
• minimalnego nakładu procesowego
• bezpośredniego dostępu do flag llama.cpp bez warstw abstrakcji
• hackowalnej bazy dla niestandardowego narzędzia

Wybierz Ollama, jeśli chcesz:

• stabilnego, dopracowanego doświadczenia
• automatycznego pobierania i wersjonowania modeli
• inteligentnego utrzymania i usuwania bez konfiguracji
• kompletu od pierwszego dnia

Żadne z nich nie jest złe. Wybór zależy od tego, ile chcesz zarządzać sam.

Jeśli wybierzesz Ollama, skrócony przewodnik CLI Ollama obejmuje codzienne polecenia. Dla szerszego porównania, które obejmuje również vLLM, LM Studio i LocalAI, zobacz jak różne środowiska uruchamiające lokalnie porównują się w 2026 roku.

Llama.cpp vs llama-swap

llama-swap jest zewnętrznym orchestratorem, który stoi przed jednym lub więcej instancjami llama-server:

• przechwytuje zapytania i bada pole model
• uruchamia odpowiedni proces llama-server dla tego modelu
• wyłącza bezczynne instancje po konfigurowalnym czasie
• przekierowuje zapytanie dalej, gdy model jest gotowy

Dla praktycznego ustawienia, zobacz szybki start llama-swap.

Kluczowa różnica

Kiedy użyć llama-swap

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

Użyj go, jeśli potrzebujesz:

• lepszej kontroli nad cyklem życia i izolacji
• inteligentniejszej logiki przełączania z konfigurowalnym czasem bezczynności
• bardziej przewidywalnego opóźnienia (każdy model ma ciepły proces po pierwszym ładowaniu)
• stabilności produkcyjnej teraz, a nie kiedyś

Kiedy natywny tryb routera wystarcza

Użyj wbudowanego routera, jeśli chcesz:

• zerowych zewnętrznych zależności
• jednego procesu do zarządzania
• prostszego wdrożenia (jeden plik binarny, jeden plik konfiguracyjny)
• minimalnego stosu dla środowisk deweloperskich lub jednoużytkowych

Myśli końcowe

Tryb routera jest znaczącym krokiem do przodu dla llama-server.

Odpowiada na długotrwałe żądanie:

Czym jest tryb routera w serwerze llama.cpp

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

Ale nie jest skończony.

Dziś jest:

• wystarczająco mocny dla prawdziwych 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ć zapytania według modelu, tryb routera działa dobrze dziś. Jeśli potrzebujesz stabilności produkcyjnej i izolacji per model, sięgnij po llama-swap, podczas gdy natywna implementacja dojrzewa.

W każdym przypadku otrzymujesz zachowanie podobne do Ollama, bez ukrywania mechanizmu.