Qwen3.8-Flash-Next-Uncensored-NVFP4 : Un runbook de service Blackwell

Qwen3.8-Flash-Next-Uncensored-NVFP4 ne fonctionne que sur une seule famille de GPU : Blackwell. NVFP4 s'exécute sur les cœurs tensoriels FP4 matériels, et Hopper (H100/H200) et tout ce qui est plus ancien ne les possèdent tout simplement pas. Si vous êtes sur Hopper, arrêtez-vous ici — la version Qwen3.8-Flash-Next-Uncensored-FP8 est celle qu'il vous faut. Tout ce qui suit suppose une carte Blackwell (B100, B200, GB200 ou une carte de la série RTX 50), une version récente de vLLM prenant en charge qwen4_exp, et transformers ≥ 5.16.

Voici la quantification NVFP4 du build abliterated (sans refus) de Qw​en/Qwen3.8-Flash-Next, réduit de 330 Go en BF16 à 178 Go sur disque. OrcaRouter l'a publié sur Hugging Face le 27 août 2026 sous le nom orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4. Le dépôt est restreint : vous devez être connecté à Hugging Face et avoir accepté les conditions du dépôt, ou hf download et vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4 échouent tous deux avec une erreur d'authentification avant qu'un octet ne soit transféré. Cette page est un runbook de déploiement, pas une couverture de lancement — le build date de deux jours, et les questions que les gens rencontrent réellement sont le matériel, les flags et quel build choisir.

Et avant que les chiffres commencent : Qwen3.8-Flash-Next-Uncensored n'est pas Qwen3.8-27B-Uncensored. Ce sont deux modèles différents qui partagent un nom de famille et une technique d'abliteration — des poids de base différents, des architectures différentes, des collections Hugging Face différentes. Flash-Next est abliteré à partir de Qw​en/Qwen3.8-Flash-Next, un aperçu de l'architecture Qwen4 (qwen4_exp) à base de mixture-of-experts routée : 512 experts avec dix routés plus un partagé actif, attention hybride (couches linéaires Gated DeltaNet aux côtés de couches de pleine attention), Hyper-Connections, un embedding n-gram PLE, une tour native vision et vidéo, et une tête de décodage spéculatif MTP. Le 27B est abliteré à partir de Qw​en/Qwen3.8-27B, une base dense complètement différente. Aucun des chiffres de service d'une page 27B ne s'applique à ce modèle ; là où une page 27B est réellement utile — le guide d'abliteration, les calculs généraux de choix de quantification — elle est liée ci-dessous avec ce qui s'applique et ce qui ne s'applique pas.

Ce qu'est cette construction, précision par précision.

Qwen3.8-Flash-Next est un MoE routé : chaque jeton active 10 des 512 experts plus un expert partagé, et seulement quelques milliards de paramètres sont actifs par jeton alors que le modèle stocké est bien plus volumineux. La version NVFP4 est une quantification compressed-tensors en précision mixte de cette pile, et la répartition est toute l'histoire :

• Poids des experts MoE — NVFP4 (4 bits, NVIDIA FP4 E2M1, groupes de 16 avec échelles de blocs FP8).

• Attention (self_attn.{q,k,v,o}), les projections linear_attn, l'expert partagé et lm_head — FP8 (8-bit).

• Embedding n-gramme PLE, embeddings de token et de vision, Hyper-Connections, l'indexeur QSA, conv/dt Gated-DeltaNet, toutes les normes, et l'ensemble de la tour de vision — BF16, conservés en pleine précision.

Trois propriétés de la conversion importent plus que le partage de précision lui-même. Premièrement, elle ne porte que sur les poids : les activations sont quantifiées dynamiquement à l’exécution, il n’y a pas de calibration statique, et les poids sont dérivés directement du point de contrôle BF16 (la fiche qualifie cette dérivation de sans données). Deuxièmement, la modification d’abliteration est intégrée dans les poids, donc la suppression du refus survit à la quantification — une conversion en 4 bits est un changement de précision, pas une intervention de sécurité. Troisièmement, le cache KV n’est pas quantifié ; il reste en BF16 à l’exécution. Ce dernier point est facile à manquer et il compte au contexte natif de 262 144 jetons du modèle, où le cache KV constitue un vrai poste de mémoire aux côtés des poids.

