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 modellen die het serveert zijn GGUF-bestanden, meestal 4-bit gekwantiseerd, waardoor een 7B- of 8B-model ongeveer 5 GB op schijf inneemt in plaats van 16 GB. Kwantisatie is wat CPU-inferentie überhaupt mogelijk maakt.

De runner is gebouwd op llama.cpp, de C++ inferentie-bibliotheek die GGUF-kwantisatie praktisch maakte op standaardhardware. Ollama heeft sindsdien een eigen engine toegevoegd voor sommige nieuwere modelfamilies, maar llama.cpp vormt nog steeds de basis voor het merendeel van wat het serveert. Wanneer mensen Ollama vergelijken met llama.cpp, vergelijken ze dus grotendeels een ergonomische laag met de software die het omhult.

Het ontwerpdoel is één gebruiker. Sinds juli 2026 is de standaardwaarde voor OLLAMA_NUM_PARALLEL 1, wat betekent dat één model één verzoek tegelijk verwerkt en al het overige in een wachtrij staat die standaard 512 items bevat (OLLAMA_MAX_QUEUE). U kunt de parallelle instelling verhogen, en de onderstaande sectie legt uit wat dit u kost. Als u Ollama nog niet eerder heeft gedraaid, begin dan met Ollama hosten op een VPS en poort 11434 gesloten houden, omdat de API geen enkele vorm van authenticatie heeft.

Wat vLLM precies is

vLLM is een inference-server en niets meer dan dat. Het beheert geen modelbibliotheek, het bevat geen chat-prompt 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 voor elk actief verzoek bijhoudt) op in blokken van vaste grootte, op de manier waarop een besturingssysteem geheugen pagineert. Een verzoek heeft niet langer één grote aaneengesloten reservering nodig die is afgestemd op 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 decoderingsstap aan de lopende batch deel te nemen, 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 het gaan 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 dezelfde hardware bij een server binnenkomen.

Ollama voert met de standaardinstellingen het eerste verzoek volledig uit, daarna het tweede, enzovoort. De vijfde aanvrager moet wachten op vier volledige generaties. De totale doorvoer is ongeveer gelijk aan 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 kostbare 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 prijs hiervoor is geheugen. Elke parallelle slot heeft zijn eigen KV-cache nodig, en Ollama verdeelt het contextvenster over de slots. Hierdoor houden vier parallelle verzoeken bij een model dat is geconfigureerd voor 8192 tokens elk 2048 tokens aan context over. Die 8192 is zelf een keuze in plaats van een vaststaand gegeven, dus het verhogen van num_ctx en het bepalen van het benodigde RAM is de stap die bepaalt of vier slots überhaupt bruikbaar zijn. De paged cache van vLLM voorkomt deze afweging, omdat blokken aan een verzoek worden toegewezen naarmate het verzoek daadwerkelijk groeit. Hoe dan ook, de bovengrens van hoeveel mensen één server tegelijkertijd kan bedienen, wordt bepaald door de KV-cachegrootte, de prefill-kosten en de wachtrijdiepte. Dat is waarom een server die voor één persoon prima aanvoelde, bij vijf personen traag wordt.

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 getoond, is uw werkelijke aantal tokens per seconde op die machine. Vertrouw hierop in plaats van op gepubliceerde cijfers. Eén meting op basis van één prompt is slechts een startpunt en geen capaciteitsgetal. Daarom is het timen van tokens per seconde tijdens een gelijktijdigheidstest de enige manier om te bepalen of de machine standhoudt onder de verwachte belasting, 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 geeft de feitelijke status weer. 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 het model standaard na vijf minuten zonder verzoek wordt verwijderd uit het geheugen. Het model in het geheugen houden tussen verzoeken voorkomt dat de eerste prompt na een uur inactiviteit opnieuw de volledige laadtijd vereist.

Installeren en serveren met vLLM

vLLM vereist Linux en Python 3.10 tot 3.13. Installeer het in een eigen virtuele omgeving, omdat het een specifieke PyTorch-build vereist:

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

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

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

Het opstarten duurt de eerste keer lang, omdat de gewichten worden gedownload en de GPU wordt geprofileerd om te bepalen hoeveel KV-cacheblokken er passen. De service 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 server aanwezig is, voorkomt de officiële image het handmatig oplossen van 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 is vereist, niet optioneel: PyTorch verplaatst tensors tussen processen via gedeeld geheugen, en de standaard Docker-toewijzing voor gedeeld geheugen is te klein 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 (het deel van de kaart dat vLLM mag claimen, standaard 0.92 per juli 2026), --tensor-parallel-size voor het verdelen van één model over meerdere GPU's, en --api-key.

