Fuite de Qwen 4 : la PR Host-Staging de SGLang montre comment la table PLE de 47,7 GiB tient sur un seul GPU

Le nombre qui déterminera si Qwen 4 est un modèle que vous pouvez servir vous-même n'est pas son nombre de paramètres. C'est 47,7 Gio — la taille de la table d'embeddings de n-grammes qui accompagne l'architecture Qwen4, distincte des poids, et qui doit bien résider quelque part pendant que le modèle génère. Une pull request ouverte dans le dépôt SGLang le 18 septembre 2026, intitulée [Qwen4-Exp] Ajouter une mise en attente côté hôte pour le PLE adossé à des fichiers, vise à empêcher que cette table dicte la quantité de RAM dont une machine a besoin avant même de pouvoir tourner. Qwen 4 n'est toujours pas publié : pas de fiche modèle, pas de poids, pas d'entrée au catalogue, pas de date. Le seul modèle livré qui instancie cette architecture est Qwen3.8-Flash-Next, l'aperçu à poids ouverts publié le 26 août 2026, dont la configuration déclare model_type=qwen4_exp — la même chaîne qui donne son nom à la pull request. Son pendant de production Qwen3.8-Flash est la version qu'un appelant d'API peut réellement atteindre aujourd'hui. Tout ce qui est dit ici à propos de Qwen 4 relève de l'inférence à partir de cet aperçu et du code du moteur ; la pull request est ouverte et non fusionnée, alors lisez tout cela comme un signal, et non comme une capacité déjà livrée.

Ce qu'est réellement le signal

La pull request sgl-project/sglang#40235 n'est pas un lancement et n'est pas fusionnée. Elle repose sur un seul commit, ouverte par le contributeur Dev-Jahn, fusionnant une branche appelée task/ple-host-staged dans la branche principale de SGLang. Neuf propriétaires de code ont été sollicités pour une revue et tous apparaissent comme en attente, donc au moins une revue approbatrice sépare ceci de la branche principale. Trois jobs CI — le test de PR de base, le test de PR supplémentaire et l'exécution AMD ROCm — échouent sur le commit ouvert. C'est la situation normale d'un grand changement de moteur en cours, et c'est aussi pourquoi la partie intéressante de cette PR n'est pas de savoir si elle sera fusionnée, mais ce que son auteur a dû mesurer pour la défendre. La description comporte environ 1 400 lignes ajoutées, y compris les tests, et un tableau de benchmark qui constitue les données publiques les plus concrètes que quiconque ait publiées sur l'exécution de cette architecture sur un seul GPU.

Pourquoi la table est toute l'histoire

Les embeddings par couche sont la bizarrerie structurelle de cette génération. Là où un modèle normal place un seul embedding de token à l’entrée, la conception de Qwen4 embarque une grande table de n-grammes — bigrammes et trigrammes, hachés dans un vocabulaire bien plus vaste que celui du tokenizer — et alimente à partir d’elle des recherches d’embeddings par couche dans toute la pile. Le matériel d’aperçu d’Alibaba lui-même décrit le composant n-grammes comme représentant des dizaines de milliards de paramètres en plus du corps MoE de 125B paramètres ; les analyses communautaires du checkpoint publié situent le fichier de table à 47,7 Gio. Ces chiffres proviennent de sources du fournisseur et de la communauté plutôt que d’une reproduction indépendante, et la relation exacte entre la table de l’aperçu et ce que Qwen 4 livre réellement est inconnue.

Ce qui ne fait aucun doute, c'est la conséquence d'ingénierie. Une table latérale de 47,7 Gio qui doit être consultée à chaque étape de décodage n'est pas quelque chose que l'on peut discrètement reléguer dans un coin de la VRAM. Sur une carte de 96 Go, elle entre directement en concurrence avec le cache KV ; sur des cartes plus petites, elle ne rentre tout simplement pas. C'est pourquoi SGLang, qui a mis en place un support dès le premier jour pour la version préliminaire fin août, a passé les trois semaines suivantes à produire une pull request après l'autre à propos de cette seule structure de données plutôt que du modèle qui l'entoure.

Qu'est-ce qui était cassé avant cette PR ?

SGLang disposait déjà de deux façons de conserver la table, et toutes deux présentaient un côté dur.

• Pinnedgarde toute la table dans la RAM de l'hôte et la lit depuis là. Ça fonctionne, c'est rapide, et cela rend l'exigence de mémoire de l'hôte absolue — il n'en existe pas de version plus petite.

• File-backed, ajouté plus tôt dans une pull request distincte, conserve la table dans un fichier creux et permet au noyau gather de lire directement le mappage, de sorte que le cache de pages du système d'exploitation décide de la part qui en reste résidente. Le hic est matériel : ce chemin de lecture directe exige que le GPU signale cudaDevAttrPageableMemoryAccessUsesHostPageTables — la capacité que le texte même de la PR désigne comme « la classe GB10 ». Sur un GPU qui en est dépourvu, le backend fichier est purement et simplement refusé, et pinned est la seule option qui reste.

