Llama-Server-Router-Modus – Dynamischer Modellwechsel ohne Neustart

Seit langem hatte llama.cpp eine eklatante Einschränkung:
Man konnte nur ein Modell pro Prozess bereitstellen, und ein Wechsel erforderte einen Neustart.

Diese Ära ist vorbei.

Neue Updates haben im llama-server den Router-Modus eingeführt und damit etwas geliefert, das dem entspricht, was man von modernen lokalen LLM-Runtimes erwartet:

• dynamisches Modell-Loading
• bedarfsgesteuertes Unloading
• Wechsel pro Anfrage
• kein Prozess-Neustart

Mit anderen Worten: Ollama-ähnliches Verhalten, aber ohne die Stützräder.

Wenn Sie noch zwischen lokalen Runtimes, Cloud-APIs und selbst gehosteter Infrastruktur entscheiden müssen, ist die
LLM-Hosting-Übersicht ein guter Ausgangspunkt.

Voraussetzungen

Der Router-Modus erfordert einen aktuellen llama-server-Build – grob ab Mitte 2024. Ältere Builds verfügen nicht über die --models-Flagge.

Für Installationsmöglichkeiten (Paketmanager, vorgefertigte Binärdateien oder vollständiger Source-Compile mit CUDA) siehe die
llama.cpp Quickstart-Anleitung.

Sobald Sie llama-server haben, bestätigen Sie, dass Ihr Build den Router-Modus unterstützt:

llama-server --help | grep -i models

Wenn die --models-Flagge erscheint, sind Sie gut. Wenn sie fehlt, aktualisieren Sie auf einen neueren Build.

Mein aktueller Output bezüglich modellbezogener Hilfe:

-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)

Was der Router-Modus tatsächlich tut

Der Router-Modus verwandelt llama-server in einen Modell-Dispatcher.

Anstatt über -m an ein einzelnes Modell zu binden, der Server:

• startet ohne geladenes Modell
• empfängt eine Anfrage, die ein Modell benennt
• lädt dieses Modell, falls es nicht bereits im Speicher ist
• führt die Inferenz durch
• entlädt das Modell optional nach der Antwort oder hält es warm für die nächste Anfrage

Die Kernidee

Sie führen nicht mehr Folgendes aus:

./llama-server -m model.gguf

Sie führen Folgendes aus:

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

Und lassen den Server entscheiden, was wann geladen wird, basierend auf dem, was der Client tatsächlich anfordert.

Das ist wichtig, weil es bedeutet, dass ein persistenter Prozess eine ganze Flotte von Modellen bedienen kann, wobei Clients das richtige Modell pro Aufgabe auswählen – ein Coding-Modell, ein Chat-Modell, ein Zusammenfassungsmodell – ohne Koordinationsaufwand auf Ihrer Seite.

Konfiguration: Definition Ihrer Modelle

Hier ist es noch etwas roher.

Es gibt noch kein vollständig stabiles offizielles Format, aber aktuelle Builds unterstützen INI-ähnliche Modelldefinitionen über eine Konfigurationsdatei.

Beispiel 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

Jeder Sektionsname wird zum Modell-Identifikator, den Clients im "model"-Feld ihrer API-Anfragen verwenden.

Wichtige Konfigurationsparameter

Die Wahl des richtigen ngl-Werts hängt von der verfügbaren VRAM Ihrer GPU ab – für die GPU-Auswahl und Hardware-Ökonomie ist der Leitfaden für Compute-Hardware eine nützliche Referenz. Um den VRAM-Verbrauch live zu überwachen, während Sie ihn einstellen, sehen Sie sich die GPU-Monitoring-Tools für Linux an.

Server mit Konfiguration starten

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

Bestätigen Sie, dass der Server korrekt gestartet wurde:

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

Sie sollten jeden Sektionsnamen aus Ihrem models.ini als Modell-ID aufgelistet sehen.

Ein Hinweis zur Stabilität

Die INI-Konfigurations-Schnittstelle entwickelt sich noch weiter:

• Flaggen können sich zwischen Commits ändern
• einige Parameter werden nur von bestimmten Build-Konfigurationen erkannt
• die Dokumentation hinkt der Implementierung hinterher

Festigen Sie sich an einem bestimmten llama.cpp-Commit, wenn Sie Reproduzierbarkeit über Neustarts hinweg benötigen.

API-Nutzung: Modelle pro Anfrage wechseln

Sobald der Server läuft, erfolgt der Modellwechsel über die standardmäßige OpenAI-kompatible API. Sie setzen einfach das "model"-Feld.

Gelistete registrierte Modelle

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

Kompletierungsanfrage — erstes Modell

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"}
    ]
  }'

