Ollama, vLLM of llama.cpp: welke runtime past bij jouw situatie?
llama.cpp is de C/C++ inference-engine, Ollama de gebruiksvriendelijke laag eromheen voor lokaal experimenteren, en vLLM de productie-serving-engine voor GPU’s met veel gelijktijdige gebruikers. Welke past bij jouw workload.
Voor lokaal experimenteren en eenvoudig self-hosten is Ollama meestal de praktischste keuze. Voor een toepassing waarin maximale controle, brede hardwareondersteuning of deployment op edge-apparatuur belangrijk is, past llama.cpp beter. Bouw je een productie-API op GPU-servers waarop veel gebruikers tegelijk inferentie aanvragen, dan is vLLM doorgaans de logische runtime.
Het belangrijkste verschil zit niet in welk taalmodel je wilt draaien, maar in de manier waarop je het wilt serveren. llama.cpp is een C/C++ inference-engine, Ollama bouwt daar een gebruiksvriendelijke beheer- en API-laag omheen, terwijl vLLM vanaf de basis is ontworpen voor efficiënte model-serving met hoge throughput en veel gelijktijdige requests.
llama.cpp: de inference-engine dicht op de hardware
llama.cpp is de meest fundamentele van de drie. Het project implementeert inferentie voor LLM's grotendeels in C/C++ en probeert modellen efficiënt te laten draaien op een brede verzameling hardware. Het ondersteunt onder meer gewone CPU's, Apple Silicon via Metal, NVIDIA-GPU's via CUDA en verschillende andere GPU-backends. Ook hybride CPU/GPU-inferentie is mogelijk.
Een belangrijk onderdeel van het llama.cpp-ecosysteem is GGUF. Dit formaat wordt veel gebruikt voor gequantiseerde modellen, bijvoorbeeld met 4-, 5- of 8-bit gewichten. Door quantisatie kan een model met minder geheugen worden uitgevoerd, vaak ten koste van enige numerieke precisie — zie ook welke hardware je nodig hebt om een taalmodel lokaal te draaien.
Dat maakt llama.cpp interessant wanneer hardwarebeperkingen belangrijk zijn. Een model hoeft niet noodzakelijk volledig op een zware datacenter-GPU te staan. Je kunt inferentie uitvoeren op een CPU, een Mac met unified memory, een compacte GPU of een combinatie daarvan. Apple Silicon is expliciet een first-class platform binnen het project.
llama.cpp levert bovendien niet alleen een library. Met llama-server kan het ook zelf een OpenAI-compatibele HTTP-server aanbieden. Toch blijft de filosofie relatief low-level: je krijgt veel controle over modelbestanden, quantisatie, geheugen, offloading en hardware-backends, maar moet daarvan ook meer zelf begrijpen en beheren. Juist daardoor is llama.cpp geschikt voor embedded en edge-deployments, appliances, compacte lokale servers en gespecialiseerde toepassingen waarin een complete Python-servingstack ongewenst is.
Ollama: llama.cpp toegankelijk gemaakt
Ollama zit een niveau hoger. De runtime gebruikt llama.cpp als ondersteunde inference-backend, maar voegt daar modelbeheer, een eenvoudige CLI, lokale API's en configuratie omheen toe. De huidige Ollama-codebase bouwt een eigen gepinde versie van llama.cpp en gebruikt llama-server als onderdeel van zijn runtime.
Daarmee haalt Ollama veel operationele details weg die je bij rechtstreeks gebruik van llama.cpp zelf moet regelen. Een model downloaden, starten, vervangen en via HTTP aanspreken vereist weinig configuratie. Dat maakt Ollama aantrekkelijk voor developers die lokaal met verschillende open modellen willen werken zonder eerst een complete inference-omgeving op te zetten.
Voor een mkb-organisatie is dat bijvoorbeeld handig bij een lokale RAG-prototype, een interne chatbot of een agent die tijdens ontwikkeling op een workstation draait. Applicaties kunnen tegen de Ollama-API praten terwijl het onderliggende model lokaal blijft.
Die eenvoud is tegelijkertijd de beperking. Wie exact wil bepalen hoe de inference-engine wordt gebouwd, hoe geheugen wordt verdeeld of hoe een embedded deployment eruitziet, zit dichter bij de bron met llama.cpp zelf. Ook voor zeer drukke productie-inference is Ollama niet primair ontworpen als equivalent van gespecialiseerde high-throughput serving-engines: gebruiksgemak en modelbeheer zijn belangrijkere ontwerpdoelen dan het maximaliseren van concurrency op een GPU-cluster.
vLLM: gebouwd voor productie-serving
vLLM kiest een andere uitgangspositie. Het project richt zich in de eerste plaats op GPU-georiënteerde model-serving met hoge throughput. Het integreert sterk met het Hugging Face-ecosysteem en biedt een OpenAI-compatibele API-server, maar de belangrijkste verschillen zitten dieper in de inference-engine.
Een kerntechniek is PagedAttention. Daarbij wordt het geheugen voor de attention key/value-cache efficiënter beheerd, zodat geheugen niet voor iedere request als één groot aaneengesloten blok hoeft te worden behandeld. Daarnaast gebruikt vLLM continuous batching: nieuwe requests kunnen dynamisch aan het inference-proces worden toegevoegd in plaats van dat een vaste batch eerst volledig moet worden afgewerkt.
Dat wordt belangrijk zodra meerdere gebruikers tegelijk hetzelfde model aanspreken. Een enkele interactieve chat vanaf een laptop stelt heel andere eisen dan tientallen of honderden gelijktijdige inference-streams op een centrale server. Bij dat tweede scenario kunnen scheduler, batching en KV-cachebeheer een groot deel van de daadwerkelijke systeemprestaties bepalen. vLLM ondersteunt daarnaast technieken zoals prefix caching, verschillende vormen van quantisatie en meerdere strategieën voor parallelle inferentie over GPU's en nodes.
Daar staat complexiteit tegenover. vLLM past vooral in omgevingen waar GPU-infrastructuur beschikbaar is en waar een model als centrale service wordt aangeboden. Voor een klein model op een kantoor-pc of een edge-device is die architectuur meestal onnodig zwaar.
Het verschil tussen snelheid en throughput
Bij de keuze tussen deze runtimes wordt "snelheid" vaak te algemeen gebruikt. Er zijn minstens twee verschillende vragen. De eerste is: hoe snel krijgt één gebruiker tokens terug? Daar kunnen modelgrootte, quantisatie, geheugenbandbreedte en gebruikte hardware zwaarder wegen dan de runtimekeuze alleen.
De tweede is: hoeveel inferenceverkeer kan één server als geheel verwerken? Daar worden technieken als continuous batching veel belangrijker. Dit is het terrein waarvoor vLLM expliciet is ontworpen.
Een runtime die uitstekend werkt voor één lokale gebruiker is daarom niet automatisch de beste runtime voor honderd API-clients. Andersom heeft een geavanceerde GPU-servingstack weinig voordeel wanneer er vrijwel nooit gelijktijdige requests zijn.
Ollama of direct llama.cpp?
Deze twee liggen technisch dichter bij elkaar dan de vergelijking met vLLM doet vermoeden. Ollama gebruikt llama.cpp als inference-backend en neemt vooral beheerwerk uit handen.
Kies Ollama wanneer je vooral denkt: ik wil een model lokaal kunnen starten en er vanuit mijn applicatie tegen praten. Kies direct llama.cpp wanneer je denkt: ik wil zelf controle over de inference-engine, modelbestanden, build, hardware-backend en deployment.
Voor een prototype kan Ollama daarom een snellere route zijn. Wanneer hetzelfde systeem later een gespecialiseerde appliance of edge-oplossing wordt, kan rechtstreeks gebruik van llama.cpp logischer worden.
Praktische vuistregel
Voor hobbygebruik, ontwikkeling, lokale RAG-experimenten en prototypes is Ollama meestal de eenvoudigste keuze. Je krijgt een bruikbare lokale API en modelbeheer zonder veel infrastructuurwerk.
Voor edge, embedded, CPU-inference, Apple Silicon en deployments waarbij je maximale controle over geheugen en hardware wilt, ligt llama.cpp meer voor de hand. Het is de onderliggende C/C++ inference-engine en kan zeer dicht op de beschikbare hardware worden ingezet.
Voor een centrale productie-API op GPU-infrastructuur met veel gelijktijdige gebruikers is vLLM meestal de betere uitgangspositie. Continuous batching, PagedAttention en de bredere servingarchitectuur zijn juist voor dat type workload ontworpen.
Kort gezegd: Ollama voor gemak, llama.cpp voor controle en hardwareflexibiliteit, vLLM voor schaalbare GPU-serving. De beste runtime is dus niet degene met de langste featurelijst, maar degene waarvan de architectuur overeenkomt met je echte inference-workload.