Servir Qwen3.8-Flash-Next-Uncensored-FP8 : un runbook vLLM pour la version block-FP8

Qwen3.8-Flash-Next-Uncensored-FP8 — la version block-FP8 du Flash-Next abliterated — est l'artefact que vous téléchargez effectivement lorsque vous servez ce modèle sur du matériel de centre de données, et c'est le dernier de la collection à avoir son propre runbook. Il se trouve à orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 sur Hugging Face : la direction de refus est retirée du Qwen3.8-Flash-Next de Qw​en, puis le modèle est re-quantifié hors ligne selon le schéma FP8 exact du Qwen3.8-Flash-Next-FP8 officiel, afin que vLLM le serve sur le même chemin de noyau. C'est la version vers laquelle toute personne exécutant ce modèle sur des GPU de classe Hopper et plus récents se tournera, et le chemin de service comporte un flag facile à mal configurer et difficile à diagnostiquer quand c'est le cas.

D'abord, la frontière, parce que les lecteurs ne cessent de la brouiller et cela change tout ce qui suit. Qwen3.8-Flash-Next-Uncensored et Qwen3.8-27B-Uncensored sont deux modèles distincts, et non deux versions du même modèle. Des poids de base différents — Qwen3.8-Flash-Next contre Qwen3.8-27B — des architectures différentes, des versions de poids différentes, des collections Hugging Face différentes. Ils partagent une technique d'abliteration et un nom de famille ; c'est tout. Aucun des chiffres d'une page 27B ne s'applique à ce modèle, et si vous êtes arrivé ici depuis une recherche 27B, le runbook local du 27B est une page séparée avec un ensemble distinct de décisions.

Cette page est la page de serving Flash-Next FP8 et rien d’autre. Le runbook GGUF/MLX couvre l’explication de l’abliteration pour ce modèle et les deux lignes de build pour matériel grand public ; la technique derrière toute la famille est expliquée dans le primer sur l’abliteration et dans l’explicateur plus large sur les LLM non censurés ; et Qwen3.8-27B-Uncensored-FP8, le jumeau vers lequel on a pu vous orienter, a son propre runbook FP8. Ici, nous restons sur une seule question : comment servir la build block-FP8, ce qui casse quand on le fait mal, et ce que les chiffres de la fiche vous disent et ne vous disent pas.

Avant de commencer : le portail et le runtime

Deux choses conditionnent ce dépôt, et toutes deux produisent des échecs qui ressemblent à autre chose.

Le premier point est l'accès. Le dépôt est restreint : vous devez être connecté à Hugging Face et avoir accepté les conditions du dépôt pour que le moindre téléchargement fonctionne. La page du modèle elle-même est lisible sans compte — l'intégralité du texte de la fiche est publique — mais pas les poids. Concrètement, sans une session connectée ayant accepté les conditions, hf download et vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 échouent tous deux avec une erreur d'authentification, et non un message convivial du type « vous devez cliquer sur Agree ». Faites d'abord ce clic d'acceptation unique, puis récupérez les ~186 Go avec la CLI hf ou laissez vLLM résoudre le dépôt lors de la première exécution.

Le second est le runtime. Le checkpoint s'enregistre sous l'architecture qwen4_exp (Qwen4ExpForConditionalGeneration), que les versions standard de vLLM et de Transformers ne peuvent pas charger. Vous avez besoin de l'image vLLM day-0 et de transformers 5.16+. C'est l'échec « ça ne charge pas » le plus courant dans les runbooks de la communauté cette semaine — non pas un téléchargement corrompu, mais un runtime antérieur à l'architecture. L'image n'est pas facultative ; c'est la voie.

Matériel, pour que vous puissiez planifier avant de faire quoi que ce soit : l'invocation de la carte cible un nœud à 8 GPU, et les recommandations de la recette officielle vLLM pour le checkpoint FP8 s'appliquent ici, étant donné que les builds correspondent tenseur pour tenseur — de l'ordre de 265 Go de VRAM GPU pour un déploiement sur nœud complet, avec TP2 comme minimum sur la classe GB300 et TEP4/TEP8 comme configurations validées à plateau complet.

