Ollama vs llama.cpp: Welches sollten Sie 2026 wählen? ?

#Der echte Zusammenhang zwischen Ollama und llama.cpp

llama.cpp ist das C/C++-Projekt von Georgi Gerganov, das Sprachmodelle im GGUF-Format auf CPU und GPU ausführt, ohne von Python oder PyTorch abhängig zu sein. Es ist der maßgebliche Inferenzbaustein des gesamten lokalen Ökosystems: LM Studio, KoboldCpp, Jan und Ollama bauen darauf auf, direkt oder über einen Fork.

Ollama ist daher im engeren Sinne kein Konkurrent von llama.cpp, sondern eine darauf aufbauende Softwareschicht. Es bringt eine eigene, von llama.cpp abgeleitete Engine mit und ergänzt sie um einen Modellmanager, einen Daemon im Hintergrund und eine API. Wenn Sie `ollama run qwen3` eingeben, erzeugt Code aus llama.cpp die Tokens. Die Frage lautet nicht „Was ist schneller?“ – bei gleicher Quantisierung und gleicher Hardware liegen die Leistungen sehr nahe beieinander –, sondern „Welcher Abstraktionsgrad passt zu Ihnen?“

#Was Ollama tatsächlich über llama.cpp hinaus bringt

llama.cpp von Hand zu kompilieren und zu starten bedeutet, sich selbst um den Download der GGUF-Dateien, die Dateipfade und eine lange Befehlszeile mit Flags zu kümmern. Ollama übernimmt all das. Konkret bietet es zusätzlich zur reinen Engine Folgendes:

Registry und Pull

`ollama pull qwen3:8b` lädt das Modell von ollama.com herunter, wählt eine Standardquantisierung (häufig Q4_K_M) und legt es in einem Blob-Speicher ab. Die Suche nach der richtigen Datei auf Hugging Face entfällt.

Persistenter Daemon

Ein Dienst läuft im Hintergrund und lauscht auf http://localhost:11434. Das Modell bleibt zwischen zwei Anfragen im Speicher geladen (keep-alive) und wird nach Inaktivität automatisch entladen.

Automatischer GPU-Offload

Ollama schätzt den verfügbaren VRAM und verteilt die Schichten zwischen GPU und CPU, ohne dass Sie `-ngl` einstellen müssen. Praktisch, aber manchmal zu vorsichtig.

Modelfile

Eine deklarative Datei (ähnlich einem Dockerfile), die ein Basismodell, einen System-Prompt, eine Temperatur und eine Chat-Vorlage unter einem wiederverwendbaren Namen festlegt.

OpenAI-kompatible API

Ein sofort einsatzbereiter Endpunkt /v1/chat/completions zusätzlich zur nativen API /api/generate. Jeder OpenAI-Client lässt sich durch Ändern der Basis-URL damit verbinden.

Demgegenüber können Sie mit llama.cpp alles machen — aber Sie müssen auch alles selbst machen. Sie laden die GGUF-Datei selbst herunter, schreiben die Befehlszeile und verwalten den Lebenszyklus des Prozesses. Das ist der Preis für die vollständige Kontrolle, auf den dieser Vergleich zwischen llama.cpp und Ollama im weiteren Verlauf genauer eingeht.

#Voraussetzungen

Der einzige Faktor, der wirklich darüber entscheidet, was Sie ausführen können, ist der Speicher (RAM oder VRAM auf einer dedizierten GPU). Diese Richtwerte für Q4_K_M gelten für beide Tools, da sie dieselbe Engine verwenden:

3B ≈ 2 GB

Passt auf nahezu jede Hardware, auch auf eine RTX 3060 mit 12 GB und enorm viel Speicherreserve.

7B ≈ 5 GB

Läuft ab 8 GB VRAM problemlos (RTX 3060, 4060).

14B ≈ 9 GB

Passt vollständig auf eine RTX 3060 mit 12 GB oder eine 4070 mit 12 GB.

32B ≈ 19 GB

Erfordert eine RTX 4090 mit 24 GB oder bei 16 GB eine teilweise Auslagerung zwischen CPU und GPU.

70B ≈ 40 GB

Erfordert mehrere GPUs, einen Mac mit gemeinsamem Speicher (M4 Pro 48 GB) oder aggressives Offloading.

#Beide installieren und starten

1. 01
   Ollama installieren

   Das offizielle Skript installiert unter Linux den Daemon und die CLI mit einem einzigen Befehl; für macOS und Windows steht auf ollama.com ein grafisches Installationsprogramm bereit. Nach der Einrichtung lauscht der Dienst auf http://localhost:11434.
2. 02
   Ein Modell mit Ollama starten

   `ollama run qwen3:8b` lädt das Modell beim ersten Aufruf herunter und öffnet eine Chat-Sitzung. Keine weiteren Einstellungen nötig: GPU-Offload, Kontext und Template werden automatisch verwaltet.
