Échantillonnage batch-shardé de Qwen4Exp : au sein de la PR vLLM #61018, et ce qu’elle dit à propos de Qwen 4

Le nombre le plus instructif dans la pull request vLLM #61018 est une perte : 1,5 %. C'est la borne supérieure que l'auteur attribue à son propre changement — environ 0,6 à 0,8 milliseconde gagnée sur un pas moyen de 42 millisecondes, mesurée sur une machine qui ne lui appartient pas, dans un patch qu'il ne peut pas exécuter du tout. La pull request, intitulée « [Model] Qwen4Exp: support batch-sharded sampling (compute_logits_local) » et ouverte le 2026-10-10 par le contributeur kimseunghyun-kr, ajoute trois lignes de code de modèle à deux fichiers afin que l'architecture Qwen4Exp puisse emprunter un chemin d'échantillonnage que vLLM a livré en août. C'est un brouillon. Cela fait 14 lignes de code de modèle plus 57 lignes de test. Et cela vaut quand même la peine d'être lu attentivement, à cause de ce que ces trois lignes contournent : Qwen4Exp est l'architecture à l'intérieur de Qwen3.8-Flash-Next, le modèle à poids ouverts de 125 milliards de paramètres que le fournisseur a publié le 2026-08-24 comme « un aperçu expérimental de l'architecture qui servira de base à Qwen4 » — et un bug à deux chemins dans la moitié purement textuelle de cette architecture est exactement le genre de détail que l'on n'apprend qu'en observant la couche de service plutôt que l'article de lancement.

Pour lever toute ambiguïté sur le cadrage, car cela compte ici : Qwen 4 lui-même n'est pas encore publié. Le fournisseur a nommé quatre niveaux de Qwen 4 — Qwen 4 Max, Flash, Plus et 27B — lors de sa conférence Apsara le 22 septembre 2026, et n'a publié aucun poids, aucun identifiant, aucun prix, aucune longueur de contexte et aucun benchmark pour aucun d'entre eux. Rien de ce qui suit ne constitue une version publiée. Il s'agit d'un état des lieux de ce que l'on sait à ce jour au sujet d'une seule pull request en brouillon, et tout ce qu'il contient qui comporte un chiffre est soit un horodatage que vous pouvez vérifier, soit un chiffre que le contributeur a saisi dans le corps de sa propre PR, soit une valeur lue dans un fichier de configuration de modèle public.

Ce qu'est l'échantillonnage partitionné par lots, en un paragraphe

Le parallélisme tensoriel répartit les poids d'un modèle entre les GPU ; la projection du vocabulaire est le tenseur unique le plus large de la pile, donc chaque rang ne calcule normalement que sa propre tranche du vocabulaire — puis chaque rang effectue un all-gather, de sorte que chacun finit par détenir les logits complets pour chaque requête du lot. L'échantillonnage fragmenté inverse cet échange. Au lieu de répliquer le vocabulaire entre les rangs, il fragmente le lot : chaque rang échantillonne une tranche des requêtes, et les rangs échangent entre eux des tranches de vocabulaire via un all-to-all. La documentation CLI de vLLM décrit simplement l'option — « Chaque rang échantillonne une tranche du lot au lieu que chaque rang échantillonne tout le lot » — et énonce les contraintes : --enable-batch-sharded-sampling vaut False par défaut, nécessite tensor_parallel_size supérieur à 1, au moins tensor_parallel_size séquences maximum, et un max_logprobs non négatif. La dernière ligne de cette documentation est le crochet auquel s'accroche cette pull request : « Les modèles s'inscrivent en implémentant compute_logits_local. »

La fonctionnalité elle-même n'est pas nouvelle. vLLM l'a fusionnée via la PR #50465 — « [Model Runner V2] batch-sharded sample », par Giancarlo Delfin — le 2026-08-24, le jour même où les poids de Qwen3.8-Flash-Next ont été mis en ligne. La motivation était la mémoire et la latence : matérialiser les logits cibles complets coûte de l'ordre de taille du lot × (tokens spéculatifs + 1) × taille du vocabulaire, et le sharding réduit cette allocation d'un facteur égal au degré de parallélisme tensoriel, tout en permettant au travail de top-k et de top-p de l'échantillonneur de s'exécuter en parallèle. C'est l'étape qui ouvre la voie, pas la destination : le texte de la PR lui-même mentionne les logits de draft shardés parmi les travaux futurs.

