Qwen 4-läcka: SGLang shardar Qwen4Exp-prefill för 18 % snabbare TTFT och en GiB tillbaka per GPU

En pull request som öppnades i SGLang-repositoriet kl. 03:47 UTC i morse, 2026-10-08, lovar något som inget Qwen 4-tillkännagivande ännu har åstadkommit: en siffra. Den har titeln feat(qwen4-exp): aktivera LayerNorm-sekvensparallelism för GR och PLE, och på fyra H20-GPU:er som kör den öppenviktade Qwen3.8-Flash-Next-checkpointen i FP8 rapporterar författaren förbättringar i tid-till-första-token på 17,7–18,4 % vid 32K indata och 14,6–14,7 % vid 235K indata, ungefär en gigabyte frigjort toppminne per GPU, och upp till 22 % mer indatagenomströmning. Qwen 4 självt – familjen som leverantören namngav men inte släppte på Apsara-konferensen i Hangzhou den 2026-09-22 – är fortfarande inte släppt, utan vikter, utan identifierare och utan pris. Den enda modellen som i dag instansierar Qwen4Exp-arkitekturen är Qwen3.8-Flash-Next, publicerad den 2026-08-26, och dess hanterade syskon Qwen3.8-Flash är den version som en API-anropare faktiskt kan nå. Så läs det följande för exakt vad det är: en ingenjörs parade mätningar, bifogade till en öppen, ej sammanslagen pull request i utkastform, om serveringsenveloppen för en modellfamilj som ännu inte existerar.

Källhänvisning först, eftersom detta är en läckt artikel och distinktionen spelar verklig roll. Signalen är sgl-project/sglang#43048, öppnad 2026-10-08 kl. 03:47 UTC av GitHub-kontot shiyang814-cpu, senast ändrad 03:55 UTC, och fortfarande markerad som utkast, utan registrerad godkännandegranskning och utan merge. Den ändrar sex filer — två testfiler, Qwen4Exp-modellfilen, LayerNorm-SP-modulen, en lagergränsfabrik och en argumentgruppshook — med +345 och −50 rader. Alla prestandasiffror nedan kommer från PR-beskrivningen, är författarens egen parvisa OFF/ON-mätning och har inte reproducerats av någon. Tre CI-körningar på revisionen i grenens topp är markerade som misslyckade. Inget här är en levererad funktion.

Vad pull requesten faktiskt ändrar

Sekvensparallellism är inte en modelländring och det är inte en ny förmåga. Det är en omkoppling av var några lager utför sin aritmetik. Dess härstamning går tillbaka till Megatron-liknande sekvensparallellism — tricket från arXiv:2205.05198 — och SGLang levererar det redan: modulens egen docstring förklarar mekanismen den återanvänder, att under ren tensorparallellism är en radparallell all_reduce är algebraiskt sett en reduce_scatter följd av en all_gather. Eftersom dessa två kollektiv flyttar exakt samma byte som den enskilda all_reduce de ersätter, att dela upp operationen på det sättet kostar ingen extra kommunikationsvolym alls. Vad det ger är friheten att låta normaliserings- och residualregionerna köra på sekvens-shardade aktiveringar — varje tensorparallell rank håller en 1/tp-del av token-raderna — vilket minskar det transienta aktiveringsminnet som långkontext-prefill behöver hålla vid liv.

Vad den här specifika pull requesten gör är att utöka den befintliga vägen från arkitekturen som den validerades på till Qwen4Exp-arkitekturen. Under prefill förblir aktiveringarna för Gated Residual och Per-Layer Embedding shardade längs token-dimensionen över TP-gruppen. Innan attention, innan GDN, innan QSA och innan Mixture-of-Experts-blocket körs, all-gatheras de fullständiga token-raderna tillbaka, den befintliga tensor-parallella beräkningen för hela rader körs oförändrat bakom en gemensam fallback, och en reduce-scatter summerar sedan de partiella bidragen och återställer varje ranks shard. Decode rör aldrig den nya vägen alls. Funktionen nås via det alternativ som redan finns – --enable-layernorm-sp – utan någon Qwen4Exp-specifik flagga, och när flaggan saknas beter sig koden exakt som den gjorde tidigare.

Qwen4Exp är arkitekturen som behöver detta

Anledningen till att detta spelar roll specifikt för Qwen4Exp, och inte i lika hög grad för varje modell, ligger i arkitekturens egen design. Qwen3.8-Flash-Next tillämpar Gated Residual-projektioner på alla tokenrader i varje dekoderlager — konfigurationen deklarerar fyra residualströmmar och en bottleneck-rank på 320 över 48 lager — och Per-Layer Embedding lägger till ytterligare en replikerad projektion, tokenrad för tokenrad, ovanpå det. Under tensor-parallellism dupliceras båda dessa operationer identiskt på varje rank, eftersom de inte bär någon egen TP-shardad viktmatris som tvingar fram en uppdelning. Att sharda deras tokendimension tar bort det replikerade arbetet direkt, och som PR:ens motiveringsavsnitt uttrycker det sker det samtidigt som den befintliga tensor-parallella layouten och reduktionssemantiken för attention, GDN/QSA och MoE bevaras — vilket är den del som gör ändringen säker snarare än smart.

