Ollama of vLLM: welke LLM-server past bij u?

Ollama versus vLLM in één alinea

Ollama is een modelbeheerder met een gekoppelde server: deze downloadt gekwantiseerde gewichten, laadt ze en beantwoordt verzoeken op 127.0.0.1:11434, met een CPU als dat het enige onderdeel is waarover de machine beschikt. vLLM is een engine voor doorvoer: deze houdt een GPU volledig bezet met veel gelijktijdig actieve verzoeken. Het is het verkeerde hulpmiddel voor een machine zonder GPU. Dat is de volledige keuze. Eén persoon die met een lokale assistent praat, is een Ollama-taak. Een applicatie die een team bedient, is een vLLM-taak.

Beide bieden een OpenAI-compatibele HTTP API. Daardoor kan clientcode tussen beide worden overgezet door alleen de base URL te wijzigen. De API is niet het verschil. Het verschil is wat er gebeurt wanneer een tweede verzoek binnenkomt terwijl het eerste nog tokens genereert.

Wat Ollama werkelijk is

Ollama is een gebruiksvriendelijke laag. Met één installatieopdracht krijgt u een modelregister (ollama pull llama3.1:8b), een lokale opslag voor gewichten, een chatprompt, een systemd-service en een HTTP API. De modellen die deze service aanbiedt, zijn GGUF-bestanden, meestal gekwantiseerd naar 4 bits. Daarom neemt een 7B- of 8B-model ongeveer 5 GB schijfruimte in beslag in plaats van 16 GB. Kwantisatie maakt inferentie op de CPU überhaupt mogelijk.

De runner is gebaseerd op llama.cpp, de C++-inferentiebibliotheek die GGUF-kwantisatie praktisch maakte op standaardhardware. Ollama heeft sindsdien een eigen engine toegevoegd voor enkele nieuwere modelfamilies, maar llama.cpp vormt nog steeds de basis van het grootste deel van wat Ollama aanbiedt. Wanneer mensen Ollama met llama.cpp vergelijken, vergelijken ze dus meestal een gebruiksvriendelijke laag met de onderliggende software die deze laag gebruikt.

Het ontwerp is gericht op één gebruiker. Vanaf juli 2026 is de standaardwaarde voor OLLAMA_NUM_PARALLEL 1. Dat betekent dat één model één verzoek tegelijk verwerkt en dat alle overige verzoeken wachten in een wachtrij die standaard 512 vermeldingen bevat (OLLAMA_MAX_QUEUE). U kunt de instelling voor parallelle verwerking verhogen. In het onderstaande gedeelte wordt uitgelegd wat dit kost. Als u Ollama nog niet eerder hebt uitgevoerd, begint u met Ollama hosten op een VPS en poort 11434 gesloten houden, omdat de API geen enkele vorm van authenticatie gebruikt.

Wat vLLM daadwerkelijk is

vLLM is uitsluitend een inference-server. Het beheert geen modelbibliotheek, heeft geen chatprompt en haalt tijdens een aanvraag geen model voor u op. U geeft bij het starten een Hugging Face-repository op. vLLM laadt dat ene model en serveert het totdat u het proces stopt.

Deze beperkte opzet levert een hoge doorvoer op. Twee mechanismen zorgen daarvoor. PagedAttention slaat de KV-cache (key-value-cache, de aandachtsstatus per token die een model voor elke actieve aanvraag bijhoudt) op in blokken met een vaste grootte, vergelijkbaar met hoe een besturingssysteem geheugen pagineert. Een aanvraag heeft daardoor geen grote, aaneengesloten reservering meer nodig die is afgestemd op het slechtste geval. Geheugen dat eerder gereserveerd maar ongebruikt bleef, komt beschikbaar voor meer gelijktijdige aanvragen. Continuous batching laat een nieuwe aanvraag bij de volgende decodeerstap aan de actieve batch deelnemen, in plaats van te wachten totdat de huidige batch is voltooid. Een voltooide reeks verlaat de batch onmiddellijk en de vrijgekomen plaats wordt opnieuw gebruikt.