Pourquoi la version FP8 existe — et pourquoi le « chemin de noyau identique » est tout l’intérêt

Les poids BF16 abliterated sont la source de vérité ; ce dépôt est ce modèle re-quantifié hors ligne, reproduisant délibérément la recette officielle Qwen3.8-Flash-Next-FP8. Le quantificateur ne touche qu'aux 512 projections des experts routés — experts.{e}.down/gate/up_proj — qu'il défusionne de la disposition 3D de la build BF16 et stocke chacune sous forme de poids float8_e4m3fn accompagnés d'échelles BF16 weight_scale_inv en blocs de 128×128. Les activations sont en FP8 dynamique par token ; il n'y a pas d'ensemble de calibration. Tout le reste reste en BF16 : l'attention et linear_attn, l'expert partagé, le routeur MoE (mlp.gate), les mixers Hyper-Connection, les embeddings, lm_head, la tête de décodage spéculatif MTP, et toute la tour de vision.

La ligne « identical kernel path » est plus que du marketing, et elle mérite une phrase. La build a été vérifiée par rapport au checkpoint officiel FP8 : les échelles de blocs se reproduisent exactement (scale_relerr = 0) et les codes FP8 correspondent à un arrondi sub-ULP. C'est pourquoi vLLM l'exécute avec les mêmes kernels FP8 à échelle de blocs et le même décodage spéculatif MTP que la version officielle — les tenseurs sont effectivement les mêmes tenseurs, moins la direction de refus.

Concrètement, cela vous donne environ 186 Go répartis sur 131 shards (152 089 tenseurs, dont 75 264 en FP8), 262 144 jetons de contexte natif, la tour vision + vidéo préservée octet pour octet (333 tenseurs visual.*), et la tête MTP intacte. Les poids ont d'abord été ablitérés — une direction de refus unique estimée au niveau de la couche 24 et orthogonalisée hors de 149 tenseurs d'écriture résiduelle en float32, suivant Arditi et al. (2024) — et les écrivains résiduels de la tête MTP ont été modifiés de manière cohérente, de sorte que le décodage spéculatif continue de fonctionner. Ce dernier détail n'est pas évident, et c'est la différence entre une tête qui accélère le décodage et une qui le dégrade silencieusement.

Le drapeau qui fait ou défait le chargement

Servez cette build sans --enable-expert-parallel et vous obtenez une erreur qui ressemble à un bug de forme, pas à une erreur de configuration. C'est l'échec de service le plus signalé pour ce checkpoint, et il est entièrement déterministe.

Voici le calcul. La projection fusionnée gate+up des experts routés a une taille intermédiaire de 640. Block-FP8 quantifie en blocs de 128. En parallélisme de tenseurs standard, ce 640 est réparti entre les rangs — 640 ÷ TP — et pour les degrés de TP courants (2, 4, 8), la tranche par rang n'est pas divisible par 128 : TP8 donne 80, TP4 donne 160, TP2 donne 320. vLLM refuse alors de charger les poids avec une erreur qui ressemble à une incompatibilité de forme : The output_size of gate's and up's weight = 80 is not divisible by weight quantization block_n = 128.

Le parallélisme d'experts corrige ce problème en répartissant les poids des experts entre les rangs du parallélisme d'experts plutôt que ceux du parallélisme tensoriel, ce qui préserve les limites de blocs FP8. C'est pourquoi ce flag est obligatoire pour ce build : avec --enable-expert-parallel, TP8 devient un TEP8 fonctionnel. (Il est sans effet pour le build BF16, où il n'y a pas de blocs FP8 à préserver.) La recette officielle de vLLM est explicite : le TP8 simple est incompatible avec les blocs de quantification de 128 de large du checkpoint, et un problème vLLM ouvert deux jours après la publication des poids documente la même défaillance sur un nœud de 8×L40s en TP2, TP4 et TP8. Si un chargement échoue avec une erreur d'apparence de forme, vérifiez le flag avant de vérifier le téléchargement.

La commande exacte

Voici l'invocation docker de la carte, reproduite fidèlement :

