Qwen3.8-Flash-Next im Detail: Gated DeltaNet, Sparse Attention und N-Gram-Speicher

Qwen3.8-Flash-Next ist ein multimodales Modell mit offenen Gewichten, veröffentlicht am 26. August 2026. Seine Architektur ist im Technical Report, in der Model Card und in der Checkpoint-Konfiguration des Qwen-Teams dokumentiert. Sie kombiniert rekurrentes Token-Mixing, selektive Attention, geroutete Experten, vier Residual-Zweige und eine große N-Gram-Lookup-Tabelle. Hier geht es um den veröffentlichten Checkpoint. Qwen beschreibt das separate API-Modell Qwen3.8-Flash als auf Flash-Next basierend, aber mit zusätzlichen Produktivfunktionen; beide Namen bezeichnen deshalb nicht einfach denselben Checkpoint.¹²

Entscheidend ist die Trennung dreier Speicherformen: Gated DeltaNet (GDN) hält einen rekurrenten Zustand fester Größe. Qwen Sparse Attention (QSA) ruft ausgewählte Token aus dem aktuellen Kontext ab. Die N-Gram-Tabelle enthält gelernte Parameter, die kurze Tokenfolgen adressieren. Sie ist weder der KV-Cache der Anfrage noch ein Router zur Auswahl von MoE-Experten.³ Der VRAM-Leitfaden behandelt die getrennten Speicherbudgets für Gewichte und Inferenzzustand.

Der veröffentlichte Stack

Die MI350P-Serving-Fallstudie verfolgt diese Architektur bis zu tatsächlichen GDN-Zustands-Writes, K/V-Wiederverwendung zwischen QSA-Verifikationszeilen und MoE-Dispatch-Kerneln. Sie prüft den gemessenen Konfigurationsverlauf und benennt Grenzen bei Durchsatz, Latenz und numerischer Korrektheit.

Die Model Card nennt 125 Mrd. + 51 Mrd. + 4 Mrd. für Backbone, N-Gram-Tabelle und MTP. Die Angabe 6 Mrd. aktiv beschreibt die sparse Berechnung im Hauptmodell; die übrigen gespeicherten Parameter verschwinden nicht aus dem Speicherbudget. Bei zwei Byte pro unquantisiertem BF16-Parameter benötigen allein die 51 Mrd. Tabellenparameter rechnerisch etwa 102 GB dezimal Rohspeicher, ohne Allocator-, Sharding- und Caching-Overhead. Das ist eine Rechnung aus der veröffentlichten Parameterzahl und dem Datentyp, kein gemessener Serving-Footprint.²⁴

Der Weg eines Tokens durch das Modell

1. Hybrides Token-Mixing. Der Stack mit 48 Schichten enthält 36 GDN- und zwölf QSA-Schichten. GDN schreibt den bisherigen Verlauf in einen rekurrenten Zustand und benötigt in diesen Schichten keinen KV-Eintrag pro Token. Ein endlicher Zustand bietet jedoch keinen exakten Direktzugriff auf jedes frühere Token. Deshalb besitzt jede vierte Schicht Attention über die Sequenz. Im Continued Pretraining ersetzte Qwen die dichte Attention an diesen Stellen durch QSA. Die veröffentlichte Konfiguration nennt diese Stellen weiterhin full_attention, während der Report ihre Implementierung als QSA beschreibt.³⁴

2. Die zwei Stufen von QSA. Der Indexer projiziert Token zunächst auf leichte Keys, mittelt Gruppen von vier Keys zu Micro-Block-Keys und bewertet diese Blöcke mit vier Query-Heads und einem gemeinsamen Key-Head. RoPE wird nach dem Pooling angewandt, damit Vektoren verschiedener Positionen nicht mit unterschiedlichen Rotationsphasen gemittelt werden. Pro Query beträgt das dokumentierte Budget 512 vollständig gewählte Blöcke = 2.048 Token, zuzüglich eines eventuell unvollständigen letzten Blocks. Die eigentliche Attention verarbeitet anschließend die ausgewählten Token mit 24 Query-Heads und zwei KV-Heads der Dimension 256.³²⁴ Die vierfache Kompression verringert die Prefill-Arbeit des Indexers, macht das Gesamtsystem aber nicht unabhängig von der Kontextlänge. Qwens gemeldete Beschleunigungen von 7,6× im Prefill und 4,9× im Decode bei 1 Mio. Kontext vergleichen das gesamte QSA-Attention-Modul mit dichter Attention auf Kernel-Ebene. Gemessen wurden Chunked Prefill mit 16.000-Token-Chunks bei Batchgröße 1 und Decode mit Batchgröße 4 sowie drei MTP-Schritten; es sind keine Ende-zu-Ende-Latenzen des gesamten Modells.³