3. 03
   llama.cpp kompilieren

   Man klont das Repository ggml-org/llama.cpp und kompiliert mit CMake. Die GPU-Backend-Option hängt von Ihrer Hardware ab: CUDA für NVIDIA, Metal (standardmäßig aktiviert) auf dem Mac, ROCm oder Vulkan für AMD.
4. 04
   GGUF mit llama.cpp starten

   `llama-cli` lädt eine ausdrücklich angegebene .gguf-Datei; sämtliche Einstellungen werden über die Kommandozeile festgelegt: Anzahl der GPU-Schichten (`-ngl`), Kontextgröße (`-c`), CPU-Threads (`-t`). Nichts wird für Sie erraten.

# Installer (Linux) puis lancer un modèle
curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:8b

# Vérifier le daemon et lister les modèles
curl http://localhost:11434/api/tags
ollama list

# Cloner et compiler avec le backend CUDA (NVIDIA)
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

# Lancer un GGUF avec 35 couches sur le GPU et 8192 de contexte
./build/bin/llama-cli -m ./qwen3-8b-Q4_K_M.gguf -ngl 35 -c 8192 -p "Bonjour"

#Einfacher Benchmark beider Tools mit derselben GGUF-Datei

Der beste Weg, Debatten zu beenden: beide mit derselben Datei auf demselben Rechner messen. llama.cpp stellt `llama-bench` bereit, ein eigens dafür entwickeltes Tool, das den Generierungsdurchsatz (Tokens pro Sekunde) und die Promptverarbeitung (prompt processing) getrennt erfasst.

# Débit brut du moteur sur le GGUF, tout GPU
./build/bin/llama-bench -m ./qwen3-8b-Q4_K_M.gguf -ngl 99
# Sortie : colonnes pp (prompt) et tg (génération) en tok/s

# Importer le GGUF dans Ollama sans le re-télécharger
printf 'FROM ./qwen3-8b-Q4_K_M.gguf\n' > Modelfile
ollama create qwen3-local -f Modelfile

# Chronométrer une génération (--verbose affiche les tok/s)
ollama run qwen3-local --verbose "Explique la photosynthèse en 200 mots"

Das typische Ergebnis im Jahr 2026 bei identischer GGUF-Datei und vollständig auf der GPU ausgeführten Schichten: Die Generierungsrate ist bis auf wenige Prozent nahezu identisch. Das ist logisch, denn es kommt derselbe Rechenkern zum Einsatz. Die beobachteten Unterschiede entstehen fast immer durch unterschiedliche implizite Einstellungen, nicht durch die Engine:

Auf die GPU ausgelagerte Schichten

Ollama kann vorsichtshalber einige Schichten auf der CPU belassen, um den VRAM zu schonen, während `llama-bench -ngl 99` alles auf die GPU verlagert. Ergebnis: Ollama wirkt langsamer, obwohl dies auf eine Entscheidung über die Verteilung zurückgeht.

Kontextgröße

Ein größerer Kontext reserviert mehr VRAM für den KV-Cache und verringert den Platz für die Gewichte. Vergleichen Sie bei gleicher Kontextgröße.

Flash-Attention und KV-Cache

Aktiviert oder nicht, quantisiert oder nicht, diese Einstellungen beeinflussen den Durchsatz. In llama.cpp setzen Sie sie manuell; in Ollama hängen sie von der Version und Umgebungsvariablen ab.

#Detaillierte Einstellungen nur in llama.cpp verfügbar

Hier fällt der Vergleich zwischen llama.cpp und Ollama klar zugunsten einer Seite aus. Da llama.cpp die Flags der Engine direkt zugänglich macht, bietet es Einstellmöglichkeiten, die Ollama verbirgt oder nur teilweise bereitstellt. Für fortgeschrittene Nutzung machen diese Einstellungen den entscheidenden Unterschied:

Präzises Offloading (-ngl)

Sie legen auf die einzelne Schicht genau fest, wie viele Schichten auf die GPU ausgelagert werden. Wenn der VRAM gerade ausreicht, können 2 oder 3 zusätzliche Schichten gegenüber Ollama ein Modell von „langsam“ zu „flüssig“ machen.

Quantisierter KV-Cache (-ctk/-ctv)

Die Quantisierung des KV-Caches auf q8_0 halbiert nahezu den Speicherbedarf des Kontexts und ermöglicht bei gleichbleibendem VRAM deutlich längere Kontextfenster – eine Möglichkeit, die in Ollama nur eingeschränkt zugänglich ist.

Flash Attention (--flash-attn)

Explizite Aktivierung des optimierten Attention-Mechanismus mit direktem Einfluss auf die Geschwindigkeit und den Speicherbedarf bei langen Kontexten.

Spekulative Decodierung (--model-draft)

Ein kleines „Entwurfsmodell“ einbinden, um ein großes Modell zu beschleunigen. Der Geschwindigkeitsgewinn kann bei Code erheblich sein, und llama.cpp unterstützt dies nativ.

GBNF-Grammatiken (--grammar)

Die Ausgabe auf eine formale Grammatik beschränken (striktes JSON, Aufzählung, eigenes Format). Unverzichtbar für zuverlässige strukturierte Ausgaben und mit deutlich feineren Steuerungsmöglichkeiten als der JSON-Modus von Ollama.

