Qwen4-Exp QSA kommer till Huaweis Ascend: en titt in i SGLangs opt-in-PR för CANN-prefill

Den 2026-09-30 öppnade en bidragsgivare SGLang-pull request #41855, med titeln ”[NPU] Lägg till opt-in CANN sparse attention för Qwen4-Exp QSA prefill”, och det intressanta är inte aritmetiken. Det är hårdvaran. Arkitekturen Qwen4Exp har nu en handskriven sparse-attention-väg för Huaweis Ascend 910C-accelerator, bakom en flagga som är avstängd som standard, i en draft-pull request som inte har mergats — medan modellen som arkitekturnamnet tillhör, Qwen4-Exp, aldrig har publicerats i någon form. Den enda checkpoint som bär denna arkitektur i öppna vikter är fortfarande Qwen3.8-Flash-Next, den 125 miljarder parametrar stora mixture-of-experts-förhandsversionen som leverantören släppte på Hugging Face den 2026-08-24, och vars modellkort faktiskt deklarerar dess arkitektur som qwen4_exp. Qwen 4 självt — nivåerna Max, Flash, Plus och 27B som leverantören namngav vid sin Apsara-konferens den 2026-09-22 — har fortfarande inga vikter, ingen identifierare, inget pris och inget datum. Så det här är en genomgång av vad vi vet så här långt om en ingenjörsartefakt, inte en lansering: ännu en leverantörs serving-stack som i tysthet beslutar att en osläppt arkitektur är värd att stödja tidigt.

Vad pull requesten faktiskt tillför

Ändringen är medvetet liten och medvetet snäv. Fem filer, en commit, +355 rader mot en huvudgren vid commit b87a241, som bär SGLang npu-etiketten. Författaren, w1ida, anger avsikten direkt: en opt-in CANN-väg för main-attention för Qwen4-Exp QSA eager prefill, byggd på torch_npu.npu_sparse_flash_attention, med indexeraren, Top-K-valet, tokenbudgeten och KV-cachens innehåll lämnade exakt som de var.

