Qwen-4-Leak: SGLang shardet Qwen4Exp-Prefill für 18 % schnelleres TTFT und ein GiB zurück pro GPU

Ein Pull Request, der heute Morgen, am 2026-10-08, um 03:47 UTC im SGLang-Repository geöffnet wurde, verspricht etwas, das noch keine Qwen-4-Ankündigung hervorgebracht hat: eine Zahl. Er trägt den Titel feat(qwen4-exp): enable LayerNorm sequence parallelism for GR and PLE, und auf vier H20-GPUs, die den offenen Qwen3.8-Flash-Next-Checkpoint in FP8 ausführen, meldet der Autor Verbesserungen der Zeit bis zum ersten Token von 17,7–18,4 % bei 32K Eingabe und 14,6–14,7 % bei 235K Eingabe, rund ein Gigabyte zurückgewonnenen Spitzenarbeitsspeichers pro GPU und bis zu 22 % mehr Eingabedurchsatz. Qwen 4 selbst – die Familie, die der Anbieter auf der Apsara-Konferenz in Hangzhou am 2026-09-22 benannt, aber nicht ausgeliefert hat – ist nach wie vor unveröffentlicht, ohne Gewichte, ohne Kennung und ohne Preis. Das einzige Modell, das die Qwen4Exp-Architektur heute instanziiert, ist Qwen3.8-Flash-Next, veröffentlicht am 2026-08-26, und sein verwaltetes Schwestermodell Qwen3.8-Flash ist die Version, die ein API-Aufrufer tatsächlich erreichen kann. Lesen Sie das Folgende also genau als das, was es ist: die gepaarten Messungen eines Ingenieurs, angehängt an einen offenen, als Entwurf vorliegenden, nicht zusammengeführten Pull Request, über die Serving-Hüllkurve einer Modellfamilie, die es noch nicht gibt.

Zuerst die Quellenprüfung, denn dies ist ein Leak-Stück, und die Unterscheidung leistet echte Arbeit. Das Signal ist sgl-project/sglang#43048, geöffnet am 2026-10-08 um 03:47 UTC vom GitHub-Konto shiyang814-cpu, zuletzt aktualisiert um 03:55 UTC, und nach wie vor markiert als Entwurf, ohne verzeichnete genehmigende Review und ohne Merge. Es ändert sechs Dateien — zwei Testdateien, die Qwen4Exp-Modelldatei, das LayerNorm-SP-Modul, eine Layer-Boundary-Factory und einen Argument-Group-Hook — mit +345 und −50 Zeilen. Jede unten stehende Performance-Zahl stammt aus der PR-Beschreibung, ist die eigene gepaarte OFF/ON-Messung des Autors und wurde von niemandem reproduziert. Drei CI-Läufe auf der Revision an der Spitze des Branches sind als fehlgeschlagen markiert. Nichts hiervon ist eine ausgelieferte Fähigkeit.

Was der Pull Request tatsächlich ändert

Sequenzparallelität ist keine Modelländerung und keine neue Fähigkeit. Sie ist eine Neuverdrahtung dessen, wo einige wenige Schichten ihre Arithmetik ausführen. Ihre Abstammung reicht zurück bis zur Sequenzparallelität im Megatron-Stil – dem Trick aus arXiv:2205.05198 – und SGLang liefert sie bereits mit: Der Docstring des Moduls selbst erklärt den Mechanismus, den es wiederverwendet, dass unter reiner Tensorparallelität ein zeilenparalleles all_reduce algebraisch ein reduce_scatter gefolgt von einem all_gather ist. Da diese beiden Kollektive genau dieselben Bytes bewegen wie das einzelne all_reduce, das sie ersetzen, kostet das Aufteilen der Operation auf diese Weise überhaupt kein zusätzliches Kommunikationsvolumen. Was es bringt, ist die Freiheit, die Normalisierungs- und Residualbereiche auf sequenzpartitionierten Aktivierungen laufen zu lassen – wobei jeder tensorparallele Rang ein-1/tptel der Token-Zeilen hält – was den transienten Aktivierungsspeicher reduziert, den Long-Context-Prefill am Leben erhalten muss.

