llama.cpp vs. vLLM: Laptop oder GPU-Cluster?

TL;DR

Beide Tools betreiben LLMs selbst — ohne Cloud-API. llama.cpp holt Modelle auf kleine Hardware (GGUF, Quantisierung, CPU+GPU, offline). vLLM holt Durchsatz auf den GPU-Server (Paged Attention, Continuous Batching, viele parallele Nutzer). Der typische Weg im Mittelstand: llama.cpp oder Ollama zum Testen, vLLM sobald ein Team dieselbe Karte teilt.

Ollama ist ein Produkt auf llama.cpp, nicht der dritte Pol in diesem Vergleich. Den Desktop-Vergleich finden Sie unter llama.cpp vs. Ollama.

Warum lokale LLMs — und warum zwei Engines?

Drei Gründe, die in der Praxis zählen: Token-Rechnungen, Ausfälle und Daten, die das Haus nicht verlassen sollen. OpenAI-kompatible Endpoints machen den Wechsel technisch klein (Base-URL). Der Betrieb ist der eigentliche Aufwand: VRAM, Quant, Batching, Monitoring.

llama.cpp: Modelle verkleinern, statt GPUs zu kaufen

Die 70B-Klasse brauchte lange Datacenter-Karten. llama.cpp dreht die Schraube andersherum: Gewichte von FP16 auf INT8/INT4, ein GGUF (Weights, Tokenizer, Config in einer Datei), CPU-Fallback wenn keine CUDA-Karte da ist.

Wirkung: ein Modell, das unquantisiert nicht in 24 GB passt, läuft mit Q4 oft auf einer Workstation. Genau deshalb bauen Ollama und LM Studio darauf. Für Factory-PCs ohne GPU und für Air-Gap ist das der Default.

Preis der Quantisierung: etwas weniger Genauigkeit. Für Agents mit Tools und Suche meist tragbar, für reine Wissensfragen ohne Retrieval eher sichtbar. VRAM-Stufen: Lokale KI 2026: GPU-Wahl 16 GB vs. 24 GB.

vLLM: dieselbe Karte, mehr gleichzeitige Nutzer

vLLM ist für den Fall gebaut, dass viele Requests dieselbe GPU teilen. Traditionelle Server reservieren KV-Cache worst-case pro Request — kurze Prompts bekommen den Speicher langer Prompts. Fragmentierung und Überallokation fressen 60–80 % des VRAM.

Paged Attention teilt den KV-Cache in Pages, analog zum virtuellen Speicher. Auslastung steigt in Laborangaben von rund 20 % auf etwa 95 % — mehr parallele Nutzer auf derselben Karte. Continuous Batching hält die GPU beschäftigt, statt auf das Ende eines Stapels zu warten.

Zusätze in der vLLM-Welt: Speculative Decoding (kleines Modell schlägt vor, großes prüft) und Prefill/Decode-Trennung in Stacks wie LLM-D. Für den Mittelstand zählt zuerst: OpenAI-kompatible /v1-API und messbare Tokens/Sekunde unter Last.

Drei Inferenzserver im Detail: vLLM vs. SGLang vs. TensorRT-LLM. Cluster: vLLM Multi-GPU.

Der Stufenweg, der in der Praxis klappt

1. Einzelplatz: llama.cpp oder Ollama auf der Workstation, Daten lokal.
2. Team: eine GPU-Box, vLLM (oder Ollama nur noch als Katalog), Open WebUI, Gateway.
3. Plattform: vLLM auf Kubernetes, Autoscaling, RBAC, Audit.

Den API-Cut machen beide. Den Betrieb nicht: Auslastung, Sicherheit, Updates. Gateway davor, Runtime austauschbar: LiteLLM-Cluster Setup.

Häufige Fragen

llama.cpp oder vLLM — eine Regel?

llama.cpp wenn die Maschine klein, offline oder CPU-lastig ist. vLLM wenn mehrere Nutzer eine NVIDIA-Karte teilen und Tokens/Sekunde das Budget entscheiden. Nicht umgekehrt: vLLM auf einem Laptop ohne CUDA ist der falsche Kampf; llama.cpp als einziger Prod-Server für 80 parallele Chats auch.

Kann ich die Cloud-App 1:1 umstellen?

Ja, wenn sie gegen eine OpenAI-kompatible API spricht. Base-URL und Modellname ändern. Auth, Rate-Limits und Kontextlänge müssen Sie neu setzen — das ist Betrieb, kein Code-Rewrite.

Was ist Quantisierung in einem Satz?

Gewichte kompakter speichern (typisch Q4/Q5), damit das Modell in den VRAM passt. Standard 2026, kein Trick. Ab zu aggressivem Quant merken Sie es in Wissensaufgaben zuerst.

Brauche ich Kubernetes dafür?

Nein. Stufe 2 ist ein GPU-Server mit systemd oder Docker. Kubernetes kommt, wenn Sie mehrere Modelle, Teams und Failover orchestrieren — siehe GPUs in Kubernetes.

Fazit und nächster Schritt

llama.cpp macht lokale KI auf der Hardware, die Sie schon haben. vLLM macht aus derselben GPU einen Multi-User-Server. Die falsche Engine kostet entweder Tempo oder Geld — die richtige ist eine Stufenfrage, kein Glaubenskrieg.

Wenn Sie den Cut gegen Ihre Last messen wollen — eine Workstation, ein Server, ein Cluster: Sprechen Sie uns an. Wir legen Runtime und Karte an den Use Case, nicht an das Datenblatt.