llama.cpp vs. Ollama: Was solltest du 2026 nutzen?

Rohes llama.cpp, wenn du maximale Tokens/Sekunde und volle Kontrolle willst; Ollama, wenn du eine Ein-Befehl-Installation und eine API willst, die ab der ersten Minute funktioniert. Ollama ist keine konkurrierende Engine — es ist ein Go-Dienst, der llama.cpp als Inferenz-Backend mitbringt, Modellverwaltung obendrauf packt (ollama pull llama3.1) und eine REST-API auf Port 11434 bedient. Die eigentliche Frage ist also nicht „welche Engine ist schneller”, sondern „wie viel Kontrolle willst du über die Stellschrauben dieser Engine”. Weil Ollama konservative Defaults mitliefert (Q4_K_M-Quantisierung, bescheidener Kontext, bis vor Kurzem kein Flash Attention), können identische Maschinen spürbar unterschiedliche Zahlen produzieren. Unten: was wirklich unterschiedlich ist, woher das Tempogefälle kommt, dasselbe Modell in beiden und eine Entscheidungstabelle.

Wo ist der Unterschied zwischen llama.cpp und Ollama?

llama.cpp ist die Inferenz-Engine: ein einzelnes C/C++-Projekt vom GGUF-Schöpfer Georgi Gerganov, das quantisierte Modelle auf CPU, GPU oder einer Mischung aus beidem laufen lässt. Es gibt dir llama-cli für Einzelprompts und llama-server — einen OpenAI-kompatiblen HTTP-Server — plus jedes Tuning-Flag, das die Engine kennt: GPU-Layer-Offload, KV-Cache-Quantisierung, Speculative Decoding, eigene Sampler.

Ollama ist ein Produkt, das auf diese Engine gesetzt wird. Es forkt und vendort llama.cpp und wickelt es ein in:

• eine Modell-Registry (ollama pull, ollama list) mit automatischem GGUF-Gewichtssplitting,
• ein Modelfile-System (eine Dockerfile-artige Spec für Prompt-Templates und Parameter),
• einen Hintergrund-Daemon, der Modelle im VRAM warmhält und eine eigene REST-API anbietet,
• automatische Hardware-Erkennung mit sicheren Defaults.

Die praktische Folge: Mit Ollama verwaltest du Modelle; mit llama.cpp verwaltest du Inferenz. Wenn du schon mal die Quantisierungsform ändern, den KV-Cache quantisieren, den Kontext über den Default heben oder bestimmte Layer auf die GPU pinnen wolltest — das ist llama.cpp-Gebiet. Ollama versteckt die meisten dieser Regler, und zwar mit Absicht.

	llama.cpp	Ollama
Was es ist	Inferenz-Engine (C/C++)	Dienst, der llama.cpp verpackt
Installation	Selbst bauen oder Paket	Einzeilen-Installer, eine Binärdatei
Modell starten	llama-cli -m model.gguf + Flags	ollama run llama3.1
API	OpenAI-kompatibel (llama-server)	Eigene REST + OpenAI-kompatibler Endpoint
Modellverwaltung	GGUF-Dateien selbst besorgen	Registry: pull/list/rm
Defaults	Du wählst alles	Sicher: Q4_K_M, bescheidener Kontext
Engine-Updates	Ab Tag eins (upstream)	Hinken hinter Upstream-Releases her
Tuning-Tiefe	Voll (KV-Quant, Spec Decode, Sampler)	Begrenztes Durchreichen
Am besten für	Performance-Arbeit, Server, Edge-Geräte	Einstieg, Dev-Laptops

Ist llama.cpp schneller als Ollama?

Bei derselben GGUF-Datei, derselben Quantisierung, demselben Kontext und derselben llama.cpp-Version — nein, sie liegen im Rauschen voneinander, denn Ollama ist llama.cpp, das die Mathematik macht. Jeder „Ollama ist 30 % langsamer”-Benchmark vergleicht in Wahrheit Defaults. Das Gefälle kommt aus drei Quellen:

1. Wahl der Quantisierung. Ollamas Registry nutzt standardmäßig Q4_K_M. Dasselbe Modell als Q5_K_M oder Q6_K aus llama.cpp liefert bessere Qualität pro Token bei ähnlichem Tempo — oder nimm Q4_0/IQ4 für rohe Geschwindigkeit.
2. Flash Attention und KV-Cache-Quantisierung. --flash-attn plus -ctk q8_0 -ctv q8_0 schrumpft den KV-Cache drastisch, was die Tokens/Sekunde bei langem Kontext hebt und größere Kontexte in denselben VRAM bringt. Ollama gibt davon nur einen Teil frei.
3. Versionsverzug. llama.cpp landet Kernel-Optimierungen im Wochentakt; Ollama merged upstream nach eigenem Zeitplan. Ein frischer llama.cpp-Build kann auf derselben Kiste messbar schneller sein als ein monatelanges Ollama-Binary — bis Ollama aufholt.

