Qwen 4 QSA obtient le parallélisme de contexte de décodage : au cœur de la PR à l'état de brouillon de vLLM pour Qwen3.8-Flash-Next

Le 29 septembre 2026, une pull request brouillon est apparue dans le dépôt vLLM, intitulée « [Model][DCP] Support Qwen4Exp QSA », et pour le modèle qu’elle décrit, elle contient les chiffres de serving les plus concrets publiés par quiconque depuis le début du mois : des exécutions appariées de Qwen3.8-Flash-Next sur quatre GPU montrant une capacité de tokens KV passant de 9 759 529 à 17 603 636, une concurrence maximale passant de 37,23× à 67,15×, et un temps jusqu’au premier token passant de 1 869 ms à 767 ms. Qwen3.8-Flash-Next est la préversion à poids ouverts de 125 milliards de paramètres, de type mélange d’experts, dont la fiche Hugging Face le décrit comme « un aperçu de l’architecture Qwen4 » ; la pull request ajoute un parallélisme de contexte de décodage au chemin d’attention creuse autour duquel cette architecture est construite. Qwen4 lui-même — les niveaux Qwen4 Max, Flash, Plus et 27B que le fournisseur a nommés lors de sa conférence Apsara le 22 septembre 2026 — n’est toujours pas publié, sans poids, sans identifiant, sans prix et sans date. Considérez donc ceci pour ce que c’est : non pas un lancement, non pas un benchmark, mais un artefact d’ingénierie qui vous indique comment l’enveloppe de serving de Qwen4 est en train de s’élargir avant même que la famille n’existe.

Ceci est un point d'étape sur ce que nous savons à ce jour, et la source importe plus que d'habitude. La pull request est une ébauche, ouverte et non fusionnée — vllm-project/vllm#59279, ouverte le 2026-09-29 par Sungsoo Ha, ingénieur logiciel chez NVIDIA, et toujours à l'état d'ébauche. Chaque chiffre ci-dessous provient de la propre mesure appariée de l'auteur, rapportée dans le corps de la PR, réalisée sur une révision antérieure du même travail. Rien ici n'a fait l'objet d'un audit indépendant, rien ici n'a été intégré à une version publiée, et la mise en garde que l'auteur y associe est suffisamment importante pour qu'elle ait sa propre section ci-dessous.

Ce que la pull request change réellement

Le parallélisme de contexte de décodage — DCP — est une technique de serving, pas une modification du modèle. Au lieu qu’un seul groupe de GPU détienne l’intégralité d’un cache KV, DCP répartit ce cache entre les rangs : chaque rang ne lit donc que sa tranche du contexte, tandis que les résultats d’attention sont combinés entre les rangs à la fin. L’enjeu, c’est la capacité : une fois le cache partitionné, un déploiement peut prendre en charge bien plus de trafic simultané à contexte long sur le même matériel, ce qui est exactement la contrainte qui se fait sentir lorsque chaque requête transporte un quart de million de jetons.

La complication est que Qwen Sparse Attention — QSA — n'est pas une simple couche d'attention. Comme le précise la fiche modèle de Qwen3.8-Flash-Next, un indexeur léger compresse les clés en micro-blocs avec un taux de compression de 4, les note et conserve les 512 meilleurs blocs, soit environ 2 048 positions de jetons, tandis que le softmax final et l'agrégation des valeurs s'exécutent toujours sur les K et V non compressés. Cela signifie que QSA porte plus d'état qu'un cache KV : il y a le cache principal, et il y a les caches de sélection et annexes que l'indexeur maintient. L'implémentation DCP générique dans vLLM ne sait rien de tout cela.

Ce que fait #59279, d'après sa description, c'est d'enseigner à DCP les parties spécifiques à QSA :

• Chaque rang lit sa propre partie de la principale mémoire cache KV, tandis que le sélecteur de QSA et les caches secondaires restent répliqués entre les rangs plutôt que partitionnés.

• Les résultats d’attention sont combinés entre les rangs après la lecture fractionnée.

• Le sélecteur et le cache KV principal sont conservés dans un même groupe de cache, de sorte qu'ils ne peuvent pas diverger.

• Les lots synthétiques V2 ne sont pas autorisés à écrire dans les caches latéraux QSA.

