3 Min. Lesezeit

Qwen3.8 Flash Next schrumpft von 354 GB auf 29,6 GB

Qwen3.8 Flash NextквантизацияMoE

ISTA-DASLab komprimierte das Coding-MoE-Modell Qwen3.8 Flash Next, indem die Hälfte der Experten entfernt und GSQ- sowie RCO-Quantisierung mit 3,5 bpw eingesetzt wurden. Der angegebene Arbeitssatz sank von 354 GB auf 29,6 GB und behielt den Großteil der Ergebnisse bei SWE-bench Verified und LiveCodeBench v6, was lokale Inferenz erleichtert.

Wie das Modell ohne blinde Quantisierung komprimiert wurde

Interessant ist hier nicht das GGUF-Format selbst, sondern die Kombination aus zwei Hebeln: weniger MoE-Experten und eine nicht einheitliche Quantisierung der verbleibenden Gewichte. In der Hugging-Face-Modellkarte von ISTA-DASLab wird Qwen3.8 Flash Next als MoE-Modell mit 512 Experten beschrieben, das mit GSQ und RCO für llama.cpp-kompatible Umgebungen komprimiert wurde.

Für den veröffentlichten Build wird die Entfernung der Hälfte aller Experten und eine Gewichtspräzision von 3,5 bpw angegeben. Die ursprüngliche BF16-Basis belegte 354 GB, während der Arbeitssatz nach der Verarbeitung 29,6 GB umfasst. Das ist keine kosmetische Verringerung der Dateigröße, sondern der Wechsel in eine andere Klasse verfügbarer Hardware.

GSQ führt eine skalare Post-Training-Quantisierung durch. Die Methode lernt mithilfe einer Gumbel-Softmax-Relaxierung die Zuordnung von Koordinaten zu Gittern und die Skalierungen für Gewichtsgruppen. Ziel ist es, nicht alle Tensoren in ein einziges grobes Schema zu zwängen, obwohl die Empfindlichkeit der einzelnen Modellteile deutlich variiert.

RCO löst die nächste Ebene des Problems: Für jeden Tensor wird einer von K Quantisierungstypen gewählt, während eine exakte Beschränkung der endgültigen Größe eingehalten wird. Ein separater Strafkoeffizient für das Budget muss nicht abgestimmt werden. Technisch ist das stärker als das bloße Ausprobieren von GGUF-Presets, weil die Größe zur Optimierungsbedingung und nicht zum zufälligen Ergebnis von Einstellungen wird.

Der gemeldete Qualitätserhalt wirkt beeindruckend: 91,3 % des ursprünglichen Ergebnisses bei SWE-bench Verified und 98,7 % bei LiveCodeBench v6. Die Materialien der offiziellen Modellkarte belegen GSQ, RCO und die Architektur mit 512 Experten zwar detailliert, erlauben aber keine unabhängige Prüfung aller Kompressions- und Testwerte. Daher betrachte ich sie als Release-Ergebnisse, nicht als reproduzierte Messungen.

Was das für lokale Coding-Modelle verändert

Die praktische Veränderung ist einfach: Ein großes MoE-Modell lässt sich nicht nur durch eine aggressive Quantisierung, sondern durch die gemeinsame Optimierung von Struktur und Gewichtsrepräsentation an lokale Inferenz heranführen. Das senkt den Speicherbedarf und bewahrt einen großen Teil der behaupteten Qualität bei Programmieraufgaben.

Die Entfernung von Experten wäre allerdings der erste Punkt, den ich prüfen würde. Ein durchschnittlicher Benchmarkwert kann Einbrüche bei seltenen Sprachen, ungewöhnlichen Repositories und Aufgaben verdecken, deren Routing auf spezialisierte Experten angewiesen war. Ebenso wichtig sind tatsächlicher Durchsatz, Speicherverbrauch in langen Sitzungen und Qualitätsstabilität außerhalb der zwei genannten Tests.

Der Ansatz wirkt nicht wie ein Trick, sondern wie ein ernsthaftes Kompressionsverfahren für ein vorgegebenes Budget. Die zentrale offene Frage lautet, ob die Qualität auf seltenen MoE-Routen ebenso gut erhalten bleibt wie bei der vertrauten Verteilung von Coding-Benchmarks.

Wir haben Pony Alpha ebenfalls als Modell für risikoarme Pilotprojekte und zur Prüfung einer KI-Architektur unter begrenzten Ressourcen betrachtet. Die Quantisierung von Qwen3.8 Flash Next macht solche Experimente für einen lokalen und kosteneffizienten Einsatz deutlich zugänglicher.