llama.cpp vs. Ollama: Welche Runtime für lokale LLMs?

TL;DR

Ollama ist der schnellste Weg zu einem lokalen Modell. llama.cpp ist die Engine darunter — und die bessere Wahl, sobald Sie GGUF, GPU-Offload und eine stabile HTTP-API selbst steuern wollen. Für den Mittelstand heißt das: Ollama zum Ausprobieren, llama.cpp (oder vLLM) sobald mehrere Nutzer und feste Hardware im Spiel sind.

Zwei Tools, eine Ebene — nicht dasselbe Produkt

Beide laden Gewichte und erzeugen Tokens. Der Unterschied liegt in der Abstraktion:

Ollama ist ein Produkt um die Engine. llama.cpp ist die Engine. Wer nur „ein Modell lokal starten“ will, gewinnt mit Ollama. Wer VRAM-Splits, Kontextlänge und Batching an die Karte anpassen muss, braucht die Flags von llama.cpp.

Die Hardware-Seite — welche Karte, wie viel VRAM — steht in Lokale KI 2026: GPU-Wahl 16 GB vs. 24 GB und im Leitfaden KI-Server kaufen 2026.

Wann Ollama die richtige Runtime ist

• Ein Entwickler oder ein kleines Fachteam testet Modelle.
• Sie wollen den Katalog (ollama pull) statt Modell-URLs pflegen.
• Docker-Einstieg auf einer Workstation: Ollama in Docker installieren.

Grenzen, die in PoCs selten stören und in Produktion sofort:

• Wenig Transparenz, welches Quant und welches Offload wirklich läuft.
• Durchsatz hinter vLLM, sobald parallele Requests kommen — in einem dokumentierten Cluster-Test lag Ollama bei rund 21 Tokens/s, vLLM beim Vielfachen.
• Betrieb mehrerer Endpoints, Routing und Kostenkonten braucht sowieso ein Gateway, nicht nur Ollama.

Wann llama.cpp die bessere Runtime ist

• Sie haben eine konkrete GGUF-Datei und wollen sie ohne Store laden.
• CPU+GPU-Split: große Gewichte, 16- oder 24-GB-Karte, Rest im RAM.
• Sie brauchen reproduzierbare Flags (Kontext, Batch, Threads) in systemd oder einem Container, nicht in einer Desktop-App.
• Air-Gap: Modelldatei liegt im Haus, kein Pull gegen eine Registry.

Typischer Start (Schema, keine Copy-Paste-Produktion):

# llama-server spricht eine OpenAI-ähnliche API
./llama-server -m ./models/qwen-27b-q4.gguf -c 8192 -ngl 99 --port 8080

-ngl schiebt Layer auf die GPU. Zu hoch für den VRAM → OOM. Zu niedrig → die Karte idlet und die CPU trägt. Genau diese Schraube fehlt Ollama im Alltag.

Wer bereits auf Mehr-GPU und hohem Durchsatz ist, liegt oft bei vLLM, nicht bei llama.cpp: vLLM Cluster Multi-GPU. llama.cpp bleibt die richtige Antwort für GGUF, Mixed-Offload und Maschinen ohne CUDA-Vollstack.

Entscheidung im Mittelstand

Nur testen, ein Nutzer, eine Workstation?     → Ollama
GGUF, VRAM-Split, fester Server, Air-Gap?     → llama.cpp
Viele parallele Requests, CUDA-Server?        → vLLM
Mehrere Engines hinter einer Firmen-API?      → LiteLLM davor

LiteLLM als Klammer: LiteLLM-Cluster Setup und LiteLLM + Open WebUI.

So bleibt die Runtime austauschbar. Fachanwender sehen Open WebUI, das Team sieht eine URL — nicht „wir haben uns auf Ollama festgenagelt“.

Häufige Fragen

Ist Ollama nicht einfach llama.cpp mit UI?

Nein. Ollama nutzt llama.cpp-Technologie, ist aber ein eigenes Produkt mit Katalog, Daemon und API-Konventionen. Sie steuern nicht dieselben Flags. Ein Umstieg ist ein Endpoint-Wechsel, kein Skin-Tausch.

Welche Runtime ist schneller?

Auf einer Karte mit passendem Quant ist llama.cpp oft näher am Blech. Bei vielen parallelen Nutzern auf NVIDIA-Servern gewinnt in der Praxis vLLM. Ollama gewinnt bei Zeit-bis-erstes-Token im Setup, nicht im Dauerbetrieb.

Brauche ich CUDA für llama.cpp?

Nein. llama.cpp läuft auf CPU, Metal, CUDA, ROCm — je nach Build. Genau deshalb eignet es sich für gemischte Parks (AMD-Gebrauchtkarten, Mac, eine NVIDIA-Workstation).

Kann ich beide parallel betreiben?

Ja. Unterschiedliche Ports, ein Gateway davor. Nicht zwei Daemons auf dieselbe GPU ohne Scheduler — VRAM-Konflikte sind der häufigste Betriebsfehler.

Welches Format soll ich kaufen bzw. speichern?

GGUF für llama.cpp und die meisten lokalen Desktops. Safetensors/AWQ für vLLM. Nicht beide Stacks mit demselben Dateiformat erzwingen.

Fazit und nächster Schritt

Ollama holt Sie in fünf Minuten lokal. llama.cpp holt die Kontrolle über VRAM und GGUF, die ein KI-Server braucht. vLLM kommt dazu, wenn Durchsatz das Problem ist — nicht wenn das erste Modell startet.

Wenn Sie Runtime, GPU und Gateway zu einem betreibbaren Private-AI-Stack zusammenziehen wollen: Sprechen Sie uns an. Wir messen gegen Ihre Last, nicht gegen ein Demo-Chatfenster.