Qwen 4 Leak: SGLangs Host-Staging-PR zeigt, wie die 47,7 GiB große PLE-Tabelle auf eine GPU passt

Die Zahl, die darüber entscheiden wird, ob Qwen 4 ein Modell ist, das man selbst hosten kann, ist nicht seine Parameteranzahl. Sie beträgt 47,7 GiB — die Größe der n-Gramm-Embedding-Tabelle, die neben der Qwen4-Architektur mitläuft, von den Gewichten getrennt ist und irgendwo untergebracht sein muss, während das Modell dekodiert. Ein Pull Request, der am 18. September 2026 im SGLang-Repository geöffnet wurde, mit dem Titel [Qwen4-Exp] Host-Staging für dateibasierte PLE hinzufügen, ist ein Versuch, zu verhindern, dass diese Tabelle bestimmt, wie viel RAM eine Maschine braucht, bevor sie überhaupt laufen kann. Qwen 4 ist noch nicht veröffentlicht: keine Modellkarte, keine Gewichte, kein Katalogeintrag, kein Datum. Das einzige ausgelieferte Modell, das diese Architektur instanziiert, ist Qwen3.8-Flash-Next, die Open-Weight-Vorschau, veröffentlicht am 26. August 2026, deren Konfiguration deklariert: model_type=qwen4_exp — dieselbe Zeichenkette, die dem Pull Request seinen Namen gibt. Sein Produktions-Pendant Qwen3.8-Flash ist die Version, die ein API-Nutzer heute tatsächlich erreichen kann. Alles in diesem Artikel über Qwen 4 ist eine Schlussfolgerung aus dieser Vorschau und aus Engine-Code; der Pull Request ist offen und nicht gemergt, so ist all das als Signal zu verstehen, nicht als ausgelieferte Fähigkeit.

Was das Signal tatsächlich ist

Pull-Request sgl-project/sglang#40235 ist kein Launch und ist nicht gemergt. Es steht auf einem Commit, eröffnet von dem Mitwirkenden Dev-Jahn, der einen Branch namens task/ple-host-staged in die Hauptlinie von SGLang zusammenführt. Neun Code-Owner wurden zur Überprüfung angefragt, und alle werden als wartend angezeigt, sodass mindestens eine zustimmende Review zwischen diesem PR und main steht. Drei CI-Jobs — der Basis-PR-Test, der zusätzliche PR-Test und der AMD-ROCm-Lauf — schlagen auf dem offenen Commit fehl. Das ist der normale Zustand einer großen Engine-Änderung in Arbeit, und es ist auch der Grund, warum der interessante Teil dieses PRs nicht darin besteht, ob er gemergt wird, sondern darin, was sein Autor messen musste, um dafür zu argumentieren. Die Beschreibung enthält ungefähr 1.400 hinzugefügte Zeilen einschließlich Tests und eine Benchmark-Tabelle, die die konkretesten öffentlichen Daten sind, die jemals über den Betrieb dieser Architektur auf einer einzelnen GPU veröffentlicht wurden.

Warum der Tisch die ganze Geschichte ist

Per-Layer-Embeddings sind die strukturelle Kuriosität dieser Generation. Während ein normales Modell ein einziges Token-Embedding an den Anfang setzt, trägt das Qwen4-Design eine große n-Gramm-Tabelle – Bigramme und Trigramme, in ein Vokabular gehasht, das weit größer ist als das des Tokenizers – und speist daraus über den gesamten Stack hinweg Per-Layer-Embedding-Lookups. Alibabas eigenes Vorschaumaterial beschreibt die n-Gramm-Komponente als mehrere Zehnmilliarden Parameter zusätzlich zum 125B-Parameter-MoE-Körper; Community-Teardowns des veröffentlichten Checkpoints beziffern die Tabellendatei auf 47,7 GiB. Diese Zahlen stammen aus Hersteller- und Community-Quellen statt aus unabhängiger Reproduktion, und die genaue Beziehung zwischen der Tabelle der Vorschau und dem, was Qwen 4 letztlich ausliefert, ist unbekannt.