Het praktische resultaat: op 1 GPU stijgt de totale tokens-per-seconde-doorvoer sterk wanneer u van 1 gelijktijdige gebruiker naar 30 gaat, terwijl de snelheid per gebruiker veel minder afneemt dan u zou verwachten. Met de standaardinstellingen van Ollama zorgt een overgang van 1 gebruiker naar 30 er alleen voor dat 29 mensen wachten.

Continue batching is het volledige verschil

Stel u voor dat vijf aanvragen op hetzelfde moment bij elke server binnenkomen op identieke hardware.

Ollama verwerkt met de standaardinstellingen aanvraag een volledig en begint daarna aan aanvraag twee, enzovoort. De vijfde aanroeper wacht totdat vier volledige generaties zijn voltooid. De totale doorvoer is ongeveer de snelheid van één generatie, omdat de processor steeds slechts aan één reeks werkt.

vLLM decodeert alle vijf in dezelfde forward pass. Het genereren van één token voor vijf reeksen kost nauwelijks meer dan het genereren van één token voor één reeks, omdat het dure deel het lezen van de modelgewichten uit het geheugen is en die leesbewerking voor de hele batch wordt gedeeld. Dit is hetzelfde feit over geheugenbandbreedte waardoor CPU-inferentie traag is: u betaalt voor het verplaatsen van gewichten, niet voor de berekeningen.

U kunt OLLAMA_NUM_PARALLEL=4 instellen en een deel van dit effect bereiken. Daarvoor is geheugen nodig. Elke parallelle sleuf heeft een eigen KV-cache nodig. Ollama verdeelt het contextvenster over de sleuven. Vier parallelle aanvragen voor een model dat is geconfigureerd voor 8192 tokens laten daardoor voor elke aanvraag 2048 tokens context over. De gepagineerde cache van vLLM voorkomt deze afweging. Blokken worden toegewezen aan een aanvraag naarmate die aanvraag daadwerkelijk groeit.

Installeren en beschikbaar maken 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 systeemgebruiker ollama aan, installeert het binaire bestand en registreert ollama.service, dat gebonden is aan 127.0.0.1:11434. De regel eval rate die door --verbose wordt weergegeven, is het werkelijke aantal tokens per seconde op die machine. Vertrouw hierop en niet op gepubliceerde cijfers.

Gebruik een systemd drop-in om de gelijktijdigheid te verhogen, zodat een upgrade deze 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 is geladen en de kolom PROCESSOR geeft de werkelijke waarde weer. 100% CPU betekent dat er geen GPU wordt gebruikt. Dat is de juiste verklaring voor de meeste meldingen dat Ollama traag is.

Installeren en uitvoeren met vLLM

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

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

Voer vervolgens een model uit. De naam is een repository-ID van Hugging Face, geen korte tag:

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

De eerste keer duurt het opstarten lang, omdat de gewichten worden gedownload en vervolgens de GPU wordt geprofileerd om te bepalen hoeveel KV-cacheblokken 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 staat, voorkomt de officiële image het werk voor de CUDA-afhankelijkheid:

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 en niet alleen voor de vorm: PyTorch geeft tensors via shared memory door tussen processen, en de standaardtoewijzing van shared memory in Docker is te klein voor inference met tensor parallelism.

De belangrijkste flags in productie zijn --max-model-len (het contextvenster waarvoor u wilt betalen), --gpu-memory-utilization (het deel van de GPU dat vLLM mag gebruiken, standaard 0.92 vanaf juli 2026), --tensor-parallel-size om één model over meerdere GPU's te verdelen, en --api-key.

Verificatie is één vlag in vLLM en ontbreekt in Ollama

vLLM vereist een bearer-token als u dit opgeeft:

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

Dezelfde waarde kan afkomstig zijn uit de omgevingsvariabele VLLM_API_KEY. Een verzoek zonder deze waarde krijgt HTTP 401. Dat is nog steeds geen reden om poort 8000 op een openbare interface beschikbaar te maken. vLLM heeft namelijk geen snelheidsbeperking en een token via gewoon HTTP kan tijdens het transport worden uitgelezen. De server heeft daardoor wel een concept van een aanroeper.

