#17 · Qwen 3.8 Flash Next 176B: der belesene Bruder unseres Arbeitspferds

Ein Sprichwort sagt: Chirurgen können viel und wissen nichts, Internisten wissen viel und können nichts. Unser Arbeitspferd, das kleine Qwen 3.8 27B aus #14, übernimmt bei uns die Rolle des Chirurgen: Es programmiert hervorragend und bedient Werkzeuge zuverlässig. Nur weiß es wenig. Aufgrund der kleinen Anzahl von nur 27 Milliarden Parametern ist das auch keine Überraschung, und viele Berichte zeigen, dass es bei Wissensfragen gern ins Halluzinieren kommt. Qwen3.8-Flash-Next ist deutlich größer und kann bei ähnlicher Qualität im Tool-Calling und beim Codieren die Wissenslücken teilweise schließen, was für uns bei Projekt-Analysen, Code-Analysen und Anforderungserhebungen wichtig ist.

Auf unserem Rig läuft das große Modell inzwischen mit 83,9 tok/s bei 100.000 Tokens Kontext, bei einem Kontextfenster von 524.288 Tokens, auf sechs von zehn Grafikkarten. Die übrigen vier bleiben für den Produktivbetrieb frei. Beim Hersteller misst Artificial Analysis 71,9 tok/s, und dort kostet das Modell 0,15 $ je Million Eingabe-Tokens und 0,47 $ je Million Ausgabe-Tokens. Sauber vergleichbar sind die beiden Geschwindigkeiten nicht: anderes Messverfahren, anderer Lastpunkt.

Zur Wissensfrage gibt es bisher nur eine fremde Zahl: Artificial Analysis setzt Qwen3.8-Flash-Next im Intelligence Index auf 42 und das 27B auf 34. Die acht Punkte Abstand sind real, allerdings ist die 42 dort ausdrücklich als Schätzung markiert, die unabhängige Prüfung steht noch aus. Ein Zweikampf ist es ohnehin nicht, denn Artificial Analysis misst die beiden gegen verschiedene Vergleichsgruppen: das 27B gegen Modelle seiner eigenen Größe, das große gegen deutlich größere.

Wo das Wissen sitzt

Das Bild vom Chirurgen hat eine handfeste technische Entsprechung: Wissen liegt in den gespeicherten Parametern, Können zeigt sich beim Rechnen. Das 27B muss beides in 27 Milliarden Parametern unterbringen, und jedes Token läuft durch alle. Wer dem Modell mehr Wissen geben will, legt dort Parameter dazu, die anschließend bei jedem einzelnen Token mitgelesen werden. Je mehr es weiß, desto langsamer wird es.

Qwen3.8-Flash-Next löst diese Kopplung. Der größte Teil des Modells besteht aus 512 Teilnetzen, den Experten. Für jedes Token sucht eine kleine Vorschaltstufe, der Router, zehn davon heraus; ein weiterer Experte läuft immer mit. Gespeichert sind 176 Milliarden Parameter — Artificial Analysis führt 180, weil dort der kleine Vorhersagekopf mitzählt —, gerechnet wird je Token mit sechs Milliarden. Platz für Wissen hat das Modell damit um ein Vielfaches mehr als das 27B, ohne deshalb langsamer zu rechnen.

Von diesen 176 Milliarden entfallen allein 51,2 Milliarden auf eine Nachschlagetabelle; die übrigen rund 125 Milliarden sind das eigentliche Modell. Die Tabelle liegt im Betrieb im Arbeitsspeicher des Rechners und nicht auf den Grafikkarten, rund 102 GB. Damit klärt sich eine Zahl, die zunächst nicht zusammenpasst: Der Download der Fassung, die wir fahren, ist 180 GB groß, auf die Karten kommen davon nur rund 73 GiB.

Aus den sechs Milliarden aktiven Parametern lässt sich ausrechnen, was theoretisch drin sein müsste. Bei etwa einem Byte je Parameter liest die Karte rund 6 GB je Token, und eine 3090 hat 936 GB/s Speicherbandbreite:

6 GB je Token gelesen
bei 936 GB/s Speicherbandbreite
    = rund 156 tok/s, rechnerisch, auf einer einzigen Karte

Gemessen haben wir auf acht Karten 51 tok/s. Woher diese Lücke kommt, ist der interessantere Teil der Arbeit; er steht weiter unten.

Von 28 auf 84 tok/s