Cette dernière paire de détails est la partie intéressante si l’on se soucie de l’exactitude plutôt que du débit. Un cache d’attention partitionné qui diverge silencieusement d’un sélecteur répliqué est le genre de bug qui se manifeste par une lente dégradation de la précision sur un contexte long plutôt que par un crash, et la modification indique explicitement que les deux doivent rester synchronisés. L’auteur précise également qu’une assistance IA a été utilisée et que Codex est crédité comme co-auteur — ce qui vaut la peine d’être dit sans détour, car dans une PR brouillon de ce type, il est légitime de se demander qui a écrit quoi.

Les nombres appariés, et comment ils ont été obtenus

Le plan de test est suffisamment précis pour être vérifiable, et c'est pourquoi les résultats valent la peine d'être cités. Les deux branches exécutent Qwen/Qwen3.8-Flash-Next-FP8 sur quatre GPU avec un parallélisme tensoriel de 4 et le parallélisme d'experts activé, à --gpu-memory-utilization 0.90 avec la mise en cache de préfixes activée. La seule différence entre les deux branches est --decode-context-parallel-size : omis pour DCP=1, défini à 2 pour DCP=2, avec un redémarrage entre les branches afin que le benchmark démarre à partir d'un cache froid. La charge correspond à une trace AgentX 256k avec 128 utilisateurs pendant 900 secondes ; la précision est mesurée par EvalScope pour GSM8K ainsi que par l'évaluateur MRCR versionné dans le dépôt, exécuté six fois par branche, la première exécution après le redémarrage étant écartée.

Les écarts de débit signalés, DCP=2 par rapport à DCP=1 :

• Jetons KV — 9 759 529 contre 17 603 636, soit une augmentation de 1,80× de la capacité de cache.

• Concurrence maximale — 37,23× contre 67,15×, également 1,80×.

• Requêtes par seconde — 1,69 contre 2,30, 1,36×.

• Tokens d'entrée par seconde — 128 730 vs 179 702, 1,40×.

• Temps jusqu'au premier token — 1 869 ms contre 767 ms, soit 2,44× plus bas.

• Latence inter-tokens — 43,48 ms contre 26,27 ms, soit 1,66× plus faible.

• Taux de succès du cache de préfixes en régime permanent — 67,85 % contre 88,98 %, soit un gain de 21,1 points de pourcentage.

L'exactitude, rapportée comme moyenne ± écart-type d'échantillon sur les exécutions après échauffement, était essentiellement stable : l'agrégat MRCR 0,8630 ± 0,0005 à DCP=1 contre 0,8697 ± 0,0153 à DCP=2, et GSM8K 0,9788 ± 0,0020 contre 0,9790 ± 0,0016. Les échantillons MRCR à 2 aiguilles et à 4 aiguilles étaient fixes à 0,9960 et 0,9906 sur les deux bras, donc toute la variation d'une exécution à l'autre provenait des échantillons à 8 aiguilles — et une exécution agrégée DCP=2 a obtenu 0,8970 tandis que les quatre autres se situaient entre 0,8620 et 0,8632. C'est une réelle dispersion, pas un bruit que l'on peut balayer d'un revers de main, et c'est indiqué dans la PR plutôt que lissé.

Ce que ces chiffres n’établissent pas

La mise en garde figure dans le texte de la PR et elle n'est pas anodine. Les résultats appariés d'AgentX et de précision ont été mesurés sur une précédente révision de QSA DCP, à l'aide d'un vLLM nightly basé sur le commit 3df4ae153eb. Le commit propre final de la pull request inclut un correctif ultérieur du noyau de localisation QSA et a passé une validation ciblée sur B200 — mais les évaluations complètes d'AgentX et de précision n'ont pas été répétées sur cette source exacte. Autrement dit : l'histoire du débit et le diff livré ne sont pas le même artefact, et l'auteur le dit.

Au-delà de cela, la discipline habituelle s’applique, et elle s’applique durement ici. Ce sont des chiffres pour une configuration unique, provenant d’un seul contributeur sur une seule installation à quatre GPU. Ils sont proches du fournisseur plutôt que neutres : qu’un contributeur à un framework mesure une modification du framework est une chose normale et utile, mais ce n’est pas un audit indépendant, et aucun tiers n’a reproduit l’exécution. Il n’existe aucune version publiée de vLLM que vous pouvez installer aujourd’hui et qui contient cette modification, car celle-ci n’a pas été fusionnée. Et DCP=2 est un découpage en deux d’une forme spécifique — les deltas ne constituent pas une promesse quant à ce que feraient DCP=4 ou DCP=8, et rien dans la PR ne prétend qu’ils le font.

