Qwen3.8-27B-Uncensored Benchmarks : le refus s'effondre, la capacité reste

L'histoire des benchmarks de Qwen3.8 27B Uncensored (Aggressive) — la version abliterated de Qwen3.8 27B publiée en tant que checkpoint FP8 le 15 août 2026 et en build GGUF le 16 août — n'est pas qu'il est devenu plus fort. C'est qu'il a cessé de refuser. La fiche du modèle rapporte que le taux de refus des invites nuisibles chute de 64–99 % sur le modèle de base à 0–6 % sur la version abliterated avec le raisonnement désactivé, et à 1,7 % ou moins avec le raisonnement activé, tandis que tous les benchmarks de capacités se situent à ±1,3 points du modèle de base et que la perplexité WikiText-2 est de 6,96. Si vous êtes ici pour les benchmarks qwen uncensored, ce sont les chiffres clés : ce n'est pas un modèle plus intelligent, c'est un modèle qui ne refuse pas.

Cette distinction compte, car la plupart de ce qui se classe dans les « benchmarks non censurés » est soit un listicle superficiel de scores de capacités, soit un post de hype prétendant que le modèle est « meilleur ». Or, ce n'est pas ce que fait l'abliteration. Cet article parcourt les données mesurées réelles — effondrement des refus, sur-refus, rétention des capacités et perplexité —, la méthode qui les a produites, et la limite de sécurité que vous devriez lire avant de toucher aux poids.

Ce que mesure réellement un tour d'horizon de benchmarks non censurés

Une évaluation de modèle ordinaire ne porte que sur un axe : la capacité — MMLU, GSM8K, codage, raisonnement. Un modèle abliteré est intéressant sur un autre axe, et toute la raison d'être de l'étiquette « non censuré » est que l'axe de sécurité s'est déplacé. Donc la question utile pour Qwen3.8-27B-Uncensored-FP8 n'est pas « est-il plus intelligent ? » mais « qu'a coûté la suppression du mécanisme de refus, et dans quelle mesure a-t-elle été complète ? »

Trois familles de chiffres doivent être lues ensemble. Taux de refus sur les benchmarks de prompts dangereux — à quelle fréquence le modèle refuse ; plus le taux de base est élevé, plus le retrait est visible. Sur-refus sur les prompts bénins — à quelle fréquence il refuse à tort une requête innocente ; plus c'est bas, mieux c'est pour tout le monde. Et le maintien des capacités — si la modification a dégradé le modèle. Un résumé de benchmark qui n'affiche que les scores de capacités répond à la mauvaise question.

La méthode : l'abliteration est une modification des poids, pas un fine-tuning.

Ce qui distingue l’ablitération des packs « jailbreak » communautaires, c’est l’endroit où le changement opère. Un jailbreak au niveau du prompt enveloppe l’entrée ; l’ablitération modifie les poids. La méthode provient d’Arditi et al. (2024), « Refusal in Language Models Is Mediated by a Single Direction ». La découverte centrale est que le comportement de refus dans de nombreux modèles est piloté par une seule direction dans le flux résiduel — estimez cette direction, supprimez-la, et le modèle cesse de refuser sans être ré-entraîné.

Concrètement, la carte décrit l'estimation d'une direction de refus à partir de la différence moyenne des résidus du dernier token (nuisibles moins inoffensifs), masquée par les activations massives, à la couche 38 (round(0.6 × 64)), en utilisant AdvBench comme ensemble nuisible et Alpaca comme ensemble inoffensif. La modification est une orthogonalisation, W′ = W − r(rᵀW), calculée en float32 et appliquée à 131 matrices d'écriture de résidus — les projections de sortie de l'attention, les projections de sortie de l'attention linéaire, les projections descendantes du MLP, et l'espace des lignes du plongement. Aucune étape d'entraînement n'est exécutée ; la tour de vision est laissée intacte ; la tête de décodage spéculatif MTP est ablatée de manière cohérente. C'est pourquoi la capacité survit : supprimer une direction est une intervention bien plus douce que d'affiner le modèle pour le rendre conforme.

Le refus s'effondre : les chiffres

