Qwen4-Exp QSA komt naar Huawei's Ascend: binnen SGLang's opt-in CANN prefill-PR

Op 30 september 2026 opende een bijdrager SGLang pull request #41855, met de titel "[NPU] Voeg opt-in CANN sparse attention toe voor Qwen4-Exp QSA prefill", en het interessante deel is niet het rekenwerk. Het is de hardware. De Qwen4Exp-architectuur heeft nu een handgeschreven sparse-attentionpad voor Huawei’s Ascend 910C-accelerator, achter een flag die standaard uit staat, in een concept-pullrequest die nog niet is samengevoegd — terwijl het model waartoe die architectuurnaam behoort, Qwen4-Exp, nog nooit in welke vorm dan ook is gepubliceerd. Het enige checkpoint dat deze architectuur in open gewichten bevat, is nog steeds Qwen3.8-Flash-Next, de 125 miljard parameters tellende mixture-of-experts-preview die de leverancier op 24 augustus 2026 op Hugging Face heeft uitgebracht, en waarvan de kaart de architectuur daadwerkelijk aangeeft als qwen4_exp. Qwen 4 zelf — de Max-, Flash-, Plus- en 27B-varianten die de leverancier op 22 september 2026 tijdens zijn Apsara-conferentie noemde — heeft nog steeds geen gewichten, geen identifier, geen prijs en geen datum. Dit is dus een stuk over wat we tot nu toe weten over een engineeringartefact, geen lancering: nog een leverancier wiens servingstack stilletjes besluit dat een niet-uitgebrachte architectuur het waard is om vroeg te ondersteunen.

Wat de pull request daadwerkelijk toevoegt

De wijziging is bewust klein en bewust beperkt. Vijf bestanden, één commit, +355 regels tegen een main-branch op commit b87a241, met het SGLang npu label. De auteur, w1ida, verwoordt de intentie vooraf: een opt-in CANN main-attention-pad voor Qwen4-Exp QSA eager prefill, gebouwd op torch_npu.npu_sparse_flash_attention, waarbij de indexer, de Top-K-selectie, het tokenbudget en de inhoud van de KV-cache allemaal exact hetzelfde zijn gelaten als ze waren.

