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

Dies führt dazu, dass viele Schichten auf der CPU verbleiben, was zu einem starken Rückgang der Token-Geschwindigkeit führt. Sie können versuchen, die GPU-Schicht-Offload mit ngl zu erhöhen, eine kleinere Quantisierung zu wählen oder den Kontext zu verkürzen, damit mehr des Modells auf die GPU passt.

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

Ein längeres Kontextfenster vergrößert den KV-Cache und den VRAM-Verbrauch, was die Token pro Sekunde reduzieren oder ein teilweises Offloading erzwingen kann. Ein kürzeres Kontextfenster, kleinere Modelle oder aggressivere Quantisierung helfen, die Geschwindigkeit auf einer einzelnen 16-GB-Karte aufrechtzuerhalten.

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

Niedrigere Bit-Qualitäten verbrauchen weniger VRAM und können die Tokens pro Sekunde erhöhen, beeinträchtigen jedoch möglicherweise die Qualität. IQ3- und IQ4-Style-Qualitäten sind häufige Kompromisse für llama.cpp auf einer einzelnen GPU mit 16 GB, wenn Sie einen langen Kontext oder größere Checkpoints benötigen.

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

MoE-Modelle können hohe Tokens pro Sekunde erreichen, da bei jedem Forward-Schritt nur ein Teil des Netzwerks aktiv ist. Dennoch benötigen Sie ausreichend VRAM für die aktiven Experten sowie die Gewichte und den KV-Cache bei der gewählten Kontextlänge.

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

Passen Sie die Anzahl der auf der GPU geladenen Schichten mit ngl an, 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 Druck auf den KV-Cache abnimmt.

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

Token-Geschwindigkeit von llama.cpp mit 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 die Selbsthosting-Nutzung aus.

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

Stylisierte GPU mit VRAM-Blöcken und Benchmark-ähnlichen Diagrammen

In diesem Beitrag dokumentiere ich meine Versuche, so viel Leistung in Bezug auf Geschwindigkeit wie möglich herauszuholen.

LLM-Geschwindigkeitsvergleichstabelle (Tokens pro Sekunde und VRAM)

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

Die Last oben bezieht sich auf die GPU-Last. 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 anständige Geschwindigkeit erreichen kann. Dieses Muster entspricht dem, was man beobachtet, wenn zu wenig des Modells auf die GPU passt oder wenn der Kontext die Arbeit zurück auf den Host schiebt.

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

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

Für das breitere Leistungsbild (Durchsatz versus Latenz, VRAM-Grenzen, parallele Anfragen und wie Benchmarks über Hardware und Laufzeiten hinweg zusammenpassen), sehen Sie sich LLM-Leistung 2026: Benchmarks, Engpässe & Optimierung an.

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

Beste LLMs für OpenCode - Lokal getestet. Mehr über OpenCode erfahren Sie in OpenCode Schnellstart: Installieren, Konfigurieren und Nutzen des Terminal-AI-Coding-Agents
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.

Wenn Sie Qwen 3.6 27B oder 35B über llama.cpp ausführen und die Generierungsgeschwindigkeit weiter steigern möchten, sehen Sie sich Qwen 3.6 MTP vs. Standard-Decodierung auf 16GB GPU an — MTP-spekulative Decodierung fügt bis zu 67 % Generierungsdurchsatz für das 27B-dichte Modell hinzu, mit Tabellen, die die VRAM-Kosten und den Kompromiss zwischen Kontextfenster bei jedem --spec-draft-n-max-Level zeigen.

Warum Kontextlänge Tokens pro Sekunde verändert

Wenn Sie von 19K auf 32K oder 64K Tokens wechseln, 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 gleich bleiben, was ein Signal ist, Quants, Kontextgrenzen oder Layer-Offloading zu überprüfen, anstatt anzunehmen, dass das Modell allgemein „langsam“ ist.

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

GPU/CPU ist eine Last, gemessen von nvitop.

llama.cpp versucht bei der Auto-Konfiguration des Entladens von Schichten auf die GPU, 1 GB frei zu halten. Wir geben diesen Parameter manuell über den Befehlszeilenparameter -ngl an, aber ich optimiere ihn hier nicht, sondern möchte nur verstehen, dass, wenn es bei Erhöhung der Kontextfenstergröße von 32k auf 64k zu einem signifikanten Leistungsabfall kommt, wir versuchen können, die Geschwindigkeit bei 64k durch Feinabstimmung der Anzahl der entladenen Schichten zu erhöhen.

Testhardware und llama.cpp-Setup

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 Schichten angegeben
Anfangs verwendeter VRAM, bevor llama-cli gestartet wurde: 300MB

Zusätzliche Runs bei 128K Kontext (Qwen3.5 27B und 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

Optimierte Runs

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

Modell	Kontext	Schichten 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

Erkenntnisse für 16 GB VRAM Builds

Mein aktueller Favorit Qwen3.5-27B-UD-IQ3_XXS sieht bei seinem Sweetspot von 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, Kontext von 100k Tokens zu handhaben, und es passt in den VRAM, also kein Leistungsabfall
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 trotzdem, könnte testen, um den Verdacht zu bestätigen.