Welk AI model (LLM) en formaat server moet ik gebruiken met Ollama/Lama.cpp/Codex/Claude?

Voor het hosten van LLM’s is stevige hardware nodig. Bij voorkeur gebruik je één of meerdere krachtige GPU’s, maar het is ook mogelijk om LLM’s alleen op CPU en RAM te draaien. Dat is vooral interessant wanneer je een model intern wilt hosten, wanneer GPU’s te duur zijn, of wanneer data niet naar externe AI-diensten mag.

Let wel: CPU-only inference is meestal aanzienlijk trager dan GPU-inference. Reken grofweg op 10 tot 50 keer tragere performance, afhankelijk van het model, de CPU, het geheugen, de gebruikte quantization en de contextgrootte. Voor interactieve chat kan dat vervelend zijn, maar voor taken zoals code-analyse, documentatie, batchverwerking of agentic coding kan CPU-only alsnog bruikbaar zijn als snelheid niet de belangrijkste eis is.

In dit artikel gaan we in op welke modellen en formaat server je nodig hebt om effectief gebruik te maken van een LLM in combinatie met Ollama, Llama.cpp, Codex en Claude Code.

Modelbestand is niet hetzelfde als RAM-verbruik

Een veelgemaakte fout is om alleen naar de downloadgrootte van het model te kijken. Als een model in Ollama bijvoorbeeld 20 GB groot is, betekent dat niet dat de volledige runtime ook maar 20 GB RAM gebruikt.

Het totale RAM-verbruik bestaat grofweg uit:

Daarom kan een model van 7,2 GB soms wel in llama.cpp werken op een Ubuntu-server met 8 GB RAM, maar niet in Ollama. Ollama zelf gebruikt extra geheugen en het besturingssysteem heeft ook RAM nodig. Bij zulke krappe marges kan 500 MB tot 1 GB overhead al het verschil maken tussen “werkt” en “out of memory”.

Quantization: minder RAM, iets minder kwaliteit

Om hardwarevereisten te verlagen kun je quantized modellen gebruiken. Simpel gezegd wordt een model dan compacter opgeslagen. Je levert meestal een klein beetje nauwkeurigheid in, maar verlaagt de benodigde RAM of vRAM aanzienlijk.

Ollama gebruikt voor veel lokale modellen standaard een 4-bit quantized variant wanneer je alleen de modelnaam gebruikt, bijvoorbeeld:

ollama pull qwen3.5

Dat haalt normaal gesproken de standaardtag op, bijvoorbeeld qwen3.5:latest. Wil je bewust een andere quantization, dan moet je een specifieke tag kiezen, bijvoorbeeld:

ollama pull qwen3.5:27b
ollama pull qwen3.5:27b-q8_0

De exacte tag-namen verschillen per model. Controleer daarom altijd de “Tags”-pagina van het model in Ollama.

Voorbeeld: Qwen3.5 en RAM per quantization

Onderstaande tabel geeft een praktische indruk van de modelgrootte/RAM-richting voor Qwen3.5-achtige modellen. Dit is niet hetzelfde als het volledige runtime-verbruik bij maximale context, maar het helpt om de formaten te begrijpen.

Context size en K/V cache

De context size bepaalt hoeveel tokens het model tegelijk kan meenemen. Voor simpele chat is 4K tot 16K context vaak genoeg. Voor RAG, lange documenten en codebases wil je eerder 32K tot 64K. Voor Codex / Claude Code-achtige workflows is 64K of meer vaak wenselijk (liefst zelfs 256k of meer)s, omdat de agent veel code, terminaloutput, toolresultaten en eerdere stappen in context moet houden.

Maar grote context is niet gratis. Tijdens inference moet het model voor elke token informatie opslaan in de zogenaamde K/V cache.

De simpele uitleg:

• Het modelbestand is het “brein”.
• De prompt en conversatie zijn wat je op dat moment vraagt.
• De K/V cache is het werkgeheugen waarmee het model die context efficiënt kan blijven gebruiken.

Een grote context kan daardoor tientallen GB extra RAM kosten.

Ruwe formule voor K/V cache

De K/V cache hangt af van de architectuur van het model:

K/V cache ≈ 2 × layers × KV_heads × head_dim × context_tokens × bytes_per_value

De 2 staat voor Key en Value. Het aantal layers, KV-heads en head-dimensies verschilt per model. Daarom kun je de K/V cache niet betrouwbaar berekenen op basis van alleen “20B” of “70B”.

Voorbeeld: 20B model met 256K context

Stel dat je een modern 20B-achtig model hebt met Grouped Query Attention, bijvoorbeeld:

48 layers
8 KV-heads
128 head-dim
256K context

Dan kom je ongeveer uit op:

Belangrijk: een Q4-model betekent niet automatisch dat de K/V cache ook Q4 is. In veel runtimes is de K/V cache standaard F16, tenzij je expliciet K/V cache quantization inschakelt. Dat is een belangrijke reden waarom een model met een ogenschijnlijk acceptabele bestandsgrootte toch veel meer RAM kan vragen zodra je de context verhoogt.

Voorbeeld: GLM-5.2 met 1M context

