Llama-Server Router-Modus – Dynamisches Modellwechseln ohne Neustart

Lange Zeit hatte llama.cpp eine offensichtliche Einschränkung: Man konnte nur ein Modell pro Prozess bereitstellen, und ein Wechsel bedeutete einen Neustart.

Diese Ära ist vorbei.

Neue Updates haben den Router-Modus in llama-server eingeführt und bringen etwas, das dem, was man von modernen lokalen LLM-Runtimes erwartet, viel näher kommt:

• dynamisches Laden von Modellen
• entladen auf Anfrage
• Wechsel pro Anfrage
• kein Neustart des Prozesses

Mit anderen Worten: Ollama-ähnliches Verhalten, aber ohne Trainingssupport.

Wenn Sie noch zwischen lokalen Runtimes, Cloud-APIs und selbst gehosteter Infrastruktur schwanken, ist der Überblick zur LLM-Hosting ein guter Ausgangspunkt.

Voraussetzungen

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

Für Installationsoptionen (Paketmanager, vorkompilierte Binärdateien oder vollständiger Quellcode-Build mit CUDA) siehe den llama.cpp Quickstart.

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

llama-server --help | grep -i models

Wenn --models-preset oder --models-dir erscheint, sind Sie gut aufgehoben. Fehlen sie, aktualisieren Sie auf einen neueren Build.

Meine aktuelle Ausgabe der modellbezogenen 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 Modelldispatcher.

Anstatt sich ü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 aus
• 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 aus:

./llama-server -m model.gguf

Sie führen aus:

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

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

Dies ist wichtig, weil es bedeutet, dass ein einzelner, persistent laufender 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 sind die Dinge noch etwas roh.

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 zur Modellkennung, die Clients im Feld "model" ihrer API-Anfragen verwenden.

Wichtige Konfigurationsparameter

Die Wahl des richtigen ngl-Werts hängt vom verfügbaren VRAM Ihrer GPU ab – für GPU-Auswahl und Hardware-Ökonomie ist der Leitfaden zur Compute-Hardware eine nützliche Referenz. Um die VRAM-Nutzung beim Feintuning live zu beobachten, siehe die GPU-Monitoring-Tools für Linux.

Starten des Servers mit Konfiguration

./llama-server --models-preset /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 Ihrer models.ini als Modell-ID aufgelistet sehen.

Ein Hinweis zur Stabilität

Die INI-Konfigurations-Schnittstelle entwickelt sich noch:

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

Binden Sie sich an einen spezifischen llama.cpp-Commit, wenn Sie Reproduzierbarkeit über Neustarts hinweg benötigen.

API-Nutzung: Wechseln der Modelle pro Anfrage

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

Registrierte Modelle auflisten

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

Completion-Anfrage — 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 handhabt den Entlade-/Lade-Zyklus 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")

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

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. Inferenz läuft
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 er Modelle pro Anfrage dynamisch lädt, anstatt sie beim Start zu binden.

Systemd-Dienst: produktionsreifes Setup

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 die Modellkonfiguration an die richtige Stelle:

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

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 einem erfolgreichen Start sehen Sie Zeilen, die anzeigen, dass der Server hört 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 automatischem Neustart und zentralem Modellwechsel – kein manuelles Prozessmanagement erforderlich. Wenn Sie dasselbe Muster auf andere Binärdateien anwenden möchten, erläutert Hosting any executable as a Linux service den allgemeinen Ansatz.

Das llama-server-Flag --metrics stellt einen Prometheus-kompatiblen Endpunkt bereit. Für llama.cpp-spezifische Dashboards, PromQL-Abfragen und Alerting-Regeln siehe den Leitfaden zur LLM-Inferenz-Monitoring. Für die umfassendere Observability-Einrichtung deckt der Observability-Leitfaden den vollständigen Stack ab.

Einschränkungen, die Sie verstehen müssen

Der Router-Modus ist genuinely nützlich, aber er kommt mit Kompromissen, über die Sie sich im Klaren sein sollten, bevor Sie ihn in der Produktion einsetzen.

Nur ein Modell im Speicher zur gleichen Zeit

Obwohl mehrere Modelle in models.ini definiert sind, befindet sich zu jedem gegebenen Zeitpunkt nur eines im VRAM pro Worker. Ein Wechsel bedeutet einen vollständigen Entlade- und Neuladezyklus.

