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

Dit betekent vaak dat veel lagen op de CPU blijven, waardoor de tokensnelheid sterk daalt. U kunt proberen de GPU-laagoffload met ngl te verhogen, een kleinere kwantisering 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?

Langere context verhoogt de KV-cache en het VRAM-gebruik, wat de tokens per seconde kan verminderen of gedeeltelijke offload kan forceren. Kortere context, kleinere modellen of agressievere kwantisatie helpen de snelheid op een enkele 16 GB-kaart te behouden.

Welke kwantiseringsafwegingen zijn belangrijk voor het passen van grote modellen in 16 GB?

Lager bit-quants gebruiken minder VRAM en kunnen de tokens per seconden verhogen, maar kunnen de kwaliteit aantasten. IQ3- en IQ4-stijl quants zijn veelvoorkomende compromissen voor llama.cpp op één GPU met 16 GB geheugen wanneer u lange context of grotere checkpoints nodig heeft.

Zijn mixture-of-experts-modellen snel op één GPU van 16 GB?

MoE-modellen kunnen een hoog aantal tokens per seconde halen omdat slechts een deel van het netwerk per forward-stap wordt uitgevoerd, maar u heeft nog steeds voldoende VRAM nodig voor actieve experts, gewichten en de KV-cache op de 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 dat bij uw taak past, of gebruik een lichtere kwantiseringsvariant zodat meer lagen op het apparaat blijven en de KV-cache-belasting afneemt.

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

llama.cpp tokensnelheid 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 optie voor zelfhosting.

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

Stylizeerde GPU met VRAM-blokken en benchmark-achtige grafieken

In dit artikel documenteer ik mijn pogingen om zoveel mogelijk prestaties, met name wat betreft snelheid, uit het systeem te persen.

Snelheidsvergelijking LLM’s (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,8 GB	96%/100%	147,5	14,0 GB	96%/101%	149,1	14,7 GB	96%/101%	145,8
Qwen3.6-35B-A3B-UD-IQ4_XS	17,7	14,3 GB	62%/266%	95,0	14,9 GB	58%/279%	92,3	14,9 GB	57%/293%	86,4
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-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
Mistral-Small-4-119B UD-IQ3_XXS	42,8	14,8	28/585	30,4	14,7	27/574	28,5	14,9	20/590	31,5
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 verwijst naar GPU Load. Als u hier een laag getal ziet, betekent dit dat het model voornamelijk op de CPU draait en op deze hardware geen aanvaardbare snelheid kan behalen. Dit patroon komt overeen met wat men ziet wanneer te weinig van het model in de GPU past of wanneer de context de werklast terug naar de host duwt.

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

Als u installatiepaden, llama-cli- en llama-server-voorbeelden, en de vlaggen die van belang zijn voor VRAM en tokens per seconde (contextgrootte, batching, -ngl) wilt, begint u bij llama.cpp Quickstart met CLI en Server.

Voor een breder overzicht van prestaties (doorvoer versus latentie, VRAM-limiten, parallelle verzoeken en hoe benchmarks samenhangen over hardware en runtimes heen), zie LLM-prestaties in 2026: Benchmarks, bottlenecks & optimalisatie.

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

Beste LLM’s voor OpenCode - Lokaal getest. U kunt meer lezen over OpenCode in OpenCode Quickstart: Installeren, configureren en gebruiken van de AI-codeeragent voor de terminal
Vergelijking van de vertaalkwaliteit van Hugo-pagina’s - LLM’s op Ollama

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

Als u Qwen 3.6 27B of 35B via llama.cpp uitvoert en de generatiesnelheid verder wilt verbeteren, bekijk dan Qwen 3.6 MTP versus standaard decodering op GPU met 16 GB — MTP-speculatieve decodering voegt tot 67% generatiedoorvoer toe voor het 27B dichtheidsmodel, met tabellen die de VRAM-kosten en de afwegingen in contextvenster tonen op elk --spec-draft-n-max-niveau.

Waarom contextlengte tokens per seconde beïnvloedt

Naarmate u van 19K naar 32K of 64K tokens gaat, groeit de KV-cache en neemt de druk op de VRAM toe. Sommige rijen tonen een grote daling in tokens per seconde bij 64K, terwijl anderen stabiel blijven; dit is een signaal om quants, contextlimiten of layer-offload te heroverwegen, in plaats ervan uit te gaan dat het model over het algemeen “langzaam” is.

De modellen en quants die ik heb gekozen om te testen, zijn bedoeld om door mijzelf te worden uitgevoerd om te zien of ze een goede kosten-batenverhouding bieden op deze apparatuur. Dus hier geen q8-quants met 200K context :) …

GPU/CPU is een last, gemeten door nvitop.

llama.cpp probeert bij het automatisch configureren van de offloading van lagen naar de GPU 1 GB vrij te houden. We specificeren deze parameter handmatig via de commandoregelparameter -ngl, maar ik optimaliseer dit hier niet fijn, ik wil alleen duidelijk maken dat als er een significante prestatiedaling is bij het vergroten van het contextvenster van 32K naar 64K, we kunnen proberen de snelheid bij 64K te verhogen door het aantal offlinegeladen lagen te optimaliseren.

Testhardware en llama.cpp-configuratie

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

CPU i-14700
RAM 64 GB 6000Hz (2x32GB)
GPU RTX-4080
Ubuntu met NVidia-drivers
llama.cpp/llama-cli, geen offlinegeladen lagen gespecificeerd
Initieel VRAM-gebruik, voordat llama-cli startte: 300 MB

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 enkele interessante modellen en quants heb ik geprobeerd speciale commandoregelparameters voor llama-cpp te vinden om de 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, ziet er goed uit op zijn ideale context van 50K (ik krijg ongeveer 36 t/s)
Qwen3.5-122B-A10B-UD-IQ3_XXS overtreft qua prestaties de Qwen3.5 27B bij contexten boven de 64K.
Ik kan Qwen3.5-35B-A3B-UD-IQ3_S aanpassen om een context van 100K tokens te hanteren, en het past in de VRAM, dus er is geen prestatieverlies
Ik zal gemma-4-31B niet gebruiken op 16 GB VRAM, maar gemma-4-26B zou middelmatig-goed kunnen zijn…, moet ik nog testen.
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 testen om het vermoeden te bevestigen.