Pourquoi trois lignes, c’était tout le travail

Voici le défaut réel, et c'est un défaut intéressant car il est invisible depuis l'extérieur du code. L'implémentation Qwen4Exp de vLLM se présente sous la forme de deux classes. Qwen4ExpForConditionalGeneration est le wrapper vision-langage — une tour de vision Qwen3-VL greffée sur le modèle de langage — et Qwen4ExpForCausalLM est le chemin texte uniquement. Le wrapper hérite de compute_logits_local de Qwen3_5ForConditionalGeneration, qui transmet l'appel à language_model.compute_logits_local. Mais la classe de modèle de langage vers laquelle le wrapper pointait n'a jamais défini cette méthode.

Ainsi, les deux chemins se trouvaient dans des états différents. Un déploiement vision-langage de Qwen3.8-Flash-Next pouvait emprunter le chemin partitionné ; un déploiement texte uniquement ne le pouvait pas, car la méthode à laquelle le wrapper déléguait n’existait pas. Le correctif consiste en une seule méthode, identique dans les copies NVIDIA et AMD du fichier de modèle :

• La méthode renvoie self.logits_processor(self.lm_head, hidden_states, skip_gather=True) — le fragment de vocabulaire propre au rang, sans gather ni matérialisation du vocabulaire complet sur aucun rang.

Il suit ce que la PR appelle « le même schéma de 3 lignes que Qwen3.5 et MiniMax M3 », ce sur quoi il vaut la peine de s'arrêter : deux autres familles de modèles dans le même dépôt avaient déjà fait ce choix. Qwen4Exp était simplement celle qui ne l'avait pas fait.

Le fichier de test est l'endroit où l'honnêteté du patch est la plus facile à vérifier, et où ses limites sont les plus faciles à voir. Il fait 57 lignes, il est paramétré sur les modules NVIDIA et AMD, et il ne télécharge pas de modèle. La fonction auxiliaire construit la classe avec object.__new__, remplace nn.Identity pour la tête du modèle de langage, et installe un faux processeur de logits qui renvoie son entrée plus un tout en enregistrant comment il a été appelé. Le premier test vérifie qu'un 4.0 en entrée ressort à 5.0 et que l'appel enregistré portait skip_gather=True. Le second enveloppe le modèle de langage dans la classe de génération conditionnelle et vérifie que la délégation aboutit. C'est un vrai test du câblage et un test de rien d'autre — aucun noyau n'est exercé, aucune frontière de rang n'est franchie, et le nombre de GPU impliqués est nul.

Ces deux faits sont énoncés dans la PR plutôt qu'enfouis. La docstring du fichier de test lui-même qualifie Qwen4Exp de « minuscule double de test uniquement CPU ». La section de validation de l'auteur indique qu'il n'a pas pu importer le modèle du tout sur sa configuration macOS, parce que la transformers dont il disposait n'embarquait pas de Qwen4ExpConfig. L'exécution sur CUDA était encore en attente. Le benchmark de bout en bout — jeu de données agentique MLPerf, 20 sessions simultanées, trois bras de 60 minutes — était encore en attente. Le chemin des logits du drafter MTP est signalé comme non vérifié. LoRA est déjà rejeté en amont par le flag, il est donc hors périmètre plutôt qu'une régression. Il y a aussi une ligne divulguant que le brouillon a été rédigé avec l'aide d'une IA, et le trailer de commit nomme Claude Opus 5.5 comme co-auteur, ce qui est le genre de divulgation qui devrait être normal dans une stack de cette taille et qui, le plus souvent, ne l'est pas.

L’estimation de 1,5 %, et les mesures à côté desquelles elle se trouve.