RoPE und Kontextskalierung

`--rope-freq-base` und `--rope-freq-scale` anpassen, um den Kontext über die beim ursprünglichen Training verwendete Länge hinaus zu erweitern und dabei die Qualitätseinbußen unter Kontrolle zu halten.

Ollama macht einen Teil dieser Einstellungen über Modelfile-Parameter oder Umgebungsvariablen zugänglich, allerdings selten mit derselben Granularität und oft mit Verzögerung gegenüber den Neuerungen von llama.cpp. Wenn Sie „den längstmöglichen Kontext für meinen VRAM“ oder „garantiert gültiges JSON“ benötigen, bietet Ihnen die Engine ohne zusätzliche Softwareschicht Stellschrauben, die diese Schicht festgeschweißt hat.

#API-Server: Ollama vs. llama-server

Beide können ein Modell über HTTP bereitstellen. Ollama stellt seinen Daemon unter http://localhost:11434 mit einer nativen API (/api/generate, /api/chat) und einem OpenAI-kompatiblen Endpunkt (/v1/chat/completions) bereit. llama.cpp bietet seinerseits `llama-server`, ein Binärprogramm, das eine OpenAI-kompatible API und eine kleine integrierte Weboberfläche startet.

# API OpenAI-compatible sur le port 8080, tout GPU
./build/bin/llama-server -m ./qwen3-8b-Q4_K_M.gguf -ngl 99 -c 8192 --port 8080
# Interface web : http://localhost:8080  ·  API : /v1/chat/completions

Mehrere Modelle bei Bedarf

Ollama lädt und entlädt automatisch mehrere Modelle je nach Anfrage. `llama-server` stellt ein Modell pro Prozess bereit — leichter nachzuvollziehen, weniger magisch.

Kontrolle über die Flags

Bei llama-server wird jede Einstellung der Engine (Kontext, KV-Cache, Flash Attention) über ein explizites Startflag festgelegt. Ideal, um eine reproduzierbare Produktionskonfiguration festzuschreiben.

Ökosystem

Ollamas API auf Port 11434 ist zu einem De-facto-Standard geworden: Open WebUI, Code-Editoren und Integrationen greifen direkt darauf zu. Das ist ein echter Vorteil in Sachen Komfort.

#Urteil nach Profil: Anfänger, Entwickler, Homelab

Da beide dieselbe Engine verwenden, richtet sich das Urteil nicht nach der Leistung, sondern nach Ihrem Profil und Ihrer Bereitschaft, mit der Kommandozeile zu arbeiten.

Anfänger → Ollama

Ein Befehl zum Installieren, einer zum Starten, ein Modell, das ohne irgendwelche Einstellungen „funktioniert“. Es gibt keinen Grund, C++ zu kompilieren, um mit einem LLM zu chatten. Bleiben Sie bei Ollama, gegebenenfalls mit Open WebUI als Oberfläche.

Entwickler → beide

Ollama für schnelles Prototyping und eine sofort verfügbare OpenAI-API; llama.cpp, wenn Sie GBNF-Grammatiken, spekulatives Decoding oder eine genaue Kontrolle über den KV-Cache benötigen. Der Wechsel zwischen beiden ist problemlos, da beide dasselbe GGUF verwenden.

Homelab / Self-Hosting → llama.cpp (llama-server)

Um das Letzte aus knapp bemessenem VRAM herauszuholen, eine reproduzierbare Konfiguration festzulegen und den Kontext zu erweitern, ist die reine Inferenz-Engine im Vorteil. Der damit verbundene Aufwand – kompilieren, Flags angeben, Prozesse verwalten – ist genau das, was Sie beherrschen lernen möchten.

In einem Satz: Ollama ist der beste Ausgangspunkt und reicht für die überwältigende Mehrheit der Anwendungsfälle aus; zu llama.cpp ohne zusätzliche Oberfläche wechselt man, sobald eine bestimmte Einstellung — Kontext, KV-Cache, Grammatik, Offloading mit schichtgenauer Steuerung — zum begrenzenden Faktor wird. Das ist kein Ersatz, sondern ein Schritt zu mehr Kontrolle.

#Weiterführende Informationen

Diese Anleitungen ergänzen diesen Vergleich, von der Installation bis zur Feinabstimmung:

Mit Ollama starten

„Ollama in 5 Minuten installieren (Windows, macOS, Linux)“ behandelt die Installation des Daemons und das erste Modell und legt dabei den Schwerpunkt auf Einfachheit.

Modelle ohne Ollama bereitstellen

„llama-server: eine lokale OpenAI-API mit llama.cpp“ erläutert im Hinblick auf die Steuerung das fein abgestimmte Offloading der Layer und die enthaltene Weboberfläche.

Quantisierung wählen

„GGUF-Quantisierung 2026: Q4_K_M vs Q5_K_M vs Q6_K“ hilft dabei, die richtige .gguf-Datei auszuwählen, die für beide Tools verwendet werden kann.