Fuite de Qwen 4 : SGLang fragmente le prefill de Qwen4Exp pour un TTFT 18 % plus rapide et un GiB récupéré par GPU

Une pull request ouverte dans le dépôt SGLang à 03:47 UTC ce matin, le 8 octobre 2026, promet quelque chose qu'aucune annonce de Qwen 4 n'a encore produit : un chiffre. Elle est intitulée feat(qwen4-exp): activer le parallélisme de séquence LayerNorm pour GR et PLE, et sur quatre GPU H20 exécutant le checkpoint à poids ouverts Qwen3.8-Flash-Next en FP8, son auteur rapporte des gains de temps jusqu'au premier token de 17,7–18,4 % à 32K d'entrée et de 14,6–14,7 % à 235K d'entrée, environ un gigaoctet de mémoire de pointe restitué par GPU, et jusqu'à 22 % de débit d'entrée en plus. Qwen 4 lui-même — la famille que le fournisseur a nommée mais n'a pas livrée à la conférence Apsara de Hangzhou le 22 septembre 2026 — n'est toujours pas publié, sans poids, sans identifiant ni prix. Le seul modèle qui instancie aujourd'hui l'architecture Qwen4Exp est Qwen3.8-Flash-Next, publié le 26 août 2026, et son homologue géré Qwen3.8-Flash est la version qu'un appelant d'API peut réellement atteindre. Lisez donc ce qui suit pour ce que c'est exactement : les mesures appariées d'un ingénieur, attachées à une pull request ouverte, à l'état de brouillon et non fusionnée, concernant l'enveloppe de service d'une famille de modèles qui n'existe pas encore.

D'abord le sourcing, car il s'agit d'un article sur une fuite et la distinction a une réelle importance. Le signal est sgl-project/sglang#43048, ouvert le 2026-10-08 à 03:47 UTC par le compte GitHub shiyang814-cpu, dernière modification le 03:55 UTC, et toujours marqué brouillon, sans aucune revue d'approbation enregistrée et sans fusion. Il modifie six fichiers — deux fichiers de test, le fichier du modèle Qwen4Exp, le module LayerNorm-SP, une fabrique de limites de couches et un hook de groupe d'arguments — pour +345 et −50 lignes. Chaque chiffre de performance ci-dessous provient de la description de la PR, est la mesure OFF/ON appariée de l'auteur lui-même, et n'a été reproduit par personne. Trois exécutions de CI sur la révision à la tête de la branche sont marquées comme en échec. Rien ici n'est une fonctionnalité livrée.

Ce que la pull request change réellement

Le parallélisme de séquence n'est pas un changement de modèle et ce n'est pas une nouvelle capacité. C'est un recâblage de l'endroit où quelques couches effectuent leurs calculs. Sa lignée remonte au parallélisme de séquence de style Megatron — l'astuce de arXiv:2205.05198 — et SGLang l'implémente déjà : la docstring du module explique lui-même le mécanisme qu'il réutilise, à savoir qu'en parallélisme tensoriel pur, un all_reduce parallèle sur les lignes est algébriquement un reduce_scatter suivi d'un all_gather. Comme ces deux collectifs déplacent exactement le même nombre d'octets que le seul all_reduce qu'ils remplacent, scinder l'opération de cette façon ne coûte aucun volume de communication supplémentaire. Ce que cela apporte, c'est la liberté de laisser les régions de normalisation et de résidu s'exécuter sur des activations découpées par séquence — chaque rang de parallélisme tensoriel détenant un 1/tpième des lignes de tokens — ce qui réduit la mémoire d'activation transitoire que le prefill à long contexte doit maintenir en vie.

