Qwen3.8-27B-Uncensored-NVFP4 : un runbook de service pour GPU Blackwell

Qwen3.8-27B-Uncensored-NVFP4 est sur Hugging Face depuis le 19 août 2026, et au cours des dix jours qui ont suivi, il a été téléchargé environ 32 700 fois. Ceci n'est pas une couverture de lancement — les poids ont dix jours, il n'y a aucune annonce à rapporter, et les builds associés Qwen3.8-27B-Uncensored-FP8 et Qwen3.8-27B-Uncensored-GGUF sont déjà documentés sur ce blog. C'est un manuel pour une version que les gens téléchargent activement en ce moment : ce qu'est réellement NVFP4, pourquoi cette version spécifique le mélange avec FP8, quels GPU en profitent et lesquels n'en profitent pas, comment la servir, et qui devrait la préférer aux versions FP8 ou GGUF — et qui ne le devrait pas.

Un point à clarifier d'emblée, car il piège tous les nouveaux téléchargeurs : le dépôt est verrouillé. La commande naïve hf download orcarouter/Qwen3.8-27B-Uncensored-NVFP4 échoue avec une erreur d'authentification tant que vous n'êtes pas connecté à Hugging Face et n'avez pas accepté les conditions d'accès du dépôt sur la page du modèle. Tout ce qui suit suppose que vous avez fait les deux.

D'emblée : la fiche modèle de ce dépôt se trouve derrière la même barrière, donc rien ici ne la paraphrase. Ce qui suit s'appuie sur la liste publique des fichiers et les métadonnées du dépôt, sur la documentation publique de NVIDIA sur NVFP4, et sur des retours de terrain de personnes servant des builds Qwen3.8-27B NVFP4 sur Blackwell. Lorsqu'un chiffre provient d'un praticien plutôt que d'un fournisseur, le texte le précise.

Ce qu'est cette version

Qwen3.8-27B-Uncensored-NVFP4 est la quantification NVFP4 de Qwen3.8-27B-Uncensored, la version abliterée du modèle d'Ali​baba Qw​en/Qwen3.8-27B, publiée par l'organisation orcarouter le 2026-08-18. L'abliteration retire du flux résiduel la direction de refus du modèle ; cette technique est expliquée dans notre guide explicatif sur les modèles non censurés et n'est pas réexpliquée ici. La base est le modèle dense 27B avec attention hybride — 48 couches d'attention linéaire plus 16 couches d'attention complète — une compréhension native des images et des vidéos, un contexte de 262 144 jetons, et une tête de décodage spéculatif MTP intégrée. Apache 2.0 de bout en bout.

Ce qui rend ce build intéressant, ce n'est pas l'abliteration, mais le schéma de quantification : il s'agit délibérément d'un build quantifié — si vous avez cherché NVFP4, le format est le cœur du sujet. Selon les métadonnées publiques du dépôt et sa configuration de quantification, c'est un build compressed-tensors en précision mixte : les projections d'attention sont en FP8 (E4M3), les MLP en NVFP4 (4 bits, empaquetés), et l'encodeur visuel, la tête MTP, le lm_head, ainsi que les normes et biais de l'attention linéaire, restent en BF16. Les métadonnées safetensors du listing public des fichiers correspondent à ce schéma : environ 3,5 milliards de paramètres en BF16, 9,4 milliards en FP8-E4M3 et 15 milliards en tenseurs 4 bits empaquetés, soit environ 24,7 Go sur disque, répartis sur cinq shards plus un shard model-extra distinct. Rien de tout cela ne constitue une affirmation sur son comportement au serving — la VRAM à l'exécution et le débit pour ce dépôt précis ne sont publiés nulle part que je puisse citer aujourd'hui. La taille sur disque provient du listing des fichiers, le format provient de la configuration, et le comportement de serving ci-dessous est vérifié par la communauté sur des builds NVFP4 très proches.

Ce qu'est NVFP4, et en quoi il diffère de FP8 et d'INT8/AWQ

NVFP4 est le format virgule flottante 4 bits de NVIDIA, introduit pour les cœurs tensoriels de cinquième génération sur Blackwell, et le blog technique officiel de NVIDIA est la source primaire appropriée à ce sujet. Il stocke les poids sous forme E2M1 — un bit de signe, deux bits d'exposant, un bit de mantisse — et les met à l'échelle par blocs : toutes les 16 valeurs partagent une échelle E4M3 FP8, et le tenseur entier reçoit un scalaire FP32 par tenseur. Ce schéma à deux niveaux est tout l'intérêt du format : il récupère la plage dynamique qu'un flottant 4 bits naïf perdrait, au prix de quelques bits de surcharge par bloc. Les différences pratiques, en une ligne :

