Qwen4Exp batch-shakeling sampling: in vLLM PR #61018, en wat het zegt over Qwen 4

Het meest informatieve getal in vLLM pull request #61018 is een verlies: 1,5%. Dat is de bovengrens die de auteur zelf aan zijn eigen wijziging stelt — ruwweg 0,6 tot 0,8 milliseconden bespaard op een gemiddelde stap van 42 milliseconden, gemeten op een machine die niet van hem is, in een patch die hij helemaal niet kan uitvoeren. De pull request, getiteld "[Model] Qwen4Exp: support batch-sharded sampling (compute_logits_local)" en geopend op 10 oktober 2026 door bijdrager kimseunghyun-kr, voegt drie regels modelcode toe aan twee bestanden, zodat de Qwen4Exp-architectuur een samplingpad kan volgen dat vLLM in augustus uitbracht. Het is een concept. Het zijn 14 regels modelcode plus 57 regels test. En toch is het de moeite waard om het aandachtig te lezen, vanwege wat die drie regels verbergen: Qwen4Exp is de architectuur in Qwen3.8-Flash-Next, het open-weightmodel met 125 miljard parameters dat de leverancier op 24 augustus 2026 publiceerde als "een experimentele preview van de architectuur die ten grondslag zal liggen aan Qwen4" — en een bug met twee paden in de alleen-teksthelft van die architectuur is precies het soort detail dat je alleen leert kennen door naar de servinglaag te kijken in plaats van naar het lanceringsbericht.

Om ondubbelzinnig te zijn over de inkadering, want dat is hier van belang: Qwen 4 zelf is nog niet uitgebracht. De leverancier noemde vier Qwen 4-tiers — Qwen 4 Max, Flash, Plus en 27B — tijdens zijn Apsara-conferentie op 2026-09-22, en heeft voor geen enkele daarvan gewichten, een identifier, een prijs, een contextlengte of een benchmark gepubliceerd. Niets hieronder is een release. Dit is een overzicht van wat we tot nu toe weten over één concept-pullrequest, en alles erin dat een getal bevat, is ofwel een tijdstempel die je kunt verifiëren, een cijfer dat de bijdrager in de body van zijn eigen PR heeft getypt, of een waarde die is uitgelezen uit een openbaar modelconfiguratiebestand.

Wat batch-sharded sampling is, in één alinea

Tensorparallelisme splitst de gewichten van een model over GPU's; de vocabulaireprojectie is de breedste afzonderlijke tensor in de stack, dus elke rank berekent normaal gesproken alleen zijn eigen deel van het vocabulaire — en vervolgens voert elke rank een all-gather uit, zodat elk ervan uiteindelijk de volledige logits voor elk verzoek in de batch bevat. Gesharde sampling keert die uitwisseling om. In plaats van het vocabulaire over ranks te repliceren, shard het de batch: elke rank samplet één deel van de verzoeken, en de ranks ruilen vocabulaire-delen met elkaar uit via een all-to-all. vLLM's eigen CLI-documentatie beschrijft de flag eenvoudigweg — "Elke rank samplet een deel van de batch in plaats van dat elke rank alles samplet" — en vermeldt de beperkingen: --enable-batch-sharded-sampling staat standaard op False, vereist tensor_parallel_size groter dan 1, ten minste tensor_parallel_size maximumaantal sequenties, en een niet-negatieve max_logprobs. De laatste regel van die documentatie is de haak waaraan deze pull request hangt: "Modellen kiezen hiervoor door compute_logits_local te implementeren."

De functie zelf is niet nieuw. vLLM heeft het samengevoegd als PR #50465 — "[Model Runner V2] batch-sharded sample," door Giancarlo Delfin — op 2026-08-24, dezelfde dag dat de gewichten van Qwen3.8-Flash-Next online kwamen. De motivatie daar was geheugen en latentie: het materialiseren van volledige target-logits kost in de orde van batchgrootte × (speculatieve tokens + 1) × vocabulairegrootte, en sharding verkleint die allocatie met een factor gelijk aan de tensor-parallelle graad, terwijl het top-k- en top-p-werk van de sampler parallel kan draaien. Het is de stap die het mogelijk maakt, niet het einddoel: de tekst van de PR zelf bestempelt gesharde draft-logits als toekomstig werk.

