16 GB VRAM LLM-Benchmarks mit 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 Self-Hosting-Einsatz 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-Diagrammen

In diesem Beitrag dokumentiere ich meine Versuche, so viel Leistung wie möglich in Bezug auf die 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.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-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
nvidia Nemotron-Cascade-2-30B IQ4_XS 18.2 14.6 60/305 115.8 14.7 57/311 113.6 14.7 55/324 103.4
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 (Last) ist eine 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 erzielen kann. Dieses Muster deckt sich mit dem, was Menschen sehen, wenn zu wenig des Modells auf der GPU Platz findet 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 suchen, die für VRAM und Tokens pro Sekunde (Kontextgröße, Batching, -ngl) relevant sind, beginnen Sie mit llama.cpp Quickstart mit CLI und Server.

Für das breitere Leistungsprofil (Durchsatz versus Latenz, VRAM-Limits, parallele Anfragen und wie Benchmarks über Hardware und Laufzeiten hinweg zusammenpassen), sehen Sie LLM-Leistung 2026: Benchmarks, Flaschenhälse & Optimierung.

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

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 auf 32K oder 64K Tokens bewegen, wächst der KV-Cache und der VRAM-Druck steigt. Einige Zeilen zeigen bei 64K einen großen Rückgang der Tokens pro Sekunde, während andere konstant bleiben. Dies ist das Signal, Quantisierungen, Kontextlimits oder Layer-Offloading neu zu überdenken, anstatt anzunehmen, dass das Modell im Allgemeinen „langsam" ist.

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 bringen oder nicht. Also keine q8-Quantisierungen hier mit 200k Kontext :) …

GPU/CPU ist eine Last, gemessen durch nvitop.

llama.cpp versucht bei der auto-konfigurierten Entladung der Layer auf die GPU, 1GB frei zu halten. Wir spezifizieren diesen Parameter manuell über den Kommandozeilenparameter -ngl, aber ich feine hier nicht darauf ab. Es ist nur wichtig zu verstehen, dass, wenn es bei einer Erhöhung der Kontextfenstergröße von 32k auf 64k zu einem signifikanten Leistungsabfall kommt, wir versuchen können, die Geschwindigkeit bei 64k zu erhöhen, indem wir die Anzahl der entladenen Layer feinjustieren.

Testhardware und llama.cpp-Einrichtung

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 genutzte 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

Feingestimmte Läufe

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

Modell Kontext Layers on GPU CPU/CPU load Speed
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 in seinem Sweet-Spot bei 50k Kontext gut aus (ich erhalte ca. 36t/s).
  • Qwen3.5-122B-A10B-UD-IQ3_XXS übertrifft leistungsbezogen das Qwen3.5 27B bei Kontexten über 64K.
  • Ich kann Qwen3.5-35B-A3B-UD-IQ3_S dazu bringen, einen Kontext von 100k Tokens zu verarbeiten, und er passt in die VRAM, sodass es keinen Leistungsabfall gibt.
  • 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 bezweifle es, aber trotzdem werde ich testen, um den Verdacht zu bestätigen.