Angefangen haben wir mit der Inferenz-Engine ik_llama.cpp und einer auf vier Bit zusammengedrückten Fassung im GGUF-Format, dem Gewichtsformat der llama.cpp-Familie: 28,1 tok/s. Vier Bit heißt, dass jede Gewichtszahl statt mit 16 Bit nur noch mit vier abgelegt ist. In voller Auflösung wäre das Modell 354 GB groß.

Die erste Zahl, die wir überhaupt sahen, war eine schönere: 58,94 tok/s, gemeldet von der Engine selbst, gemessen bei 21 Prompt-Tokens und damit am günstigsten denkbaren Arbeitspunkt. Nach unserer eigenen Messvorschrift — rund 1.000 Tokens Prompt, 256 Ausgabe-Tokens, Median aus drei Läufen, im Folgenden der Kurzlauf — blieben davon 28,1 übrig. Selbst gemeldete Werte sind mit dem Benchmark nicht vergleichbar.

Aus dieser Engine kam am Ende nicht mehr heraus als 29,8 tok/s, und das war bereits die beste der getesteten Spekulationsvarianten. Den Sprung brachte der Wechsel auf einen Fork von vLLM, in dem die Architektur des Modells schon unterstützt war: 51,8 tok/s mit der Acht-Bit-Fassung auf acht Karten. Die Vier-Bit-Fassung legte auf vier Karten 56,1 nach.

Die ersten vier Werte stammen aus dem Kurzlauf, die letzten beiden aus dem Lauf mit 100.000 Tokens Kontext. Beide Messpunkte gehören zum Bild: Der Endstand liefert im Kurzlauf 71 tok/s und bei 100.000 Tokens 83,9. Der lange Lauf ist hier schneller als der kurze.

Der nächste große Schritt kam vom spekulativen Dekodieren. Das Modell bringt dafür einen kleinen Vorhersagekopf mit: Er schlägt mehrere Tokens auf einmal vor, das große Modell prüft sie in einem Durchgang und übernimmt die Treffer. Aus 56,1 wurden damit 79,7 tok/s. Den Rest holte die Erweiterung des Kontextfensters, dazu weiter unten mehr.

Eine Warnung nebenbei: Sechs Zusatzschalter, die alle aus der Dokumentation des Forks stammen, kosteten zusammengeschaltet 23 Prozent Durchsatz. Einzeln nachgemessen haben wir sie nicht; wir fahren seitdem ohne sie.

Mehr Karten machen es langsamer

Der Befund, der am meisten gegen die Intuition geht: Karten dazuzunehmen hilft nicht. Mit der Vier-Bit-Fassung lieferten acht Karten 51,9 tok/s und vier Karten 56,1. In der Acht-Bit-Fassung fielen zehn Karten mit 46,3 tok/s noch hinter die acht mit 51,8 zurück. Vier Gründe stehen dahinter.

Vieles wird auf jeder Karte doppelt gehalten. Der Router mit seinen 512 Einträgen, die fortgeschriebenen Zustände der Schichten und die Tabellen, die Tokens in Zahlenvektoren übersetzen, liegen auf jeder beteiligten Karte in voller Größe. Sichtbar wird das an der Belegung: Acht Karten hielten zusammen 165 GiB, obwohl von der Acht-Bit-Fassung nur 125 GiB überhaupt auf die Karten müssen. Jede zusätzliche Karte kostet damit einen festen Aufschlag an Speicher, bevor sie das erste Token gerechnet hat.

Bei einer einzelnen Anfrage ist die Rechnung zu klein. Jeder der zehn aktiven Experten bekommt genau ein Token. Die Matrix, die dabei multipliziert wird, hat exakt eine Zeile — die Tensorkerne einer 3090 kommen erst bei etwa 32 Zeilen richtig in Fahrt.

Das Zusammenführen läuft über PCIe. Nach jedem Rechenschritt müssen die Karten ihre Zwischenergebnisse abgleichen. NVLink haben unsere Karten nicht, direkte Übertragung von Karte zu Karte ist bei GeForce ohnehin abgeschaltet. Jeder Abgleich geht deshalb über den Hauptspeicher, und je mehr Karten beteiligt sind, desto mehr Stufen hat er.

36 der 48 Schichten sind rekurrent. Sie schreiben einen Zustand fort, den das jeweils nächste Token braucht. Über Tokens hinweg lässt sich das grundsätzlich nicht parallelisieren, gleichgültig wie viele Karten bereitstehen.