Wechsel zu einem anderen Modell — gleicher Endpunkt, gleicher 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"}
    ]
  }'

Der Server übernimmt den Entlade-/Ladezyklus transparent. Ihr Client-Code ändert sich nicht – nur das model-Feld.

Python-Beispiel

Wenn Sie den openai Python-Client verwenden:

from openai import OpenAI

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

# Verwenden Sie das Coding-Modell
response = client.chat.completions.create(
    model="qwen",
    messages=[{"role": "user", "content": "Write a Go HTTP handler"}],
)
print(response.choices[0].message.content)

# Wechseln Sie zum Chat-Modell — gleicher Client, anderer Modellname
response = client.chat.completions.create(
    model="llama3",
    messages=[{"role": "user", "content": "What is the capital of Australia?"}],
)
print(response.choices[0].message.content)

Was intern passiert

Wenn eine Anfrage für qwen eingeht und llama3 aktuell geladen ist:

1. llama3 wird aus dem VRAM entladen
2. qwen-Gewichte werden von der Festplatte gelesen und in den VRAM geladen
3. die Inferenz wird ausgeführt
4. die nächste Anfrage bestimmt, ob qwen geladen bleiben soll oder erneut gewechselt wird

Dies beantwortet direkt die häufige Frage:

Wie kann ein lokaler LLM-Server Modelle wechseln, ohne neu zu starten?

Indem Modelle dynamisch pro Anfrage geladen werden und nicht beim Start gebunden werden.

Systemd-Dienst: produktionsreife Einrichtung

Erstellen Sie einen dedizierten Benutzer und Verzeichnisse

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

Kopieren Sie Ihre Binärdatei und Modellkonfiguration an den richtigen Ort:

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

Aktivieren und starten

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

Verifizieren und Logs inspizieren

sudo systemctl status llama-server

journalctl -u llama-server -f

Bei erfolgreichem Start sehen Sie Zeilen, die anzeigen, dass der Server lauscht und das Modellregister geladen wurde. Eine schnelle Plausibilitätsprüfung:

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

Jetzt haben Sie einen persistenten Dienst mit Auto-Neustart und zentralem Modellwechsel – ohne manuelles Prozessmanagement. Wenn Sie dasselbe Muster auf andere Binärdateien anwenden möchten, beschreibt Hosting einer beliebigen ausführbaren Datei als Linux-Dienst den allgemeinen Ansatz.

Die llama-server --metrics-Flagge stellt einen Prometheus-kompatiblen Endpunkt bereit. Für llama.cpp-spezifische Dashboards, PromQL-Abfragen und Alert-Regeln, sehen Sie den LLM-Inferenz-Monitoring-Leitfaden. Für die umfassendere Observability-Einrichtung deckt der Observability-Leitfaden den gesamten Stack ab.

Einschränkungen, die Sie verstehen müssen

Der Router-Modus ist wirklich nützlich, bringt aber Kompromisse mit sich, die Sie klar vor Augen haben sollten, bevor Sie ihn in der Produktion einsetzen.

Nur ein Modell im Speicher zur gleichen Zeit

Obwohl mehrere Modelle in models.ini definiert sind, ist zu jedem Zeitpunkt nur ein Modell pro Worker im VRAM resident. Ein Wechsel bedeutet einen vollständigen Entlade-/Ladezyklus.

• Wechsel bedeutet Neuladen
• Latenzspitze ist unvermeidbar
• bei einem typischen 7B-Modell bei Q5 kann ein Neuladen je nach Festplattengeschwindigkeit und VRAM-Bandbreite 3–10 Sekunden dauern

Dies beantwortet eine weitere wichtige Frage:

Unterstützt llama.cpp das Bereitstellen mehrerer Modelle gleichzeitig?

Nicht wirklich. Es unterstützt mehrere Definitionen, nicht die gleichzeitige Residenz. Wenn Sie zwei Modelle wirklich parallel geladen benötigen, benötigen Sie zwei Prozesse auf zwei separaten GPUs.

Für gemessenen VRAM-Verbrauch und Tokens pro Sekunde über Modellgrößen hinweg, deckt der LLM-Leistungsbenchmark das vollständige Bild ab. Für Zahlen spezifisch für llama.cpp auf einer 16-GB-GPU – dichte und MoE-Modelle bei mehreren Kontextgrößen – sehen Sie die 16-GB-VRAM-llama.cpp-Benchmarks.

Keine intelligente Caching

Im Gegensatz zu Ollama, das einen warmen Pool pflegt und Modelle basierend auf Aktualität verdrängt:

• gibt es keine automatische Modell-Verdrängungsstrategie
• kein Hintergrund-Pre-Warming
• keine Prioritätswarteschlange für häufig genutzte Modelle

