Ollama of llama.cpp op een VPS: welke kiest u?

Ollama versus llama.cpp: welke laag wilt u draaien?

Ollama en llama.cpp zijn geen concurrenten op de manier die de vraag suggereert. llama.cpp is de inference-engine: deze laadt een modelbestand en zet een prompt om in tokens. Ollama is een modelbeheerder, een achtergrond-daemon en een HTTP API die boven op die engine draait. De README van Ollama vermeldt nog steeds llama.cpp als de inference-backend (gecontroleerd op 2 augustus 2026). De werkelijke vraag is dus op welke laag u op uw VPS wilt werken, niet welke sneller is.

Gebruik Ollama wanneer u een service wilt die modellen op naam ophaalt en zonder toezicht blijft werken. Gebruik llama.cpp direct wanneer de server klein is en u het exacte modelbestand, de exacte contextgrootte en het exacte aantal threads moet kiezen, omdat op een kleine VPS elk van die instellingen geheugen kost dat u niet heeft.

Wat elk project precies is

llama.cpp is een C- en C++-implementatie van transformer-inference, gebouwd op de ggml-bibliotheek. Het leest GGUF-bestanden. GGUF (GGML universal file format) is een containerbestand dat de gewichten, de tokenizer en de metadata bevat die de engine nodig heeft om het model uit te voeren. Het project levert afzonderlijke binaries voor verschillende taken. llama-server is een HTTP-server, llama-cli is een interactieve prompt en llama-bench meet de doorvoer. Releases worden gelabeld met een buildnummer in plaats van met semantische versiebeheer. De huidige tag is b10224, gepubliceerd op 2 augustus 2026, en op de meeste werkdagen verschijnt er een nieuwe tag.

Ollama is een Go-programma. Een achtergrond-daemon, gestart met ollama serve, laadt modellen en beantwoordt HTTP-verzoeken, en een command-line client communiceert met die daemon. Achter beide bevindt zich een register op ollama.com dat voorverpakte modellen bevat. Ollama gebruikt semantische versies en v0.32.5 werd uitgebracht op 27 juli 2026. ollama pull haalt een GGUF op, samen met een prompt-template en een set standaardparameters, en slaat deze op onder /usr/share/ollama/.ollama/models op Linux. Deze bestanden staan op de root-schijf en zijn elk enkele gigabytes groot. Op een VPS met een root-volume van 25 GB is het daarom nuttig om te weten wat pull achterlaat en hoe u de modeldirectory naar een andere locatie verplaatst voordat de derde download de schijf vult.

Die verpakking is het enige verschil. Ollama bepaalt de kwantisatie, de template en de contextlengte voor u, en geeft u één naam om te onthouden. llama.cpp bepaalt niets en geeft u vlaggen.

As 1: controle over model en kwantisatie

Kwantisatie verkleint elk gewicht van 16 of 32 bits naar 4, 5 of 8 bits. Dit zorgt ervoor dat een model met 8 miljard parameters in het RAM-geheugen van een standaard VPS past. De GGUF-naamgeving is leesbaar zodra u het patroon kent: Q4_K_M staat voor 4-bit K-kwantisatie, medium grootte. Een hoger getal behoudt meer precisie en vereist meer geheugen.

[
  {
    "label": "Q2_K",
    "file_size_gib": 2.96
  },
  {
    "label": "Q3_K_M",
    "file_size_gib": 3.74
  },
  {
    "label": "Q4_K_M",
    "file_size_gib": 4.58
  },
  {
    "label": "Q5_K_M",
    "file_size_gib": 5.34
  },
  {
    "label": "Q6_K",
    "file_size_gib": 6.14
  },
  {
    "label": "Q8_0",
    "file_size_gib": 7.95
  }
]

Dit zijn de gepubliceerde bestandsgroottes in de bartowski/Meta-Llama-3.1-8B-Instruct-GGUF-repository op Hugging Face, geraadpleegd op 2 augustus 2026 en omgerekend van bytes naar GiB. 6 builds van één model, waarbij de kleinste 2.96 GiB is tegenover 7.95 GiB voor de grootste. De gebruikelijke standaard, Q4_K_M, is 4.58 GiB. Op een VPS van 4 GiB bepaalt die enkele keuze of het model überhaupt laadt. Grootte is slechts de helft van die beslissing, omdat een rij die u kunt betalen niet automatisch een rij is die het waard is om te gebruiken, en wat Q4, Q8 en fp16 u werkelijk kosten aan antwoordkwaliteit vertelt u of de extra gigabytes iets opleveren wat u zou merken.

