Was bedeutet eine niedrige GPU-Auslastung beim Ausführen eines LLM mit llama.cpp?

Dies führt häufig dazu, dass viele Schichten auf der CPU verbleiben, wodurch die Token-Geschwindigkeit stark abnimmt. Sie können versuchen, das GPU-Layer-Offloading über ngl zu erhöhen, eine kleinere Quantisierung zu wählen oder den Kontext zu verkürzen, damit mehr des Modells auf der GPU untergebracht werden kann.

Wie wirkt sich ein längeres Kontextfenster auf die Token pro Sekunde bei 16 GB VRAM aus?

Ein längerer Kontext vergrößert den KV-Cache und den VRAM-Verbrauch, was die Token pro Sekunde reduzieren oder eine teilweise Offloading erzwingen kann. Ein kürzerer Kontext, kleinere Modelle oder aggressiveres Quantisieren helfen, die Geschwindigkeit auf einer einzigen 16-GB-Karte hochzuhalten.

Welche Kompromisse bei der Quantisierung sind für die Nutzung großer Modelle auf 16 GB relevant?

Niedrigere Bit-Quantisierungen verbrauchen weniger VRAM und können die Token pro Sekunde erhöhen, beeinträchtigen jedoch möglicherweise die Qualität. IQ3- und IQ4-ähnliche Quantisierungen sind übliche Kompromisse für llama.cpp auf einer 16-GB-GPU, wenn lange Kontexte oder größere Checkpoints erforderlich sind.

Können Mixture-of-Experts-Modelle auf einer einzigen 16-GB-GPU schnell laufen?

MoE-Modelle können eine hohe Tokenpro-Sekunden-Rate erreichen, da bei jedem Forward-Schritt nur ein Teil des Netzwerks aktiv ist. Dennoch ist genügend VRAM für die aktiven Experten sowie für die Gewichte und den KV-Cache bei der gewählten Kontextlänge erforderlich.

Was können Sie versuchen, wenn ein Kontext von 64K auf derselben GPU deutlich langsamer ist als ein Kontext von 32K?

Stellen Sie mit ngl ein, wie viele Schichten auf der GPU geladen werden, akzeptieren Sie einen kürzeren Kontext, falls dies Ihrer Aufgabe entspricht, oder wechseln Sie zu einer leichteren Quantisierung, damit mehr Schichten auf dem Gerät verbleiben und der KV-Cache-Druck nachlässt.

LLM-Benchmarks mit 16 GB VRAM und llama.cpp (Geschwindigkeit und Kontext)

Token-Geschwindigkeit von llama.cpp auf 16 GB VRAM (Tabellen).

Inhaltsverzeichnis

Hier vergleiche ich die Geschwindigkeit verschiedener LLMs, die auf einer GPU mit 16 GB VRAM laufen, und wähle das beste Modell für den Selbst-Hosting-Einsatz aus.

Ich habe diese LLMs mit llama.cpp mit Kontextfenstern von 19K, 32K und 64K Tokens ausgeführt.

Stylized GPU with VRAM blocks and benchmark-style charts

In diesem Beitrag dokumentiere ich meine Versuche, so viel Leistung wie möglich im Sinne von Geschwindigkeit herauszuholen.

LLM-Geschwindigkeitsvergleichstabelle (Tokens pro Sekunde und VRAM)

Modell	Größe	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 und 64K sind die Kontextgrößen.

Die oben genannte load ist eine GPU-Auslastung. Wenn Sie in dieser Spalte eine niedrige Zahl sehen, bedeutet das, dass das Modell hauptsächlich auf der CPU läuft und auf dieser Hardware keine ordentliche Geschwindigkeit erzielen kann. Dieses Muster stimmt mit dem überein, was man beobachtet, wenn zu wenig vom Modell auf die GPU passt oder wenn der Kontext die Arbeit zurück zum Host schiebt.

Über llama.cpp, LLM-Leistung, OpenCode und andere Vergleiche

Wenn Sie Installationspfade, llama-cli- und llama-server-Beispiele sowie die Flags benötigen, die für VRAM und Tokens pro Sekunde relevant sind (Kontextgröße, Batching, -ngl), beginnen Sie mit llama.cpp Quickstart mit CLI und Server.

