Qwen3.8-Flash-Next en local : ce que représentent réellement 6 milliards de paramètres actifs pour la RAM, la VRAM et le NVMe

Non, Qwen3.8-Flash-Next ne tient pas en mémoire comme un modèle de 6B simplement parce qu’il active environ 6B paramètres par token. Qwen décrit un modèle principal de 125B paramètres avec 6B paramètres activés, auxquels s’ajoutent 51B d’embeddings de n-grammes et un composant MTP d’environ 4B paramètres. Le dépôt officiel Qwen3.8-Flash-Next fait actuellement environ 360 Go dans sa version BF16 publiée. Les conversions GGUF de la communauté peuvent réduire considérablement cette taille, mais elles ne transforment pas Flash-Next en modèle conventionnel de 6B.

La façon utile d’envisager le déploiement local consiste à considérer une hiérarchie de mémoire. La VRAM détermine la quantité d’exécution du modèle à haute vitesse qui peut rester sur le GPU. La RAM système fournit la capacité nécessaire aux composants résidents du processeur et aux composants déportés, notamment l’immense table de n-grammes que Qwen a explicitement conçue pour fonctionner depuis la mémoire hôte. Le NVMe fournit un stockage local rapide et un support mappé en mémoire pour les fichiers approchant ou dépassant 100 Go, mais il ne remplace ni la RAM ni la VRAM. La véritable question est donc de savoir ce que le nombre de 6B actifs retire à la charge matérielle — et ce qu’il ne retire pas.

6B actifs signifie-t-il que Qwen3.8-Flash-Next ne nécessite que la mémoire d’un modèle de 6B ?

Non. Les paramètres activés décrivent les calculs effectués pour chaque token, et non la quantité totale d’état du modèle qui existe. Cette distinction est particulièrement importante pour Qwen3.8-Flash-Next, car l’écart entre le nombre de paramètres actifs et le nombre de paramètres stockés est exceptionnellement important.

Selon la fiche officielle du modèle Qwen3.8-Flash-Next, le modèle de langage contient 125B paramètres, dont environ 6B sont activés pour chaque token, auxquels s’ajoutent 51B paramètres d’embeddings de n-grammes et environ 4B paramètres associés au MTP. Le MoE principal contient 512 experts routés et sélectionne 10 experts routés ainsi qu’un expert partagé pour un token.

Ce qui produit trois nombres différents qu’il ne faut pas confondre :

L'essentiel est que les experts inactifs ne cessent pas d'exister. Différents jetons peuvent être orientés vers différents experts ; l'environnement d'exécution doit donc toujours pouvoir accéder à l'ensemble plus vaste des poids, même si seule une petite fraction participe à la propagation avant d'un jeton donné. C'est la même raison générale pour laquelle d'autres grands modèles MoE peuvent effectuer relativement peu de calculs actifs tout en conservant une empreinte mémoire très importante, une distinction également essentielle dans notre analyse du matériel local pour GLM-5.3-Flash.

Flash-Next ajoute une autre particularité. Sa table d'embeddings n-grammes de 51 milliards de paramètres n'est pas utilisée comme une matrice ordinaire de poids d'un réseau neuronal dense. Dans la présentation officielle de l'architecture Flash-Next par Qwen, l'équipe explique que les emplacements de consultation des n-grammes peuvent être déterminés à l'avance. La table peut donc résider dans la mémoire hôte et être préchargée de manière asynchrone pendant que les autres calculs du modèle sont exécutés.

C'est pourquoi le nombre de 6 milliards de paramètres actifs est pertinent, même s'il ne correspond pas à un besoin en mémoire. Flash-Next est conçu pour séparer plus fortement la capacité du modèle du calcul par jeton qu'un modèle dense classique. Pour l'inférence locale, la question matérielle ne se résume donc plus à une seule valeur de VRAM, mais à l'efficacité avec laquelle la VRAM, la RAM système et le stockage peuvent fonctionner ensemble.

Quelle est la taille de Qwen3.8-Flash-Next après quantification ?