Waarom drie regels de hele klus waren

Dit is het eigenlijke defect, en het is een goed defect, want het is onzichtbaar van buiten de code. De Qwen4Exp-implementatie van vLLM wordt geleverd als twee klassen. Qwen4ExpForConditionalGeneration is de vision-language-wrapper — een Qwen3-VL-visiontower die op het taalmodel is vastgeschroefd — en Qwen4ExpForCausalLM is het alleen-tekstpad. De wrapper erft compute_logits_local van Qwen3_5ForConditionalGeneration, die de aanroep doorstuurt naar language_model.compute_logits_local. Maar de taalmodelklasse waarnaar de wrapper verwees, heeft die methode nooit gedefinieerd.

Dus de twee paden verkeerden in verschillende toestanden. Een vision-language-implementatie van Qwen3.8-Flash-Next kon het gesharde pad volgen; een tekst-only variant niet, omdat de methode waaraan de wrapper delegeerde niet bestond. De oplossing is één methode, identiek in de NVIDIA- en AMD-kopieën van het modelbestand:

• De methode retourneert self.logits_processor(self.lm_head, hidden_states, skip_gather=True) — de eigen vocabulaire-shard van de rank, zonder gather en zonder dat de volledige vocabulaire op enige rank wordt gematerialiseerd.

• Het volgt wat de PR "hetzelfde 3-regelige patroon als Qwen3.5 en MiniMax M3" noemt, wat het waard is om bij stil te staan: twee andere modelfamilies in dezelfde repository hadden zich al aangesloten. Qwen4Exp was simpelweg degene die dat niet had gedaan.

Het testbestand is waar de eerlijkheid van de patch het gemakkelijkst te controleren is, en waar de beperkingen ervan het gemakkelijkst te zien zijn. Het telt 57 regels, het is geparametriseerd over zowel de NVIDIA- als de AMD-modules, en het downloadt geen model. De helper bouwt de klasse met object.__new__, vervangt nn.Identity voor de taalmodel-kop, en installeert een nep-logitsprocessor die zijn invoer plus één teruggeeft terwijl hij registreert hoe hij werd aangeroepen. De eerste test stelt dat een 4.0 die erin gaat eruit komt als 5.0 en dat de geregistreerde aanroep skip_gather=True meedroeg. De tweede wikkelt het taalmodel in de klasse voor voorwaardelijke generatie en stelt dat de delegatie aankomt. Dat is een echte test van de bedrading en een test van niets anders — er wordt geen enkele kernel uitgeoefend, er wordt geen ranggrens overschreden, en het aantal betrokken GPU's is nul.

Beide feiten worden in de PR vermeld in plaats van begraven. In de docstring van het testbestand zelf wordt Qwen4Exp "een kleine, alleen-CPU-testdouble" genoemd. In de validatiesectie van de auteur staat dat hij het model op zijn macOS-opstelling helemaal niet kon importeren, omdat de transformers-build die hij had geen Qwen4ExpConfig meeleverde. De CUDA-run stond nog open. De end-to-endbenchmark — MLPerf-agentic-dataset, 20 gelijktijdige sessies, drie armen van 60 minuten — stond nog open. Het eigen logits-pad van de MTP-drafter is als ongecontroleerd gemarkeerd. LoRA wordt al upstream door de flag afgewezen, dus het valt buiten scope in plaats van een regressie te zijn. Er is ook een regel die onthult dat het concept met AI-hulp is geschreven, en de commit-trailer noemt Claude Opus 5.5 als co-auteur, wat het soort disclosure is dat normaal zou moeten zijn in een stack van deze omvang en dat meestal niet is.

De 1,5%-schatting, en de metingen waarnaast deze staat