L’écart que cela crée n’a rien de théorique. Un rapport distinct déposé contre le même chemin de code documente un utilisateur sur deux RTX 3090 dont la part par rang de la table s’élevait à 23,84 GiB pour 23,56 GiB de mémoire utilisable — soit 0,28 GiB de moins, avec 188 GiB de RAM hôte qui restaient libres. Dans cette configuration, le backend de fichiers a été rejeté par la vérification matérielle, et l’option ordinaire de délestage CPU lève une erreur lorsqu’elle est combinée à l’option de délestage PLE. Se retrouver à court de trois cents mégaoctets alors que cent quatre-vingts gigaoctets sont disponibles est précisément le type de problème que cette pull request a pour but d’éliminer.

Quels changements de staging d'hôte

Le mécanisme ajouté par la PR est une couche intermédiaire entre le fichier et le périphérique. Au lieu de demander au GPU de déréférencer des pages hôtes, un composant côté CPU lit les lignes dont il a besoin via le mappage existant du loader et conseille au noyau de charger ces pages à l'avance ; une variable d'environnement, SGLANG_QWEN4_PLE_FILE_PREFETCH, désactive ce conseil si vous souhaitez mesurer sans lui. Chaque couche PLE reçoit alors deux tampons épinglés de 8 192 lignes — environ 1,25 Mio chacun en FP8 — et un worker. Les lignes sont rassemblées dans un tampon pendant que l'autre est copié vers le périphérique, de sorte que la collecte et le transfert se chevauchent au lieu de se sérialiser. Les identifiants de n-grammes sont hachés sur l'hôte plutôt que sur le périphérique. Le rejeu de graphe bénéficie d'un appel de préparation avant chaque rejeu, et le thread de lancement attend l'étape précédente.

Ce dernier détail, c’est le coût, et la PR l’annonce sans détour : environ 0,5 à 1 milliseconde ajoutée par étape de décodage par rapport au chemin épinglé. Tout le reste est le gain. Mesuré sur une seule RTX PRO 6000 Blackwell avec 96 Go, un hôte AMD EPYC avec 377 Gio de RAM, CUDA 13.2, à l’aide des checkpoints publics FP8 et NVFP4 de Qwen3.8-Flash-Next :

• Cache de pages de l'hôte, FP8 TP4/EP4 — 71 Go épinglés et sans plafond, contre 49 Go avec un plafond de 64 Go, 15 Go à 32 Go et 6 Go avec un plafond de 24 Go

• Latence de décodage, mêmes exécutions — 8,62 ms par token en concurrence 1 épinglée, contre 9,16 / 9,20 / 9,12 ms sur les trois exécutions de fichier plafonnées

• Concurrence 16 — 16,54 ms en mode épinglé contre 17,62 / 17,85 / 17,37 ms en mode plafonné, soit une baisse de 893 jetons par seconde à 827–840

• Débit de préremplissage — 620 tokens par seconde à 8k épinglé contre 624 / 630 / 631 plafonnés ; à 32k, 1 347 contre 1 358 / 1 359 / 1 361

• NVFP4 TP2 — 69 GB épinglés contre 24 GB avec le backend fichier à un plafond de 32 GB, à 8,87 ms contre 9,18 ms

• NVFP4 mono-GPU — 69 Go épinglés contre 51 Go avec un plafond de 64 Go, à 6,44 ms contre 6,73 ms

• L'alternative qu'il surpasse — la lecture du même fichier via la gestion de la mémoire hôte sur ce GPU a donné 10,8 ms à une concurrence de 1 et 46,5 ms à une concurrence de 16, ce que la PR décrit comme 2,8× la latence pinned à cette concurrence

Le volet exactitude est déclaré sans problème. La sortie gloutonne déterministe sur huit invites de 256 jetons était identique jeton pour jeton entre les chemins pinned et file sur FP8 TP4, et GSM8K est ressorti à 97,6 % pour pinned contre 98,0 % pour file au plafond de 64 Go — un écart de six questions que l'auteur attribue à une variation d'une exécution à l'autre plutôt qu'au chemin d'offload. Tous ces chiffres sont ceux de l'auteur de la pull request, mesurés une seule fois, sur une seule machine, et personne ne les a reproduits.

Les coûts que la PR admet

