Qwen4-Exp QSA arrive sur l'Ascend de Huawei : au cœur de la PR de préremplissage CANN en opt-in de SGLang

Le 30 septembre 2026, un contributeur a ouvert la pull request SGLang n° 41855, intitulée « [NPU] Ajouter une attention creuse CANN à activation optionnelle pour le préremplissage QSA de Qwen4-Exp », et ce qui est intéressant n’est pas l’arithmétique. C’est le matériel. L’architecture Qwen4Exp dispose désormais d’un chemin d’attention creuse écrit à la main pour l’accélérateur Ascend 910C de Huawei, derrière un indicateur désactivé par défaut, dans une pull request en brouillon qui n’a pas été fusionnée — alors que le modèle auquel ce nom d’architecture appartient, Qwen4-Exp, n’a jamais été publié sous quelque forme que ce soit. Le seul checkpoint qui porte cette architecture en poids ouverts est encore Qwen3.8-Flash-Next, l’aperçu de type mélange d’experts de 125 milliards de paramètres publié par le fournisseur sur Hugging Face le 24 août 2026, et dont la fiche déclare en réalité son architecture comme qwen4_exp. Qwen 4 lui-même — les paliers Max, Flash, Plus et 27B que le fournisseur a nommés lors de sa conférence Apsara le 22 septembre 2026 — n’a toujours ni poids, ni identifiant, ni prix, ni date. Il s’agit donc d’un article de type « ce que l’on sait à ce jour » sur un artefact d’ingénierie, et non d’un lancement : une pile de serving d’un fournisseur de plus qui décide discrètement qu’une architecture non publiée mérite d’être prise en charge tôt.

Ce que la pull request ajoute réellement

Le changement est délibérément petit et délibérément étroit. Cinq fichiers, un commit, +355 lignes par rapport à une branche principale au commit b87a241, portant le SGLang npu label. L'auteur, w1ida, déclare d'emblée son intention : un chemin d'attention principale CANN opt-in pour le préremplissage eager QSA de Qwen-Exp, construit sur torch_npu.npu_sparse_flash_attention, avec l'indexeur, la sélection Top-K, le jeton et le contenu du cache KV tous laissés exactement tels qu'ils étaient.