Was dieser spezielle Pull-Request bewirkt, ist, den bestehenden Pfad von der Architektur, auf der er validiert wurde, auf die Qwen4Exp-Architektur auszuweiten. Während des Prefill bleiben die Gated-Residual- und Per-Layer-Embedding-Aktivierungen entlang der Token-Dimension über die TP-Gruppe hinweg geshardet. Vor der Attention, vor GDN, vor QSA und bevor der Mixture-of-Experts-Block ausgeführt wird, werden die vollständigen Token-Zeilen per All-Gather wieder zusammengeführt, die bestehende Tensor-Parallel-Berechnung mit vollständigen Zeilen läuft unverändert hinter einem gemeinsamen Fallback, und ein Reduce-Scatter summiert anschließend die Teilbeiträge und stellt den Shard jedes Ranks wieder her. Decode berührt den neuen Pfad überhaupt nicht. Das Feature wird über die bereits vorhandene Option erreicht — --enable-layernorm-sp — ohne Qwen4Exp-spezifisches Flag, und bei fehlendem Flag verhält sich der Code genau wie zuvor.

Warum Qwen4Exp die Architektur ist, die das braucht

Der Grund, warum dies speziell für Qwen4Exp relevant ist und nicht gleichermaßen für jedes Modell, liegt im Design der Architektur selbst. Qwen3.8-Flash-Next wendet Gated-Residual-Projektionen auf alle Token-Zeilen in jeder Decoder-Schicht an — die Konfiguration deklariert vier Residual-Streams und einen Bottleneck-Rang von 320 über 48 Schichten — und Per-Layer Embedding fügt darauf zusätzlich eine zweite replizierte Projektion Token-Zeile für Token-Zeile hinzu. Unter Tensor-Parallelität werden beide dieser Operationen auf jedem Rank identisch dupliziert, weil sie keine eigene TP-geshardete Gewichtsmatrix besitzen, die eine Aufteilung erzwingen würde. Das Sharding ihrer Token-Dimension beseitigt die replizierte Arbeit direkt, und wie es im Motivationsabschnitt des PR heißt, geschieht dies unter Beibehaltung des bestehenden tensor-parallelen Layouts und der Reduktionssemantik von Attention, GDN/QSA und MoE — was der Teil ist, der die Änderung sicher statt clever macht.

Es lohnt sich, klar zu sagen, was das für den Leser bedeutet. Das Interessante an diesem PR ist nicht, dass SGLang schneller wird. Es ist, dass die Qwen4-Architektur Kosten pro Schicht mit sich bringt, die mit Token-Anzahl statt mit der Parameteranzahl skalieren, und genau diese Kosten schlagen bei langen Prefills zu. Das ist ein Design-Fingerabdruck, und es ist die Art von Sache, die ein Datenblatt nie erwähnt.

Die gemessenen Deltas

Der Benchmark des Autors legt eine Konfiguration fest und schaltet das Flag um: vier NVIDIA H20 GPUs, Qwen3.8-Flash-Next-FP8, Tensor-Parallel 4 und Expert-Parallel 4, Chunked-Prefill-Größe 8192, FlashInfer-Backends für Linear-Attention-Prefill und -Decode, dieselbe Serverkonfiguration für OFF und ON, abwechselnde Service-Neustarts OFF → ON → OFF → ON sowie feste Token-Eingaben mit Warmup-Anfragen. Jede unten stehende Abbildung stammt aus diesem Setup und ist ungeprüft:

• 32K-Eingabe, Batch-Größe 1 — TTFT um 17,72–18,36 % verbessert, End-to-End-Latenz etwa 16 %, Eingabedurchsatz etwa 20 %

• 235K Eingabe, Batchgröße 1 — TTFT verbessert um 14,63–14,71 %, End-to-End-Latenz etwa 14 %, Eingabedurchsatz etwa 17 %

32K-Eingabe, Batch-Größe 4 — TTFT um 18,74 % verbessert, End-to-End-Latenz um 18,14 %, Eingabedurchsatz um 22,14 %

• Spitzenspeicher — um etwa 1,0 GiB pro GPU reduziert

• Decode, Batch-Größe 1 — Zeit pro Ausgabe-Token praktisch unverändert

Die letzte Zeile ist die, die man zweimal lesen sollte, und der Autor sagt offen, warum: Diese Optimierung ist nur für Prefill aktiviert, daher hat der Single-Stream-Decode nichts davon. Die Batch-4-Verbesserung der Zeit pro Token, wo sie auftritt, spiegelt verringerte Scheduling-Verzögerungen durch gleichzeitige lange Prefills wider, nicht einen schnelleren Decode-Kernel. Wenn Sie gehofft haben, dass dies eine Durchsatz-Geschichte ist, dann ist es keine – es ist eine Geschichte über die Latenz bis zum ersten Token und den Speicher, und das sind die beiden Einschränkungen, die darüber entscheiden, ob eine 235K-Token-Anfrage überhaupt bedienbar ist.

Der Layout-Bug, den sie zuerst beheben mussten

