llama.cpp vs. vLLM vs. Exllama

#Inferenz-Engines: Was sie wirklich unterscheidet

Eine Inferenz-Engine wandelt Eingabetokens in Ausgabetokens um. Die Anwendungen, die Sie installieren (Ollama, LM Studio, Jan), enthalten eine solche Engine; Produktionsserver (vLLM, SGLang) sind selbst eine. Drei Unterschiede wirken sich auf Ihre Nutzung aus: die unterstützten Modellformate, die nutzbare Hardware und die Art, wie mehrere Anfragen gleichzeitig verarbeitet werden.

#Das Modellformat bestimmt, welche Inferenz-Engine verwendet werden kann

Bevor Sie Geschwindigkeiten vergleichen, prüfen Sie, in welchem Format das gewünschte Modell veröffentlicht ist. Eine GGUF-Datei lässt sich in llama.cpp und damit auch in Ollama, LM Studio und Jan laden. Modellgewichte von Hugging Face in FP16, FP8 oder mit AWQ oder GPTQ quantisiert lassen sich in vLLM oder SGLang laden. Ein für MLX konvertiertes Modell lässt sich auf dem Mac mit MLX LM laden, ein EXL3-Modell mit ExLlamaV3. Ein Wechsel der Inferenz-Engine bedeutet oft, das Modell in einem anderen Format erneut herunterzuladen.

#llama.cpp: der portable Standard

llama.cpp ist eine C/C++-Implementierung ohne Abhängigkeiten, deren erklärtes Ziel es ist, Inferenz mit minimalem Konfigurationsaufwand auf einem breiten Spektrum an Hardware zu ermöglichen. Apple Silicon wird dabei vorrangig berücksichtigt (NEON, Accelerate, Metal), x86-CPUs werden mit AVX, AVX2, AVX512 und AMX unterstützt, ebenso NVIDIA-GPUs (CUDA), AMD-GPUs (HIP) sowie Vulkan und SYCL. llama.cpp bietet Quantisierungen von 1,5 bis 8 Bit und hybride Inferenz auf CPU und GPU, mit der sich ein Modell ausführen lässt, dessen Speicherbedarf den verfügbaren VRAM übersteigt.

Ein verbreiteter Irrtum muss korrigiert werden: llama.cpp ist nicht auf eine Anfrage gleichzeitig beschränkt. Sein Server bietet laut Beschreibung parallele Generierung für mehrere Nutzer und kontinuierliches Batching, das standardmäßig aktiviert ist; die Anzahl der Slots wird über den Parameter --parallel festgelegt. Damit eignet er sich durchaus für ein kleines Team; mit den Funktionen von vLLM für den Produktionsbetrieb in großem Maßstab will er jedoch nicht gleichziehen.

Stärken

Portabilität (Mac, Linux, Windows, Android), weit verbreitete GGUF-Formate, hybrider CPU- und GPU-Modus, geringe Abhängigkeit.

Grenzen

Keine Funktionen für verteilte Bereitstellung, die mit denen von vLLM vergleichbar wären; Kenntnisse der Einstellungen (Kontext, Slots, Schichten auf der GPU) erforderlich.

Ökosystem

Grundlage von Ollama und LM Studio, auch von Jan genannt.

Zum Kompilieren mit CUDA, Metal oder Vulkan lesen Sie die Kompilierungsanleitungen; der vollständige Leitfaden zu llama.cpp erläutert die Nutzung im Detail.

#vLLM: der Server für viele Benutzer

vLLM ist eine Bibliothek für Inferenz und die Bereitstellung von Modellen als Dienst, die am Sky Computing Lab der University of California in Berkeley entstand. Sie basiert auf PagedAttention, das den Speicher für die Schlüssel und Werte des Attention-Mechanismus seitenweise verwaltet, und auf kontinuierlichem Batching, ergänzt durch stückweises Prefill und Prefix-Caching. Sie gibt Unterstützung für die Formate FP8, INT4, GPTQ, AWQ und GGUF, eine OpenAI-kompatible API sowie für GPUs von NVIDIA, AMD und Intel und CPUs der Architekturen x86, ARM und PowerPC an.

Zwei verbreitete Irrtümer sind zu korrigieren. Erstens ist vLLM nicht mehr auf NVIDIA beschränkt und unterstützt inzwischen auch CPUs: Sein Repository nennt die Unterstützung verschiedener GPUs und CPUs. Zweitens unterstützt vLLM inzwischen auch GGUF: Die Dokumentation beschreibt diese Unterstützung als sehr experimentell und wenig optimiert; sie ist vor allem zur Verringerung des Speicherbedarfs nutzbar. Für den täglichen Einsatz von GGUF bleibt llama.cpp der übliche Weg.

Stärken

Durchsatz unter Last, seitenweise Verwaltung des Cache-Speichers, OpenAI-kompatible API, Parallelisierung (Tensor, Pipeline, Experten), zahlreiche Formate.

Grenzen

Aufwendiger zu installieren und zu konfigurieren als llama.cpp; für GPU-Server konzipiert; GGUF gehört nicht zu seinen Stärken.

Ökosystem

Die Standardwahl, wenn mehrere Personen oder Anwendungen gleichzeitig dasselbe Modell abfragen.

Der Leitfaden zu vLLM erklärt, was die Inferenz-Engine ist; der Leitfaden zu ihrem Einsatz in der Produktion beschreibt die Einstellungen und die Überwachung im Detail.