De schatting van de contributor is een nsys-trace bij 16 gelijktijdige sessies op Qwen3.8-Flash-Next-FP8 met tensor-parallelisme 8 en expert-parallelisme over acht A100-SXM4-40GB-kaarten: ongeveer 1,6 milliseconden van een stap van 42 milliseconden, teruggebracht tot ongeveer een derde daarvan, voor een end-to-end winst van 1,5 tot 2%. Zijn hoofdpunt is de rekensom — 0,6 tot 0,8 ms op 42 ms. Let op wat daaraan vastzit: 42 ms is een inter-tokenlatentiecijfer, dus een verlaging van 1,7% is een verlaging van 1,7% op de tokengeneratietijd, niet een bewering over de doorvoer op zich.

De eerlijke vergelijking is met de eigen samengevoegde cijfers van de bovenliggende feature, omdat die end-to-end zijn gemeten door iemand met de hardware. In de Speed-Bench 2K/2K-runs die in PR #50465 zijn gepubliceerd, verplaatste batch-sharded sampling DeepSeek V4 met DSpark bij 7 speculatieve tokens en concurrency 64 van 2,62 naar 2,66 verzoeken per seconde — een doorvoerwinst van 1,53% — waarbij de mediane inter-tokenlatentie met 3,09% daalde en de tijd tot het eerste token met 1,45% steeg. Bij MiniMax M3 met DSpark bij 8 speculatieve tokens steeg de doorvoer van verzoeken met 5,38% en daalde de mediane TPOT met 8,33%, van 15,61 naar 14,31 milliseconden. En hetzelfde plan documenteert waar het niet helpt: bij concurrency 4 tot 16 vielen de runs vlak tot licht negatief uit, waarbij de concurrency-16-arm 0,54% lager uitkwam op doorvoer en 1,89% op acceptatielengte.

Dat patroon is het belangrijkste om mee te nemen. Sharded sampling loont wanneer sampling zwaar is en de batch breed is — hoge gelijktijdigheid, veel speculatieve tokens, top-k en top-p die echt werk verrichten — en het kost een beetje wanneer de batch klein genoeg is dat de all-to-all pure overhead is. Een schatting van 1,5% voor één model dat hiervoor kiest is daarmee consistent, niet ermee in tegenspraak: de cijfers 5,38% en 8,33% horen bij verschillende modellen met verschillende speculatieve budgetten, en het model in deze PR heeft zijn eigen configuratie, zijn eigen vocabulaire van 248.320 tokens en zijn eigen pad voor speculatief decoderen.

Niets ervan is geauditeerd. De cijfers van de bovenliggende PR zijn de gepaarde runs van één contributor op één node; de smoke-testcijfers hier zijn een trace op hardware die de auteur niet heeft, van een revisie van de patch die volgens hem slechts bij 16 sessies is gemeten. Een meting door één contributor in één configuratie is een nuttig signaal over de richting en een slechte basis voor een capaciteitsplan. De reden dat het onderwerp überhaupt het schrijven waard is, is de richting, niet het cijfer achter de komma.

Wat de omliggende patchcluster zegt over Qwen4Exp

Een draft-PR zou geen verhaal zijn. Het verhaal is dat Qwen4Exp in de week dat dit landde een blijvend serving-target is geworden, en de kleinste patch in dat cluster is degene die het patroon leesbaar maakt. In de zeven dagen tot 2026-10-10 bevatte vLLM, van dezelfde contributor en anderen: een FP8 main-KV-cachepad voor sparse attention op Ampere, met een KV-capaciteit die 1,83× hoger is op acht A100's en 1,87× op vier RTX 3090's, en ongeveer 2,7× zoveel requests bij concurrency 16, ten koste van ongeveer 6% hogere single-stream decode-TPOT; een fix voor W4A4 MoE-padding bij tensor-parallel 1 en expert-parallelisme; een AMD-pad dat een fallback uitvoert voor niet-ondersteunde AITER FP8 MoE-operaties en in fp16 serveert; een fix die de PLE short-convolution-state door align mode heen draagt; en een decode-kernel die e4m3-bytes vier tegelijk per register unpackt op sm_80. Een daarvan, een retune van het H200 M=4 merged QSA LL-GEMM-plan, werd op 2026-10-09 in main gemerged.