Der aussagekräftigste Teil des Pull Requests ist nicht die Speedup-Tabelle. Es ist der Abschnitt zum physischen Zeilenlayout von PLE, denn er zeigt, was der Qwen4Exp-Serving-Stack noch falsch macht.

Per-Layer Embedding arbeitet auf einem festen physischen CUDA-Graph-Bucket, während nur ein Präfix der Zeilen in diesem Bucket echte Token enthalten kann. Das Padding muss daher angewendet werden, bevor die Sequenz geshardet wird, nicht danach. Im letzten Chunk einer 235K-Token-Anfrage sind die Zahlen des Autors 5.624 verarbeitete Token in einem physischen Bucket mit 8.192 Zeilen bei TP 4, und das einzig korrekte Layout ist, dass Rank 0 2.048 gültige Zeilen enthält, Rank 1 2.048 gültige Zeilen enthält, Rank 2 1.528 gültige Zeilen plus 520 Padding-Zeilen enthält und Rank 3 2.048 Padding-Zeilen enthält. Das Sharding der 5.624 verarbeiteten Zeilen zuerst – die naheliegende Implementierung – fügt Padding zwischen global zusammenhängende gültige Bereiche ein und beschädigt das Ergebnis. Der Autor hält fest, dass ein echter 235K-OFF/ON-Test erst identische 16-Token-Greedy-Ausgabe lieferte, nachdem dieses Layout korrigiert wurde.

Das ist ein kleines Detail mit großer Tragweite. Der PLE-Pfad in SGLang wurde erst so kurzlich hinzugefügt, dass ein Token-Reihenfolge-Bug dieser Art noch auftreten konnte, und die Person, die ihn fand, schrieb gerade die Sequence-Parallel-Erweiterung. Der Day-zero-Serving-Support für diese Architektur ist nicht fertig; er wird aktiv, öffentlich, von Mitwirkenden gebaut – ein Layout nach dem anderen.

Was es Sie kostet: die Einschränkungen

Ein Flag, das nur manchen Deployments hilft, ist nur dann nützlich, wenn man weiß, welchen. Der PR nennt seine Anforderungen ausdrücklich, und Konfigurationen, die darüber hinausgehen, schlagen bei der Argumentvalidierung fehl, statt sich stillschweigend zu verschlechtern:

• Die Tensor-Parallel-Größe muss größer als 1 sein – ein Single-GPU-Deployment bringt nichts, da es keinen Rank gibt, über den aufgeteilt werden könnte

• Die Expert-Parallelgröße muss gleich der Tensor-Parallelgröße sein

• Pipeline-Parallelgröße muss gleich 1 sein

• Datenparallele Attention muss deaktiviert werden

• Spekulative Dekodierung muss deaktiviert sein

Die letzte Einschränkung ist diejenige, hinter der eine echte Entscheidung steht. Für ein Sparse-Modell, das pro Token rund 6B Parameter aktiviert, ist spekulatives Decoding einer der wenigen Hebel zur Beschleunigung der Decodierung, und diese Funktion schaltet diesen Hebel ausdrücklich ab, um einen Prefill-Gewinn zu erzielen. Wenn Ihr Workload aus einem langen Prompt und einer kurzen Ausgabe besteht — Dokument- und Codebase-Analyse, Videozusammenfassung, ein großer Kontext, der einmal gelesen wird —, ist der Tausch schlichtweg gut. Wenn Ihr Workload aus einem kurzen Prompt und einer langen Generierung besteht, geben Sie die Sache auf, die Ihnen geholfen hat, und kaufen eine Zahl, die auf Sie nicht zutrifft. Die Anforderung, dass Expert-Parallel gleich Tensor-Parallel sein muss, ist die andere, die man beachten sollte: Sie bedeutet, dass die MoE-Sharding-Geometrie exakt mit der TP-Geometrie übereinstimmen muss, was mehrere ansonsten vernünftige Multi-Node-Layouts ausschließt.

Was dies über den Zeitplan für Qwen 4 aussagt

Liest man den Diff anders, bekommt man einen Kalender. Das LayerNorm-SP-Modul von SGLang im Main-Branch enthält heute eine explizite Allowlist von Architekturen, für die das Feature validiert wurde, und zum Zeitpunkt dieses Schreibens enthält diese Allowlist genau einen Eintrag, Qwen3ForCausalLM — jede andere Architektur wird bei der Konstruktion abgelehnt, wenn man das Flag übergibt. Qwen4Exp zu diesem Pfad hinzuzufügen ist daher keine kleine Anpassung an einer ausgereiften Abstraktion; es ist das erste Mal, dass die Qwen4-Architektur auf eine Optimierung gebracht wird, die um Generationen älter ist als sie.