Was nicht infrage steht, ist die technische Konsequenz. Eine 47,7 GiB große Nebentabelle, die bei jedem Decode-Schritt herangezogen werden muss, kann man nicht einfach unauffällig in eine Ecke des VRAM schieben. Auf einer 96-GB-Karte konkurriert sie direkt mit dem KV-Cache; auf kleineren Karten passt sie schlicht nicht hinein. Deshalb hat SGLang, das Ende August Day-0-Support für die Preview aufgesetzt hat, die folgenden drei Wochen damit verbracht, einen Pull Request nach dem anderen zu dieser einen Datenstruktur zu erstellen – statt zu dem Modell drumherum.

Was war vor diesem PR kaputt?

SGLang hatte bereits zwei Möglichkeiten, den Tisch zu halten, und beide hatten eine harte Kante.

• Pinned hält die gesamte Tabelle im Host-RAM und liest sie von dort. Es funktioniert, es ist schnell, und es macht den Host-Speicherbedarf absolut — es gibt keine kleinere Version davon.

• File-backed, in einem früheren, separaten Pull Request hinzugefügt, hält die Tabelle in einer Sparse-Datei und lässt den Gather-Kernel das Mapping direkt lesen, sodass der Page-Cache des Betriebssystems entscheidet, wie viel davon resident ist. Der Haken ist hardwarebedingt: Dieser Direktlesepfad erfordert, dass die GPU cudaDevAttrPageableMemoryAccessUsesHostPageTables meldet — die Fähigkeit, die der Text des PRs selbst als „die GB10-Klasse“ umschreibt. Auf einer GPU ohne sie wird das Datei-Backend rundheraus verweigert, und Pinned ist die einzige verbleibende Option.

Die Lücke, die dadurch entsteht, ist nicht theoretisch. Ein separater Bericht, der gegen denselben Codepfad eingereicht wurde, dokumentiert einen Nutzer mit zwei RTX 3090s, bei dem der Pro-Rank-Anteil an der Tabelle 23,84 GiB gegenüber 23,56 GiB nutzbarem Speicher betrug — 0,28 GiB zu wenig, während 188 GiB Host-RAM frei blieben. In dieser Konfiguration wurde das Datei-Backend von der Hardwareprüfung abgelehnt, und das normale CPU-Offload-Flag löst einen Fehler aus, wenn es mit dem PLE-Offload-Flag kombiniert wird. Dass dreihundert Megabyte fehlen, während hundertachtzig Gigabyte übrig sind, ist genau die Art von Problem, die dieser Pull Request beseitigen soll.

Welche Host-Staging-Änderungen

Der vom PR hinzugefügte Mechanismus ist eine Staging-Schicht zwischen der Datei und dem Gerät. Anstatt die GPU zu bitten, Host-Seiten zu dereferenzieren, liest eine CPU-seitige Komponente die benötigten Zeilen über das vorhandene Mapping des Loaders und regt den Kernel dazu an, diese Seiten vorab einzuladen; eine Umgebungsvariable, SGLANG_QWEN4_PLE_FILE_PREFETCH, schaltet den Hinweis ab, wenn Sie ohne ihn messen möchten. Jede PLE-Schicht erhält dann zwei gepinnte Puffer mit 8.192 Zeilen – etwa 1,25 MiB pro Puffer bei FP8 – und einen Worker. Zeilen werden in einen Puffer gesammelt, während der andere auf das Gerät kopiert wird, sodass das Sammeln und die Übertragung sich überlappen, anstatt serialisiert zu werden. N-Gramm-Identifikatoren werden auf dem Host statt auf dem Gerät gehasht. Graph-Replay erhält vor jedem Replay einen Vorbereitungsaufruf, und der startende Thread wartet auf den vorherigen Schritt.

Dieses letzte Detail ist der Preis, und die PR sagt es unverblümt: ungefähr 0,5 bis 1 Millisekunde zusätzlich pro Decodierschritt gegenüber dem gepinnten Pfad. Alles andere ist der Gewinn. Gemessen auf einer einzelnen RTX PRO 6000 Blackwell mit 96 GB, einem AMD EPYC Host mit 377 GiB RAM, CUDA 13.2, unter Verwendung der öffentlichen FP8- und NVFP4-Checkpoints von Qwen3.8-Flash-Next:

