Qwen 4 Lek: SGLang splitst Qwen4Exp Prefill op voor 18% snellere TTFT en een GiB terug per GPU

Een pull request die vanmorgen om 03:47 UTC in de SGLang-repository is geopend, op 2026-10-08, belooft iets wat nog geen enkele Qwen 4-aankondiging heeft opgeleverd: een getal. De titel luidt feat(qwen4-exp): LayerNorm-sequentieparallellisme inschakelen voor GR en PLE, en op vier H20-GPU's die de open-weight Qwen3.8-Flash-Next-checkpoint in FP8 draaien, meldt de auteur winst in time-to-first-token van 17,7–18,4% bij 32K invoer en 14,6–14,7% bij 235K invoer, ongeveer een gigabyte aan piekgeheugen vrijgemaakt per GPU, en tot 22% meer invoer-doorvoer. Qwen 4 zelf — de familie die de leverancier noemde maar niet uitbracht tijdens de Apsara-conferentie in Hangzhou op 2026-09-22 — is nog steeds niet uitgebracht, zonder gewichten, zonder identifier en zonder prijs. Het enige model dat vandaag de Qwen4Exp-architectuur implementeert, is Qwen3.8-Flash-Next, gepubliceerd op 2026-08-26, en zijn beheerde zustermodel Qwen3.8-Flash is de versie die een API-aanroeper daadwerkelijk kan bereiken. Lees dus wat volgt precies voor wat het is: de gepaarde metingen van één engineer, gehecht aan een open, niet-samengevoegde concept-pull request, over de serving-envelope van een modelfamilie die nog niet bestaat.

Eerst de bronvermelding, want dit is een lekpublicatie en dat onderscheid doet er echt toe. Het signaal is sgl-project/sglang#43048, geopend op 2026-10-08 om 03:47 UTC door het GitHub-account shiyang814-cpu, voor het laatst bijgewerkt om 03:55 UTC, en nog steeds gemarkeerd als concept, zonder goedkeurende review en zonder merge. Het wijzigt zes bestanden — twee testbestanden, het Qwen4Exp-modelbestand, de LayerNorm-SP-module, een layer-boundary-factory en een argument-group-hook — goed voor +345 en −50 regels. Elk prestatiecijfer hieronder komt uit de PR-beschrijving, is de eigen gepaarde OFF/ON-meting van de auteur, en is door niemand gereproduceerd. Drie CI-runs op de revisie aan de tip van de branch zijn als mislukt gemarkeerd. Niets hiervan is een uitgeleverde functionaliteit.

Wat de pull request daadwerkelijk verandert

Sequentieparallellisme is geen modelwijziging en het is geen nieuwe mogelijkheid. Het is een herbedrading van waar een paar lagen hun rekenwerk doen. De oorsprong gaat terug tot sequentieparallellisme in Megatron-stijl — de truc uit arXiv:2205.05198 — en SGLang levert het al mee: de docstring van de module zelf legt het mechanisme uit dat het hergebruikt, namelijk dat onder puur tensorparallellisme een rijparallelle all_reduce is, algebraïsch, een reduce_scatter gevolgd door een all_gather. Omdat die twee collectieven precies dezelfde bytes verplaatsen als de enkele all_reduce die ze vervangen, kost het op die manier opsplitsen van de bewerking helemaal geen extra communicatievolume. Wat het oplevert, is de vrijheid om de normalisatie- en residualregio's te laten draaien op sequentie-gesharde activaties — waarbij elke tensorparallelle rank één-1/tpde van de tokenrijen bevat — wat het tijdelijke activatiegeheugen vermindert dat prefill met lange context in leven moet houden.

