llama.cpp vs Ollama vs LM Studio: welke in 2026?

llama.cpp, Ollama en LM Studio delen hetzelfde hart — de GGUF-inferentie-engine — maar ze bedienen drie totaal verschillende gebruikers. Van de developer die elke milliseconde wil knijpen tot de ontwerper die liever tweemaal klikt dan eenmaal typt. Wat je kiest, bepaalt niet alleen de workflow, maar ook hoeveel je van de hardware overhoudt.

Drie tools, één doel

Het startpunt is altijd hetzelfde: een taalmodel in GGUF-formaat, kwantisatie ergens tussen Q3_K_S en Q8_0, en genoeg VRAM om het model niet naar systeemgeheugen te laten wegzakken. Alle drie de tools lossen dat kernprobleem op. Het verschil zit in de abstractielaag daarboven.

llama.cpp is de kern: een in C/C++ geschreven inferentie-engine van Georgi Gerganov, zonder omweg, zonder daemon, zonder GUI. Je roept een binaire aan, je geeft een model mee, je krijgt tokens terug. Ollama wikkelt llama.cpp in een Go-laag die modeldownloads, automatische GPU-detectie en een OpenAI-compatibele REST API levert — en die op de achtergrond als service draait. LM Studio bouwt daarop én op MLX verder via een Electron-applicatie met vensters, sliders en een ingebouwde chat-interface, plus een lokale serveroptie die je zonder één regel code opstart.

De hiërarchie is dus verticaal: Ollama gebruikt grotendeels dezelfde llama.cpp-backend als je zelf zou compileren, en LM Studio kan óók llama.cpp als backend gebruiken — maar voegt UI en het MLX-alternatief toe. Dat heeft consequenties voor de snelheid.

llama.cpp: puur snelheid, geen laag ertussen

llama.cpp bouwt na elke significante GPU-generatie opnieuw aan zijn backend. Voor NVIDIA-hardware is CUDA de standaard: compile met make GGML_CUDA=1 of gebruik een prebuilt release, en je hebt de snelste lokale inferentie die vandaag beschikbaar is. Op een RTX 4070 haalt Llama 3.1 8B in Q4_K_M gemiddeld 52–55 tok/s, een RTX 4090 loopt door naar 100–110 tok/s bij dezelfde modelgrootte.

Voor AMD-hardware zijn er twee paden. ROCm/HIP is de "CUDA-equivalent" voor Instinct-kaarten en nieuwere Radeon-series: sneller dan Vulkan bij gelijke hardware, maar vereist ROCm-installatie en werkt het best op Linux. Phoronix benchmarkte in 2026 de Radeon AI PRO R9700 en vond dat ROCm 7.1 de Vulkan-backend met zo'n 25–35% versloeg op llama.cpp. De Vulkan-backend is het universele vangnet: werkt op elke GPU die Vulkan ondersteunt — AMD, NVIDIA, Intel Arc, en zelfs een RX 580 uit 2017. Compile met make GGML_VULKAN=1. In een representatieve test op een oudere AMD-kaart steeg de promptverwerkingssnelheid van 165 naar 880 tok/s door van CPU naar Vulkan over te schakelen; generatiesnelheid ging van 22 naar 90 tok/s.