• Host-Page-Cache, FP8 TP4/EP4 — 71 GB gepinnt und ohne Obergrenze, gegenüber 49 GB bei einer Obergrenze von 64 GB, 15 GB bei 32 GB und 6 GB bei einer Obergrenze von 24 GB

• Dekodierungslatenz, gleiche Durchläufe — 8,62 ms pro Token bei Nebenläufigkeit 1 (gepinnt), gegenüber 9,16 / 9,20 / 9,12 ms über die drei begrenzten Datei-Durchläufe

• Parallelität 16 — 16,54 ms gepinnt gegenüber 17,62 / 17,85 / 17,37 ms begrenzt, was einen Rückgang von 893 Token pro Sekunde auf 827–840 bedeutet

• Prefill-Durchsatz — 620 Token pro Sekunde bei 8k gepinnt gegenüber 624 / 630 / 631 begrenzt; bei 32k 1.347 gegenüber 1.358 / 1.359 / 1.361

• NVFP4 TP2 — 69 GB gepinnt gegenüber 24 GB mit dem Datei-Backend bei einer Obergrenze von 32 GB, bei 8,87 ms gegenüber 9,18 ms

• Single-GPU NVFP4 — 69 GB gepinnt gegenüber 51 GB bei einer Obergrenze von 64 GB, bei 6,44 ms gegenüber 6,73 ms

• Die Alternative, die es schlägt — das Lesen derselben Datei über die Host-Speicherverwaltung auf dieser GPU ergab 10,8 ms bei Nebenläufigkeit 1 und 46,5 ms bei Nebenläufigkeit 16, was die PR als das 2,8-Fache der Pinned-Latenz bei dieser Nebenläufigkeit beschreibt

Die Genauigkeitsseite wird als sauber gemeldet. Deterministische Greedy-Ausgaben über acht Prompts à 256 Tokens waren zwischen dem gepinnten Pfad und dem Dateipfad auf FP8 TP4 token-identisch, und GSM8K kam auf 97,6 % für den gepinnten Pfad gegenüber 98,0 % für den Dateipfad bei der 64-GB-Grenze — eine Lücke von sechs Fragen, die der Autor eher auf Schwankungen von Lauf zu Lauf als auf den Offload-Pfad zurückführt. Alle diese Zahlen stammen vom Autor des Pull Requests selbst, einmal gemessen, auf einer Maschine, und niemand hat sie reproduziert.

Die Kosten, die PR einräumt

Eine faire Auslegung dieses Pull Requests schließt ein, was er sich weigert zu tun. Mehrere Ausführungsmodi werden bereits zur Konstruktionszeit abgelehnt, statt stillschweigend degradiert zu werden, und jede Ablehnung benennt das gepinnte Backend als Fallback: Prefill-CUDA-Graphen, datenparallele Attention, der Prefill-Decode-Multiplexing-Pfad, Zwei-Batch-Überlappung, die DLLM-Decode-Graphen und kompakte Ragged-Verify-Graphen sind alle außen vor. Ebenso wichtig: Er fügt kein neues Flag und keinen neuen benutzerseitigen Schalter hinzu — der Staging-Pfad ist das, was das Datei-Backend auf Hardware tut, die ihn zuvor überhaupt nicht nutzen konnte. Und der Genauigkeitslauf trägt eine Einschränkung, die der Autor von sich aus nennt: Die gedeckelten Läufe hielten nie die gesamte Tabelle, denn die Tabelle ist 47,7 GiB groß und die Obergrenzen gehen bis auf 24 GB herunter, sodass eine Workload mit einem wirklich flachen, unvorhersehbaren Zugriffsmuster über die gesamte Tabelle nicht das ist, was gemessen wurde.

Warum das speziell für Qwen 4 wichtig ist

Blendet man die Engine-Details aus, wird das Muster erkennbar. Alibaba veröffentlichte am 26. August eine Architektur-Vorschau mit Anweisungen an die Open-Source-Community, im Vorfeld der vollständigen Familie Laufzeitumgebungen, Quantisierung und Inferenz-Engines vorzubereiten. SGLang tat das und verbrachte dann drei Wochen damit, Pull Requests zu der einen Komponente einzureichen, die die Architektur umständlich zu deployen macht. Als Prognose gelesen ist das eine Aussage darüber, was Qwen 4 von Ihrer Hardware benötigen wird, nicht darüber, was es in einem Benchmark leisten kann.