Bij llama.cpp benoemt u het bestand zelf, dus u kiest die rij zelf.

llama-server -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 --host 127.0.0.1 --port 8080

-c is de contextgrootte in tokens, -t is het aantal threads en -ngl bepaalt hoeveel lagen naar een GPU worden verplaatst (0 op een systeem zonder GPU). Niets wordt voor u gegokt.

Bij Ollama gaat de kwantisatie mee met de tag die u ophaalt, en ollama ls toont wat u daadwerkelijk op schijf heeft staan. Wanneer de registry de build die u wilt niet bevat, importeert u zelf een GGUF. Schrijf een Modelfile:

FROM ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 4096

Bouw deze vervolgens en controleer het resultaat:

ollama create llama31-q4 -f ./Modelfile
ollama ls

Contextlengte is de instelling waar mensen vaak tegenaan lopen. Ollama kiest de standaardwaarde op basis van het beschikbare VRAM, en een systeem zonder GPU valt in de kleinste categorie: 4096 tokens. Stuur een document van 20.000 tokens en de extra tokens worden verwijderd voordat het model ze ooit ziet, waardoor het antwoord vol vertrouwen onjuist is over een bestand dat het slechts voor de helft heeft gelezen. Verhoog dit met OLLAMA_CONTEXT_LENGTH op de daemon, of met PARAMETER num_ctx in een Modelfile. Als slechts één taak het grotere venster nodig heeft, kan num_ctx per verzoek worden ingesteld in plaats van serverbreed, wat de extra cache buiten alles houdt wat de daemon verder moet verwerken. llama.cpp heeft ook geen standaardwaarde die het vertrouwen waard is. Stel -c expliciet in en weet wat u instelt.

De geheugenberekening die niemand u laat zien

Het modelbestand is niet de enige kostenpost. De KV cache (key/value cache) bevat één item per laag per token aan context, en deze groeit naarmate het gesprek vordert.

Reken dit uit voor Llama 3.1 8B. Het model heeft 32 lagen, 8 key/value heads en een head-dimensie van 128. Elk token slaat zowel een key als een value op van 2 bytes per stuk in f16, dus 2 x 8 x 128 x 2 = 4096 bytes per laag. Over 32 lagen is dat 128 KiB per token. Een context van 4096 tokens kost daarom 512 MiB, en een context van 32.768 tokens kost 4 GiB.

Een Q4_K_M 8B model met een context van 4k heeft dus ongeveer 4.58 GiB nodig voor de gewichten, plus ongeveer 0,5 GiB aan cache, plus de runtime zelf. Het past niet in 4 GiB RAM. Het past in 8 GiB met voldoende werkruimte. Verhoog de context naar 32k op diezelfde 8 GiB machine en de cache alleen al verbruikt de volledige marge. Monitor dit live met free -h terwijl het model wordt geladen, en vertrouw niet op een schatting die u niet zelf heeft gemeten. Als u de capaciteit berekent voor iets dat aanzienlijk groter is dan 8B, laat dezelfde berekening, toegepast op een 27B model op een CPU-only VPS, zien wat elk niveau van 8 tot 64 GB daadwerkelijk kan bevatten.

Ollama vermenigvuldigt dit. OLLAMA_NUM_PARALLEL staat standaard op 1, en het geheugen dat een model nodig heeft schaalt met dat getal vermenigvuldigd met de contextlengte. Verhoog beide tegelijk en de daemon vraagt stilletjes om een veelvoud van het RAM dat u verwachtte. Diezelfde berekening bepaalt uw plafond voor gelijktijdige gebruikers, omdat elk gelijktijdig verzoek zijn eigen deel van de KV cache vereist, wat verklaart waarom een server die prima werkt voor één persoon, vastloopt bij vijf.

As 2: de daemon die u moet beheren

Het installatiescript van Ollama schrijft een systemd-unit, maakt een ollama systeemgebruiker aan en schakelt de service in. U krijgt lifecycle-beheer zonder dat u zelf iets hoeft te schrijven. Configuratie verloopt via systemd:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -e -u ollama