La taille sur disque est dominée par un seul tenseur. La carte décrit l'embedding n-gramme PLE comme un tenseur unique d’environ 66B de paramètres, conservé en BF16 par conception ; c’est le plus grand shard et la raison pour laquelle la build fait 178 Go plutôt qu’un nombre plus léger. Une divergence à signaler plutôt qu’à masquer : la carte sœur FP8 appelle la même table l’embedding n-gramme PLE à 51B de paramètres, et la note W4A4 de cette carte la désigne comme faisant environ 100 Go. Les deux cartes indiquent des chiffres différents pour la même table ; traitez donc chaque chiffre comme celui de sa propre carte — et lorsque vous dimensionnez un déploiement, supposez que la table est volumineuse en BF16 et planifiez en conséquence.

La condition préalable matérielle, explicitée.

C'est la section la plus courte et la plus importante de la page. NVFP4 est un format Blackwell : la voie rapide est un GEMM FP4 natif sur les cœurs tensoriels de cinquième génération, et sans ce matériel, le format n'a rien sur quoi tourner. La configuration requise pour la carte est explicite — un GPU Blackwell (B100 / B200 / GB200 / série RTX 50), car NVFP4 utilise les cœurs tensoriels FP4 matériels, et il ne fonctionnera pas sur Hopper (H100/H200) ni sur les générations antérieures, qui ne disposent pas du calcul FP4.

Les redirections, en un seul endroit :

• Sur Hopper (H100/H200) — servez plutôt Qwen3.8-Flash-Next-Uncensored-FP8. Ce sont les mêmes poids en 8 bits, cela fonctionne sur Hopper et Blackwell, et c'est la version couverte par le runbook FP8 de ce blog.

• Sur un GPU NVIDIA grand public ou une machine CPU — la version GGUF, avec ses 13 quants llama.cpp, est la solution locale.

• Sur Apple Silicon — la version MLX, en paliers de 4/6/8 bits, est le chemin natif Metal.

L'exigence relative au runtime est aussi contraignante que le silicium. qwen4_exp est une architecture flambant neuve, donc les builds vLLM standards qui lui sont antérieurs refuseront de charger le checkpoint. Vous avez besoin d'un vLLM récent prenant en charge qwen4_exp, plus le lecteur NVFP4 de compressed-tensors (le format est détecté à partir de config.json, et non choisi manuellement), et de transformers ≥ 5.16. L'entrée multimodale requiert en outre la pile de vision Qw​en du runtime ; le service en mode texte seul fonctionne sans elle.

La commande serve de la carte, drapeau par drapeau

L'invocation de la carte du modèle elle-même est un bon point de départ, et il vaut la peine de comprendre à quoi sert chaque option plutôt que de copier-coller aveuglément :

vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4 --tensor-parallel-size 4 --trust-remote-code --enable-expert-parallel --enable-auto-tool-choice --tool-call-parser qwen3_coder

• --tensor-parallel-size 4 — les poids occupent ~178 Go sur disque, la carte les répartit donc sur quatre GPU. C'est la configuration pour laquelle ce build est dimensionné ; ne l'interprétez pas comme une suggestion.

• --trust-remote-code — requis pour une architecture personnalisée. Le code de modélisation de qwen4_exp n'est pas encore dans le registre standard des transformers, donc vLLM charge le code d'architecture depuis le dépôt. Vous faites confiance à ce code, ce qui est une décision normale mais réelle pour une toute nouvelle architecture.

• --enable-expert-parallel — répartit les experts entre les rangs tensor-parallel au lieu de les répliquer, ce qui rend un MoE à 512 experts réalisable en TP4. La carte sœur FP8 indique la raison plus précise sur cette build : sans cette option, la largeur intermédiaire du MoE divisée par TP n'est pas divisible par la taille de bloc FP8. Traitez-la comme obligatoire, non facultative.

• --enable-auto-tool-choice et --tool-call-parser qwen3_coder — ensemble, ils activent l'appel de fonctions. Le drapeau auto permet au modèle de décider s'il doit appeler un outil, et le parseur qwen3_coder décode son format d'appel d'outil, la même famille de parseurs que Qwen3.8-27B et Qwen3.8-Flash-Next utilisent.

Une fois en place, le point de terminaison compatible OpenAI situé à /v1/chat/completions offre l’ensemble complet des fonctionnalités via la pile Qwen4 du runtime : appel d’outils comme ci-dessus, raisonnement via chat_template_kwargs.enable_thinking, et vision via les parties de contenu image_url. Vous n’avez pas besoin d’un serveur séparé pour le multimodale ; c’est le même point de terminaison.

Une note structurelle de la fiche : il n'existe pas de variante W4A4 entièrement statique de cette build, et il n'y en aura pas à moindre coût. Une conversion W4A4 statique nécessite une passe forward de calibration des activations, et cette passe doit contenir l'embedding n-gram d'environ 100 Go sur un seul GPU. C'est la même raison pour laquelle la table PLE domine la liste des fichiers, et c'est pourquoi cette build reste en poids uniquement avec des activations dynamiques.