docker run -d --name flashnext --gpus all --ipc host -p 8000:8000 -v /path/to/Qwen3.8-Flash-Next-Uncensored-FP8:/model vllm/vllm-openai:qwen38-flash-next-x86_64-cu130 --model /model --served-model-name Qwen3.8-Flash-Next-Uncensored --tensor-parallel-size 8 --trust-remote-code --max-model-len 262144 --enable-expert-parallel --enable-auto-tool-choice --tool-call-parser qwen3_coder

Traitez les drapeaux non évidents :

• vllm/vllm-openai:qwen38-flash-next-x86_64-cu130 — l'image day-0 qwen4_exp. Ce n'est pas un vLLM générique ; c'est l'image spécifique à l'architecture, et les images standard antérieures à qwen4_exp ne chargeront pas du tout le checkpoint.

• --trust-remote-code — charge le code de modélisation qwen4_exp fourni avec le dépôt. Sans lui, le chargeur refuse par principe.

• --max-model-len 262144 — correspond à la fenêtre de contexte native. Vous voulez qu'il soit explicite ici plutôt que laissé à une valeur par défaut.

• --enable-expert-parallel — requis pour la build FP8, pour les raisons évoquées dans la section ci-dessus. La carte indique qu'il est sans danger pour le BF16.

• --enable-auto-tool-choice --tool-call-parser qwen3_coder — active l'appel d'outils et de fonctions à l'aide du format XML Qwen3-Coder. Si vous les désactivez, le modèle continue de discuter, mais l'utilisation agentique des outils est désactivée.

• --tensor-parallel-size 8 — l'invocation de la carte suppose un nœud à 8 GPU (8× classe Hopper). Avec --enable-expert-parallel, cela correspond à un déploiement TEP8.

Une fois le conteneur démarré, le endpoint est compatible avec OpenAI sur :8000/v1. Définissez --served-model-name sur ce que vos clients attendent ; la carte utilise Qwen3.8-Flash-Next-Uncensored.

Alternatives, toutes dans la fiche ou corroborées par des praticiens cette semaine : lancer `vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8` directement une fois votre session HF authentifiée ; SGLang via l’image `lmsysorg/sglang:qwen38flashnext` avec `--tp 8 --ep 8` — même exigence de parallélisme d’experts, même raison ; et Transformers avec `pipeline("image-text-to-text", ...)` sur transformers 5.16+ si vous voulez scripter contre le modèle plutôt que de le servir.

Ce qui fonctionne vraiment quand on le sert.

Les modèles de cette section sont des constatations de la communauté issues des runbooks de praticiens et des fils de discussion de cette semaine, et non des recommandations de fournisseurs. Lorsque plusieurs configurations rapportent le même comportement, il vaut mieux le considérer comme réel :

• Le décodage spéculatif MTP fonctionne. Ajoutez --speculative-config '{"method":"mtp","num_speculative_tokens":3}' et vLLM utilise la tête MTP préservée. Plusieurs runbooks rapportent que MTP est la raison pour laquelle le décodage de ce modèle reste utilisable malgré sa taille.

• OOM au chargement ? Déportez la table de n-grammes.L'embedding n-gram PLE à 51 milliards de paramètres est la surprise mémoire de cette architecture. VLLM_PLE_CPU_OFFLOAD=1 le déplace vers la RAM hôte — prévoyez au moins ~51 Go là-bas. La recette officielle et les runbooks communautaires multi-nœuds ont tous recours à ce flag.

• La vision est réelle, pas vestigiale. La tour vision + vidéo est préservée octet pour octet, donc cela reste un modèle vision-langage complet. Passez une partie de contenu image_url dans une complétion de chat et le même point de terminaison sert à la compréhension d'images ; les sondes OCR communautaires sur cette version font état de passes sans erreur.

• Le raisonnement est activé par défaut — et cela change la donne en matière de sécurité. Le template de chat active la réflexion sauf indication contraire. Basculez par requête avec chat_template_kwargs={"enable_thinking": true|false}, et ajoutez un parseur de raisonnement si vous voulez que le texte de réflexion soit séparé de la réponse. En raison de cette valeur par défaut, vous servez presque toujours le modèle avec la réflexion activée, sauf si vous la désactivez explicitement.

