Lokale KI-Modelle ohne Neustart: llama.cpp Router-Modus

llama.cpp hat kürzlich 100.000 GitHub-Sterne überschritten — ein Meilenstein, der die Reife des lokalen KI-Ökosystems unterstreicht. Projekt-Gründer Georgi Gerganov schrieb dazu auf X, er prognostiziere, dass "90% of all AI agents will be running locally with llama.cpp" — und fügte hinzu, dass ihm das eine Gelegenheit sei, auf den zurückgelegten Weg zurückzublicken.

Die Zahl ist bemerkenswert, aber das eigentlich Wichtige für Teams, die lokale KI produktiv einsetzen wollen, ist ein konkretes neues Feature: der Router-Modus des llama-server. Damit lassen sich mehrere lokale LLMs aus einer einzigen Server-Instanz heraus bedienen — ganz ohne Neustart, ganz ohne Cloud, ganz ohne API-Kosten.

Was ist der Router-Modus?

Bis vor kurzem hatte llama-server eine grundlegende Einschränkung: pro Prozess ein Modell. Wer auf einem Mac Studio M3 Ultra gleichzeitig ein Coding-Modell, einen allgemeinen Chat-Assistenten und ein Analyse-Modell betreiben wollte, musste drei separate Serverprozesse starten und eine eigene Routing-Logik aufbauen — oder auf Ollama ausweichen.

Mit dem neuen Router-Modus ist das Geschichte. Wie Victor Mustar auf X berichtet, bringt llama.cpp jetzt Ollama-ähnliche Modellverwaltung mit:

"Auto-discover GGUFs from cache • Load on first request • Each model runs in its own process • Route by model (OpenAI-compatible API) • LRU unload at --models-max"

Ein einziger llama-server-Prozess übernimmt die Rolle eines Multi-Modell-Load-Balancers. Jedes Modell läuft in einem eigenen Child-Prozess — wenn eines abstürzt, laufen die anderen weiter. Modelle werden beim ersten API-Aufruf geladen und nach dem LRU-Prinzip (Least Recently Used) entladen, sobald das Limit --models-max erreicht ist.

Einrichtung in der Praxis

Der Einstieg ist denkbar einfach: Wird llama-server ohne --model-Flag gestartet, wechselt er automatisch in den Router-Modus. GGUF-Modelldateien werden aus dem Cache-Verzeichnis automatisch erkannt.

# Router-Modus: kein --model Flag, dafür --models-max setzen
llama-server --port 8080 --models-max 3

Anfragen an die OpenAI-kompatible API werden wie gewohnt gestellt — der Modellname im model-Feld entscheidet, welches Modell die Anfrage bearbeitet:

{
  "model": "qwen2.5-coder-7b-q4_k_m",
  "messages": [{"role": "user", "content": "Erkläre diesen Python-Code:"}]
}

Wird das Modell nicht gefunden, lädt der Router es beim ersten Aufruf aus dem Cache. Ist das --models-max-Limit erreicht, wird das am längsten inaktive Modell entladen, bevor das neue geladen wird. Laut Community-Berichten liegt die Umschaltzeit bei 3–10 Sekunden — je nach Lese-Geschwindigkeit des Datenträgers und VRAM-Bandbreite.

Drei Modelle, ein Server: KMU-Szenarien

Szenario 1: Software-Entwicklungsteam

Ein fünfköpfiges Entwicklungsteam betreibt auf einem Mac Studio M3 Ultra (192 GB) bis zu drei Modelle gleichzeitig:

• DeepSeek-R1:32B (Q4) für komplexes Reasoning und Code-Review
• Qwen2.5-Coder:7B (Q8) für schnelle Code-Vervollständigung im IDE-Plugin
• Llama 3.3:70B (Q4) für Dokumentation und allgemeine Team-Anfragen

Mit --models-max 3 bleiben alle drei im Speicher. Jede Anwendung — IDE-Plugin, Slack-Bot, CI-Pipeline — wählt das passende Modell per model-Feld in der API-Anfrage, ohne dass ein Administrator den Server anpassen muss.