Rapports de terrain communautaires — à quoi ressemble réellement le fait de servir cela.

Aucun chiffre de débit ou de latence n'est publié pour ce dépôt exact, et cette page n'en inventera pas. Ce qui existe, c'est un ensemble croissant de retours de terrain de la part de praticiens qui servent les builds NVFP4 de base Qwen3.8-Flash-Next — même architecture, même répartition de précision NVFP4/FP8/BF16, à l'exception de la modification d'abliteration — et le comportement en service se transpose directement. Ce sont des constatations de la communauté, et non des recommandations du fournisseur, et les personnes qui les ont rapportées étaient sur du matériel Blackwell avec le même schéma de quantification.

• Le décodage spéculatif MTP est le principal levier de performance. Le modèle est livré avec une tête de prédiction multi-tokens, et sur une RTX PRO 6000 (96 Go, SM120), le module MTP se charge quantifié en NVFP4 pour environ 0,51 Go de VRAM — le rapport a mesuré une longueur d'acceptation de 2,3 à 3,9 sur un maximum de 4 et un taux d'acceptation de 0,86 à 0,96. Le même rapport a mesuré un décodage mono-flux médian de 180 à 226 tok/s (216,9 en codage, 225,8 sur une charge de travail d'appel d'outil d'agent, 136,6 en raisonnement) par rapport à une base d'environ 105 tok/s, et a répondu à une invite de 216 685 tokens en 8,4 secondes. Considérez ces chiffres comme ceux d'une machine particulière, pas comme une spécification.

• Déchargez l'embedding n-gram PLE vers la RAM hôte. Parce que la table est énorme et qu’elle est rarement un goulot d’étranglement du débit, les recettes communautaires sur une seule carte Blackwell le placent sur l’hôte (~50 Gio de RAM hôte libre dans le rapport RTX PRO 6000) et le mappent en mémoire depuis le NVMe, sacrifiant un peu de latence pour que le modèle puisse tenir. Attendez-vous à faire quelque chose de similaire, sauf si vous disposez d’un très grand budget de VRAM.

• Fixez explicitement la fenêtre de contexte. Avec le cache KV en BF16 et MTP actif, un pool KV à dimensionnement automatique a gonflé au-delà de ce que la carte pouvait contenir et a fait OOM lors d'un long préremplissage ; fixer max-model-len / max-total-tokens à 262144 a rétabli la marge de manœuvre. Avec un contexte de 262K, le cache KV est un poste à budgéter, pas une valeur par défaut.

• Un bug d'autotune de FlashInfer corrompt silencieusement la sortie. Le mode de défaillance le plus important sur le terrain : l'autotune sélectionne les tactiques de noyaux fused-MoE uniquement en fonction de la latence et ne vérifie jamais la correction numérique, si bien que pour certaines formes, le décodage dégénère en un token répété. Le rapport sur la RTX PRO 6000 l'a reproduit avec 36 générations corrompues sur 36 lorsque l'autotune était activé, et 0 sur 36 lorsqu'il était désactivé — la solution de contournement consiste à désactiver l'autotune de FlashInfer (dans vLLM, --no-enable-flashinfer-autotune ; dans SGLang, --disable-flashinfer-autotune). Si les sorties de votre service dégénèrent soudainement, vérifiez cela avant de toucher à quoi que ce soit d'autre.

• Le DGX Spark (GB10, SM121) nécessite ses propres correctifs.Les poids NVFP4 (~126 Gio sur la version communautaire) ne tiennent pas dans un seul Spark de 128 Go, donc les recettes SGLang exécutent tensor-parallel 2 sur deux nœuds via RoCE, et le résolveur de décodage sparse QSA verrouille le noyau FlashInfer rapide derrière un contrôle is_sm100_supported() qui échoue sur SM121, retombant sur un chemin qui plante au warmup — la solution est un petit correctif plus un déchargement PLE. Comptez ~47–50 tok/s en décodage, culminant à près de 70 avec MTP4 et les graphes CUDA, et vérifiez que votre noyau fonctionne réellement sur SM121 avant de promettre un benchmark.

Raisonnement, appel d'outils et vision via la pile Qwen4

Le consensus communautaire sur la génération Qwen3.8 s'applique à ce modèle avec la réserve habituelle qu'il s'agit d'une pratique de terrain, et non d'une recommandation du fournisseur.

• reasoning_effort est le curseur le plus important.Le chat template est réglé par défaut sur xhigh, ce qui fait que le modèle réfléchit longuement à chaque requête. Les opérateurs de boucle d'agent définissent medium par défaut et passent à low pour les appels sensibles à la latence ; enable_thinking false désactive complètement le raisonnement lorsque vous n'en avez pas besoin. Sur une seule carte Blackwell, laisser xhigh activé pour les appels courants est ce qui fait qu'un modèle rapide produit des réponses lentes.

• Associez les échantillonneurs au mode de réflexion. Les praticiens convergent vers une température de 1.0 / top-p 0.95 lorsque la réflexion est activée, et une température de 0.7 / top-p 0.80 avec une pénalité de présence d'environ 1.5 lorsqu'elle est désactivée. Mélanger les deux ensembles dégrade la qualité de la sortie.

• L'appel d'outils survit à la fois à l'abliteration et à la conversion en 4 bits. Le chemin d'appel de fonction est intact, c'est ce que le parseur qwen3_coder et les options auto-tool-choice mettent en place. Pour une red team, c'est un fait à double tranchant, car cela signifie qu'un usage agentique malveillant est pleinement opérationnel sur un modèle non aligné — traité ci-dessous.

• La vision est préservée, ce qui élargit la surface d'attaque. La tour de vision n'a jamais été touchée par l'abliteration et reste en BF16, de sorte que l'entrée d'image fonctionne via les parties de contenu image_url. Les praticiens qui évaluent la ligne non censurée traitent le chemin multimodal comme une cible d'évaluation de première classe : une injection de prompt portée par une image atterrit sur un modèle sans comportement de refus à contourner.

Quelle build devriez-vous servir

La collection Flash-Next comprend cinq builds — BF16, GGUF, MLX, FP8, et celui-ci en NVFP4 — et la logique de sélection honnête repose sur le matériel et les compromis, pas sur un classement.

• NVFP4 (cette version, ~178 Go sur disque) — le choix Blackwell. Cœurs tensoriels FP4, experts 4 bits, la version la plus récente de la collection et la plus petite de ses versions serveur vLLM, et celle dont parle cette page.

• FP8 (~186 Go sur disque) — le choix Hopper, et tout aussi à l'aise sur Blackwell. Les mêmes poids en 8 bits, ce qui est la voie vLLM la plus largement vérifiée et celle dont l'exigence de parallélisme expert est la plus nette.

• GGUF (13 quants, IQ2_XXS ~52 GB à Q5_K_M ~125 GB) — le choix de llama.cpp pour les machines grand public NVIDIA, AMD ou CPU. Pas besoin de Blackwell, pas besoin de vLLM.

• MLX (niveaux 4/6/8 bits, environ 163–221 Go) — le choix Apple Silicon, Metal natif, tête MTP incluse.

Deux notes honnêtes avant de faire votre choix. Premièrement, les versions NVFP4 et FP8 ne sont séparées que d’environ huit Go sur le disque, car toutes deux conservent la grande table de n-grammes en BF16 — l’économie de 4 bits se concentre dans les poids des experts, pas dans l’empreinte totale. Le véritable avantage de NVFP4 sur Blackwell est la vitesse des cœurs tensoriels FP4 sur ces experts, pas un fichier nettement plus petit. Deuxièmement, la fiche décrit NVFP4 comme une dérivation de poids déterministe qui hérite de l’évaluation d’abliteration avec un léger compromis de qualité supplémentaire dû aux experts 4 bits, et elle ne quantifie pas ce compromis. Ce compromis est non quantifié — considérez-le comme un coût réel mais non spécifié des experts plus petits, et non comme négligeable.

L'évaluation, lue correctement

La fiche rapporte l'abliteration mesurée sur la build BF16 servie avec vLLM, comparée au Qw​en/Qwen3.8-Flash-Next officiel : le refus de prompts nuisibles chutant de 64–100 % à environ 0–3,3 %, le sur-refus de prompts bénins restant proche de zéro, et les capacités restant à ±2 points de la base. Trois choses à bien comprendre à propos de ces chiffres. {{1}}Il s'agit de mesures effectuées sur la build BF16, reprises par cette build 4 bits par déduction plutôt que mesurées sur elle.{{/1}} {{2}}Ce sont les chiffres du fournisseur lui-même, obtenus avec un classifieur à base de règles sur les phrases d'ouverture, que les fiches de la collection décrivent comme indicatifs plutôt que de niveau publication — une mesure interne de sa propre modification, et non un audit indépendant.{{/2}} {{3}}Et ils ne disent rien du compromis de qualité NVFP4 évoqué plus haut, que la fiche ne quantifie pas.{{/3}}

La limite de sécurité — recherche uniquement

L'avertissement de la fiche est sans détour, et c'est la partie de cette page qui ne doit pas ressembler à un texte passe-partout. L'alignement de sécurité de ce modèle a été substantiellement supprimé : la direction de refus a été orthogonalisée hors du flux résiduel, et le modèle se conformera aux demandes nuisibles, contraires à l'éthique ou illégales que le Qwen3.8-Flash-Next d'origine refuserait. Il est publié strictement à des fins de recherche légitime — interprétabilité, étude de la sécurité de l'IA et des mécanismes de refus, red-teaming et évaluation de la robustesse — et les auteurs déclinent toute responsabilité en cas d'utilisation abusive. Vous assumez l'entière responsabilité de ce qu'il génère, et vous ajoutez vos propres couches de sécurité et de modération avant que quoi que ce soit n'atteigne un utilisateur. Apache 2.0 est le plancher ; la restriction à des fins de recherche se situe au-dessus.

Deux erreurs du discours sur les modèles non censurés, que cette fiche rend impossibles à manquer. Premièrement, une sonde de jailbreak qui réussit contre ce modèle n'est pas une évaluation de sécurité réussie — c'est le comportement annoncé. Un modèle abliteré échoue à ces sondes exprès ; le mesurer avec un simple test « pouvez-vous le jailbreaker » revient à mesurer que la modification a fonctionné, et non qu'une barrière de protection est solide. Deuxièmement, la tour de vision préservée et le chemin d'appel d'outils intact élargissent la surface d'attaque réelle au-delà du texte : l'injection de prompt par image et le mauvais usage d'outils agentiques sont tous deux pleinement opérationnels, ce qui explique précisément pourquoi le cadrage red team traite ceci comme une sonde de capacité, et non comme un candidat chatbot. Si votre cas d'usage est de livrer un assistant orienté utilisateur, ce n'est pas votre modèle, et c'est voulu.

Où OrcaRouter s'intègre

Un build vieux de deux jours, restreint et exclusivement auto-hébergé, est le cas d'école du routage plutôt que du câblage en dur. Lorsque vous exécutez vous-même ce build NVFP4, vous pouvez dresser une route qui pointe vers lui et bascule vers un modèle hébergé si le build se comporte mal sous charge — une seule interface, aucun recâblage entre fournisseurs au moment du changement. Pour le travail d'évaluation en particulier, la baseline servie censurée est la comparaison que vous voulez, et elle n'est qu'à une clé d'API : le catalogue propose le Qwen3.8-Flash d'Ali​baba à 0,15 $ par million de tokens en entrée et 0,47 $ par million en sortie, répercuté au prix catalogue du fournisseur avec une marge de 0 %, si bien qu'un harnais de red team peut passer de la base hébergée censurée à votre build local non censuré sans second contrat, et toute variation de prix du fournisseur atterrit sur votre endpoint le jour même.

Qui devrait télécharger ceci — et qui ne devrait pas

Téléchargez orcarouter/Qwen3.8-Flash-Next-Uncensored-NVFP4 si vous êtes sur Blackwell, si vous voulez la plus petite empreinte serveur de la collection Flash-Next avec la vitesse des cœurs tensoriels FP4, et si vous faites le travail de recherche pour lequel cette gamme existe. Téléchargez Qwen3.8-Flash-Next-Uncensored-FP8 si vous êtes sur Hopper ou si vous préférez la voie la plus largement vérifiée. Téléchargez la version GGUF si vous êtes sur un GPU grand public ou une machine CPU, la version MLX si vous êtes sur Apple Silicon, et rien du tout si l'objectif est un déploiement destiné aux utilisateurs. Lisez les termes et l'avertissement avant d'accepter l'un ou l'autre — ce sont les termes du modèle, pas une formalité.

Les cinq builds Flash-Next — BF16, GGUF, MLX, FP8 et NVFP4 — sont regroupés dans la collection Qwen3.8-Flash-Next-Uncensored sur Hugging Face.

Un modèle différent, pas une autre version de celui-ci : Qwen3.8-27B-Uncensored est abliteré à partir d'une base différente et possède sa propre collection et ses propres runbooks.

Ces poids sont uniquement locaux par conception. Pour disposer d'une référence hébergée à laquelle comparer la version abliterated, Qwen3.8-Flash est servi sur OrcaRouter au prix catalogue du fournisseur avec 0% de marge — le modèle standard, alignement de sécurité intact.