Ce que cette pull request particulière fait, c'est étendre ce chemin existant depuis l'architecture sur laquelle il a été validé vers l'architecture Qwen4Exp. Pendant le prefill, les activations Gated Residual et Per-Layer Embedding restent sharded selon la dimension des tokens à travers le groupe TP. Avant l'attention, avant GDN, avant QSA et avant l'exécution du bloc Mixture-of-Experts, les lignes de tokens complètes sont rassemblées par all-gather, le calcul tensor-parallel existant sur lignes complètes s'exécute inchangé derrière un fallback partagé, puis un reduce-scatter additionne les contributions partielles et restaure le shard de chaque rank. Le decode n'emprunte jamais le nouveau chemin du tout. La fonctionnalité est accessible via l'option qui existe déjà — --enable-layernorm-sp — sans indicateur spécifique à Qwen4Exp, et en l'absence de l'indicateur, le code se comporte exactement comme avant.

Pourquoi Qwen4Exp est l’architecture qui a besoin de cela

La raison pour laquelle cela importe spécifiquement pour Qwen4Exp, et pas de la même manière pour tous les modèles, tient à la conception même de l'architecture. Qwen3.8-Flash-Next applique des projections Gated Residual à toutes les lignes de tokens de chaque couche de décodeur — la configuration déclare quatre flux résiduels et un rang de goulot d'étranglement de 320 sur 48 couches — et Per-Layer Embedding ajoute par-dessus une seconde projection répliquée, ligne de token par ligne de token. En parallélisme tensoriel, ces deux opérations sont dupliquées à l'identique sur chaque rang, car elles ne portent aucune matrice de poids partitionnée en TP qui leur soit propre et qui forcerait une séparation. Partitionner leur dimension de tokens supprime directement le travail répliqué et, comme le formule la section motivant la PR, cela se fait tout en préservant la disposition existante du parallélisme tensoriel et la sémantique de réduction de l'attention, du GDN/QSA et du MoE — ce qui est précisément ce qui rend ce changement sûr plutôt qu'astucieux.

Il vaut la peine de dire clairement ce que cela signifie pour le lecteur. Ce qui est intéressant avec cette PR, ce n’est pas que SGLang devienne plus rapide. C’est que l’architecture Qwen4 comporte des coûts par couche qui augmentent avec le nombre de tokensplutôt qu’avec le nombre de paramètres, et ce sont ces coûts qui pèsent lors des préremplissages longs. C’est une empreinte de conception, et c’est le genre de chose qu’une fiche technique ne mentionne jamais.

Les deltas mesurés

Le benchmark de l’auteur fixe une configuration et bascule le flag : quatre GPU NVIDIA H20, Qwen3.8-Flash-Next-FP8, tensor parallel 4 et expert parallel 4, chunked prefill size 8192, backends FlashInfer de prefill et decode pour attention linéaire, la même configuration serveur pour OFF et ON, des redémarrages de service en alternance OFF → ON → OFF → ON, et des entrées de jetons fixes avec des requêtes de préchauffage. Chaque figure ci-dessous provient de cette configuration et n’a pas été auditée :

• Entrée 32K, taille de lot 1 — TTFT amélioré de 17,72–18,36 %, latence de bout en bout d'environ 16 %, débit d'entrée d'environ 20 %

• Entrée de 235 K, taille de lot 1 — TTFT amélioré de 14,63–14,71 %, latence de bout en bout d'environ 14 %, débit d'entrée d'environ 17 %

• Entrée de 32 K, taille de lot 4 — TTFT amélioré de 18,74 %, latence de bout en bout de 18,14 %, débit d'entrée de 22,14 %

• Mémoire de pointe — réduite d'environ 1,0 Gio par GPU

• Décodage, taille de lot 1 — temps par token de sortie pratiquement inchangé

C'est la dernière ligne qu'il faut lire deux fois, et l'auteur explique sans détour pourquoi : cette optimisation n'est activée que pour le prefill, si bien que le décodage en flux unique n'en tire rien. L'amélioration du temps par token en lot de 4, là où elle se manifeste, reflète une réduction des délais d'ordonnancement due à des prefills longs exécutés en parallèle, et non un quelconque noyau de décodage plus rapide. Si vous espériez qu'il s'agissait d'une histoire de débit, ce n'est pas le cas — c'est une histoire de latence jusqu'au premier token et de mémoire, et ce sont là les deux contraintes qui déterminent si une requête de 235K tokens peut être servie tout court.

