Qwen 4 QSA får dekodningskontext-parallellism: inuti vLLMs PR-utkast för Qwen3.8-Flash-Next

Den 29 september 2026 dök ett utkast till pull request upp i vLLM-repositoriet med titeln ”[Model][DCP] Support Qwen4Exp QSA”, och för den modell den beskriver innehåller den de mest konkreta serving-siffrorna som någon har publicerat under hela månaden: parvisa körningar av Qwen3.8-Flash-Next på fyra GPU:er som visar att KV-tokenkapaciteten går från 9 759 529 till 17 603 636, att maximal samtidighet går från 37,23× till 67,15× och att tiden till första token sjunker från 1 869 ms till 767 ms. Qwen3.8-Flash-Next är förhandsversionen av en mixture-of-experts-modell med öppna vikter och 125 miljarder parametrar, vars Hugging Face-kort beskriver den som ”A Preview of the Qwen4 Architecture”; pull requesten lägger till decode context parallelism till den sparse-attention-vägen som arkitekturen är uppbyggd kring. Qwen4 i sig – Qwen4 Max-, Flash-, Plus- och 27B-nivåerna som leverantören namngav vid sin Apsara-konferens den 22 september 2026 – är fortfarande inte släppt, utan vikter, utan identifierare, utan pris och utan datum. Så läs detta som vad det är: inte en lansering, inte ett benchmark, utan en ingenjörsartefakt som berättar hur Qwen4:s serving-envelopp vidgas innan familjen existerar.

Det här är en lägesrapport om vad vi vet hittills, och källorna spelar större roll än vanligt. Pull requesten är ett utkast, öppen och inte mergad — vllm-project/vllm#59279, öppnad den 2026-09-29 av Sungsoo Ha, en mjukvaruingenjör på NVIDIA, och ligger fortfarande som utkast. Alla siffror nedan är författarens egen parvisa mätning, rapporterad i PR-beskrivningen, utförd på en tidigare revision av samma arbete. Inget här är oberoende granskat, inget här har hamnat i en release, och förbehållet som författaren bifogar är tillräckligt väsentligt för att få ett eget avsnitt nedan.

Vad pull requesten faktiskt ändrar

Decode-kontextparallellism – DCP – är en servingteknik, inte en modelländring. I stället för att en GPU-grupp håller en hel KV-cache delar DCP upp den cachen mellan rankar, så att varje rank bara läser sin del av kontexten medan attention-resultaten kombineras mellan rankarna i slutet. Poängen är kapacitet: med cachen partitionerad kan en driftsättning hantera långt mycket mer samtidig långkontexttrafik på samma hårdvara, vilket är precis den begränsning som biter när varje begäran bär en kvarts miljon tokens.

Komplikationen är att Qwen Sparse Attention — QSA — inte är ett vanligt attention-lager. Som modellkortet för Qwen3.8-Flash-Next anger det, komprimerar en lättviktig indexerare nycklar till mikroblock med en komprimeringsfaktor på 4, poängsätter dem och behåller de bästa 512 blocken, ungefär 2 048 tokenpositioner, medan den slutliga softmaxen och värdeaggregeringen fortfarande körs på de okomprimerade K och V. Det innebär att QSA bär mer tillstånd än en KV-cache: det finns huvudcachen, och det finns selector- och sidocacherna som indexeraren underhåller. Den generiska DCP-implementeringen i vLLM känner inte till något av detta.

Vad #59279 gör, enligt dess beskrivning, är att lära DCP om de QSA-specifika delarna:

• Varje rank läser sin egen del av den huvudsakliga KV-cachen, medan QSA:s väljare och sidocacher förblir replikerade mellan rankar snarare än shardade.

• Attention-resultaten kombineras över rankar efter den delade läsningen.

• Väljaren och huvud-KV-cachen hålls i en cachegrupp, så att de inte kan glida ifrån varandra.

• Syntetiska V2-batcher förhindras från att skriva QSA-sidocachar.