• 262K natif, 1M avec un rope override. Le contexte natif est de 262 144 jetons. Pour atteindre 1M, il faut un override explicite du rope-scaling YaRN ainsi qu'une variable d'environnement qui lève la limite max-model-len de vLLM — et vous devriez d'abord tester par régression la qualité sur des contextes plus courts, car c'est l'extension aveugle par 4× qui dégrade généralement la qualité sur les longs contextes.

Ce que disent les chiffres de la carte — et ce qu'ils ne disent pas

Ce sont les mesures du fournisseur lui-même sur sa propre édition, publiées dans la fiche du modèle et mesurées sur ces poids exacts servis avec vLLM par rapport à la base officielle, avec des scripts et des réglages identiques. Présentez-les pour ce qu'elles sont : indicatives, et non un audit indépendant.

Le constat principal est l'effondrement du taux de refus lorsque la réflexion est désactivée. Sur la suite de prompts nuisibles de la fiche (n allant de 50 à 150 par benchmark), le taux de refus de base se situe entre 64 et 100 %, et celui de cette version entre 0 et 2,7 % : AdvBench 100 %→2,0 %, JailbreakBench 94 %→0,0 %, StrongREJECT 99,3 %→1,3 %, HarmBench 100 %→1,3 %, MaliciousInstruct 98 %→0,0 %, SimpleSafetyTests 64 %→2,0 %, ForbiddenQuestions 75,3 %→2,7 %, et une sonde personnalisée chinois/anglais 63,6 %→0,0 %.

Venons-en maintenant à la moitié honnête. Le taux de refus du modèle de base s'effondre lorsque la réflexion est activée — AdvBench passe de 100 % sur le modèle de base à 7,0 % avec le raisonnement activé — si bien que la comparaison avec réflexion est beaucoup moins spectaculaire : cette version affiche 0,0 % sur la même suite, mais elle ne fait que retirer un petit nombre à un nombre que le modèle de base avait déjà réduit. Ne citer que les chiffres sans réflexion, c'est présenter la moitié flatteuse de l'histoire, et c'est précisément la moitié sur laquelle une évaluation de sécurité ne doit pas s'appuyer.

La sur-réflexion sur les invites bénignes (XSTest-safe, n=250) passe de 9,6 % sur la base à 1,2 % sur cette version avec la réflexion désactivée — une réelle amélioration, car un modèle qui refuse les invites bénignes est le mode d’échec le plus discret. Le maintien des capacités sur MMLU / MMLU-Pro / GSM8K / CMMLU montre des écarts de −2,0, −1,2, −1,3 et −0,6 points respectivement, ce qui concorde avec l’affirmation selon laquelle orthogonaliser une direction coûte presque zéro capacité générale. L’appel d’outils, la vision/OCR et le raisonnement sont tous signalés comme fonctionnels sur cette version.

Deux réserves pèsent sur tout ce qui précède. La métrique de refus provient d'un classificateur de phrase d'ouverture à base de règles, que la fiche elle-même qualifie d'indicatif plutôt que d'un juge LLM ou d'un chiffre de qualité publication — un panel humain ou un modèle juge ne reproduira pas ces chiffres exacts. Et la colonne des réserves compte : sur la suite avec réflexion désactivée, environ la moitié à trois quarts des sorties de cette version s'ouvrent encore par un court avertissement avant d'obtempérer. Le modèle refuse rarement ; il nuance. « Uncensored » signifie ici qu'il répond, pas qu'il répond sans préambule.

La section sécurité n'est pas une formalité.

Lisez ceci avant de tirer les poids, pas après.

