Vad betyder låg GPU-belastning när man kör en LLM med llama.cpp?

Det innebär ofta att många lager stannar på CPU:n, vilket leder till en kraftig minskning av token-hastigheten. Du kan prova att öka GPU-lageravlastningen med ngl, välja en mindre kvantiserad modell eller förkorta kontexten så att mer av modellen får plats på GPU:n.

Hur påverkar ett längre kontextfönster antalet token per sekund på 16 GB VRAM?

Längre kontext ökar KV-cache:n och VRAM-användningen, vilket kan minska antalet token per sekund eller tvinga till delvis offload. Kortare kontext, mindre modeller eller mer aggressiv kvantisering hjälper till att bibehålla hastigheten på ett enda 16 GB-kort.

Vilka kvantiseringskompromisser är avgörande för att få in stora modeller i 16 GB?

Lågre bitkvantiseringar använder mindre VRAM och kan öka antalet token per sekund, men kan försämra kvaliteten. IQ3- och IQ4-stilar är vanliga kompromisser för llama.cpp på en 16 GB GPU när du behöver lång kontext eller större checkpointar.

Kan modeller med blandning av experter vara snabba på en enda 16 GB GPU?

MoE-modeller kan uppnå höga token per sekund eftersom endast en del av nätverket körs vid varje framåtsteg, men du behöver fortfarande tillräckligt med VRAM för aktiva experter samt vikter och KV-cachen vid ditt valda kontextlängd.

Vad kan du försöka göra om 64K-kontext är mycket långsammare än 32K på samma GPU?

Justera antalet lager som laddas på GPU:n med ngl, acceptera en kortare kontext om det passar din uppgift, eller byt till en lättare kvantisering så att fler lager kan behållas på enheten och trycket på KV-cachen minskar.

16 GB VRAM LLM-benchmarks med llama.cpp (hastighet och kontext)

Tokenhastighet för llama.cpp på 16 GB VRAM (tabeller).

Sidinnehåll

Här jämför jag hastigheten för flera LLM-modeller som körts på en GPU med 16 GB VRAM och väljer den bästa för självhostning.

Jag har kört dessa LLM-modeller med llama.cpp med kontextfönster på 19K, 32K och 64K token.

Stylized GPU with VRAM blocks and benchmark-style charts

I detta inlägg dokumenterar jag mina försök att utnyttja så mycket prestanda som möjligt, i termer av hastighet.

Jämförelsetabell för LLM-hastighet (token per sekund och VRAM)

Modell	Storlek	19K VRAM	19K GPU/CPU	19K T/s	32K VRAM	32K Last	32K T/s	64K VRAM	64K Last	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 och 64K är kontextstorlekar.

“Last” ovan är en “GPU Last”. Om du ser ett lågt nummer i denna kolumn betyder det att modellen körs mestadels på CPU:n och inte kan uppnå någon anständig hastighet på denna hårdvara. Det mönstret matchar vad folk ser när för lite av modellen ryms på GPU:n eller när kontexten tvingar arbete tillbaka till värdmaskinen.

Om llama.cpp, LLM-prestanda, OpenCode och andra jämförelser

Om du vill ha installationsvägar, exempel på llama-cli och llama-server, samt flaggor som är viktiga för VRAM och token per sekund (kontextstorlek, batching, -ngl), börja med llama.cpp Quickstart med CLI och Server.

För den bredare prestandabilden (genomströmning kontra latens, VRAM-gränser, parallella förfrågningar och hur benchmarkar passar ihop över hårdvara och runtime-miljöer), se LLM-prestanda 2026: Benchmarkar, flaskhalsar & optimering.

Svarskvaliteten analyseras i andra artiklar, till exempel:

Bästa LLM:er för OpenCode - Testat lokalt. Du kan läsa mer om Opencode i OpenCode Quickstart: Installera, konfigurera och använd Terminal AI Coding Agent.
Jämförelse av Hugo-sidöversättningskvalitet - LLM:er på Ollama

Jag körde liknande tester för LLM:er på Ollama: Bästa LLM:er för Ollama på GPU med 16GB VRAM.

Varför kontextlängd ändrar token per sekund

När du går från 19K till 32K eller 64K token växer KV-cachen och VRAM-trycket ökar. Vissa rader visar en stor minskning av token per sekund vid 64K medan andra är oförändrade, vilket är ett tecken på att man bör granska kvantiseringsnivåer, kontextgränser eller lageroffloading istället för att anta att modellen är “långsam” generellt.

De modeller och kvantiseringsnivåer jag valt att testa är för att jag själv ska se om de ger en bra vinst i termer av kostnad/förhållande på denna utrustning eller inte. Så inga q8-kvantiseringsnivåer här med 200k kontext :) …

GPU/CPU är en last, mätt med nvitop.

När llama.cpp konfigurerar lagren automatiskt för att lossa till GPU:n försöker den hålla 1GB ledigt. Vi specificerar denna parameter manuellt via kommandoradsparametern -ngl, men jag finjusterar den inte här, behöver bara förstå att om det finns en betydande prestanda-försämring när kontextfönstret ökar från 32k till 64k - kan vi försöka öka hastigheten på 64k genom att finjustera antalet lossade lager.

Testhårdvara och llama.cpp-uppsättning

Jag testade LLM-hastigheten på en PC med denna konfiguration:

CPU i-14700
RAM 64GB 6000Hz (2x32GB)
GPU RTX-4080
Ubuntu med NVidia-drivrutiner
llama.cpp/llama-cli, inga lossade lager specificerade
Initial VRAM-användning, innan start av llama-cli: 300MB

Extra körningar vid 128K kontext (Qwen3.5 27B och 122B)

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

Finjusterade körningar

För vissa intressanta modeller och kvantiseringsnivåer försökte jag hitta speciella llama-cpp-kommandoradsparametrar för att bättre utnyttja VRAM. Här är vad jag lyckades uppnå:

Modell	Kontext	Lager på GPU	CPU/CPU Last	Hastighet
Qwen3.5-27B-IQ4_XS.gguf	18k	65	98%/100%	38.0
Qwen3.5-27B-IQ4_XS.gguf	64k	53	33%/488%	15.7

Slutsatser för byggen med 16 GB VRAM

Min nuvarande favorit Qwen3.5-27B-UD-IQ3_XXS ser bra ut i sitt “sweetspot” med 50k kontext (jag får ca 36t/s)
Qwen3.5-122B-A10B-UD-IQ3_XXS övertar prestandamässigt Qwen3.5 27B på kontexter över 64K.
Jag kan köra Qwen3.5-35B-A3B-UD-IQ3_S för att hantera kontext på 100k token, och den ryms i VRAM, så ingen prestandaförsämring.
Jag kommer inte använda gemma-4-31B på 16GB VRAM, men gemma-4-26B kan vara måttligt bra…, behöver testa.
Behöver testa hur väl Nemotron cascade 2 och GLM-4.7 Flash REAP 23B fungerar. Kommer de vara bättre än Qwen3.5-35B q3? Jag tvivlar, men kommer testa för att bekräfta misstanken.