Ollama of vLLM kiezen: welke LLM server is geschikt?

Ollama versus vLLM, in één alinea

Ollama is een modelbeheerder met een ingebouwde server: het downloadt gekwantiseerde gewichten, laadt deze en beantwoordt verzoeken op 127.0.0.1:11434, zelfs op een CPU als de machine niet over meer beschikt. vLLM is een engine voor doorvoersnelheid: het houdt een GPU verzadigd door veel verzoeken tegelijkertijd te verwerken, en is daarom ongeschikt voor machines zonder GPU. Dat is de kern van de afweging. Eén gebruiker die met een lokale assistent praat, is een taak voor Ollama. Een applicatie die een team bedient, is een taak voor vLLM.

Beide ondersteunen een OpenAI-compatibele HTTP API, waardoor clientcode eenvoudig kan wisselen door de base URL aan te passen. De API is niet het onderscheidende kenmerk. Het verschil zit in de afhandeling wanneer een tweede verzoek binnenkomt terwijl het eerste nog tokens genereert.

Wat Ollama precies is

Ollama is een gebruiksvriendelijke laag. Het biedt een modelregister (ollama pull llama3.1:8b), een lokale opslag voor gewichten, een chat-prompt, een systemd-service en een HTTP API, allemaal via één installatiecommando. De meeste modellen die het aanbiedt zijn GGUF-bestanden, meestal 4-bit gekwantiseerd. Daarom is een 7B- of 8B-model ongeveer 5 GB op schijf in plaats van 16 GB. Kwantisatie vermindert het geheugen dat nodig is voor CPU-inferentie. Op Apple Silicon Macs kan het ook safetensors-gebaseerde modellen uitvoeren via een MLX-engine. Sinds v0.40.0 (september 2026) draaien ondersteunde architecturen daar automatisch op MLX.

De GGUF-runner is gebouwd op llama.cpp, de C++ inferentie-bibliotheek die GGUF-kwantisatie praktisch maakte op standaardhardware. Sinds oktober 2026 ondersteunt Ollama twee engines: llama.cpp en MLX. Linux-builds ondersteunen nu ook MLX-inferentie met CUDA. De ontwikkelhandleiding activeert die backend met cmake -B build . -DOLLAMA_MLX_BACKENDS=cuda_v13, met CUDA 13+ en cuDNN 9+ als vereisten. Wanneer mensen Ollama vergelijken met llama.cpp, vergelijken ze in feite een ergonomische laag met de software die eronder draait.

Het ontwerp is gericht op één gebruiker. Sinds oktober 2026 is de standaardwaarde voor OLLAMA_NUM_PARALLEL 1. Dit betekent dat één model één verzoek tegelijk verwerkt en dat al het overige in een wachtrij staat die standaard 512 items bevat (OLLAMA_MAX_QUEUE). U kunt de parallelle instelling verhogen; de onderstaande sectie legt uit wat de gevolgen daarvan zijn. Als u Ollama nog niet eerder heeft gebruikt, begin dan bij Ollama hosten op een VPS en poort 11434 gesloten houden, omdat de lokale API geen authenticatie vereist.

Wat vLLM daadwerkelijk is

vLLM is een inference server en niets anders. Het beheert geen modelbibliotheek, het biedt een vllm chat client voor een draaiende server, en het haalt geen model voor u op tijdens een verzoek. U geeft bij het opstarten een Hugging Face repository op, het laadt dat specifieke model en het serveert dit totdat u het proces stopt.

Wat u voor die beperkte focus terugkrijgt, is doorvoersnelheid. Twee mechanismen doen het werk. PagedAttention slaat de KV cache (key-value cache, de per-token attention-status die een model bijhoudt voor elk actief verzoek) op in blokken van vaste grootte, op de manier waarop een besturingssysteem geheugen pagineert. Een verzoek heeft niet langer één grote aaneengesloten reservering nodig ter grootte van het worst-case scenario, waardoor geheugen dat voorheen gereserveerd en ongebruikt bleef, beschikbaar komt voor meer gelijktijdige verzoeken. Continuous batching stelt een nieuw verzoek in staat om bij de volgende decoding-stap aan te sluiten bij de actieve batch, in plaats van te wachten tot de huidige batch is voltooid. Een voltooide reeks verlaat de batch onmiddellijk en de vrijgekomen plek wordt direct opnieuw gevuld.