Ce modèle a vu son alignement de sécurité substantiellement retiré, et le mécanisme est précis : une direction de refus unique a été estimée dans le flux résiduel et orthogonalisée hors de chaque matrice d'écriture résiduelle — 149 d'entre elles — calculée en float32. La conséquence est annoncée, non accidentelle. La fiche est sans détour : le modèle se conformera aux demandes nuisibles, contraires à l'éthique, offensantes ou illégales que le modèle de base Qwen3.8-Flash-Next refuserait, et il ne dispose d'aucune garde-fou intégrée digne de ce nom. Il est publié strictement pour la recherche légitime — interprétabilité, étude des mécanismes de refus et de sécurité de l'IA, red-teaming, évaluation de la robustesse et expériences contrôlées — et l'utilisateur assume l'entière responsabilité et la pleine liability pour ce qu'il génère. La licence Apache 2.0 régit ce que vous pouvez faire des poids.

Deux choses à faire exactement comme il faut, car cette version les rend faciles à mal faire.

D'abord, 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é. Si votre évaluation prétend que « la sécurité de ce modèle a été contournée », vous avez mesuré la conception, pas une vulnérabilité. Ce qui constituerait réellement un résultat, c'est un refus qui survit à l'abliteration, ou une régression de capacités — et les chiffres de la fiche technique suggèrent que les deux sont rares.

Deuxièmement, la surface d'attaque préservée est plus large que le texte. La tour de vision est intacte octet pour octet et l'appel d'outils fonctionne, donc l'entrée d'images et l'utilisation agentique sont toutes deux actives. Un plan d'équipe rouge qui ne sonde que les invites textuelles manque les modalités que ce modèle expose réellement. Et les chiffres de refus ci-dessus sont un classificateur basé sur des règles sur la propre modification du fournisseur — ils ne constituent pas un audit indépendant de quoi que ce soit, y compris la sécurité.

Ne déployez pas ceci auprès des utilisateurs finaux ou en production sans ajouter vos propres couches de sécurité, de modération et de prévention des abus. Les conditions du dépôt le disent clairement, et ce n'est pas un texte générique : les sorties ne reflètent pas les points de vue des personnes ayant mis en ligne le contenu, ni ceux de Qw​en / Ali​baba.

Comment obtenir une référence censurée pour comparaison

Si votre travail consiste en une recherche sur les mécanismes de refus ou en du red-teaming, vous voudrez presque certainement disposer côte à côte de la version censurée de ce modèle — la même architecture sans la modification — afin de mesurer l’écart. Cette version non censurée est uniquement locale par conception : le dépôt est restreint et ne dispose d’aucun déploiement d’inférence hébergé, ce qui est volontaire pour que les charges utiles sensibles ne transitent jamais par une API tierce.

Pour la baseline hébergée, OrcaRouter route la gamme Qw​en au prix catalogue du fournisseur avec zéro marge — Qwen3.8-Flash à 0,15 $ par million de tokens en entrée et 0,47 $ par million en sortie, le tout transmis en l'état, avec basculement automatique et une seule clé pour plus de 200 modèles. Un changement de prix du fournisseur apparaît le jour même. Si vous vous demandez s'il vaut la peine d'exécuter cette build, ou quelle partie de votre stack elle peut supporter, c'est le moyen le moins cher de comparer la version censurée à celle-ci, sans second contrat ni second codebase.

Commencez ici

Résumé de la décision. Vous avez besoin : d'un compte Hugging Face avec les conditions du dépôt acceptées ; d'un nœud de classe Hopper ou plus récent — la commande de la fiche cible 8 GPU, et de l'ordre de 265 Go de VRAM GPU selon les recommandations de la recette officielle pour le point de contrôle FP8 correspondant ; de l'image vLLM day-0 et de transformers 5.16+ ; et d'environ 186 Go d'espace disque pour les poids.

Ordre d'exécution : acceptez les conditions du dépôt → téléchargez les poids → récupérez l'image day-0 → servez avec --enable-expert-parallel → vérifiez avec une requête vers :8000/v1/chat/completions → puis lancez vos évaluations. Si un chargement échoue avec une erreur ressemblant à un problème de forme, vérifiez l'option avant de vérifier le téléchargement.

Et gardez le cadre. C'est un instrument de recherche, publié à cette condition. Ses chiffres sont les mesures indicatives du fournisseur sur sa propre version. Son comportement de sécurité est l'objet de l'exercice, pas un bug à contourner. Servez-le, mesurez-le, et mettez votre propre modération entre lui et tout ce qui est humain.

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.