• NVFP4 vs FP8 — les deux sont en virgule flottante, mais FP8 (E4M3, 8 bits) fonctionne sur Hopper et Blackwell, alors que NVFP4 est en 4 bits et n'est accéléré nativement que sur Blackwell. NVIDIA cite des poids environ 3.5× plus petits que FP16 et environ 1.8× plus petits que FP8, et sur Blackwell, le matmul s'exécute directement sur les cœurs tensoriels FP4.

• NVFP4 vs INT8/AWQ — INT8 (W8A8) et AWQ (W4A16) sont des formats entiers qui fonctionnent à partir d'Ampere ; AWQ est en 4 bits mais entier, et sur la plupart des matériels, les poids sont déquantifiés vers un type plus large pour la multiplication matricielle. NVFP4 est un flottant 4 bits avec mise à l'échelle par blocs, ce qui lui permet de conserver plus de précision dans les bits de poids faible, et il dispose d'un chemin GEMM FP4 natif que les formats entiers n'ont pas.

• NVFP4 vs MXFP4 — les deux sont constamment confondus. MXFP4 utilise des blocs de 32 éléments et des échelles E8M0 (puissances de deux) ; NVFP4 utilise des blocs de 16 éléments et des échelles E4M3. Les blocs plus fins donnent à NVFP4 une meilleure isolation des valeurs aberrantes, c'est pourquoi ce format est le standard de facto 4 bits sur les piles de service Blackwell.

Quel matériel en bénéficie — et lequel n'en bénéficie pas

Le fait le plus important à propos de cette configuration : NVFP4 est un format Blackwell. Il ne fait ses preuves que sur les GPU dont les cœurs tensoriels implémentent nativement le FP4 GEMM, et sur tout autre matériel, c'est un mauvais outil, quelle que soit la vitesse annoncée de la machine.

• Blackwell — RTX 50-series, B200/B300, RTX PRO 6000, DGX Spark (GB10) — c'est là que NVFP4 s'impose : cœurs tensoriels FP4 natifs, la plus petite empreinte de qualité serveur de la gamme non censurée, et le format pour lequel ce build a été conçu.

• Hopper — H100/H200 — pas de GEMM FP4 natif. NVFP4 se dégrade en un chemin de déquantisation poids uniquement, plus lent et sans aucun bénéfice. Utilisez Qwen3.8-27B-Uncensored-FP8 ici ; cette version est vérifiée sur exactement ce matériel.

• Ampere/Ada — RTX 3090/4090 — NVFP4 ne les accélère pas non plus. La version GGUF, avec son niveau Q4_K_M à 16,8 Go, est l'outil qu'il faut pour une carte de 24 Go.

• Apple Silicon — NVFP4 n'a pas d'importance sur un Mac. La version MLX (ou GGUF) est celle qui fonctionne.

Une nuance honnête : les forks communautaires exécutent bien du NVFP4 poids uniquement sur du matériel pré-Blackwell. Un build communautaire NVFP4 du même modèle abliteré est explicitement configuré pour les cartes de classe V100 via un fork vLLM patché, et les récentes recettes DGX Spark autour de Qwen3.8-27B sont une autre affaire. Ce sont des voies spécialisées avec leurs propres limites, pas ce que ce build vise. Si vous êtes sur Blackwell, rien de tout cela n'a d'importance ; si vous n'êtes pas sur Blackwell, le build FP8 ou GGUF est le meilleur téléchargement.

Comment le servir

Le dépôt est taggé pour vLLM, et le format compressed-tensors est lu automatiquement depuis config.json — on ne sélectionne pas manuellement un schéma de quantification. La pile sur laquelle convergent les praticiens pour les builds Qwen3.8-27B NVFP4 est un vLLM récent sur une carte Blackwell, un cache KV FP8, et la tête MTP du modèle utilisée pour le décodage spéculatif. Le guide NVFP4 d'Unsloth, qui est la référence communautaire la plus citée, recommande vLLM 0.25.0 ou une version plus récente avec FlashInfer et la dépendance au kernel CUTLASS-DSL pour la voie FP4 rapide.

Un point de départ fonctionnel, assemblé à partir des indicateurs vérifiés de notre build FP8 et des recettes NVFP4 de la communauté, le tout sur une seule ligne :

vllm serve orcarouter/Qwen3.8-27B-Uncensored-NVFP4 --kv-cache-dtype fp8 --max-model-len 262144 --reasoning-parser qwen3 --enable-auto-tool-choice --tool-call-parser qwen3_coder --speculative-config '{"method": "mtp", "num_speculative_tokens": 3}'

• FP8 KV cache — le moyen le plus largement compatible de réduire de moitié la mémoire cache ; les praticiens rapportent qu'il double à peu près le contexte que vous pouvez conserver. La prise en charge du cache KV NVFP4 existe mais est limitée à certains backends d'attention, donc FP8 KV est le choix par défaut le plus sûr.

