Qwen 4 QSA krijgt decode-contextparallellisme: in vLLM's concept-PR voor Qwen3.8-Flash-Next

Op 29 september 2026 verscheen een concept-pullrequest in de vLLM-repository met de titel "[Model][DCP] Support Qwen4Exp QSA", en voor het model dat erin wordt beschreven bevat deze de meest concrete servingcijfers die deze maand door wie dan ook zijn gepubliceerd: gepaarde runs van Qwen3.8-Flash-Next op vier GPU's waaruit blijkt dat de KV-tokencapaciteit stijgt van 9.759.529 naar 17.603.636, de maximale concurrency van 37,23× naar 67,15×, en de tijd tot het eerste token daalt van 1.869 ms naar 767 ms. Qwen3.8-Flash-Next is de open-weight mixture-of-experts-preview met 125 miljard parameters, waarvan de Hugging Face-kaart het beschrijft als "een preview van de Qwen4-architectuur"; de pullrequest voegt decode context parallelism toe aan het sparse-attentionpad waarop die architectuur is gebouwd. Qwen4 zelf — de Qwen4 Max-, Flash-, Plus- en 27B-tiers die de leverancier op 22 september 2026 tijdens zijn Apsara-conferentie noemde — is nog steeds niet uitgebracht, zonder gewichten, zonder identifier, zonder prijs en zonder datum. Lees dit dus als wat het is: geen lancering, geen benchmark, maar een engineering-artefact dat je vertelt hoe de serving-envelope van Qwen4 wordt verbreed voordat de familie bestaat.

Dit is een stuk over wat we tot nu toe weten, en de bronvermelding is belangrijker dan gewoonlijk. De pull request is een concept, open en niet samengevoegd — vllm-project/vllm#59279, geopend op 2026-09-29 door Sungsoo Ha, een software-engineer bij NVIDIA, en staat nog steeds als concept. Elk cijfer hieronder is de eigen gepaarde meting van de auteur, gerapporteerd in de hoofdtekst van de PR, uitgevoerd op een eerdere revisie van hetzelfde werk. Niets hier is onafhankelijk gecontroleerd, niets hier is in een release terechtgekomen, en het voorbehoud dat de auteur maakt is materieel genoeg om hieronder een eigen sectie te krijgen.

Wat de pull request daadwerkelijk verandert

Decode context parallelism — DCP — is een servingtechniek, geen modelwijziging. In plaats van dat één GPU-groep een volledige KV-cache vasthoudt, splitst DCP die cache over ranks, zodat elke rank alleen zijn eigen deel van de context leest, terwijl de attention-resultaten aan het einde over de ranks worden gecombineerd. Het doel is capaciteit: met de gepartitioneerde cache kan een deployment veel meer gelijktijdig lang-contextverkeer op dezelfde hardware verwerken, precies de beperking die knelt wanneer elk verzoek een kwart miljoen tokens meedraagt.

De complicatie is dat Qwen Sparse Attention — QSA — geen gewone attentionlaag is. Zoals de modelkaart van Qwen3.8-Flash-Next het specificeert, comprimeert een lichtgewicht indexeerder keys in microblokken met een compressieverhouding van 4, scoort ze en houdt de beste 512 blokken over, ongeveer 2.048 tokenposities, terwijl de uiteindelijke softmax en value-aggregatie nog steeds op de ongecomprimeerde K en V draaien. Dat betekent dat QSA meer state bijhoudt dan een KV-cache: er is de hoofdcache, en er zijn de selector- en side-caches die de indexeerder onderhoudt. De generieke DCP-implementatie in vLLM weet niets van dat alles.

Wat #59279 doet, volgens de beschrijving, is DCP leren over de QSA-specifieke onderdelen:

• Elke rank leest zijn eigen deel van de hoofd-KV-cache, terwijl QSA’s selector en side-caches blijven gerepliceerd over ranks in plaats van geshard.

• Na de gesplitste leesbewerking worden de attention-resultaten over de ranks gecombineerd.

• De selector en de hoofd-KV-cache worden in één cachegroep gehouden, zodat ze niet uit elkaar kunnen lopen.

• Er wordt voorkomen dat synthetische V2-batches QSA-sidecaches schrijven.