De truc die het gebruikt om daar te komen is een alinea waard, omdat die verklaart waarom dit een layout-adapter is en niet een nieuwe attention-kernel. Voor al geroteerde Q en K verpakt het pad de cache als C = [K, V] en de query als Q' = [Q, 0]. Het product Q' @ C.T is dan gelijk aan Q @ K.T, en omdat de opgevulde query niets bijdraagt, softmax(scale * Q' @ C.T) @ C geeft [P @ K, P @ V] gestapeld — dus het V-gedeelte kan eruit worden gesneden. In de woorden van de auteur zelf is dit “een attention-layout-embedding, geen verandering aan de attention van het model of een low-rank KV-compressie.” Elke KV-head wordt een onafhankelijke batch in de native MLA-layout, de oorspronkelijke D256-schaal blijft behouden, en hulp-RoPE wordt op nul gezet.

De operationele details zijn net zo belangrijk als de wiskunde:

• Inschakeling — SGLANG_NPU_QSA_NATIVE_PREFILL=1, standaard uit. Alleen de gewone ForwardMode.EXTEND doet mee; decode, speculatieve modi, gemengde forward en graph capture blijven allemaal op de bestaande paden, en graph capture omzeilt de adapter volledig.

• Hardware en dtype — BF16 met head-dimensie 256, Ascend 910C (Ascend910_93*), getest tegen CANN 9.0 en torch-npu 2.10. Elke niet-ondersteunde dtype of shape valt stil terug naar het referentiepad.

• Head-vormen — ondersteunde lokale (Q-heads, KV-heads)-paren zijn (16,2), (24,2), (12,1), (6,1) en (3,1). CANN verwerpt een query/KV-ratio van 12 ronduit — de tiler accepteert alleen machten van twee — dus worden heads opgevuld 12→16, 6→8 of 3→4 en worden de toegevoegde outputs weggegooid. Dit is het duidelijkste teken in de hele PR dat de hardware niet ontworpen is met sparse-attention-head-ratio's in gedachten, en de adapter absorbeert die mismatch in plaats van dat het model daarvoor van vorm verandert.

• Groottegrenzen — alleen de gerefereerde fysieke cacheomvang wordt verpakt, met een bovengrens van 262.144 tokens, wat de auteur berekent als maximaal 512 MiB voor de verpakte BF16 K/V-tensor bij twee KV-heads. Interne -1 padding wordt gedetecteerd en naar de fallback geleid, omdat CANN aaneengesloten geldige slots vereist; volledig gemaskeerde rijen behouden de bestaande zero-output-conventie.

• Waarom alleen prefill — de extent- en lay-outcontrole kopieert twee scalars naar de host, en de tijdelijke kopieën plus de native workspace kosten geheugen. Die synchronisatie is de reden dat het pad beperkt blijft tot eager prefill en tijdens capture wordt uitgeschakeld.

Negen tests die geslaagd zijn, en een snelheidsgetal dat niet van deze branch afkomstig is

Het correctheidsbewijs is specifiek en reproduceerbaar, wat meer is dan de meeste kernel-PR's bieden. De auteur meldt 9 tests die slagen in 40,772 seconden op een Ascend 910C (Ascend910_9362) met CANN 9.0 en torch-npu 2.10.0, zonder checkpoint: niet-nul random BF16 Q/K/V tegen een FP32 CPU-referentie berekend uit dezelfde BF16-invoer, ongeordende fysieke slots op breedtes 1/63/64/65/2051, standaard en expliciete scales, volledig gemaskeerde rijen, nulrijen, selectiebreedte nul, niet-contiguë tensors, causal tail-remainders van 0 tot en met 3 bij compressieratio 4, fysieke mapping van twee requests met een gedeelde prefix, hergebruik van cache-inhoud, en de Flash-Next lokale head-vormen bij 1 en 257 queryrijen.

Het voornaamste geval is een lange prefill: 7.810 querytokens tegen een cache van 65.536 tokens met 2.051 geselecteerde slots per query, alle outputs eindig, met acht gesamplede rijen vergeleken met de FP32-referentie. De waargenomen relatieve L2-fout bereikte 0,209% bij de kleine head-shape-gevallen en 0,231% op de gesamplede lange-prefill-rijen, tegen testdrempels van atol=0.025, rtol=0.025 en relatieve L2 onder 0,008, waarbij lege rijen exact nul moeten zijn. De piek van het toegewezen NPU-geheugen voor die run wordt opgegeven als 1.042,7 MiB — en de auteur bestempelt het als de PyTorch-allocator-metriek, niet board-HBM en niet het geheugen van het volledige model, wat precies de juiste kanttekening is om erbij te plaatsen.

Dan is er nog het getal dat geciteerd zal worden en dat niet zou moeten. De PR-body bevat een snelheidstabel die het bestaande lokale attention-pad toont met 2.270,79 nieuwe tokens per seconde en de native packed main attention met 3.890,06 — een winst van 1,713× / +71,3%, waarbij de gemiddelde tijd tot het eerste token daalt van 3,109 s naar 1,812 s. De auteur zegt expliciet dat dit historische prototypemetingen zijn van 2026-09-29 op een aangepast Whittle-Next-26B-A3B checkpoint, uitgevoerd op TP1 met W8A8-gewichten en BF16-attention op 910C onder CANN 9.0, met behulp van de officiële sglang.bench_serving harness bij concurrency 1 met zes verzoeken, elk één outputtoken, en 36.096 gecachte prefixtokens uitgesloten van de doorvoer van nieuwe tokens. Het gaat hierbij niet om een benchmark van de upstream-branch in de PR, de originele serving-JSON-artefacten zijn niet aanwezig in de checkout, en latere lokale resultaten rond 5.000 tokens per seconde gebruikten aanvullend native indexer- en block4-werk dat expliciet niet aan deze wijziging wordt toegeschreven. De auteur merkt ook op dat de indexer-gewichten van het aangepaste checkpoint inert zijn en dat het budget ervan afwijkt van het origineel, dus niets ervan is bewijs voor indexer-correctheid of generatiekwaliteit bij volledig budget.

Eén verduidelijking over de naamgeving, want die zal iedereen die naar het checkpoint zoekt, in de war brengen: het benchmarkmodel is het eigen aangepaste artefact van de bijdrager. Los daarvan is “Whittle-Next” ook de naam van een publieke reeks van Qwen3.8-afgeleide MoE-finetunes die is gepubliceerd door een Hugging Face-account van een derde partij, waaronder een 26B-A3B-variant die in september is geüpload. Dat zijn niet het Qwen4Exp-model waarop deze PR zich richt, en ze moeten niet worden opgevat als de benchmarkconfiguratie achter die 1,713×-waarde.

Twee verdere kanttekeningen komen van de auteur en niet van mij. Volledige serving-integratie, gedistribueerd tensorparallellisme en het volledige Qwen3.8-Flash-Next-model zijn niet gevalideerd op deze branch; de bijdrager zegt dat het opzettelijk is om het een draft te houden terwijl de integratie- en afhankelijkheidskwestie wordt besproken, en vraagt zelfs in de PR-body of de adapter thuishoort in SGLang of in de afzonderlijke sgl-kernel-npu-repository. CI is ook niet schoon — het statusblok in de PR-body toont fouten bij PR Test (Base), PR Test (Extra) en de AMD ROCm 10-run. De hierboven beschreven correctheid is op operatorniveau; niets in de PR claimt een end-to-end nauwkeurigheids- of doorvoerresultaat op de geïntegreerde stack.

Waarom QSA het lastige onderdeel is, in cijfers

Qwen Sparse Attention is geen conventionele attentionlaag, en de gepubliceerde configuratie laat zien waarom een acceleratorleverancier hiervoor een op maat gemaakt pad moet schrijven. Uit de configuratie van Qwen3.8-Flash-Next: 48 lagen, opgebouwd als twaalf herhalingen van drie Gated DeltaNet-blokken gevolgd door één full-attentionblok, full_attention_interval 4, verborgen grootte 2.560, dimensie van de attention-head 256, 24 query-heads tegenover 2 KV-heads, RoPE-dimensie 64. De indexer die de attention sparse maakt, is een multi-querystructuur met 4 query-heads die 1 key-head delen, head-dimensie 128, een compressieverhouding van 4 en een budget van 2.048 geselecteerde microblokken per query.

Dat budget is wat de PR vast houdt. De sparse blokgrootte blijft 1, de sparse modus blijft 0, de attention modus blijft 2, en de selected-token interface blijft onaangeroerd; native indexer- en block4-optimalisaties vallen expliciet buiten scope. Dus dit is een adapter die onder een bestaand selectiemechanisme is geschroefd, geen herimplementatie van QSA — wat ook de reden is waarom de auteur geloofwaardig kan beweren dat de inhoud van de KV-cache ongewijzigd is.

De modelkaart zet de ontwerpintentie duidelijk uiteen: in plaats van individuele tokens te selecteren, werkt QSA op microblokniveau om de latentie bij lange contexten te verlagen, en die microblokgranulariteit, plus de gerepliceerde selectortoestand die daarbij hoort, is precies wat zich op het silicium van geen van beide leveranciers netjes laat mappen op een generieke paged-attention-kernel.

Waar dit past in de uitbouw van de Qwen4Exp-serving

Op zichzelf gezien is één concept-PR op één accelerator een curiositeit. Afgezet tegen de rest van september is het de vierde of vijfde plank van een platform dat in het openbaar wordt samengesteld voordat de familie die het dient bestaat:

• De architectuur in open weights — Qwen3.8-Flash-Next, 2026-08-24, een MoE met 125B parameters waarvan 6B geactiveerd, een n-gram-embeddingtabel van 51 miljard parameters en een MTP-head van 4B, met model_type: qwen4_exp en architecturen Qwen4ExpForConditionalGeneration.

• De vLLM-kant — #53909, de “qwen4 fuse op”-PR die HyperConnection-, QSA- en PLE-kernels toevoegt, is sinds 2026-08-26 nog steeds open en niet samengevoegd; #59279, die decode-contextparallelisme aan hetzelfde QSA-pad toevoegt, een concept dat op 2026-09-29 is geopend; en het PLE-offloadwerk dat in de loop van september is samengevoegd.

• De SGLang-kant — #38642 voor het vastleggen van DFlash hidden states, #39548 voor Qwen4-Exp PLE CPU-offload op Ascend, #40235 voor het toevoegen van host-staging voor de bestandsgebaseerde PLE-tabel, en nu #41855 voor het Ascend-attentiepad.

• De NPU-enablementlijn — sglang #37570, waarmee Qwen3.8-Flash-Next aan SGLang op NPU wordt toegevoegd met graph replay, MTP en Triton-kernels (geopend op 2026-09-02, nog open, +2.590 regels verdeeld over 20 bestanden), en sgl-kernel-npu #807 voor de bijbehorende Triton-kernels (geopend op 2026-09-17, +4.643 regels). Beide zijn afkomstig van dezelfde bijdrager. #41855 is de attention-laag die binnen die grotere enablementinspanning valt.

Twee observaties waar een lezer iets mee kan. Ten eerste berust het hele Ascend Qwen4Exp-verhaal op een heel klein aantal bijdragers: de enablement-PR's en de kernel-repository hebben dezelfde auteur, en de attention-adapter heeft een andere. Die concentratie is een redelijke inschatting van hoe ver Ascend Qwen4Exp-serving verwijderd is van een ondersteund productpad in plaats van een experiment. Ten tweede is de kernelbottleneck niet leveranciersspecifiek: twee SGLang-issues die op 2026-08-28 zijn ingediend, documenteren Qwen4Exp-decode op een NVIDIA DGX Spark waarbij QSA-, PLE- en Gated DeltaNet-kerneltijd domineert, en waarbij een NVFP4-KV-cache een regressie van ruwweg 29% in decode opleverde ten opzichte van fp8_e4m3. De attention- en embeddinglagen van deze architectuur zijn overal het moeilijkste onderdeel.

Wat dit niet betekent

Het betekent niet dat Qwen 4 uit is, of bijna uit is. De Qwen 4-familie die Alibaba op 2026-09-22 noemde — Max, Flash, Plus en een 27B-tier — blijft een roadmap zonder modelkaart, zonder weights, zonder API-identifier, zonder contextvenster, zonder licentie en zonder prijs. Een framework-adapter die zich richt op de interne architectuurnaam is een stap naar het op een dag goed bedienen van die familie; het is geen stap naar het bestaan van die familie.

Het betekent niet dat je dit vandaag kunt draaien. De PR is een concept met een falende CI en geen mergedatum. Zelfs als hij gemerged is, heeft het pad een Ascend 910C, BF16, CANN 9.0 met torch-npu 2.10 nodig, plus een van vijf specifieke lokale head-vormen, en het is opt-in — wat betekent dat een deployment ervoor moet kiezen. De auteur weigerde ook aanspraak te maken op validatie op serverniveau, wat juist het onderdeel is dat je daadwerkelijk zou vertellen of het standhoudt onder echte batching.

En het betekent niet dat Qwen3.8-Flash-Next een ondersteund product is op Ascend, of ergens anders in een uitgeleverde engine-build. De Qwen4Exp-paden in beide grote open runtimes zijn niet-gemergde pull requests. Er is geen uitgebrachte versie van SGLang of vLLM die je kunt installeren en die deze architectuur native ondersteunt — het FastAPI-achtige gemak van een gehoste endpoint is iets anders dan een kernel die je zelf kunt draaien, en de kloof daartussen is precies waar PR's zoals deze voor bedoeld zijn.

Wat je daadwerkelijk kunt bellen terwijl je wacht

Als de reden dat je om Qwen4Exp geeft is dat je het long-contextgedrag van de architectuur wilt testen in plaats van de kernelinternals, dan is het model waarnaar je moet grijpen de tier die Alibaba daadwerkelijk aanbiedt. Qwen3.8-Flash — de productielijn gebouwd op Qwen3.8-Flash-Next, met officiële ingebouwde tools en een context van 1.000.000 tokens — is live op OrcaRouter als qwen/qwen3.8-flash: tekst-, beeld- en video-invoer, maximale uitvoer van 131.072 tokens, $0,15 per miljoen invoertokens en $0,47 per miljoen uitvoertokens, met cache-reads tegen $0,0184. Dat zijn de lijstprijzen van de provider die aan onze kant met 0% markup worden doorgegeven, dus een prijs- of limietwijziging van de leverancier bereikt je op dezelfde dag dat die wordt aangekondigd. Over het afgelopen venster van zeven dagen toont de live-kaart een p50-latentie voor het eerste token van 4.416 ms, ongeveer 106 uitvoertokens per seconde en een foutpercentage van 2,68% — het profiel van een tekst-tier voor hoog volume in plaats van een labpreview.

Twee eerlijke voorbehouden, en het zijn dezelfde twee die de zusterdocumenten over deze architectuur ook maken. Qwen3.8-Flash-Next zelf — het FP8-preview-checkpoint, het ding dat je nodig zou hebben om een van deze kernelmetingen lokaal te reproduceren — staat niet in onze catalogus; de geleverde Flash-tier is de productie-implementatie die erop is gebouwd, niet het ruwe preview-artefact. En niets van het hierboven beschreven Ascend- of DCP-werk bestaat in iets dat je kunt aanroepen, omdat niets ervan is gemerged. Wat de geleverde tier je wel geeft, is een goedkope manier om erachter te komen of je workload de vorm heeft van het probleem dat deze kernels oplossen — lange, prefix-zware, agentische prompts tegen een zeer lange context. Als dat zo is, dan zijn de doorvoer en het cachegedrag dat je daar waarneemt hetzelfde gedrag dat de Qwen 4-servingstack zal worden afgestemd om te beschermen.

Er is ook een infrastructurele reden om niet te wachten op een familie zonder datum. Welke tier er ook wint in de Qwen 4-line-up, de overstapkosten zijn een routeringskwestie in plaats van een integratieproject, en één API voor meer dan 200 modellen is hoe je die optie openhoudt zonder een tweede contract of een codewijziging wanneer de weights arriveren. Failover is hier om dezelfde reden op een specifieke manier van belang: als je tegen een onbewezen tier wilt bouwen, wil je dat het verzoek overschakelt naar iets stabiels in plaats van te falen wanneer het pad waarop je hebt ingezet een slecht moment heeft.

Drie vragen die het waard zijn om direct te beantwoorden.

Betekent SGLang #41855 dat Qwen 4 uit is, of te previewen?

Nee, op beide punten. De pull request richt zich op de Qwen4Exp-architectuur zoals geïmplementeerd in Qwen3.8-Flash-Next, die Alibaba op 2026-08-24 heeft uitgebracht. Hij raakt de Qwen 4-gewichten niet, en geen enkele Qwen 4-tier heeft gewichten om aan te raken. Het signaal dat hier gelezen moet worden gaat over serveercapaciteit voor een preview-architectuur, niet over de beschikbaarheid van de familie.

Als er op een modelkaart qwen4_exp staat, is dat dan Qwen 4?

Nee — en dit is de valkuil rond de naamgeving in het hele verhaal. qwen4_exp is de interne architectuuridentificatie, en dit is wat je zult vinden in config.json voor Qwen3.8-Flash-Next en zijn FP8-tegenhanger. “Experimentele architectuur” is het sleutelwoord: de gewichten zijn gepubliceerd, de architectuur is echt, en het model is een voorproefje van waarop de Qwen 4-familie naar verwachting zal worden gebouwd. Het zoeken naar de identificatie en het vinden van een SGLang- of vLLM-PR met Qwen4Exp in de titel zegt je iets over enginewerk, niet over een release.

Is dit een verhaal van Ascend versus NVIDIA?

Niet echt. Hetzelfde attention-pad had aan de NVIDIA-kant ook een op maat gemaakte adapter nodig — decode-context-parallelisme voor QSA in vLLM, en een native sparse prefill-kernel voor Hopper — en de problemen met DGX Spark tonen aan dat ook daar de QSA-, PLE- en Gated DeltaNet-kerneltijd het decoderen domineren. QSA's micro-block-indexer en de bijbehorende gerepliceerde selectorstatus zijn simpelweg niet wat generieke paged-attention-kernels veronderstellen. Ascends bijdrage aan het patroon is de scherpere beperking: een head-ratio-tiler die alleen machten van twee accepteert, wat de padding forceert die de adapter moet verbergen.

Het ding om in de gaten te houden

Niet of dit wordt gemerged. De adapter is eerlijk over het feit dat hij een adapter is, de correctheidstests zijn reproduceerbaar zonder checkpoint, en de auteur heeft de integratiekwestie aangekaart in plaats van te doen alsof die al beslecht is. Waar je op moet letten, is wat er gebeurt nadat de NPU-enablementlijn en dit attention-pad zijn gecombineerd — of de geïntegreerde branch de end-to-end run krijgt die geen van beide heeft gehad, op echte batching met het volledige model in plaats van lokale head-shape-tensoren. Het cijfer van 1,713× is het cijfer dat de ronde zal doen, en het is het cijfer dat is berekend op een andere build, op een aangepast checkpoint, met een inerte indexer. Een gemeten getal op de voltooide stack zou aanzienlijk meer waard zijn dan een historisch getal.

Tot dan is de eerlijke samenvatting de samenvatting die de PR zelf aanhoudt: de berekening klopt, de flag staat standaard uit, de CI is rood, en het model in de titel bestaat nog steeds niet.