Opgelet: Ollama gebruikt een gebundelde versie van llama.cpp die niet altijd de meest recente Vulkan-optimalisaties bevat. Een GitHub-issue (ollama/ollama #15601) documenteert dat Ollama op AMD/Vulkan tot 56% trager kan zijn dan stand-alone llama.cpp door het ontbreken van Wave32 Flash Attention en graphics-queue-optimalisaties die pas in commit b8500+ (post maart 2026) aanwezig zijn in upstream. Als je een AMD GPU hebt en de maximale snelheid wilt, compile je llama.cpp zelf.

"Op een AMD GPU met Vulkan laat standalone llama.cpp tot 56% meer tokens per seconde zien dan de bundled versie in Ollama. Dat verschil zit in één commit."

Voor Apple Silicon gebruikt llama.cpp de Metal-backend. Dat werkt, maar MLX — Apples eigen tensorbibliotheek — is op hetzelfde silicon 10–20% sneller doordat het de unified memory beter benut en GPU-datakopie vermijdt. llama.cpp is op Apple Silicon dus niet de snelste keuze meer.

Ollama: inferentie als service

Ollama verandert llama.cpp in een daemon. Na installatie draait er een achtergrondproces op poort 11434 met een REST API die bewust compatibel is met de OpenAI-specificatie. POST /api/chat werkt identiek aan POST /v1/chat/completions — je kunt bestaande OpenAI-clients zonder aanpassing doorverbinden.

ollama pull llama3.1:8b
curl http://localhost:11434/api/generate \
  -d '{"model":"llama3.1:8b","prompt":"Wat is kwantisatie?","stream":false}'

Ollama haalt zijn modellen standaard van de eigen registry, maar ondersteunt ook directe GGUF-import. Via Hugging Face kun je elk van de 45.000+ publieke GGUF-checkpoints direct aanroepen:

ollama run hf.co/bartowski/Llama-3.1-8B-Instruct-GGUF:Q4_K_M

Geen download, geen conversie, geen Modelfile. Ollama detecteert automatisch de GPU's, verdeelt lagen over meerdere kaarten als je die hebt, en offloadt de rest naar CPU-RAM. De snelheidsboete van CPU-offloading is groot: zodra ook maar één laag naar RAM uitwijkt, halveer je de outputsnelheid of erger. In versie 0.6.2 (maart 2026) voegde Ollama Flash Attention v2.7 toe — activeer met OLLAMA_FLASH_ATTENTION=1 voor 15–20% winst en tot 30% minder VRAM op modellen die dit ondersteunen. Hetzelfde release bracht Llama 4-ondersteuning en M4 Metal-optimalisaties mee. Een preview van MLX-ondersteuning voor Apple Silicon rolde uit in maart 2026 met vroege resultaten die een 1,6× prefill-speedup tonen ten opzichte van de Metal-backend.

Ollama is het juiste gereedschap als je een API-laag wilt die andere tools kunnen aanroepen — Open WebUI, Continue.dev, Cursor, je eigen Python-script — zonder je bezig te houden met modelformaten, GPU-flags of serverlogica.

LM Studio: GUI, MLX en MCP

LM Studio is de enige van de drie die een grafische interface biedt. Je downloadt een model via een ingebouwde zoekinterface, selecteert het gewenste kwantisatieniveau, en klikt op "Load". Een slider bepaalt hoeveel GPU-lagen worden geladen; een teller toont het VRAM-gebruik in realtime. Dat klinkt triviaal, maar voor iemand die niet gewend is aan CLI-tooling is het het verschil tussen een werkende setup in vijf minuten of een middag debuggen.

Het technisch interessantste aspect van LM Studio is de MLX-backend, aanwezig sinds versie 0.3.4. Op Apple Silicon kun je kiezen: llama.cpp (Metal) of MLX. Het verschil is meetbaar: op een M3 Ultra haalt LM Studio met MLX 237 tok/s op Gemma 3 1B, tegenover 149 tok/s voor Ollama (dat op dit moment nog de Metal-backend gebruikt). De 26–60% snelheidswinst van MLX ten opzichte van llama.cpp/Metal is hardware-afhankelijk: bij kleinere modellen in volledig geheugenpaste context is het voordeel het grootst. Bij lange contexten (8.500+ tokens) is er een caveat: de prefill-overhead van MLX kan de effectieve throughput terugbrengen tot een fractie van de getoonde tokenssnelheid — een meting van 57 tok/s bleek in de praktijk dichter bij 3 tok/s effectieve outputsnelheid te liggen door prefillvertraging.

Versie 0.3.17 introduceerde ingebouwde MCP-ondersteuning. LM Studio fungeert als MCP Host: je voegt servers toe via een mcp.json-configuratiebestand, en elk geladen model krijgt toegang tot de gedefinieerde tools. Dat stelt je in staat om een lokaal model bestandssysteem te laten doorzoeken, webbrowsers aan te sturen, of databasequeries uit te voeren — zonder dat het model ooit het apparaat verlaat. MCP is een open protocol van Anthropic, maar LM Studio is tot nu toe de enige van de drie die het natively ondersteunt. Ollama vereist voor vergelijkbare tool use een externe wrapper of een framework zoals LangChain of LlamaIndex.

Welke tool past bij jouw stack?

De keuze hangt af van drie variabelen: de hardware die je gebruikt, de manier waarop je het model aanroept, en hoeveel beheersoverlast je wilt accepteren.

Gebruik llama.cpp direct als je op AMD-hardware de maximale Vulkan- of ROCm-prestatie wilt, het model inbedt via de C API of Python-bindings, of geen daemon wilt draaien. Het nadeel: elke modelwisseling is een nieuw commando, en je compileert voor elk backend-type apart.

Gebruik Ollama als je een stabiele, altijd-aan API-laag wilt die andere tools aanroepen. De OpenAI-compatibiliteit maakt het vervangbaar in elk systeem dat al met de OpenAI SDK werkt. Op NVIDIA is de prestatiekloof met standalone llama.cpp klein (3–10%); op AMD/Vulkan is die groter.

Gebruik LM Studio als je op Apple Silicon de MLX-backend wilt benutten, regelmatig van model wisselt, of MCP-tool use wilt testen zonder framework. Op Windows en Linux met NVIDIA-GPU kies je puur op workflow-voorkeur.

Veelgestelde vragen

Kan ik llama.cpp, Ollama en LM Studio tegelijk installeren?

Ja. Ze gebruiken allemaal aparte processen en poorten. Zorg wel dat je niet twee services tegelijk probeert een model in VRAM te laden — dat geeft geheugenconflicten. Ollama luistert op poort 11434, LM Studio op 1234 (configureerbaar).

Ollama zegt dat mijn AMD GPU niet ondersteund wordt. Wat nu?

Ollama ondersteunt op Linux AMD-kaarten via ROCm, maar niet alle Radeon-varianten zijn officieel gedekt. De Vulkan-backend in standalone llama.cpp werkt op vrijwel alle AMD-kaarten met een recente driver — compileer zelf met make GGML_VULKAN=1 voor de ruimste compatibiliteit.

Maakt kwantisatieniveau uit bij de toolkeuze?

Niet direct. Alle drie de tools ondersteunen dezelfde GGUF-kwantisaties (Q2_K tot Q8_0, IQ-varianten). Het kwantisatieniveau bepaalt VRAM-gebruik en kwaliteit, niet welke tool je kiest. Q4_K_M is voor de meeste use cases de zoetste spot: circa 4,5 bit per gewicht, ~5% kwaliteitsverlies ten opzichte van FP16.

Werkt MCP in LM Studio ook met open-source modellen?

Ja, maar de kwaliteit van tool use varieert sterk per model. Modellen die getraind zijn op function calling — zoals Llama 3.1 Instruct, Qwen 2.5 Instruct en Mistral v0.3 — presteren aanzienlijk beter dan modellen zonder die training.