Le bug de mise en page qu’ils ont dû corriger en premier

La partie la plus instructive de la pull request n’est pas le tableau des gains de vitesse. C’est la section sur l’agencement physique des lignes PLE, car elle montre ce que la stack de service Qwen4Exp fait encore de travers.

Per-Layer Embedding opère sur un bucket physique fixe de graphe CUDA, tandis que seul un préfixe des lignes de ce bucket peut contenir de vrais tokens. Le padding doit donc être appliqué avant que la séquence soit shardée, et non après. Dans le dernier chunk d'une requête de 235K tokens, les nombres de l'auteur sont 5 624 tokens traités à l'intérieur d'un bucket physique de 8 192 lignes en TP 4, et la seule disposition correcte est : le rang 0 contient 2 048 lignes valides, le rang 1 contient 2 048 lignes valides, le rang 2 contient 1 528 lignes valides plus 520 lignes de padding, et le rang 3 contient 2 048 lignes de padding. Le sharding préalable des 5 624 lignes traitées — l'implémentation évidente — insère du padding entre des plages valides globalement contiguës et corrompt le résultat. L'auteur rapporte qu'un vrai test OFF/ON de 235K n'a produit une sortie gloutonne identique de 16 tokens qu'après que cet agencement ait été corrigé.

C'est un petit détail aux grandes implications. Le chemin PLE dans SGLang a été ajouté suffisamment récemment pour qu'un bug d'ordonnancement des tokens de cette forme soit encore atteignable, et la personne qui l'a trouvé écrivait l'extension sequence-parallel. La prise en charge du serving dès le jour zéro pour cette architecture n'est pas terminée ; elle est activement construite, en public, par des contributeurs, un layout à la fois.

Ce que cela vous coûte : les contraintes

Un indicateur qui n'aide que certains déploiements n'est utile que si l'on sait lesquels. La PR énonce explicitement ses exigences, et les configurations en dehors de celles-ci échouent lors de la validation des arguments plutôt que de se dégrader silencieusement :

• La taille du parallélisme tensoriel doit être supérieure à 1 — un déploiement mono-GPU n’apporte rien, car il n’y a aucun rang sur lequel répartir

• La taille parallèle expert doit être égale à la taille parallèle tenseur

• La taille du parallélisme de pipeline doit être égale à 1

• L'attention en parallélisme de données doit être désactivée

• Le décodage spéculatif doit être désactivé

La dernière contrainte est celle qui cache une véritable décision. Pour un modèle sparse qui active environ 6B paramètres par token, le décodage spéculatif est l'un des rares leviers qui accélère le décodage, et cette fonctionnalité désactive explicitement ce levier en échange d'un gain de prefill. Si votre charge de travail se compose de longs prompts et de sorties courtes — analyse de documents et de bases de code, résumé vidéo, grand contexte lu une seule fois —, le compromis est clairement avantageux. Si votre charge de travail est un prompt court et une longue génération, vous abandonnez ce qui vous aidait et achetez un chiffre qui ne s'applique pas à vous. L'exigence que le parallélisme expert soit égal au parallélisme tenseur est l'autre point à remarquer : cela signifie que la géométrie de partitionnement du MoE doit correspondre exactement à la géométrie du TP, ce qui exclut plusieurs dispositions multi-nœuds par ailleurs raisonnables.

Ce que cela dit sur la chronologie de Qwen 4

Lisez le diff autrement et vous obtenez un calendrier. Le module LayerNorm-SP de SGLang sur la branche principale porte aujourd'hui une liste d'autorisation explicite d'architectures pour lesquelles la fonctionnalité a été validée, et à l'heure où j'écris ces lignes, cette liste d'autorisation contient exactement une entrée, Qwen3ForCausalLM — toute autre architecture est rejetée à la construction si vous passez le drapeau. Ajouter Qwen4Exp à ce chemin n'est donc pas un simple ajustement apporté à une abstraction mature ; c'est la première fois que l'architecture Qwen4 est intégrée à une optimisation qui la précède de plusieurs générations.