Wat deze specifieke pull request doet, is dat bestaande pad uitbreiden van de architectuur waarop het gevalideerd was naar de Qwen4Exp-architectuur. Tijdens prefill blijven de Gated Residual- en Per-Layer Embedding-activaties langs de token-dimensie geshard over de TP-groep. Voordat attention, voordat GDN, voordat QSA en voordat het Mixture-of-Experts-blok draait, worden de volledige tokenrijen weer all-gathered, loopt de bestaande tensor-parallel-berekening op volledige rijen ongewijzigd achter een gedeelde fallback, en telt een reduce-scatter vervolgens de partiële bijdragen op en herstelt de shard van elke rank. Decode raakt het nieuwe pad helemaal niet aan. De functie is bereikbaar via de optie die al bestaat — --enable-layernorm-sp — zonder Qwen4Exp-specifieke flag, en zonder de flag gedraagt de code zich precies zoals voorheen.

Waarom Qwen4Exp de architectuur is die dit nodig heeft

De reden dat dit specifiek voor Qwen4Exp van belang is, en niet in gelijke mate voor elk model, ligt in het ontwerp van de architectuur zelf. Qwen3.8-Flash-Next past Gated Residual-projecties toe op alle tokenrijen in elke decoderlaag — de configuratie declareert vier residualstromen en een bottleneck-rang van 320 over 48 lagen — en Per-Layer Embedding voegt daar bovenop een tweede gerepliceerde projectie per tokenrij toe. Onder tensor-parallelisme worden beide bewerkingen identiek gedupliceerd op elke rank, omdat ze geen eigen TP-gesharde gewichtsmatrix hebben die een splitsing afdwingt. Het sharden van hun token-dimensie verwijdert het gerepliceerde werk direct, en zoals de motivatiesectie van de PR het stelt, gebeurt dat met behoud van de bestaande tensor-parallelle lay-out en de reductiesemantiek van attention, GDN/QSA en MoE — en dat is het deel dat de wijziging veilig maakt in plaats van slim.

Het is de moeite waard om ronduit te zeggen wat dat voor de lezer betekent. Het interessante aan deze PR is niet dat SGLang sneller wordt. Het is dat de Qwen4-architectuur kosten per laag met zich meebrengt die schalen met het aantal tokens in plaats van met het aantal parameters, en juist die kosten bijten bij lange prefills. Dat is een ontwerp-vingerafdruk, en het is precies het soort ding dat een specificatieblad nooit vermeldt.

De gemeten delta's

De benchmark van de auteur houdt één configuratie vast en schakelt de vlag om: vier NVIDIA H20 GPU's, Qwen3.8-Flash-Next-FP8, tensor-parallel 4 en expert-parallel 4, grootte van chunked prefill 8192, FlashInfer linear-attention prefill- en decode-backends, dezelfde serverconfiguratie voor OFF en ON, afwisselende herstarts van de service in de volgorde OFF → ON → OFF → ON, en vaste tokeninputs met warmup-aanvragen. Elk getal hieronder is afkomstig uit die opstelling en is niet gecontroleerd:

• 32K-invoer, batchgrootte 1 — TTFT verbeterd met 17,72–18,36%, end-to-end latentie ongeveer 16%, invoerthroughput ongeveer 20%

• 235K invoer, batchgrootte 1 — TTFT verbeterd met 14,63–14,71%, end-to-end latentie ongeveer 14%, invoerthroughput ongeveer 17%

• 32K-invoer, batchgrootte 4 — TTFT verbeterd met 18,74%, end-to-end latentie 18,14%, invoerthroughput 22,14%

• Piekgeheugen — ongeveer 1,0 GiB minder per GPU

• Decoderen, batchgrootte 1 — tijd per outputtoken vrijwel ongewijzigd

De laatste regel is degene die je twee keer moet lezen, en de auteur is openhartig over waarom: deze optimalisatie is alleen ingeschakeld voor prefill, dus single-stream decode heeft er niets aan. De verbetering in tijd-per-token bij batch-4, waar die zich voordoet, weerspiegelt verminderde scheduling-vertragingen door gelijktijdige lange prefills, niet een snellere decode-kernel. Als je hoopte dat dit een throughput-verhaal was: dat is het niet — het is een verhaal over latency-to-first-token en geheugen, en dat zijn de twee beperkingen die bepalen of een verzoek van 235K tokens überhaupt te bedienen is.

