Llama-Server Router-Modus – Dynamischer Modellwechsel ohne Neustarts

Eine lange Zeit litt llama.cpp unter einem augenfälligen Mangel: Sie konnten pro Prozess nur ein Modell bereitstellen, und ein Wechsel erforderte einen Neustart.

Diese Ära ist vorbei.

Jüngere Aktualisierungen führten den Router-Modus in llama-server ein, der etwas näher an dem ist, was man von modernen lokalen LLM-Runtimes erwartet:

• dynamisches Laden von Modellen
• Ausladen bei Bedarf
• Wechsel pro Anfrage
• kein Prozess-Neustart

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

Falls Sie noch zwischen lokalen Runtimes, Cloud-APIs und selbst gehosteter Infrastruktur abwägen, ist die Übersicht zum LLM-Hosting ein guter Einstiegspunkt.

Voraussetzungen

Der Router-Modus benötigt einen aktuellen llama-server-Build — ungefähr aus der Zeit nach Mitte 2024. Ältere Builds haben keine --models-preset- oder --models-dir-Flags.

Für Installationsmöglichkeiten (Paketmanager, vorab gebaute Binaries oder vollständiger Quellcode-Build mit CUDA) siehe die llama.cpp-Einleitung.

Sobald Sie llama-server haben, stellen Sie sicher, dass Ihr Build den Router-Modus unterstützt:

llama-server --help | grep -i models

Wenn --models-preset oder --models-dir angezeigt werden, ist alles in Ordnung. Wenn sie fehlen, aktualisieren Sie auf einen neueren Build.

Mein aktueller Ausgabe-Text für modellbezogene 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 an ein einzelnes Modell über -m gebunden zu sein, tut der Server Folgendes:

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

Die Kernidee

Sie führen nicht länger Folgendes aus:

./llama-server -m model.gguf

Sie führen Folgendes aus:

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

Und lassen den Server entscheiden, was zu laden ist und wann, basierend darauf, was der Client tatsächlich anfordert.

Dies ist wichtig, da es bedeutet, dass ein persistenter Prozess eine gesamte Flotte von Modellen bedienen kann, wobei Clients das richtige Modell pro Aufgabe auswählen — ein Coding-Modell, ein Chat-Modell, ein Zusammenfassungs-Modell — ohne Koordinationsaufwand auf Ihrer Seite.

Konfiguration: Ihre Modelle definieren

Hier sind die Dinge noch etwas in der Entwicklung.

Es gibt noch kein vollständig stabiles offizielles Format, aber aktuelle Builds unterstützen INI-artige 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 Abschnittsname wird zur Modellkennung, die Clients im "model"-Feld 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 Rechenhardware-Leitfaden eine nützliche Referenz. Um die Live-VRAM-Nutzung beim Einstellen zu überwachen, siehe die GPU-Monitoring-Tools für Linux.

Server mit Konfiguration starten

./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 Abschnittsnamen aus Ihrer models.ini als Modell-ID aufgelistet sehen.

Hinweis zur Stabilität

Die INI-Konfigurationsschnittstelle ist noch in der Entwicklung:

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

Festlegen Sie eine spezifische llama.cpp-Komponente, 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.

Registrierte Modelle auflisten

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

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

Zu einem anderen Modell wechseln — 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 behandelt den Auslade-/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")

# 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 derzeit geladen ist:

1. llama3 wird aus dem VRAM ausgeladen
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 bleibt oder wieder getauscht wird

Dies beantwortet direkt die häufige Frage:

Wie kann ein lokaler LLM-Server Modelle ohne Neustart wechseln?

Durch dynamisches Laden von Modellen pro Anfrage, statt sie beim Start zu binden.

Systemd-Service: produktionsreife Einrichtung

Dedizierten Benutzer und Verzeichnisse erstellen

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

Prüfen und Protokolle anzeigen

sudo systemctl status llama-server

journalctl -u llama-server -f

Bei einem erfolgreichen Start sehen Sie Zeilen, die darauf hinweisen, dass der Server lauscht und das Modellregister geladen wurde. Ein schneller Plausibilitätscheck:

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

Jetzt haben Sie einen persistenten Service mit automatischem Neustart und zentralem Modellwechsel — ohne manuelles Prozess-Management. Wenn Sie dasselbe Muster auf andere Binärdateien anwenden möchten, erklärt Jedes ausführbare Programm als Linux-Service hosten den allgemeinen Ansatz.

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

Einschränkungen, die Sie verstehen müssen

Der Router-Modus ist wirklich nützlich, aber er kommt mit Kompromissen, die Sie vor dem Einsatz in Produktion klar kennen sollten.

Nur ein Modell im Speicher gleichzeitig

Auch wenn mehrere Modelle in models.ini definiert sind, ist in jedem Moment nur eines pro Worker im VRAM resident. Ein Wechsel bedeutet einen vollständigen Auslade- und Ladezyklus.

• Wechsel bedeutet Neu laden
• Latenzsprünge sind unvermeidbar
• bei einem typischen 7B-Modell in Q5 kann ein Neuladen je nach Festplattengeschwindigkeit und VRAM-Bandbreite 3–10 Sekunden dauern