Lees die lijst als geheel en die zegt iets concreets. De Qwen4Exp-architectuur — degene die de leverancier niet heeft uitgebracht — wordt tegelijkertijd afgestemd op Ampere, Hopper, ROCm en fp16-fallback, in een project dat ondersteuning vanaf dag één levert voor modellen die mensen daadwerkelijk kunnen downloaden. De reden is niet mysterieus: Qwen3.8-Flash-Next is een echt, downloadbaar en veelgebruikt model, en het is gebouwd op de architectuur die Qwen 4 zal gebruiken. Of de Qwen 4-gewichten ooit zo zullen verschijnen, is onbekend en de leverancier heeft niets gezegd, maar de serving-envelop wordt in het openbaar verbreed, en dat is controleerbare informatie, op een manier waarop een gerucht over een oktober-novembervenster dat niet is.

Een deel van de architectonische vorm is ook openbaar, voor iedereen die de configuratie leest in plaats van de aankondiging. De config van Qwen3.8-Flash-Next vermeldt een vocabulaire van 248.320 tokens over 48 lagen, 512 experts met per token 10 gerouteerde plus één gedeelde actieve, bij een expert-tussenbreedte van 640, een hidden size van 2.560, en een native context van 262.144 tokens die wordt beschreven als uitbreidbaar tot één miljoen. Het is een hybride: de lijst met laagtypes wisselt drie lineaire-attentieblokken af met één volledige-attentieblok, en de volledige-attentieblokken gebruiken het sparse-attentiepad met een indexeerder met één head die keys met een factor vier comprimeert en een budget van 2.048 posities aanhoudt. Er is een per-laag-embeddingtabel op laag 2, een n-gram-embedding met een vocabulaire van 20 miljoen items — dat is de tabel van 47,7 GiB die andere patches in dit cluster aan het host-stagen zijn — en een MTP-head van één laag voor speculatieve decoding. De samenvatting op de modelkaart zelf luidt: "125B met 6B geactiveerd, plus 51B n-gram-embedding en 4B MTP." Een vocabulaire van 248.320 items is waarom het de moeite loont om de logits-projectie überhaupt te sharden.

Wat dit niet voor jou verandert

Het loont de moeite om precies te zijn, want een patchcluster die zo dicht opeen zit, kan als een lancering lezen. Niets van het bovenstaande is gemerged, en één onderdeel ervan — het werk aan de Ampere FP8 KV-cache — is expliciet niet gevalideerd in CI, omdat de CI van vLLM geen A100 heeft. Er is vandaag geen uitgebrachte vLLM-versie die je kunt installeren en die de Qwen4Exp sharded-sampling-opt-in bevat. Er is geen onafhankelijke benchmark van het serveergedrag van Qwen3.8-Flash-Next onder een van deze wijzigingen; elk cijfer dat hierboven wordt genoemd, komt uit de PR-body's, waardoor ze door bijdragers gerapporteerd en niet geauditeerd zijn in de specifieke zin dat geen enkele derde partij de run heeft gereproduceerd. En het belangrijkste cijfer in de PR waarmee dit stuk begon, is 1,5%, wat een echte winst is in een servingstack en geen reden om een modelkeuze te veranderen.

Wat een beslissing zou veranderen, is een volledige, geauditeerde serving-run, en die bestaat nog niet. De pacing-metingen die wél bestaan voor Qwen3.8-Flash-Next vallen volledig buiten deze patches: het model scoort een Intelligence Index van 40 op Artificial Analysis, ruim boven de mediaan van 18 voor open-weightmodellen van vergelijkbare grootte, en dat cijfer staat los van alles wat hier wordt besproken.

Wat je vandaag kunt bellen, en de routeringsinvalshoek

