Großes Coder-MoE-Modell auf 8-GB-Grafikkarte: Qwen3.8-Flash-Next mit halbierten Experten

Worum es geht

Im Forum r/LocalLLaMA zeigt ein Nutzer, wie sich eine stark komprimierte Coder-Version von Qwen3.8-Flash-Next auf einer Grafikkarte mit nur 8 GB VRAM betreiben lässt, inklusive 262K Token Kontext. Die zugrunde liegende Kompression stammt vom Deep Algorithms and Systems Lab (DASLab) am Institute of Science and Technology Austria (ISTA). Der Nutzer hat daraus eine zusätzlich „vokabular-beschnittene“ GGUF-Variante auf Hugging Face veröffentlicht (Skyrion/Qwen3.8-Flash-Next-GSQ-RCO-Coder-GGUF-Pruned). GGUF ist das Dateiformat, das llama.cpp und darauf aufbauende Programme wie Ollama oder LM Studio nutzen.

Das Modell: Experten entfernen statt nur komprimieren

Qwen3.8-Flash-Next ist ein Mixture-of-Experts-Modell (MoE): Jede Schicht besitzt viele unabhängige Teilnetze („Experten“), und ein kleiner Router wählt pro Token nur einige aus. Hier sind es 512 Experten pro Schicht bei 48 Schichten, 10 sind pro Token aktiv. Die Experten enthalten den Großteil der Parameter (Stellschrauben des Modells), doch es rechnet immer nur ein kleiner Teil. Das Modell hat insgesamt 176,9 Mrd. Parameter und belegt in BF16 etwa 354 GB.

Die Coder-Variante kombiniert zwei Techniken: - Expert Pruning: 50 % der Experten werden komplett entfernt (256 von 512 pro Schicht). Das verkleinert Datei und Speicherbedarf und beschränkt den Router auf weniger Kandidaten. - Quantisierung: Die verbliebenen Gewichte werden mit 3,5 Bit pro Gewicht (bpw) statt 16 Bit gespeichert, mit dem GSQ-Verfahren.

Das ergibt 58,4 GB, davon müssen nur 29,6 GB im Speicher liegen: Die zweite Datei (28,8 GB) ist eine n-Gramm-Nachschlagetabelle, die auch von der Festplatte bedient werden kann. Rechnet man die entfernten Experten auf die ursprüngliche Parameterzahl um, ergeben sich effektiv 1,89 Bit pro Parameter. Viele hielten das Modell deshalb fälschlich für eine 1-Bit-Quantisierung – tatsächlich liegt kein einzelnes Gewicht bei 1,89 Bit, die behaltenen Gewichte haben 3,5 Bit.

Wie die Experten ausgewählt wurden

Die Auswahl erfolgte mit RCO (Riemannian-manifold-basierte Optimierung mit exakten Budgetgrenzen). Statt Experten nach einer Heuristik zu ranken, minimiert RCO die KL-Divergenz (ein Maß für den Unterschied der Ausgaben) zwischen beschnittenem und vollem Modell auf Kalibrierdaten. Da GGUF nur eine einheitliche Expertenzahl pro Modell speichert, muss jede Schicht gleich viele Experten behalten; RCO erzwingt dieses Budget pro Schicht exakt, optimiert aber alle Schichten gemeinsam.

Welche Fähigkeiten überleben, bestimmen die Kalibrierdaten: Eine erste Suche nur mit Code- und Agentendaten entfernte die für Bilder nötigen Experten, die Bildfähigkeit brach ein. Die veröffentlichte Version enthält Vision in den Kalibrierdaten und behält sie. Dafür sind andere Fähigkeiten abgeschwächt; für allgemeine Nutzung empfehlen die Autoren die unbeschnittenen GSQ-RCO-Versionen.

Benchmarks (Herstellerangaben)

Alle Werte wurden bei „xhigh“-Reasoning-Aufwand gemessen.

Das Update vom 17. Oktober verringerte laut Karte Endlosschleifen und hob SWE-bench von 75,60 auf 79,20 und LiveCodeBench von 86,28 auf 87,43. Nur der erste Shard wurde geändert; wer früher geladen hat, muss diesen neu laden. Die Autoren erklären den größeren Verlust bei SWE-bench damit, dass lange Mehrschritt-Aufgaben Fehler anhäufen und Kapazitätsverlust schlechter verkraften.

Die Vokabular-Beschneidung

Der Nutzer entfernte zusätzlich Tokens, die für Coding irrelevant sind (nicht-englische Zeichen). Aus 248.320 Tokens bleiben 130.020 (52,36 %). Die Matrizen token_embd und output schrumpfen dadurch, was rund 409 MB spart. Das klingt wenig, kann laut Nutzer aber bei Systemen mit 8–16 GB VRAM plus 32 GB RAM den Ausschlag geben. Automatische Prüfungen bestätigen, dass Architektur, Metadaten, Tokenizer-Reihenfolge und alle übrigen 1222 Tensoren byteidentisch bleiben. Für andere Sprachen als Englisch ist diese Variante nicht empfohlen. Die Datei der Variante IQ1_M ist 57,993 GB groß.

Was du zum Ausprobieren brauchst

• Grafikkarte: etwa 8 GB VRAM (NVIDIA oder, bei Problemen, per Vulkan-Backend).
• Arbeitsspeicher: rund 24 GB RAM; mit ca. 32 GB Gesamtspeicher geht es ebenfalls, dann aber mit kleinerem Kontext.
• Speicherplatz: ca. 58 GB, idealerweise auf der schnellsten SSD, da die n-Gramm-Tabelle von dort gelesen wird.
• Mac/CPU/Colab: Die Quelle nennt dazu nichts Konkretes; llama.cpp läuft grundsätzlich auch auf macOS und Linux.

Der Trick: Die meisten MoE-Experten bleiben im RAM, die kleinsten kommen für mehr Tempo in den VRAM, die n-Gramm-Tabelle liegt auf der SSD. Mit selektivem MoE-Offloading per Regex erreicht der Nutzer etwa 70 T/s beim Prompt-Processing und rund 8 T/s bei der Generierung, begrenzt durch seine PCIe-3.0-Anbindung. Die Option --n-cpu-moe sei für denselben Zweck langsamer. Wegen mmap ist der erste Lauf langsamer, für Messwerte also zweimal starten. Außerdem empfiehlt er die „qwen sharp“-Chatvorlage, die übermäßiges Nachdenken reduziere. Die Startparameter stehen in den Kommentaren des Reddit-Beitrags.

Einordnung

Das Beispiel zeigt, wie weit sich ein 177-Milliarden-Parameter-Modell durch Kombination aus Experten-Pruning, Low-Bit-Quantisierung und Speicher-Offloading auf Consumer-Hardware drücken lässt, mit nur gut 4 Punkten Verlust bei SWE-bench. Einschränkungen: Es ist ein experimentelles, auf Code, Agenten, Bild und räumliches Denken getrimmtes Modell; allgemeine Fähigkeiten leiden. Die Benchmarks stammen vom Hersteller des Quants, nicht von unabhängiger Seite. Die Tempozahlen (ca. 8 T/s Generierung) sind für Agenten-Workflows eher langsam und hängen stark von RAM, PCIe und SSD ab. Eine Anmerkung des Nutzers: CUDA habe mit 8 GB VRAM Probleme, daher Vulkan. Im Modellkarten-Text wird außerdem die Engine „Strata“ erwähnt, ein Drittanbieter-Tool; eine Bewertung dazu fehlt. Die Lizenz entspricht der des Basismodells Qwen3.8-Flash-Next.