llama.cpp vs Ollama: welke draai je in 2026?

Rauwe llama.cpp als je maximale tokens per seconde en volledige controle wilt; Ollama als je een installatie in één commando en een API-server wilt die uit de doos werkt. Ollama is geen concurrerende engine — het is een Go-dienst die llama.cpp als inferentiebackend meebrengt, modelbeheer toevoegt (ollama pull llama3.1) en een REST API serveert op port 11434. De echte vraag is dus niet welke engine sneller is, maar hoeveel controle je over de knoppen van die engine wilt. Omdat Ollama conservatieve defaults meelevert (Q4_K_M-quantisatie, bescheiden context, tot voor kort geen flash attention) kan identieke hardware merkbaar andere getallen opleveren. Hieronder: wat er werkelijk verschilt, waar het snelheidsverschil vandaan komt, hetzelfde model in beide, en een beslistabel.

Wat is het verschil tussen llama.cpp en Ollama?

llama.cpp is de inferentie-engine: één C/C++-project van GGUF-maker Georgi Gerganov dat gequantiseerde modellen draait op CPU, GPU of een mix. Het geeft je llama-cli voor eenmalige prompts en llama-server — een OpenAI-compatibele HTTP-server — plus elke tuningflag die de engine ondersteunt: GPU-laagoffload, KV-cache-quantisatie, speculative decoding, eigen samplers.

Ollama is een product bovenop die engine. Het neemt llama.cpp op (geforkt en ingebouwd) en wikkelt er dit omheen:

• een modelregistry (ollama pull, ollama list) met automatisch splitsen van GGUF-gewichten,
• een Modelfile-systeem (een Dockerfile-achtige spec voor prompt-templates en parameters),
• een achtergronddaemon die modellen warm in het VRAM houdt en zijn eigen REST API blootlegt,
• automatische hardwaredetectie met veilige defaults.

Het praktische gevolg: met Ollama beheer je modellen; met llama.cpp beheer je inferentie. Heb je ooit de quantisatie-indeling willen wijzigen, de KV-cache willen quantiseren, de context voorbij de default willen optillen of specifieke lagen naar de GPU willen pinnen, dan is dat llama.cpp-territorium. Ollama verbergt de meeste van die knoppen — met opzet.

	llama.cpp	Ollama
Wat het is	Inferentie-engine (C/C++)	Dienst om llama.cpp heen
Installatie	Zelf bouwen of via pakket	Eénregelaar-installer, één binary
Een model draaien	llama-cli -m model.gguf + flags	ollama run llama3.1
API	OpenAI-compatibel (llama-server)	Eigen REST + OpenAI-compatibel endpoint
Modelbeheer	GGUF-bestanden zelf ophalen	Registry: pull/list/rm
Defaults	Jij kiest alles	Veilig: Q4_K_M, bescheiden context
Engine-updates	Dag één (upstream)	Loopt achter op upstream-releases
Tuningdiepte	Volledig (KV-quant, spec decode, samplers)	Beperkte doorgifte
Best voor	Performantiewerk, servers, edge-apparaten	Beginnen, dev-laptops

Is llama.cpp sneller dan Ollama?

Op hetzelfde GGUF-bestand, dezelfde quantisatie, dezelfde context en dezelfde llama.cpp-versie — nee, ze zitten binnen de ruis van elkaar, want Ollama is llama.cpp die de wiskunde doet. Elke Ollama-is-30%-langzamer-benchmark die je ziet is in werkelijkheid een vergelijking van defaults. De kloof komt van drie plekken:

1. Quantisatiekeuze. De registry van Ollama default naar Q4_K_M. Draai hetzelfde model als Q5_K_M of Q6_K vanuit llama.cpp en je krijgt betere kwaliteit per token bij vergelijkbare snelheid — of kies Q4_0/IQ4 voor rauwe snelheid.
2. Flash attention en KV-cache-quantisatie. --flash-attn plus -ctk q8_0 -ctv q8_0 verkleint de KV-cache aanzienlijk, wat tokens per seconde oplevert bij lange context en grotere contexten in hetzelfde VRAM laat passen. Ollama legt hiervan maar een deel bloot.
3. Versie-achterstand. llama.cpp landt kernel-optimalisaties wekelijks; Ollama merged upstream op zijn eigen tempo. Een verse llama.cpp-build is op dezelfde doos meetbaar sneller dan een maandenoude Ollama-binary — tot Ollama bijtrekt.