OLLAMA_KEEP_ALIVE is op een CPU VPS belangrijker dan waar dan ook. Modellen worden standaard 5 minuten in het geheugen gehouden en daarna ontladen. Het volgende verzoek moet het volledige bestand teruglezen van de schijf voordat het kan antwoorden, dus een 4.58 GiB herlaadactie verandert een reactie van twee seconden in een reactie van dertig seconden op trage opslag. Een lange keep-alive lost de latentie op en verbruikt permanent het RAM-geheugen. Beide zijn reële kosten. Kies de optie die het minst nadelig is. Als u besluit dat het model permanent in het geheugen moet blijven, kost het instellen van keep_alive zodat het inactieve periodes en reboots overleeft slechts een paar regels en bespaart het u het handmatig opwarmen van het model telkens wanneer de server herstart.

llama.cpp biedt geen daemon, dus u schrijft de unit zelf als /etc/systemd/system/llama-server.service:

[Unit]
Description=llama.cpp server
After=network-online.target

[Service]
ExecStart=/usr/local/bin/llama-server -m /srv/models/model-Q4_K_M.gguf -c 4096 -t 4 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=3
User=llama

[Install]
WantedBy=multi-user.target

Schakel deze in met sudo systemctl enable --now llama-server. Het proces houdt het model vervolgens gedurende de gehele levensduur vast. Niets wordt ontladen bij inactiviteit, wat betekent dat er geen verrassingen zijn bij het herladen en er geen manier is om het geheugen vrij te maken, behalve door de service te stoppen. Als het schrijven van units nieuw voor u is, volgt dit hetzelfde patroon als het draaien van uw eigen services onder systemd op een VPS.

As 3: de API waarmee uw applicatie communiceert

Dit as is aanzienlijk nauwer geworden. Beide projecten ondersteunen nu het OpenAI-chatformaat, waardoor de meeste clientbibliotheken met beide werken na het aanpassen van enkel de base URL.

Ollama luistert op 127.0.0.1:11434. De OpenAI-compatibele route is http://localhost:11434/v1/chat/completions, en daarnaast blijft een native API beschikbaar op /api/chat. Ook een Anthropic-compatibele route is gedocumenteerd.

curl -X POST http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama31-q4", "messages": [{"role": "user", "content": "Say this is a test"}]}'

llama-server luistert op 127.0.0.1:8080 en bedient /v1/chat/completions, /v1/completions en /v1/embeddings, naast een eigen /completion-endpoint en een ingebouwde web-UI. Het stelt ook operationele routes beschikbaar die Ollama niet heeft: /health voor een readiness probe, /props voor de instellingen van het geladen model, /slots voor de status van elk request-slot, en /metrics in Prometheus-formaat. Als u van plan bent deze service te monitoren, is dat verschil waarschijnlijk doorslaggevend.

Geen van beide servers schakelt automatisch authenticatie in. Beide luisteren standaard op loopback, en dat is met een goede reden. Benader ze via een SSH-tunnel of vanachter een reverse proxy, en stel poort 11434 of 8080 nooit open naar het internet.

Wat een VPS zonder GPU daadwerkelijk kan

Een VPS die alleen op CPU draait, voert kleine modellen traag uit. Dat is de eerlijke samenvatting, en het nuttige deel is weten waar de grens ligt. Meet dit voordat u er een ontwerp op baseert:

llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128

De kolom pp staat voor de verwerkingssnelheid van prompts en de kolom tg voor de generatiesnelheid van tokens, beide in tokens per seconde. Op een plan met gedeelde vCPU haalt een 8B-model in Q4_K_M meestal een snelheid van enkele tokens per seconde voor tg. De verwerking van de prompt is het knelpunt: de volledige prompt wordt verwerkt voordat het eerste output-token verschijnt, dus een lange systeemprompt zorgt bij elk verzoek voor een wachttijd. De lengte van het antwoord is het deel van de rekensom dat u daadwerkelijk kunt beheersen; bij drie tokens per seconde houdt een model dat 600 tokens genereert de server drie minuten bezet. Daarom is het beperken van de output met num_predict de goedkoopste manier om te voorkomen dat één langdradig antwoord tot een time-out leidt.

