Llama.cpp vs. vLLM: Lokale LLM-Server im Vergleich

Lokale Large Language Models sind im Arbeitsalltag angekommen. Sprachmodelle können auf dem eigenen Rechner, in der Entwicklungsumgebung oder auf Unternehmenshardware laufen: als Chat-Assistent, Coding-Hilfe, RAG-System oder Teil eines Agenten-Workflows.

Für die Inferenz tauchen besonders oft zwei Namen auf: llama.cpp und vLLM. Beide stellen Modelle lokal bereit und können sich über OpenAI-kompatible Schnittstellen in bestehende Anwendungen einfügen. Ihre Stärken liegen jedoch in sehr verschiedenen Umgebungen.

Die Kurzfassung: llama.cpp eignet sich besonders für einzelne Modelle auf Consumer-Hardware, auch ohne leistungsfähige GPU. vLLM ist auf leistungsfähige Beschleuniger und viele gleichzeitige Anfragen ausgelegt. Für eine belastbare Entscheidung lohnt sich ein genauer Blick auf Speicher, Parallelität, Modellformate und Betriebsmodell.

Warum ein LLM lokal ausführen?

Wer ein Modell selbst betreibt, möchte meist eines oder mehrere praktische Probleme lösen:

• Kostenkontrolle: Bei regelmäßiger Nutzung können API-Kosten spürbar werden. Eigene Hardware verlagert die Kosten in Infrastruktur, Betrieb und Energie.
• Datenschutz und Sicherheit: Eingaben und Dokumente verbleiben im eigenen Umfeld, sofern die gesamte Verarbeitung lokal organisiert ist.
• Unabhängigkeit: Externe Rate Limits, Service-Ausfälle und Änderungen am Angebot eines API-Anbieters beeinflussen den Betrieb weniger.
• Offline-Fähigkeit: In Umgebungen mit eingeschränkter oder fehlender Internetverbindung kann ein lokales Modell weiterarbeiten.
• Kontrolle über Modelle: Teams können Open-Weight-Modelle herunterladen, testen und für konkrete Aufgaben auswählen.

Lokaler Betrieb löst allerdings nicht automatisch alle Sicherheitsfragen. Besonders bei RAG-Anwendungen gehören Berechtigungen, Quellenangaben und Protokollierung zur Architektur. Einen Überblick dazu bietet der Beitrag Architekturen für sichere RAG-Systeme im Unternehmen.

Was sind llama.cpp und vLLM?

llama.cpp: Lokale Inferenz mit wenig Hardware

llama.cpp ist eine Inferenz-Engine, die Modelle auf vergleichsweise kleiner Hardware zugänglich macht. Sie kann auf CPUs laufen und unterstützt auch GPUs. Damit eignet sie sich für Desktop-PCs, Laptops und kleinere Systeme, auf denen kein großes Rechenzentrum und keine High-End-Grafikkarte bereitstehen.

Der Kern des Ansatzes ist, Modelle möglichst speichersparend auszuführen. Das macht llama.cpp interessant für persönliche Assistenten, lokale Tests, Offline-Szenarien und Anwendungen am Rand des Netzwerks, etwa in IoT- oder Produktionsumgebungen.

Auf llama.cpp bauen weitere verbreitete Werkzeuge auf, darunter Ollama und LM Studio. Wer diese Tools bereits nutzt, arbeitet daher oft indirekt mit den Optimierungen des llama.cpp-Ökosystems.

vLLM: Lokale Inferenz für hohen Durchsatz

vLLM ist ebenfalls eine Engine für die Modellinferenz, richtet sich aber stärker an produktive Server-Workloads. Die Software ist dafür gedacht, viele Anfragen effizient auf Hardwarebeschleunigern zu verarbeiten, etwa auf GPUs und weiteren Accelerator-Plattformen.

Typische Einsatzorte sind leistungsfähige Server, virtuelle Maschinen und Kubernetes-Umgebungen. vLLM spielt seine Vorteile aus, wenn mehrere Nutzende, Anwendungen oder Agenten gleichzeitig auf Modelle zugreifen und Antwortzeiten auch unter Last stabil bleiben sollen.

Neben Textmodellen kann vLLM mit unterschiedlichen Modellarten umgehen, etwa für Audio-, Bild- und Videoverarbeitung. Die konkrete Unterstützung hängt dabei immer vom jeweiligen Modell und der eingesetzten Plattform ab.

Der wichtigste Unterschied: Einzelplatz oder skalierbarer Dienst?

Die Wahl lässt sich häufig anhand einer einfachen Betriebsfrage eingrenzen: Läuft das Modell für eine Person oder wird es als Dienst für viele parallele Anfragen bereitgestellt?