Tricket den använder för att komma dit är värt ett stycke, eftersom det förklarar varför detta är en layoutadapter snarare än en ny attention-kärna. För redan roterade Q och K packar vägen cachen som C = [K, V] och queryn som Q' = [Q, 0]. Produkten Q' @ C.T är då lika med Q @ K.T, och eftersom den paddade queryn inte bidrar med något, softmax(scale * Q' @ C.T) @ C returnerar [P @ K, P @ V] staplade — så V-halvan kan skäras ut. Med författarens egna ord är detta ”en attention-layoutinbäddning, inte en förändring av modellens attention eller en lågrankad KV-komprimering.” Varje KV-huvud blir en oberoende batch i den nativa MLA-layouten, den ursprungliga D256-skalan bevaras, och auxiliär RoPE nollställs.

De operativa detaljerna är lika viktiga som matematiken:

• Aktivering — SGLANG_NPU_QSA_NATIVE_PREFILL=1, som standard av. Endast ordinarie ForwardMode.EXTEND väljer att använda den; avkodning, spekulativa lägen, blandad framåtpassning och graffångst stannar alla kvar på de befintliga körvägarna, och graffångst kringgår adaptern helt.

• Hårdvara och dtype — BF16 med huvuddimension 256, Ascend 910C (Ascend910_93*), testad mot CANN 9.0 och torch-npu 2.10. Varje dtype eller form som inte stöds faller tyst tillbaka till referensvägen.

• Huvudformer – lokalt stödda (Q-huvuden, KV-huvuden)-par är (16,2), (24,2), (12,1), (6,1) och (3,1). CANN avvisar en query/KV-kvot på 12 direkt – dess tiler accepterar bara tvåpotenser – så huvuden paddas 12→16, 6→8 eller 3→4 och de tillagda utdata kastas. Detta är det tydligaste tecknet i hela PR:en på att hårdvaran inte designades med sparse-attention-huvudkvoter i åtanke, och adaptern absorberar den missanpassningen i stället för att modellen ändrar form för den.

• Storleksgränser — endast den refererade fysiska cache-utsträckningen packas, begränsad till 262 144 token, vilket författaren beräknar till högst 512 MiB för den packade BF16 K/V-tensorn vid två KV-huvuden. Inre -1 utfyllnad upptäcks och dirigeras till reservlösningen, eftersom CANN kräver sammanhängande giltiga platser; helt maskerade rader behåller den befintliga nollutdatakonventionen.

• Varför endast prefill — kontrollen av extent och layout kopierar två skalärer till värden, och de tillfälliga kopiorna plus native-arbetsytan kostar minne. Den synkroniseringen är anledningen till att sökvägen är begränsad till eager prefill och hålls avstängd under capture.

Nio tester som passerade, och en hastighetssiffra som inte kom från den här grenen

Bevisen för korrekthet är specifika och reproducerbara, vilket är mer än vad de flesta kernel-PR:er erbjuder. Författaren rapporterar 9 tester som passerar på 40,772 sekunder på en Ascend 910C (Ascend910_9362) med CANN 9.0 och torch-npu 2.10.0, utan att någon checkpoint behövs: nollskilda slumpmässiga BF16 Q/K/V mot en FP32 CPU-referens beräknad från samma BF16-indata, oordnade fysiska platser vid bredderna 1/63/64/65/2051, standard- och explicita skalor, fullständigt maskerade rader, nollrader, noll selektionsbredd, icke-kontinuerliga tensorer, causala svansrester med kompressionsförhållande 4 från 0 till och med 3, fysisk mappning för två förfrågningar med ett delat prefix, återanvändning av cacheinnehåll och Flash-Nexts lokala head-former vid 1 och 257 query-rader.

Huvudfallet är en lång prefill: 7 810 query-token mot en cache på 65 536 token med 2 051 valda slots per query, alla utdata ändliga, med åtta samplade rader jämförda mot FP32-referensen. Observerat relativt L2-fel uppgick till 0,209 % för de små fallen med head-form och 0,231 % för de samplade långa prefill-raderna, mot testgränser på atol=0.025, rtol=0.025 och relativ L2 under 0,008, där tomma rader måste vara exakt noll. Maximalt allokerat NPU-minne för den körningen anges till 1 042,7 MiB – och författaren betecknar det som PyTorch-allokatorns mätvärde, inte HBM på kortet och inte fullmodellsminne, vilket är precis rätt förbehåll att lägga till.

Sedan har vi siffran som kommer att citeras och inte borde det. PR-beskrivningen innehåller en hastighetstabell som visar den befintliga lokala attention-vägen vid 2 270,79 nya tokens per sekund och den nativa packade main attention vid 3 890,06 – en förbättring på 1,713× / +71,3 %, med genomsnittlig tid till första token som sjunker från 3,109 s till 1,812 s. Författaren är tydlig med att dessa är historiska prototypmätningar tagna 2026-09-29 på en anpassad Whittle-Next-26B-A3B checkpoint, körd vid TP1 med W8A8-vikter och BF16-attention på 910C under CANN 9.0, med hjälp av den officiella sglang.bench_serving harnessen vid samtidighet 1 med sex förfrågningar, en output-token var, och 36 096 cachade prefixtoken exkluderade från genomströmningen för nya token. De är inte ett benchmark av uppströmsgrenen i PR:en, de ursprungliga serving-JSON-artefakterna finns inte i utcheckningen, och senare lokala resultat runt 5 000 tokens per sekund använde ytterligare nativt indexer- och block4-arbete som uttryckligen inte tillskrivs denna ändring. Författaren noterar också att den anpassade checkpointens indexer-vikter är inerta och att dess budget skiljer sig från den ursprungliga, så inget av det utgör bevis för indexer-korrekthet eller genereringskvalitet med full budget.

Ett förtydligande om namngivningen, eftersom det kommer att förvirra alla som söker efter checkpointen: benchmarkmodellen är bidragsgivarens egen anpassade artefakt. Separat är ”Whittle-Next” också namnet på en offentlig serie av Qwen3.8-härledda MoE-finjusteringar som publicerats av ett tredjepartskonto på Hugging Face, inklusive en 26B-A3B-variant som laddades upp i september. De är inte den Qwen4Exp-modell som denna PR riktar sig mot, och de bör inte tolkas som benchmarkkonfigurationen bakom den där 1,713×-siffran.

Ytterligare två varningar kommer från författaren snarare än från mig. Fullständig serving-integration, distribuerad tensorparallelism och den kompletta modellen Qwen3.8-Flash-Next har inte validerats på den här grenen; bidragsgivaren säger att det är avsiktligt att behålla den som utkast medan integrations- och beroendefrågan diskuteras, och frågar till och med i PR-beskrivningen om adaptern hör hemma i SGLang eller i det separata sgl-kernel-npu-arkivet. CI är inte heller felfri — statusblocket i PR-beskrivningen visar misslyckanden i PR Test (Base), PR Test (Extra) och AMD ROCm 10-körningen. Korrektheten som beskrivs ovan är på operatornivå; inget i PR:en hävdar ett resultat för noggrannhet eller genomströmning från början till slut på den integrerade stacken.

Varför QSA är den knepiga delen, i siffror

Qwen Sparse Attention är inte ett konventionellt attention-lager, och den publicerade konfigurationen visar varför en acceleratorleverantör måste skriva en skräddarsydd väg för det. Från konfigurationen för Qwen3.8-Flash-Next: 48 lager ordnade som tolv upprepningar av tre Gated DeltaNet-block följda av ett full-attention-block, full_attention_interval 4, dold storlek 2 560, attention-huvuddimension 256, 24 query-huvuden mot 2 KV-huvuden, RoPE-dimension 64. Indexeraren som gör attention gles är en multi-query-struktur med 4 query-huvuden som delar 1 key-huvud, huvuddimension 128, ett komprimeringsförhållande på 4 och en budget på 2 048 valda mikroblock per query.

Det är den budget som PR:n håller oförändrad. Sparse-blockstorleken förblir 1, sparse-läget förblir 0, attention-läget förblir 2, och selected-token-gränssnittet är orört; native indexer och block4-optimeringar ligger uttryckligen utanför omfattningen. Så det här är en adapter som skruvas fast under en befintlig urvalsmekanism, inte en nyimplementering av QSA — vilket också är varför författaren trovärdigt kan hävda att innehållet i KV-cachen är oförändrat.

Modellkortet formulerar designavsikten tydligt: i stället för att välja enskilda tokens arbetar QSA på mikroblocksnivå för att minska latensen vid lång kontext, och just den mikroblocksgranulariteten, tillsammans med det replikerade selectortillstånd som hör samman med den, är precis det som inte mappar rent mot en generisk paged-attention-kärna på någon av leverantörernas kisel.

Var detta passar in i Qwen4Exp:s serving-utbyggnad

Sett för sig är en draft-PR på en accelerator en kuriositet. Sett mot resten av september är den den fjärde eller femte plankan i en plattform som sätts samman offentligt innan familjen som den betjänar existerar:

• Arkitekturen i öppna vikter — Qwen3.8-Flash-Next, 2026-08-24, en MoE med 125B parametrar varav 6B aktiverade, en n-gram-inbäddningstabell med 51 miljarder parametrar och ett MTP-huvud på 4B, med model_type: qwen4_exp och arkitekturer Qwen4ExpForConditionalGeneration.

• vLLM-sidan — #53909, PR:en ”qwen4 fuse op” som lägger till HyperConnection-, QSA- och PLE-kärnor, fortfarande öppen och inte sammanslagen sedan 2026-08-26; #59279, som lägger till decode-kontextparallellism i samma QSA-väg, ett utkast öppnat 2026-09-29; och PLE-offload-arbetet som landade under september.

• SGLang-sidan — #38642 för DFlash-infångning av dolda tillstånd, #39548 för PLE-CPU-offload för Qwen4-Exp på Ascend, #40235 som lägger till host-staging för den filbaserade PLE-tabellen, och nu #41855 för Ascend-attentionsvägen.

• NPU-aktiveringsspåret – sglang #37570, som lägger till Qwen3.8-Flash-Next i SGLang på NPU med grafåteruppspelning, MTP och Triton-kärnor (öppnad 2026-09-02, fortfarande öppen, +2 590 rader fördelade på 20 filer), och sgl-kernel-npu #807 för de tillhörande Triton-kärnorna (öppnad 2026-09-17, +4 643 rader). Båda kommer från samma bidragsgivare. #41855 är attention-lagret som ingår i den större aktiveringssatsningen.

Två iakttagelser som en läsare kan agera utifrån. För det första vilar hela historien om Ascend Qwen4Exp på ett mycket litet antal bidragsgivare – aktiverings-PR:erna och kernel-repot har samma författare, och attention-adaptern har en annan författare. Den koncentrationen är en rimlig uppskattning av hur långt Ascend Qwen4Exp-serving är från att vara en produktväg som stöds snarare än ett experiment. För det andra är kernel-flaskhalsen inte leverantörsspecifik: två SGLang-issues som lämnades in 2026-08-28 dokumenterar Qwen4Exp-avkodning på en NVIDIA DGX Spark där kerneltiden för QSA, PLE och Gated DeltaNet dominerar, och där en NVFP4-KV-cache uppmättes försämra avkodningen med ungefär 29 % jämfört med fp8_e4m3. Attention- och embedding-lagren i den här arkitekturen är den svåra delen överallt.

Vad detta inte innebär

Det betyder inte att Qwen 4 är ute, eller nära. Qwen 4-familjen som Alibaba namngav den 22 september 2026 – Max, Flash, Plus och en 27B-nivå – förblir en färdplan utan modellkort, utan vikter, utan API-identifierare, utan kontextfönster, utan licens och utan pris. En ramverksadapter som riktar sig mot det interna arkitekturnamnet är ett steg mot att en dag kunna serva den familjen väl; det är inte ett steg mot att familjen existerar.

Det betyder inte att du kan köra detta idag. PR:en är ett utkast med misslyckad CI och inget merge-datum. Även om den mergas kräver vägen en Ascend 910C, BF16, CANN 9.0 med torch-npu 2.10 och en av fem specifika lokala head-former, och den är opt-in – vilket innebär att en driftsättning måste välja den. Författaren avstod också från att hävda validering på servernivå, vilket är den del som faktiskt skulle visa om den håller under verklig batchning.

Och det betyder inte att Qwen3.8-Flash-Next är en produkt som stöds på Ascend, eller någon annanstans i en levererad engine-build. Qwen4Exp-vägarna i båda de stora öppna runtime-miljöerna är omergeade pull requests. Det finns ingen släppt version av SGLang eller vLLM som du kan installera som kör den här arkitekturen nativt – den FastAPI-liknande bekvämligheten med en hostad endpoint är en annan sak än en kernel som du kan köra själv, och gapet mellan dem är precis vad PR:er som den här är till för.

Vad du faktiskt kan ringa medan du väntar

Om anledningen till att du bryr dig om Qwen4Exp är att du vill testa arkitekturens långkontextbeteende snarare än dess kernel-interna, är modellen du ska använda den nivå som Alibaba faktiskt levererar. Qwen3.8-Flash — produktionslinjen byggd på Qwen3.8-Flash-Next, med officiella inbyggda verktyg och ett kontextfönster på 1 000 000 token — är live på OrcaRouter som qwen/qwen3.8-flash: text-, bild- och videoindata, maximalt 131 072 token i utdata, 0,15 USD per miljon indata-token och 0,47 USD per miljon utdata-token, med cacheläsningar på 0,0184 USD. Det är leverantörens listpriser som förs vidare med 0 % påslag från vår sida, så en ändring av leverantörens pris eller gräns når dig samma dag som den tillkännages. Under den senaste sjudagarsperioden visar live-kortet en p50-latens för första token på 4 416 ms, omkring 106 utdata-token per sekund och en felfrekvens på 2,68 % — profilen för en högvolymsnivå för text snarare än en labbförhandsvisning.

Två ärliga förbehåll, och de är samma två som de systerliga texterna om den här arkitekturen innehåller. Qwen3.8-Flash-Next i sig – FP8-förhandsvisningscheckpointen, den du skulle behöva för att kunna reproducera någon av dessa kernelmätningar lokalt – finns inte i vår katalog; den Flash-nivå som betjänas är den produktionsdriftsättning som byggts från den, inte den råa förhandsvisningsartefakten. Och inget av det Ascend- eller DCP-arbete som beskrivs ovan finns i något du kan anropa, eftersom inget av det har mergats. Vad den betjänade nivån däremot ger dig är ett billigt sätt att ta reda på om din arbetsbelastning är formad för problemet som dessa kernelar löser – långa, prefix-tunga, agentiska prompter mot en mycket lång kontext. Om den är det är den genomströmning och det cachebeteende du observerar där samma beteende som Qwen 4:s serving-stack kommer att trimmas för att skydda.

Det finns också ett infrastrukturargument för att inte vänta på en familj som saknar datum. Vilken nivå som än till slut vinner Qwen 4-lineupen, är byteskostnaden en routingfråga snarare än ett integrationsprojekt, och ett API för 200+ modeller är hur du håller det alternativet öppet utan ett andra avtal eller en kodändring när vikterna landar. Failover spelar roll av samma anledning här på ett specifikt sätt: om du vill bygga mot en oprövad nivå, vill du att begäran ska växla över till något stabilt i stället för att misslyckas när vägen du satsade på har en dålig minut.

Tre frågor värda att besvara direkt

Betyder SGLang #41855 att Qwen 4 har släppts, eller går att förhandsgranska?

Nej, på båda punkterna. Pull requesten riktar sig mot Qwen4Exp-arkitekturen så som den implementerats i Qwen3.8-Flash-Next, som Alibaba släppte den 24 augusti 2026. Den rör inte Qwen 4-vikter, och ingen Qwen 4-nivå har några vikter att röra. Signalen att läsa här handlar om serving-kapacitet för en förhandsvisningsarkitektur, inte om familjens tillgänglighet.

Om ett modellkort säger qwen4_exp, är det då Qwen 4?

Nej – och detta är namnfällan i hela historien. qwen4_exp är den interna arkitekturidentifieraren, och det är den du hittar i config.json för Qwen3.8-Flash-Next och dess FP8-syskon. ”Experimentell arkitektur” är det avgörande ordet: vikterna är publicerade, arkitekturen är verklig, och modellen är en förhandsvisning av vad Qwen 4-familjen förväntas byggas på. Att söka efter identifieraren och hitta en SGLang- eller vLLM-PR med Qwen4Exp i titeln säger dig att det handlar om motorarbete, inte om ett släpp.

Är det här en historia om Ascend mot NVIDIA?

Inte riktigt. Samma uppmärksamhetsväg behövde en skräddarsydd adapter även på NVIDIA-sidan — avkodningskontext-parallellism för QSA i vLLM, och en nativ gles prefyll-kärna för Hopper — och problemen med DGX Spark visar att QSA-, PLE- och Gated DeltaNet-kärntid dominerar avkodningen där också. QSA:s mikroblockindexerare och dess replikerade väljartillstånd är helt enkelt inte vad generiska paged-attention-kärnor förutsätter. Ascends bidrag till mönstret är den skarpare begränsningen: en head-ratio-tiler som bara accepterar tvåpotenser, vilket tvingar fram den utfyllnad som adaptern måste dölja.

Det man ska hålla ögonen på

Inte huruvida detta mergas. Adaptern är ärlig med att vara en adapter, korrekthetstesterna är reproducerbara utan en checkpoint, och författaren har flaggat integrationsfrågan i stället för att låtsas att den är avgjord. Det man bör hålla ögonen på är vad som händer efter att NPU-aktiveringsraden och denna attention-väg kombineras – huruvida den integrerade grenen får den end-to-end-körning som ingen av dem har haft, på riktig batchning med hela modellen i stället för lokala head-shape-tensorer. Siffran 1,713× är den som kommer att cirkulera, och det är den som beräknats på en annan build, på en anpassad checkpoint, med en inert indexerare. Ett uppmätt tal på den färdiga stacken skulle vara värt betydligt mer än ett historiskt sådant.

Fram till dess är den ärliga sammanfattningen den som PR:en själv håller sig till: aritmetiken stämmer, flaggan är avstängd som standard, CI:t är rött, och modellen i titeln existerar fortfarande inte.