Det är värt att säga rakt ut vad det innebär för läsaren. Det intressanta med den här PR:en är inte att SGLang blir snabbare. Det är att Qwen4-arkitekturen har kostnader per lager som skalar med antalet tokens snarare än med antalet parametrar, och det är dessa kostnader som biter vid långa prefills. Det är ett designavtryck, och det är sådant som ett datablad aldrig nämner.

De uppmätta deltana

Författarens benchmark fixerar en konfiguration och växlar flaggan: fyra NVIDIA H20-GPU:er, Qwen3.8-Flash-Next-FP8, tensor-parallellism 4 och expert-parallellism 4, chunked prefill-storlek 8192, FlashInfer-backends för linjär-attention-prefill och -decode, samma serverkonfiguration för OFF och ON, omväxlande OFF → ON → OFF → ON-tjänsteomstarter, och fasta token-indata med uppvärmningsförfrågningar. Varje siffra nedan kommer från den uppsättningen och är ogranskad:

• 32K indata, batchstorlek 1 – TTFT förbättrades med 17,72–18,36 %, latens från ände till ände cirka 16 %, indata-genomströmning cirka 20 %

• 235K indata, batchstorlek 1 — TTFT förbättrades 14,63–14,71 %, end-to-end-latens cirka 14 %, indata-genomströmning cirka 17 %

• 32K indata, batchstorlek 4 — TTFT förbättrades med 18,74 %, total latens 18,14 %, indata-genomströmning 22,14 %

• Toppminne – minskat med cirka 1,0 GiB per GPU

• Avkodning, batchstorlek 1 — tid per utdatatoken i praktiken oförändrad

Den sista raden är den man ska läsa två gånger, och författaren är uppriktig om varför: den här optimeringen är endast aktiverad för prefill, så single-stream-avkodning får inget av den. Förbättringen av tid per token vid batch-4, där den förekommer, speglar minskade schemaläggningsfördröjningar från samtidiga långa prefills snarare än någon snabbare avkodningskärna. Om du hoppades att detta var en throughput-historia, är det inte det – det är en historia om latens till första token och minne, och det är de två begränsningarna som avgör huruvida en förfrågan på 235K token över huvud taget kan betjänas.

Layoutbuggen de var tvungna att åtgärda först

Den mest informativa delen av pull requesten är inte snabbhetstabellen. Det är avsnittet om PLE:s fysiska radlayout, eftersom det visar vad Qwen4Exp-servingstacken fortfarande gör fel.

Per-Layer Embedding arbetar på en fast fysisk CUDA-grafbucket, medan endast ett prefix av raderna i den bucketen kan innehålla riktiga tokens. Paddingen måste därför appliceras innan sekvensen shardas, inte efter. I den sista chunken av en 235K-token-förfrågan är författarens siffror 5 624 bearbetade tokens i en fysisk bucket med 8 192 rader vid TP 4, och den enda korrekta layouten är rank 0 med 2 048 giltiga rader, rank 1 med 2 048 giltiga rader, rank 2 med 1 528 giltiga rader plus 520 paddingrader, och rank 3 med 2 048 rader padding. Att sharda de 5 624 bearbetade raderna först – den uppenbara implementationen – infogar padding mellan globalt sammanhängande giltiga intervall och korrumperar resultatet. Författaren noterar att ett verkligt 235K OFF/ON-test endast producerade identisk greedy-utdata på 16 tokens efter att denna layout hade fixats.

Det är en liten detalj med stor innebörd. PLE-vägen i SGLang lades till så pass nyligen att en tokenordningsbugg av detta slag fortfarande var möjlig, och personen som hittade den höll på att skriva det sekvensparallella tillägget. Day-zero-serveringsstöd för den här arkitekturen är inte färdigt; det byggs aktivt, öppet, av bidragsgivare, en layout i taget.

Vad det kostar dig: begränsningarna

En flagga som bara hjälper vissa driftsättningar är bara användbar om man vet vilka. PR:en anger sina krav explicit, och konfigurationer utanför dem misslyckas under argumentvalidering i stället för att tyst försämras:

• Tensor parallel-storleken måste vara större än 1 – en en-GPU-distribution ger ingenting, eftersom det inte finns någon rank att sharda över

• Expert-parallellstorlek måste vara lika med tensor-parallellstorlek

• Pipeline-parallell storlek måste vara lika med 1

• Dataparallell attention måste inaktiveras

• Speculativ avkodning måste inaktiveras