3. Gated Residual. In jeder Teilschicht werden die vier Residual-Zweige separat normalisiert. Ein datenabhängiges, elementweises Gate bestimmt, wie viel jeder Zweig zum Eingang der Teilschicht beiträgt. Das Ergebnis wird mit einem datenabhängigen Skalar pro Zweig zurückgeschrieben, den eine gelernte Projektion aus den normalisierten Zweigen berechnet. Das ist etwas anderes als MoE-Routing: Die Zweige steuern den Informationsfluss zwischen Schichten, während der Expert-Router für ein Token Feedforward-Gewichte auswählt.³

4. N-Gram-Lookup. In Schicht 2 werden kurze Tokenfolgen bis zur aktuellen Position – im veröffentlichten Modell Bigramme und Trigramme – auf Zeilen gelernter Embeddings gehasht. Der Checkpoint nennt eine N-Gram-Vokabularbasis von 20 Millionen Einträgen, acht Hash-Heads pro N-Gram, Embedding-Dimension 2.560 und ple_layer_ids: [2].²⁴ Der gelesene Vektor wird kontextabhängig in den Residual-Strom eingefügt. Die Transformers-Implementierung nutzt zusätzlich eine dilatierte tiefenweise Faltung und hält beim Decoding einen kleinen N-Gram-/Faltungszustand vor; die große Parametertabelle selbst ist vom KV-Cache der Anfrage zu unterscheiden.⁵ Weil die Adressen von Token-IDs abhängen, können Zeilen aus einer im Host-Speicher liegenden Tabelle vorab geholt werden, während die erste Transformer-Schicht rechnet.³ Sparse Zugriff senkt die Arithmetik pro Token, verlagert Kosten aber auf Tabellenspeicher, Host-RAM, Transferbandbreite und das Verbergen der Transferlatenz. Die Placement-Ablation im Report fand keinen konsistenten Vorteil durch Aufteilung eines festen Tabellenbudgets auf zwei Schichten; das veröffentlichte Modell nutzt daher eine.³

Ist das dasselbe wie DeepSeeks Engram?

Das Prinzip ist gemeinsam: Gelernter, per N-Gram adressierter Speicher ergänzt Transformer-Aktivierungen über sparse Lookups. Die Model Card von DeepSeek V4.1 Flash nennt ihr Modul Engram; Qwen nennt sein Merkmal N-Gram Embedding, im Checkpoint auch PLE. Daraus folgt weder dieselbe Modellarchitektur noch dasselbe Tabellenlayout.⁶²

Der bestehende DeepSeek-Architekturartikel erläutert dessen Encoder-Decoder-KV-Kompression im Detail. Diese Tabelle grenzt lediglich die Gemeinsamkeit beim Lookup-Speicher ein. Eine größere Tabelle belegt für sich genommen weder bessere Qualität noch schnellere Inferenz. Die Modellteams nutzen unterschiedliche Backbones, Trainingsdaten, Quantisierung und Serving-Pfade; ihre Parameterzahlen und Benchmark-Ergebnisse sind deshalb keine kontrollierte Ablation.

Was die veröffentlichten Daten belegen

Qwen hat Gewichte veröffentlicht und beschreibt das Serving mit Transformers, vLLM und SGLang.¹² Die Ablationen im Report stützen die Architekturentscheidungen unter den dort genannten Trainings- und Testbedingungen. Beispielsweise sinkt in einem Versuch der Loss mit wachsender N-Gram-Vokabulargröße, während die Downstream-Ergebnisse sättigen oder schwanken. Mehr Tabellenzeilen sind deshalb kein belegtes Versprechen für bessere Anwendungen.³ Auch die QSA-Kernel-Zahlen ersetzen keinen Test mit eigener Runtime, Kontextverteilung, Quantisierung und Offload-Strategie. Der native Kontext des Checkpoints beträgt 262.144 Token; die Model Card beschreibt eine Erweiterung auf eine Million Token mit angepassten RoPE/YaRN-Einstellungen. Diese größere Zahl ist nicht die Standardkonfiguration des Checkpoints.²⁴

Quellen