Bruikbaar op CPU: een 1B tot 4B-model voor classificatie, extractie, korte samenvattingen of routing. Antwoorden verschijnen binnen enkele seconden en het geheugengebruik past binnen een standaard plan. Voor een uitgewerkt voorbeeld op dat formaat in plaats van een bereik, biedt Nemotron 3.5 Lightning opgehaald en gemeten op een VPS de exacte tag, het werkelijke RAM-gebruik en de snelheid zonder GPU. Niet bruikbaar op CPU: interactieve chat op leessnelheid, code-assistenten, werk met lange documenten of taken met een agent-loop die veel opeenvolgende aanroepen doet. Een loop die twaalf aanroepen van elk vier seconden doet, heeft een minuut nodig voordat er resultaat is. Als een code-assistent toch het plan was, zet het koppelen van een agent aan een zelfgehost model uiteen welke taken een klein lokaal model daadwerkelijk aankan en welke taken op een gehoste API moeten blijven.

Er zijn twee uitwegen wanneer de cijfers niet voldoen. Als het probleem gelijktijdigheid is, waarbij veel gebruikers tegelijkertijd een model aanroepen, verandert de keuze van de engine, en de vergelijking van Ollama tegenover vLLM voor gelijktijdige bediening behandelt dat onderwerp. Als het probleem de pure snelheid is, is het antwoord een VPS met een gekoppelde GPU, waarbij -ngl pas echt relevant wordt. Bepaal voor beide opties eerst een baseline voor de hardware zelf, omdat schijf- en geheugenbandbreedte de laadtijd net zozeer bepalen als de CPU. Een reproduceerbare VPS-benchmark is het uur werk waard.

Installatie van llama.cpp, vastgezet op een specifieke build

Beide projecten worden wekelijks bijgewerkt, dus noteer de versie die u heeft geïmplementeerd. De one-liner van de ontwikkelaar installeert de huidige build:

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

Om een specifieke build vast te zetten, gebruikt u in plaats daarvan het vooraf gecompileerde tarball-bestand van de releases-pagina. Build b10224 is de huidige tag per 2 augustus 2026:

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10224/llama-b10224-bin-ubuntu-x64.tar.gz
tar xf llama-b10224-bin-ubuntu-x64.tar.gz
find . -type f -name 'llama-server'

Of compileer diezelfde tag vanuit de broncode:

sudo apt update && sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10224
cmake -B build
cmake --build build --config Release -j $(nproc)

libssl-dev is de gedocumenteerde afhankelijkheid voor de HTTPS-functies. Het compileren duurt enkele minuten en vereist meer RAM dan de kleinste abonnementen bieden; compileer daarom op een grotere machine en kopieer de binaries als de kleine machine onvoldoende geheugen heeft.

Ollama installeren, vastgezet op een specifieke versie

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.5 sh
ollama -v

Het script leest OLLAMA_VERSION, zodat u een bekende, werkende release kunt vasthouden in plaats van de versie te installeren die vanochtend is uitgebracht. v0.32.5 werd gepubliceerd op 27 juli 2026. Er is ook een handmatige methode als u liever geen script naar een shell pipe:

sudo rm -rf /usr/lib/ollama
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr
ollama -v

De handmatige route maakt de systemd-unit of de service-gebruiker niet aan, dus deze moet u zelf toevoegen. De volledige walkthrough voor Ollama op een VPS behandelt deze service-configuratie stap voor stap.

Foutmodi en de meldingen die u zult zien

Ollama weigert het model te laden. ollama run geeft een regel terug in deze vorm:

Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)

Ollama controleert de grootte vóór het laden, dus het proces faalt direct met een duidelijke reden. Stap over naar een lagere kwantisatierij, verlaag de contextlengte of kies een kleiner model.

llama.cpp faalt niet, maar werkt extreem traag. llama.cpp gebruikt standaard memory-mapping voor het GGUF-bestand, waardoor een bestand dat groter is dan het RAM-geheugen toch opstart. De kernel wisselt vervolgens bij elke token gewichten in en uit het geheugen vanaf de schijf, waardoor de generatiesnelheid daalt naar seconden per token en de schijfbelasting op 100 procent blijft staan. Gebruik --no-mmap om een daadwerkelijke toewijzing af te dwingen, zodat het proces direct faalt in plaats van in prestaties af te nemen. Wanneer de kernel ingrijpt, toont dmesg de reden:

Out of memory: Killed process 1234 (llama-server)

Het modelbestand laadt helemaal niet. Een GGUF die is gebouwd voor een modelfamilie die nieuwer is dan uw engine, geeft een foutmelding met de naam van de onbekende architectuur:

error loading model architecture: unknown model architecture: 'qwen3next'