Pourquoi une PR de serving à propos d’une architecture non publiée vaut encore votre temps

L’objection évidente : le modèle mentionné dans le titre n’existe pas, alors pourquoi s’en soucier ? Parce que ce que l’on ajuste n’est pas Qwen 4. C’est Qwen3.8-Flash-Next, et ce modèle existe bel et bien — Alibaba l’a publié le 24 août 2026 comme 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, une tête MTP de 4 B pour le décodage spéculatif, 48 couches agencées en douze répétitions de trois blocs Gated DeltaNet suivis d’un bloc QSA, 512 experts dont 10 routés et 1 partagé actifs, et un contexte natif de 262 144 tokens que la fiche annonce comme extensible à 1 000 000. C’est l’implémentation de référence de l’architecture Qwen4 en poids ouverts, et QSA — l’attention parcimonieuse à micro-blocs que cette pull request apprend à DCP à partitionner — en est la partie la plus distinctive.

Ce que les chiffres décrivent, c'est ce qui se passe lorsqu'on cesse de traiter ce contexte de 262K comme quelque chose qu'un seul groupe de GPU doit garder en entier. Le bond de 1,80× de la capacité de jetons KV et de la concurrence, c'est l'arithmétique de la division d'un cache en deux, soit le résultat le moins surprenant de la liste. Les chiffres les plus intéressants sont ceux de la latence : un temps jusqu'au premier jeton 2,44× plus faible et une latence entre jetons 1,66× plus faible à charge offerte identique, plus une amélioration de 21 points du taux de succès du cache de préfixes en régime permanent. Ces chiffres disent que le chemin DCP n'achète pas simplement de la capacité au prix d'une latence — dans cette exécution appairée, il a acheté les deux. C'est la forme de changement qui compte pour quiconque sert du trafic d'agents avec de très longs prompts système, car le comportement du cache de préfixes en contexte long est généralement là où le débit en contexte long s'effondre discrètement.

Et ce n’est pas un patch isolé. La même semaine a donné lieu à un ensemble de travaux sur le moteur Qwen4Exp : #59214 ajoute des plans GEMM de décodage à faible latence SM100 pour les formes B200, #59010 ajoute un noyau de préremplissage sparse natif SM90 pour le chemin QSA sur Hopper, #58977 couvre les embeddings BF16 INC PLE, et #58961 — celui qui a réellement été fusionné, le 2026-09-28 — a corrigé un cache KV de profilage que les vues de clés QSA maintenaient en vie. Lus ensemble, ils constituent l’enveloppe de service de l’architecture Qwen4 en cours de construction en public, dans les runtimes, des mois avant la sortie de la famille. Si vous planifiez Qwen 4, le signal utile n’est pas une date de lancement — il n’y en a pas — c’est ce que les noyaux et les agencements de cache supposent déjà sur la manière dont vous devrez le servir.

Ce que vous pouvez appeler aujourd'hui.

Si vous souhaitez tester le comportement en contexte long sur l’architecture dont traite cette PR, le modèle vers lequel se tourner est le niveau Flash qu’Alibaba sert réellement. Qwen3.8-Flash — le déploiement de production construit sur Qwen3.8-Flash-Next, avec un contexte de 1 000 000 de tokens et une sortie maximale de 131 072 tokens, acceptant en entrée du texte, des images et de la vidéo — est en ligne, et il s’agit de d’un point de terminaison pour le modèle qui exécute réellement l’architecture Qwen4Exp aujourd’hui, répertorié comme qwen/qwen3.8-flash à 0,15 $ par million de tokens d’entrée et 0,47 $ par million de tokens de sortie, avec les lectures de cache à 0,0184 $. Comme il s’agit de prix catalogue du fournisseur répercutés sans marge de notre côté, toute modification de prix ou de limite apportée par le fournisseur vous parvient le jour même de son annonce.

Deux précisions honnêtes. Premièrement, Qwen3.8-Flash-Next lui-même — les poids FP8 du plan de test de la pull request, ceux dont vous auriez besoin pour reproduire localement l’une de ces mesures — ne figure pas dans notre catalogue ; le palier Flash servi correspond à la ligne de production QwenCloud, pas au checkpoint d’aperçu brut. Si vous voulez exécuter la configuration exacte de la PR, vous vous auto-hébergez sur quatre GPU. Deuxièmement, la modification DCP n’est pas fusionnée, donc rien de ce que vous pouvez appeler aujourd’hui, où que ce soit, ne l’exécute. Ce que le palier servi vous offre, c’est un moyen de déterminer si votre charge de travail est ne serait-ce qu’un peu adaptée au problème que résout DCP : si vos prompts sont longs, agentiques et à forte composante de préfixes, alors la capacité de 1,80× et le delta du cache de préfixes sont les chiffres à surveiller dans vos propres traces.