De lay-outbug die ze eerst moesten oplossen

Het meest informatieve deel van de pull request is niet de versnellingstabel. Het is de sectie over de fysieke rij-indeling van PLE, omdat die laat zien wat de Qwen4Exp-servingstack nog steeds verkeerd doet.

Per-Layer Embedding werkt op een vaste fysieke CUDA-graph-bucket, terwijl alleen een prefix van de rijen in die bucket echte tokens kan bevatten. De padding moet daarom worden toegepast voordat de sequentie wordt geshard, niet erna. In de laatste chunk van een verzoek van 235K tokens zijn de cijfers van de auteur 5.624 verwerkte tokens in een fysieke bucket van 8.192 rijen bij TP 4, en de enige correcte lay-out is rang 0 met 2.048 geldige rijen, rang 1 met 2.048 geldige rijen, rang 2 met 1.528 geldige rijen plus 520 paddingrijen, en rang 3 met 2.048 rijen padding. Het eerst sharden van de 5.624 verwerkte rijen — de voor de hand liggende implementatie — voegt padding in tussen globaal aaneengesloten geldige bereiken en corrumpeert het resultaat. De auteur vermeldt dat een echte 235K OFF/ON-test pas identieke 16-token greedy-uitvoer opleverde nadat deze lay-out was gecorrigeerd.

Dat is een klein detail met grote gevolgen. Het PLE-pad in SGLang is zo recent toegevoegd dat een token-orderingbug van deze vorm nog steeds bereikbaar was, en degene die de bug vond, was bezig met het schrijven van de sequence-parallel-extensie. Day-zero-ondersteuning voor serving van deze architectuur is nog niet af; er wordt actief aan gebouwd, in het openbaar, door bijdragers, één lay-out per keer.

Wat het je kost: de beperkingen

Een flag die alleen sommige deployments helpt, is alleen nuttig als je weet welke. De PR vermeldt de vereisten ervan expliciet, en configuraties daarbuiten falen tijdens argumentvalidatie in plaats van stilzwijgend te degraderen:

• Tensor-parallelgrootte moet groter zijn dan 1 — een implementatie op één GPU levert niets op, omdat er geen rank is om over te verdelen

• Grootte van expert-paralleliteit moet gelijk zijn aan grootte van tensor-paralleliteit

• Pipeline-parallelgrootte moet gelijk zijn aan 1

• Data-parallel attention moet worden uitgeschakeld

• Speculatieve decoding moet uitgeschakeld zijn

De laatste beperking is degene waar daadwerkelijk een beslissing achter zit. Voor een sparse model dat ongeveer 6B parameters per token activeert, is speculatieve decoding een van de weinige hefbomen die zorgen voor een versnelling van decodering, en deze functie zet die hefboom expliciet uit in ruil voor een prefill-winst. Als je werklast een lange prompt en een korte output is — document- en codebase-analyse, videosamenvatting, een grote context die één keer wordt gelezen — dan is de ruil ronduit goed. Als je werklast een korte prompt en een lange generatie is, geef je het ding op dat je hielp en koop je een getal dat niet op jou van toepassing is. De eis dat expert-parallel gelijk is aan tensor-parallel is de andere die opvalt: het betekent dat de MoE-shardinggeometrie exact moet overeenkomen met de TP-geometrie, wat verscheidene anderszins redelijke multi-node-indelingen uitsluit.

Wat dit zegt over de Qwen 4-tijdlijn

Lees je de diff op een andere manier, dan krijg je een kalender. SGLang's LayerNorm-SP op de main-branch bevat vandaag een expliciete allowlist van architecturen waarvoor de functie is gevalideerd, en op het moment van schrijven bevat die allowlist precies één vermelding, Qwen3ForCausalLM — elke andere architectuur wordt bij constructie afgewezen als je de flag meegeeft. Qwen4 aan dat pad toevoegen is daarom geen kleine aanpassing aan een volwassen abstractie; het is de eerste keer dat de Qwen4-architectuur wordt onderworpen aan een optimalisatie die generaties ouder is.

