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

Dit betekent vaak dat er vele lagen op de CPU blijven, waardoor de tokensnelheid sterk daalt. U kunt proberen de GPU-layer offload te verhogen via ngl, een kleinere kwantisatie te kiezen, of de context te verkorten zodat meer 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 VRAM-gebruik, wat het aantal tokens per seconde kan verminderen of gedeeltelijke offloading noodzakelijk maakt. Een kortere context, kleinere modellen of agressievere kwantisatie helpen de snelheid op een enkele kaart met 16 GB te behouden.

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

Lagere bitkwantisaties gebruiken minder VRAM en kunnen de tokens per seconde verhogen, maar kunnen de kwaliteit aantasten. IQ3- en IQ4-stijl kwantisaties zijn gebruikelijke compromissen voor llama.cpp op één GPU met 16 GB geheugen wanneer u een lange context of grotere checkpoints nodig heeft.

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

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

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

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

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

Snelheid van llama.cpp-tokens bij 16 GB VRAM (tabellen).

Inhoud

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

Ik heb deze LLMs uitgevoerd met llama.cpp 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 te halen.

Vergelijkingstabel LLM-snelheid (tokens per seconde en VRAM)

Model	Grootte	19K VRAM	19K GPU/CPU	19K T/s	32K VRAM	32K Load	32K T/s	64K VRAM	64K Load	64K: T/s
Qwen3.6-35B-A3B-UD-IQ3_XXS	13.2	13.8GB	96%/100%	147.5	14.0GB	96%/101%	149.1	14.7GB	96%/101%	145.8
Qwen3.6-35B-A3B-UD-IQ4_XS	17.7	14.3GB	62%/266%	95.0	14.9GB	58%/279%	92.3	14.9GB	57%/293%	86.4
Qwen3.5-35B-A3B-UD-IQ3_S	13.6	14.3GB	93%/100%	136.4	14.6GB	93%/100%	138.5	14.9GB	88%/115%	136.8
Qwen3.5-27B-IQ3_XXS-bartowsky	11.3	12.8	98/100	44.9	13.5	98/100	44.9	14.5	45/415	23.6
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
Qwen3-Coder-Next-UD-IQ4_XS	38.4	14.6	32/460	41.1	14.7	29/440	41.3	14.8	32/460	38.3
Nemotron Super 120b IQ3_XXS	56.2	15.0	26/517	17.5	14.6	26/531	17.4	14.6	26/535	17.6
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 zijn de contextgroottes.

De load hierboven is de GPU-belasting. Als je hier een laag getal ziet, betekent dat dat het model voornamelijk op de CPU draait en op deze hardware geen fatsoenlijke snelheid kan halen. 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, voorbeelden van llama-cli en llama-server wilt, 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 (doorslag tegen latentie, VRAM-limieten, parallelle verzoeken en hoe benchmarks samenhangen over hardware en runtime heen), zie LLM Prestaties in 2026: Benchmarks, Flesschhalsen & Optimalisatie.

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

Beste LLMs voor OpenCode - Lokaal getest. Je kunt meer lezen over Opencode in OpenCode Quickstart: Installatie, configuratie en gebruik van de Terminal AI Coding Agent
Vergelijking van de vertaalingskwaliteit van Hugo-pagina’s - LLMs op Ollama

Ik heb vergelijkbare tests uitgevoerd voor LLMs op Ollama: Beste LLMs voor Ollama op 16GB VRAM GPU.

Waarom contextlengte de tokens per seconde verandert

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

De modellen en quants die ik heb gekozen om te testen, zijn om zelf uit te voeren en te zien of ze een goede winst opleveren in termen van kosten/baten op deze apparatuur of niet. Dus hier geen q8-quants met 200k context :) …

GPU/CPU is een belasting, gemeten door nvitop.

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

Testhardware en llama.cpp-opstelling

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

CPU i-14700
RAM 64GB 6000Hz (2x32GB)
GPU RTX-4080
Ubuntu met NVidia-drivers
llama.cpp/llama-cli, geen ontladen lagen gespecificeerd
Initiële VRAM-gebruik, voor het starten van llama-cli: 300MB

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

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

Geoptimaliseerde runs

Voor sommige interessante modellen en quants 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 load	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

Conclusies voor builds met 16 GB VRAM

Mijn huidige favoriet Qwen3.5-27B-UD-IQ3_XXS presteert goed op zijn sweet spot van 50k context (ik krijg ongeveer 36t/s)
Qwen3.5-122B-A10B-UD-IQ3_XXS overtreft prestatie-technisch de Qwen3.5 27B op contexten boven de 64K.
Ik kan Qwen3.5-35B-A3B-UD-IQ3_S dwingen om context van 100k tokens aan te kunnen, en het past in de VRAM, dus geen prestatiedaling.
Ik zal geen gemma-4-31B op 16GB VRAM gebruiken, maar gemma-4-26B zou misschien redelijk goed kunnen…, moet ik testen.
Ik 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 twijfel, maar ik zal het toch testen om de verdenking te bevestigen.