Qwen3.8-Flash-Next: Von 36 auf 400 t/s Prefill mit zwei RTX 3060
Der Benchmark wurde auf einem Consumer-System mit zwei RTX 3060 (je 12 GB VRAM), einem AMD Ryzen 7800X3D und 128 GB DDR5 durchgeführt, wobei das Modell Qwen3.8-Flash-Next als UD-IQ4_XS-Quantisierung mit 93,7 GB Dateigröße geladen wurde. Der Beitrag identifiziert -sm tensor als systemischen Flaschenhals in llama.cpp: Weil llama.cpp MoE-Gewichte per Op-Offload (ggml-backend.cpp, Zeile 1643) auf GPU schiebt, greift dieser Pfad nur bei einem einzelnen Gerät – bei Tensor-Parallelisierung fallen alle Expert-Matmuls auf die CPU zurück. Die CPU-Auslastung schnellte unter -sm tensor auf 1191 % hoch, während GPU0 und GPU1 nahezu auf 0 % lagen; mit -sm layer sank die CPU-Last auf 139 % bei 49 % bzw. 38 % GPU-Auslastung. Der zweite entscheidende Parameter ist -ubatch: Erst nachdem der Split-Mode-Fehler beseitigt war, entfaltete -ub 2048 seinen Effekt und hob den Prefill-Durchsatz von 135 auf 303 t/s in llama.cpp bzw. auf ~407 t/s in ik_llama.cpp. Ein weiterer Befund betrifft die Expert-Layer-Verteilung: Das Einlagern von MoE-Experten per -ncmoe in den VRAM brachte nur minimale Gewinne (135 → 141 t/s bei -ub 512), verbrauchte aber so viel VRAM, dass -ub 2048 mit Out-of-Memory scheiterte – der VRAM ist als Compute-Buffer für große Batches besser investiert. Der Decode-Throughput verharrt bei rund 12 t/s und ist durch die Speicherbandbreite des DDR5-Kits (etwa 40 GB/s nutzbar bei 3200 MT/s) limitiert; ein im PR-Thread genannter Vergleichswert nennt 28 t/s auf anderer Hardware.
- Modellgröße UD-IQ4_XS: 93,7 GB, basierend auf 125B MoE-Architektur mit nur 6B aktiven Parametern pro Token.
- CUDA 0 läuft auf 16× PCIe-Lanes mit vollen 12 GB, CUDA 1 teilt sich 4× PCIe-Lanes und hält im Desktop-Betrieb 1,5 GB belegt — asymmetrisches Setup.
- Bei -c 262144 (maximaler Kontext) lässt sich -ub 2048 nicht mehr einsetzen, weshalb der Prefill-Durchsatz dort auf ~180–200 t/s fällt und Decode bei 12 t/s bleibt.
- GGML_OP_OFFLOAD_MIN_BATCH=999999 (Op-Offload komplett deaktiviert) lieferte mit -sm tensor 38 t/s — praktisch identisch mit dem normalen -sm-tensor-Wert von 35–41 t/s, was den Befund bestätigt.
- ik_llama.cpp benötigt 106–108 GB RAM (nur 16–18 GB frei), während llama.cpp mit --load-mode mmap dank reclaimable Page-Cache nur 21–32 GB belegt.
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.
Verwandte Beiträge
Qwen3.8-Flash-Next: Von 36 auf 400 t/s Prefill mit zwei RTX 3060
Der Benchmark wurde auf einem Consumer-System mit zwei RTX 3060 (je 12 GB VRAM), einem AMD Ryzen 7800X3D und 128 GB DDR5 durchgeführt, wobei das Modell Qwen3.8-Flash-Next als UD-IQ4_XS-Quantisierung mit 93,7 GB Dateigröße geladen wurde. Der Beitrag identifiziert -sm tensor als systemischen Flaschenhals in llama.cpp: Weil llama.cpp MoE-Gewichte per Op-Offload (ggml-backend.cpp, Zeile 1643) auf GPU schiebt, greift dieser Pfad nur bei einem einzelnen Gerät – bei Tensor-Parallelisierung fallen alle Expert-Matmuls auf die CPU zurück. Die CPU-Auslastung schnellte unter -sm tensor auf 1191 % hoch, während GPU0 und GPU1 nahezu auf 0 % lagen; mit -sm layer sank die CPU-Last auf 139 % bei 49 % bzw. 38 % GPU-Auslastung. Der zweite entscheidende Parameter ist -ubatch: Erst nachdem der Split-Mode-Fehler beseitigt war, entfaltete -ub 2048 seinen Effekt und hob den Prefill-Durchsatz von 135 auf 303 t/s in llama.cpp bzw. auf ~407 t/s in ik_llama.cpp. Ein weiterer Befund betrifft die Expert-Layer-Verteilung: Das Einlagern von MoE-Experten per -ncmoe in den VRAM brachte nur minimale Gewinne (135 → 141 t/s bei -ub 512), verbrauchte aber so viel VRAM, dass -ub 2048 mit Out-of-Memory scheiterte – der VRAM ist als Compute-Buffer für große Batches besser investiert. Der Decode-Throughput verharrt bei rund 12 t/s und ist durch die Speicherbandbreite des DDR5-Kits (etwa 40 GB/s nutzbar bei 3200 MT/s) limitiert; ein im PR-Thread genannter Vergleichswert nennt 28 t/s auf anderer Hardware.
- Modellgröße UD-IQ4_XS: 93,7 GB, basierend auf 125B MoE-Architektur mit nur 6B aktiven Parametern pro Token.
- CUDA 0 läuft auf 16× PCIe-Lanes mit vollen 12 GB, CUDA 1 teilt sich 4× PCIe-Lanes und hält im Desktop-Betrieb 1,5 GB belegt — asymmetrisches Setup.
- Bei -c 262144 (maximaler Kontext) lässt sich -ub 2048 nicht mehr einsetzen, weshalb der Prefill-Durchsatz dort auf ~180–200 t/s fällt und Decode bei 12 t/s bleibt.
- GGML_OP_OFFLOAD_MIN_BATCH=999999 (Op-Offload komplett deaktiviert) lieferte mit -sm tensor 38 t/s — praktisch identisch mit dem normalen -sm-tensor-Wert von 35–41 t/s, was den Befund bestätigt.
- ik_llama.cpp benötigt 106–108 GB RAM (nur 16–18 GB frei), während llama.cpp mit --load-mode mmap dank reclaimable Page-Cache nur 21–32 GB belegt.
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.