• Décodage spéculatif MTP — le modèle embarque une tête de draft MTP, et la quantification la conserve en BF16. Les praticiens rapportent que deux à trois jetons de draft fonctionnent bien avec des poids NVFP4 sur Blackwell, avec les plus grands gains sur les sorties structurées comme JSON et les appels d'outils.

• Vision — l'encodeur de vision est conservé en BF16 dans cette version. Ajoutez --language-model-only pour servir le texte uniquement ; retirez-le si vous avez besoin d'une entrée image ou vidéo.

• Sur un DGX Spark — quelques pièges remontés du terrain : gardez --gpu-memory-utilization à 0,90 ou moins (des valeurs plus élevées ont figé la machine pendant le chargement des poids), et ajoutez --safetensors-load-strategy lazy si la mémoire est limitée. Vous aurez aussi besoin d'une build GB10 de vLLM pour les kernels sm_121a.

Des performances honnêtes : il n'existe aucun chiffre de débit publié et indépendant pour ce dépôt précis. Les mesures existantes concernent des builds NVFP4 étroitement liés. Unsloth rapporte 1,41 à 1,49× les tokens par seconde du BF16 sur un B200 pour son propre build Qwen3.8-27B-NVFP4 (89,8 à 133,7 tok/s à batch 1 ; 3 048 à 4 407 à batch 64), et un utilisateur de DGX Spark sur les forums NVIDIA rapporte environ 20 à 32 tok/s avec des poids NVFP4, un cache KV FP8 et une profondeur MTP de 3. Les deux méritent d'être cités ; aucun n'est un benchmark de ce dépôt.

Des modèles d'utilisation qui fonctionnent réellement

Les praticiens qui exécutent les modèles de la famille Qwen3.8-27B sur Blackwell convergent vers une poignée de réglages. Traitez-les comme des retours de terrain, pas comme des recommandations du fournisseur — Qw​en ne documente pas la plupart de ces éléments, et la fiche de ce dépôt est elle-même restreinte.

• reasoning_effort est le paramètre le plus important. La valeur xhigh par défaut fait réfléchir le modèle longtemps à chaque requête. Les personnes qui exécutent des boucles d'agent définissent medium par défaut et passent à low — ou désactivent entièrement la réflexion avec enable_thinking: false — pour les appels uniques sensibles à la latence. Sur une seule GPU Blackwell, le raisonnement xhigh sur une tâche de routine est ce qui fait qu'on a un modèle rapide et des réponses lentes.

• Les échantillonneurs sont associés au mode de réflexion, pas indépendants.Consensus de la communauté : la réflexion activée utilise une température de 1.0 / top_p de 0.95 ; la réflexion désactivée utilise une température de 0.7 / top_p de 0.80 avec presence_penalty de 1.5. Échanger les deux ensembles dégrade la qualité de la sortie.

• Utilisez un modèle de chat actuel. Le modèle qwen3_5 enveloppe chaque tour de l'assistant dans un bloc think, et plusieurs praticiens signalent des boucles ou des réponses tronquées avec des modèles obsolètes ; les variantes communautaires Qw​en-Fixed-Chat-Templates et Qw​en-Sharp définissent preserve_thinking et arrêtent les boucles. Si votre sortie servie divague au-delà du jeton d'arrêt, c'est la première chose à vérifier.

• Budget pour les traces de raisonnement longues dans le travail des agents. Les praticiens rapportent que le modèle de génération 3.8 émet environ deux fois plus de jetons par tâche que son prédécesseur 3.6 — l'amélioration de la qualité vient en partie d'un raisonnement plus long. Pour les réponses xhigh longues, diffusez la sortie du raisonnement, sinon vous rencontrerez des délais d'expiration de la passerelle.

• L'appel d'outil reste intact après la quantification. Le chemin d'appel de fonction survit à la fois à l'abliteration et à la conversion en 4 bits ; activez-le avec l'analyseur d'appels d'outils qwen3_coder et le modèle sélectionne les outils de la même manière que le modèle de base.

Qui devrait choisir ce build — et qui ne devrait pas

La décision honnête, sans répéter les calculs de sélection de quantification que nos articles FP8 et GGUF traitent déjà en détail :

• Choisissez NVFP4 si vous servez sur Blackwell et voulez la plus petite empreinte de niveau serveur de la gamme non censurée, avec la vitesse des cœurs tensoriels FP4 — et que vous effectuez des travaux de recherche, de red-team ou d'interprétabilité qui exigent légitimement un modèle abliterated.

• Choisissez Qwen3.8-27B-Uncensored-FP8 si vous êtes sur Hopper, ou si vous voulez le chemin vLLM le plus largement vérifié — ce sont les mêmes poids en 8 bits, vérifiés sur un H200, avec environ 40 Go de VRAM comme minimum.