La version officielle BF16 fait environ 360 Go, ce qui exclut immédiatement un déploiement non quantifié entièrement chargé en mémoire sur du matériel de bureau courant. La quantification change considérablement la situation.

Au 1er septembre 2026, les versions GGUF actuelles de Flash-Next d'Unsloth vont de versions basse précision extrêmement agressives à des variantes beaucoup plus volumineuses et de haute qualité. Deux points de référence utiles sont la version UD-IQ4_XS d'environ 93,7 Go et la version UD-Q4_K_XL d'environ 111 Go.

Ces tailles de GGUF sont des conversions réalisées par la communauté, et non des recommandations officielles de Qwen concernant la RAM ou la VRAM minimales. Elles restent néanmoins utiles pour planifier la capacité, car elles montrent l’ampleur du problème avant l’ajout des tampons d’exécution, de l’état du contexte, du traitement de la vision, du système d’exploitation et des autres applications.

Par exemple, un fichier de modèle de 94 Go n’implique pas qu’une machine disposant exactement de 96 Go de mémoire combinée offrira un déploiement confortable. Le moteur a toujours besoin d’espace de travail, et la quantité de mémoire supplémentaire requise varie selon la longueur du contexte, le backend, le format du cache, la stratégie de déportage vers le GPU et la concurrence.

De combien de VRAM Qwen3.8-Flash-Next a-t-il besoin ?

Il n’existe pas de valeur unique utile de « VRAM minimale » pour Flash-Next, car l’inférence locale peut aller d’une exécution presque entièrement résidente sur le CPU à un modèle réparti sur un ou plusieurs GPU. La VRAM détermine principalement la quantité de la charge d’inférence à large bande passante qui peut rester sur le GPU et donc la vitesse d’exécution du système.

Un GPU grand public de 24 ou 32 Go ne peut pas contenir à lui seul un GGUF actuel de 94 à 111 Go en quatre bits. Cela ne rend pas nécessairement le GPU inutile. Un moteur capable d’un déportage partiel vers le GPU peut conserver certains tenseurs ou certaines couches dans la VRAM, tandis que la RAM système contient le reste.

Les options actuelles de chargement des modèles de llama.cpp incluent le placement des couches sur le GPU, la sélection explicite des périphériques, la surcharge des tenseurs et les contrôles du MoE sur le CPU. Cela signifie que « mon GPU peut-il l’exécuter ? » et « mon GPU peut-il contenir le modèle entier ? » sont deux questions différentes.

La différence de performances entre ces configurations peut être énorme, même lorsque chacune charge techniquement le modèle. La bande passante mémoire du GPU est bien supérieure à celle de la mémoire système ordinaire, et le transfert d’une grande partie des calculs actifs vers le CPU peut transformer un modèle local autrement impressionnant en un outil davantage adapté à l’expérimentation qu’à l’utilisation interactive d’agents.

Pour Flash-Next, la VRAM doit donc être considérée comme une **allocation de performances**, et non comme un simple seuil de compatibilité binaire.

De combien de RAM Qwen3.8-Flash-Next a-t-il besoin pour le déport CPU-GPU ?

La RAM système est sans doute plus importante pour Flash-Next que ne le laisse penser le titre « 6 milliards actifs ». Une machine équipée d’un GPU grand public mais disposant de très peu de RAM n’a aucun emplacement utile pour la grande quantité d’état du modèle qui ne tient pas dans la VRAM.

L’intégration n-grammes rend cela particulièrement intéressant. Qwen indique que la table de 51 milliards de paramètres peut être placée dans la mémoire hôte, car ses accès sont déterministes et peuvent être préchargés. Lorsque l’implémentation de Flash-Next a été fusionnée dans llama.cpp le 27 août, ses notes d’implémentation décrivaient la table d’intégration n-grammes par couche comme occupant environ 97,7 Gio en BF16 et indiquaient que la recherche de ses lignes était effectuée côté hôte.

Cela ne signifie pas que chaque déploiement local nécessite en permanence 97,7 Gio non quantifiés supplémentaires en plus d’un GGUF quantifié. La quantification et la représentation à l’exécution jouent un rôle. Cela montre toutefois pourquoi l’architecture a été conçue autour d’une mémoire hétérogène, plutôt que de supposer que chaque paramètre doit rester dans la mémoire du GPU.