L’estimation du contributeur est une trace nsys à 16 sessions simultanées sur Qwen3.8-Flash-Next-FP8 avec un parallélisme tensoriel de 8 et un parallélisme d’experts réparti sur huit cartes A100-SXM4-40GB : environ 1,6 milliseconde sur une étape de 42 millisecondes, réduit à environ un tiers de cela, pour un gain de bout en bout de 1,5 à 2 %. Son argument principal est l’arithmétique — 0,6 à 0,8 ms sur 42 ms. Notez ce qui y est rattaché : 42 ms est une valeur de latence inter-jetons, donc une réduction de 1,7 % est une réduction de 1,7 % du temps de génération de jetons, et non une affirmation de débit dans l’absolu.

La comparaison honnête se fait par rapport aux propres chiffres fusionnés de la fonctionnalité parente, car ceux-ci ont été mesurés de bout en bout par une personne disposant du matériel. Dans les exécutions Speed-Bench 2K/2K publiées dans la PR #50465, l’échantillonnage fragmenté par lots a fait passer DeepSeek V4 avec DSpark, à 7 tokens spéculatifs et une concurrence de 64, de 2,62 à 2,66 requêtes par seconde — un gain de débit de 1,53 % — avec une latence médiane entre tokens en baisse de 3,09 % et un temps jusqu’au premier token en hausse de 1,45 %. Sur MiniMax M3 avec DSpark à 8 tokens spéculatifs, le débit de requêtes a augmenté de 5,38 % et le TPOT médian a chuté de 8,33 %, passant de 15,61 à 14,31 millisecondes. Et le même plan documente les cas où cela n’aide pas : à une concurrence de 4 à 16, les exécutions se sont révélées stables à légèrement négatives, la branche à concurrence 16 étant en baisse de 0,54 % en débit et de 1,89 % en longueur d’acceptation.

C'est ce schéma qu'il faut retenir. L'échantillonnage shardé est rentable lorsque l'échantillonnage est lourd et que le lot est large — forte concurrence, nombreux tokens spéculatifs, top-k et top-p qui font un vrai travail — et il coûte un peu lorsque le lot est assez petit pour que l'all-to-all ne soit que du surcoût pur. Une estimation de 1,5 % pour un modèle qui s'y rallie est cohérente avec cela, et non en contradiction : les chiffres de 5,38 % et 8,33 % concernent des modèles différents avec des budgets spéculatifs différents, et le modèle de cette PR a sa propre configuration, son propre vocabulaire de 248 320 tokens et son propre chemin de décodage spéculatif.

Rien de tout cela n'est audité. Les chiffres de la PR parente proviennent des exécutions appariées d'un seul contributeur sur un seul nœud ; les chiffres du smoke-test ici sont une trace sur du matériel que l'auteur ne possède pas, issue d'une révision du correctif qu'il dit n'avoir été mesurée que sur 16 sessions. Une mesure réalisée par un seul contributeur avec une seule configuration est un signal utile quant à la direction, et une base médiocre pour un plan de capacité. Si le sujet mérite d'être traité, c'est pour la direction, pas pour la décimale.

Ce que la grappe de correctifs environnante dit à propos de Qwen4Exp

Une PR brouillon ne ferait pas une histoire. L’histoire, c’est que Qwen4Exp est devenu une cible de serving durable dans la semaine où cela a été intégré, et le plus petit patch de ce groupe est celui qui rend le motif lisible. Au cours des sept jours précédant le 2026-10-10, vLLM a intégré, de la part du même contributeur et d’autres : un chemin principal de cache KV FP8 pour l’attention sparse sur Ampere, avec une capacité KV augmentée de 1,83× sur huit A100 et de 1,87× sur quatre RTX 3090, et environ 2,7× plus de requêtes à concurrence 16, au prix d’un TPOT de décodage mono-flux supérieur d’environ 6 % ; un correctif pour le padding W4A4 MoE en tensor-parallel 1 et parallélisme d’experts ; un chemin AMD qui effectue un repli pour les opérations AITER FP8 MoE non prises en charge et sert en fp16 ; un correctif qui fait passer l’état de convolution courte PLE à travers le mode align ; et un noyau de décodage qui déballe les octets e4m3 quatre à la fois par registre sur sm_80. L’un d’eux, un recalibrage du plan QSA LL-GEMM fusionné M=4 pour H200, a été fusionné dans main le 2026-10-09.

