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.12
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.3 Der VRAM-Leitfaden behandelt die getrennten Speicherbudgets für Gewichte und Inferenzzustand.
Der veröffentlichte Stack
| Komponente | Veröffentlichte Konfiguration | Aufgabe |
|---|---|---|
| Hauptsprachmodell | 125 Mrd. Parameter; etwa 6 Mrd. pro Token aktiviert | Sparse-MoE-Backbone, ohne N-Gram-Tabelle und MTP-Modul.2 |
| Token-Mixing-Schichten | 48 Schichten: zwölf Wiederholungen aus drei GDN-Schichten und einer QSA-Schicht | GDN aktualisiert einen kompakten Zustand; QSA behält inhaltsbasierten Zugriff auf ältere Token.23 |
| MoE | 512 geroutete Experten, zehn pro Token ausgewählt, dazu ein gemeinsamer Experte | Bedingte Berechnung nach dem Token-Mixing; unabhängig vom N-Gram-Lookup.2 |
| Residual | Vier Zweige; gegatetes Lesen und skalares Schreiben pro Zweig | Leitet unterschiedliche Informationen durch die Schichten, statt alles in einen Residual-Vektor zu zwingen.3 |
| N-Gram-Speicher | Weitere 51 Mrd. Parameter; Bigramm-/Trigramm-Lookup in Schicht 2 | Zusätzliche gelernte Kapazität durch sparse Tabellenzugriffe.2 |
| Draft-Modul | Eine MTP-Schicht, ungefähr 4 Mrd. weitere Parameter | Mehrtoken-Vorhersage; nicht in den 125 Mrd. Backbone-Parametern enthalten.2 |
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.24
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.34
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.324 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 QSA mit dichter Attention auf Kernel-Ebene. Es sind keine Ende-zu-Ende-Latenzen des gesamten Modells.3
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 gelernten Skalar pro Zweig zurückgeschrieben. 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.3
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].24 Der gelesene Vektor wird kontextabhängig in den Residual-Strom eingefügt. 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.3 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.3
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.52
| Qwen3.8-Flash-Next | DeepSeek V4.1 Flash | |
|---|---|---|
| Gelernte Lookup-Kapazität | 51 Mrd. N-Gram-Parameter | 196 Mrd. Engram-Parameter25 |
| Platzierung | Eine Schicht: ple_layer_ids: [2] | Zwei Module: engram_layer_ids: [1, 14]46 |
| Hauptpfad der Token | Drei GDN- plus eine QSA-Schicht pro Vierergruppe; Gated Residual | 20-Schicht-Causal-Encoder plus 20-Schicht-Decoder; CSA2-Sparse-Attention und Single-Pass-mHC35 |
| Sparse Berechnung | 512 geroutete Experten, zehn gewählt plus ein gemeinsamer | 384 geroutete Experten, sechs gewählt plus ein gemeinsamer25 |
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.12 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.3 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.24