Qwen4-Exp QSA arriva sull'Ascend di Huawei: dentro la PR opt-in di prefill CANN di SGLang

Il 30 settembre 2026, un contributore ha aperto la pull request #41855 di SGLang, intitolata “[NPU] Aggiungi attenzione sparsa CANN opt-in per il prefill QSA di Qwen4-Exp”, e la parte interessante non è l'aritmetica. È l'hardware. L'architettura Qwen4Exp ora ha un percorso di attenzione sparsa scritto a mano per l'acceleratore Ascend 910C di Huawei, dietro un flag disattivato per impostazione predefinita, in una pull request in bozza che non è stata unita — mentre il modello a cui appartiene quel nome di architettura, Qwen4-Exp, non è mai stato pubblicato in alcuna forma. L'unico checkpoint che porta questa architettura in pesi aperti è ancora Qwen3.8-Flash-Next, l'anteprima mixture-of-experts da 125 miliardi di parametri che il fornitore ha rilasciato su Hugging Face il 24 agosto 2026, e la cui scheda dichiara effettivamente la propria architettura come qwen4_exp. Qwen 4 stesso — le fasce Max, Flash, Plus e 27B che il fornitore ha indicato alla sua conferenza Apsara il 22 settembre 2026 — non ha ancora pesi, né identificatore, né prezzo, né data. Quindi questo è un articolo su ciò che sappiamo finora riguardo a un artefatto ingegneristico, non un lancio: l'ennesimo stack di serving di un fornitore che decide in silenzio che un'architettura non ancora rilasciata vale la pena di essere supportata in anticipo.

Cosa aggiunge effettivamente la pull request

Il cambiamento è volutamente piccolo e volutamente circoscritto. Cinque file, un commit, +355 righe rispetto a un ramo main al commit b87a241, con l'etichetta SGLang npu. L'autore, w1ida, dichiara subito l'intento: un percorso di main attention CANN opt-in per il prefill eager di Qwen4-Exp QSA, basato su torch_npu.npu_sparse_flash_attention, con l'indexer, la selezione Top-K, il budget di token e il contenuto della KV-cache lasciati esattamente come erano.