Ollama heeft dit niet. Er is geen sleutel, geen aanmelding en geen allow-list. Elk proces dat 11434 kan bereiken, kan modellen uitvoeren, ophalen of verwijderen. Houd de service op loopback en bereik deze via een WireGuard-VPN die u zelf host, of via een reverse proxy die authenticatie uitvoert en TLS (Transport Layer Security) beëindigt.

Hardware: wat elke optie nodig heeft

Ollama draait op de CPU. Een 4-bit gekwantiseerd model gebruikt ongeveer een halve gigabyte RAM per miljard parameters, plus ongeveer een gigabyte runtime-overhead en extra geheugen voor de context. Een 3B-model heeft daarom ongeveer 4 GB vrije ruimte nodig en een 8B-model ongeveer 8 GB. De snelheid op een gedeelde vCPU ligt tussen enkele en lage dubbele cijfers tokens per seconde. Dit wordt veroorzaakt door de geheugenbandbreedte, niet door een verkeerde configuratie. Geen enkele flag lost dit op.

vLLM gaat uit van een GPU. Het standaardpad serveert niet-gekwantiseerde gewichten met 16-bit precisie. Dat is ongeveer 2 GB per miljard parameters. Een 8B-model heeft daardoor alleen voor de gewichten al ongeveer 16 GB videogeheugen nodig, nog vóór de KV-cache die nodig is voor de gelijktijdige verwerking waarvoor u vLLM hebt geïnstalleerd. Op een kaart van 24 GB blijft dan een bruikbare cache over. Op een kaart van 16 GB is dat niet het geval. U kiest dan een kleiner model of geeft --quantization door met een gekwantiseerd checkpoint. Er bestaat een CPU-backend, maar de standaardwheels zijn daarvoor niet gebouwd. Bovendien vervalt daarmee de reden om vLLM te gebruiken.

De hardwarevraag beantwoordt daarom meestal ook de softwarevraag. Geen GPU betekent Ollama. Een gehuurde GPU die op 5 procent benutting draait omdat aanvragen sequentieel worden verwerkt, betekent vLLM.

Welke optie voor uw workload

• Eén persoon, een CPU-VPS, opstellen en samenvatten: Ollama. De snelheid is acceptabel en niets anders is eenvoudiger.
• Een programmeerassistent of een MCP-server die uw tools met een lokaal model verbindt die alleen door u wordt aangeroepen: Ollama. Een gelijktijdige aanroep is de werkelijke workload.
• Deze week vijf modellen vergelijken: Ollama. Getagde modellen ophalen en verwijderen is precies waar Ollama goed in is, terwijl vLLM voor elk model een procesrestart vereist.
• Een interne app, een chatproduct of een retrieval-pipeline met echte gebruikers: vLLM. Hier rechtvaardigt batching de GPU-kosten.
• Een batchtaak die 's nachts honderdduizend documenten beoordeelt: vLLM, met een hoge --max-num-seqs. Doorvoer is de enige relevante metriek; latentie per document is dat niet.
• Een agentplatform waarop meerdere zelf-gehoste AI-agents het model tegelijk aanroepen: vLLM, omdat agentverkeer van nature bursty en parallel is.

Foutscenario's, met de meldingen die u ziet

vLLM weigert te starten met een KV-cachefout. De melding bevat beide waarden:

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 nadat de gewichten zijn geladen. Verlaag dit met --max-model-len 8192, of verhoog --gpu-memory-utilization als niets anders de kaart gebruikt. Als u de benutting boven ongeveer 0.95 verhoogt, wordt deze opstartfout meestal vervangen door een CUDA-fout wegens onvoldoende geheugen tijdens de belasting. Dat is de ernstigste van de twee.

Ollama geeft Killed weer tijdens het genereren. De Linux Out-of-Memory Killer heeft het proces gestopt omdat het model meer RAM nodig had dan op de server beschikbaar is. Controleer dit met sudo dmesg | grep -i oom. De oplossing is een kleiner of sterker gekwantiseerd model, niet een instelling.