Det sista paret detaljer är det intressanta om man bryr sig om korrekthet snarare än genomströmning. En shardad attention-cache som i tysthet inte stämmer överens med en replikerad selector är den typ av bugg som visar sig som en långsam försämring av noggrannheten vid lång kontext snarare än en krasch, och ändringen är tydlig med att hålla de två synkroniserade. Författaren anger också att AI-assistans användes och Codex anges som medförfattare – värt att säga rakt ut, eftersom det i en utkast-PR av detta slag är en rimlig fråga att ställa vem som skrev vad.

De parade numren, och hur de togs fram

Testplanen är tillräckligt specifik för att kunna kontrolleras, vilket är anledningen till att resultaten är värda att citera. Båda armarna betjänar Qwen/Qwen3.8-Flash-Next-FP8 på fyra GPU:er med tensor-parallellism 4 och expert-parallellism aktiverad, vid --gpu-memory-utilization 0.90 med prefix-cachning på. Den enda skillnaden mellan de två armarna är --decode-context-parallel-size: utelämnad för DCP=1, satt till 2 för DCP=2, med en omstart mellan armarna så att benchmarken börjar från en kall cache. Belastningen är ett AgentX 256k-spår med 128 användare i 900 sekunder; noggrannheten är EvalScope för GSM8K plus den incheckade MRCR-utvärderaren, körd sex gånger per arm där den första körningen efter omstarten förkastas.

De rapporterade genomströmningsskillnaderna, DCP=2 mot DCP=1:

• KV-tokens — 9 759 529 vs 17 603 636, en 1,80× ökning av cachekapaciteten.

• Maximal samtidighet — 37,23× mot 67,15×, även 1,80×.

• Förfrågningar per sekund — 1,69 mot 2,30, 1,36×.

Indatatokens per sekund – 128 730 mot 179 702, 1,40×.

• Tid till första token — 1 869 ms vs 767 ms, 2,44× lägre.

• Inter-token-latens — 43,48 ms vs 26,27 ms, 1,66× lägre.

• Träffrekvens för prefixcache i stabilt tillstånd — 67,85 % mot 88,98 %, en förbättring med 21,1 procentenheter.

Noggrannhet, rapporterad som medelvärde ± stickprovsstandardavvikelse över körningar efter uppvärmning, var i stort sett oförändrad: MRCR-aggregat 0,8630 ± 0,0005 vid DCP=1 jämfört med 0,8697 ± 0,0153 vid DCP=2, och GSM8K 0,9788 ± 0,0020 jämfört med 0,9790 ± 0,0016. MRCR-proverna med 2 nålar och 4 nålar var fasta vid 0,9960 respektive 0,9906 i båda armarna, så all variation mellan körningarna kom från 8-nålsproverna – och en aggregerad DCP=2-körning fick 0,8970 medan de övriga fyra låg mellan 0,8620 och 0,8632. Det är en verklig spridning, inte brus som man kan vifta bort, och den anges i PR:en i stället för att slätas över.

Vad dessa siffror inte fastställer

Förbehållet finns i PR-texten och det är inte litet. De parade AgentX- och noggrannhetsresultaten mättes på en tidigare QSA DCP-revision, med en vLLM-nightly baserad på commit 3df4ae153eb. Den slutliga rena commiten i pull requesten innehåller en efterföljande fix för QSA-lokaliseringskärnan och har klarat fokuserad B200-validering – men de fullständiga AgentX- och noggrannhetsutvärderingarna har inte upprepats på exakt den källan. Med andra ord: throughput-berättelsen och den levererade diffen är inte samma artefakt, och författaren säger det.

Utöver det gäller den vanliga disciplinen, och den gäller med eftertryck här. Detta är siffror från en enda konfiguration från en enda bidragsgivare på en enda fyr-GPU-uppsättning. De är leverantörsnära snarare än neutrala: att en ramverksbidragsgivare mäter en ramverksändring är normalt och användbart, men det är inte en oberoende granskning, och ingen tredje part har reproducerat körningen. Det finns ingen släppt vLLM-version som du kan installera i dag som innehåller den här ändringen, eftersom ändringen inte har slagits samman. Och DCP=2 är en tvåvägsuppdelning av en specifik form — deltavärdena är inte ett löfte om vad DCP=4 eller DCP=8 skulle göra, och inget i PR:en gör anspråk på att de är det.

