CPU versus GPU inferentie voor lokale open source modellen

Bij het lokaal draaien van open source taalmodellen vormt de hardwarekeuze de belangrijkste technische en financiële beslissing. Waar de centrale processor (CPU) in vrijwel elke bestaande server of werkplek al standaard aanwezig is, vereist een grafische processor (GPU) vaak aanzienlijke investeringen in gespecialiseerde PCIe-kaarten, extra koelcapaciteit en zware voedingen. Het fundamentele onderscheid tussen beide verwerkingsmethoden zit niet louter in ruwe rekenkracht, maar vooral in de manier waarop geheugenbandbreedte, cache-hiërarchieën en parallelle instructies worden afgehandeld. In dit artikel ontleden we de bottlenecks, vergelijken we prestaties tijdens prefill- en decode-cycli, behandelen we de invloed van multi-channel architectuur en rekenen we uit waar het omslagpunt ligt tussen betaalbare CPU-inzet en noodzakelijke GPU-versnelling.

De fundamenten van inferentie: Compute versus Memory Bandwidth

Om te doorgronden waarom hardwarekeuzes zo direct doorwerken in de eindgebruikerservaring, moeten we de rekenkundige cyclus van een Large Language Model (LLM) ontleden. AI-inferentie bij autoregressieve transformatormodellen bestaat uit twee scherp gescheiden fasen: de prefill-fase (waarin de ingevoerde prompt wordt verwerkt) en de decode-fase (waarin het model token voor token het antwoord formuleert). Deze twee fasen stellen fundamenteel andere eisen aan de onderliggende siliciumarchitectuur.

Tijdens de prefill-fase worden alle invoertokens tegelijkertijd geanalyseerd. Deze stap bestaat uit matrix-matrix-vermenigvuldigingen (General Matrix Multiply of GEMM) en is zwaar rekenintensief (compute-bound). Hier excelleert een processor met duizenden parallelle rekenkernen en gespecialiseerde matrix-eenheden, zoals de Tensor Cores op Nvidia-chips. De gehele invoercontext kan in één rekenstap worden verwerkt, waarbij de rekeneenheden continu maximaal bezet blijven.

Tijdens de daaropvolgende decode-fase verandert het speelveld echter compleet. Om exact één nieuw token te voorspellen, moet het systeem nagenoeg alle parameters en gewichten van het model eenmalig vanuit het werkgeheugen naar de rekeneenheden transporteren. Deze stap betreft een matrix-vector-vermenigvuldiging (GEMV). Omdat de rekenkundige intensiteit (het aantal floating-point operaties per getransporteerde byte) hier uiterst laag is, raakt de processor vrijwel direct beperkt door de geheugenbandbreedte (memory-bound). De rekenkernen staan het merendeel van de tijd te wachten tot de benodigde parameters over de geheugenbus zijn binnengekomen.

De theoretische maximale doorvoersnelheid in tokens per seconde tijdens deze decode-fase laat zich voor single-batch inferentie betrouwbaar benaderen met de volgende rekenkundige formule:

Doorvoersnelheid (tokens/s) ≈ Geheugenbandbreedte (GB/s) / Modelgrootte in werkgeheugen (GB)