#ExLlama: V2 archiviert, V3 im Entwicklungsstadium

Im Repository von ExLlamaV2 steht ein Hinweis, dass das Projekt vorerst archiviert ist und die Entwicklung in ExLlamaV3 fortgesetzt wird. Viele Vergleiche, darunter die frühere Version dieser Seite, stellen V2 weiterhin als die fortschrittlichste Option dar. Das Repository von ExLlamaV3 kündigt das Quantisierungsformat EXL3, tensor- und expertenparallele Inferenz, CPU-Offloading für Expertenmodelle, kontinuierliches Batching, spekulatives Decoding und eine OpenAI-kompatible API über TabbyAPI, den empfohlenen Server, an.

ExLlamaV3 richtet sich an Consumer-GPUs, nicht an Produktionsserver oder Macs. Wenn Sie eine NVIDIA-Grafikkarte besitzen und den besten Kompromiss zwischen Qualität und Größe suchen, ist die EXL3-Quantisierung einen Versuch wert; prüfen Sie zuerst, ob Ihr Modell in der Architekturliste des Repositorys aufgeführt ist.

#SGLang, MLX LM und die anderen

SGLang

Serving-Framework, das als auf geringe Latenz und hohen Durchsatz ausgelegt beschrieben wird, von einer einzelnen GPU bis hin zu großen Clustern. Es wirbt mit RadixAttention für das Präfix-Caching, kontinuierlichem Batching, PagedAttention und spekulativem Decoding. Auf Servern konkurriert es mit vLLM; der eigens dafür vorgesehene Leitfaden erläutert es im Detail.

MLX LM

Python-Paket zur Textgenerierung und zum Fine-Tuning von Modellen auf Apple Silicon mit MLX. Es funktioniert nur auf dem Mac. Der Leitfaden MLX vs. llama.cpp vergleicht die beiden auf dem Mac.

TensorRT-LLM

Engine von NVIDIA, auf NVIDIA-Karten sehr leistungsfähig, aber aufwendiger einzurichten; nur für eine Flotte von NVIDIA-GPUs im Produktionsbetrieb in Betracht ziehen.

#Was die veröffentlichten Messungen zeigen

Die Durchsatzraten hängen von der Hardware, dem Modell, der Quantisierung, der Länge der Anfragen und der Version der Engine ab und verändern sich jeden Monat. Dieser Leitfaden enthält daher keine eigenen Messungen und empfiehlt Ihnen, Tabellen mit Tokens pro Sekunde ohne dokumentiertes Messverfahren skeptisch zu betrachten. Ein Drittanbieter hat jedoch ein vollständiges Messverfahren veröffentlicht: Red Hat im August 2025.

Mit Vorbehalt zu lesen: Der Artikel ist den Produkten von Red Hat AI zugeordnet und stammt somit von einem kommerziellen Anbieter in diesem Bereich; die Tests betreffen Ollama und nicht direkt llama.cpp und wurden mit Standardeinstellungen durchgeführt; seitdem sind mehrere Versionen erschienen. Die belastbare Aussage ist qualitativer Natur: Bei vielen gleichzeitigen Anfragen übertrifft eine Serving-Engine mit aggressivem Batching eine Anwendung, die für einen einzelnen Nutzer konzipiert ist. Bei alleiniger Nutzung ist der Durchsatzunterschied nicht der Faktor, der Sie ausbremst.

#Speicher: Was jede Engine reserviert

Der Speicherbedarf eines Modells setzt sich aus den Gewichten, dem Kontext-Cache (KV) und einer Reserve zusammen. Die Größe der Gewichte lässt sich berechnen: Ein Modell mit 8 Milliarden Parametern benötigt etwa 16 GB in FP16 (8 Milliarden mal 2 Byte) und etwa 5 GB in Q4 – ein Richtwert dieser Website. Der Kontext-Cache wächst mit der Gesprächslänge und der Anzahl gleichzeitiger Anfragen.

Merken Sie sich: vLLM reserviert den Speicher von Anfang an. Das macht es für den Inferenzbetrieb effizient, aber wenig geeignet für eine Grafikkarte, die auch von anderen Anwendungen genutzt wird. Reduzieren Sie den Parameter gpu_memory_utilization, wenn die Karte auch anderen Zwecken dient.

#Welche Inferenz-Engine für welchen Einsatz

Die Engines können nebeneinander betrieben werden: Ollama für den alltäglichen Chat, vLLM bei Bedarf zum Verarbeiten eines Stapels von Extraktionsaufgaben. Es gibt keinen Grund, nur eine zu behalten, wenn sich die Einsatzbereiche unterscheiden. Planen Sie lediglich genügend Festplattenspeicher für dasselbe Modell in zwei Formaten ein, etwa eine GGUF-Datei für den Chat und Hugging-Face-Gewichte für den Server.

• Ollama gegenüber llama.cpp
• vLLM: Der vollständige Leitfaden
• SGLang als lokaler LLM-Server
• MLX vs. llama.cpp auf dem Mac
• llama.cpp: der umfassende Leitfaden
• Ollama, LM Studio, Jan oder GPT4All

• Quelle: Repository von llama.cpp
• Quelle: vLLM-Repository
• Quelle: Repository von ExLlamaV2
• Quelle: Red Hat, Ollama gegen vLLM