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

Ollama versus llama.cpp: op 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 llama.cpp nog steeds 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 blijft werken zonder dat u er omkijken naar heeft. 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 inhoudt

llama.cpp is een C- en C++-implementatie van transformer-inferentie, 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 op basis van buildnummer in plaats van semantische versie. De huidige tag is b10224, gepubliceerd op 2 augustus 2026, en er verschijnt op de meeste werkdagen 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 vervolgens op onder /usr/share/ollama/.ollama/models op Linux.

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: model- en kwantisatiebeheer

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, maar 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 met 4 GiB bepaalt die enkele keuze of het model überhaupt laadt.

Bij llama.cpp geeft u het bestand een naam, 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 ingeschat.

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 niet de build bevat die u wilt, importeert u zelf een GGUF. Schrijf een Modelfile:

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

Bouw het vervolgens en controleer het resultaat:

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

Contextlengte is de instelling waar gebruikers 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. Als u een document van 20.000 tokens verstuurt, worden de extra tokens verwijderd voordat het model ze ziet. Het antwoord is dan vol overtuiging onjuist 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. llama.cpp heeft eveneens geen standaardwaarde die betrouwbaar 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.

Bereken dit 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 4k context 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 wel in 8 GiB met ruimte om te werken. Verhoog de context naar 32k op diezelfde 8 GiB-machine en de cache alleen al verbruikt de resterende ruimte. Bekijk het live met free -h terwijl het model wordt geladen, en vertrouw niet op een schatting die u niet zelf heeft gemeten.

Ollama vermenigvuldigt dit effect. 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-geheugen dat u had verwacht.

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 verwijderd. Het volgende verzoek moet het volledige bestand opnieuw van de schijf lezen voordat het kan antwoorden, waardoor een 4.58 GiB herlaadactie een antwoord van twee seconden verandert in een antwoord van dertig seconden op trage opslag. Een lange keep-alive verhelpt de latentie en verbruikt permanent het RAM-geheugen. Beide zijn reële kosten. Kies de optie die het minst nadelig is.

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 verwijderd bij inactiviteit, wat betekent dat er geen verrassingen zijn bij het herladen en dat er geen manier is om het geheugen vrij te maken zonder 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 eigen API beschikbaar op /api/chat. Een Anthropic-compatibele route is eveneens 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 biedt /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 elke request-slot, en /metrics in Prometheus-formaat. Als u van plan bent deze service te monitoren, is dit verschil waarschijnlijk doorslaggevend.

Geen van beide servers schakelt automatisch authenticatie voor u 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 realistisch kan presteren

Een VPS die alleen op CPU draait, voert kleine modellen traag uit. Dat is de eerlijke samenvatting; het nuttige deel is weten waar de grens ligt. Meet de prestaties 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 snelheid van het genereren van tokens, beide uitgedrukt in tokens per seconde. Op een gedeeld vCPU-abonnement haalt een 8B-model in Q4_K_M-kwaliteit meestal lage cijfers voor tg. De verwerking van de prompt is het knelpunt: de volledige prompt wordt verwerkt voordat het eerste output-token verschijnt, waardoor een lange systeemprompt bij elk verzoek voor een wachttijd zorgt.

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 standaardabonnement. Niet bruikbaar op CPU: interactieve chat op leessnelheid, code-assistenten, werk met lange documenten of taken waarbij een agent-loop veel opeenvolgende aanroepen doet. Een loop die twaalf aanroepen van elk vier seconden doet, heeft een minuut nodig voordat er resultaat is.

Er zijn twee uitwegen wanneer de cijfers niet voldoen. Als het probleem gelijktijdigheid is, waarbij veel gebruikers tegelijkertijd één model benaderen, verandert de keuze voor de engine; de vergelijking tussen Ollama en vLLM voor gelijktijdige verwerking behandelt dit onderwerp. Als het probleem de pure snelheid is, is de oplossing een VPS met een gekoppelde GPU, waarbij -ngl relevant wordt. Bepaal voor beide opties eerst een nulmeting voor de hardware zelf, omdat schijf- en geheugenbandbreedte de laadtijd net zozeer beïnvloeden als de CPU. Een reproduceerbare VPS-benchmark is de investering van een uur waard.

llama.cpp installeren, vastgezet op een specifieke build

Beide projecten worden wekelijks bijgewerkt, dus noteer de versie die u heeft geïmplementeerd. De standaard 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 server en kopieer de binaries als de kleine server 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 gebruiken die vanochtend is uitgebracht. v0.32.5 werd gepubliceerd op 27 juli 2026. Er is ook een handmatige methode als u liever geen script direct 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 die service-configuratie stap voor stap.

Foutmodi en de meldingen die u zult zien

Ollama weigert het model te laden. ollama run geeft een regel van 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 reden. Kies een lagere kwantisatierij, verklein de contextlengte of kies een kleiner model.

llama.cpp faalt niet, maar werkt extreem traag. llama.cpp gebruikt standaard memory-mapping voor GGUF-bestanden, waardoor een bestand dat groter is dan het RAM-geheugen toch opstart. De kernel verplaatst gewichten continu tussen het geheugen en de schijf bij elk token, 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 te degraderen. 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 model-familie 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, en daarom noteert u het buildnummer. 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" krijgt. Stel OLLAMA_HOST=0.0.0.0:11434 alleen in via systemctl edit ollama wanneer de poort zich achter een firewall of een privénetwerk bevindt, omdat de API zelf geen authenticatie heeft.

Het eerste antwoord na een pauze is erg traag. Het model is na 5 minuten inactiviteit uit het geheugen verwijderd en 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 modelkeuze regelmatig wijzigt.

Gebruik llama.cpp direct wanneer het geheugen beperkt is en u zelf de kwantisatierij moet bepalen, 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 stabiel moet blijven draaien.

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?

Beide gebruiken dezelfde engine, dus bij hetzelfde modelbestand, dezelfde kwantisatie, contextgrootte en thread-aantal 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 kolom tg 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 op zichzelf al ongeveer 4 GiB aan cache nodig. Houd er bij Ollama rekening mee dat de vereiste ook schaalt met OLLAMA_NUM_PARALLEL.