Authenticatie is een vlag op vLLM en ontbreekt op 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 afkomstig zijn van de VLLM_API_KEY omgevingsvariabele. Een verzoek zonder dit token resulteert in een HTTP 401. Dat is nog steeds geen reden om poort 8000 op een publieke interface te publiceren, aangezien vLLM geen rate limiting heeft en een plat HTTP-token leesbaar is tijdens het transport, maar het betekent wel dat de server een concept van een aanroeper heeft.

Ollama heeft dit niet. Er is geen sleutel, geen login, geen allow-list. Elk proces dat 11434 kan bereiken, kan modellen uitvoeren, ophalen of verwijderen. Houd het op loopback en bereik het via een WireGuard VPN die u zelf beheert, 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 kost ongeveer een halve gigabyte aan RAM per miljard parameters, plus ongeveer een gigabyte aan runtime-overhead en extra ruimte voor de context. Een 3B-model vereist dus ongeveer 4 GB vrije ruimte 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 is een beperking van de geheugenbandbreedte, geen onjuiste configuratie, en geen enkele flag lost dit op. 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 serveert ongekwantiseerde gewichten op 16-bit precisie, wat neerkomt op ongeveer 2 GB per miljard parameters: een 8B-model heeft ongeveer 16 GB 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 kiest dan een kleiner model of geeft --quantization mee met een gekwantiseerd checkpoint. Er bestaat een CPU-backend, maar de standaard-wheels zijn hier niet voor gebouwd en het gebruik ervan doet de reden om vLLM te draaien teniet.

De hardwarevraag beantwoordt daarom meestal de softwarevraag. Geen GPU betekent Ollama. Een gehuurde GPU die op 5 procent bezetting blijft hangen 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 start niet vanwege een KV cache-fout. De melding bevat beide getallen:

ValueError: The model's max seq len (32768) is larger than the maximum number of tokens that can be stored in KV cache (8192). Try increasing gpu_memory_utilization or decreasing max_model_len when initializing the engine.

Het model declareert een contextvenster dat groter is dan het geheugen dat overblijft 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. Het pushen van het gebruik tot boven ongeveer 0.95 leidt er vaak toe dat deze opstartfout wordt ingeruild voor een CUDA out-of-memory crash tijdens belasting, wat de ergere van de twee is.

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

Ollama reageert goed bij enkelvoudig gebruik, maar loopt vast 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 die het enige slot bezet houdt totdat het model stopt, iedereen erachter blokkeert. Daarom zorgt het beperken van het antwoord met num_predict voor een maximum aan de tijd die een enkele beurt de server kan bezet houden. Verhoog de parallelle instelling en accepteer de kleinere context per verzoek, of verplaats de werklast naar vLLM.

vLLM geeft een 401-fout bij elk verzoek. U heeft het gestart met --api-key en de client stuurt geen Authorization-header. De meeste OpenAI-clientbibliotheken sturen wat u als sleutel opgeeft, dus stel deze daar in in plaats van de vlag weg te laten.

vLLM meldt dat het model niet is gevonden. Ollama haalt modellen op verzoek binnen, vLLM niet. Het model-veld in de body van het verzoek moet overeenkomen met de repository-id waarmee u het heeft opgestart, of de waarde van --served-model-name als u die heeft ingesteld. Bevestig de exacte string 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?

Bij een enkel verzoek op dezelfde GPU is het verschil klein, aangezien beide dezelfde berekeningen uitvoeren. Bij veel gelijktijdige verzoeken loopt vLLM ver vooruit, omdat continuous batching elke actieve reeks in één forward pass decodeert, terwijl de standaardinstelling van Ollama deze na elkaar uitvoert. Op een machine zonder GPU is de vraag niet relevant: Ollama draait daar wel, maar vLLM in de praktijk niet.

Kan vLLM draaien zonder GPU?

Niet op een zinvolle manier. 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 voor ontwikkeldoeleinden. Gebruik voor daadwerkelijke 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. De runner van Ollama is hierop gebouwd en voegt de onderdelen toe die llama.cpp aan de gebruiker overlaat: een modelregister, automatische downloads, een resident server, een systemd-unit en een OpenAI-compatibel endpoint. Ollama heeft voor sommige nieuwere modelfamilies een eigen engine toegevoegd, waardoor de twee onderhuids niet langer identiek zijn.

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

Bij 16-bit precisie nemen de gewichten alleen al ongeveer 16 GB in beslag, ruwweg 2 GB per miljard parameters, en de KV-cache heeft daarbovenop nog ruimte nodig. Een kaart met 24 GB is comfortabel. Een kaart met 16 GB vereist een gekwantiseerd checkpoint of een kleiner model. vLLM claimt een fractie van de kaart zoals ingesteld door --gpu-memory-utilization, wat per juli 2026 standaard op 0.92 staat.

Moet ik mijn applicatiecode aanpassen om tussen beide te wisselen?

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