Ollama geeft zelfstandig goede antwoorden, maar loopt vast onder belasting. Er verschijnt nergens een foutmelding. Aanvragen duren eenvoudigweg langer naarmate er meer aanroepers zijn, omdat OLLAMA_NUM_PARALLEL=1 ze sequentieel verwerkt. Verhoog deze waarde en accepteer de kleinere context per aanvraag, of verplaats de werklast naar vLLM.

vLLM geeft bij elke aanroep 401 terug. U bent gestart met --api-key, maar de client verzendt geen Authorization-header. De meeste OpenAI-clientbibliotheken verzenden de waarde die u als sleutel opgeeft. Stel de sleutel daar in, in plaats van de vlag te verwijderen.

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

Beide uitvoeren is een redelijke oplossing

Ze sluiten elkaar niet uit. Een gebruikelijke opzet is vLLM op een GPU-instantie voor de applicatie, met Ollama op de gewone VPS ernaast voor lokale scripts, cron-taken en het uitproberen van nieuwe modelreleases. Beide endpoints zijn compatibel met de OpenAI-API. Daarom volstaan één clientbibliotheek en een wissel van de base-URL. Kostenbeheersing is hier belangrijker dan de keuze tussen beide engines, omdat een inactieve GPU hetzelfde kost als een GPU die actief wordt gebruikt. Bovendien is de kosten voor agents en inferentie voorspelbaar houden een afzonderlijke discipline van het kiezen van een server.

FAQ

Is vLLM sneller dan Ollama?

Voor één aanvraag op dezelfde GPU is het verschil beperkt, omdat beide dezelfde berekeningen uitvoeren. Bij veel gelijktijdige aanvragen loopt vLLM ver voor, omdat continuous batching elke actieve reeks in één forward pass decodeert, terwijl de standaardconfiguratie van Ollama deze na elkaar uitvoert. Op een machine zonder GPU is deze vraag niet van toepassing: Ollama werkt daar wel, maar vLLM praktisch niet.

Kan vLLM zonder GPU worden uitgevoerd?

Niet op een zinvolle manier. De standaardwheels zijn bedoeld voor NVIDIA- of AMD-GPU's. De reden waarom vLLM bestaat, namelijk een accelerator volledig benutten met gebatchte aanvragen, vervalt op een CPU. Er is een CPU-backend beschikbaar voor ontwikkelwerk. Gebruik voor echte CPU-inferentie rechtstreeks Ollama of llama.cpp.

Wat is het verschil tussen Ollama en llama.cpp?

llama.cpp is de inferentiebibliotheek en GGUF is de indeling voor de gekwantiseerde gewichten. De runner van Ollama is hierop gebaseerd en voegt de onderdelen toe die u bij llama.cpp zelf moet beheren: een modelregister, automatische downloads, een permanente server, een systemd-unit en een OpenAI-compatibel endpoint. Ollama heeft voor sommige nieuwere modelfamilies een eigen engine toegevoegd. Daardoor zijn beide onderliggend niet meer identiek.

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

Bij een precisie van 16 bits nemen alleen de gewichten ongeveer 16 GB in beslag, ongeveer 2 GB per miljard parameters. Daarnaast is ruimte nodig voor de KV-cache. Een kaart van 24 GB biedt voldoende ruimte. Voor een kaart van 16 GB is een gekwantiseerd checkpoint of een kleiner model nodig. vLLM gebruikt een fractie van het kaartgeheugen die wordt ingesteld met --gpu-memory-utilization. Vanaf July 2026 is de standaardwaarde 0.92.

Moet ik de code van mijn applicatie aanpassen om tussen beide te wisselen?

Meestal hoeft u alleen de basis-URL, de API-sleutel en de modelnaam aan te passen. Ollama biedt zijn OpenAI-compatibele interface aan op http://127.0.0.1:11434/v1 en negeert de sleutel. vLLM biedt deze aan op http://localhost:8000/v1 en controleert de sleutel als u er een instelt. De modelnamen hebben een verschillende vorm: llama3.1:8b voor Ollama en een volledige repository-id, zoals Qwen/Qwen2.5-1.5B-Instruct, voor vLLM.