De oplossing is een upgrade van de engine, niet een ander bestand. Dit is het gevolg van het vastzetten van versies (pinning), en daarom is het belangrijk om het buildnummer te noteren. U moet weten vanaf welke versie u upgradet.

De API antwoordt lokaal, maar niet vanuit uw applicatie. Ollama bindt aan 127.0.0.1:11434, waardoor een andere host een 'connection refused'-fout krijgt. Stel OLLAMA_HOST=0.0.0.0:11434 in via systemctl edit ollama alleen wanneer de poort zich achter een firewall of een privénetwerk bevindt, omdat de API zelf geen authenticatie bevat.

Het eerste antwoord na een pauze is erg traag. De automatische unload na 5 minuten inactiviteit heeft plaatsgevonden en het model wordt opnieuw vanaf de schijf gelezen. ollama ps uitgevoerd vlak voor het verzoek toont dat er niets geladen is, wat dit bevestigt. Verhoog OLLAMA_KEEP_ALIVE.

Welke optie moet u gebruiken?

Gebruik Ollama wanneer u wilt dat modellen voor u worden beheerd en u een OpenAI-compatibel eindpunt wilt zonder extra configuratie. Dit is de juiste standaardkeuze voor een eerste implementatie en voor situaties waarin de keuze voor een model regelmatig verandert.

Gebruik llama.cpp direct wanneer het geheugen zo beperkt is dat u zelf de kwantisatierij moet kiezen, wanneer u /health, /slots en /metrics nodig heeft voor monitoring, of wanneer u een flag nodig heeft die Ollama niet ondersteunt. Dit is de meest transparante keuze op een VPS waar het model nauwelijks in het geheugen past, omdat de instellingen die dit mogelijk maken exact de instellingen zijn die Ollama anders voor u zou kiezen.

Het is gebruikelijk om beide te draaien. Ollama voor experimenten, llama.cpp voor het specifieke model dat u in productie neemt en dat niet meer gewijzigd hoeft te worden.

FAQ

Is Ollama slechts een wrapper rondom llama.cpp?

Bijna, maar de wrapper verricht daadwerkelijk werk. De README van Ollama vermeldt llama.cpp als de inference-backend (gecontroleerd op 2 augustus 2026). Daarbovenop voegt Ollama een modelregister toe, de prompt-template die chatberichten omzet in een prompt, een set standaard sampling-parameters, een daemon die inactieve modellen uit het geheugen verwijdert en een HTTP API. Wanneer u tokens per seconde vergelijkt bij identieke instellingen, vergelijkt u in feite dezelfde engine met zichzelf. Waar u daadwerkelijk tussen kiest, is de beheerlaag.

Wat is sneller op een VPS zonder GPU?

Ze delen dezelfde engine, dus bij hetzelfde modelbestand, dezelfde kwantisatie, contextgrootte en het aantal threads liggen de prestaties dicht bij elkaar. Verschillen die gebruikers rapporteren, komen meestal voort uit verschillende standaardinstellingen, vaker de contextlengte en het aantal threads dan de engine zelf. Meet het met llama-bench -m <file> -p 512 -n 128 en vergelijk de tg-kolom op uw eigen systeem voordat u gepubliceerde cijfers gelooft.

Kan ik mijn eigen GGUF-bestand gebruiken met Ollama?

Ja. Plaats het bestand op de server, schrijf een Modelfile waarvan de eerste regel FROM ./your-model.gguf is, voeg eventuele PARAMETER-regels toe die u nodig heeft, zoals num_ctx, en voer vervolgens ollama create your-name -f ./Modelfile uit. ollama ls zal het bestand tonen naast alles wat u uit het register heeft opgehaald. Dit is de manier om een kwantisatie te gebruiken die niet in het register staat.

Hoeveel RAM heb ik nodig voor een 8B-model?

Houd rekening met de bestandsgrootte, plus de KV-cache, plus de runtime. Een Q4_K_M-build van Llama 3.1 8B is ongeveer 4.58 GiB op schijf, en een context van 4096 tokens voegt ongeveer 512 MiB aan cache toe, dus 8 GiB RAM is comfortabel en 4 GiB is onvoldoende. De cache schaalt mee met de context: hetzelfde model bij een context van 32.768 tokens heeft alleen al ongeveer 4 GiB aan cache nodig. Vergeet bij Ollama niet dat de vereisten ook schalen met OLLAMA_NUM_PARALLEL.