Het praktische resultaat: op een enkele GPU zorgt het opschalen van één naar dertig gelijktijdige gebruikers voor een scherpe stijging van het totaal aantal tokens per seconde, terwijl de snelheid per gebruiker veel minder afneemt dan u zou verwachten. Bij de standaardinstellingen van Ollama betekent opschalen van één naar dertig gebruikers simpelweg dat negenentwintig mensen moeten wachten.

Continuous batching maakt het volledige verschil

Stel u voor dat vijf verzoeken tegelijkertijd op een server binnenkomen, op identieke hardware.

Ollama voert met de standaardinstellingen het eerste verzoek volledig uit, daarna het tweede, enzovoort. De vijfde aanroeper wacht op vier volledige generaties. De totale doorvoer is ongeveer de snelheid van één generatie, omdat de processor telkens aan slechts één reeks werkt.

vLLM decodeert alle vijf de verzoeken in dezelfde forward pass. Het genereren van één token voor vijf reeksen kost nauwelijks meer dan het genereren van één token voor één reeks. Dit komt doordat het dure gedeelte het inlezen van de modelgewichten uit het geheugen is, en die leesactie wordt gedeeld over de gehele batch. Dit is hetzelfde feit over geheugenbandbreedte dat CPU-inferentie traag maakt: u betaalt voor het verplaatsen van gewichten, niet voor de rekenkundige bewerkingen.

U kunt OLLAMA_NUM_PARALLEL=4 instellen om een deel hiervan te bereiken. De kosten hiervan zijn geheugen. Elke parallelle slot heeft zijn eigen KV-cache nodig, en Ollama vermenigvuldigt de context-allocatie in plaats van deze te verdelen: de FAQ stelt dat het vereiste RAM schaalt met OLLAMA_NUM_PARALLEL keer OLLAMA_CONTEXT_LENGTH. Dus vier parallelle verzoeken tegen een model dat is geconfigureerd voor 8192 tokens behouden elk 8192 tokens, maar de server moet in totaal cache voor 32768 tokens vasthouden. Die 8192 is zelf een keuze in plaats van een vaststaand gegeven, dus het verhogen van num_ctx en het bepalen van de RAM-kosten is de stap die bepaalt of vier slots überhaupt passen. De paged cache van vLLM voorkomt dat het volledige venster voor elke slot vooraf wordt gereserveerd, omdat blokken aan een verzoek worden toegewezen naarmate het verzoek daadwerkelijk groeit. Hoe dan ook, de bovengrens van hoeveel gebruikers een enkele server tegelijkertijd kan bedienen, komt neer op de KV-cachegrootte, de prefill-kosten en de wachtrijdiepte, wat de reden is waarom een server die voor één persoon prima aanvoelde, traag wordt bij vijf.

Installeren en serveren met Ollama

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b
ollama run --verbose llama3.1:8b "Write two sentences about Linux."

Het installatiescript maakt een ollama-systeemgebruiker aan, installeert het binaire bestand en registreert ollama.service gekoppeld aan 127.0.0.1:11434. De eval rate-regel die door --verbose wordt afgedrukt, is uw werkelijke aantal tokens per seconde op die machine. Vertrouw hierop in plaats van op gepubliceerde cijfers. Eén meting van één prompt is slechts een startpunt en geen capaciteitsgetal. Daarom vertelt het timen van tokens per seconde tijdens een gelijktijdigheidstest u of de machine standhoudt bij de belasting die u daadwerkelijk verwacht, en of het huren van een GPU voordeliger is dan betalen per token.

Gebruik een systemd drop-in om de gelijktijdigheid te verhogen, zodat een upgrade de wijziging niet overschrijft:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl restart ollama
ollama ps

ollama ps toont wat er geladen is, en de PROCESSOR-kolom vertelt de waarheid. 100% CPU betekent dat er geen GPU wordt gebruikt; dit is de eerlijke verklaring voor de meeste meldingen dat Ollama traag is. De OLLAMA_KEEP_ALIVE=30m-regel in die drop-in is net zo belangrijk op een rustige machine, omdat de standaardinstelling het model na vijf minuten zonder verzoek ontlaadt. Het model in het geheugen houden tussen verzoeken voorkomt dat de eerste prompt na een pauze van maximaal een half uur opnieuw de volledige laadtijd vereist. Als uw periodes van inactiviteit langer duren, stel dan een hogere waarde in.

Installeren en serveren met vLLM

