Wat betekent een lage GPU-belasting bij het uitvoeren van een LLM met llama.cpp?

Dit betekent vaak dat vele lagen op de CPU blijven, waardoor de tokensnelheid sterk daalt. U kunt proberen het GPU-layer-offload te verhogen met ngl, een kleinere kwantiseringsniveaus te kiezen, of de context te verkorten zodat een groter deel van het model op de GPU past.

Hoe beïnvloedt een langere contextvenster de tokens per seconde op 16 GB VRAM?

Een langere context vergroot de KV-cache en het VRAM-gebruik, wat het aantal tokens per seconde kan verminderen of gedeeltelijke offloading noodzakelijk maakt. Een kortere context, kleinere modellen of meer agressieve kwantisatie helpen de snelheid op een enkele kaart met 16 GB VRAM hoog te houden.

Welke kwantisatie-compromissen zijn van belang voor het laden van grote modellen in 16 GB?

Lager-bit-kwantisaties gebruiken minder VRAM en kunnen het aantal tokens per seconde verhogen, maar dit kan de kwaliteit beïnvloeden. IQ3- en IQ4-stijl kwantisaties zijn veelgebruikte compromissen voor llama.cpp op een GPU met 16 GB geheugen wanneer u een lange context of grotere checkpoints nodig hebt.

Kunnen mixture-of-experts-modellen snel werken op één GPU met 16 GB geheugen?

MoE-modellen kunnen een hoog aantal tokens per seconde bereiken omdat bij elke forward-stap slechts een deel van het netwerk wordt uitgevoerd, maar u heeft nog steeds voldoende VRAM nodig voor de actieve experts, de weights en de KV-cache bij de door u gekozen contextlengte.

Wat kunt u proberen als een context van 64K aanzienlijk trager is dan 32K op dezelfde GPU?

Pas aan hoeveel lagen op de GPU worden geladen met ngl, accepteer een kortere context als dat past bij uw taak, of schakel over naar een lichtere kwantisering zodat meer lagen op het apparaat blijven en de KV-cache-druk afneemt.

LLM-benchmarks met 16 GB VRAM in llama.cpp (snelheid en context)

Token snelheid van llama.cpp op 16 GB VRAM (tabellen).

Inhoud

Hier vergelijk ik de snelheid van verschillende LLM’s die op een GPU met 16 GB VRAM draaien, en kies ik de beste voor self-hosting.

Ik heb deze LLM’s op llama.cpp getest met contextvensters van 19K, 32K en 64K tokens.

Stylized GPU with VRAM blocks and benchmark-style charts

In dit artikel documenteer ik mijn pogingen om zo veel mogelijk prestaties in termen van snelheid uit de hardware te halen.

LLM-snelheidsvergelijkings tabel (tokens per seconde en VRAM)

Model	Grootte	19K VRAM	19K GPU/CPU	19K T/s	32K VRAM	32K Belasting	32K T/s	64K VRAM	64K Belasting	64K: T/s
Qwen3.5-35B-A3B-UD-IQ3_S	13.6	14.3 GB	93%/100%	136.4	14.6 GB	93%/100%	138.5	14.9 GB	88%/115%	136.8
Qwen3.5-27B-UD-IQ3_XXS	11.5	12.9	98/100	45.3	13.7	98/100	45.1	14.7	45/410	22.7
Qwen3.5-27B-IQ4_XS.gguf	15.0	14.6	49/406	20.5	14.7	37/465	17.4	14.7	23/533	13.3
Qwen3.5-122B-A10B-UD-IQ3_XXS	44.7	14.7	30/470	22.3	14.7	30/480	21.8	14.7	28/490	21.5
Qwen3.5-122B-A10B-UD-IQ3_S	46.5	14.7	25/516	19.4	14.7	24/516	19.5	14.7	24/516	19.6
nvidia Nemotron-Cascade-2-30B IQ4_XS	18.2	14.6	60/305	115.8	14.7	57/311	113.6	14.7	55/324	103.4
gemma-4-26B-A4B-it-UD-IQ4_XS	13.4	14.7	95/100	121.7	14.9	95/115	114.9	14.9	75/190	96.1
gemma-4-31B-it-UD-IQ3_XXS	11.8	14.8	68/287	29.2	14.8	41/480	18.4	14.8	18/634	8.1
GLM-4.7-Flash-IQ4_XS	16.3	15.0	66/240	91.8	14.9	62/262	86.1	14.9	53/313	72.5
GLM-4.7-Flash-REAP-23B IQ4_XS	12.6	13.7	92/100	122.0	14.4	95/102	123.2	14.9	71/196	97.1

19K, 32K en 64K verwijzen naar de contextgroottes.