Dat laatste paar details is het interessante deel als je om correctheid geeft in plaats van doorvoer. Een gesharde attention-cache die stilletjes niet overeenkomt met een gerepliceerde selector is het soort bug dat zich uit als een langzame afname van de nauwkeurigheid bij lange context in plaats van een crash, en de wijziging is expliciet over het in de pas houden van de twee. De auteur stelt ook dat er AI-assistentie is gebruikt en Codex wordt als medeauteur vermeld — dit is het waard om gewoon te zeggen, want in een concept-PR van deze vorm is het een terechte vraag wie wat heeft geschreven.

De gepaarde getallen, en hoe ze werden genomen.

Het testplan is specifiek genoeg om controleerbaar te zijn, en daarom zijn de resultaten het citeren waard. Beide armen draaien Qwen/Qwen3.8-Flash-Next-FP8 op vier GPU's met tensorparallellisme 4 en expertparallellisme ingeschakeld, bij --gpu-memory-utilization 0.90 met prefixcaching aan. Het enige verschil tussen de twee armen is --decode-context-parallel-size: weggelaten voor DCP=1, ingesteld op 2 voor DCP=2, met een herstart tussen de armen zodat de benchmark vanuit een koude cache begint. De belasting is een AgentX 256k-trace bij 128 gebruikers gedurende 900 seconden; de nauwkeurigheid is EvalScope voor GSM8K plus de ingecheckte MRCR-evaluator, zes keer per arm uitgevoerd, waarbij de eerste run na de herstart wordt weggegooid.

De gerapporteerde doorvoerverschillen, DCP=2 ten opzichte van DCP=1:

• KV-tokens — 9.759.529 vs 17.603.636, een toename van 1,80× in cachecapaciteit.

• Maximale gelijktijdigheid — 37,23× vs 67,15×, ook 1,80×.

• Verzoeken per seconde — 1.69 vs 2.30, 1.36×.

• Invoertokens per seconde — 128.730 vs 179.702, 1,40×.

• Tijd tot eerste token — 1.869 ms vs 767 ms, 2,44× lager.

• Inter-tokenlatentie — 43,48 ms vs. 26,27 ms, 1,66× lager.

• Hitratio van prefix-cache in steady state — 67,85% vs 88,98%, een winst van 21,1 procentpunten.

Nauwkeurigheid, gerapporteerd als gemiddelde ± steekproefstandaardafwijking over runs na de warmup, was vrijwel vlak: MRCR-aggregatie 0,8630 ± 0,0005 bij DCP=1 tegenover 0,8697 ± 0,0153 bij DCP=2, en GSM8K 0,9788 ± 0,0020 tegenover 0,9790 ± 0,0016. De MRCR-steekproeven met 2 naalden en 4 naalden waren op beide armen vastgezet op 0,9960 en 0,9906, dus alle variatie tussen runs kwam van de steekproeven met 8 naalden — en één aggregatierun met DCP=2 scoorde 0,8970, terwijl de andere vier tussen 0,8620 en 0,8632 lagen. Dat is een echte spreiding, geen ruis die je weg kunt wuiven, en die wordt in de PR vermeld in plaats van gladgestreken.

Wat deze cijfers niet aantonen

Het voorbehoud staat in de PR-tekst en is niet gering. De gepaarde AgentX- en nauwkeurigheidsresultaten zijn gemeten op een eerdere QSA DCP-revisie, met een vLLM-nightly op basis van commit 3df4ae153eb. De definitieve schone commit in de pull request bevat een daaropvolgende fix voor de QSA-localisatiekernel en is geslaagd voor gerichte B200-validatie — maar de volledige AgentX- en nauwkeurigheidsevaluaties zijn niet herhaald op die exacte bron. Met andere woorden: het doorvoerverhaal en de geleverde diff zijn niet hetzelfde artefact, en de auteur zegt dat zelf.

Daarnaast geldt de gebruikelijke discipline, en hier geldt die des te strenger. Dit zijn cijfers uit één enkele configuratie, van één enkele bijdrager, op één enkele opstelling met vier GPU's. Ze zijn niet neutraal, maar staan dicht bij de leverancier: dat een bijdrager aan een framework een wijziging in dat framework meet, is normaal en nuttig, maar het is geen onafhankelijke audit, en geen enkele derde partij heeft de run gereproduceerd. Er is vandaag geen uitgebrachte vLLM-versie die je kunt installeren en die deze wijziging bevat, omdat de wijziging niet is samengevoegd. En DCP=2 is een splitsing in tweeën van één specifieke vorm — de delta's zijn geen belofte over wat DCP=4 of DCP=8 zouden doen, en niets in de PR beweert dat.

Waarom een serving-PR over een nog niet uitgebrachte architectuur toch de moeite waard is