• Wechsel bedeutet Neuladen
• Latenzspike ist unvermeidlich
• bei einem typischen 7B-Modell in Q5 kann ein Neuladen je nach Festplatten- 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 simultane Residenz. Wenn Sie zwei Modelle genuinely parallel geladen benötigen, benötigen Sie zwei Prozesse auf zwei separaten GPUs.

Für gemessene VRAM-Nutzung und Tokens pro Sekunde über verschiedene Modellgrößen hinweg decken die LLM-Leistungsbenchmarks das vollständige Bild ab. Für Zahlen speziell für llama.cpp auf einer 16-GB-GPU – dense und MoE-Modelle bei mehreren Kontextgrößen – siehe die 16-GB-VRAM-llama.cpp-Benchmarks.

Kein intelligentes Caching

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

• es gibt keine automatische Modelleviktionsstrategie
• kein Hintergrund-Pre-Warming
• keine Prioritätswarteschlange für häufig verwendete Modelle

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

Latenz ist für gemischte Workloads unvorhersehbar

Ein gutartiger Workload, der ein Modell konsistent verwendet, wird schnell sein. Ein Workload, der mehrere Modelle durchmischt, wird langsam sein. Planen Sie Ihre Client-Routing-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. Flags und Parameternamen haben sich über Versionen hinweg geändert. Wenn Sie llama-server aktualisieren, testen Sie Ihre models.ini gegen den neuen Build, bevor Sie bereitstellen.

Llama.cpp vs Ollama: ehrlicher Vergleich

Meinungsstarker Standpunkt

Wählen Sie den llama.cpp-Router-Modus, wenn Sie Folgendes möchten:

• maximale Kontrolle über Laufzeitparameter pro Modell
• minimalen Prozess-Overhead
• direkten Zugriff auf llama.cpp-Flags ohne Abstraktionsebenen
• eine hackbare Basis für benutzerdefinierte Tools

Wählen Sie Ollama, wenn Sie Folgendes möchten:

• ein stabiles, poliertes Erlebnis
• automatisches Herunterladen und Versionieren von Modellen
• intelligentes Keep-Alive und Eviktionsverhalten ohne Konfiguration
• alles ab Werk (Batteries Included)

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

Wenn Sie Ollama wählen, deckt die Ollama CLI Cheatsheet die täglichen Befehle ab. Für einen breiteren Vergleich, der auch vLLM, LM Studio und LocalAI einschließt, siehe wie verschiedene lokale Runtimes 2026 verglichen werden.

Llama.cpp vs llama-swap

llama-swap ist ein externer Orchestrierer, der vor einer oder mehreren llama-server-Instanzen steht:

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

Für ein praktisches Setup siehe den llama-swap Quickstart.

Hauptunterschied

Wann man llama-swap verwenden sollte

llama-swap bietet Ihnen Prozess-Isolation pro Modell, was bedeutet, dass ein Absturz einer Modellinstanz andere nicht beeinflusst. Es ermöglicht auch, dass jedes Modell mit vollständig unabhängigen llama-server-Flags läuft.

Verwenden Sie es, wenn Sie Folgendes benötigen:

• bessere Lebenszykluskontrolle und Isolation
• intelligenteres Switching-Verhalten mit konfigurierbaren Idle-Timeouts
• vorhersehbarere Latenz (jedes Modell hat nach dem ersten Laden einen warmen Prozess)
• Produktionsstabilität heute, nicht irgendwann

Wann der native Router-Modus ausreicht

Verwenden Sie den eingebauten Router, wenn Sie Folgendes möchten:

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

Letzte Gedanken

Der Router-Modus ist ein bedeutsamer Schritt nach vorne für llama-server.

Er beantwortet die langjährige Nachfrage:

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

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

Aber er ist nicht fertig.

Heute ist er:

• mächtig genug für echte Workloads
• vielversprechend als Grundlage für ausgefeilteres 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 Modell-Isolation benötigen, greifen Sie zu llama-swap, während die native Implementierung reift.

Wenn Sie VRAM freigeben müssen, ohne neu zu starten – für einen Benchmark-Run, ein Wartungsfenster oder einen sauberen Entwicklungszurücksetzung – ist der skriptbare Ansatz, geladene Modelle aufzulisten und den Entlade-Endpunkt für jedes aufzurufen. Das vollständige curl-und-jq-Muster wird in Alle llama.cpp-Router-Modelle entladen, ohne Neustart behandelt.

Auf jeden Fall erhalten Sie Ollama-ähnliches Verhalten, ohne die Mechanik zu verbergen.