De load hierboven is de GPU-belasting. Als je hier een laag getal ziet, betekent dit dat het model voornamelijk op de CPU draait en op deze hardware geen aanvaardbare snelheid kan bereiken. Dit patroon komt overeen met wat mensen zien wanneer te weinig van het model op de GPU past of wanneer de context de verwerking naar de host duwt.

Over llama.cpp, LLM-prestaties, OpenCode en andere vergelijkingen

Als je installatiepaden, llama-cli en llama-server voorbeelden nodig hebt, en de vlaggen die belangrijk zijn voor VRAM en tokens per seconde (contextgrootte, batching, -ngl), begin dan met llama.cpp Quickstart met CLI en Server.

Voor het bredere prestatiebeeld (doorvoer versus latentie, VRAM-limieten, parallelle verzoeken en hoe benchmarks samenhangen over hardware en runtime), zie LLM-prestaties in 2026: Benchmarks, Bottlenecks & Optimalisatie.

De kwaliteit van de respons wordt in andere artikelen geanalyseerd, bijvoorbeeld:

Beste LLM’s voor OpenCode - lokaal getest. Je kunt meer lezen over OpenCode in OpenCode Quickstart: Installeren, configureren en gebruiken van de Terminal AI Coding Agent
Vergelijking van de vertaalingskwaliteit van Hugo-pagina’s - LLM’s op Ollama

Ik heb vergelijkbare tests uitgevoerd voor LLM’s op Ollama: Beste LLM’s voor Ollama op 16 GB VRAM GPU.

Waarom contextlengte de tokens per seconde verandert

Naarmate je van 19K naar 32K of 64K tokens gaat, groeit de KV-cache en stijgt de VRAM-druk. Sommige rijen tonen een grote daling in tokens per seconde bij 64K, terwijl andere stabiel blijven; dit is het signaal om kwantisaties, contextlimieten of layer-offload te heroverwegen in plaats van aan te nemen dat het model over het algemeen “langzaam” is.

De modellen en kwantisaties die ik heb gekozen om te testen, zijn bedoeld om zelf te draaien en te zien of ze een goede winst opleveren in termen van kosten-baten op dit apparaat of niet. Dus hier geen q8-kwantisaties met 200k context :) …

GPU/CPU is een belasting, gemeten door nvitop.

Wanneer llama.cpp automatisch de lagen ontladen naar de GPU configureert, probeert het 1 GB vrij te houden. We specificeren deze parameter handmatig via de commandline parameter -ngl, maar ik fine-tun dit hier niet; ik wil alleen begrijpen dat als er een significante prestatiedaling is bij het verhogen van de contextvenstergrootte van 32k naar 64k, we de snelheid op 64k kunnen proberen te verhogen door het aantal ontladen lagen te fine-tunen.

Testhardware en llama.cpp configuratie

Ik testte de LLM-snelheid op een PC met deze configuratie:

CPU i-14700
RAM 64 GB 6000 Hz (2x32 GB)
GPU RTX-4080
Ubuntu met NVidia-drivers
llama.cpp/llama-cli, geen ontladen lagen gespecificeerd
Begins VRAM-gebruik, voordat llama-cli wordt gestart: 300 MB

Extra runs bij 128K context (Qwen3.5 27B en 122B)

Model	128K Belasting	128K: T/s
Qwen3.5-27B-UD-IQ3_XXS	16/625	9.6
Qwen3.5-122B-A10B-UD-IQ3_XXS	27/496	19.2

Fine-tuned runs

Voor sommige interessante modellen en kwantisaties heb ik geprobeerd speciale llama-cpp commandline parameters te vinden om VRAM beter te benutten. Hier is wat ik kon bereiken:

Model	Context	Lagen op GPU	CPU/CPU-belasting	Snelheid
Qwen3.5-27B-IQ4_XS.gguf	18k	65	98%/100%	38.0
Qwen3.5-27B-IQ4_XS.gguf	64k	53	33%/488%	15.7

Belangrijkste punten voor builds met 16 GB VRAM

Mijn huidige favoriet Qwen3.5-27B-UD-IQ3_XXS presteert goed in zijn sweet spot van 50k context (ik krijg ongeveer 36t/s)
Qwen3.5-122B-A10B-UD-IQ3_XXS haalt prestatie-technisch de Qwen3.5 27B in op contexten boven de 64K.
Ik kan Qwen3.5-35B-A3B-UD-IQ3_S dwingen om context van 100k tokens te hanteren, en het past in de VRAM, dus geen prestatiedaling.
Ik zal gemma-4-31B niet gebruiken op 16 GB VRAM, maar gemma-4-26B zou middelmatig kunnen zijn…, moet getest worden.
Moet testen hoe goed Nemotron cascade 2 en GLM-4.7 Flash REAP 23B werken. Zullen ze beter zijn dan Qwen3.5-35B q3? Ik betwijfel het, maar zal het testen om de vermoedens te bevestigen.