Bleibt die Frage, warum es ausgerechnet sechs Karten geworden sind. Die Zahl der Karten, über die eine Gewichtsmatrix zerlegt wird, muss 16 teilen: Der Bildverarbeitungsteil des Modells hat 16 Aufmerksamkeitsköpfe, also 16 parallele Teilrechnungen, die sich nur gleichmäßig verteilen lassen. Sechs ist kein Teiler von 16, der Start bricht mit einer entsprechenden Meldung ab. Sechs Karten gehen deshalb nur zweistufig: Je zwei Karten teilen sich die Matrizen, und drei solche Paare hintereinander teilen sich die 48 Schichten des Modells. Genau dieser Aufbau liefert die 83,9 tok/s — und lässt vier Karten für andere Modelle frei.

Vier Vorschläge, zwei Treffer

Beim spekulativen Dekodieren gibt es eine Stellschraube: wie viele Tokens der Vorhersagekopf auf einmal vorschlagen soll. Die Werte dazwischen sind lehrreich, weil sie eine naheliegende Annahme widerlegen.

Die höchste Trefferquote hat drei Vorschläge, den höchsten Durchsatz vier. Was zählt, ist das Produkt aus Kettenlänge und Quote: Vier Vorschläge bei 58,2 Prozent ergeben 2,3 angenommene Tokens je Zyklus, drei Vorschläge bei 67,1 Prozent nur 2,0. Wer die Konfiguration nach der Akzeptanzrate auswählt, landet auf dem schlechteren Wert.

Nach oben hat das eine Grenze. Bei sechs Vorschlägen kippt es auf 70,8 tok/s, weil die Prüfung der längeren Kette mehr kostet, als die zusätzlichen Treffer einbringen. Wir fahren vier.

Vier Bit ist kein definiertes Maß

Vor dem ersten Start stand die Frage, welche Fassung wir überhaupt herunterladen. Wir haben dafür 214 öffentliche Ablagen mit fertigen Quantisaten erfasst und ihre Dateigrößen summiert. Das Ergebnis ist eine Warnung, die über dieses Modell hinausgeht: Die Namen der Quantisierungsstufen sind zwischen Anbietern nicht vergleichbar.

Dasselbe Etikett — Q4_K_M — steht bei einem Anbieter für 88,9 GB, bei einem anderen für 119,2, bei einem dritten für 135,4 und bei einem vierten für 238,3 GB. Der letzte Wert liegt über der Acht-Bit-Fassung des Modells, die 188,2 GB misst, und ist vermutlich schlicht defekt. Die Ursache ist immer dieselbe: Jeder Anbieter behandelt die große Nachschlagetabelle anders. Manche quantisieren sie mit, manche lassen sie in voller Auflösung im Paket — und entsprechend weit gehen die Größen unter demselben Namen auseinander. Wer nach dem Namen auswählt, kauft die Katze im Sack.

Zur Qualität lässt sich mehr sagen, als man erwarten würde, aber nur für einen Teil der Fassungen. Strukturell quantisieren alle Anbieter ausschließlich die Schicht der 512 Experten; die Aufmerksamkeitsschichten, die Übersetzungstabellen für Tokens und der Vorhersagekopf bleiben unangetastet. Intel misst für seine eigene Vier-Bit-Fassung 99,64 Prozent der Güte der vollen Fassung, gemittelt über vier Benchmarks. Für die GGUF-Quantisate sind uns dagegen keine veröffentlichten Qualitätswerte bekannt. Alle brauchbaren Messwerte stammen von Fassungen im safetensors-Format, das vLLM und verwandte Engines laden; sie auf die GGUF-Dateien zu übertragen, ist plausibel und unbelegt.

Das Kontextfenster, das man selbst einschalten muss

Ausgeliefert wird Qwen3.8-Flash-Next mit 262.144 Tokens Kontext. Die Million, die man häufig liest, entsteht erst durch YaRN — ein Verfahren, das die Positionskodierung streckt und dem Modell ein größeres Fenster gibt, als es trainiert wurde. Eingeschaltet ist das nirgends von selbst; man muss es beim Start konfigurieren.

Wir fahren 524.288 Tokens, also den Faktor 2. Der Durchsatz leidet darunter nicht, im Gegenteil: Die 83,9 tok/s bei 100.000 Tokens sind mit gestrecktem Fenster gemessen und liegen über den 79,7 ohne. Ungeprüft ist dagegen die Ausgabegüte bei 300.000 oder 500.000 Tokens. Wer diesen Bereich ernsthaft nutzt, sollte die Qualität an seinen eigenen Aufgaben nachmessen.

Der Zwischenspeicher für den bereits gelesenen Kontext fasst 793.921 Tokens, verteilt über alle gleichzeitigen Sitzungen. Bei 50.000 Tokens je Sitzung laufen darin etwa 15 Gespräche nebeneinander, bei 200.000 noch vier, bei 400.000 genau eines.

