Review: vLLM versus Ollama voor productie op eigen servers

Wie op eigen servers taalmodellen wil draaien voor interne applicaties, achtergrondverwerking of web-interfaces, stuit vrijwel direct op twee dominante server-engines: vLLM en Ollama. Beide open-source projecten hebben in de afgelopen twaalf maanden een enorme volwassenwording doorgemaakt. Desondanks zijn ze ontworpen vanuit fundamenteel verschillende architecturen en gebruikssituaties. Waar het ene pakket uitblinkt in minimalistische lokale opstellingen en eenvoudige CLI-workflows, is de andere motor vanaf de basis ontworpen om gigantische volumes gelijktijdige API-aanroepen over clusters van grafische kaarten te verwerken.

In dit artikel vergelijken we vLLM en Ollama op basis van technische architectuur, doorvoercapaciteit onder gelijktijdige belasting, geheugenbeheer, ondersteunde bestandsformaten en beheercomplexiteit. We kijken naar de harde cijfers, de concrete implementatie op Linux-servers en de afwegingen die bepalen wanneer een overstap van de ene naar de andere tool noodzakelijk wordt.

De fundamentele scheiding in architectuur

Ollama is gebouwd rondom llama.cpp en richt zich op het laagdrempelig verpakken en uitvoeren van taalmodellen via container-achtige modelfiles. De engine draait als een gecompileerd Go-programma dat C/C++-bibliotheken aanroept om berekeningen uit te voeren op CPU's, Apple Silicon unified memory of NVIDIA/AMD GPU's. De focus van Ollama ligt op eenvoudige distributie, desktop-integratie en seriële aanroepen. Standaard verwerkt Ollama verzoeken sequentieel of met een beperkte, handmatig ingestelde wachtrijcapaciteit via parallelle slots.

vLLM daarentegen is een high-throughput serving framework dat is ontwikkeld aan UC Berkeley. Het is specifiek geoptimaliseerd voor GPU-clusters met NVIDIA Tensor Cores en AMD ROCm-architecturen. De kern van vLLM is geschreven in C++ en CUDA met een Python-laag voor modelorkestratie. In plaats van modellen laag voor laag door te rekenen voor één gebruiker tegelijk, gebruikt vLLM geavanceerde batching- en geheugentechnieken om tientallen verzoeken parallel te verwerken binnen hetzelfde GPU-geheugenvlak.

Om te begrijpen hoe deze twee platformen zich binnen een homelab of serveromgeving hebben ontwikkeld, loont het om de eerdere signalen over lokale LLM's en de adoptie van inferentie-engines te bekijken, waarin de verschuiving naar zelf-gehoste infrastructuren al duidelijk zichtbaar werd. Waar Ollama ideaal is om binnen zestig seconden een model operationeel te krijgen op een ontwikkelmachine, stelt vLLM enterprise-eisen aan de hardware en configuratie.

Geheugenbeheer: PagedAttention versus statische allocatie

Het grootste technische onderscheid tussen beide engines zit in het beheer van de Key-Value (KV) cache in het VRAM van de grafische kaart. Tijdens het genereren van tokens moet het model eerdere context opslaan in het videogeheugen. Traditionele systemen reserveren hiervoor een aaneengesloten, statisch blok VRAM op basis van de maximale contextlengte die een verzoek theoretisch kan bereiken. Dit leidt tot zware geheugenfragmentatie en ongebruikte capaciteit.

vLLM lost dit op met PagedAttention, een algoritme dat sterk lijkt op virtueel geheugenbeheer in traditionele besturingssystemen. PagedAttention verdeelt de KV-cache in niet-aaneengesloten fysieke geheugenblokken (pages). Hierdoor kan vLLM geheugen dynamisch toewijzen naarmate de prompt en het gegenereerde antwoord groeien. Geheugenfragmentatie daalt hierdoor van circa 60 tot 80 procent naar minder dan 4 procent. Dit maakt het mogelijk om VRAM vrijwel tot de fysieke grens te vullen met actieve verzoeken.

Ollama (via llama.cpp) alloceert daarentegen geheugen per context-slot. Als een server wordt geconfigureerd met vier parallelle slots via OLLAMA_NUM_PARALLEL=4, wordt het geheugen opgesplitst in vier vaste context-buffers. Als drie van die slots korte vragen verwerken van 200 tokens en de maximale contextlengte staat op 8.192 tokens, blijft het gereserveerde geheugen van die drie slots onbenut geblokkeerd. Hierdoor loopt een server met Ollama aanzienlijk sneller tegen Out-of-Memory (OOM) fouten aan bij piekbelasting.

Continuous batching en doorvoer onder belasting