Et si ce qui vous intéresse n'est pas un modèle en particulier mais la question du basculement — sur quel niveau s'appuyer alors que la gamme Qwen 4 n'a pas encore de nom —, il s'agit d'un problème de routage plutôt que de service, et une API pour plus de 200 modèles est ce qui vous permet de garder l'option ouverte sans second contrat ni modification du code lorsque la famille verra enfin le jour.

Questions qui méritent une réponse directe

Le #59279 signifie-t-il que Qwen 4 est sorti, ou sur le point de l'être ?

Non. La pull request porte sur l’architecture Qwen4Exp telle qu’implémentée dans Qwen3.8-Flash-Next, qu’Alibaba a livrée le 24 août 2026. La famille Qwen 4 — Max, Flash, Plus et 27B — a été nommée sur une scène à Apsara le 22 septembre 2026 et inscrite sur une feuille de route d’entreprise avec une lignée de successeurs prévue à 5 à 10 billions de paramètres, et elle n’a toujours ni fiche modèle, ni poids, ni identifiant d’API, ni fenêtre de contexte, ni prix, ni date. Une PR de framework qui ajoute un mode de parallélisme à l’architecture de préversion est un pas vers le fait de bien servir Qwen 4. Ce n’est pas un pas vers l’existence de Qwen 4.

En quoi le parallélisme de contexte de décodage diffère-t-il du parallélisme tensoriel ?

Ils partitionnent des éléments différents et échouent de manières différentes. Le parallélisme tensoriel partitionne les poids et le calcul de chaque couche entre les GPU, de sorte que chaque rang participe à chaque token mais voit toute la séquence. Le parallélisme de contexte en décodage partitionne le cache KV lui-même, de sorte que chaque rang ne détient et ne lit qu'une tranche du contexte, et les résultats partiels d'attention sont fusionnés ensuite. Le TP sert à faire tenir le modèle ; le DCP sert à faire tenir le contexte et le trafic concurrent qui l'accompagne. C'est exactement pour cette raison que cette PR n'est pas triviale : le sélecteur de QSA et les caches secondaires ne peuvent pas simplement être shardés comme le cache KV principal, la modification doit donc sharder l'un et répliquer les autres, puis prouver que les deux restent cohérents.

Si j’appelle Qwen3.8-Flash-Next aujourd’hui via une API hébergée, est-ce que j’obtiens déjà ces chiffres ?

Non, et l'écart se décompose en trois parties. La modification n'est pas fusionnée, donc aucune version publiée de vLLM ne la contient. Même une fois fusionnée, le fournisseur doit adopter cette version et choisir de l'exécuter avec une taille DCP supérieure à un — il s'agit d'une configuration de service, pas d'une valeur par défaut. Et les écarts mesurés proviennent d'une révision antérieure du correctif plutôt que du commit final, dont l'auteur indique qu'il n'a fait l'objet jusqu'ici que d'une validation ciblée sur B200. Considérez les écarts rapportés comme une borne supérieure bien documentée de ce que l'approche apporte dans une configuration donnée, et non comme une spécification d'un point de terminaison que vous pouvez louer cette semaine.

La question ouverte

Ce qu'il faut surveiller, ce n'est pas si ce brouillon précis sera fusionné — il le sera probablement sous une forme ou une autre, car la gestion du cache spécifique à QSA qu'il ajoute est une véritable lacune plutôt qu'une préférence. Ce qu'il faut surveiller, c'est si le commit final reçoit la même évaluation appariée que la révision intermédiaire. Un changement de serving dont les affirmations de débit proviennent d'un build et les affirmations d'exactitude d'un autre est, pour l'instant, une proposition bien argumentée plutôt qu'un résultat mesuré, et l'écart de précision sur les échantillons MRCR à 8 aiguilles est suffisamment large pour que répéter l'exécution sur la source livrée soit la chose la plus utile que quiconque puisse publier à ce sujet. D'ici là : la direction est lisible, le bilan n'est pas clos, et le seul modèle d'architecture Qwen4 en poids ouverts reste celui d'août.