Il trucco che usa per arrivarci merita un paragrafo, perché spiega perché questo è un adattatore di layout anziché un nuovo kernel di attenzione. Per Q e K già ruotati, il percorso impacchetta la cache come C = [K, V] e la query come Q' = [Q, 0]. Il prodotto Q' @ C.T è quindi uguale a Q @ K.T, e poiché la query con padding non contribuisce, softmax(scale * Q' @ C.T) @ C restituisce [P @ K, P @ V] impilati — così la metà V può essere estratta tramite slicing. Nelle parole stesse dell'autore, questo è "un embedding del layout di attenzione, non una modifica all'attenzione del modello né una compressione KV a basso rango". Ogni testa KV diventa un batch indipendente nel layout MLA nativo, la scala D256 originale è preservata e il RoPE ausiliario è azzerato.

I dettagli operativi contano quanto la matematica:

• Attivazione — SGLANG_NPU_QSA_NATIVE_PREFILL=1, predefinito disattivato. Solo il normale ForwardMode.EXTEND vi aderisce; decodifica, modalità speculative, forward misto e cattura del grafo restano tutti sui percorsi esistenti, e la cattura del grafo bypassa completamente l'adapter.

• Hardware e dtype — BF16 con dimensione head 256, Ascend 910C (Ascend910_93*), testato con CANN 9.0 e torch-npu 2.10. Qualsiasi dtype o shape non supportato ricade silenziosamente sul percorso di riferimento.

• Forme delle teste — supportate locali (teste Q, teste KV) coppie sono (16,2), (24,2), (12,1), (6,1) e (3,1). CANN rifiuta senza appello un rapporto query/KV di 12 — il suo tiler accetta solo potenze di due — quindi le teste vengono portate da 12 a 16, da 6 a 8 o da 3 a 4 e gli output aggiunti scartati. Questo è il segno più chiaro in tutta la PR che l'hardware non è stato progettato pensando ai rapporti tra teste dello sparse attention, e l'adapter sta assorbendo questo disallineamento invece di essere il modello a cambiare forma per esso.

• Limiti di dimensionamento — viene impacchettata solo l'estensione fisica della cache referenziata, limitata a 262.144 token, che l'autore calcola essere al massimo 512 MiB per il tensore K/V BF16 impacchettato con due teste KV. Il padding interno -1 viene rilevato e instradato al fallback, poiché CANN richiede slot validi contigui; le righe completamente mascherate mantengono la convenzione esistente di output zero.

• Perché solo prefill — il controllo dell'estensione e del layout copia due scalari sull'host, e le copie temporanee più il workspace nativo costano memoria. Tale sincronizzazione è il motivo per cui il percorso è limitato al prefill eager e tenuto disattivato durante la cattura.

Nove test superati e un valore di velocità che non proveniva da questo branch

Le prove di correttezza sono specifiche e riproducibili, il che è più di quanto offrano la maggior parte delle PR del kernel. L'autore riporta 9 test superati in 40,772 secondi su un Ascend 910C (Ascend910_9362) con CANN 9.0 e torch-npu 2.10.0, senza bisogno di un checkpoint: Q/K/V BF16 casuali diversi da zero rispetto a un riferimento FP32 su CPU calcolato dagli stessi input BF16, slot fisici non ordinati con larghezze 1/63/64/65/2051, scale predefinite ed esplicite, righe completamente mascherate, righe a zero, larghezza di selezione zero, tensori non contigui, resti di coda causale con rapporto di compressione 4 da 0 a 3, mappatura fisica a due richieste con un prefisso condiviso, riutilizzo del contenuto della cache e le forme locali della testa Flash-Next a 1 e 257 righe di query.

Il caso principale è un prefill lungo: 7,810 token di query contro una cache da 65,536 token con 2,051 slot selezionati per query, tutti gli output finiti, con otto righe campionate confrontate con il riferimento FP32. L'errore relativo L2 osservato ha raggiunto 0.209% sui casi con head-shape piccola e 0.231% sulle righe campionate del prefill lungo, rispetto a soglie di test di atol=0.025, rtol=0.025 e L2 relativo inferiore a 0.008, con le righe vuote che devono essere esattamente zero. La memoria NPU di picco allocata per quella esecuzione è indicata in 1,042.7 MiB — e l'autore la definisce come metrica dell'allocatore PyTorch, non l'HBM della scheda e non la memoria dell'intero modello, che è esattamente l'avvertenza giusta da aggiungere.

Poi c'è il numero che verrà citato e che non dovrebbe esserlo. Il corpo della PR contiene una tabella di velocità che mostra il percorso di attenzione locale esistente a 2.270,79 nuovi token al secondo e l'attenzione principale nativa packed a 3.890,06 — un guadagno di 1,713× / +71,3%, con il tempo medio al primo token che scende da 3,109 s a 1,812 s. L'autore è esplicito sul fatto che si tratta di misurazioni storiche di prototipo effettuate il 2026-09-29 su un Whittle-Next-26B-A3B checkpoint adattato, eseguito a TP1 con pesi W8A8 e attenzione BF16 su 910C sotto CANN 9.0, utilizzando il sglang.bench_serving harness ufficiale a concorrenza 1 con sei richieste, un token di output ciascuna, e 36.096 token di prefisso in cache esclusi dal throughput dei nuovi token. Questi dati nonun benchmark del branch upstream nella PR, gli artefatti JSON di serving originali non sono presenti nel checkout, e risultati locali successivi intorno ai 5.000 token al secondo hanno utilizzato ulteriore lavoro nativo su indexer e block4 che non è esplicitamente attribuito a questa modifica. L'autore osserva inoltre che i pesi dell'indexer del checkpoint adattato sono inerti e che il suo budget differisce da quello originale, quindi nulla di tutto ciò costituisce prova sulla correttezza dell'indexer o sulla qualità di generazione a budget completo.

Un chiarimento sulla denominazione, perché confonderà chiunque cerchi il checkpoint: il modello di benchmark è l’artefatto adattato del contributore stesso. Separatamente, “Whittle-Next” è anche il nome di una serie pubblica di fine-tuning MoE derivati da Qwen3.8 pubblicata da un account Hugging Face di terze parti, inclusa una variante 26B-A3B caricata a settembre. Quelli non sono il modello Qwen4Exp a cui punta questa PR, e non devono essere interpretati come la configurazione di benchmark alla base di quel valore di 1.713×.

Due ulteriori avvertenze provengono dall'autore, non da me. L'integrazione completa del serving, il parallelismo tensoriale distribuito e il modello completo Qwen3.8-Flash-Next non sono stati convalidati su questo branch; il contributore afferma che mantenerla come bozza mentre si discute della questione dell'integrazione e delle dipendenze è una scelta deliberata, e chiede persino nel corpo della PR se l'adattatore debba stare in SGLang o nel separato sgl-kernel-npu repository. Neanche la CI è pulita — il blocco di stato nel corpo della PR mostra fallimenti in PR Test (Base), PR Test (Extra) e nell'esecuzione AMD ROCm 10. La correttezza descritta sopra è a livello di operatore; nulla nella PR rivendica un risultato di accuratezza o throughput end-to-end sullo stack integrato.

Perché QSA è la parte scomoda, in cifre

Qwen Sparse Attention non è un livello di attenzione convenzionale, e la configurazione pubblicata mostra perché un fornitore di acceleratori debba scrivere un percorso su misura per essa. Dalla configurazione di Qwen3.8-Flash-Next: 48 livelli disposti come dodici ripetizioni di tre blocchi Gated DeltaNet seguiti da un blocco di attenzione completa, full_attention_interval 4, dimensione nascosta 2.560, dimensione della testa di attenzione 256, 24 teste di query contro 2 teste KV, dimensione RoPE 64. L'indicizzatore che rende l'attenzione sparsa è una struttura multi-query con 4 teste di query che condividono 1 testa di chiave, dimensione della testa 128, un rapporto di compressione di 4 e un budget di 2.048 micro-blocchi selezionati per query.

Quel budget è ciò che la PR mantiene fisso. La dimensione del blocco sparse resta 1, la modalità sparse resta 0, la modalità di attenzione resta 2, e l'interfaccia dei token selezionati rimane intatta; l'indexer nativo e le ottimizzazioni block4 sono esplicitamente fuori ambito. Quindi questo è un adattatore avvitato sotto un meccanismo di selezione esistente, non una reimplementazione di QSA — motivo per cui l'autore può anche affermare in modo credibile che il contenuto della KV-cache è invariato.

La model card inquadra chiaramente l'intento progettuale: invece di selezionare singoli token, QSA opera a livello di micro-blocco per ridurre la latenza sui contesti lunghi, e proprio quella granularità a micro-blocchi, insieme allo stato del selettore replicato che la accompagna, è esattamente ciò che non si mappa in modo pulito su un kernel generico di paged attention sul silicio di nessuno dei due fornitori.

Dove si inserisce questo nel build-out del serving di Qwen4Exp

Visto da solo, una PR in bozza su un acceleratore è una curiosità. Visto in rapporto al resto di settembre, è la quarta o quinta tavola di una piattaforma che viene assemblata in pubblico prima che esista la famiglia che serve:

• L'architettura in open weights — Qwen3.8-Flash-Next, 2026-08-24, un MoE da 125B parametri con 6B attivati, una tabella di embedding n-gram da 51 miliardi di parametri e una testa MTP da 4B, che riporta model_type: qwen4_exp e le architetture Qwen4ExpForConditionalGeneration.

• Il lato vLLM — #53909, la PR “qwen4 fuse op” che aggiunge i kernel HyperConnection, QSA e PLE, ancora aperta e non mergiata dal 2026-08-26; #59279, che aggiunge il parallelismo di contesto in decodifica allo stesso percorso QSA, una bozza aperta il 2026-09-29; e il lavoro di offload PLE integrato nel corso di settembre.

• Il lato SGLang — #38642 per la cattura dello stato nascosto di DFlash, #39548 per l'offload su CPU di PLE di Qwen4-Exp su Ascend, #40235 che aggiunge lo staging sull'host per la tabella PLE basata su file, e ora #41855 per il percorso di attenzione di Ascend.

• La linea di abilitazione NPU — sglang #37570, che aggiunge Qwen3.8-Flash-Next a SGLang su NPU con graph replay, MTP e kernel Triton (aperta il 2026-09-02, ancora aperta, +2.590 righe su 20 file), e sgl-kernel-npu #807 per i kernel Triton complementari (aperta il 2026-09-17, +4.643 righe). Entrambe provengono dallo stesso contributore. #41855 è il layer di attenzione che si trova all'interno di quel più ampio sforzo di abilitazione.

Due osservazioni su cui un lettore può agire. In primo luogo, l'intera vicenda di Ascend Qwen4Exp si basa su un numero molto esiguo di contributori: le PR di enablement e il repository dei kernel condividono un autore, mentre l'adattatore di attenzione ne ha un altro. Questa concentrazione è una stima ragionevole di quanto il serving di Ascend Qwen4Exp sia lontano dall'essere un percorso di prodotto supportato anziché un esperimento. In secondo luogo, il collo di bottiglia dei kernel non è specifico di un fornitore: due issue di SGLang aperte il 2026-08-28 documentano il decode di Qwen4Exp su una NVIDIA DGX Spark, dove domina il tempo dei kernel QSA, PLE e Gated DeltaNet, e dove è stato misurato che una KV cache NVFP4 peggiora il decode di circa il 29% rispetto a fp8_e4m3. I layer di attenzione e di embedding di questa architettura sono la parte difficile ovunque.

Cosa questo non significa

Non significa che Qwen 4 sia disponibile, né che lo sarà a breve. La famiglia Qwen 4 a cui Alibaba ha dato un nome il 22 settembre 2026 — Max, Flash, Plus e una fascia da 27B — resta una roadmap senza model card, senza pesi, senza identificatore API, senza finestra di contesto, senza licenza e senza prezzo. Un adattatore di framework che punta al nome dell'architettura interna è un passo verso il riuscire a servire bene quella famiglia un giorno; non è un passo verso l'esistenza della famiglia.

Non significa che tu possa eseguirlo oggi. La PR è una bozza con la CI che fallisce e nessuna data di merge. Anche dopo il merge, il percorso richiede un Ascend 910C, BF16, CANN 9.0 con torch-npu 2.10 e una delle cinque specifiche forme locali di head, ed è opt-in — il che significa che un deployment deve sceglierlo. L'autore ha inoltre rifiutato di dichiarare una validazione a livello server, che è la parte che in realtà ti direbbe se regge in condizioni di batching reale.

E non significa che Qwen3.8-Flash-Next sia un prodotto supportato su Ascend, né altrove in una build di un motore rilasciata. I percorsi Qwen4Exp in entrambi i principali runtime open sono pull request non unite. Non esiste alcuna versione rilasciata di SGLang o vLLM che tu possa installare e che serva nativamente questa architettura — la comodità in stile FastAPI di un endpoint ospitato è una cosa diversa da un kernel che puoi eseguire da solo, e il divario tra i due è esattamente ciò per cui esistono PR come questa.

Cosa puoi effettivamente chiamare mentre aspetti

Se il motivo per cui ti interessa Qwen4Exp è che vuoi testare il comportamento a contesto lungo dell'architettura anziché i suoi interni del kernel, il modello da scegliere è il tier che Alibaba serve effettivamente. Qwen3.8-Flash — la linea di produzione basata su Qwen3.8-Flash-Next, con strumenti integrati ufficiali e un contesto da 1.000.000 di token — è attivo su OrcaRouter come qwen/qwen3.8-flash: input di testo, immagini e video, output massimo di 131.072 token, $0,15 per milione di token in input e $0,47 per milione in output, con letture dalla cache a $0,0184. Quelli sono i prezzi di listino del provider trasferiti con markup dello 0% da parte nostra, quindi una variazione di prezzo o di limite da parte del fornitore ti raggiunge lo stesso giorno in cui viene annunciata. Nella finestra degli ultimi sette giorni la scheda live mostra una latenza p50 al primo token di 4.416 ms, circa 106 token di output al secondo e un tasso di errore del 2,68% — il profilo di un tier testuale ad alto volume piuttosto che di un'anteprima da laboratorio.

Due precisazioni oneste, e sono le stesse due che portano gli articoli gemelli su questa architettura. Qwen3.8-Flash-Next stesso — il checkpoint di anteprima FP8, ciò che servirebbe per riprodurre localmente una qualsiasi di queste misurazioni dei kernel — non è nel nostro catalogo; il tier Flash servito è la distribuzione di produzione costruita a partire da esso, non l'artefatto di anteprima grezzo. E nessuno dei lavori su Ascend o DCP descritti sopra esiste in qualcosa che tu possa chiamare, perché nulla di tutto ciò è stato sottoposto a merge. Ciò che il tier servito ti offre è un modo economico per scoprire se il tuo carico di lavoro è modellato per il problema che questi kernel risolvono: prompt agentici lunghi e ricchi di prefissi su un contesto molto lungo. Se lo è, il throughput e il comportamento della cache che osservi lì sono gli stessi che lo stack di servizio di Qwen 4 sarà ottimizzato per proteggere.

C'è anche un argomento infrastrutturale per non aspettare una famiglia che non ha una data. Qualunque tier finisca per vincere nella gamma Qwen 4, il costo di passaggio è una questione di routing più che un progetto di integrazione, e un'unica API per oltre 200 modelli è il modo per mantenere aperta quell'opzione senza un secondo contratto o una modifica al codice quando arrivano i pesi. Il failover conta per lo stesso motivo, qui in modo specifico: se vuoi sviluppare su un tier non collaudato, vuoi che la richiesta passi a qualcosa di stabile invece di fallire quando il percorso su cui hai puntato sta avendo un brutto momento.

Tre domande a cui vale la pena rispondere direttamente

SGLang #41855 significa che Qwen 4 è uscito, o che è disponibile in anteprima?

No, su entrambi i punti. La pull request è destinata all'architettura Qwen4Exp così come implementata in Qwen3.8-Flash-Next, che Alibaba ha rilasciato il 2026-08-24. Non tocca i pesi di Qwen 4, e nessun tier di Qwen 4 ha pesi da toccare. Il segnale da leggere qui riguarda la capacità di serving per un'architettura in anteprima, non la disponibilità della famiglia.

Se una model card dice qwen4_exp, è Qwen 4?

No — e questa è la trappola della denominazione in tutta la storia. qwen4_exp è l'identificatore interno dell'architettura, ed è quello che troverai in config.json per Qwen3.8-Flash-Next e il suo fratello FP8. "Architettura sperimentale" è la parola chiave: i pesi sono pubblicati, l'architettura è reale e il modello è un'anteprima di ciò su cui si prevede che sarà costruita la famiglia Qwen 4. Cercare l'identificatore e trovare una PR di SGLang o vLLM con Qwen4Exp nel titolo ti dice qualcosa sul lavoro sul motore, non su un rilascio.

È questa una storia Ascend contro NVIDIA?

Non proprio. Lo stesso percorso di attenzione ha richiesto un adattatore su misura anche sul lato NVIDIA — parallelismo del contesto di decodifica per QSA in vLLM, e un kernel nativo di prefill sparso per Hopper — e i problemi di DGX Spark mostrano che anche lì il tempo dei kernel QSA, PLE e Gated DeltaNet domina la decodifica. L’indicizzatore a micro-blocchi di QSA e il suo stato del selettore replicato semplicemente non sono ciò che presuppongono i kernel generici di paged attention. Il contributo di Ascend al pattern è il vincolo più netto: un tiler head-ratio che accetta solo potenze di due, il che impone il padding che l’adattatore deve nascondere.

La cosa da tenere d'occhio

Non se questo venga unito. L'adapter è onesto sul fatto di essere un adapter, i test di correttezza sono riproducibili senza un checkpoint, e l'autore ha segnalato la questione dell'integrazione invece di fingere che sia risolta. La cosa da tenere d'occhio è ciò che succede dopo che la linea di abilitazione NPU e questo percorso di attenzione vengono combinati — se il ramo integrato ottiene l'esecuzione end-to-end che nessuno dei due ha avuto, su batching reale con il modello completo invece che su tensori locali di forma delle teste. Il valore di 1,713× è quello che circolerà, ed è quello calcolato su una build diversa, su un checkpoint adattato, con un indicizzatore inerte. Un numero misurato sullo stack finito varrebbe considerevolmente di più di uno storico.

Fino ad allora, il riepilogo onesto è quello a cui la PR stessa si attiene: i calcoli tornano, il flag è disattivato per impostazione predefinita, la CI è rossa e il modello nel titolo continua a non esistere.