GPU-builds van vLLM vereisen Linux (macOS op Apple Silicon heeft alleen CPU-ondersteuning via een prebuilt wheel in de 0.32.0-release; GPU-versnelling op die Macs verloopt via vLLM-Metal, een afzonderlijke door de community onderhouden plugin gebaseerd op MLX). Wat betreft Python accepteert de huidige release (0.32.0, oktober 2026) versies 3.11 tot 3.14, en de installatiehandleiding vermeldt hetzelfde bereik. Python 3.10 werd in 0.32.0 verwijderd, dus 3.12, dat hieronder wordt gebruikt, is de veilige keuze. Installeer het in een eigen virtuele omgeving, omdat het een specifieke PyTorch-build ophaalt:

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto
vllm download-kernels

De laatste regel staat in de NVIDIA-installatiehandleiding van vLLM per oktober 2026. Deze installeert de voorgecompileerde kernels van FlashInfer. Zonder deze kernels downloadt en compileert vLLM de kernels bij het opstarten, wat volgens de handleiding op Hopper- en nieuwere GPU's enkele minuten kan duren. Voer dit opnieuw uit na elke vLLM-upgrade, omdat FlashInfer weigert te importeren wanneer de kernels niet overeenkomen.

Serveer vervolgens een model. De naam is een repository-id van Hugging Face, geen korte tag:

vllm serve Qwen/Qwen2.5-1.5B-Instruct

Het opstarten duurt de eerste keer lang, omdat het de gewichten downloadt en vervolgens de GPU profileert om te bepalen hoeveel KV-cacheblokken er passen. Het luistert op poort 8000. Controleer dit voordat u clientcode schrijft:

curl http://localhost:8000/v1/models
curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "Qwen/Qwen2.5-1.5B-Instruct", "messages": [{"role": "user", "content": "Who won the world series in 2020?"}]}'

Als Docker al op de machine staat, voorkomt de officiële image het werk met CUDA-afhankelijkheden:

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=$HF_TOKEN" \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model Qwen/Qwen3-0.6B

--ipc=host geeft de container toegang tot het gedeelde geheugen van de host; het verhogen van --shm-size is een alternatieve optie. PyTorch verplaatst tensors tussen processen via gedeeld geheugen, in het bijzonder voor tensor-parallelle inferentie.

De vlaggen die in productie het belangrijkst zijn, zijn --max-model-len (het contextvenster waarvoor u bereid bent te betalen), --gpu-memory-utilization (de fractie van de kaart die vLLM mag claimen, standaard 0.92 per oktober 2026), --tensor-parallel-size voor het splitsen van één model over meerdere GPU's, en --api-key.

Authenticatie is een vlag in vLLM en ontbreekt in de lokale API van Ollama

vLLM dwingt een bearer token af als u er een opgeeft:

vllm serve Qwen/Qwen2.5-1.5B-Instruct --api-key token-abc123

Dezelfde waarde kan worden ingelezen vanuit de omgevingsvariabele VLLM_API_KEY. Een verzoek aan de /v1-routes zonder dit token resulteert in een HTTP 401-foutmelding. De sleutel beveiligt echter niet de gehele server. De beveiligingshandleiding van vLLM en de authenticatiecode in de 0.32.0-broncode passen dit alleen toe op eindpunten onder de padprefixen /v1, /v2, /inference en /cohere. De helptekst voor --api-key op de vllm serve-pagina vermeldt alleen de eerste drie, maar de code controleert alle vier de paden. Zowel de handleiding als de helptekst geven aan dat andere eindpunten, met name /invocations, dat dezelfde inferentie blootstelt als /v1, niet worden geauthenticeerd. Dit is reden genoeg om poort 8000 niet op een publieke interface te publiceren. De beveiligingshandleiding van vLLM laat rate limiting bovendien over aan een reverse proxy die voor de server wordt geplaatst. Een token dat via onversleuteld HTTP wordt verzonden, is tijdens het transport leesbaar, maar de vlag betekent wel dat de server onderscheid kan maken tussen aanroepers.

De lokale API van Ollama vereist geen authenticatie. Cloudmodellen, het publiceren van modellen en het downloaden van privémodellen vereisen een aanmelding; directe API-toegang tot ollama.com vereist een API-sleutel. Elk proces dat poort 11434 kan bereiken, kan modellen uitvoeren, ophalen of verwijderen. Houd de service op localhost en benader deze via een door u zelf gehoste WireGuard VPN, of via een authenticerende reverse proxy die TLS (transport layer security) afhandelt.

Hardware: wat elk systeem vereist

