Ollama of llama.cpp op een VPS: wat is de beste keuze?

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-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 met een buildnummer in plaats van met semantische versiebeheer. 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. Hierdoor past een model met 8 miljard parameters in het RAM-geheugen van een standaard VPS. 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, gelezen 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 de bestandsnaam op, 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). Er wordt niets 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 deze vervolgens en controleer het resultaat:

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

De 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 slechts voor de helft is 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.

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 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 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 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 capaciteit plant voor iets dat aanzienlijk groter is dan 8B, laat dezelfde berekening, uitgewerkt voor een 27B-model op een VPS met alleen CPU, zien wat elke klasse 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-geheugen dat u verwachtte. Diezelfde berekening bepaalt uw limiet voor gelijktijdige gebruikers, omdat elk gelijktijdig verzoek een eigen deel van de KV-cache vereist, wat de reden is waarom een server die voor één persoon prima werkt, 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 verwijderd. Het volgende verzoek moet het volledige bestand opnieuw van de schijf lezen voordat er antwoord kan worden gegeven. Een herlaadactie van 4.58 GiB 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.

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 het geheugen niet kan worden vrijgemaakt zonder de service te stoppen. Als het schrijven van units nieuw voor u is: het volgt hetzelfde patroon als het draaien van uw eigen services onder systemd op een VPS.

As 3: de API waarmee uw applicatie communiceert

Deze as is aanzienlijk nauwer geworden. Beide projecten ondersteunen nu het OpenAI-chatformaat, waardoor de meeste clientbibliotheken met beide werken na enkel een wijziging van 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. 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 bedient /v1/chat/completions, /v1/completions en /v1/embeddings, naast een eigen /completion-endpoint en een ingebouwde web-UI. Het stelt ook operationele routes bloot 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 standaard authenticatie in. Beide luisteren om goede redenen standaard op de loopback-interface. 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 met alleen een CPU realistisch kan

Een VPS met alleen een CPU 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 omheen bouwt:

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 in tokens per seconde. Op een gedeeld vCPU-abonnement haalt een 8B-model in Q4_K_M meestal lage enkelvoudige cijfers voor tg. De verwerking van de prompt is het pijnlijke punt: de volledige prompt wordt verwerkt voordat het eerste output-token verschijnt, dus een lange systeemprompt zorgt bij elk verzoek voor een wachttijd.

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 alles 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 goed uitvoert 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 één model benaderen, verandert de keuze van de engine, en de vergelijking van Ollama tegenover vLLM voor gelijktijdige bediening behandelt dat onderwerp. Als het probleem pure snelheid is, is het antwoord een VPS met een gekoppelde GPU, waar -ngl betekenis begint te krijgen. Bepaal voor beide opties eerst een nulmeting 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 upstream one-liner 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 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 handleiding 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 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 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 van en naar 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-bestand dat is gebouwd voor een modelarchitectuur 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; 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" 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, aangezien de API zelf geen authenticatie heeft.

Het eerste antwoord na een pauze is erg traag. De automatische ontlading na 5 minuten inactiviteit heeft plaatsgevonden en het model wordt opnieuw van de schijf gelezen. ollama ps toont vlak voor het verzoek 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 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 het model passend maken exact de instellingen zijn die Ollama anders voor u zou kiezen.

Het is gebruikelijk om beide te draaien. Ollama voor experimenten, en 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?

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. Vergeet bij Ollama niet dat de vereiste ook schaalt met OLLAMA_NUM_PARALLEL.