Pour une inférence GGUF pratique, la mémoire système doit être dimensionnée à partir de la taille réelle du modèle quantifié, à laquelle il faut ajouter une marge pour le système d’exploitation et l’exécution. Avec une quantification d’environ 94 Go, 128 Go de RAM constituent une capacité expérimentale plausible, mais ce n’est pas généreux une fois pris en compte le système d’exploitation, le contexte, les tampons et le comportement d’allocation entre le GPU et l’hôte. Un système doté de 192 ou 256 Go offre une marge bien plus sûre pour une inférence hybride sérieuse.

C’est l’un des exemples les plus clairs de la raison pour laquelle la mémoire de l’IA locale devient une hiérarchie plutôt qu’une simple spécification de VRAM. La mémoire du GPU prend en charge les opérations les plus sensibles à la bande passante, la mémoire hôte augmente la capacité des modèles et le stockage fournit les données persistantes des modèles sous-jacentes à ces deux niveaux.

Le déport vers un SSD NVMe peut-il rendre Qwen3.8-Flash-Next utilisable en pratique ?

Un NVMe peut faciliter le stockage et le chargement d’un modèle surdimensionné, mais il ne transforme pas la capacité d’un SSD en mémoire d’inférence rapide. Cette distinction devient plus importante à mesure que les modèles locaux dépassent la barre des 100 Go.

Un disque NVMe rapide est utile pour stocker plusieurs variantes GGUF, charger un modèle volumineux sans attendre un stockage réseau ou un disque dur plus lent, et prendre en charge l’accès aux modèles mappés en mémoire. llama.cpp utilise le mappage mémoire comme mode de chargement des modèles, ce qui permet de mapper les pages du modèle depuis un fichier au lieu d’exiger que le fichier entier soit copié dans une allocation RAM séparée au démarrage.

Cependant, la documentation de llama.cpp sur le chargement en mémoire explique également pourquoi cela ne doit pas être interprété comme un déport gratuit vers le disque. Si le modèle actif dépasse la RAM disponible, les sorties de pages et les accès répétés au stockage peuvent dégrader les performances. Le verrouillage de la mémoire existe précisément parce qu’il peut être important de conserver en RAM les pages du modèle fréquemment utilisées.

Une règle utile est la suivante : un NVMe peut rendre chargeable un modèle surdimensionné ; il ne le rend pas automatiquement interactif.

Cela explique également pourquoi l’architecture de stockage devient de plus en plus importante pour l’IA locale, même lorsque le périphérique de stockage lui-même n’effectue pas l’inférence. Les modèles, ressources visuelles, index RAG, jeux de données, espaces de travail d’agents et plusieurs points de contrôle quantifiés peuvent facilement occuper des centaines de gigaoctets. Le stockage local rapide devient une composante du système d’IA, mais il reste à un niveau différent de la mémoire qui alimente les calculs actifs.

Comment un contexte de 262K modifie-t-il les besoins en mémoire ?

Qwen3.8-Flash-Next prend nativement en charge une longueur de contexte de 262 144 tokens, extensible jusqu’à près d’un million de tokens avec YaRN. Cela ne signifie pas que chaque déploiement local devrait configurer par défaut le contexte maximal.

Le modèle utilise une architecture hybride plutôt qu’une attention complète conventionnelle à chaque couche. Gated DeltaNet compresse l’historique, tandis que Qwen Sparse Attention utilise un indexeur pour sélectionner les blocs de contexte pertinents. Cette conception vise précisément à réduire la pression sur le calcul et la mémoire associée aux séquences longues.

Un contexte étendu n’est toujours pas gratuit. La mémoire d’exécution peut inclure l’état récurrent, les caches d’attention sparse, l’état de l’indexeur, les tampons temporaires de calcul, les entrées visuelles, la surcharge liée au traitement par lots et les allocations propres au backend. La courbe mémoire exacte dépend donc du moteur d’inférence et ne se résume pas à la seule taille du fichier GGUF.