Lisez cette liste dans son ensemble et elle dit quelque chose de concret. L’architecture Qwen4Exp — celle que le fournisseur n’a pas publiée — est en cours d’optimisation pour Ampere, Hopper, ROCm et le repli fp16 simultanément, dans un projet qui assure une prise en charge dès le premier jour pour des modèles que les gens peuvent réellement télécharger. La raison n’a rien de mystérieux : Qwen3.8-Flash-Next est un modèle réel, téléchargeable et très utilisé, et il repose sur l’architecture que Qwen 4 utilisera. Que les poids de Qwen 4 finissent un jour par ressembler à cela est inconnu et le fournisseur n’a rien dit, mais le périmètre de service s’élargit publiquement, et c’est une information vérifiable, contrairement à une fenêtre d’octobre à novembre qui n’est qu’une rumeur.

Une partie de la forme architecturale est publique elle aussi, pour quiconque lit la configuration plutôt que l'annonce. La configuration de Qwen3.8-Flash-Next indique un vocabulaire de 248 320 tokens réparti sur 48 couches, 512 experts avec 10 experts routés plus un expert partagé actifs par token, pour une largeur intermédiaire d'expert de 640, une taille cachée de 2 560, et un contexte natif de 262 144 tokens décrit comme extensible à un million. C'est un hybride : la liste des types de couches alterne trois blocs d'attention linéaire avec un bloc d'attention complète, et les blocs d'attention complète empruntent le chemin d'attention parcimonieuse avec un indexeur à une seule tête qui compresse les clés d'un facteur quatre et conserve un budget de 2 048 positions. Il y a une table d'embeddings par couche à la couche 2, un embedding de n-grammes avec un vocabulaire de 20 millions d'entrées — c'est la table de 47,7 GiB que d'autres patchs de ce cluster sont en train de préparer en staging côté hôte — et une tête MTP à une couche pour le décodage spéculatif. Le résumé de la fiche du modèle est lui-même « 125B avec 6B activés, plus 51B d'embedding de n-grammes et 4B de MTP. » Un vocabulaire de 248 320 entrées est précisément pourquoi la projection des logits mérite d'être fragmentée en premier lieu.

Ce que cela ne change pas pour vous

Il vaut la peine d’être précis, car un ensemble de correctifs aussi dense peut se lire comme un lancement. Rien de ce qui précède n’est fusionné, et l’un de ses éléments — le travail sur le cache KV FP8 pour Ampere — n’est explicitement pas validé en CI, car la CI de vLLM ne dispose d’aucun A100. Il n’existe aujourd’hui aucune version publiée de vLLM que vous pouvez installer qui propose l’échantillonnage shardé de Qwen4Exp en opt-in. Il n’existe aucun benchmark indépendant du comportement de service de Qwen3.8-Flash-Next sous l’une quelconque de ces modifications ; tous les chiffres cités ci-dessus proviennent des corps des PR, ce qui en fait des chiffres rapportés par les contributeurs et non audités, au sens précis où aucun tiers n’a reproduit l’exécution. Et le chiffre phare de la PR à l’origine de cet article est de 1,5 %, ce qui est un gain réel dans une pile de service et non une raison de changer le choix d’un modèle.

Ce qui changerait une décision, c’est une campagne de service complète et auditée, et cela n’existe pas encore. Les mesures de cadencement qui existent pour Qwen3.8-Flash-Next sont totalement étrangères à ces correctifs : le modèle obtient un Intelligence Index de 40 sur Artificial Analysis, bien au-dessus de la médiane de 18 pour les modèles à poids ouverts de taille similaire, et ce chiffre est indépendant de tout ce qui est abordé ici.

Ce que vous pouvez appeler aujourd'hui, et l'angle de routage

