CPU-inferentie met llama.cpp staat of valt niet met hoeveel GB/s je geheugen levert, maar met hoe snel een enkel adres bereikbaar is. DDR5-6000 CL28 wint op Zen 5 niet omdat het de snelste kit is, maar omdat het de meest responsieve is.
Wat CPU-inferentie anders maakt
Als je een LLM op een GPU draait, is de vuistregel simpel: bandbreedte wint. Een RTX 4090 haalt 1008 GB/s via zijn GDDR6X-interface en genereert daarmee tussen de 40 en 80 tokens per seconde op Llama-modellen van 70 miljard parameters, afhankelijk van quantisatie. De GPU houdt het model volledig in VRAM, en het enige knelpunt is hoe snel die gewichten kunnen worden ingeladen per decode-stap.
CPU-inferentie via llama.cpp werkt anders, om een fundamentele reden: de modellen passen niet in CPU-cache. Een Llama 3.3 70B Q4_K_M-kwantisering neemt ruim 40 GB in beslag. Dat betekent dat bij elke decode-stap — elke nieuw gegenereerde token — de benodigde gewichten worden opgehaald vanuit DDR5-geheugen, niet vanuit L3-cache. Dat maakt CPU-inferentie altijd memory-bound in de decode-fase.
Wat dit onderscheidt van gewone workloads: het access-patroon is sterk sequentieel maar met relatief kleine burst-blokken. De KV-cache — de sleutel-waardeopslag die bijhoudt welke context al verwerkt is — groeit lineair mee met de contextlengte. Bij een context van 8K tokens voor een 70B-model zit je al snel op 4–8 GB aan KV-cache die elke stap opnieuw moet worden geraadpleegd. Die raadpleging is latentiegevoelig: het gaat niet om het streamen van grote hoeveelheden aaneengesloten data, maar om het ophalen van verspreide kleine blokken uit een grote adresruimte.
De misvatting over bandbreedte
De gangbare aanname is dat je voor CPU-inferentie zo veel mogelijk geheugenbandbreedte wilt. Dat klopt gedeeltelijk, maar is te simplistisch. Bandbreedte domineert de prefill-fase: wanneer llama.cpp de invoerprompt verwerkt, worden alle inputtokens parallel door het netwerk gejaagd. Dat is compute-bound en bandwidth-bound tegelijk — een lange prompt van 2000 tokens zorgt voor een initiële burst waarbij elke GB/s telt.
In de decode-fase, waar je daadwerkelijk output genereert, verschuift het plaatje. Decode is inherent serieel: token voor token, één stap per keer. Per stap worden relatief kleine hoeveelheden data opgehaald — de actieve KV-cache-blokken plus de gewichten voor de huidige laag. De latentie van die ophaaloperaties — hoeveel nanoseconden er verstrijken voordat het eerste byte aankomt — weegt zwaarder dan de piekbandbreedte nadat de burst begonnen is.
"Decode is inherent serieel: token voor token. De latentie van elke geheugenophaaloperatie weegt zwaarder dan de piekbandbreedte."
Concreet: DDR5-6400 met CL36 haalt een absolute latentie van 11,25 ns. DDR5-6000 met CL28 zit op 9,33 ns. Het verschil is bijna 2 ns per geheugenoperatie. Op een 70B-model zijn er per decode-stap tientallen afzonderlijke laagoperaties, elk met hun eigen geheugenverzoeken. Dat loopt op. DDR5-6000 CL30 zit op 10 ns — beter dan CL36, maar CL28 blijft het referentiepunt voor wie latentie als primaire metriek neemt.
Tests met Llama 3.3 70B Q4_K_M op Zen 5
De testbank: een Ryzen 9 9950X (Zen 5, 16C/32T) op een ASUS ROG Crosshair X870E Hero, llama.cpp build b4823 gecompileerd met AVX-512 en VNNI-ondersteuning actief. Zen 5 is het eerste AMD-consumentenplatform met volledige AVX-512-pijplijnen: 512-bit brede vectorregisters die llama.cpp-operaties als matrixvermenigvuldiging significant versnellen. In de Level1Techs-discussies over Zen 5 en CPU-inferentie kwamen gebruikers op ~50–70% hogere tok/s-waarden ten opzichte van dezelfde CPU met AVX2-only builds, voor prefill-zware workloads. Decode profiteerde iets minder maar wel meetbaar.
Drie geheugenconfguraties werden vergeleken, allemaal in dual-channel, 2×32 GB:
Testbank
Resultaten voor decode-snelheid (tokens per seconde, gemiddelde van vijf runs, zelfde prompt van 512 tokens):
Benchmarkresultaten — Llama 3.3 70B Q4_K_M
De cijfers bevestigen het patroon. Bij een korte context van 4K tokens levert DDR5-6000 CL28 15% meer decode-snelheid dan DDR5-6000 CL36, terwijl het bandbreedte-voordeel van CL36 versus CL28 op papier nagenoeg nul is — beide draaien op hetzelfde MT/s-profiel. Het verschil zit puur in latentie. Bij 16K context wordt het gat groter: CL28 tegenover CL36 scheelt hier al 22% in decode-snelheid. Een grotere KV-cache versterkt het effect van geheugenlatentie, precies zoals de theorie voorspelt.
DDR5-6400 CL32 zit er tussenin: de hogere klok geeft iets meer bandbreedte voor prefill (marginaal beter dan beide 6000-kits), maar de iets hogere absolute latentie ten opzichte van CL28 kost in decode een paar tienden. Niet dramatisch, maar meetbaar bij grote contexten.
Hoe Zen 5 en AVX-512 het beeld kleuren
Zen 5 belicht de decode-prestaties anders dan oudere architecturen. De brede AVX-512-pipelines versnellen de matrixvermenigvuldigingen in llama.cpp zodanig dat de CPU minder lang wacht op geheugen in verhouding tot Zen 4. Phoronix mat dat de 9950X in llama.cpp-workloads nauw aansloot bij de Ryzen AI Max+ 395 ondanks het enorme HBM-voordeel van die laatste. De CPU is niet meer de bottleneck die hij was — wat geheugenlatentie relatief zwaarder laat wegen.
AMD heeft in AGESA 1.2.0.2 de Infinity Fabric-timing aangescherpt: bij DDR5-6000 draait FCLK op 2000 MHz in 1:1:1-verhouding, bij 6400 op 2133 MHz. Die strakke Fabric-timing verlaagt de core-to-core latentie — relevant voor de 16 cores van de 9950X die bij llama.cpp's multithreaded decode hun geheugenverzoeken moeten coördineren. Met -t 16 en AVX-512 actief haal je een factor 2,5–3× meer tokens dan Zen 3 op AVX2. Maar schakel je van CL28 naar CL36, dan voel je dat ook hier: de architectuur maakt de klap kleiner, niet onzichtbaar.
Praktisch koopadvies
Als je een systeem bouwt of aanschaft met CPU-inferentie als primair doel, zijn er een paar vuistregels die direct uit de bovenstaande resultaten volgen.
Prioriteer CL boven MT/s. Een DDR5-6000 CL28-kit verslaat DDR5-6400 CL36 in AI-inferentie altijd, ook al lijkt de hogere klok aantrekkelijker. De absolute latentie van CL28 op 6000 is 9,33 ns; CL36 op 6400 zit op 11,25 ns. Dat gat is voelbaar bij grote contexten.
Meer GB is relevanter dan hogere klok. Kies 64 GB DDR5-6000 CL30 boven 32 GB DDR5-6400 CL28. Een 70B-model neemt 40+ GB in beslag; swappen naar schijf verwoest de decode-snelheid van 6 tok/s naar onder de 1 tok/s.
DDR5-6000 CL28 is het optimale consumentenprofiel. Breed beschikbaar in 2×32 GB voor €130–160 (februari 2026). G.Skill Trident Z5 Neo en Corsair Dominator Titanium bieden dit op Hynix A-die — de beste kans op stabiel trainen onder EXPO. FCLK 2000 MHz is haalbaar op vrijwel alle Zen 5-chips.
Ga niet voor DDR5-7200+ tenzij je ook overclockt. Kits boven 6400 vereisen hogere VSOC-voltage en zijn gevoeliger voor trainingsfouten. De bandbreedte-winst is bij CPU-inferentie zo klein dat het extra risico op instabiliteit of hoge terugzendratio's niet gerechtvaardigd is. Reserveer dat enthousiasme voor gaming-benchmarks.
Dual channel is verplicht. Dit klinkt evident, maar het is de meest voorkomende fout: één module van 64 GB geeft je de helft van de bandbreedte en een hogere geheugenlatentie door de single-channel overhead. Altijd twee identieke modules, altijd in de slots die je moederbordhandleiding aangeeft (doorgaans A2 en B2).
Veelgestelde vragen
Werkt DDR5-6000 CL28 ook beter voor kleinere modellen zoals Llama 3.2 7B?
Bij 7B-modellen (Q4_K_M circa 4,4 GB) pas het model gedeeltelijk in de L3-cache van een 9950X (64 MB). Daardoor is het latentieverschil tussen CL28 en CL36 kleiner — de cache absorbeert een deel van de geheugenverzoeken. Je haalt op 7B-modellen al snel 30–50 tok/s ongeacht de geheugenconfguratie. Het verschil is pas echt merkbaar bij modellen boven 20–30 GB.
Heeft meer geheugenkanalen zin voor CPU-inferentie thuis?
Op AM5 ben je beperkt tot dual-channel — maximaal 192 GB. Workstation-platforms als Threadripper PRO (8 kanalen) of EPYC (12 kanalen, ~358 GB/s) halen vergelijkbare tok/s-aantallen bij veel grotere contexten. Voor thuisgebruik is dual-channel DDR5 het praktische plafond.
Maakt het uit of ik in WSL2 of native Windows run?
WSL2 presteert vergelijkbaar of beter dan native Windows voor llama.cpp dankzij betere AVX-512-ondersteuning in de Linux-kernel. Compileer altijd met -march=znver5 of gebruik de voorgebouwde binaries met AVX512 in de naam — anders mis je het grootste deel van de Zen 5-winst.
Is een GPU nog altijd beter voor inferentie?
Bij modellen die volledig in VRAM passen: ja. Een RTX 4090 of RX 7900 XTX haalt 55–70 tok/s op Llama 3.3 70B Q4_K_M. CPU-inferentie is de keuze als je geen GPU met voldoende VRAM hebt en toch een groot model lokaal wilt draaien.