GLM-5.2 is interessant omdat het gericht is op lange agentic engineering-taken en een context rond 1M tokens biedt. Door de gebruikte MLA/KV-compressie kan de K/V cache veel efficiënter zijn dan bij klassieke attention.

Bij een volledige 1M context en Q4 K/V cache kom je ruwweg uit rond 25 GiB K/V cache. Bij F16/BF16 zou dat eerder ongeveer 88 GiB K/V cache uitkomen.

Dit is alleen realistisch als de runtime de gecomprimeerde K/V cache van het model goed ondersteunt. Als een runtime de cache zou uitbreiden naar klassieke K/V-heads, wordt 1M context al snel onpraktisch op CPU-only servers.

Ollama versus llama.cpp

Ollama en llama.cpp gebruiken onderliggend vergelijkbare technieken, maar in de praktijk is llama.cpp vaak iets beter te tunen als je op de absolute grens van je RAM zit.

Hoe groot moet de server zijn?

Onderstaande RAM-adviezen gaan uit van CPU-only servers, Q4-modellen en normaal tot redelijk groot contextgebruik. Ze zijn bewust praktisch en niet theoretisch minimaal.

Modelgeschiktheid voor Codex / Claude Code

Codex en Claude Code-achtige tools stellen hogere eisen aan een model dan gewone chat. Het model moet niet alleen tekst genereren, maar ook:

• code kunnen begrijpen;
• meerdere bestanden tegelijk kunnen analyseren;
• tool calls betrouwbaar kunnen structureren;
• terminaloutput kunnen interpreteren;
• fouten kunnen herstellen;
• instructies strikt kunnen volgen;
• niet te snel hallucineren;
• lange taken over meerdere stappen kunnen volhouden.

Daarom zijn 2B- en 4B-modellen ongeschikt voor dit soort workflows. Ze kunnen simpele codevoorbeelden genereren, maar falen vaak bij echte repositories, refactors, tests, dependencyproblemen en meerstaps taken.

Onderstaande sterrenrating is praktisch bedoeld: hoe geschikt is het model als backend voor Codex / Claude Code-achtige agentic coding? De rating gaat niet alleen over benchmarkscore, maar ook over tool use, codingkwaliteit, context en realistische bruikbaarheid op CPU-only servers.

Use cases per server formaat

Als snelheid minder belangrijk is (15 tokens per seconde) en je vooral wilt dat het goed werkt, is gpt-oss 120B een van de meest logische keuzes. Het model is relatief compact voor zijn klasse, is ontworpen voor agentic workflows, ondersteunt tool use en reasoning, en past praktischer in een server met 96 GB tot 128 GB RAM dan veel andere 100B+-modellen.

Praktische instellingen

1. Houd context bewust laag

Gebruik niet automatisch de maximale context. Begin bijvoorbeeld met:

2. Gebruik K/V cache quantization waar zinvol

Als je lange context gebruikt, kan K/V cache quantization veel RAM besparen. Een Q4 K/V cache kan bij grote context tientallen GB schelen vergeleken met F16/BF16. Q8 K/V cache is vaak een veilige middenweg. Q4 K/V cache bespaart meer RAM, maar gaat meer ten koste van de kwaliteit.

3. Kies liever een beter 20B–35B model dan een zwak 70B model

Groter is niet altijd beter. Voor Codex / Claude Code is een model dat goed is getraind op coding, tool use en instruction following vaak nuttiger dan een groter algemeen chatmodel.

4. Gebruik kleine modellen niet voor serieuze agents

2B- en 4B-modellen zijn aantrekkelijk omdat ze snel en goedkoop draaien, maar voor echte agentic coding zijn ze teleurstellend. Ze missen vaak betrouwbare tool calling, goed foutherstel, codebegrip, langetermijnplanning, consistente patches en begrip van projectstructuur.

Aanbevolen modellen

• Beste keuze voor 32 GB RAM: Devstral Small 2 24B of gpt-oss 20B. Devstral is sterk voor coding workflows en relatief licht. gpt-oss 20B is aantrekkelijk voor tool use, reasoning en agentic focus.
• Beste keuze voor 48 GB RAM: Qwen3.6 35B-A3B of DeepSeek-R1 32B. Deze klasse is krachtig genoeg voor serieus codingwerk en past nog redelijk op CPU-only servers.
• Beste keuze voor 128 GB RAM: gpt-oss 120B. Voor een CPU-only server met 128 GB RAM, waarbij snelheid minder belangrijk is dan kwaliteit, is gpt-oss 120B een van de sterkste keuzes (met nog steeds een performance van 15 tokens per seconde). Het past praktischer in het geheugen dan veel andere grote modellen, is ontworpen voor agentic workflows en is sterk in tool use en reasoning.
• Beste cloudoptie via Ollama: GLM-5.2 cloud (ook lokaal beschikbaar, maar minimaal 256GB RAM vereist). Als lokaal hosten geen harde eis is, is een cloud-hosted versie van GLM-5.2 interessant door de zeer grote context en focus op long-horizon agentic engineering. Het is vooral relevant voor grote repositories en lange taken waarbij veel context nodig is.