Naast geheugenbeheer bepaalt de scheduling-strategie de werkelijke doorvoersnelheid (throughput in tokens per seconde). Traditionele statische batching groepeert inkomende prompts en wacht tot het langste antwoord in de batch klaar is voordat nieuwe verzoeken worden geaccepteerd. Dit zorgt ervoor dat snelle prompts onnodig lang moeten wachten op complexe generaties.

vLLM implementeert continuous batching (ook wel dynamic chunked prefill en iterative scheduling genoemd). Zodra een enkel token in een actieve sequentie is berekend, kan de scheduler direct een nieuw binnenkomend verzoek invoegen in de lopende iteratie. Tokens van verschillende gebruikers worden op iteratieniveau gemixt en parallel berekend op de Tensor Cores. Dit resulteert in een doorvoer die bij 16 of meer gelijktijdige streams tot wel 5 tot 10 keer hoger ligt dan bij seriële afhandeling.

Voor wie een robuuste API-gateway wil opzetten met load balancing en foutafhandeling, is het essentieel om te bepalen hoe deze modelservers worden ontsloten. Zie hiervoor het overzicht over lokale modellen achter je eigen API beheren om te zien hoe routers omgaan met latency en concurrency van verschillende backends.

Kwantisatie en ondersteunde modelformaten

Het bestandsformaat waarin gewichten worden geladen, beïnvloedt zowel de opstartsnelheid als de inferentieprestaties op specifieke chips. Ollama vertrouwt volledig op het GGUF-formaat. GGUF bundelt tensoren, metadata en hyperparametrisering in één enkel binair bestand. Dit formaat is uitstekend geoptimaliseerd voor CPU-inferentie en Apple Silicon Metal Shaders, waarbij individuele model-lagen naar believen kunnen worden verdeeld tussen systeem-RAM en GPU-VRAM.

vLLM richt zich primair op ongekwantiseerde weights (FP16, BF16) of moderne GPU-specifieke kwantisatiemethoden zoals AWQ (Activation-aware Weight Quantization), GPTQ en native FP8/FP4 formaten. Deze formaten behouden een hogere precisie op GPU-kernels en maken optimaal gebruik van de gespecialiseerde matrix-vermenigvuldigingseenheden op datacenterkaarten en moderne consumenten-GPU's.

Wie de trade-off tussen geheugenbesparing en kwaliteitsverlies tot in detail wil analyseren, kan de uitgebreide meetresultaten raadplegen in het artikel over quantization-verlies bij AWQ, GGUF en EXL2, waarin zichtbaar wordt dat AWQ op pure NVIDIA-architecturen aanzienlijk sneller decodeert dan traditionele k-quants in GGUF.

Multi-GPU ondersteuning: Tensor Parallelism versus Layer Splitting

Wanneer een model te groot is voor het VRAM van een enkele videokaart (bijvoorbeeld een 70B parameter model dat circa 40 GB aan gecomprimeerde gewichten vereist), moeten de berekeningen worden verdeeld over meerdere grafische kaarten. De wijze waarop deze verdeling plaatsvindt, heeft drastische gevolgen voor de latency.

Ollama ondersteunt voornamelijk naïeve layer-offloading. Als er twee videokaarten aanwezig zijn, laadt Ollama bijvoorbeeld laag 1 tot en met 40 op GPU 0 en laag 41 tot en met 80 op GPU 1. Dit betekent dat GPU 1 niets staat te doen terwijl GPU 0 de eerste helft van het netwerk doorrekent. De hardware draait in serie, waardoor de rekenkracht niet cumulatief toeneemt; alleen het beschikbare geheugen wordt opgeteld.

vLLM ondersteunt echte Tensor Parallelism via NCCL (NVIDIA Collective Communications Library). Hierbij wordt elke afzonderlijke matrixlaag horizontaal of verticaal opgesplitst over alle beschikbare GPU's. Beide kaarten voeren gelijktijdig berekeningen uit voor dezelfde tokens en wisselen tussenresultaten uit via PCIe of NVLink. Dit halveert de tijd per token ten opzichte van sequentiële verwerking, mits de interconnectie tussen de kaarten snel genoeg is.

In virtuele en gecontaineriseerde omgevingen vereist dit wel een directe toewijzing van de hardware. In de technische gids over GPU-passthrough op Proxmox voor lokale modelservers staat exact beschreven hoe IOMMU-groepen en PCIe-bussen moeten worden geconfigureerd om PCIe-bandbreedteverlies te voorkomen.

Praktische implementatie en configuratie

Het verschil in complexiteit tussen beide tools wordt direct duidelijk bij de installatie en het operationele beheer. Ollama installeert als een enkele binary of een minimalistische Docker-container en vereist vrijwel geen initiële afstelling om te functioneren:

# Ollama starten met een standaard model
ollama run qwen2.5:7b-instruct-q4_K_M

# API aanroep via curl
curl http://localhost:11434/api/generate -d '{
  "model": "qwen2.5:7b-instruct-q4_K_M",
  "prompt": "Leg continuous batching uit in twee zinnen."
}'