Mesuré sur la build FP8 servie par vLLM et publié sur la fiche du modèle Hugging Face (2026-08-15), le taux de refus sur les benchmarks de prompts nuisibles passe de 64–99 % sur la base à 0–6 % sur la build non censurée avec la réflexion désactivée :

• AdvBench — 99.0% → 0.0%

• JailbreakBench (dangereux) — 94.0% → 0.0%

• StrongREJECT — 97.3% → 2.0%

• HarmBench (standard) — 98,7 % → 2,7 %

• MaliciousInstruct — 99,0 % → 0,0 %

• SimpleSafetyTests — 64,0 % → 6,0 %

• ForbiddenQuestions — 73,3 % → 4,7 %

Avec le raisonnement activé, le refus est essentiellement inexistant — 1,7 % sur AdvBench et 0,0 % sur la plupart du reste. La fiche ajoute une réserve honnête : 30 à 50 % des réponses préfixent encore un bref avertissement. C'est un artefact d'entraînement, pas un refus — le modèle répond, mais adoucit son introduction. Cela se lit comme une friction, pas comme une sécurité.

Le sur-refus est lui aussi un échec.

Le chiffre moins connu se situe de l'autre côté de l'axe de sécurité. Sur XSTest-safe — 250 invites bénignes que les modèles alignés refusent parfois à tort — le modèle de base sur-refuse 5,6 % du temps. La build non censurée sur-refuse 0,4 %. Supprimer la direction de refus n'empêche pas seulement le modèle de refuser des requêtes nuisibles ; cela l'empêche aussi de refuser des requêtes inoffensives qu'il signalait auparavant par sur-généralisation. Pour quiconque construit des outils d'évaluation ou de red team où une base sans refus est l'objectif, c'est une réelle amélioration de l'outil, et non un effet secondaire à excuser.

La capacité est préservée, pas améliorée.

C'est ici que meurt le cadrage « non censuré = plus fort ». La fiche du modèle compare la version FP8 abliterée à la FP8 de base officielle, avec les mêmes scripts et réglages :

• MMLU (0-shot) — 84,3% → 84,7%

• GSM8K (CoT) — 90.0% → 88.7%

MMLU-Pro (CoT) — 77,6 % → 76,8 %

• CMMLU (0-shot, chinois) — 81,4 % → 80,8 %

Chaque score se situe à ±1,3 points de la base, et la perplexité brute WikiText-2 s'élève à 6,96 — la preuve apportée par la fiche que la modélisation du langage elle-même ne s'est pas dégradée. La lecture honnête : l'abliteration est quasi neutre en termes de capacités sur cette architecture. Vous n'obtenez pas un meilleur modèle ; vous obtenez le même modèle sans le comportement de refus.

Le même avertissement s'applique à l'écosystème plus large : les affirmations « lossless uncensored » sur les builds communautaires méritent une lecture sceptique. Une comparaison à trois sur un build open-weight de 4B sur Hugging Face a révélé que la technique qui prétendait être sans perte a en réalité fait chuter TruthfulQA d'environ 7 points et Lambada d'environ 4, tandis que son taux de réussite d'attaque HarmBench atteignait 100 % ; les deux autres méthodes se situaient à 99,2 % et 95,5 %. Et un essai agressif sur un autre build a obtenu zéro refus mais a produit une salade de mots incohérente, si bien que la version livrée a reculé vers des paramètres par couche plus doux. Les résultats d'abliteration sont spécifiques à la méthode — ces chiffres correspondent spécifiquement aux données de la fiche du build FP8.

Ce que la carte ne prétend pas

Lisez la méthodologie avant de citer les chiffres. La carte indique que sa mesure du refus est « indicative, pas un chiffre de niveau juge-LLM / publication » : le refus a été évalué par un classificateur de phrases d'ouverture basé sur des règles, avec un compartiment « avertissement » distinct pour les réponses qui se conformaient mais ajoutaient une clause de non-responsabilité. Les benchmarks sont limités au texte, exécutés contre la compilation FP8 servie par vLLM avec le modèle de langue uniquement, et la suite de capacités utilisait des scripts d'évaluation standard. Le bon cadre : il s'agit des données mesurées par le fournisseur lui-même, reproductibles à partir de la carte publiée — pas d'un exécution tierce indépendante, et pas d'une affirmation concernant la compilation GGUF, qui est livrée quantifiée pour llama.cpp et doit être évaluée séparément.