Varför en serving-PR för en orelanserad arkitektur fortfarande är värd din tid

Den uppenbara invändningen: modellen i titeln finns inte, så varför bry sig? Därför att det som finjusteras inte är Qwen 4. Det är Qwen3.8-Flash-Next, och den modellen finns — Alibaba publicerade den 2026-08-24 som en MoE med 125B parametrar, varav 6B aktiva, en n-gram-inbäddningstabell på 51 miljarder parametrar, ett 4B MTP-huvud för spekulativ avkodning, 48 lager ordnade som tolv upprepningar av tre Gated DeltaNet-block följt av ett QSA-block, 512 experter med 10 routade och 1 delad aktiva, samt en inbyggd kontext på 262,144 token som kortet säger kan utökas till 1,000,000. Det är referensimplementationen av Qwen4-arkitekturen i öppna vikter, och QSA — den glesa attentionen i mikroblock som den här pull requesten lär DCP att sharda — är den enskilt mest utmärkande delen av den.

Vad siffrorna beskriver är vad som händer när man slutar behandla den där 262K-kontexten som något en enda GPU-grupp måste hålla hel. Hoppet på 1,80× i KV-tokenkapacitet och samtidighet är aritmetiken i att dela en cache i två, vilket är det minst överraskande resultatet i listan. De mer intressanta siffrorna är latenssiffrorna: 2,44× kortare tid till första token och 1,66× lägre latens mellan token vid samma erbjudna last, plus en förbättring på 21 procentenheter i träffrekvensen för prefixcachen i stabilt tillstånd. De säger att DCP-vägen inte bara köper kapacitet mot en latenskostnad – i denna parade körning köpte den båda. Det är den form av förändring som betyder något för alla som betjänar agenttrafik med mycket långa systemprompter, eftersom prefixcachebeteende vid lång kontext vanligtvis är där genomströmningen för lång kontext tyst dör.

Och detta är inte en isolerad patch. Samma vecka producerade ett kluster av Qwen4Exp-motorarbete: #59214 lägger till SM100 GEMM-planer för låg latens vid avkodning för B200-former, #59010 lägger till en SM90-native sparse prefill-kärna för QSA-vägen på Hopper, #58977 täcker BF16 INC PLE-inbäddningar, och #58961 — den som faktiskt har mergats, den 2026-09-28 — fixade en profilerings-KV-cache som QSA-nyckelvyer höll vid liv. Lästa tillsammans är de serveringsenveloppen för Qwen4-arkitekturen som byggs öppet, i körmiljöerna, månader innan familjen släpps. Om du planerar för Qwen 4 är den användbara signalen inte ett lanseringsdatum — det finns inget — utan vad kärnorna och cache-layouterna redan förutsätter om hur du kommer att behöva servera den.

Vad du kan ringa idag

Om du vill testa långkontextbeteende på den arkitektur som den här PR:en handlar om är modellen du bör ta till den Flash-nivå som Alibaba faktiskt erbjuder. Qwen3.8-Flash – produktionsdistributionen byggd på Qwen3.8-Flash-Next, med en kontext på 1 000 000 token och en maximal utdata på 131 072 token, som tar text-, bild- och videoindata – är live, och det är en slutpunkt för modellen som faktiskt kör Qwen4Exp-arkitekturen idag, listad som qwen/qwen3.8-flash till $0.15 per miljon indatatoken och $0.47 per miljon utdatatoken, med cacheläsningar på $0.0184. Eftersom detta är leverantörens listpriser som förs vidare utan påslag från vår sida, når en pris- eller gränsändring från leverantören dig samma dag som den tillkännages.

Två ärliga förbehåll. För det första finns Qwen3.8-Flash-Next i sig – FP8-vikterna i pull requestens testplan, de du skulle behöva för att reproducera någon av dessa mätningar lokalt – inte i vår katalog; den Flash-nivå som erbjuds är QwenClouds produktionslinje, inte den råa förhandsvisnings-checkpointen. Om du vill köra den exakta konfigurationen i PR:en självhostar du på fyra GPU:er. För det andra är DCP-ändringen inte mergad, så inget du kan anropa någonstans idag kör den. Det den erbjudna nivån ger dig är ett sätt att ta reda på om din arbetsbelastning ens är formad för problemet som DCP löser: om dina prompter är långa, agentiska och prefix-tunga, då är 1,80× kapacitet och prefix-cache-deltat siffrorna att hålla koll på i dina egna traces.