Dies beantwortet eine weitere wichtige Frage:

Unterstützt llama.cpp die gleichzeitige Bereitstellung mehrerer Modelle?

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

Für gemessenen VRAM-Verbrauch und Tokens pro Sekunde über Modellgrößen hinweg deckt die LLM-Leistungsbenchmarks das gesamte Bild ab. Für Zahlen speziell für llama.cpp auf einer 16-GB-GPU — dichte und MoE-Modelle bei verschiedenen Kontextgrößen — siehe die 16-GB-VRAM-llama.cpp-Benchmarks.

Kein intelligentes Caching

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

• es gibt keine automatische Modell-Eviktionsstrategie
• kein Hintergrund-Vorwärmen
• 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. Das ist der fundamentale Preis, näher an der Hardware zu sein.

Latenz ist für gemischte Workloads unberechenbar

Ein gut verhaltensfähiger Workload, der ein Modell konsequent verwendet, wird schnell sein. Ein Workload, der mehrere Modelle wechselt, wird langsam sein. Planen Sie Ihre Client-Router-Logik entsprechend — gruppieren Sie Anfragen nach Modell, wenn möglich.

Konfiguration ist nicht stabil

Die INI-Unterstützung existiert und funktioniert in den meisten aktuellen Builds, aber sie ist 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 ihn deployen.

Llama.cpp vs Ollama

Der Router-Modus schließt die alte Lücken in der Lebenszyklus-Verwaltung gegenüber Ollama — dynamisches Laden und Wechsel pro Anfrage existieren nun nativ in llama-server — aber er schließt sie nicht vollständig. Die Speicherverwaltung bleibt basisch (keine Eviktionspolitik, kein warmer Pool), die Konfigurationsstabilität ist immer noch experimentell, und der Wechsel zwischen zwei verschiedenen Modellen zahlt immer einen vollständigen Auslade- und Ladezyklus, im Gegensatz zu Ollamas TTL-basiertem Keep-Alive. Kurz gesagt: Der Router-Modus bietet maximale Kontrolle und eine anpassbare Basis; Ollama bietet ein polierteres, meinungsbasiertes Erlebnis mit weniger zu konfigurieren.

Für die vollständige Paare-Analyse — Installation, Modellverwaltung, GPU-Platzierung, KV-Cache-Steuerung, APIs, Leistung, Fehlermodi und konkrete Auslöser für die Auswahl eines oder die Migration zwischen ihnen — siehe llama.cpp vs Ollama im Jahr 2026, die die kanonische Vergleichs zwischen den beiden Runtimes auf dieser Website ist.

Wenn Sie Ollama wählen, deckt der Ollama CLI-Spickzettel die alltäglichen Befehle ab. Für einen breiteren Vergleich, der auch vLLM, LM Studio und LocalAI einschließt, siehe Wie verschiedene lokale Runtimes im Jahr 2026 miteinander vergleichbar sind.

Llama.cpp vs llama-swap

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

• es fängt Anfragen ab und prüft das model-Feld
• es startet den entsprechenden llama-server-Prozess für dieses Modell
• es schaltet inaktive Instanzen nach einem konfigurierbaren Timeout ab
• es leitet die Anfrage weiter, sobald das Modell bereit ist

Für eine praktische Einrichtung siehe die llama-swap-Einleitung.

Hauptunterschied

Wann llama-swap verwenden

llama-swap bietet prozessbasierte Isolation pro Modell, was bedeutet, dass ein Crash in einer Modellinstanz andere nicht beeinflusst. Es lässt auch jedes Modell mit völlig unabhängigen llama-server-Flags laufen.

Verwenden Sie es, wenn Sie benötigen:

• bessere Lebenszyklus-Kontrolle und Isolation
• schlauere Wechsellogik mit konfigurierbaren Idle-Timeouts
• vorhersagbarere 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 möchten:

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

Abschließende Gedanken

Der Router-Modus ist ein bedeutsamer Fortschritt für llama-server.

Er beantwortet die langjährige Nachfrage:

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

Er ist die fehlende Schicht, die eine statische Binärdatei in einen dynamischen Inferenz-Service verwandelt — einen Prozess, der Anfragen für einen ganzen Katalog von Modellen bearbeiten kann.

Aber er ist nicht fertig.

Heute ist er:

• leistungsfähig genug für echte Workloads
• vielversprechend als Grundlage für anspruchsvolleres Routing
• etwas rauh an den Rändern der Konfiguration und Stabilität

Wenn Ihr Workload vorhersagbar ist und Sie Anfragen nach Modell gruppieren können, funktioniert der Router-Modus heute gut. Wenn Sie produzierungsreife Zuverlässigkeit und prozessbasierte Isolation pro Modell 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-Lauf, ein Wartungsfenster oder einen sauberen Entwicklungsrücksetz — ist der skriptbare Ansatz, geladene Modelle aufzulisten und für jedes den Auslade-Endpunkt aufzurufen. Das vollständige curl-und-jq-Muster ist in Alle llama.cpp-Router-Modelle ohne Neustart ausladen.

Entweder Weg, Sie erhalten Ollama-ähnliches Verhalten, ohne die Mechanik zu verbergen.