Wanneer een 8B model gekwantiseerd naar 4-bit precisie circa 5,5 GB aan werkgeheugen inneemt op een standaardsysteem met dual-channel DDR5-geheugen (effectief zo'n 75 GB/s bandbreedte), ligt het absolute theoretische plafond rond de 13,6 tokens per seconde. In de praktijk zorgen kernel-overhead en context-beheer ervoor dat hier circa 9 tot 11 tokens per seconde van overblijven. Op een dedicated videokaart met GDDR6X-geheugen (1000 GB/s bandbreedte) schiet ditzelfde model naar ruim 100 tokens per seconde. Dit mechanisme vormt de harde fysieke verklaring voor het snelheidsverschil tussen CPU en GPU.

Geheugenarchitectuur: DDR5 versus GDDR6, HBM en Unified Memory

Het enorme contrast in geheugenbandbreedte tussen regulier systeem-RAM en gespecialiseerd videogeheugen verklaart waarom pure CPU-inferentie bij interactieve toepassingen traag kan overkomen. Regulier desktop- en server-RAM is primair ontworpen voor lage willekeurige toegangstijden (lage latency) bij complexe, sequentiële CPU-instructies, niet voor het gelijktijdig verplaatsen van massale, aaneengesloten datastromen.

De tabel toont direct aan waarom consumenten-CPU's met dual-channel geheugen moeite hebben met grotere taalmodellen. Zodra we echter overstappen naar octa-channel serverconfiguraties, begint de CPU-bandbreedte serieus mee te tellen. Om exact te bepalen hoeveel werkgeheugen of VRAM een gekozen modelstructuur inclusief de benodigde KV-cache opeist, is het raadzaam om vooraf parameters om te rekenen naar benodigd VRAM zodat er geen geheugentekorten optreden tijdens piekbelastingen.

Rekenkracht en vectorinstructies: AVX-512, AMX versus Tensor Cores

Hoewel de decode-fase voornamelijk begrensd wordt door geheugenbandbreedte, stelt de verwerking van lange invoerprompts juist hoge eisen aan de ruwe computekracht. Tijdens de prefill-fase moet de volledige aandachtskaart (attention matrix) over alle ingevoerde tokens worden berekend. Hier tonen gespecialiseerde instructiesets hun waarde.

Moderne CPU's maken gebruik van geavanceerde vector- en matrixinstructies. Met AVX2 en AVX-512 kunnen moderne AMD- en Intel-processors meerdere 8-bit of 16-bit berekeningen tegelijkertijd uitvoeren binnen één enkele klokcyclus. Intel AMX (Advanced Matrix Extensions), aanwezig op moderne Xeon-processors, gaat een stap verder door dedicated hardwareblokken toe te wijzen aan 2D-matrixvermenigvuldigingen. Hiermee levert een high-end CPU aanzienlijk betere prestaties dan eerdere processorgeneraties.

Desondanks blijft het verschil met grafische hardware enorm. Een moderne consumenten-GPU beschikt over duizenden streaming multiprocessors en honderden gespecialiseerde Tensor Cores, waardoor de ruwe rekenkracht voor INT4- en FP16-berekeningen in de honderden tot duizenden TFLOPS loopt. Dit verschil vertaalt zich direct in de Time-to-First-Token (TTFT). Waar een CPU over een document van 4000 tokens enkele seconden doet om het eerste antwoordtoken te produceren, voltooit een GPU diezelfde taak in minder dan honderd milliseconden.

De invloed van kwantisatie op CPU- en GPU-architecturen

Kwantisatie comprimeert modelgewichten van hun oorspronkelijke 16-bit drijvende-kommagetal (FP16 of BF16) naar compactere precisies zoals 8-bit, 4-bit of zelfs 2-bit integers. Deze compressie levert twee doorslaggevende voordelen op: het model past in een aanzienlijk kleinere geheugenruimte, en de totale datatransmissie per tokengeneratie over de geheugenbus wordt drastisch verlaagd.

De keuze voor het onderliggende hardwareplatform bepaalt in grote mate welk kwantisatieformaat de voorkeur heeft. Voor CPU-inferentie vormt het GGUF-formaat, ontwikkeld binnen het open source llama.cpp-ecosysteem, de onbetwiste standaard. GGUF-kernels zijn specifiek ontworpen om optimaal gebruik te maken van CPU-vectorinstructies (zoals AVX-512) en systeem-RAM zonder onnodige overhead.

Op dedicated GPU's bieden andere formaten vaak aanzienlijk betere prestaties. Formaten zoals AWQ (Activation-aware Weight Quantization) en EXL2 (ExLlamaV2) zijn specifiek geoptimaliseerd voor de geheugen- en rekenhiërarchie van GPU's. Raadpleeg het vergelijkende overzicht over het kiezen van quantization-formaten zoals GGUF, AWQ en EXL2 om de juiste afweging te maken tussen rekenplatform en bestandsformaat.

Met behulp van 4-bit kwantisatie kunnen krachtige modellen van 7 tot 14 miljard parameters probleemloos worden ingezet op apparaten met beperkte hardware. Hoe compacte modellen presteren binnen lokale omgevingen zonder enterprise-accelerators staat uitgebreid beschreven in de gids over kleine modellen op het apparaat.

Hybride inferentie: Layer offloading en PCIe-knelpunten

Wanneer een model net te omvangrijk is voor het beschikbare videogeheugen van een grafische kaart, biedt hybride inferentie via layer offloading een praktische tussenoplossing. Frameworks zoals llama.cpp en Ollama maken het mogelijk om een exact aantal lagen van het transformatormodel toe te wijzen aan het snelle VRAM van de GPU, terwijl de resterende lagen worden verwerkt door de CPU en het systeem-RAM.

Het principe achter layer offloading laat zich eenvoudig configureren via de command-line interface:

# Starten van een 32-lagen model met gedeeltelijke GPU-offloading
# 24 lagen draaien in GPU VRAM (-ngl 24), de overige 8 lagen blijven in RAM
./llama-cli -m models/meta-llama-3-8b-instruct.Q4_K_M.gguf -ngl 24 -c 4096 -p "Vraag:"

Tijdens elke tokengeneratie worden de activatietensors tussen de transformatorlagen heen en weer gestuurd over de PCIe-bus. Hoewel de GPU-lagen razendsnel worden berekend, ontstaat er bij de overgang naar de CPU-lagen een onvermijdelijke vertraging. De uiteindelijke generatiesnelheid wordt begrensd door de bandbreedte van het systeemgeheugen en de doorvoersnelheid van de PCIe-sleuf (ongeveer 31,5 GB/s voor een PCIe 4.0 x16 verbinding of 63 GB/s voor PCIe 5.0).

Hybride inferentie presteert daardoor langzamer dan een volledige GPU-opstelling, maar levert wel een substantiële versnelling ten opzichte van zuivere CPU-uitvoering en voorkomt dat een proces crasht door geheugentekort.

Meetmethode en reproduceerbare benchmarkopzet

Om prestatieverschillen objectief en reproduceerbaar vast te stellen, moeten benchmarks worden uitgevoerd onder gestandaardiseerde condities. Het simpelweg klokken van een willekeurige chatprompt geeft een vertekend beeld door wisselende caching en variabele antwoordlengtes. Een betrouwbare meetopzet scheidt de prefill-latentie scherp van de decodeersnelheid.

Voor gestandaardiseerde metingen wordt gebruikgemaakt van de interne benchmarking-tools van llama.cpp, waarbij zowel de prompt-lengte (bijvoorbeeld exact 512, 1024 of 2048 tokens) als het aantal te genereren tokens (bijvoorbeeld 128 of 256 tokens) strikt worden vastgelegd:

# Gestandaardiseerde benchmark voor TTFT en tokengeneratie
./llama-bench -m models/llama-3-8b-instruct.Q4_K_M.gguf -p 512,2048 -n 128 -t 16

Belangrijke variabelen die tijdens metingen gecontroleerd moeten worden zijn:

1. Geheugenkanalen: Zorg dat RAM daadwerkelijk in meerkanaalsmodus (dual-, quad- of octa-channel) draait via BIOS-verificatie.
2. Thermische throttling: Voorkom dat processors na langdurige belasting terugschakelen in klokfrequentie door voldoende koeling te waarborgen.
3. Contextgrootte: Houd de KV-cachegrootte identiek tussen testruns, omdat een groeiende context extra geheugenverkeer genereert.

Praktijkvergelijking en meetresultaten

Onderstaande meetresultaten geven een representatief beeld van typische hardwareconfiguraties bij het verwerken van een gangbaar 8B-model en een zwaarder 70B-model, beide gekwantiseerd naar 4-bit precisie (Q4_K_M).

De cijfers maken duidelijk dat een consumenten-CPU bij kleine modellen een leessnelheid kan bieden die net toereikend is voor enkelvoudig gebruik (boven de 10 tokens per seconde), maar tekortschiet bij interactieve chatbots met lange documenten. Om een evenwichtige keuze te maken tussen doorvoersnelheid, wachttijd en modelcomplexiteit biedt het overzicht over de balans tussen modelgrootte, latentie en nauwkeurigheid aanvullende richtlijnen.

Randgevallen en uitzonderingen: Concurrency, Batching en Apple Silicon

Bij het evalueren van hardware volstaat het niet om alleen naar enkelvoudige verzoeken te kijken. In de praktijk doen zich specifieke scenario's voor waarin de prestatieverhoudingen anders uitvallen.

Meerdere gelijktijdige gebruikers (Concurrency): Zodra een lokaal systeem meerdere verzoeken tegelijk moet afhandelen via continuous batching, verandert de rekenintensiteit van de decode-fase. Doordat meerdere tokens tegelijk worden berekend voor verschillende gebruikers, verschuift de bewerking van matrix-vector (GEMV) naar matrix-matrix (GEMM). GPU's schalen in dit scenario uitstekend op dankzij hun enorme parallelle capaciteit. CPU's daarentegen lopen bij gelijktijdige verzoeken snel vast, waardoor de wachttijd per gebruiker lineair oploopt.

Lange contexten en KV-cache druk: Bij prompts van meer dan 16.000 tokens neemt de omvang van de KV-cache drastisch toe. Een model dat normaal in 6 GB past, kan met een vol contextvenster plotseling 12 tot 16 GB aan geheugen opeisen. Als dit de VRAM-grens van een videokaart overschrijdt, crasht de GPU-pipeline tenzij er wordt uitgeweken naar CPU-geheugen of geavanceerde KV-cache kwantisatie.

De uitzondering van Apple Silicon: De Unified Memory Architecture (UMA) van Apple vormt een categorie apart. Doordat de CPU, GPU en Neural Engine direct toegang hebben tot dezelfde brede geheugenpool met bandbreedtes tot 800 GB/s, kunnen modellen van 70B parameters volledig in het werkgeheugen worden geladen zonder de fysieke VRAM-beperkingen van standaard PCIe-insteekkaarten. Dit maakt het een aantrekkelijk platform voor workstations waar grote modellen lokaal getest worden.

Expliciete zwakke punten en operationele beperkingen

Elke hardwarekeuze brengt duidelijke nadelen met zich mee die vooraf moeten worden meegewogen in het ontwerp van de infrastructuur:

Beperkingen van CPU-inferentie:

De Time-to-First-Token op een CPU is bij documenten met duizenden tokens onbruikbaar traag voor realtime gebruikersinterfaces. Daarnaast is de energie-efficiëntie per token bij intensief gebruik aanzienlijk ongunstiger: omdat een CPU-berekening tot tien keer langer duurt dan op een GPU, blijft de processor gedurende langere tijd onder vollast stroom verbruiken.

Beperkingen van GPU-inferentie:

Videokaarten kennen een harde VRAM-limiet. Als een model inclusief context niet volledig in het videogeheugen past, faalt de uitvoering direct met een Out-Of-Memory foutmelding. Bovendien vereisen high-end GPU's zware voedingen (vaak 850W tot 1500W), genereren ze aanzienlijke warmte en lawaai, en vragen servers om specifieke PCIe-lay-outs met voldoende fysieke tussenruimte voor airflow.

Kosten, energieverbruik en TCO van lokale hardware

Naast de initiële aanschafprijs van componenten is de Total Cost of Ownership (TCO) over een periode van twee tot drie jaar doorslaggevend. Een server met meerdere high-end grafische accelerators vraagt een forse investering vooraf, maar levert per kilowattuur aanzienlijk meer voltooide tokens op.

Wanneer een bedrijfsserver 24/7 actief is met continue AI-taken, kan een GPU-cluster van 700 watt op jaarbasis duizenden kilowatturen aan stroom verbruiken. Bij incidenteel of asynchroon gebruik op de achtergrond (zoals het 's nachts indexeren van interne documenten) kan het juist financieel verstandiger zijn om gebruik te maken van een reeds aanwezige CPU-server, waardoor er geen additionele hardware aangeschaft hoeft te worden.

Wanneer lokale modelservers worden ingezet om interne bedrijfssystemen en microservices te ontsluiten, is een gestandaardiseerde API-architectuur essentieel. Hoe je lokale modellen betrouwbaar beschikbaar stelt via een eigen gateway met load balancing en routering lees je in de architectuurgids over lokale modellen hosten achter een eigen API.

Conclusie en beslisstructuur voor hardwarekeuze

De afweging tussen CPU- en GPU-inferentie is geen principekwestie, maar een technische balans tussen latentie-eisen, gelijktijdige gebruikersbelasting, modelgrootte en beschikbaar budget. Onderstaande beslisregels vatten de operationele keuzes samen:

Kies voor CPU-inferentie wanneer:

De verwerkingstaak asynchroon op de achtergrond mag draaien (zoals nachtelijke samenvattingen, e-mailclassificatie of periodieke data-extractie); het model compact is (1B tot 8B parameters met 4-bit kwantisatie); er uitsluitend sprake is van één actieve gebruiker tegelijk; of wanneer er al krachtige serverhardware aanwezig is met octa-channel DDR5-geheugen waardoor extra investeringen overbodig zijn.

Kies voor GPU- of Unified Memory-acceleratie wanneer:

Er sprake is van realtime interactie zoals interactieve chatbots of live assistenten waarbij antwoorden direct moeten verschijnen; er grote prompts (meer dan 2000 tokens) worden ingelezen die een snelle Time-to-First-Token vereisen; er meerdere gelijktijdige verzoeken worden afgehandeld; of wanneer middelgrote tot grote modellen (14B, 32B tot 70B parameters) moeten draaien met een continue doorvoersnelheid boven de 25 tokens per seconde.