16-GB-VRAM-LLM-Benchmarks mit llama.cpp (Geschwindigkeit und Kontext)
Token-Geschwindigkeit von llama.cpp auf 16 GB VRAM (Tabellen).
Hier vergleiche ich die Geschwindigkeit mehrerer LLMs, die auf einer GPU mit 16 GB VRAM laufen, und wähle die beste Option für das Selbst-Hosting aus.
Ich habe diese LLMs mit llama.cpp ausgeführt und dabei Kontextfenster mit 19K, 32K und 64K Tokens getestet.
Stilisierte Darstellung einer GPU mit VRAM-Blöcken und Benchmark-Diagrammen
In diesem Beitrag dokumentiere ich meine Versuche, aus der Hardware im Sinne von Geschwindigkeit so viel Leistung wie möglich herauszuholen.
Vergleichstabelle der LLM-Geschwindigkeit (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 |
| 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 load-Spalte oben ist die 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 brauchbare Geschwindigkeit erzielen kann. Dieses Muster tritt auf, wenn zu wenig des Modells auf der GPU platziert werden kann oder wenn der Kontext die Arbeit wieder auf den Host (CPU) zurückverlagert.
Zu llama.cpp, LLM-Leistung, OpenCode und anderen Vergleichen
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) wichtig sind, beginnen Sie mit llama.cpp-Quickstart mit CLI und Server.
Für das umfassendere Leistungsprofil (Durchsatz versus Latenz, VRAM-Limits, parallele Anfragen und wie sich Benchmarks über Hardware- und Laufzeitumgebungen hinweg zusammensetzen), siehe LLM-Leistung 2026: Benchmarks, Engpässe & Optimierung.
Die Qualität der Antworten wird in anderen Artikeln analysiert, zum Beispiel:
- Beste LLMs für OpenCode - Lokal getestet. Weitere Informationen zu Opencode finden Sie in OpenCode Quickstart: Installation, Konfiguration und Nutzung des Terminal-AI-Coding-Agenten
- 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 GPU mit 16 GB VRAM.
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 16GB GPU — MTP-spekulative Decodierung erhöht den Generierungsdurchsatz für das 27B-dichte Modell um bis zu 67 %, mit Tabellen, die die VRAM-Kosten und den Kompromiss bei der Kontextfenstergöße auf jeder --spec-draft-n-max-Stufe zeigen.
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 starken Rückgang der Tokens pro Sekunde bei 64K, während andere stabil bleiben. Das ist ein Signal, Quants, Kontextlimits oder Layer-Offloading zu überdenken, anstatt anzunehmen, das Modell sei allgemein „langsam“. 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: Langer Kontext wirklich unterbringen.
Die Modelle und Quants, die ich zum Testen ausgewählt habe, dienen dazu, sie selbst auszuführen und zu sehen, ob sie auf dieser Ausrüstung einen guten Gewinn im Sinne von Kosten-Nutzen-Verhältnis liefern. Also hier keine q8-Quants mit 200k Kontext :) …
GPU/CPU ist eine Last, gemessen mit nvitop.
llama.cpp versucht bei der automatischen Konfiguration der Layer-Entladung auf die GPU, 1 GB frei zu halten.
Wir geben diesen Parameter manuell über den Kommandozeilenparameter -ngl an, aber ich optimiere ihn hier nicht im Detail.
Es reicht zu verstehen, dass, wenn es beim Erweitern des Kontextfensters von 32k auf 64k zu einem signifikanten Leistungsabfall kommt, man die Geschwindigkeit bei 64k versuchen kann zu erhöhen, indem man die Anzahl der entladenen Layer justiert.
Testhardware und llama.cpp-Setup
Ich habe die LLM-Geschwindigkeit auf einem PC mit folgender Konfiguration getestet:
- CPU i-14700
- RAM 64GB 6000Hz (2x32GB)
- GPU RTX-4080
- Ubuntu mit NVidia-Treibern
- llama.cpp/llama-cli, keine entladenen Layer spezifiziert
- Anfangs-VRAM-Nutzung, vor dem Start von llama-cli: 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 |
Optimierte Läufe
Für einige interessante Modelle und Quants habe ich versucht, spezielle llama-cpp-Kommandozeilenparameter zu finden, um das VRAM besser auszunutzen. Hier ist das, was ich erzielen konnte:
| Modell | Kontext | Layer 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-Setups
- Mein aktueller Favorit Qwen3.5-27B-UD-IQ3_XXS sieht auf seinem Sweetspot mit 50k Kontext gut aus (ich erziele ca. 36 T/s)
- Qwen3.5-122B-A10B-UD-IQ3_XXS übertrifft leistungsseitig den Qwen3.5 27B bei Kontexten über 64K.
- Ich kann den Qwen3.5-35B-A3B-UD-IQ3_S dazu bringen, einen Kontext von 100k Tokens zu verarbeiten, und er passt ins VRAM, daher gibt es keinen Leistungsabfall
- Ich werde gemma-4-31B auf 16GB VRAM nicht verwenden, aber gemma-4-26B könnte mittel-mäßig 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 teste trotzdem, um den Verdacht zu bestätigen.
- Warum der 25–34B-Bereich der Standard für 2026 ist, sobald man 24 GB hat, und warum ein Q4 Qwen3.8-27B wirklich nicht auf diese 16-GB-Karte gehört, siehe Die effiziente Frontier offener Modelle in 2026.