• Choisissez Qwen3.8-27B-Uncensored-GGUF si vous êtes sur un GPU grand public ou un Mac, ou si vous voulez llama.cpp plutôt que vLLM — la déclinaison Q4_K_M est le meilleur choix en local.

• Ne choisissez ni l'un ni l'autre si vous voulez une fidélité maximale, si vous construisez quoi que ce soit destiné aux utilisateurs (voir la limite de sécurité ci-dessous), ou si vous ne voulez pas du tout auto-héberger — la même gamme non censurée est proposée via OrcaRouter, avec un accès réservé aux chercheurs, donc aucun GPU n'est requis.

La limite de sécurité — recherche uniquement

{{1}}Ceci est un modèle abliteré, et la version quantifiée ne remet pas les garde-fous en place.{{/1}} {{2}}La direction de refus a été retirée du flux résiduel de Qw​en/Qwen3.8-27B,{{/2}} et {{3}}NVFP4 est un changement de précision, pas une intervention de sécurité{{/3}} — le modèle accédera aux demandes que le modèle de base refuse, et cette version ne comporte aucune modération intégrée. {{4}}Il est publié pour la recherche en interprétabilité, en sécurité de l'IA et en red-teaming{{/4}} sous licence {{5}}Apache 2.0{{/5}}, et la responsabilité vous incombe.

{{1}}Deux remarques d'évaluation qui reviennent trop rarement dans l'espace des modèles non censurés.{{/1}} Premièrement, {{2}}une sonde de jailbreak unique qui réussit trivialement ne constitue pas une évaluation de sécurité concluante{{/2}} — les modèles abliterés échouent délibérément à ces tests. Mesurez ce qui vous importe réellement avec les batteries adéquates (AdvBench, HarmBench et StrongREJECT pour la nocivité ; XSTest-safe pour le sur-refus) et comparez les taux de refus avant et après l'intervention. Deuxièmement, {{3}}évaluez la quantification, pas seulement le modèle de base : une version 4 bits peut modifier le comportement sur des cas limites même lorsque les scores agrégés semblent corrects.{{/3}} {{4}}Ne déployez pas ceci auprès des utilisateurs finaux sans vos propres couches de modération et de prévention des abus.{{/4}}

Où OrcaRouter s'intègre

Une build quantifiée vieille de dix jours est le cas d'école pour le routage plutôt que le câblage en dur. Vous pouvez mettre en place une route qui pointe vers la build NVFP4 que vous exécutez vous-même et basculer vers un modèle hébergé si la build se comporte mal sous charge — une seule interface, aucun recâblage entre les fournisseurs lors du changement. OrcaRouter transmet le prix catalogue du fournisseur avec une marge de 0 %, donc si le prix du modèle sous-jacent change, votre endpoint le reflète le jour même plutôt que selon votre cycle de facturation.

Et si tout l'intérêt est d'éviter complètement de faire tourner un GPU : la même ligne non censurée est disponible via OrcaRouter, réservée aux chercheurs en sécurité et aux red teams, avec bascule automatique entre les fournisseurs. Que vous auto-hébergiez cette version NVFP4 ou que vous fassiez appel à la ligne hébergée, c'est une seule clé API dans les deux cas.

En résumé

Qwen3.8-27B-Uncensored-NVFP4 est le bon téléchargement si vous servez le modèle abliterated sur Blackwell et souhaitez la plus petite empreinte avec la vitesse des cœurs tensoriels FP4. C'est le mauvais téléchargement sur Hopper (utilisez la version FP8), sur un GPU grand public ou Apple (utilisez la version GGUF ou MLX), ou si vous avez besoin d'une fidélité maximale. Ce n'est pas nouveau — il est téléchargeable depuis le 19 août 2026 — mais il est téléchargé en volume, et maintenant vous savez dans quoi vous vous engagez avant d'accepter le portail.

Pas un autre build de ce modèle — Qwen3.8-Flash-Next-Uncensored est une version distincte : abliteré à partir de Qwen3.8-Flash-Next, un aperçu de l'architecture Qwen4 en mélange d'experts avec 176B paramètres stockés / 6B actifs. Même technique d'abliteration, poids différents, sa propre collection.

Les six builds 27B — BF16, GGUF, MLX, FP8, INT8 et NVFP4 — sont réunis dans la collection Qwen3.8-27B-Uncensored sur Hugging Face.

Ces poids sont locaux uniquement par conception. Pour une base de référence hébergée contre laquelle mesurer la version abliterée, Qwen3.8-27B est servi sur OrcaRouter au prix catalogue du fournisseur avec 0 % de marge — le modèle standard, alignement de sécurité intact.