Das schärft auch die Frage nach dem Zeitplan. Qwen 4 wurde noch nicht veröffentlicht, und die Spekulationen im September darum deuten auf Alibabas Apsara Conference vom 22. bis 24. September in Hangzhou hin — den Ort, an dem frühere Qwen-Generationen angekündigt wurden. Nichts davon ist bestätigt, und das Muster aus dem letzten Preview-Zyklus ist, dass eine Architekturvorschau der vollständigen Familie um Monate statt um Wochen vorausgeht. Ein Pull Request, der drei Tage vor dieser Konferenz eröffnet wird, ist vielsagend und nichts weiter.

Eine ehrliche Zusammenfassung dessen, was das für einen Leser bedeutet: Qwen 4 existiert nicht, Qwen3.8-Flash-Next schon, und Letzteres verrät einem, was Ersteres im Betrieb kosten wird. Wenn die 47,7-GiB-Tabelle beim effektiven Footprint weiter schrumpft – und drei Wochen an Pull-Requests zeigen, dass intensiv daran gearbeitet wird –, dann liegt die Hürde für den Einsatz der Qwen 4-Familie niedriger, als die Startwoche der Vorschau nahelegte.

Was Sie damit heute tatsächlich tun können

Nichts in diesem Pull-Request ist auf main verfügbar, und das Modell, auf das er abzielt, lässt sich nicht über eine API aufrufen. Der Open-Weight-Checkpoint Qwen3.8-Flash-Next ist eine Self-Hosting-Geschichte: Man lädt die Gewichte herunter, hostet sie selbst, und der dateibasierte PLE-Pfad ist das, worum es hier geht. Es wird hier nicht geroutet. Was geroutet wird, ist die Produktionsvariante — Qwen3.8-Flash, erreichbar als qwen/qwen3.8-flash für 0,15 $ pro Million Eingabe-Tokens und 0,47 $ pro Million Ausgabe-Tokens, mit einem Kontext von 1 Mio. Tokens sowie Text-, Bild- und Videoeingabe — und das größere Qwen3.8-Max für 2,00 $ und 6,00 $.

Diese Unterscheidung ist die nützliche für Leser, die entscheiden, was sie diese Woche tun sollen. Die Preview ist Forschung, die Sie selbst betreiben; die bereitgestellte Variante ist der Produktionspfad derselben Architektur, und sie ist nur einen Endpunkt entfernt. OrcaRouter gibt den Listenpreis des Anbieters weiter – zum 0 % Aufschlag, sodass eine Preisänderung eines Anbieters an diesem Endpunkt noch am selben Tag sichtbar wird und nicht erst zum nächsten Abrechnungszyklus, und jedes Modell am Schlüssel über eine einzige OpenAI-kompatible Basis-URL erreichbar ist statt über einen separaten Vertrag, ein SDK und eigene Zugangsdaten pro Anbieter. Für eine so junge Architektur – bei der die Arbeit an der Engine noch wöchentlich landet und die Roadmap nicht veröffentlicht wurde – ist automatisches Failover über Anbieter hinweg der praktische Weg, sich auf die bereitgestellte Variante zu verlassen, ohne einen Produktionspfad auf die Verfügbarkeit eines einzelnen Anbieters zu setzen. All das betrifft die Modelle, die Sie heute aufrufen können. Über Qwen 4 sagt es nichts, denn das ist keines davon.

Was wir noch nicht wissen

Ob Qwen 4 dieselbe Tabelle in derselben Größe ausliefern wird. Ob der Pull Request überhaupt gemergt wird – er hat drei fehlschlagende CI-Läufe und noch keine Reviews. Und ob die 0,5 bis 1 Millisekunde pro Schritt Mehrkosten außerhalb der Konfigurationen mit geringer Nebenläufigkeit des Autors Bestand haben. Und ob Alibaba am 22. September bei Apsara etwas sagt. Nach der derzeitigen Beweislage ist die sicherste Schlussfolgerung über Qwen 4 nicht, welche Werte es erzielt, sondern wie viel Maschinerie die Industrie aufbaut, nur damit es passt – was an sich eine nützliche Information ist, bevor das Modell in irgendeinem Katalog einen Namen hat.