Szenario 2: Bürobetrieb mit mehreren Abteilungen

Auch in Nicht-Tech-Unternehmen deckt der Router-Modus unterschiedliche Bedürfnisse ab:

• Buchhaltung: kleines Phi-4-Modell (3,8B) für Belegkategorisierung und DATEV-Klassifizierung
• Kundenservice: Llama 3.3 für strukturierte E-Mail-Entwürfe und FAQ-Antworten
• Übersetzung: Qwen 2.5 für Deutsch/Spanisch/Englisch-Übersetzungen ohne Drittanbieter

Alle Abteilungen nutzen denselben internen API-Endpunkt. Kein Mitarbeiter kommuniziert mit externen Servern — das DSGVO-Risiko bleibt bei null.

Szenario 3: Zeitgesteuerter Batch-Betrieb

Über Nacht verarbeitet ein großes Modell (70B) Batch-Analysen von Kundendaten oder Vertragsarchiven. Tagsüber übernehmen kleinere, schnellere Modelle die interaktiven Anfragen. Der LRU-Cache kümmert sich um den Wechsel vollautomatisch — kein Cron-Job, kein Neustart.

Router-Modus vs. Ollama: Was passt wann?

Ollama bleibt eine exzellente Wahl für Teams, die schnell starten und eine einfache Verwaltungsoberfläche schätzen. Der Unterschied liegt im Grad der Kontrolle:

Der Router-Modus von llama.cpp ist die bessere Wahl, wenn maximale Inference-Geschwindigkeit, feingranulare Prozesskontrolle oder Integration in bestehende DevOps-Pipelines gefragt sind. Ollama bleibt vorzuziehen für Teams mit heterogenem technischen Hintergrund oder wenn die grafische Verwaltungsoberfläche gebraucht wird.

Hardware und Kosten

Der Router-Modus verändert keine Hardware-Anforderungen: Arbeitsspeicher bleibt der entscheidende Faktor. Je mehr aktive Modelle parallel im Speicher gehalten werden sollen, desto mehr RAM wird benötigt.

Laut Community-Messungen erzielen 7B-Modelle in Q4 auf Apple Silicon zwischen 30 und 80 Tokens pro Sekunde — deutlich schneller als viele Cloud-APIs unter Last, ohne Latenz durch Netzwerkübergang.

Die Amortisationsrechnung ist für viele KMU überzeugend: Ein Mac Studio M3 Max kostet rund 2.000–3.500 €, ersetzt dauerhaft API-Ausgaben, die bei aktivem Einsatz 300–600 € monatlich betragen können. Der Break-Even liegt typischerweise bei 4–8 Monaten.

Datenschutz ohne Abstriche

Der tiefgreifendste Vorteil gegenüber Cloud-Lösungen bleibt unverändert: Kein Datum verlässt das Firmennetz. Kein API-Schlüssel, kein DSGVO-Drittland-Transfer, kein Einblick eines Drittanbieters in Ihre Prompts oder Antworten.

Für Branchen mit erhöhten Anforderungen — Recht, Medizin, Finanzen, Personalwesen — ist lokale Inferenz keine Option, sondern oft die einzige compliant Wahl. Mehr dazu auf unserer Seite zu lokaler KI und Datensouveränität sowie in unserem Überblick zu lokaler KI für Unternehmen.

Nächster Schritt

Der Router-Modus macht llama.cpp zum zentralen Inference-Server für Teams mit vielfältigen Modell-Bedürfnissen — ohne externe Abhängigkeiten, ohne Token-Kosten, ohne Datenschutzrisiko. Wer bisher Ollama als Einstieg genutzt hat und mehr Kontrolle und Rohleistung will, findet hier die natürliche nächste Stufe.

Wenn Sie wissen möchten, welcher lokale KI-Stack für Ihr Unternehmen am besten geeignet ist, starten Sie mit uns ein Pilotprojekt — in zwei Wochen läuft Ihr erster interner Multi-Modell-Server.