Het voor de hand liggende bezwaar: het model in de titel bestaat niet, dus waarom zou je je er iets van aantrekken? Omdat wat er wordt afgestemd niet Qwen 4 is. Het is Qwen3.8-Flash-Next, en dat model bestaat wel — Alibaba publiceerde het op 2026-08-24 als een MoE met 125B parameters waarvan 6B geactiveerd, een n-gram-embeddingtabel van 51 miljard parameters, een MTP-head van 4B voor speculatieve decoding, 48 lagen gerangschikt als twaalf herhalingen van drie Gated DeltaNet-blokken gevolgd door één QSA-blok, 512 experts met 10 gerouteerde en 1 gedeelde expert actief, en een native context van 262.144 tokens die volgens de modelkaart uitbreidbaar is tot 1.000.000. Het is de referentie-implementatie van de Qwen4-architectuur in open gewichten, en QSA — de micro-block sparse attention die deze pull request DCP leert sharden — is het meest onderscheidende onderdeel ervan.

Wat de cijfers beschrijven, is wat er gebeurt wanneer je die context van 262K niet langer behandelt als iets dat één GPU-groep in zijn geheel moet vasthouden. De sprong van 1,80× in KV-tokencapaciteit en gelijktijdigheid is de rekensom van het in tweeën splitsen van een cache, wat het minst verrassende resultaat in de lijst is. De interessantere cijfers zijn de latentiecijfers: 2,44× kortere tijd tot het eerste token en 1,66× lagere latentie tussen tokens bij dezelfde aangeboden belasting, plus een verbetering van 21 punten in de hitratio van de prefixcache in stabiele toestand. Die cijfers zeggen dat het DCP-pad niet louter capaciteit koopt ten koste van latentie — in deze gepaarde run leverde het beide op. Dat is de vorm van verandering die ertoe doet voor iedereen die agentverkeer met zeer lange systeemprompts bedient, want het gedrag van de prefixcache bij lange context is meestal waar de doorvoer bij lange context stilletjes instort.

En dit is geen geïsoleerde patch. In diezelfde week ontstond een cluster aan Qwen4Exp-enginewerk: #59214 voegt SM100 GEMM-plannen voor low-latency decode voor B200-vormen toe, #59010 voegt een SM90-native sparse-prefillkernel toe voor het QSA-pad op Hopper, #58977 omvat BF16 INC PLE-embeddings, en #58961 — degene die daadwerkelijk is gemerged, op 2026-09-28 — herstelde een profiling-KV-cache die door QSA-sleutelviews in leven werd gehouden. Samen gelezen vormen ze de serveringsenvelop van de Qwen4-architectuur die in het openbaar wordt gebouwd, in de runtimes, maanden voordat de familie wordt uitgebracht. Als je je op Qwen 4 voorbereidt, is het nuttige signaal niet een releasedatum — die is er niet — maar wat de kernels en cachelay-outs al veronderstellen over hoe je het zult moeten serveren.

Wat je vandaag kunt bellen

Als je het gedrag bij lange contexten wilt testen op de architectuur waar deze PR over gaat, is het model waar je naar moet grijpen de Flash-tier die Alibaba daadwerkelijk aanbiedt. Qwen3.8-Flash — de productie-implementatie gebouwd op Qwen3.8-Flash-Next, met een context van 1.000.000 tokens en een maximale output van 131.072 tokens, met tekst-, beeld- en video-invoer — is live, en het is één endpoint voor het model dat vandaag daadwerkelijk de Qwen4Exp-architectuur draait, vermeld als qwen/qwen3.8-flash tegen $0,15 per miljoen inputtokens en $0,47 per miljoen outputtokens, met cache-reads tegen $0,0184. Omdat dit lijstprijzen van de provider zijn die zonder marge aan onze kant worden doorgegeven, bereikt een prijs- of limietwijziging van de leverancier voor dit model je op dezelfde dag dat die wordt aangekondigd.

Twee eerlijke voorbehouden. Ten eerste staat Qwen3.8-Flash-Next zelf — de FP8-gewichten in de test van de pull request, die je nodig zou hebben om een van de metingen lokaal te reproduceren — niet in onze catalogus; de geserveerde Flash-tier is de QwenCloud-productielijn, niet het ruwe preview-checkpoint. Als je de exacte configuratie uit de PR wilt draaien, host je zelf op vier GPU's. Ten tweede is de DCP-wijziging niet samengevoegd, dus alles wat je vandaag waar dan ook kunt aanroepen, draait het. Wat de geserveerde tier je geeft, is een manier om erachter te komen of je workload überhaupt is toegesneden op het probleem dat DCP oplost: als je prompts lang, agentisch en prefix-intensief zijn, dan zijn de 1,80× capaciteit en de prefix-cache-delta de cijfers waar je op moet letten in je eigen traces.