Och om den intressanta delen för dig inte är en enskild modell utan växlingsfrågan – vilken nivå man ska bygga på medan Qwen 4-serien fortfarande är namnlös – så är det ett routingproblem snarare än ett serveringsproblem, och ett API för 200+ modeller är hur du håller möjligheten öppen utan ett andra kontrakt eller en kodändring när familjen till slut lanseras.

Frågor värda att besvara direkt

Betyder #59279 att Qwen 4 är ute, eller är på väg att bli det?

Nej. Pull requesten handlar om Qwen4Exp-arkitekturen såsom den implementerats i Qwen3.8-Flash-Next, som Alibaba släppte den 24 augusti 2026. Qwen 4-familjen – Max, Flash, Plus och 27B – namngavs på en scen vid Apsara den 22 september 2026 och placerades på en företagsfärdplan med en efterföljarlinje projicerad till 5 till 10 biljoner parametrar, och den har fortfarande inget modellkort, inga vikter, ingen API-identifierare, inget kontextfönster, inget pris och inget datum. En ramverks-PR som lägger till ett parallellitetsläge i förhandsvisningsarkitekturen är ett steg mot att kunna servera Qwen 4 väl. Det är inte ett steg mot att Qwen 4 existerar.

Hur skiljer sig kontextparallellism vid avkodning från tensorparallellism?

De delar upp olika saker och misslyckas på olika sätt. Tensor-parallellism partitionerar vikterna och beräkningen för varje lager över GPU:er, så varje rank deltar i varje token men ser hela sekvensen. Decode-kontextparallellism partitionerar KV-cachen själv, så varje rank håller och läser bara en del av kontexten och de partiella attention-resultaten slås samman efteråt. TP handlar om att få plats med modellen; DCP handlar om att få plats med kontexten och den samtidiga trafiken som följer med den. Den distinktionen är precis varför denna PR inte är trivial: QSA:s selector och sidocachar kan inte helt enkelt shardas på samma sätt som huvud-KV-cachen kan, så ändringen måste sharda en och replikera de andra, och sedan bevisa att de två förblir konsistenta.

Om jag anropar Qwen3.8-Flash-Next i dag via ett hostat API, får jag redan dessa siffror?

Nej, och gapet har tre delar. Ändringen är inte mergad, så inget släppt vLLM-bygge innehåller den. Även när den väl är mergad måste leverantören adoptera det bygget och välja att köra med en DCP-storlek över ett – det är en serveringskonfiguration, inte en standard. Och de uppmätta deltavärdena kommer från en tidigare revision av patchen, inte från den slutliga commiten, som författaren uppger än så länge bara har genomgått fokuserad B200-validering. Betrakta de rapporterade deltavärdena som en väl dokumenterad övre gräns för vad metoden ger i en konfiguration, inte som en specifikation av någon endpoint du kan hyra den här veckan.

Den öppna frågan

Det man bör hålla ögonen på är inte huruvida detta specifika utkast slås samman – det kommer det förmodligen att göra i någon form, eftersom den QSA-specifika cachehanteringen som det lägger till är en verklig lucka och inte en preferens. Det man bör hålla ögonen på är huruvida den slutgiltiga commiten får samma parade utvärdering som den mellanliggande revisionen fick. En serveringsändring vars genomströmningsanspråk kommer från en byggversion och vars korrekthetsanspråk kommer från en annan är för närvarande ett välargumenterat förslag snarare än ett uppmätt resultat, och spridningen i noggrannhet hos MRCR-proverna med 8 nålar är tillräckligt stor för att en upprepning av körningen på den levererade källkoden skulle vara det enskilt mest användbara som någon kunde publicera om den. Fram till dess: riktningen är tydlig, liggaren är inte stängd, och den enda modellen med Qwen4-arkitektur i öppna vikter är fortfarande den från augusti.