Ollama draait op de CPU. Een 4-bit gekwantiseerd model verbruikt ongeveer een halve gigabyte aan RAM per miljard parameters, plus ongeveer een gigabyte aan runtime-overhead en extra geheugen voor de context. Een 3B-model vereist dus ongeveer 4 GB aan vrij geheugen en een 8B-model ongeveer 8 GB. De snelheid op een gedeelde vCPU ligt tussen de enkele en lage dubbele cijfers aan tokens per seconde. Dit wordt veroorzaakt door de geheugenbandbreedte, niet door een onjuiste configuratie, en geen enkele flag kan dit verhelpen. Om deze berekening in de praktijk te zien bij een specifieke release in plaats van een vuistregel, kunt u Nemotron 3.5 Lightning draaien op een VPS. Dit toont precies welke tag u moet ophalen, hoeveel RAM het model inneemt na het laden en of de CPU-only prestaties acceptabel zijn voor uw gebruik.

vLLM gaat uit van een GPU. Het standaardpad gebruikt ongekwantiseerde gewichten met een precisie van 16-bit, wat neerkomt op ongeveer 2 GB per miljard parameters: een 8B-model heeft ongeveer 16 GB aan videogeheugen nodig voor alleen de gewichten, nog voor de KV-cache die de gelijktijdigheid biedt waarvoor u vLLM heeft geïnstalleerd. Op een kaart met 24 GB blijft er een werkbare cache over. Op een kaart met 16 GB is dat niet het geval; u moet dan een kleiner model kiezen, de flag --quantization meegeven (met een gekwantiseerd checkpoint, of om full-precision gewichten tijdens het laden te kwantiseren), of een deel van de gewichten naar het systeem-RAM verplaatsen met --cpu-offload-gb. Dit behoudt de precisie, maar is trager omdat deze gewichten bij elke forward pass naar de GPU moeten worden verplaatst. Er bestaat een CPU-backend met eigen specifieke wheels, maar deze heft de reden om vLLM te gebruiken op.

De hardwarekeuze beantwoordt daarom meestal de softwarevraag. Geen GPU betekent Ollama. Een gehuurde GPU die op 5 procent bezetting draait omdat verzoeken worden geserialiseerd, betekent vLLM.

Welke keuze past bij uw workload

• Eén persoon, een CPU VPS, voor het opstellen en samenvatten van teksten: Ollama. Het tempo is acceptabel en er is geen eenvoudigere oplossing.
• Een programmeerassistent, of een MCP-server die uw tools koppelt aan een lokaal model, die alleen door u wordt aangeroepen: Ollama. Een concurrency van één is de werkelijke workload.
• Deze week vijf modellen vergelijken: Ollama. Het ophalen en verwijderen van getagde modellen is precies waar het goed in is, terwijl vLLM voor elk model een procesherstart vereist.
• Een interne applicatie, een chatproduct of een retrieval-pipeline met echte gebruikers: vLLM. Dit is waar batching de kosten voor een GPU rechtvaardigt.
• Een batch-job die 's nachts honderdduizend documenten verwerkt: vLLM, met een hoge --max-num-seqs. Doorvoer is de enige relevante metriek en de latentie per document is dat niet.
• Een agentplatform waar verschillende zelfgehoste AI-agents tegelijkertijd het model aanroepen: vLLM, omdat agentverkeer van nature bursty en parallel is.

Foutmodi en de bijbehorende meldingen

vLLM weigert te starten met een KV cache-fout. Het bericht vermeldt beide getallen:

ValueError: To serve at least one request with the model's max seq len (32768), (4.00 GiB KV cache is needed, which is larger than the available KV cache memory (1.00 GiB). Based on the available memory, the estimated maximum model length is 8192. Try increasing `gpu_memory_utilization` (which also controls CPU memory on the CPU backend) or decreasing `max_model_len` when initializing the engine. See https://docs.vllm.ai/en/latest/configuration/conserving_memory/ for more details.

Het model declareert een contextvenster dat groter is dan het geheugen dat beschikbaar is na het laden van de gewichten. Verlaag dit met --max-model-len 8192, of verhoog --gpu-memory-utilization als er niets anders gebruikmaakt van de kaart.

Ollama toont Killed tijdens het genereren. De Linux out-of-memory killer heeft het proces beëindigd omdat het model meer RAM nodig had dan de machine beschikbaar heeft. Bevestig dit met sudo dmesg | grep -i oom. De oplossing is een kleiner of sterker gekwantiseerd model, niet een instelling.