C'est ici que les choses deviennent concrètes pour quiconque a lu jusqu'ici et souhaite utiliser un modèle hébergé plutôt que d'en instrumenter un. Qwen3.8-Flash-Next ne figure pas au catalogue d'OrcaRouter — il ne fait pas partie des 205 modèles que nous routons, et aucun point de terminaison hébergé n'est disponible pour lui ici. Mais l'homologue de production qu'il préfigure est : qwen/qwen3.8-flash, la version officielle de Qwen3.8-Flash, que la fiche modèle du fournisseur elle-même décrit comme comportant davantage de fonctionnalités que l'aperçu, notamment un contexte d'un million de jetons par défaut et des outils intégrés, est disponible à 0,15 $ par million de jetons d'entrée et 0,47 $ par million de jetons de sortie, répercutée au prix catalogue du fournisseur, sans marge ajoutée. Pour donner un ordre de grandeur au sein de la même famille, qwen/qwen3.8-27b coûte 0,33 $ et 2,40 $, et qwen/qwen3.8-max 2,00 $ et 6,00 $ — tous accessibles avec une seule clé.

Deux raisons comptent plus que d’habitude pour un article sur une architecture non publiée. La première est le coût de bascule. Si vous voulez calibrer ce qu’un modèle à attention éparse donne sur votre trafic avant même que Qwen 4 n’existe, la comparaison à mener est avec qwen/qwen3.8-flash au prix catalogue — et passer par un routeur signifie que le modèle que vous mesurez et celui vers lequel vous pourriez basculer se trouvent derrière le même endpoint, le même SDK et la même clé, sans second contrat à signer. La seconde est que chaque changement de serving dans ce lot de correctifs cible vLLM auto-hébergé. Si vous n’exploitez pas huit A100, la capacité KV de 1,83× et le gain d’échantillonnage de 1,5 % sont des choses dont vous lisez des retours, pas des choses que vous obtenez. Un endpoint routé est la version de tout cela qui arrive sans étape de build : le basculement automatique en cas de dégradation d’un fournisseur, et un DSL de routage qui vous permet de placer un appel hébergé à côté d’un appel auto-hébergé dans un seul endpoint lorsque vous disposez bien de votre propre matériel à mesurer.

La seule chose à ne pas faire est de lire cet article comme une raison d’attendre Qwen 4. Il n’y a pas de date. Il n’y a pas de prix. Il n’y a pas de nombre de poids pour la vraie chose — les chiffres ci-dessus décrivent la version d’aperçu, pas le produit. Ce qui existe, c’est une pile de service préparée en public pour une architecture qui, pour l’instant, n’est téléchargeable que sous forme d’aperçu.

La version courte

Trois lignes qui comblent un écart entre les chemins texte uniquement et vision-langage d'un seul fichier de modèle ne constituent pas, en soi, une nouvelle. C'est le genre de correctif qui serait enfoui dans un commit de fusion si quelqu'un avait le temps de l'examiner, et il pourrait très bien être intégré à une modification plus vaste ou fermé purement et simplement — les propres directives d'agent du bot vLLM, citées sur la PR, demandent aux contributeurs assistés par IA de fermer leur travail s'il manque d'un bénéfice significatif, et 1,5 % est un chiffre qui invite à se poser la question. Ce qui le rend digne de votre attention, c'est ce qu'il documente : une table de n-grammes de 20 millions d'entrées, un MoE à 512 experts avec dix experts actifs par token, un hybride d'attention linéaire et d'attention parcimonieuse compressée, une tête spéculative — le tout étant ajusté sur NVIDIA et AMD, d'Ampere à Hopper, avant même que le produit qui le portera existe. Si le périmètre de service de Qwen4 vous intéresse, c'est dans les corps de PR que vivent actuellement ses spécifications réelles. Si vous voulez appeler un modèle aujourd'hui, Qwen3.8-Flash est celui qui est réellement là.

Une API pour plus de 200 modèles, basculement automatique, DSL de routage. Explorez le catalogue de modèles OrcaRouter