vLLM wordt daarentegen uitgerold als een Python-module of via een officiële Docker-container met CUDA-runtime dependencies. De configuratie vereist expliciete afstemming op de fysieke VRAM-limieten van de host:

# vLLM container starten met OpenAI-compatibele API en FP8-kwantisatie
docker run --gpus all \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -p 8000:8000 \
  --ipc=host \
  vllm/vllm-openai:latest \
  --model Qwen/Qwen2.5-7B-Instruct \
  --gpu-memory-utilization 0.92 \
  --max-model-len 8192 \
  --tensor-parallel-size 1 \
  --quantization fp8

De parameter --gpu-memory-utilization 0.92 instrueert vLLM om direct 92 procent van het beschikbare VRAM te reserveren. De modelgewichten nemen een deel hiervan in beslag; het volledige resterende geheugen wordt onmiddellijk geformatteerd als een pre-allocated pool voor de PagedAttention KV-cache. Hierdoor rapporteert nvidia-smi continu een nagenoeg vol geheugen, wat verwarrend kan zijn voor beheerders die gewend zijn aan dynamisch allocerende software.

Observability, metrics en productiebeheer

In een productieomgeving waar SLA's, foutpercentages en reactietijden moeten worden bewaakt, schiet Ollama op dit moment tekort. Ollama levert minimale logica voor telemetrie; er is geen native Prometheus-endpoint voor diepe GPU- en wachtrijstatistieken. Om te zien hoeveel verzoeken in de wachtrij staan of hoe vol de context-slots zitten, moeten externe wrappers of log-parsers worden ingezet.

vLLM beschikt standaard over een uitgebreid /metrics-endpoint dat direct door Prometheus kan worden gescraped. Dit endpoint exposeert cruciale productie-metrieken:

# Voorbeelden van vLLM Prometheus metrics
vllm:num_requests_running{model="Qwen2.5-7B"} 14
vllm:num_requests_waiting{model="Qwen2.5-7B"} 3
vllm:gpu_cache_usage_factor{model="Qwen2.5-7B"} 0.81
vllm:avg_generation_throughput_tok_per_s 412.8

Met deze data kunnen orchestrators zoals Kubernetes (K8s) of Docker Swarm automatisch horizontale autoscaling activeren zodra de parameter num_requests_waiting boven een bepaalde drempelwaarde stijgt, of wanneer de gpu_cache_usage_factor de 90 procent nadert.

Zwakke punten en beperkingen per engine

Geen van beide oplossingen is universeel toepasbaar. Het kiezen van de verkeerde tool leidt tot onnodige operationele frictie of verspilling van dure servercapaciteit.

Zwakke punten van Ollama in productie:

De grootste beperking is de dramatische terugval in doorvoersnelheid bij gelijktijdige aanroepen. Zodra meerdere microservices of gebruikers tegelijkertijd prompts sturen, lopen verzoeken vast in een seriële wachtrij of treden er hoge latencies op door suboptimale slot-allocatie. Daarnaast ontbreekt geavanceerde multi-GPU parallellisatie, waardoor zware 70B+ modellen traag blijven. Tot slot biedt het updatebeleid van Ollama weinig controle over onderliggende runtime-flags van llama.cpp.

Zwakke punten van vLLM:

vLLM heeft een steile leercurve en vereist diepgaande kennis van CUDA, GPU-geheugenarchitecturen en kernel-compilatie. De engine vereist strikt geschikte dedicated GPU-hardware; draaien op standaard consumenten-CPU's of Apple Silicon zonder zware omwegen is niet de primaire focus. Het systeem reserveert direct al het toegewezen VRAM, waardoor het delen van één GPU tussen meerdere verschillende modellen op dezelfde machine complexer is. Daarnaast kan het opstarten van zware containers enkele minuten duren omdat model-shards volledig in het geheugen moeten worden geïnitialiseerd.

Conclusie en implementatieadvies

Voor individuele ontwikkelaars, lokale kantoorautomatisering met één gebruiker per keer, of edge-apparaten met Apple Silicon en beperkte VRAM-capaciteit blijft Ollama de meest ergonomische en snelle keuze. De eenvoud van installatie en het brede aanbod van kant-en-klare GGUF-modellen maken het onverslaanbaar voor prototyping en kleinschalige taken.

Zodra een modelserver echter fungeert als centrale backend voor meerdere applicaties, web-interfaces, agent-loops of batch-verwerkingen met gelijktijdige API-aanroepen, is vLLM de technisch superieure keuze. Dankzij PagedAttention en continuous batching haalt vLLM het maximale rendement uit dure NVIDIA- en AMD-rekenkaarten. De aanwezigheid van native Prometheus-statistieken en Tensor Parallelism maakt het de de facto standaard voor betrouwbare productie-inferentie op eigen servers.