En als het interessante deel voor jou niet één model is, maar de omschakelingsvraag — op welk tier je moet bouwen terwijl de Qwen 4-line-up nog geen naam heeft — dan is dat een routeringsprobleem in plaats van een servingprobleem, en één API voor 200+ modellen is hoe je de optie openhoudt zonder een tweede contract of een codewijziging wanneer de familie eindelijk verschijnt.

Vragen die het waard zijn om direct te beantwoorden

Betekent #59279 dat Qwen 4 uit is, of op het punt staat uit te komen?

Nee. De pull request gaat over de Qwen4Exp-architectuur zoals geïmplementeerd in Qwen3.8-Flash-Next, die Alibaba op 24 augustus 2026 uitbracht. De Qwen 4-familie — Max, Flash, Plus en 27B — werd op 22 september 2026 op een podium in Apsara genoemd en op een bedrijfsroadmap geplaatst met een opvolgerlijn die op 5 tot 10 biljoen parameters wordt geraamd, en heeft nog steeds geen modelcard, geen gewichten, geen API-identifier, geen contextvenster, geen prijs en geen datum. Een framework-PR die een parallellismemodus toevoegt aan de preview-architectuur is een stap naar het goed kunnen serveren van Qwen 4. Het is geen stap naar het bestaan van Qwen 4.

Hoe verschilt decode-contextparallellisme van tensorparallellisme?

Ze splitsen verschillende dingen en falen op verschillende manieren. Tensor-parallelisme partitioneert de gewichten en de berekening van elke laag over GPU's, zodat elke rank aan elke token deelneemt maar de hele sequentie ziet. Decode-contextparallelisme partitioneert de KV-cache zelf, zodat elke rank slechts een deel van de context vasthoudt en leest, en de gedeeltelijke attention-resultaten daarna worden samengevoegd. TP gaat over het laten passen van het model; DCP gaat over het laten passen van de context en het gelijktijdige verkeer dat daarop meelift. Dat onderscheid is precies waarom deze PR niet triviaal is: de selector en nevencaches van QSA kunnen niet eenvoudigweg worden geshard zoals de hoofd-KV-cache dat kan, dus de wijziging moet er één sharden en de overige repliceren, en vervolgens bewijzen dat de twee consistent blijven.

Als ik Qwen3.8-Flash-Next vandaag via een gehoste API aanroep, krijg ik dan al deze cijfers?

Nee, en de kloof bestaat uit drie delen. De wijziging is niet samengevoegd, dus geen enkele vrijgegeven vLLM-build bevat die. Zelfs nadat ze is samengevoegd, moet de provider die build overnemen en ervoor kiezen om te draaien met een DCP-grootte boven één — het is een servingconfiguratie, geen standaardinstelling. En de gemeten delta's komen uit een eerdere revisie van de patch, niet uit de definitieve commit, waarvan de auteur aangeeft dat die tot nu toe alleen gerichte B200-validatie heeft gehad. Beschouw de gerapporteerde delta's als een goed gedocumenteerde bovengrens voor wat de aanpak oplevert in één configuratie, niet als een specificatie van een endpoint dat je deze week kunt huren.

De open vraag

Het punt om in de gaten te houden is niet of deze specifieke draft wordt samengevoegd — dat zal waarschijnlijk in een of andere vorm gebeuren, aangezien de QSA-specifieke cacheafhandeling die eraan wordt toegevoegd een echte leemte is en niet een voorkeur. Het punt om in de gaten te houden is of de uiteindelijke commit dezelfde gepaarde evaluatie krijgt als de tussenliggende revisie. Een wijziging in de serving waarvan de doorvoerclaims uit de ene build komen en de correctheidsclaims uit een andere is voorlopig een goed beargumenteerd voorstel in plaats van een gemeten resultaat, en de spreiding in nauwkeurigheid bij de 8-needle MRCR-samples is groot genoeg dat het herhalen van de run op de uitgebrachte bron het nuttigste zou zijn dat iemand erover zou kunnen publiceren. Tot dan: de richting is leesbaar, het grootboek is niet gesloten, en het enige model met Qwen4-architectuur in open gewichten blijft dat van augustus.