Snelle benchmark, engine-onafhankelijk — hij rapporteert prompt-evaluatie- en generatiesnelheid:

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

Draai hem tegen het eigen modelfile van Ollama (~/.ollama/models/blobs/..., hernoemd naar .gguf) en je matcht meestal exact de getallen van Ollama — en verslaat ze door -ctk q8_0 toe te voegen bij 16k context.

Hoe draai je hetzelfde model in beide?

Beide consumeren GGUF. Minimaal van nul tot draaiend voor elk:

# --- Ollama path: install, pull, serve ---
curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.1:8b        # downloads Q4_K_M, loads into VRAM, opens a chat

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

# --- llama.cpp path: build, download GGUF, serve ---
git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build -DGGML_CUDA=ON    # or -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 legt het OpenAI Chat Completions-schema bloot, dus dezelfde curl tegen http://localhost:8080/v1/chat/completions werkt ongewijzigd. Elke tool die voor de OpenAI API gebouwd is — scripts, editors, RAG-pipelines — kan naar beide wijzen. De flags doen het echte werk: -ngl 99 offloadt elke laag naar de GPU, --flash-attn plus het -ctk/-ctv-duo houdt een context van 16k binnen een kaart van 8 GB die de defaults van Ollama zouden weigeren.

Voor het kiezen van het GGUF-bestand zelf en wat de quant-labels betekenen: zie GGUF-modellen lokaal draaien.

Wanneer is Ollama zinvoller?

De meeste mensen moeten met Ollama beginnen, en dat is geen troostprijs:

• Je wilt het vanavond werkend. Eén commando, model binnengehaald, API omhoog. llama.cpp betekent een backend kiezen (CUDA/Vulkan/HIP/Metal), bouwen en gewichten met de hand ophalen.
• Je jongleert met veel modellen. De registry, het automatisch ontladen en Modelfiles verslaan het handmatig beheren van mappen vol GGUF-bestanden.
• Je machine is bescheiden. De defaults van Ollama zijn met reden conservatief — ze passen en draaien vrijwel altijd.
• Je wilt een stabiel API-oppervlak. De daemon van Ollama beheert de levenscyclus van modellen, zodat een langdraaiende service dat niet hoeft te doen.

Kies rauwe llama.cpp als je benchmarkeert, op welke schaal dan ook serveert, op een telefoon of Raspberry Pi draait, lange context op klein VRAM nodig hebt of een feature dezelfde dag wilt dat hij upstream merged. Powergebruikers draaien vaak beide: Ollama voor dagelijkse modellen, een gepinde llama.cpp-build voor die ene workload die de laatste 20% nodig heeft.

Is je vergelijking eigenlijk tussen desktop-GUI-apps, dan is dat een andere as — zie Ollama vs LM Studio — en voor de enginekeuze per taak behandelt de beste lokale LLM’s voor code de modelkant.

Welke gebruik je?

Beslis op controle, niet op snelheid. De engines zijn hetzelfde; de defaults niet. Installeer Ollama als het doel is dat het draait en een API serveert — je verliest een paar knoppen waar je toch niet aan zou draaien. Bouw llama.cpp als tokens per seconde, contextlengte of quantisatiecontrole het doel is — je krijgt elke knop, ten koste van zelf modellen beheren. Hoe dan ook draai je dezelfde GGUF-bestanden, en later wisselen kost een middag, geen herschrijfronde.

En als de modellen zelf de puzzel zijn — bestanden, quants, VRAM — loopt de GGUF-lokale-setupgids Ollama, llama.cpp en vLLM commando voor commando langs.