Schneller Benchmark-Befehl, engine-agnostisch — er meldet Prompt-Evaluation und Generierungstempo:

./build/bin/llama-bench -m Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99 -fa 1

Gegen Ollamas eigene Modelldatei ausgeführt (~/.ollama/models/blobs/..., in .gguf umbenannt) triffst du Ollamas Zahlen meist exakt — und überholst sie mit -ctk q8_0 bei 16k Kontext.

Wie läuft dasselbe Modell in beiden?

Beide essen GGUF. Das nötigste End-to-End für beide:

# --- Ollama-Weg: installieren, pullen, serven ---
curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.1:8b        # lädt Q4_K_M, packt ihn in den VRAM, öffnet einen Chat

# seine API, im OpenAI-kompatiblen Stil:
curl -s http://localhost:11434/v1/chat/completions -d '{
  "model": "llama3.1:8b",
  "messages": [{"role": "user", "content": "Say hi in 5 words"}]
}'

# --- llama.cpp-Weg: bauen, GGUF laden, serven ---
git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build -DGGML_CUDA=ON    # oder -DGGML_VULKAN=ON / -DGGML_HIP=ON
cmake --build build --config Release -j

huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF 
  Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf --local-dir models

./build/bin/llama-server -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf 
  -ngl 99 --ctx-size 16384 --flash-attn -ctk q8_0 -ctv q8_0 --port 8080

llama-server spricht das OpenAI-Chat-Completions-Schema, also läuft dasselbe curl gegen http://localhost:8080/v1/chat/completions unverändert. Jedes Werkzeug, das für die OpenAI-API gebaut ist — Skripte, Editoren, RAG-Pipelines — kann auf beide zeigen. Die Flags machen die eigentliche Arbeit: -ngl 99 lagert jeden Layer auf die GPU aus, --flash-attn plus das -ctk/-ctv-Paar hält 16k Kontext in einer 8-GB-Karte, die Ollamas Defaults verweigern würden.

Für die Wahl der GGUF-Datei selbst und was die Quant-Labels bedeuten: GGUF-Modelle lokal ausführen.

Wann ist Ollama die bessere Wahl?

Die meisten sollten mit Ollama anfangen, und das ist kein Trostpreis:

• Du willst heute Abend lauffähig sein. Ein Befehl, Modell gezogen, API steht. llama.cpp heißt: Backend wählen (CUDA/Vulkan/HIP/Metal), bauen, Gewichte von Hand holen.
• Du jonglierst viele Modelle. Registry, automatisches Entladen und Modelfiles schlagen handverwaltete Verzeichnisse voller GGUF-Dateien.
• Deine Maschine ist bescheiden. Ollamas Defaults sind aus gutem Grund konservativ — sie passen und laufen fast immer.
• Du willst eine stabile API-Oberfläche. Ollamas Daemon verwaltet Modell-Lebenszyklen, damit ein langlebiger Dienst es nicht muss.

Nimm rohes llama.cpp, wenn du benchmarkst, in irgendeinem Maßstab auslieferst, auf einem Telefon oder Raspberry Pi läufst, langen Kontext auf kleinem VRAM brauchst oder ein Feature am Tag des Upstream-Merges willst. Power-User fahren oft beides: Ollama für die Alltagsmodelle, ein gepinnter llama.cpp-Build für den einen Workload, der die letzten 20 % braucht.

Wenn dein Vergleich eigentlich zwischen Desktop-GUI-Apps spielt, ist das eine andere Achse — siehe Ollama vs LM Studio — und für die Engine-Wahl pro Aufgabe deckt die besten lokalen LLMs zum Programmieren die Modellseite ab.

Was solltest du nehmen?

Entscheide nach Kontrolle, nicht nach Tempo. Die Engines sind dieselben; die Defaults nicht. Installiere Ollama, wenn „läuft und stellt eine API bereit” das Ziel ist — du verlierst ein paar Stellschrauben, an die du nie gedreht hättest. Baue llama.cpp, wenn Tokens/Sekunde, Kontextlänge oder Quantisierungskontrolle das Ziel sind — du bekommst jeden Regler, zum Preis der eigenen Modellverwaltung. So oder so laufen dieselben GGUF-Dateien, und ein späterer Wechsel kostet einen Nachmittag, kein Rewrite.