Une lecture équitable de cette pull request inclut ce qu’elle refuse de faire. Plusieurs modes d’exécution sont rejetés au moment de la construction plutôt que silencieusement dégradés, et chaque rejet désigne le backend épinglé comme solution de repli : les graphes CUDA de prefill, l’attention data-parallel, le chemin de multiplexage prefill-decode, le chevauchement à deux lots, les graphes de décodage DLLM et les graphes de vérification ragged compacts sont tous exclus. Tout aussi important, elle n’ajoute aucun nouveau flag et aucune nouvelle option exposée à l’utilisateur — le chemin de staging est ce que le backend de fichiers fait sur du matériel qui ne pouvait auparavant pas l’utiliser du tout. Et l’exécution d’exactitude comporte une réserve que l’auteur signale volontiers : les exécutions plafonnées n’ont jamais contenu la table entière, car la table fait 47,7 Gio et les plafonds descendent jusqu’à 24 Go, donc une charge de travail avec un motif d’accès réellement plat et imprévisible sur toute la table n’est pas ce qui a été mesuré.

Pourquoi cela est important spécifiquement pour Qwen 4

Si l’on fait abstraction des détails du moteur, le schéma devient lisible. Alibaba a publié un aperçu d’architecture le 26 août, accompagné d’instructions destinées à la communauté open source pour préparer les runtimes, la quantification et les moteurs d’inférence avant la sortie de la gamme complète. SGLang l’a fait, puis a passé trois semaines à soumettre des pull requests concernant le seul composant qui rend l’architecture difficile à déployer. Lu comme une prévision, c’est une affirmation sur ce que Qwen 4 exigera de votre matériel, et non sur ce qu’il peut accomplir sur un benchmark.

Cela précise aussi la question du calendrier. Qwen 4 n'est pas encore sorti, et les spéculations de septembre à son sujet renvoient à la conférence Apsara d'Alibaba, du 22 au 24 septembre à Hangzhou — le lieu où les générations précédentes de Qwen ont été annoncées. Rien de tout cela n'est confirmé, et le schéma du dernier cycle d'aperçu montre qu'un aperçu de l'architecture précède la famille complète de plusieurs mois plutôt que de quelques semaines. Une pull request ouverte trois jours avant cette conférence est suggestive, et rien de plus.

Le résumé honnête de ce que cela laisse au lecteur : Qwen 4 n'existe pas, Qwen3.8-Flash-Next existe, et le second vous dit ce que le premier vous coûtera à faire tourner. Si l'empreinte effective de la table de 47,7 Gio continue de se réduire — et trois semaines de pull requests indiquent qu'on y travaille dur —, alors le seuil de déploiement de la famille Qwen 4 est plus bas que ne le laissait entendre la semaine de lancement de la preview.

Ce que vous pouvez réellement faire avec ceci aujourd'hui

Rien dans cette pull request n'est disponible sur main, et le modèle qu'elle cible n'est pas quelque chose que vous pouvez appeler via une API. Le checkpoint à poids ouverts Qwen3.8-Flash-Next relève de l'auto-hébergement : vous récupérez les poids, vous les servez vous-même, et le chemin PLE adossé à des fichiers est le sujet de votre lecture. Il n'est pas routé ici. Ce qui est routé est la variante de production — Qwen3.8-Flash, accessible en tant que qwen/qwen3.8-flash à 0,15 $ par million de tokens d'entrée et 0,47 $ par million de tokens de sortie, avec un contexte de 1 M de tokens et une entrée texte, image et vidéo — et le plus grand Qwen3.8-Max à 2,00 $ et 6,00 $.

Cette distinction est la plus utile pour un lecteur qui doit décider quoi faire cette semaine. L'aperçu, c'est la recherche que vous menez vous-même ; la variante servie emprunte le chemin de production de la même architecture, et elle se trouve à un point d'accès de distance. OrcaRouter répercute le prix catalogue du fournisseur à 0 % de marge, de sorte qu'un changement de tarif du fournisseur sur ce point d'accès se voit le jour même plutôt qu'au prochain cycle de facturation, et tous les modèles de la clé sont accessibles via une seule URL de base compatible OpenAI, au lieu d'un contrat, d'un SDK et d'un identifiant distincts par fournisseur. Pour une architecture aussi jeune — où le travail sur le moteur arrive encore chaque semaine et où la feuille de route n'a pas été publiée — le basculement automatique entre fournisseurs est le moyen pratique de dépendre de la variante servie sans parier un chemin de production sur la disponibilité d'un seul fournisseur. Tout cela concerne les modèles que vous pouvez appeler aujourd'hui. Cela ne dit rien de Qwen 4, qui n'en fait pas partie.

Ce que nous ne savons toujours pas

Si Qwen 4 livrera le même tableau à la même taille. Si la pull request sera fusionnée, tout simplement — elle a trois exécutions CI en échec et aucune revue pour l’instant. Si la pénalité de 0,5 à 1 milliseconde par étape tient la route en dehors des configurations à faible concurrence de l’auteur. Et si Alibaba dit quoi que ce soit à Apsara le 22 septembre. D’après les éléments actuels, la conclusion la plus sûre à tirer au sujet de Qwen 4 n’est pas ce qu’il obtient comme score, mais la quantité de machinerie que l’industrie construit juste pour le faire tenir — ce qui est en soi une chose utile à savoir avant que le modèle ait un nom dans un catalogue quelconque.