Il existe également une différence entre la limite de contexte architecturale d’un modèle et le niveau de maturité actuel de son implémentation dans un environnement d’exécution. Au 1er septembre 2026, la prise en charge de la nouvelle architecture par llama.cpp ne date que de quelques jours. Un problème CUDA actuel concernant un contexte de 262K signale un échec du lancement du noyau à exactement 262 144 jetons, tandis que 261 888 jetons fonctionnent sur le système de test. Le rapport identifie une limitation du noyau plutôt qu’un épuisement de la VRAM.

Ce problème précis sera peut-être corrigé rapidement, mais il illustre un point plus général : 262K est une capacité du modèle, et non la garantie que chaque GPU et chaque moteur d’inférence actuels peuvent exploiter efficacement toute cette fenêtre dès aujourd’hui.

Pour un déploiement local, commencez par la longueur de contexte réellement nécessaire à la charge de travail. Une session de programmation, une tâche d’analyse documentaire ou un flux de travail RAG privé qui tient dans 16K, 32K ou 64K ne devient pas meilleur simplement parce que l’environnement d’exécution réserve des centaines de milliers de jetons.

Quel matériel peut réellement exécuter Qwen3.8-Flash-Next en local ?

La réponse matérielle la plus utile dépend de ce que signifie « exécuter ». Charger un modèle fortement quantifié et générer des jetons constitue un objectif. Maintenir des performances interactives, gérer un contexte étendu, des entrées visuelles et des tâches agentiques est un objectif bien plus exigeant.

Le tableau ci-dessous sert donc de guide de planification fondé sur les tailles actuelles des modèles et des fichiers GGUF, et non de recommandation matérielle officielle de Qwen.

La principale ligne de démarcation n’est pas un modèle de GPU précis. C’est le fait que la machine dispose ou non d’une capacité combinée de mémoire rapide suffisante pour éviter que la pagination depuis le stockage n’entre dans le chemin critique de la génération.

Un GPU de 24 Go associé à 192 Go de mémoire système rapide peut constituer une expérience Flash-Next plus crédible qu’un GPU de 24 Go associé à seulement 32 ou 64 Go de RAM. À l’inverse, ajouter une grande quantité de RAM ne rend pas l’inférence fortement dépendante du processeur équivalente à l’exécution des mêmes tenseurs dans une mémoire GPU à large bande passante.

Pour la plupart des utilisateurs d’ordinateurs de bureau qui s’intéressent à la famille Qwen3.8 plutôt qu’à cette architecture en particulier, Qwen3.8-27B est la cible locale la plus conventionnelle. Flash-Next est surtout pertinent pour les utilisateurs qui souhaitent délibérément expérimenter un modèle épars beaucoup plus grand, une mémoire hétérogène, une architecture à long contexte ou la technologie qui, selon Qwen, préfigure l’orientation de Qwen4.

Qwen3.8-Flash-Next vaut-il la peine d’être exécuté en local ?

Oui, pour la bonne station de travail et la bonne raison — mais pas parce que « 6B actifs » transformerait soudainement une version d’environ 180 milliards de paramètres en petit modèle pour ordinateur de bureau.

Flash-Next est particulièrement intéressant si vous disposez de 128 à 256 Go de mémoire système ou unifiée, d’une accélération GPU significative, d’un stockage NVMe rapide et d’une bonne raison d’expérimenter de grandes charges de travail locales de programmation, multimodales, bureautiques ou agentiques. Son architecture est particulièrement pertinente pour l’IA locale, car elle sépare délibérément les paramètres fréquemment calculés des grandes structures axées sur la capacité, qui peuvent résider en dehors de la mémoire GPU.

Il convient beaucoup moins à un PC standard doté de 32 à 64 Go de RAM, lorsque le fonctionnement dépend du chargement constant par le système d’exploitation des pages manquantes du modèle depuis le SSD. Une telle machine peut démontrer que le modèle peut techniquement démarrer, mais « se charger correctement » et « fonctionner de manière réellement utile » sont deux critères différents.