Wenn Sie abwechselnde Anfragen für llama3 und mistral senden, löst jede einzelne Anfrage ein Neuladen aus. Das ist der fundamentale Kostenfaktor, näher am Metall zu sein.

Latenz ist für gemischte Workloads unvorhersehbar

Ein gutartigender Workload, der ein Modell konsistent nutzt, wird schnell sein. Ein Workload, der mehrere Modelle abwechselnd nutzt, wird langsam sein. Planen Sie Ihre Client-Router-Logik entsprechend – gruppieren Sie Anfragen nach Modell, wo möglich.

Konfiguration ist nicht stabil

Die INI-Unterstützung existiert und funktioniert in den meisten aktuellen Builds, ist aber nicht vollständig standardisiert. Flaggen und Parameterbezeichnungen haben sich über Versionen hinweg geändert. Wenn Sie llama-server aktualisieren, testen Sie Ihr models.ini gegen den neuen Build, bevor Sie es bereitstellen.

Llama.cpp vs Ollama: ehrlicher Vergleich

Meinungsgeprägter Standpunkt

Wählen Sie llama.cpp Router-Modus, wenn Sie wollen:

• maximale Kontrolle über Laufzeitparameter pro Modell
• minimale Prozess-Overheads
• direkten Zugriff auf llama.cpp-Flaggen ohne Abstraktionsschichten
• eine hackbare Basis für benutzerdefinierte Tools

Wählen Sie Ollama, wenn Sie wollen:

• eine stabile, polierte Erfahrung
• automatisches Modell-Downloaden und Versionierung
• intelligentes Keep-Alive und Verdrängen ohne Konfiguration
• alles ab Werk von Tag eins

Keines ist falsch. Die Wahl hängt davon ab, wie viel Sie selbst verwalten möchten.

Wenn Sie sich für Ollama entscheiden, deckt die Ollama CLI-Checkliste die täglichen Befehle ab. Für einen umfassenderen Vergleich, der auch vLLM, LM Studio und LocalAI enthält, sehen Sie wie verschiedene lokale Runtimes in 2026 verglichen werden.

Llama.cpp vs llama-swap

llama-swap ist ein externer Orchestrator, der vor einem oder mehreren llama-server-Instanzen sitzt:

• es fängt Anfragen ab und untersucht das model-Feld
• es startet den passenden llama-server-Prozess für dieses Modell
• es schaltet inaktive Instanzen nach einer konfigurierbaren Timeout-Zeit herunter
• es leitet die Anfrage weiter, sobald das Modell bereit ist

Für eine praktische Einrichtung sehen Sie den llama-swap Quickstart.

Hauptunterschied

Wann llama-swap verwenden

llama-swap bietet Ihnen prozessbasierte Isolation pro Modell, was bedeutet, dass ein Absturz in einer Modellinstanz andere nicht beeinflusst. Es ermöglicht es jedem Modell, mit völlig unabhängigen llama-server-Flaggen zu laufen.

Verwenden Sie es, wenn Sie benötigen:

• bessere Lebenszykluskontrolle und Isolation
• schlauere Wechsellogik mit konfigurierbaren Idle-Timeouts
• vorhersehbarere Latenz (jedes Modell hat nach der ersten Ladung einen warmen Prozess)
• Produktionsstabilität heute, nicht irgendwann

Wann der native Router-Modus ausreicht

Verwenden Sie den eingebauten Router, wenn Sie wollen:

• keine externen Abhängigkeiten
• einen einzigen Prozess zu verwalten
• einfachere Bereitstellung (eine Binärdatei, eine Konfigurationsdatei)
• einen minimalen Stack für Entwicklung oder Single-User-Einrichtungen

Abschließende Gedanken

Der Router-Modus ist ein bedeutender Schritt nach vorn für llama-server.

Er beantwortet die langjährige Nachfrage:

Was ist der Router-Modus im llama.cpp Server?

Es ist die fehlende Schicht, die eine statische Binärdatei in einen dynamischen Inferenzdienst verwandelt – einen einzigen Prozess, der Anfragen für einen ganzen Katalog von Modellen bearbeiten kann.

Aber er ist nicht fertig.

Heute ist er:

• leistungsstark genug für echte Workloads
• vielversprechend als Grundlage für fortschrittlicheres Routing
• an den Rändern der Konfiguration und Stabilität noch etwas rau

Wenn Ihr Workload vorhersehbar ist und Sie Anfragen nach Modell gruppieren können, funktioniert der Router-Modus heute gut. Wenn Sie produktionsreife Zuverlässigkeit und pro-Modell-Isolation benötigen, greifen Sie zu llama-swap, während die native Implementierung reift.

In jedem Fall erhalten Sie Ollama-ähnliches Verhalten, ohne die Mechanik zu verstecken.