Ollama reageert correct bij enkelvoudig gebruik, maar vertraagt onder belasting. Er verschijnt nergens een foutmelding. Verzoeken duren simpelweg langer naarmate er meer aanroepers zijn, omdat OLLAMA_NUM_PARALLEL=1 deze serialiseert. Lange antwoorden verergeren de wachtrij, aangezien één aanroeper het enige slot bezet houdt totdat het model stopt, wat alle volgende verzoeken blokkeert. Daarom zorgt het beperken van het antwoord met num_predict voor een maximum aan de tijd dat een enkele beurt de server kan bezetten. Verhoog de parallelle instelling en accepteer het extra RAM-verbruik per context-slot, of verplaats de werklast naar vLLM.

vLLM geeft een 401-fout op elke /v1-aanroep. U heeft de service gestart met --api-key en de client stuurt geen Authorization-header mee. De meeste OpenAI-clientbibliotheken sturen de waarde die u als sleutel opgeeft; stel deze daar in in plaats van de vlag te verwijderen.

vLLM meldt dat het model niet is gevonden. Ollama haalt modellen op verzoek binnen, vLLM doet dit niet. Het veld model in de body van het verzoek moet overeenkomen met de repository-id waarmee u de service heeft gestart, of met de waarde van --served-model-name als u deze heeft ingesteld. Controleer de exacte tekenreeks met curl http://localhost:8000/v1/models.

Beide tegelijk draaien is een redelijke oplossing

Ze sluiten elkaar niet uit. Een veelvoorkomende opzet is vLLM op een GPU-instantie voor het bedienen van de applicatie, met Ollama op de reguliere VPS ernaast voor lokale scripts, cron-jobs en het testen van nieuwe model-releases. Beide endpoints zijn OpenAI-compatibel, waardoor één client-library en een wijziging in de base-URL volstaan. Kostenbeheersing is hier belangrijker dan de keuze voor de engine zelf, omdat een inactieve GPU hetzelfde kost als een actieve, en het voorspelbaar houden van agent- en inferentiekosten is een vak apart, los van de keuze voor een server.

FAQ

Is vLLM sneller dan Ollama?

Voor een enkel verzoek op dezelfde GPU is het verschil bescheiden, aangezien beide dezelfde berekeningen uitvoeren. Bij veel gelijktijdige verzoeken loopt vLLM ver vooruit, omdat continuous batching elke actieve sequentie in één forward pass decodeert, terwijl de standaardinstelling van Ollama deze na elkaar uitvoert. Op een systeem met alleen een CPU hebben beide ondersteunde inferentiepaden, waarbij vLLM gebruikmaakt van aparte CPU-wheels.

Kan vLLM zonder GPU draaien?

Ja, via de CPU-backend. De standaard wheels zijn gericht op NVIDIA- of AMD-GPU's, en de reden voor het bestaan van vLLM — het verzadigd houden van een accelerator met gebatchte verzoeken — vervalt op een CPU. Er bestaat een CPU-backend met aparte wheels voor x86 en Arm. Gebruik voor echte CPU-inferentie direct Ollama of llama.cpp.

Wat is het verschil tussen Ollama en llama.cpp?

llama.cpp is de inferentiebibliotheek en GGUF is het bijbehorende formaat voor gekwantiseerde gewichten. Ollama gebruikt dit voor GGUF-inferentie en voegt een modelregister, getagde downloads, modelbeheer en een systemd-unit toe. Ollama levert ook een MLX-engine die op safetensors gebaseerde modellen draait op Apple Silicon en ondersteunt CUDA-builds op Linux, waardoor de twee onderhuids niet altijd identiek zijn.

Hoeveel GPU-geheugen heeft vLLM nodig voor een 8B-model?

Bij 16-bit precisie beslaan de gewichten alleen al ongeveer 16 GB, ruwweg 2 GB per miljard parameters, en de KV-cache heeft daarbovenop extra ruimte nodig. Een kaart van 24 GB is ruim voldoende. Een kaart van 16 GB vereist een gekwantiseerd model, een kleiner model of --cpu-offload-gb om een deel van de gewichten naar het systeem-RAM te verplaatsen, wat ten koste gaat van de snelheid. vLLM claimt een fractie van de kaart die wordt ingesteld via --gpu-memory-utilization, wat per oktober 2026 standaard op 0.92 staat.

Moet ik mijn applicatiecode aanpassen om tussen beide te wisselen?

Meestal alleen de base URL, de API key en de modelnaam. Ollama serveert zijn OpenAI-compatibele interface op http://127.0.0.1:11434/v1 en negeert de key, terwijl vLLM http://localhost:8000/v1 serveert en de key afdwingt op zijn /v1-routes als u er een instelt. De modelnamen verschillen van vorm: llama3.1:8b voor Ollama, en een volledig repository-id zoals Qwen/Qwen2.5-1.5B-Instruct voor vLLM.