Für das breitere Leistungsbild (Durchsatz gegenüber Latenz, VRAM-Limits, parallele Anfragen und wie Benchmarks über Hardware und Laufzeitumgebungen zusammenpassen), sehen Sie LLM-Leistung in 2026: Benchmarks, Engpässe & Optimierung.

Die Qualität der Antworten wird in anderen Artikeln analysiert, zum Beispiel:

Beste LLMs für OpenCode - Lokal getestet. Sie können mehr über Opencode in OpenCode Quickstart: Installieren, konfigurieren und den Terminal-AI-Coding-Agenten nutzen lesen.
Vergleich der Hugo-Seiten-Übersetzungsqualität - LLMs auf Ollama

Ich habe ähnliche Tests für LLMs auf Ollama durchgeführt: Beste LLMs für Ollama auf 16GB VRAM GPU.

Warum die Kontextlänge die Tokens pro Sekunde verändert

Wenn Sie sich von 19K zu 32K oder 64K Tokens bewegen, wächst der KV-Cache und der VRAM-Druck steigt. Einige Zeilen zeigen einen großen Rückgang der Tokens pro Sekunde bei 64K, während andere flach bleiben; dies ist das Signal, Quantisierungen, Kontextlimits oder Layer-Offloading zu überprüfen, anstatt anzunehmen, das Modell sei allgemein „langsam".

Die Modelle und Quantisierungen, die ich zum Testen ausgewählt habe, dienen dazu, selbst zu prüfen, ob sie auf dieser Ausrüstung einen guten Nutzen im Sinne von Kosten/Nutzen bieten oder nicht. Also hier keine q8-Quantisierungen mit 200k Kontext :) …

GPU/CPU ist eine Auslastung, gemessen von nvitop.

llama.cpp versucht beim automatischen Konfigurieren der Entladung von Layern auf die GPU, 1 GB frei zu halten. Wir geben diesen Parameter manuell über den Befehlszeilenparameter -ngl vor, aber ich feine hier nicht daran, sondern möchte nur verstehen, dass, wenn es bei Erhöhung der Kontextfenstergröße von 32k auf 64k einen signifikanten Leistungsabfall gibt, wir versuchen können, die Geschwindigkeit bei 64k zu erhöhen, indem wir die Anzahl der entladenen Layern anpassen.

Testhardware und llama.cpp-Einrichtung

Ich habe die LLM-Geschwindigkeit auf einem PC mit dieser Konfiguration getestet:

CPU i-14700
RAM 64GB 6000Hz (2x32GB)
GPU RTX-4080
Ubuntu mit NVidia-Treibern
llama.cpp/llama-cli, keine entladenen Layern angegeben
Anfangs genutzter VRAM, bevor llama-cli gestartet wurde: 300MB

Zusätzliche Läufe bei 128K Kontext (Qwen3.5 27B und 122B)

Modell	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

Feinjustierte Läufe

Für einige interessante Modelle und Quantisierungen habe ich versucht, spezielle llama-cpp-Befehlszeilenparameter zu finden, um die VRAM besser zu nutzen. Hier ist, was ich erreichen konnte:

Modell	Kontext	Layern auf GPU	CPU/CPU-Auslastung	Geschwindigkeit
Qwen3.5-27B-IQ4_XS.gguf	18k	65	98%/100%	38.0
Qwen3.5-27B-IQ4_XS.gguf	64k	53	33%/488%	15.7

Erkenntnisse für 16 GB VRAM-Systeme

Mein aktueller Favorit Qwen3.5-27B-UD-IQ3_XXS sieht auf seinem Sweet-Spot bei 50k Kontext gut aus (ich erhalte ca. 36t/s).
Qwen3.5-122B-A10B-UD-IQ3_XXS übertrifft leistungsseitig den Qwen3.5 27B bei Kontexten über 64K.
Ich kann Qwen3.5-35B-A3B-UD-IQ3_S dazu bringen, Kontexte von 100k Tokens zu bewältigen, und es passt in den VRAM, sodass keine Leistungsabnahme eintritt.
Ich werde gemma-4-31B auf 16GB VRAM nicht verwenden, aber gemma-4-26B könnte mittelgut sein…, muss getestet werden.
Es muss getestet werden, wie gut Nemotron cascade 2 und GLM-4.7 Flash REAP 23B funktionieren. Werden sie besser sein als Qwen3.5-35B q3? Ich zweifle, werde es aber trotzdem testen, um den Verdacht zu bestätigen.