llama.cpp / Ollama vs vLLM: Was, wann und warum

Lokale LLM-Inferenz hat sich auf drei Stacks eingespielt, die ständig verwechselt werden: llama.cpp, Ollama und vLLM. Sie sind keine Konkurrenten auf derselben Ebene – zwei von ihnen umhüllen bzw. ergänzen einander direkt. Dieser Guide legt fest, was jedes Einzelne ist, wo sich Concurrency- und Speichermodelle unterscheiden und was man pro Szenario wählt.

Was jede Schicht wirklich ist

llama.cpp ist die C/C++-Inferenz-Engine: eine GGUF-native Runtime mit Backends für CUDA, Metal, Vulkan, ROCm und reine CPU, plus llama-server, ein eingebauter HTTP-Server mit OpenAI- und Anthropic-kompatiblen Routen, Continuous Batching und parallelem Decoding.¹

Ollama ist eine Modell-Distributions- und Runtime-Schicht, keine eigene Engine (jedenfalls überwiegend). Historisch hat es einen gepinnten llama.cpp-Build umhüllt – die Variable LLAMA_CPP_VERSION im Ollama-Repo fixiert die exakte Upstream-Quelle, gepatcht über llama/compat/.² Über diesen Pin hinaus hat Ollama eigene Engines ergänzt: eine Multimodal-Engine, die Vision-Modelle (Llama 4, Gemma 3, Qwen 2.5 VL) direkt auf der GGML-Tensor-Bibliothek ausführt, statt separaten Text-Decoder- und Vision-Encoder-Prozess zusammenzukleben,³ sowie eine MLX-basierte Engine für Apple Silicon, die Ollama im März 2026 in den Preview gestellt hat und für beschleunigte Modelle den llama.cpp-Metal-Pfad ersetzt.⁴

vLLM ist eine Python/CUDA-Serving-Engine rund um PagedAttention: KV-Cache-Speicher, OS-artig in Blöcken fester Größe verwaltet mit logisch-zu-physisch Block-Tabellen – dadurch nahezu Null Cache-Verschwendung und 2–4× Throughput gegenüber den Systemen aus dem ursprünglichen Paper.⁵ Seit der V1-Re-Architektur ist Prefix Caching standardmäßig aktiviert (unter 1% Durchsatzverlust bei 0% Hit-Rate), und V1 erreicht bis zu 1,7× höheren Durchsatz als V0.⁶

Concurrency-Modelle: Slots und KV-Allokation

Das ist der größte Verhaltensunterschied überhaupt – und die Quelle der übelsten Falle.

llama-server: --parallel N-Slots mit optional gemeinsamem KV-Pool

llama-server -np N erzeugt N Slots. Aktuelle Master-Defaults: -np/--parallel default -1 (auto), und -cb/--cont-batching (Continuous Batching) ist standardmäßig aktiviert; -b/--batch-size hat default 2048, -ub/--ubatch-size 512. --ctx-size (Default 0 = aus dem Modell geladen) bestimmt die gesamte KV-Kapazität. Mit --no-kv-unified wird sie auf Slots aufgeteilt; mit --kv-unified teilen die Slots einen Pool. Bei automatischer Slot-Zahl ist Unified-KV derzeit standardmäßig aktiv.¹

Die Falle betrifft den nicht vereinheitlichten Modus: Mit -c 8192 -np 4 --no-kv-unified erhält jeder Slot 8192/4 = 2048 Token KV-Kapazität. Für vier gleichzeitige 8k-Slots in diesem Modus braucht es -c 32768 -np 4 --no-kv-unified. Mit --kv-unified teilen sich die Slots dagegen den 8192-Token-Pool; vier volle 8k-Sequenzen benötigen trotzdem etwa 32k Token Gesamtkapazität. --kv-unified-per-slot kann ein unabhängiges Slot-Limit setzen.⁷

vLLM: ein gepagter KV-Pool, Continuous Batching

vLLM hält einen paged KV-Pool und alloziert Blöcke nach Bedarf; auch llama-server kann einen gemeinsamen Pool nutzen, verwendet aber einen anderen Allokator und Scheduler. Requests verlassen und ergänzen den Batch bei jedem Decode-Schritt. Höhere Concurrency kostet im Leerlauf nichts, weil kein per-Request-Kontext vorreserviert wird: Der KV-Cache eines Requests wächst Token für Token in physischen Blöcken und wird bei Request-Ende sofort freigegeben.⁵ --max-num-seqs begrenzt die Batchgröße; die eigentliche Grenze für parallele Requests ist, wie viele Sequenzen mit ihrem angewachsenen KV in den Pool passen.

Ollama: Slots wie llama.cpp, dimensioniert über Defaults

Ollama erbt das Slot-Modell: OLLAMA_NUM_PARALLEL (default 1) ist die Zahl paralleler Requests pro Modell, und der RAM-Bedarf skaliert mit OLLAMA_NUM_PARALLEL * OLLAMA_CONTEXT_LENGTH.⁸ Beim Default von 1 reihen sich gleichzeitige Requests ein; jede zusätzliche parallele Anfrage kann den KV-Speicherbedarf erhöhen.

GGUF: natives Zuhause vs. experimenteller Gast