Interessant wird es, wenn mehr angefordert wird, als hineinpasst. Wir haben das mit je eigenen Zufallstexten getestet, damit der Dienst nichts wiederverwenden kann: 405.031 Prompt-Tokens je Anfrage gegen einen Zwischenspeicher von 793.921.

Der Dienst arbeitet die Anfragen sauber hintereinander ab. Keine wurde verdrängt, keine schlug fehl, die Wartezeit wächst linear mit der Schlange. Wer zu viel anfragt, wartet also länger — abgewiesen wird niemand.

Der erste Anlauf zu dieser Messung war auf lehrreiche Weise unbrauchbar: Alle sechs Anfragen trugen denselben Text. Der Dienst erkannte den bereits verarbeiteten Anfang wieder und war nach 6,5 Sekunden fertig. Gemessen hatten wir damit die Wiederverwendung des Zwischenspeichers, nicht den Überlauf.

Wenn keine Fehlermeldung kommt

Wir haben beim Start für einen Parameter einen Namen angegeben, den die Software nicht kennt. Die Folge: Exit-Code 0, keine Fehlermeldung, kein Eintrag im Protokoll des Containers, und die Logdatei bricht nach gut drei Kilobyte mitten in der Initialisierung ab. Von außen sieht das aus wie ein sauberes Ende. Weil der Container so eingestellt war, dass er sich selbst wieder hochfährt, entstanden daraus 35 Startversuche in Folge.

Die naheliegende Vermutung war Speichermangel. Sie war falsch; das Systemprotokoll zeigte keinen einzigen entsprechenden Eintrag. Die Dokumentation der Software beschreibt für diesen Fall übrigens eine sichtbare Fehlermeldung — dieser Container verhält sich anders. Wenn er ohne jede Meldung stirbt, steht ein Tippfehler in einem Startparameter dahinter und kein Speicherproblem.

Der zweite Fall ist heimtückischer. Der Regler, der bestimmt, welchen Anteil des Grafikspeichers sich der Dienst nimmt, lässt sich auf 0,95 stellen. Der Dienst startet damit, baut einen größeren Zwischenspeicher auf und meldet sich als bereit. Jede einzelne Inferenzanfrage scheitert danach mit Speichermangel und HTTP 500. Eine Bereitschaftsprüfung, die nur fragt, ob der Server antwortet, hält diesen Zustand für gesund. Das Maximum liegt bei 0,92.

Was das kleine Modell weiter macht

Das 27B bleibt im Einsatz, und eine Zahl von Artificial Analysis erklärt gut, warum wir es nicht überall einsetzen: Für den Intelligence Index verbrauchte es 200 Millionen Ausgabe-Tokens gegen einen Median von 54 Millionen in seiner Größenklasse. Es ist damit ausgesprochen wortreich. Das deckt sich mit dem, was wir im Nachtrag zu #15 selbst gemessen haben — das Modell verbraucht sein Ausgabebudget zum großen Teil im Denkteil, bevor die eigentliche Antwort beginnt. Zwei unabhängige Wege, derselbe Befund.

Auf das Ausgabebudget des großen Modells haben wir ebenfalls geschaut, allerdings nur mit einer Stichprobe. Der Schalter für den Denkaufwand kennt mehrere Stufen. Eine einzelne Kurzfrage erzeugte auf der niedrigsten Stufe 235 Ausgabe-Tokens, dieselbe Frage auf der Standardstufe 123 — fast das Doppelte für die Anweisung, sich kürzer zu fassen. Eine einzelne Kurzfrage ist keine Messreihe. Wir haben daraus nichts abgeleitet und bleiben beim Standard.

Offen bleibt einiges, und das gehört zum Stand dazu:

• Der Bildverarbeitungsteil steckt im Modell, angesprochen haben wir ihn nie. Für unsere Clients ist das Modell als reines Textmodell eingetragen.
• Die Ausgabegüte bei sehr langem Kontext ist ungeprüft. Die 524.288 Tokens sind eine Durchsatzaussage.
• Für die GGUF-Quantisate gibt es keine veröffentlichten Qualitätswerte. Wir fahren deshalb eine Vier-Bit-Fassung im safetensors-Format, für das überhaupt Messwerte vorliegen.
• Und die Kernfrage aus der Einleitung ist noch offen: Ob das große Modell die Wissenslücken wirklich schließt, wissen wir erst, wenn wir es an unseren eigenen Aufgaben gemessen haben. Der Index von Artificial Analysis ist bis dahin eine Schätzung, und unsere Erwartung ist nur eine Erwartung.