La limite de sécurité

Voici la partie qui ne peut pas être édulcorée. Un modèle abliterated a vu son mécanisme de refus en grande partie supprimé. Concrètement : il accédera à des requêtes nuisibles, contraires à l'éthique ou illégales que le modèle de base Qwen3.8 27B refuserait, et il ne dispose d'aucun garde-fou intégré digne de ce nom. Les utilisations légitimes sont la recherche — l'interprétabilité (l'étude de la manière dont les directions de refus sont encodées), l'étude de la sécurité de l'IA et des mécanismes de refus, le red-teaming (le fait de sonder les modèles avec des entrées tentant de contourner leurs garde-fous) et l'évaluation de la robustesse. Il est publié sous licence Apache 2.0, héritée du modèle de base, strictement comme artefact de recherche. Vous assumez l'entière responsabilité — y compris juridique — de votre utilisation et de tout ce qu'il génère. Ne le déployez pas auprès d'utilisateurs finaux ni en production sans vos propres couches de sécurité, de modération et de prévention des abus — et pour tout usage en production ou destiné aux consommateurs, le Qwen3.8 27B standard est le modèle qu'il vous faut.

Quand un benchmark non censuré est ce qu'il ne faut pas rechercher

Si votre question est « quel modèle est le plus fort en maths ou en code ? », vous lisez les mauvais chiffres — la version non censurée n’est pas une amélioration de capacité. Si votre application doit refuser les demandes nuisibles, ce modèle est tout le contraire de ce qu’il vous faut. Si vous commercialisez un produit, ne construisez pas sur un checkpoint « abliterated ». Et si ce que vous cherchez vraiment, c’est un jailbreak, c’est une tout autre affaire — les packs au niveau du prompt se situent en dehors de l’intervention au niveau des poids décrite ici et ne font pas l’objet de cet article. Les données de benchmark de cet article n’existent que pour répondre à une question précise et légitime : ce que produit la suppression du refus sur un Qwen3.8 27B, mesuré.

Comment y accéder

Les deux versions sont sur Hugging Face sous licence Apache 2.0 : orcarouter/Qwen3.8-27B-Uncensored-FP8 (block-FP8 E4M3, environ 30,9 Go de poids, servi sur le chemin du noyau FP8 standard de vLLM avec un contexte de 262K, outils, réflexion et MTP intacts) et orcarouter/Qwen3.8-27B-Uncensored-GGUF (F16 plus 12 niveaux de quantification pour llama.cpp, avec Q4_K_M à 16,8 Go comme valeur par défaut recommandée pour un GPU de 24 Go). La fiche du modèle sur OrcaRouter contient les tarifs et les détails des benchmarks — la version non censurée y est répertoriée sous le nom obsidian/Qwen3.8-27B à 0,40 $ par million de jetons en entrée et 4,21 $ par million de jetons en sortie, avec un contexte de 262K, et l'accès est réservé aux chercheurs en sécurité, aux red teams et aux chercheurs en sécurité de l'IA.

En résumé

Les benchmarks « qwen uncensored » répondent à une question étroite, et la réponse est nette : supprimer le refus de Qwen3.8 27B via l'abliteration préserve les capacités à ±1,3 points près, tandis que le refus sur les invites nuisibles s'effondre, passant de 64–99 % à 0–6 %, que le sur-refus chute de 5,6 % à 0,4 % et que la perplexité se maintient à 6,96. Lisez ces chiffres comme « ne refuse pas », jamais comme « plus fort ». Pour la recherche en interprétabilité, en sécurité et en red team, c'est exactement l'outil que décrit la fiche du modèle. Pour tout ce qui se retrouve face à un utilisateur, c'est le mauvais modèle par construction.

Pour une utilisation légitime à des fins de recherche, les poids sont disponibles sur Hugging Face sous licence Apache 2.0 — orcarouter/Qwen3.8-27B-Uncensored-FP8 (la version GGUF pour llama.cpp est disponible à l'adresse orcarouter/Qwen3.8-27B-Uncensored-GGUF).