Vergleicht man das mit der öffentlichen Faktenlage, ergibt sich ein stimmiges Bild. Der Anbieter gab am 2026-09-22 bekannt, dass Qwen 4 im Training ist, und stellte vier Stufennamen vor – Qwen 4 Max, Qwen 4 Flash, Qwen 4 Plus und Qwen 4 27B –, ohne dass irgendwelche Spezifikationen damit verbunden wurden. Die Open-Weight-Vorschau, die sich dieselbe Architektur teilt, Qwen3.8-Flash-Next, ist seit dem 2026-08-26 herunterladbar. Was in den drei Wochen seither geschieht, ist genau das, was man zwischen „im Training“ und „Launch“ erwarten würde: Engine-Autoren, die die Runtime einprüfen, damit der Support ab Tag eins echt und nicht bloß nominell ist. Ein Pull Request, der eine Serving-Optimierung auf der Architektur zum Laufen bringt, am Morgen des 2026-10-08 geöffnet und noch immer im Entwurfsstatus, ist ein besseres Signal dafür, wie nah Qwen 4 an der Einsatzfähigkeit ist, als jedes Datum, das jemand genannt hat. Er ist außerdem – nachdrücklich – kein Veröffentlichungstermin: Das Flag ist standardmäßig deaktiviert, die Änderung ist nicht gemergt, und das Modell, das er benchmarkt, ist die Vorschau, nicht Qwen 4.

Was Sie heute anrufen können

Nichts davon ändert etwas daran, was an diesem Nachmittag tatsächlich verfügbar ist. Qwen3.8-Flash-Next gibt es wirklich, seine Gewichte sind auf Hugging Face verfügbar, und Sie können es selbst hosten – aber es ist nicht in unserem Katalog, und wir werden nicht vorgeben, dass es anders wäre. Die Stufe, die wir tatsächlich anbieten, ist qwen/qwen3.8-flash, das verwaltete Geschwistermodell, das dieselbe Qwen4-preview-Architektur mit einem Kontextfenster von 1 Mio. Token und Text-, Bild- und Videoeingabe ausführt, zu einem Preis von 0,15 $ pro Million Eingabe-Token, 0,47 $ pro Million Ausgabe-Token und 0,0184 $ pro Million Cache-Lesevorgänge. Das ist ein Listenpreis, der mit 0 % Aufschlag durchgereicht wird; wenn der Anbieter ihn ändert, ändert sich die Zahl in Ihrer Rechnung am selben Tag, statt erst, wenn ein Zwischenhändler eine Tabelle neu veröffentlicht.

Es gibt einen zweiten, weniger offensichtlichen Grund, sich hier um eine Routing-Schicht zu kümmern. In diesem Artikel dreht sich alles um eine unerprobte Vorschau plus einen Entwurfspatch – genau die Art von Sache, die man testen möchte, ohne eine Produktionsroute darauf zu setzen. Dafür ist Failover da: die Vorschau hinter denselben Schlüssel wie das Modell zu setzen, dem Sie bereits vertrauen, zu beobachten, wie sie sich mit Ihrem Traffic verhält, und die Anfrage auf die bewährte Route zurückfallen zu lassen, wenn ein Anbieter wackelt oder der Endpunkt nicht erreichbar ist. Eine API für über 200 Modelle, ein Satz Zugangsdaten, kein zweiter Vertrag, der unterschrieben werden muss, um herauszufinden, ob eine neue Architektur Ihre Aufmerksamkeit wert ist.

Zwei Dinge, auf die man von hier aus achten muss, und keines von beiden lässt sich vorhersagen. Das Erste ist, ob dieser Patch überhaupt gemergt wird: Es ist ein Entwurf mit drei fehlschlagenden CI-Läufen bei einer Änderung an sechs Dateien von einem Contributor-Konto ohne vorherige Historie im Repository, und die Fluidität der PLE-Zeilenlayout-Arbeit deutet darauf hin, dass der Autor noch iteriert. Das Zweite ist, ob die Allowlist wächst — wenn Qwen4Exp zu Qwen3ForCausalLM als validierte Architektur hinzukommt, dann ist das kein Leak mehr und wird zur Standardmethode, wie ein Modell der Qwen4-Familie bei langem Kontext bedient wird. Bis eines davon eintritt, betrachte die 18 % als ein Versprechen darüber, wohin die Runtime geht, nicht als eine Zahl, die man mieten kann.