GGUF ist llama.cpps natives Format – die Referenzimplementierung mit der kompletten Quant-Familie (Q2_K bis Q8_0, i-Quants, Imatrix-Kalibrierung).⁹

vLLMs GGUF-Support ist ein anderes Kapitel, in den Worten der eigenen Doku: "GGUF support in vLLM is highly experimental and under-optimized at the moment, it might be incompatible with other features." Das GGUF-Loading ist aus dem Kern in das OOT-Paket vllm-gguf-plugin gewandert (uv pip install vllm-gguf-plugin), und die Doku empfiehlt, den Tokenizer des Basismodells explizit mitzugeben, z. B.¹⁰:

vllm serve unsloth/Qwen3-0.6B-GGUF:Q4_K_M --tokenizer Qwen/Qwen3-0.6B

Praktische Regel: GGUF ist in vLLM weniger optimiert; die Leistung muss für den konkreten Workload gemessen werden. Für hohen Serving-Durchsatz auch Safetensors mit unterstützter Quantisierung (AWQ, GPTQ, FP8) vergleichen.

Defaults, die beißen

Ollamas Kontext-Default ist VRAM-gestaffelt. Aktuelle Doku: < 24 GiB VRAM → 4k Kontext; 24–48 GiB → 32k; ≥ 48 GiB → 256k, überschreibbar mit OLLAMA_CONTEXT_LENGTH (ältere Releases hatten einen flachen 4096er-Default, und 4096 taucht noch in den Override-Beispielen der FAQ auf).¹¹ Wenn die 24-GB-Karte einen 32k-Default wählt, den man nicht bestellt hat, wächst der KV-Cache entsprechend – ollama ps prüfen (Spalte CONTEXT) und num_ctx pro Request oder die Env-Variable global setzen.

Ollamas KV-Cache-Typ ist default f16. OLLAMA_KV_CACHE_TYPE akzeptiert f16 (default), q8_0 (etwa halber KV-Payload-Speicher) oder q4_0 (etwa ein Viertel des Payloads; bei beiden Qualität am eigenen Workload prüfen) – und wirkt nur, wenn Flash Attention aktiviert ist.⁸

OLLAMA_NUM_PARALLEL ist default 1 – gleichzeitige Requests laufen nicht parallel, sondern werden gereiht; Erhöhen multipliziert den KV-Speicher mit N.⁸

vLLMs gpu_memory_utilization ist default 0,92 – vLLM beansprucht beim Start bis zu 92% des Gesamt-Speichers der Karte (pro Instanz, nicht prozess-koordiniert) und zieht danach Gewichte, Aktivierungs-Peak und CUDA-Graph-Pools ab; der KV-Cache ist der Rest. Auf einer Karte mit Display oder weiteren Prozessen kann dadurch zu wenig Speicher frei bleiben. Anteil oder --max-model-len nach gemessenem Bedarf anpassen.¹²

Durchgerechnet: 14B Q4_K_M, 4 Slots × 8k, auf einer 24-GB-Karte

Nehmen wir Qwen2.5-14B (48 Layer, GQA mit 8 KV-Heads, Hidden Size 5120 über 40 Heads → Head-Dim 128, 14,7 Mrd. Parameter gesamt).¹³ Wir rechnen das Budget mit der KV-Formel dieser Seite (siehe KV-Cache-Guide und Inferenz-Mathematik) und setzen llama.cpps gemessene Q4_K_M-≈4,85 Bits pro Gewicht für diese Gewichtsklasse ein.⁹

Gewichte bei 4,85 bpw:

KV-Cache pro Token (f16, 2 Byte/Wert), mit $2 \times L \times H_{KV} \times d_{head} \times b_{dtype} \times s$:

Pro Slot bei 8.192 Tokens, und gesamt für 4 Slots:

Es passt – mit deutlichem Puffer, und genau das ist die Aussage: Auf einer 24-GB-Karte liegen ein 14B-Modell in Q4_K_M und 4 parallele 8k-Konversationen komfortabel im Budget; die ~8,65 GB Puffer — 24 dezimale GB auf dem Aufkleber minus der 14,30-GiB-Zwischensumme (15,35 dezimale GB) — decken Compute-Scratch (abhängig von Batch-Größe und Backend) plus CUDA-Kontext. Zwei Hebel, wenn mehr Slots oder Kontext nötig sind: -ctk q8_0 -ctv q8_0 halbiert den KV-Cache auf 3,0 GiB (llama-server-Flags, f16 default¹) – derselbe Trade, den Ollamas OLLAMA_KV_CACHE_TYPE=q8_0 macht. Für den vollständigen Sizing-Workflow siehe VRAM-Rechner erklärt und Quantisierung erklärt; das interaktive Tool ist der LLM-Inferenz-Rechner.

Für vier feste 8k-Slots im nicht vereinheitlichten Modus startet man llama-server -m model-Q4_K_M.gguf -c 32768 -np 4 --no-kv-unified. Ein gemeinsamer Pool kann sie ebenfalls aufnehmen, wenn seine Gesamtkapazität reicht.

Entscheidungstabelle

Faustregel: llama.cpp, wenn man an die Regler muss oder exotische Hardware bedienen will; Ollama für reibungslose lokale Nutzung; vLLM, wenn andere Menschen oder Services auf den Endpunkt zugreifen und Durchsatz pro GPU zählt.