senn-techQwen3.8-Flash-Next im Vier-Tage-Test: Warum die Produktion beim 27B bleibt
Vor vier Tagen hat Alibaba die Gewichte von Qwen3.8-Flash-Next veröffentlicht, ein MoE-Modell mit 125 Milliarden Hauptgewichten plus 51 Milliarden N-Gram-Embeddings bei nur 6 Milliarden aktiven Parametern je Token. Wir hatten das Modell in unserem ersten Beitrag dazu noch aus dem Datenblatt beurteilt. Inzwischen haben wir es vier Tage lang auf unserem 4×-RTX-5090-Host kipc5090 laufen lassen, und das Urteil hat sich verschoben – aber nicht in die Richtung, die man erwarten würde.
Der eigene Build war Pflicht
Am Tag der Veröffentlichung unterstützte kein einziges Serving-Framework die neue Architektur offiziell. vLLM, llama.cpp und SGLang hatten alle nur offene Pull Requests. Wir haben llama.cpp aus dem PR-Branch in einem CUDA-Devel-Container gebaut, da der Host selbst kein nvcc besitzt, und den passenden GGUF-Checkpoint (UD-Q4_K_XL, 104 GiB) von Unsloth geladen, sobald der Upload durch war.
Die erste Anfrage lief, Tool-Calling funktionierte, die Qualitätsbatterie kam auf 8 von 9 bestandenen Tests. Dann kamen zwei Abstürze: einmal ein Segfault mit aktivierter spekulativer Dekodierung, einmal ein Assert, weil der interne Zustand des Sparse-Indexers bei parallelen Slots durcheinanderkam. Der zweite Fehler ließ sich nur mit --parallel 1 umgehen – eine einzelne Anfrage nach der anderen statt echter Nebenläufigkeit. Schon am nächsten Tag landete der Fix im PR, der Slot-Zustand blieb seitdem in Tests mit vier und acht gleichzeitigen Anfragen sauber.
Der Speicherausbau hat mehr gebracht als erwartet
Am vierten Tag kamen zwei zusätzliche RAM-Riegel dazu, von 62 auf 94 GiB. Die Erwartung war, dass nur das Prefill profitiert, weil die N-Gram-Tabelle beim Kaltstart von der SSD in den Seitencache wandert. Tatsächlich stieg auch die Dekodierrate um 18 Prozent, von rund 77 auf 96,8 Token/s. Der Grund: Die Tabelle liegt per Design im Host-Speicher und wird bei jedem einzelnen Token gelesen, nicht nur beim Prefill. Ein größerer Seitencache wirkt sich damit auch auf die laufende Generierung aus.
Der eigentliche Engpass ist keine Stabilitätsfrage mehr
Mit vier und acht parallelen Anfragen lief das Modell inzwischen ohne einen einzigen CUDA error. Der ältere Upstream-Bericht, auf den sich die --parallel 1-Regel ursprünglich stützte, stammte von einer ganz anderen Karte mit CPU-Offload – auf unserer Hardware ließ er sich nicht reproduzieren.
Was blieb, war eine Durchsatzfrage: Acht gleichzeitige Anfragen kamen zusammen auf 50,7 Token/s, eine einzelne allein auf 96,8. --parallel teilt außerdem den nutzbaren Kontext durch die Anzahl der Slots – bei acht Slots blieben von 131.072 Token nur noch 16.384 je Anfrage übrig. Für eine Spur, die mehrere Agenten gleichzeitig bedienen soll, ist das eine Warteschlange, keine Nebenläufigkeit. Das produktive 27B-Modell auf vLLM sättigt dagegen bei 32 bis 64 gleichzeitigen Anfragen mit rund 172 Token/s.
Warum das dichte 27B mit dem großen MoE gleichauf liegt
Aus den GGUF-Metadaten von Flash-Next lassen sich die aktiven Experten ablesen: 512 Experten insgesamt, 10 aktiv je Token, macht rund 6 Milliarden aktive Parameter. Das dichte 27B-Modell aktiviert dagegen alle 27 Milliarden, das 4,5-fache an Rechenarbeit pro Token. Als Faustformel für das „dichte Äquivalent" eines MoE-Modells gilt das geometrische Mittel aus Gesamt- und aktiven Parametern: √(125 × 6) ≈ 27. Genau das dichte Modell, mit dem Flash-Next in der Qualitätsbatterie gleichauf lag.
Wir hatten dasselbe Muster schon einmal gesehen, beim vorherigen Wechsel von einem 122-Milliarden-MoE mit 10 Milliarden aktiven Parametern auf das jetzige 27B: auch dort ein Gleichstand im A/B-Test bei ähnlich vorhergesagtem dichten Äquivalent. Gesamtparameter scheinen vor allem Wissensbreite zu speichern, aktive Parameter die Rechentiefe je Antwort zu bestimmen.
Ein Test, den beide Modelle nicht bestehen
Bei einem stark repetitiven Prompt mit der Aufgabe, ein bestimmtes Wort 440-mal zu zählen, kamen beide Modelle auf falsche Zahlen, und mit aktiviertem Nachdenken verbrauchten beide ihr gesamtes Token-Budget im internen Denkprozess, ohne am Ende eine Antwort auszugeben. Kein Modellunterschied, sondern eine Betriebseigenschaft: Ein langer, repetitiver Prompt kann das Nachdenk-Budget vollständig aufbrauchen, bevor Inhalt generiert wird.
Stand jetzt
Flash-Next läuft bei uns stabil, aber nicht als Produktionsspur. Offen bleibt ein sauberer Vergleich mit dem inzwischen verfügbaren vLLM-Tagesabbild für dasselbe Modell – erst damit lässt sich trennen, ob die Bündelungsschwäche an llama.cpp liegt oder an der Modellarchitektur selbst. Bis dahin bedient unser Produktivsystem weiterhin Text, Reasoning und Vision über das dichte 27B-Modell.
Weiterführende Quellen
Ist Qwen3.8-Flash-Next inzwischen stabil nutzbar?+
Ja, auf unserer Hardware läuft es inzwischen sauber – die anfänglichen Abstürze waren ein Fehler im Slot-Management von llama.cpp, der bereits am nächsten Tag gefixt wurde. Auch mehrere gleichzeitige Anfragen (np=4, np=8) laufen stabil, entgegen einem älteren Upstream-Bericht.
Warum bleibt ihr trotzdem beim 27B-Modell?+
Nicht wegen der Stabilität, sondern wegen der Bündelung: Acht gleichzeitige Anfragen kamen bei Flash-Next auf zusammen 50,7 Token/s, eine einzelne Anfrage allein auf 96,8 Token/s. Das produktive 27B-Modell auf vLLM sättigt dagegen erst bei 32 bis 64 gleichzeitigen Anfragen und liefert dabei rund 172 Token/s.
Warum ist ein 125-Milliarden-Parameter-Modell nicht klüger als ein 27B-Modell?+
Nur 6 der 125 Milliarden Parameter sind pro Token aktiv, der Rest ist ein riesiges Nachschlagewerk. Das geometrische Mittel aus Gesamt- und aktiven Parametern liegt bei rund 27 – genau im Bereich des dichten Modells, mit dem es im Test gleichauf lag.