Confrontez cela aux informations publiques et le tableau est cohérent. L'éditeur a annoncé le 2026-09-22 que Qwen 4 est en cours d'entraînement et a dévoilé quatre noms de gamme — Qwen 4 Max, Qwen 4 Flash, Qwen 4 Plus et Qwen 4 27B — sans y associer la moindre spécification. L'aperçu à poids ouverts qui partage l'architecture, Qwen3.8-Flash-Next, est téléchargeable depuis le 2026-08-26. Ce qui se passe dans les trois semaines qui ont suivi correspond exactement à ce que l'on attend entre « en cours d'entraînement » et « lancement » : des auteurs de moteurs qui rodent le runtime pour que la prise en charge dès le premier jour soit réelle et non nominale. Une pull request qui fait fonctionner une optimisation de serving sur l'architecture, ouverte le matin du 2026-10-08 et encore à l'état de brouillon, est un meilleur indicateur de la proximité de Qwen 4 avec un état servable que n'importe quelle date avancée par qui que ce soit. Ce n'est d'ailleurs catégoriquement pas une date de sortie — le flag est désactivé par défaut, la modification n'est pas fusionnée, et le modèle qu'elle évalue est l'aperçu, pas Qwen 4.

Ce que vous pouvez appeler aujourd'hui.

Rien de tout cela ne change ce qui est réellement disponible cet après-midi. Qwen3.8-Flash-Next existe bel et bien, ses poids sont sur Hugging Face, et vous pouvez l'auto-héberger — mais il ne figure pas dans notre catalogue, et nous ne prétendrons pas le contraire. L'offre que nous servons, elle, est qwen/qwen3.8-flash, le frère géré qui tourne sur la même architecture Qwen4-preview, avec une fenêtre de contexte d'1 million de tokens et des entrées texte, image et vidéo, au prix de 0,15 $ par million de tokens d'entrée, 0,47 $ par million de tokens de sortie et 0,0184 $ par million de lectures de cache. C'est un prix catalogue répercuté à 0 % de marge : ainsi, lorsque le fournisseur le modifie, le montant de votre facture change le jour même, et non au moment où un intermédiaire republie un tableau.

Il existe une seconde raison, moins évidente, de s'intéresser ici à une couche de routage. Tout, dans cet article, porte sur un aperçu non éprouvé et un correctif à l'état de brouillon — le genre de chose que l'on veut tester sans parier un chemin de production dessus. C'est à cela que sert le basculement de secours : placez l'aperçu derrière la même clé que le modèle auquel vous faites déjà confiance, observez son comportement sur votre trafic, et laissez la requête basculer vers la route éprouvée lorsqu'un fournisseur vacille ou que le point de terminaison est absent. Une seule API pour plus de 200 modèles, un seul jeu d'identifiants, aucun second contrat à signer pour découvrir si une nouvelle architecture mérite votre attention.

Deux choses à surveiller à partir d'ici, et nous ne pouvons prédire ni l'une ni l'autre. La première est de savoir si ce patch sera fusionné tout court : il s'agit d'un brouillon avec trois exécutions CI en échec sur une modification de six fichiers, provenant d'un compte de contributeur sans historique préalable dans le dépôt, et la fluidité du travail sur la disposition des lignes PLE suggère que l'auteur itère encore. La seconde est de savoir si la liste d'autorisation s'élargit — si Qwen4Exp rejoint Qwen3ForCausalLM en tant qu'architecture validée, alors cela cesse d'être une fuite et devient la manière par défaut dont un modèle de la famille Qwen4 est servi sur un contexte long. Jusqu'à ce que l'une de ces choses se produise, considérez les 18 % comme une promesse sur la direction que prend le runtime, et non comme un nombre que vous pouvez louer.