Was bedeutet eine geringe GPU-Auslastung bei der Ausführung eines LLM mit llama.cpp?

Oft bleibt ein Großteil der Ebenen auf der CPU, wodurch die Token-Geschwindigkeit stark abfällt. 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 vom Modell auf der GPU abgelegt werden kann.

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

Ein längerer Kontext vergrößert den KV-Cache und den VRAM-Verbrauch, was die Tokens pro Sekunde verringern oder einen teilweisen Offload erzwingen kann. Ein kürzerer Kontext, kleinere Modelle oder aggressivere Quantisierung helfen, die Geschwindigkeit auf einer einzelnen 16-GB-Karte zu erhalten.

Welche Kompromisse bei der Quantisierung sind relevant, um große Modelle auf 16 GB unterzubringen?

Quantisierungen mit niedrigerer Bitbreite verbrauchen weniger VRAM und können die Anzahl der Token pro Sekunde erhöhen, beeinträchtigen jedoch möglicherweise die Qualität. IQ3- und IQ4-artige Quantisierungen sind übliche Kompromisse für llama.cpp auf einer einzelnen GPU mit 16 GB, wenn ein langer Kontext oder größere Checkpoints erforderlich sind.

Können Mixture-of-Experts-Modelle auf einer einzelnen 16-GB-GPU schnell sein?

MoE-Modelle können eine hohe Token-Rate pro Sekunde erreichen, da bei jedem Forward-Schritt nur ein Teil des Netzwerks ausgeführt wird. Dennoch werden ausreichend VRAM für die aktiven Experten, die Gewichte und den KV-Cache bei der gewählten Kontextlänge benötigt.

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

Passen Sie mit ngl an, wie viele Schichten auf der GPU geladen werden, akzeptieren Sie einen kürzeren Kontext, falls dies für Ihre Aufgabe geeignet ist, oder wechseln Sie zu einer leichteren Quantisierung, damit mehr Schichten auf dem Gerät verbleiben und der KV-Cache-Druck nachlässt.

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

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

Inhaltsverzeichnis

Hier vergleiche ich die Geschwindigkeit verschiedener LLMs, die auf einer GPU mit 16 GB VRAM laufen, und wähle den besten für den Eigenbetrieb aus.

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

Stilisierte Darstellung einer GPU mit VRAM-Blöcken und Benchmark-Diagrammen

In diesem Beitrag dokumentiere ich meine Bemühungen, so viel Leistung wie möglich im Sinne der Geschwindigkeit aus dem System 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,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 und 64K beziehen sich auf die Kontextgrößen.

Der load-Wert oben ist die GPU-Auslastung. Wenn Sie in dieser Spalte eine niedrige Zahl sehen, bedeutet das, dass das Modell größtenteils auf der CPU läuft und auf dieser Hardware keine ordentliche Geschwindigkeit erreichen kann. Dieses Muster tritt auf, wenn zu wenig vom Modell auf der GPU Platz findet oder wenn der Kontext die Berechnungen zurück auf den Host verlagert.

Ü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 (Kontextgröße, Batching, -ngl) wichtig sind, beginnen Sie mit llama.cpp Quickstart mit CLI und Server.

Für ein breiteres Leistungsbild (Durchsatz gegenüber Latenz, VRAM-Limits, parallele Anfragen und wie Benchmarks über verschiedene Hardware und Laufzeitumgebungen zusammenpassen), siehe LLM-Leistung im Jahr 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-basierten AI Coding Agent nutzen
Vergleich der Hugo-Seiten-Übersetzungsqualität - LLMs auf Ollama

Ich habe einen ähnlichen Test für LLMs auf Ollama durchgeführt: Beste LLMs für Ollama auf einer 16-GB-VRAM-GPU.

Wenn Sie Qwen 3.6 27B oder 35B über llama.cpp ausführen und die Generierungsgeschwindigkeit weiter steigern möchten, siehe Qwen 3.6 MTP vs. Standard-Decoding auf einer 16-GB-GPU — MTP spekulatives Dekodieren erhöht den Generierungsdurchsatz für das 27B-dichte Modell um bis zu 67 %, mit Tabellen, die die VRAM-Kosten und den Kompromiss zwischen VRAM-Kosten und Kontextfenster bei jeder --spec-draft-n-max-Stufe zeigen.

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

Wenn Sie von 19K auf 32K oder 64K Tokens gehen, 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 stabil bleiben. Dies ist das Signal, Quants, Kontextlimits oder das Offloading von Ebenen zu überdenken, anstatt vorauszusetzen, dass das Modell allgemein „langsam" ist. Für die Budgetberechnung hinter diesen Zahlen — die genaue Formel für KV-Bytes pro Token, Cache-Typ-Tabellen bei 32K/64K/128K und wie Sie Ihren eigenen Spielraum berechnen — siehe KV-Cache auf 16-GB-GPUs: Langes Kontextfenster tatsächlich unterbringen.

Die Modelle und Quants, die ich zum Testen ausgewählt habe, sollen von mir selbst ausgeführt werden, um zu sehen, ob sie auf dieser Ausrüstung einen guten Nutzen im Sinne von Kosten-Nutzen verhältnismäßig bieten oder nicht. Also keine Q8-Quants hier mit 200k Kontext :) …

GPU/CPU ist die Auslastung, gemessen mit nvitop.

llama.cpp versucht, bei der automatischen Konfiguration des Offloadings von Ebenen auf die GPU, 1 GB frei zu halten. Wir geben diesen Parameter manuell über den Kommandozeilenparameter -ngl an, aber ich feine hier nicht weiter daran, ich brauche nur zu verstehen, dass, wenn es beim Erweitern der Kontextfenstergröße von 32k auf 64k zu einem signifikanten Leistungsverlust kommt, wir die Geschwindigkeit bei 64k versuchen können, zu erhöhen, indem wir die Anzahl der ausgeladenen Ebenen feinjustieren.

Testhardware und llama.cpp-Setup

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

CPU i-14700
RAM 64 GB 6000 Hz (2x32 GB)
GPU RTX-4080
Ubuntu mit NVidia-Treibern
llama.cpp/llama-cli, keine spezifizierte Anzahl an ausgeladenen Ebenen
Anfangliche VRAM-Nutzung, vor dem Start von llama-cli: 300 MB

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

Feingestimmte Läufe

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

Modell	Kontext	Ebenen auf GPU	CPU/CPU-Last	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

Schlüsselerkenntnisse für Builds mit 16 GB VRAM

Mein aktueller Favorit Qwen3.5-27B-UD-IQ3_XXS sieht bei seinem Sweet-Spot mit 50k Kontext gut aus (ich erhalte ca. 36 t/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, 100k Tokens Kontext zu verarbeiten, und es passt in den VRAM, also gibt es keinen Leistungsverlust
Ich werde gemma-4-31B nicht auf 16GB VRAM verwenden, aber gemma-4-26B könnte mittel-gut sein… muss getestet werden.
Muss testen, wie gut Nemotron Cascade 2 und GLM-4.7 Flash REAP 23B funktionieren. Werden sie besser sein als Qwen3.5-35B q3? Ich bezweifle es, aber vielleicht teste ich es trotzdem, um den Verdacht zu bestätigen.