Det sista villkoret är det som har ett verkligt beslut bakom sig. För en gles modell som aktiverar runt 6B parametrar per token är spekulativ avkodning en av de få spakarna som accelererar avkodningen, och den här funktionen stänger uttryckligen av den spaken i utbyte mot en prefill-vinst. Om din arbetsbelastning är lång prompt och kort utdata – dokument- och kodbasanalys, videosammanfattning, en stor kontext som läses en gång – är avvägningen otvetydigt bra. Om din arbetsbelastning är en kort prompt och en lång generering ger du upp det som hjälpte dig och köper ett tal som inte gäller dig. Kravet att expert-parallellism är lika med tensor-parallellism är det andra att lägga märke till: det betyder att moe-shardningsgeometrin måste matcha TP-geometrin exakt, vilket utesluter flera annars rimliga flernodslayouter.

Vad detta säger om Qwen 4-tidslinjen

Läs diffen på ett annat sätt och du får en kalender. SGLangs LayerNorm-SP-modul på huvudgrenen innehåller i dag en explicit tillåtelselista över arkitekturer för vilka funktionen har validerats, och när detta skrivs innehåller den tillåtelselistan exakt en post, Qwen3ForCausalLM — alla andra arkitekturer avvisas vid konstruktion om du skickar flaggan. Att lägga till Qwen4Exp i den vägen är därför inte en justering av en mogen abstraktion; det är första gången Qwen4-arkitekturen förs in i en optimering som är generationer äldre än den.

Ställ det mot det offentliga materialet och bilden är sammanhängande. Leverantören meddelade den 2026-09-22 att Qwen 4 är under träning och visade en förhandsvisning av fyra nivånamn – Qwen 4 Max, Qwen 4 Flash, Qwen 4 Plus och Qwen 4 27B – utan att några specifikationer kopplades till någon av dem. Förhandsvisningen med öppna vikter som delar arkitekturen, Qwen3.8-Flash-Next, har kunnat laddas ner sedan 2026-08-26. Det som har hänt under de tre veckorna sedan dess är precis vad man kan förvänta sig mellan "under träning" och "lansering": motorutvecklare som trimmar in körtidsmiljön så att stödet från dag ett är verkligt i stället för nominellt. En pull request som får en serveringsoptimering att fungera på arkitekturen, öppnad på morgonen den 2026-10-08 och fortfarande i utkast, är en bättre signal om hur nära Qwen 4 är att kunna serveras än något datum som någon har nämnt. Det är också, med eftertryck, inte ett lanseringsdatum – flaggan är avstängd som standard, ändringen är inte sammanfogad, och modellen den benchmarkar är förhandsvisningen, inte Qwen 4.

Vad du kan ringa idag

Inget av detta ändrar vad som faktiskt är tillgängligt i eftermiddag. Qwen3.8-Flash-Next är verkligt, dess vikter finns på Hugging Face, och du kan självhosta det – men det finns inte i vår katalog, och vi kommer inte att låtsas något annat. Den nivå vi faktiskt erbjuder är qwen/qwen3.8-flash, den hanterade syskonmodellen som kör samma Qwen4-preview-arkitektur med ett kontextfönster på 1M tokens och text-, bild- och videoindata, prissatt till 0,15 USD per miljon indatatoken, 0,47 USD per miljon utdata och 0,0184 USD per miljon cacheläsningar. Det är ett listpris som förs vidare med 0 % påslag, så när leverantören ändrar det ändras siffran på din faktura samma dag i stället för närhelst en mellanhand publicerar om en tabell.

Det finns en andra, mindre uppenbar anledning att bry sig om ett routningslager här. Allt i den här artikeln handlar om en obeprövad förhandsvisning plus en utkastpatch – den typ av sak man vill testa utan att satsa en produktionsväg på den. Det är vad failover är till för: placera förhandsvisningen bakom samma nyckel som modellen du redan litar på, observera hur den beter sig på din trafik, och låt begäran falla igenom till den beprövade vägen när en leverantör vacklar eller slutpunkten inte finns. Ett API för 200+ modeller, en uppsättning autentiseringsuppgifter, inget annat kontrakt som behöver signeras för att ta reda på om en ny arkitektur är värd din uppmärksamhet.

Två saker att hålla ögonen på härifrån, och ingen av dem kan vi förutsäga. Den första är huruvida den här patchen ens mergas: det är ett utkast med tre misslyckade CI-körningar på en ändring av sex filer från ett bidragsgivarkonto utan tidigare historik i repositoriet, och att PLE-radlayoutarbetet är så pass föränderligt tyder på att författaren fortfarande itererar. Den andra är huruvida tillåtelselistan växer – om Qwen4Exp ansluter sig till Qwen3ForCausalLM som en validerad arkitektur, då slutar detta vara en läcka och blir standardsättet som en modell i Qwen4-familjen serveras på lång kontext. Tills något av detta inträffar, behandla 18 % som ett löfte om vart runtime är på väg, inte som en siffra du kan hyra.