Zet dat tegenover de openbare gegevens en het beeld is coherent. De leverancier kondigde op 2026-09-22 aan dat Qwen 4 in training is en presenteerde vier categorienamen — Qwen 4 Max, Qwen 4 Flash, Qwen 4 Plus en Qwen 4 27B — zonder dat er specificaties aan een van de namen waren gekoppeld. De open-weight preview die de architectuur deelt, Qwen3.8-Flash-Next, is sinds 2026-08-26 downloadbaar. Wat er in de drie weken sindsdien gebeurt, is precies wat je zou verwachten tussen "in training" en "lancering": engine-auteurs die de runtime uitproberen zodat day-zero-ondersteuning echt is in plaats van nominaal. Een pull request waarmee een serving-optimalisatie op de architectuur werkt, geopend op de ochtend van 2026-10-08 en nog steeds in draft, is een beter signaal over hoe dicht Qwen 4 bij het kunnen draaien als service staat dan welke datum dan ook die iemand heeft geopperd. Het is ook, met nadruk, geen releasedatum — de flag staat standaard uit, de wijziging is niet samengevoegd, en het model dat erin wordt gebenchmarkt is de preview, niet Qwen 4.

Wat je vandaag kunt bellen

Niets daarvan verandert wat vanmiddag daadwerkelijk beschikbaar is. Qwen3.8-Flash-Next is echt, de gewichten staan op Hugging Face en je kunt het zelf hosten — maar het staat niet in onze catalogus, en we doen niet alsof dat wel zo is. De tier die wij wel leveren is qwen/qwen3.8-flash, het managed broertje dat dezelfde Qwen4-preview-architectuur draait met een contextvenster van 1M tokens en tekst-, beeld- en video-invoer, geprijsd op $0,15 per miljoen inputtokens, $0,47 per miljoen output en $0,0184 per miljoen cache-leesbewerkingen. Dat is een lijstprijs die met 0% markup wordt doorgegeven, dus wanneer de leverancier hem aanpast, verandert het bedrag op je factuur dezelfde dag in plaats van wanneer een tussenpersoon ergens een tabel opnieuw publiceert.

Er is een tweede, minder voor de hand liggende reden om je hier om een routinglaag te bekommeren. Alles in dit artikel draait om een niet-bewezen preview plus een conceptpatch — precies iets wat je wilt testen zonder er een productiepad op te verwedden. Daar is failover voor bedoeld: zet de preview achter dezelfde sleutel als het model dat je al vertrouwt, kijk hoe het zich gedraagt op jouw verkeer, en laat het verzoek doorvallen naar de bekend-goede route wanneer een provider hapert of het endpoint er niet is. Eén API voor 200+ modellen, één set inloggegevens, geen tweede contract dat je moet ondertekenen om erachter te komen of een nieuwe architectuur je aandacht verdient.

Twee dingen om vanaf hier in de gaten te houden, waarvan we geen van beide kunnen voorspellen. Het eerste is of deze patch überhaupt wordt samengevoegd: het is een concept met drie falende CI-runs op een wijziging van zes bestanden, afkomstig van een bijdragersaccount zonder eerdere geschiedenis in de repository, en het voortdurend in beweging zijn van het PLE-rijlay-outwerk suggereert dat de auteur nog aan het itereren is. Het tweede is of de allowlist groeit — als Qwen4Exp zich bij Qwen3ForCausalLM voegt als een gevalideerde architectuur, dan is dit niet langer een lek en wordt het de standaardmanier waarop een model uit de Qwen4-familie bij lange context wordt geserveerd. Totdat een van die dingen gebeurt, moet je de 18% beschouwen als een belofte over waar de runtime naartoe gaat, niet als een getal dat je kunt huren.