Bereich	llama.cpp	vLLM
Typische Hardware	CPU, Consumer-GPU, Laptop, kompakte Systeme	Server mit Hardwarebeschleunigern
Typischer Einsatz	Persönlicher lokaler Assistent, Testumgebung, Offline-Betrieb	Produktiver Modellserver, Teams, Anwendungen mit hoher Last
Priorität	Kleiner Speicherbedarf und breite lokale Nutzbarkeit	Durchsatz, Parallelität und effiziente Speichernutzung unter Last
Skalierung	Gut für einzelne oder wenige gleichzeitige Nutzungen	Für viele fortlaufend eintreffende Anfragen ausgelegt
Modellbereitstellung	Häufig über GGUF-Dateien	Breite Modell- und Beschleunigerunterstützung in Serverumgebungen

Beide Systeme können Grundlage für RAG, Tool-Use, Code-Assistenten und Agenten sein. Der Unterschied liegt vor allem darin, wie effizient sie mit der vorhandenen Hardware und mit gleichzeitig eintreffenden Anfragen umgehen.

Wie llama.cpp Modelle auf kleiner Hardware ausführt

Quantisierung reduziert den Speicherbedarf

Sprachmodelle bestehen aus sehr vielen Gewichten, die in einer bestimmten numerischen Präzision gespeichert werden. Diese Präzision beeinflusst die Modellgröße und den Bedarf an Video- oder Arbeitsspeicher erheblich.

Bei der Quantisierung werden Werte mit weniger Genauigkeit abgelegt. Vereinfacht ähnelt das dem Runden einer langen Dezimalzahl: Für viele Zwecke reicht eine kürzere Darstellung aus. Bei Modellen können beispielsweise niedrigere Zahlenformate verwendet werden, wodurch ein Modell deutlich weniger Speicher beansprucht.

Das bringt einen klaren praktischen Vorteil: Ein Modell, das in einer höheren Präzision viel Grafikspeicher benötigen würde, kann nach der Quantisierung in einer kleineren Variante auf verfügbarer Consumer-Hardware laufen. Dafür kann sich die Ausgabequalität je nach Modell und Quantisierungsgrad verändern. Wer Modelle vergleicht, sollte Qualität, Geschwindigkeit und Speicherverbrauch gemeinsam bewerten.

GGUF vereinfacht die Modellverteilung

Im llama.cpp-Umfeld ist das Dateiformat GGUF besonders relevant. Es bündelt Modellgewichte und zugehörige Informationen wie Tokenizer und Konfiguration in einer Datei. Das erleichtert das Herunterladen, Austauschen und Ausprobieren verschiedener Modelle.

Für lokale Experimente ist das angenehm unkompliziert: Modell auswählen, passende quantisierte GGUF-Variante laden und mit einer kompatiblen Laufzeit starten. Für einen produktiven Betrieb bleiben trotzdem Fragen zu Modellversionen, Zugriffskontrollen und Ressourcenplanung bestehen.

CPU-Inferenz erweitert die Einsatzmöglichkeiten

Viele persönliche Rechner haben keine dedizierte GPU oder nur begrenzten Grafikspeicher. llama.cpp kann auch die CPU für die Inferenz verwenden. Die Antwortgeschwindigkeit hängt dann stark von Modellgröße und Prozessor ab, aber der lokale Betrieb wird überhaupt erst möglich.

Das ist vor allem sinnvoll, wenn Datenschutz, Offline-Verfügbarkeit oder ein einfacher Entwicklungsaufbau wichtiger sind als maximale Tokenrate.

Wie vLLM viele Anfragen effizient verarbeitet

Continuous Batching hält die Hardware beschäftigt

Bei einem Modellserver treffen Anfragen selten gleichzeitig ein und sie dauern unterschiedlich lange. Würde ein System immer warten, bis eine feste Gruppe von Anfragen vollständig abgeschlossen ist, bliebe Rechenkapazität ungenutzt.

vLLM nutzt Continuous Batching. Neue Anfragen können in die Verarbeitung aufgenommen werden, während andere bereits Antworten erzeugen. Fertige Anfragen blockieren dadurch nicht den nächsten Arbeitsschritt für alle übrigen. Das erhöht den Durchsatz bei vielen parallelen Zugriffen.

Für einen internen Chatdienst, mehrere RAG-Anwendungen oder Agentenprozesse kann diese Fähigkeit den Unterschied zwischen einem flüssig arbeitenden Service und einer schnell überlasteten Instanz ausmachen.

KV-Cache effizient verwalten