L’astuce qu’il utilise pour y parvenir mérite un paragraphe, car elle explique pourquoi il s’agit d’un adaptateur de disposition plutôt que d’un nouveau noyau d’attention. Pour des Q et K déjà soumis à la rotation, le chemin empaquette le cache sous la forme C = [K, V] et la requête sous la forme Q' = [Q, 0]. Le produit Q' @ C.T est alors égal à Q @ K.T, et comme la requête complétée ne contribue en rien, softmax(scale * Q' @ C.T) @ C renvoie [P @ K, P @ V] empilés — de sorte que la moitié V peut être découpée. Pour reprendre les propres mots de l’auteur, il s’agit d’« un embedding de disposition d’attention, et non d’une modification de l’attention du modèle ni d’une compression KV de rang faible. » Chaque tête KV devient un batch indépendant dans la disposition MLA native, l’échelle D256 d’origine est préservée, et le RoPE auxiliaire est mis à zéro.

Les détails opérationnels importent autant que les mathématiques :

• Activation — SGLANG_NPU_QSA_NATIVE_PREFILL=1, par défaut désactivé. Seul le mode ordinaire ForwardMode.EXTEND est activé ; le décodage, les modes spéculatifs, le forward mixte et la capture de graphe restent tous sur les chemins existants, et la capture de graphe contourne entièrement l'adaptateur.

• Matériel et dtype — BF16 avec dimension de tête 256, Ascend 910C (Ascend910_93*), testé avec CANN 9.0 et torch-npu 2.10. Tout dtype ou forme non pris en charge bascule silencieusement vers le chemin de référence.

• Formes de têtes — les paires locales prises en charge (têtes Q, têtes KV) sont (16,2), (24,2), (12,1), (6,1) et (3,1). CANN rejette d'emblée un ratio query/KV de 12 — son tiler n'accepte que les puissances de deux — donc les têtes sont étendues par remplissage 12→16, 6→8 ou 3→4, et les sorties ajoutées sont écartées. C'est le signe le plus clair, dans toute la PR, que le matériel n'a pas été conçu en pensant aux ratios de têtes de l'attention clairsemée, et c'est l'adaptateur qui absorbe cette inadéquation plutôt que le modèle qui change de forme pour s'y conformer.

• Bornes de dimensionnement — seule l’étendue de cache physique référencée est compactée, plafonnée à 262 144 jetons, que l’auteur calcule à au plus 512 MiB pour le tenseur K/V BF16 compacté à deux têtes KV. Le remplissage interne à -1 est détecté et redirigé vers le repli, car CANN exige des emplacements valides contigus ; les lignes entièrement masquées conservent la convention existante de sortie nulle.

• Pourquoi uniquement le préremplissage — la vérification d’étendue et de disposition copie deux scalaires vers l’hôte, et les copies temporaires ainsi que l’espace de travail natif ont un coût en mémoire. Cette synchronisation est la raison pour laquelle le chemin est réservé au préremplissage en mode eager et désactivé pendant la capture.

Neuf tests réussis, et un chiffre de vitesse qui ne vient pas de cette branche

Les preuves de correction sont précises et reproductibles, ce qui est plus que ce qu'offrent la plupart des PR de kernel. L'auteur rapporte 9 tests réussis en 40,772 secondes sur un Ascend 910C (Ascend910_9362) avec CANN 9.0 et torch-npu 2.10.0, sans nécessiter de checkpoint : des Q/K/V BF16 aléatoires non nuls comparés à une référence CPU FP32 calculée à partir des mêmes entrées BF16, des emplacements physiques non ordonnés aux largeurs 1/63/64/65/2051, des échelles par défaut et explicites, des lignes entièrement masquées, des lignes nulles, une largeur de sélection nulle, des tenseurs non contigus, des restes de queue causale pour un ratio de compression de 4 allant de 0 à 3, un mappage physique à deux requêtes avec un préfixe partagé, une réutilisation du contenu du cache, et les formes de tête locales Flash-Next à 1 et 257 lignes de requête.

Le cas principal est un prefill long : 7 810 jetons de requête face à un cache de 65 536 jetons, avec 2 051 emplacements sélectionnés par requête, toutes les sorties étant finies, et huit lignes échantillonnées comparées à la référence FP32. L'erreur L2 relative observée atteint 0,209 % sur les petits cas de forme de tête et 0,231 % sur les lignes de prefill long échantillonnées, face à des seuils de test de atol=0.025, rtol=0.025 et une erreur L2 relative inférieure à 0,008, les lignes vides devant être exactement nulles. Le pic de mémoire NPU allouée pour cette exécution est annoncé à 1 042,7 MiB — et l'auteur précise qu'il s'agit de la métrique de l'allocateur PyTorch, et non de la HBM de la carte ni de la mémoire du modèle complet, ce qui est exactement la bonne mise en garde à apporter.

Ensuite, il y a le chiffre qui sera cité et qui ne devrait pas l'être. Le corps de la PR contient un tableau de vitesse montrant le chemin d'attention locale existant à 2 270,79 nouveaux jetons par seconde et l'attention principale native empaquetée à 3 890,06 — un gain de 1,713× / +71,3 %, avec le temps moyen jusqu'au premier jeton passant de 3,109 s à 1,812 s. L'auteur précise explicitement qu'il s'agit de mesures historiques de prototype prises le 2026-09-29 sur un point de contrôle adapté Whittle-Next-26B-A3B, exécuté à TP1 avec des poids W8A8 et une attention BF16 sur 910C sous CANN 9.0, en utilisant le harnais officiel sglang.bench_serving à une concurrence de 1 avec six requêtes, un jeton de sortie chacune, et 36 096 jetons de préfixe mis en cache exclus du débit de nouveaux jetons. Elles ne sont pas une référence (benchmark) de la branche amont dans la PR, les artefacts JSON de service originaux ne sont pas présents dans la copie de travail, et les résultats locaux ultérieurs autour de 5 000 jetons par seconde ont utilisé un travail supplémentaire natif sur l'indexeur et block4 qui n'est explicitement pas attribué à ce changement. L'auteur note également que les poids de l'indexeur du point de contrôle adapté sont inertes et que son budget diffère de l'original, donc rien de tout cela ne constitue une preuve de l'exactitude de l'indexeur ou de la qualité de génération à budget complet.

Une clarification de nommage, car elle induira en erreur quiconque recherche le checkpoint : le modèle de benchmark est l’artefact adapté propre au contributeur. Par ailleurs, « Whittle-Next » est aussi le nom d’une série publique de fine-tunes MoE dérivés de Qwen3.8 publiée par un compte Hugging Face tiers, comprenant une variante 26B-A3B mise en ligne en septembre. Ceux-ci ne sont pas le modèle Qwen4Exp que cible cette PR, et ils ne doivent pas être interprétés comme la configuration de benchmark derrière ce chiffre de 1.713×.

Deux autres réserves viennent de l'auteur plutôt que de moi. L'intégration complète du serving, le parallélisme tensoriel distribué et le modèle complet Qwen3.8-Flash-Next n'ont pas été validés sur cette branche ; le contributeur affirme que le maintien en brouillon pendant que la question de l'intégration et des dépendances est discutée est délibéré, et demande même dans le corps de la PR si l'adaptateur appartient à SGLang ou au dépôt séparé sgl-kernel-npu. La CI n'est pas propre non plus — le bloc d'état du corps de la PR montre des échecs sur PR Test (Base), PR Test (Extra) et l'exécution AMD ROCm 10. La justesse décrite ci-dessus se situe au niveau de l'opérateur ; rien dans la PR ne revendique un résultat de précision ou de débit de bout en bout sur la pile intégrée.

Pourquoi QSA est le point délicat, en chiffres

Qwen Sparse Attention n'est pas une couche d'attention conventionnelle, et la configuration publiée montre pourquoi un fournisseur d'accélérateurs doit écrire un chemin sur mesure pour celle-ci. D'après la configuration de Qwen3.8-Flash-Next : 48 couches organisées en douze répétitions de trois blocs Gated DeltaNet suivis d'un bloc d'attention complète, full_attention_interval 4, taille cachée 2 560, dimension de tête d'attention 256, 24 têtes de requête contre 2 têtes KV, dimension RoPE 64. L'indexeur qui rend l'attention creuse est une structure multi-requête avec 4 têtes de requête partageant 1 tête de clé, une dimension de tête de 128, un taux de compression de 4 et un budget de 2 048 micro-blocs sélectionnés par requête.

Ce budget est celui que la PR garde fixe. La taille de bloc sparse reste 1, le mode sparse reste 0, le mode d’attention reste 2, et l’interface de sélection de tokens reste intacte ; les optimisations native indexer et block4 sont explicitement hors périmètre. Il s’agit donc d’un adaptateur greffé sous un mécanisme de sélection existant, et non d’une réimplémentation de QSA — ce qui explique aussi pourquoi l’auteur peut affirmer de manière crédible que le contenu du KV-cache est inchangé.

La fiche modèle expose clairement l’intention de conception : plutôt que de sélectionner des tokens individuels, QSA opère au niveau des micro-blocs pour réduire la latence en contexte long, et cette granularité en micro-blocs, ainsi que l’état de sélecteur répliqué qui l’accompagne, est précisément ce qui ne se mappe pas proprement sur un noyau générique d’attention paginée, que ce soit sur le silicium de l’un ou l’autre fournisseur.

Où cela s'inscrit dans le déploiement du service Qwen4Exp

Vue isolément, une pull request en brouillon sur un accélérateur est une curiosité. Replacée dans le contexte du reste de septembre, elle constitue la quatrième ou cinquième planche d’une plateforme qui est assemblée en public avant même que la famille qu’elle sert n’existe :

• L’architecture en poids ouverts — Qwen3.8-Flash-Next, 2026-08-24, un MoE de 125 B de paramètres avec 6 B activés, une table d’embeddings de n-grammes de 51 milliards de paramètres et une tête MTP de 4 B, portant model_type: qwen4_exp et les architectures Qwen4ExpForConditionalGeneration.

• Le côté vLLM — #53909, la PR « qwen4 fuse op » ajoutant les kernels HyperConnection, QSA et PLE, toujours ouverte et non fusionnée depuis le 2026-08-26 ; #59279, qui ajoute le parallélisme de contexte de décodage au même chemin QSA, un brouillon ouvert le 2026-09-29 ; et le travail de déport de PLE qui a été intégré tout au long du mois de septembre.

• Le côté SGLang — #38642 pour la capture d'état caché DFlash, #39548 pour le déchargement CPU de PLE Qwen4-Exp sur Ascend, #40235 ajoutant le staging hôte pour la table PLE sauvegardée sur fichier, et maintenant #41855 pour le chemin d'attention Ascend.

• La ligne d’activation du NPU — sglang #37570, ajoutant Qwen3.8-Flash-Next à SGLang sur NPU avec rejeu de graphe, MTP et noyaux Triton (ouvert le 2026-09-02, toujours ouvert, +2 590 lignes réparties sur 20 fichiers), et sgl-kernel-npu #807 pour les noyaux Triton associés (ouvert le 2026-09-17, +4 643 lignes). Les deux proviennent du même contributeur. #41855 est la couche d’attention qui s’inscrit dans cet effort d’activation plus vaste.

Deux observations sur lesquelles un lecteur peut agir. Premièrement, toute l'affaire Ascend Qwen4Exp repose sur un très petit nombre de contributeurs — les PR d'activation et le dépôt de kernels partagent un même auteur, et l'adaptateur d'attention en est un autre. Cette concentration donne une estimation juste de la distance qui sépare le service Ascend Qwen4Exp d'un chemin produit pris en charge plutôt que d'une expérience. Deuxièmement, le goulot d'étranglement des kernels n'est pas propre à un fournisseur : deux tickets SGLang déposés le 2026-08-28 documentent le décodage Qwen4Exp sur un NVIDIA DGX Spark, où le temps des kernels QSA, PLE et Gated DeltaNet domine, et où un cache KV NVFP4 a été mesuré comme dégradant le décodage d'environ 29 % par rapport à fp8_e4m3. Les couches d'attention et d'embedding de cette architecture sont la partie difficile partout.

Ce que cela ne signifie pas

Cela ne signifie pas que Qwen 4 est sorti, ni qu'il est proche de l'être. La famille Qwen 4 qu'Alibaba a nommée le 22 septembre 2026 — Max, Flash, Plus et un palier 27B — reste une feuille de route sans fiche modèle, sans poids, sans identifiant d'API, sans fenêtre de contexte, sans licence et sans prix. Un adaptateur de framework qui cible le nom d'architecture interne constitue une étape pour bien servir cette famille un jour ; ce n'est pas une étape vers l'existence de cette famille.

Cela ne signifie pas que vous pouvez l'exécuter dès aujourd'hui. La PR est un brouillon avec une CI en échec et aucune date de fusion. Même une fois fusionnée, la voie nécessite un Ascend 910C, du BF16, CANN 9.0 avec torch-npu 2.10, et l'une de cinq formes de tête locales spécifiques, et elle est en opt-in — ce qui signifie qu'un déploiement doit la choisir. L'auteur a aussi refusé de revendiquer une validation au niveau serveur, qui est la partie qui vous dirait réellement si elle tient le coup sous un batching réel.

Et cela ne signifie pas que Qwen3.8-Flash-Next est un produit pris en charge sur Ascend, ni ailleurs dans une version compilée d’un moteur livré. Les chemins Qwen4Exp dans les deux principaux runtimes ouverts sont des pull requests non fusionnées. Il n’existe aucune version publiée de SGLang ou de vLLM que vous puissiez installer et qui serve cette architecture nativement — la commodité d’un point de terminaison hébergé à la FastAPI est une chose différente d’un kernel que vous pouvez exécuter vous-même, et c’est précisément pour combler cet écart que des PR comme celle-ci existent.

Ce que vous pouvez réellement appeler en attendant

Si la raison pour laquelle Qwen4Exp vous intéresse est que vous voulez tester le comportement en contexte long de l’architecture plutôt que ses rouages internes de noyau, le modèle vers lequel vous tourner est celui qu’Alibaba sert réellement. Qwen3.8-Flash — la ligne de production bâtie sur Qwen3.8-Flash-Next, avec des outils intégrés officiels et un contexte de 1 000 000 de tokens — est en ligne sur OrcaRouter sous qwen/qwen3.8-flash : entrée texte, image et vidéo, sortie maximale de 131 072 tokens, 0,15 $ par million de tokens en entrée et 0,47 $ par million en sortie, les lectures de cache étant à 0,0184 $. Ce sont les prix catalogue du fournisseur, répercutés avec 0 % de marge de notre côté, de sorte qu’une modification de prix ou de limite chez le fournisseur vous parvient le jour même de son annonce. Sur la fenêtre glissante des sept derniers jours, la fiche en direct affiche une latence p50 du premier token de 4 416 ms, environ 106 tokens de sortie par seconde et un taux d’erreur de 2,68 % — le profil d’une offre textuelle à gros volume plutôt que d’un aperçu de laboratoire.

Deux réserves honnêtes, et ce sont les deux mêmes que portent les articles frères consacrés à cette architecture. Qwen3.8-Flash-Next lui-même — le checkpoint de prévisualisation FP8, l'élément dont vous auriez besoin pour reproduire localement l'une quelconque de ces mesures de noyaux — ne figure pas dans notre catalogue ; le palier Flash servi est le déploiement de production construit à partir de lui, et non l'artefact de prévisualisation brut. Et rien de ce qui relève des travaux Ascend ou DCP décrits ci-dessus n'existe dans quoi que ce soit que vous puissiez invoquer, car rien de tout cela n'a été fusionné. Ce que le palier servi vous offre bel et bien, c'est un moyen peu coûteux de déterminer si votre charge de travail est façonnée pour le problème que ces noyaux résolvent — des invites longues, à préfixe lourd et agentiques, face à un contexte très long. Si c'est le cas, le débit et le comportement de cache que vous y observez sont ceux-là mêmes que la pile de service Qwen 4 sera réglée pour protéger.

Il existe aussi un argument d'ingénierie en faveur du fait de ne pas attendre une famille qui n'a pas de date. Quel que soit le niveau qui finit par l'emporter dans la gamme Qwen 4, le coût de basculement relève d'une question de routage plutôt que d'un projet d'intégration, et une API pour plus de 200 modèles est la façon de garder cette option ouverte sans second contrat ni modification de code lorsque les poids arriveront. Le basculement automatique compte pour la même raison ici, d'une manière bien précise : si vous voulez développer sur un niveau non éprouvé, vous voulez que la requête bascule vers quelque chose de stable plutôt qu'elle échoue lorsque le chemin sur lequel vous avez parié connaît un mauvais moment.

Trois questions qui méritent une réponse directe

Est-ce que SGLang #41855 signifie que Qwen 4 est sorti, ou qu'il est prévisualisable ?

Non, sur les deux points. La pull request cible l’architecture Qwen4Exp telle qu’implémentée dans Qwen3.8-Flash-Next, qu’Alibaba a livrée le 2026-08-24. Elle ne touche pas aux poids de Qwen 4, et aucun palier de Qwen 4 n’a de poids à toucher. Le signal à lire ici concerne la capacité de service pour une architecture en préversion, pas la disponibilité de la famille.

Si une fiche de modèle indique qwen4_exp, s'agit-il de Qwen 4 ?

Non — et c'est là le piège de dénomination de toute cette histoire. qwen4_exp est l'identifiant interne d'architecture, et c'est ce que vous trouverez dans config.json pour Qwen3.8-Flash-Next et son homologue FP8. « Architecture expérimentale » est le mot qui compte : les poids sont publiés, l'architecture est réelle, et le modèle est un aperçu de ce sur quoi la famille Qwen 4 devrait être construite. Chercher l'identifiant et tomber sur une PR SGLang ou vLLM avec Qwen4Exp dans le titre vous renseigne sur le travail du moteur, pas sur une sortie.

Est-ce une histoire d’Ascend contre NVIDIA ?

Pas vraiment. Le même chemin d’attention a aussi nécessité un adaptateur sur mesure du côté NVIDIA — le parallélisme de contexte de décodage pour QSA dans vLLM, et un noyau natif de préremplissage sparse pour Hopper — et les problèmes de DGX Spark montrent que le temps des noyaux QSA, PLE et Gated DeltaNet domine aussi le décodage là-bas. L’indexeur à micro-blocs de QSA et son état de sélecteur répliqué ne correspondent tout simplement pas à ce que supposent les noyaux d’attention paginée génériques. La contribution d’Ascend à ce schéma est la contrainte plus stricte : un tuileur de ratio de têtes qui n’accepte que les puissances de deux, ce qui impose le remplissage que l’adaptateur doit masquer.

Ce qu'il faut surveiller

Pas la question de savoir si cela fusionne. L'adaptateur est honnête sur le fait d'être un adaptateur, les tests de justesse sont reproductibles sans checkpoint, et l'auteur a signalé la question de l'intégration plutôt que de prétendre qu'elle est réglée. Ce qu'il faut surveiller, c'est ce qui se passe une fois que la ligne d'activation du NPU et ce chemin d'attention sont combinés — si la branche intégrée obtient l'exécution de bout en bout qu'aucune des deux n'a eue, sur du batching réel avec le modèle complet plutôt que des tenseurs locaux de forme de tête. Le chiffre de 1,713× est celui qui va circuler, et c'est celui calculé sur une build différente, sur un checkpoint adapté, avec un indexeur inerte. Un chiffre mesuré sur le stack terminé vaudrait bien plus qu'un chiffre historique.

D'ici là, le résumé honnête est celui auquel la PR elle-même s'en tient : l'arithmétique est correcte, le flag est désactivé par défaut, la CI est rouge, et le modèle du titre n'existe toujours pas.