La leçon plus générale va au-delà de ce modèle. Le matériel d’IA local dépend de moins en moins de la recherche d’un seul chiffre minimal de VRAM et de plus en plus de la conception d’une hiérarchie : la VRAM pour les calculs à grande vitesse, la RAM pour la capacité de modèle accessible, et le NVMe pour le stockage local persistant des modèles et des données. Qwen3.8-Flash-Next rend cette transition particulièrement visible.

FAQ : configuration matérielle requise pour exécuter Qwen3.8-Flash-Next en local

Qwen3.8-Flash-Next peut-il fonctionner sur une RTX 4090 ou une RTX 5090 ?

Oui, ces GPU peuvent participer à un déploiement local hybride, mais ni une RTX 4090 de 24 Go ni une RTX 5090 de 32 Go ne peuvent contenir entièrement en VRAM un fichier GGUF quatre bits actuel de Flash-Next d’environ 94 à 111 Go. Vous aurez besoin d’une quantité importante de RAM système et d’un déchargement vers le CPU et le GPU. Le GPU peut tout de même accélérer la partie du modèle qui y est placée ; il est donc très différent d’affirmer que ces cartes ne peuvent pas être utilisées.

Qwen3.8-Flash-Next peut-il fonctionner avec 64 Go de RAM ?

64 Go de RAM système sont inférieurs à la taille des plus petites versions GGUF quatre bits actuellement utilisables en pratique. Le mappage mémoire peut permettre d’accéder à certaines portions d’un fichier surdimensionné depuis le stockage, mais les échanges répétés de pages risquent de rendre l’inférence lente et instable dans le cadre d’une utilisation interactive. Pour un déploiement local sérieux, 64 Go ne doivent pas être considérés comme une cible pratique.

128 Go de RAM suffisent-ils pour Qwen3.8-Flash-Next ?

128 Go constitue un point de départ plausible pour l’une des versions GGUF quatre bits les plus petites, lorsqu’elle est associée à un déchargement vers le GPU et à une fenêtre de contexte prudente. Ce n’est pas une recommandation universelle confortable. Un modèle d’environ 94 Go laisse bien moins de 34 Go pour le système d’exploitation, les tampons d’exécution, l’état du contexte, le traitement de la vision et les autres services ; 192 Go ou plus offrent donc une marge nettement supérieure.

Qwen3.8-Flash-Next peut-il fonctionner entièrement depuis un SSD NVMe ?

Un environnement d’exécution peut mapper en mémoire les fichiers du modèle stockés sur un SSD NVMe, et le système d’exploitation peut charger les pages au fur et à mesure des besoins. Cela ne revient pas à exécuter le modèle « depuis le SSD » à la vitesse de la RAM ou du GPU. Le NVMe est excellent pour stocker et charger les modèles, mais y recourir en continu parce que la mémoire physique est épuisée peut réduire considérablement les performances de génération.

Le fait que 6 milliards de paramètres soient actifs signifie-t-il que Qwen3.8-Flash-Next est aussi rapide qu’un modèle de 6 milliards de paramètres ?

Non. Le chiffre de 6 milliards décrit le nombre approximatif de paramètres activés du modèle principal pour chaque jeton. Flash-Next possède toujours une architecture bien plus vaste, une logique de routage, un trafic mémoire, une recherche par n-grammes, un état d’attention parcimonieuse et d’autres opérations d’exécution. Un nombre inférieur de paramètres activés peut réduire considérablement les calculs, mais cela ne rend pas le système complet équivalent à un modèle dense de 6 milliards de paramètres.

Ollama ou llama.cpp peuvent-ils exécuter Qwen3.8-Flash-Next localement ?

Prise en charge de Qwen3.8-Flash-Next par llama.cpp qwen4exp L’architecture a été fusionnée dans master le 27 août 2026, un jour après la sortie du modèle. Les dépôts GGUF communautaires actuels proposent également des versions destinées aux flux d’inférence locale basés sur llama.cpp. Comme l’implémentation est encore très récente, consultez les versions actuelles des environnements d’exécution et les instructions du modèle avant de supposer que chaque backend GPU, longueur de contexte, chemin de vision ou configuration de déchargement est aussi mature.