Während ein Sprachmodell eine Antwort erzeugt, verarbeitet es Eingabetokens und erzeugt weitere Tokens Schritt für Schritt. Dabei entstehen Zwischenergebnisse, die im sogenannten Key-Value-Cache, kurz KV-Cache, abgelegt werden.

Dieser Cache kann viel Speicher belegen. Bei großen Prompts, längeren Kontexten und vielen gleichzeitigen Anfragen wächst der Bedarf besonders stark. Neben den Modellgewichten selbst muss daher auch Platz für diese Zwischenergebnisse eingeplant werden.

vLLM optimiert die Nutzung dieses Speichers mit Paged Attention. Das Verfahren verwaltet Cache-Speicher in kleineren Einheiten und hilft, die begrenzte Kapazität eines Beschleunigers effizienter auszunutzen. Für produktive Systeme ist das relevant, weil Speicherengpässe die Zahl paralleler Anfragen begrenzen können.

Speculative Decoding kann Antworten beschleunigen

vLLM kann Verfahren einsetzen, bei denen ein kleineres Modell mögliche nächste Textteile vorbereitet und ein größeres Modell diese Vorschläge prüft. Dieser Ansatz wird oft als Speculative Decoding bezeichnet.

Wenn die Vorschläge passen, lässt sich die Generierung beschleunigen. Die konkrete Wirkung hängt von den verwendeten Modellen, der Aufgabe und der Hardware ab. Es handelt sich daher um eine Optimierung, die getestet werden sollte, statt pauschal als garantierter Geschwindigkeitsgewinn zu gelten.

Welche Lösung für RAG, Agenten und Coding-Assistenten?

RAG-Systeme, KI-Agenten und Coding-Assistenten benötigen nicht zwangsläufig eine bestimmte der beiden Engines. Beide können Modelle bereitstellen, die über OpenAI-kompatible Endpunkte angesprochen werden. Anwendungen können damit häufig weiterhin bekannte Schnittstellen für Chat-Completions oder Responses verwenden.

Das ist besonders hilfreich, wenn ein Team zuerst mit einer gehosteten API entwickelt und später auf einen eigenen Modellserver umstellt. Der Wechsel betrifft dann vor allem Basis-URL, Zugangsdaten, Modellbezeichnung und Betriebsumgebung. Dennoch sollte die Anwendung gründlich getestet werden, denn Modellverhalten, Tool-Aufrufe, Kontextfenster und Antwortformate können sich unterscheiden.

RAG-Anwendungen

Für einen einzelnen lokalen Wissensassistenten kann llama.cpp ausreichen, sofern Modell und Embedding-Workflow auf der verfügbaren Hardware sinnvoll laufen. Wenn viele Mitarbeitende gleichzeitig auf Dokumente zugreifen, steigen Anforderungen an Parallelität und Cache-Verwaltung. Dann ist vLLM oft die passendere Basis für den Modellserver.

Auch das beste Modell darf in einem Unternehmens-RAG nicht frei über alle Daten verfügen. Quellenpflicht, Berechtigungen und Nachvollziehbarkeit senken das Risiko überzeugend klingender Falschaussagen. Dazu passt auch der Leitfaden KI-Halluzinationen im Unternehmen vermeiden.

KI-Agenten und Tool-Use

Agenten erzeugen oft viele kurze, aufeinanderfolgende Modellanfragen: planen, Werkzeug auswählen, Ergebnis prüfen, nächsten Schritt formulieren. Bei wenigen lokalen Experimenten ist llama.cpp eine pragmatische Option. Bei mehreren gleichzeitig laufenden Agenten oder vielen Nutzenden gewinnt die Fähigkeit von vLLM zur effizienten parallelen Verarbeitung an Gewicht.

Lokale Coding-Assistenten

Ein Coding-Assistent auf dem persönlichen Rechner profitiert häufig von einer schlanken, lokalen Installation und quantisierten Modellen. llama.cpp passt daher gut zu diesem Szenario. Ein zentral bereitgestellter Code-Assistent für ein Entwicklungsteam verlangt meist nach serverseitigem Betrieb, ausreichender Beschleuniger-Hardware und sauberem Zugriffsmanagement. Dafür ist vLLM ausgelegt.

Auswahlhilfe: llama.cpp oder vLLM?

Diese Checkliste hilft bei der ersten Einordnung.

llama.cpp passt häufig, wenn Sie:

• ein Modell auf Laptop, Desktop-PC oder kompakter Hardware betreiben möchten,
• keine große Server-GPU voraussetzen können,
• quantisierte GGUF-Modelle nutzen wollen,
• offline arbeiten müssen oder wollen,
• einen persönlichen Assistenten, ein lokales Experiment oder einen Einzelplatz-Workflow aufbauen,
• mit Ollama, LM Studio oder ähnlichen lokalen Werkzeugen arbeiten.