Dit is waar het beeld praktisch wordt voor iedereen die tot hier heeft gelezen en een gehost model wil gebruiken in plaats van er een te instrumenteren. Qwen3.8-Flash-Next staat niet in de catalogus van OrcaRouter — het is niet een van de 205 modellen die wij routeren, en er is hier geen gehost endpoint voor. Maar het productiebroertje dat het vooruitblikt is: qwen/qwen3.8-flash, de officiële Qwen3.8-Flash-release waarvan de eigen modelkaart van de leverancier zegt dat hij meer functies heeft dan de preview, inclusief standaard een context van een miljoen tokens en ingebouwde tools, is beschikbaar voor $0,15 per miljoen inputtokens en $0,47 per miljoen outputtokens, doorgegeven tegen de lijstprijs van de provider zonder opslag. Voor schaal binnen dezelfde familie kost qwen/qwen3.8-27b $0,33 en $2,40, en qwen/qwen3.8-max $2,00 en $6,00 — allemaal bereikbaar met één sleutel.

Er zijn twee redenen waarom dat voor een stuk over een nog niet uitgebrachte architectuur meer dan gewoonlijk van belang is. De eerste is de overstapkosten. Als je wilt kalibreren hoe een sparse-attentionmodel aanvoelt op jouw verkeer voordat Qwen 4 bestaat, is de vergelijking die je wilt maken er een met qwen/qwen3.8-flash tegen lijstprijs — en als je dat via een router doet, betekent dat dat het model dat je meet en het model waarop je eventueel terugvalt achter dezelfde endpoint, dezelfde SDK en dezelfde sleutel zitten, zonder dat je een tweede contract hoeft te ondertekenen. De tweede is dat elke wijziging in de serving in deze patchcluster zich richt op zelfgehoste vLLM. Als je geen acht A100's draait, zijn de 1,83× KV-capaciteit en de 1,5% samplingwinst dingen waarover je leest, niet dingen die je krijgt. Een gerouteerd endpoint is de versie hiervan die aankomt zonder buildstap: automatische failover als een provider degradeert, en een routing-DSL waarmee je een gehoste aanroep naast een zelfgehoste kunt plaatsen in één endpoint wanneer je wel eigen hardware hebt om te meten.

Het enige wat je niet moet doen, is dit artikel lezen als een reden om op Qwen 4 te wachten. Er is geen datum. Er is geen prijs. Er is geen gewichten-aantal voor het echte ding — de cijfers hierboven beschrijven de preview-build, niet het product. Wat bestaat, is een serving stack die in het openbaar wordt voorbereid voor een architectuur die voorlopig alleen in previewvorm te downloaden is.

De korte versie

Drie regels die een kloof dichten tussen de tekst-only- en vision-language-paden van één modelbestand is op zichzelf geen nieuws. Het is het soort patch dat in een merge commit begraven zou worden als iemand tijd had om het te reviewen, en het kan heel goed worden opgenomen in een grotere wijziging of ronduit worden gesloten — de eigen agent-richtlijnen van de vLLM-bot, geciteerd op de PR, instrueren door AI ondersteunde bijdragers om hun werk te sluiten als het geen significant voordeel biedt, en 1,5% is een getal dat die vraag oproept. Wat het uw aandacht waard maakt, is het ding dat het documenteert: een n-gramtabel met 20 miljoen entries, een MoE met 512 experts waarvan er tien per token actief zijn, een hybride van lineaire attention en gecomprimeerde sparse attention, een speculatieve head — en dat alles wordt afgestemd op NVIDIA en AMD, van Ampere tot Hopper, voordat het product dat het draagt bestaat. Als de Qwen4-serving-envelope voor jou belangrijk is, bevinden de echte specificaties zich momenteel in de PR-beschrijvingen. Als je vandaag een model wilt aanroepen, is Qwen3.8-Flash het model dat er daadwerkelijk is.

Eén API voor 200+ modellen, automatische failover, routing-DSL. Verken de OrcaRouter-modelcatalogus