vLLM passt häufig, wenn Sie:

• einen Modellserver für mehrere Nutzende oder Anwendungen bereitstellen,
• viele parallele Anfragen effizient verarbeiten müssen,
• leistungsfähige Beschleuniger in Server-, VM- oder Kubernetes-Umgebungen einsetzen,
• hohen Durchsatz und effiziente KV-Cache-Nutzung benötigen,
• unterschiedliche Modelltypen in einer skalierbaren Infrastruktur bedienen möchten.

Häufige Fehler bei lokalen LLMs

Nur auf die Modellgröße schauen

Die Parameterzahl allein sagt wenig darüber aus, ob ein Modell gut auf der eigenen Hardware läuft. Relevant sind auch Quantisierung, verfügbare VRAM-Kapazität, Arbeitsspeicher, Kontextlänge, KV-Cache und die Zahl paralleler Anfragen.

Consumer-Hardware wie einen Produktionscluster behandeln

Ein Modell kann auf einem Laptop überzeugende Einzelantworten liefern und bei mehreren parallelen Anfragen trotzdem schnell an Grenzen stoßen. Für den produktiven Betrieb sollten Last, Antwortzeit und Speicherverbrauch unter realistischen Bedingungen geprüft werden.

Ein API-kompatibles Interface mit identischem Modellverhalten verwechseln

OpenAI-kompatible Endpunkte erleichtern die Integration. Sie garantieren nicht, dass jedes Modell dieselben Antworten, Tool-Aufrufe oder strukturierten Ausgaben liefert. Prompts, Tests und Sicherheitsmechanismen müssen bei einem Modellwechsel überprüft werden.

Datenschutz mit einer lokalen Installation abhaken

Lokale Inferenz kann Datenflüsse stark reduzieren. In einem Unternehmenssystem bleiben Fragen offen: Wer darf welche Dokumente abrufen? Werden Prompts und Antworten protokolliert? Wo liegen Vektordatenbanken und Backups? Wie werden Modell- und Dokumentversionen kontrolliert?

Benchmarks ohne eigenen Anwendungsfall übernehmen

Ein Spitzenplatz in einer Rangliste beantwortet nicht automatisch, welches Modell für Support, Code, Dokumentensuche oder interne Prozesse geeignet ist. Aussagekräftig wird die Auswahl mit eigenen Testfällen, realistischen Kontexten und klaren Qualitätskriterien. Wie sich Modelle praxisnah bewerten lassen, erklärt KI-Benchmarks richtig bewerten.

Praktischer Entscheidungsprozess für lokale LLM-Inferenz

1. Anwendungsfall festlegen: Persönlicher Assistent, RAG, Coding, Agenten oder zentraler Unternehmensservice benötigen unterschiedliche Ressourcen.
2. Last abschätzen: Prüfen Sie die erwartete Zahl gleichzeitiger Anfragen, Kontextlängen und Antwortlängen.
3. Hardware erfassen: Verfügbaren CPU-, RAM- und VRAM-Ausbau sowie vorhandene Beschleuniger dokumentieren.
4. Passendes Modellformat wählen: Für llama.cpp sind quantisierte GGUF-Modelle besonders naheliegend. Für vLLM zählen Modell- und Hardwarekompatibilität im Zielsystem.
5. Mit realen Beispielen testen: Verwenden Sie typische Dokumente, Prompts, Tool-Aufrufe und Lastmuster.
6. Betrieb absichern: Zugriffsrechte, Monitoring, Protokollierung, Datenhaltung und Updates vor der breiten Nutzung planen.

Fazit: Die passende Engine folgt der Betriebsrealität

llama.cpp macht lokale LLMs auf kleiner und alltäglicher Hardware praktikabel. Quantisierung, GGUF und CPU-Unterstützung helfen dabei, Modelle auch ohne große GPU-Infrastruktur auszuführen.

vLLM richtet sich an Umgebungen, in denen ein Modellserver zuverlässig viele Anfragen bedienen soll. Continuous Batching, optimierte Cache-Verwaltung und die Ausrichtung auf Hardwarebeschleuniger machen es zur starken Wahl für skalierbare Inferenz.

Wer lokal auf dem eigenen Rechner experimentiert oder einen privaten Assistenten betreibt, findet in llama.cpp meist einen einfachen Einstieg. Wer einen dienstfähigen KI-Stack für Teams, RAG-Anwendungen oder Agenten unter Last aufbauen will, sollte vLLM und die erforderliche Serverinfrastruktur prüfen.