
Qwen3.8-Flash-Next-Uncensored : Exécuter le MoE abliterated sur llama.cpp et Apple Silicon
- AlibabaNOUVEAUQwen: Qwen3.8 Flash2026-08-26$0.15 / $0.47 par million de tokens
- z-aiNOUVEAUZ.ai: GLM 5.3 Flash2026-08-2658Intelligence72Code
- DeepSeekNOUVEAUDeepSeek: DeepSeek V4 Flash Vision (Exp)2026-08-21$0.15 / $0.29 par million de tokens
- z-aiNOUVEAUZ.ai: GLM 5.32026-08-1860Intelligence75Code
- obsidianQwen3.8 27B2026-08-1552Intelligence68Code
- qwenQwen: Qwen3.8 27B (free)2026-08-13qwen/qwen3.8-27b-free
- deepseekDeepSeek: DeepSeek V4 Pro 08132026-08-1253Intelligence69Code
- grokSpaceXAI: Grok 4.62026-08-1261Intelligence77Code
- metaMeta: Muse Spark 1.22026-08-0557Intelligence72Code
- qwenQwen: Qwen3.8 Max2026-08-0358Intelligence72Code
- deepseekDeepSeek: DeepSeek V4 Flash 07312026-07-3152Intelligence69Code
- minimaxMiniMax: MiniMax-H32026-07-31minimax/minimax-h3
- qwenQwen: Qwen3.7 Flash2026-07-27$0.03 / $0.13 par million de tokens
- orcaOrcaDub: OrcaDub 1.02026-07-27orca/dub
- anthropicAnthropic: Claude Opus 52026-07-2463Intelligence78Code
- googleGoogle: Gemini 3.6 Flash2026-07-2152Intelligence69Code
- googleGoogle: Gemini 3.5 Flash-Lite2026-07-2137Intelligence49Code
- metaMeta: Muse Spark 1.12026-07-1653Intelligence71Code
- kimiMoonshotAI: Kimi K32026-07-1560Intelligence76Code
- openaiOpenAI: GPT-5.6 Luna2026-07-0952Intelligence71Code
Avant de télécharger quoi que ce soit : Qwen3.8-Flash-Next-Uncensored n'est pas Qwen3.8-27B-Uncensored. Ils partagent un nom de famille et une technique d'abliteration, mais ce sont des modèles différents issus de versions de poids distinctes, et tous les articles « Qwen uncensored » précédemment publiés sur ce blog concernent la 27B. Le sujet ici est la paire qu'OrcaRouter a publiée sur Hugging Face le 26 août 2026 — orcarouter/Qwen3.8-Flash-Next-Uncensored-GGUF et orcarouter/Qwen3.8-Flash-Next-Uncensored-MLX — des builds abliterés de Qwen3.8-Flash-Next, le modèle de mélange d'experts routé d'Alibaba, 176B stockés / 6B actifs, qui préfigure l'architecture Qwen4. Nous avons annoncé cette sortie comme « GGUF + MLX natif, jusqu'à 262K de contexte », destinée aux chercheurs en sécurité, aux red teams et aux blue teams. Ce runbook est rédigé à partir de nos propres model cards : ce que fait la suppression des refus dans un MoE routé, ce que la promesse de 262K de contexte coûte réellement en mémoire, comment servir les deux lignes de fichiers, et où se situe la ligne de recherche. Si vous êtes arrivé ici en cherchant l'introduction à l'abliteration ou les calculs de quantification de la 27B, les articles précédents de cette série les couvrent.

D'abord, la porte.
Les deux dépôts sont soumis à un contrôle d'accès sur Hugging Face (gated: auto). Aucun téléchargement de fichier n'est possible tant que vous n'êtes pas connecté et n'avez pas accepté les conditions de chaque dépôt — les dépôts GGUF et MLX ont chacun leur propre contrôle d'accès. C'est la différence la plus concrète par rapport à une ligne GGUF non restreinte : la commande naïve en une ligne « hf download » échoue avec une erreur d'authentification avant même de récupérer un octet. Le flux est le suivant :
• Connectez-vous à Hugging Face (ou inscrivez-vous) et installez huggingface_hub, puis exécutez hf auth login une fois pour que votre token soit sur le disque.
• Ouvrez orcarouter/Qwen3.8-Flash-Next-Uncensored-GGUF dans le navigateur, acceptez les conditions, puis répétez pour orcarouter/Qwen3.8-Flash-Next-Uncensored-MLX.
• À partir de là, hf download avec votre jeton d’authentification fonctionne comme n’importe quel autre dépôt. Chaque quant que vous récupérez, ainsi que les poids MLX, est un artefact de recherche sous licence Apache-2.0 — la même licence que le modèle de base — et le portail fait partie de l’accord : lire les conditions est la première étape de l’utilisation du modèle.

Ce que l'abliteration fait à un MoE routé
La technique est la modification de poids de style Arditi que nous avons déjà abordée ailleurs sur ce blog ; ce qui est intéressant, c'est ce qu'elle fait spécifiquement à cette architecture. Sur le modèle dense de 27B, il s'agissait de 131 matrices résiduelles. Sur Qwen3.8-Flash-Next-Uncensored, la fiche du modèle MLX indique que l'abliteration a été appliquée à 149 tenseurs d'écriture résiduelle, et les composants qui font de ce modèle ce qu'il est — le routeur MoE, la table d'incorporation de n-grammes de 51B, la tour de vision — n'ont explicitement jamais été touchés.
Ce « jamais touché » résume toute l’histoire pour un modèle routé. Chaque jeton active 10 des 512 experts ; aucun expert ne possède le refus à lui seul. Le comportement de refus réside dans le flux résiduel qui compose la sortie finale, et c’est précisément la direction que l’orthogonalisation supprime. Ainsi, le routeur continue de router les mêmes experts, la table de n-grammes continue de produire les mêmes plongements, et ce qui change, c’est ce que le modèle dit une fois la projection de sortie exécutée. Les contrôles publiés sur la fiche du modèle GGUF présentent la forme de ce changement comme une baisse du refus sur invites nuisibles, de 64 à 100 % sur la base à environ 0 à 3,3 % sur cette version, un sur-refus bénin proche de 0 %, et des capacités à ±2 points de la base sur les contrôles de type MMLU-Pro / GSM8K / CMMLU. Ce sont les chiffres de la fiche elle-même, autodéclarés et non reproduits indépendamment.
La tête MTP : présente dans MLX, supprimée dans GGUF.
Qwen3.8-Flash-Next embarque une tête spéculative de prédiction multi-tokens d'environ 4B, et les deux builds divergent sur ce point. Le dépôt GGUF l'exclut — la fiche est explicite : ces fichiers n'incluent pas la tête de draft spéculative MTP — car le support de qwen4exp dans llama.cpp n'implémente pas encore MTP, donc la tête serait un poids mort dans le fichier. Le build MLX la conserve, donc sur Apple Silicon vous bénéficiez toujours du décodage spéculatif. La conséquence pratique, corroborée par les praticiens qui exécutent le modèle de base : la voie GGUF de llama.cpp fonctionne aujourd'hui sans décodage spéculatif, tandis qu'une configuration SGLang avec MTP plus que double le décodage sur la même classe de matériel. Si llama.cpp implémente un jour MTP pour qwen4exp, la ligne GGUF obtiendra une accélération gratuite — mais n'achetez pas de matériel en espérant que ce soit cette semaine.
L'affirmation concernant le contexte 262K, et ce que coûte le cache KV.
Le contexte natif est de 262 144 jetons (extensible via YaRN vers 1M), et la contrainte qui pèse réellement est la mémoire. La bonne nouvelle, c'est que l'architecture maintient le cache KV compact : sur les 48 couches, 36 utilisent l'attention linéaire Gated DeltaNet, qui compresse l'historique dans un état récurrent de taille fixe, et seules les 12 couches d'attention complète portent un cache KV conventionnel qui croît avec la longueur de la séquence.
Deux points de données mesurés par la communauté, tous deux sur le modèle de base, se transfèrent directement. Un déploiement GGUF sur 4× RTX 3090 a rapporté un passage de 65K à 131K de contexte avec seulement ~0,78 Go par carte de KV supplémentaire, et un seul DGX Spark a exécuté un contexte complet de 262K avec un fichier de classe Q4 tout en maintenant le modèle résident à ~76,9 Go de son pool de 128 Go en épinglant la table n-gram sur le CPU et en la mappant en mémoire (mmap) depuis le NVMe. La ligne de budget de la carte du modèle GGUF est : total = taille du fichier + cache KV + le mmproj d'environ 0,9 Go. En résumé pour le choix de quantification : à 262K, le cache KV est un poste réel, mais les poids sont le poste dominant, donc la même logique de priorité VRAM du guide GGUF 27B s'applique — la différence ici réside dans les tailles de fichiers elles-mêmes, qui vont d'IQ2_XXS à environ 52 Go à Q5_K_M à environ 125 Go.
La gamme GGUF : 13 quants, fichiers fractionnés, mmproj et une compilation llama.cpp
Le dépôt GGUF fournit 13 niveaux de quantification — IQ2_XXS, IQ2_M, IQ3_XXS, IQ3_M, IQ4_XS, Q2_K, Q3_K_S, Q3_K_M, Q3_K_L, Q4_K_S, Q4_K_M, Q5_K_S, Q5_K_M — les quantifications IQ étant construites à partir d'une matrice d'importance sur des textes de calibration en anglais, en chinois et en code. Chaque quant est en plusieurs parties, découpé avec llama-gguf-split, donc téléchargez l'ensemble complet pour un quant et pointez le chargeur vers la partie ...-00001-of-000NN.gguf. Il n'y a pas de palier Q6_K, Q8_0 ou F16, et la raison est structurelle plutôt qu'économique : la table d'embedding n-gram (PLE) est un tenseur trop volumineux pour satisfaire la limite de 50 Go par fichier de Hugging Face à 6 bits et plus, et un tenseur GGUF unique ne peut pas être divisé entre plusieurs fichiers — si bien que la gamme s'arrête au Q5_K_M.
L'autre fichier à ne pas ignorer est mmproj-...-F16.gguf, environ 0,9 Go : il s'agit d'un modèle vision-langage, et llama.cpp a besoin du projecteur pour toute entrée d'image. Qwen3.8-Flash-Next est multimodal, tout comme cette version — l'ablitération ne touche pas à la tour de vision.
Le support de llama.cpp n'est pas encore dans la version principale. L'identifiant d'architecture est qwen4exp, et les compilations standard échouent avec « unknown architecture 'qwen4_exp' » ; vous avez besoin d'une compilation de la PR #27742 (branche qwen4exp/qwen3.8-flash-next), compilée avec les cibles llama-cli, llama-mtmd-cli, llama-server et llama-gguf-split. Ensuite, la forme de service est le serveur llama.cpp habituel avec des options spécifiques à Qwen, utilisant le nom de quantification des fichiers de pièces :
llama-server -m Qwen3.8-Flash-Next-Uncensored-Q4_K_M-00001-of-00003.gguf --jinja --mmproj mmproj-Qwen3.8-Flash-Next-Uncensored-F16.gguf -c 8192 --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0
Définissez `-c` sur le contexte que vous pouvez contenir ; l'exemple de la fiche commence à 8192. Le raisonnement est activé par défaut et renvoyé dans `reasoning_content`, et l'appel d'outils fonctionne via le point de terminaison compatible OpenAI. Les valeurs d'échantillonnage ci-dessus sont la recommandation de la fiche du modèle ; les praticiens sur le modèle de base utilisent temp 0.7 / top-p 0.80 / top-k 20 avec une pénalité de présence de 1.5 en mode instruct sans réflexion, et ajustent la profondeur du raisonnement avec `--chat-template-kwargs {"reasoning_effort":"medium"}`.
Le build MLX sur Apple Silicon
Le dépôt MLX est la voie native Apple Silicon : mêmes poids, même suppression des refus, un runtime natif Metal. Il fournit la version 4 bits par défaut (~163 Go), la version 6 bits annoncée (~192 Go) et un palier 8 bits (~221 Go), et parce que les experts 3D fusionnés et la table n-gram sont conservés à une précision supérieure à l'étiquette nominale, la précision effective dépasse largement le 4 bits uniforme — la fiche indique ~7,85 bits effectifs par poids pour l'étiquette « 4 bits ». C'est pourquoi les tailles du dépôt paraissent élevées : la table n-gram n'est pas écrasée comme le font les quants de la communauté.

Le matériel est la contrainte limitante. MLX ne fonctionne que sur Apple Silicon (Metal), et vous avez besoin de mémoire unifiée pour les poids — la fiche du modèle indique « un Mac avec suffisamment de mémoire unifiée pour les 163 GB de poids (par exemple M-series Ultra) ». Traitez le palier 4-bit comme une machine de classe 192 GB et la version 6-bit comme une machine de classe 256 GB. Les tags de la fiche répertorient l'ensemble complet des fonctionnalités — qwen4_exp, MoE, MTP, function calling, vision-language — et elle est pilotée via mlx-vlm pour l'entrée d'images. La tête spéculative MTP est incluse ici, ce qui constitue l'avantage discret de la version MLX par rapport à la ligne GGUF.
Le chemin de vision, pour ceux qui l'utilisent
Comme il s'agit d'un modèle vision-langage, le chemin multimodal fait partie du runbook plutôt que d'une option supplémentaire. Sur llama.cpp, l'entrée d'images nécessite à la fois le projecteur mmproj et une compilation qui inclut llama-mtmd-cli / llama-server. Sur MLX, on le pilote avec mlx-vlm plutôt qu'avec le pilote texte seul mlx-lm. Pour les red teams, le chemin vision est là où se trouve le travail d'évaluation intéressant : garde-fous multimodaux, injection de prompt portée par une image, OCR sur des captures d'écran de vos propres systèmes, et images adversariales ciblant l'ensemble du pipeline. Étant donné que l'abliteration couvre le modèle complet et laisse la tour de vision intacte, une image qui aurait déclenché un refus dans la tête texte atterrit simplement sur un modèle sans comportement de refus à déclencher. La fiche GGUF indique que la vision et l'appel d'outils multi-tours ont été vérifiés sur cette compilation ; aucune suite d'évaluation vision distincte n'est publiée.
À quoi cela sert, et où se situe la ligne.
Cette version existe pour une seule catégorie de travail : évaluer ce qu’un modèle dont les refus ont été retirés peut faire, au service de la compréhension et de la défense des systèmes. Pour une équipe rouge, cela signifie tester vos propres garde-fous contre un modèle qui ne refusera pas poliment — résistance à l’injection de prompts, scénarios d’exfiltration, abus d’utilisation d’outils, et l’écart entre « le modèle de base refuse » et « le modèle ne peut en réalité pas le faire ». Cet écart constitue toute la valeur de recherche d’une build abliterated : elle vous révèle ce que la couche de refus dissimulait, à savoir la différence entre la sécurité par politique et la sécurité par capacité. Pour une équipe bleue, ces mêmes poids constituent la base plausible de l’adversaire : si un acteur hostile peut télécharger et exécuter ce modèle, vos défenses doivent tenir face à un modèle qui répond au lieu de se dérober. Les évaluations qui s’appuient dessus constituent une borne inférieure de ce qu’un modèle personnalisé, jamais aligné, pourrait faire — traitez-les comme telles, pas comme un plafond.
Soyons clairs sur ce que la suppression des refus change et ne change pas. Elle change le comportement de sortie — le modèle ne refuse plus — et elle ne change pas les capacités. Pas de nouvelles connaissances, pas de nouvelles compétences, pas de nouveaux calculs ; la même formation, les mêmes limites sur ce que le modèle peut réellement produire. Un modèle abliteré ne peut pas concevoir un logiciel malveillant qu'il était incapable de créer auparavant ; il répond simplement au lieu de se dérober, et ses sorties ne sont pas plus véridiques parce qu'elles sont plus permissives. La plage de capacité de ±2 points de la carte et l'effondrement des chiffres de refus sont le même fait vu sous deux angles.
Là où se situe la limite, c'est l'accord de dépôt à accès contrôlé, et ce n'est pas une clause type. Usage légitime : évaluer vos propres systèmes, mener des recherches publiques de vulnérabilités sur les modèles, concevoir des évaluations de détection et de défense, étudier les mécanismes de refus. Usage illégitime : déployer ceci comme assistant orienté utilisateur, générer des logiciels malveillants fonctionnels ou des exploits contre des systèmes que vous ne possédez pas ou que vous n'êtes pas autorisé à tester, fraude, matériel militaire. La licence Apache-2.0 et le droit applicable constituent le plancher ; la barrière est l'accord explicite à finalité de recherche qui s'y superpose. Si votre cas d'usage est « livrer un chatbot aux utilisateurs », ce modèle n'est pas pour vous — et c'est voulu, pas un oubli.
Comment obtenir la référence servie
Ces poids sont volontairement locaux uniquement : les charges utiles de sonde d’une équipe rouge ne doivent jamais transiter par une API tierce, et l’auto-hébergement est tout l’intérêt. Lorsque vous voulez la baseline servie et censurée pour comparaison — le Qwen3.8-Flash d’Alibaba à 0,16 $ par million d’entrées et 0,47 $ par million de sorties — OrcaRouter l’achemine au prix catalogue du fournisseur avec une marge de 0 % et une bascule automatique, afin qu’un harnais d’évaluation puisse passer de la base hébergée à votre build local non censuré avec une seule clé et aucun second contrat. Les poids ouverts Qwen3.8-Flash-Next ne sont pas encore à notre catalogue ; lorsqu’un runtime que nous acheminons les prend en charge, ils atterrissent dans cette même configuration à une seule clé et au prix catalogue.
Commencez ici
Décidez quelle ligne correspond à votre matériel, puis lisez la porte concernée. Sur un Mac à mémoire unifiée de 128 Go ou plus, la version MLX vous donne MTP et la vision au même endroit — acceptez les conditions du dépôt MLX, récupérez les poids 4 bits ou 6 bits, et pilotez-les avec mlx-vlm. Sur une machine NVIDIA, AMD ou CPU, compilez llama.cpp à partir de la PR #27742, acceptez les conditions du dépôt GGUF, récupérez une quantification adaptée, et n'oubliez pas le fichier mmproj. Dans les deux cas, les chiffres de refus et la bande de capacité appartiennent au dépôt, publiés sur la fiche et non reproduits à ce jour — la façon honnête de les lire est d'y voir une mesure par le vendeur de sa propre modification, et non un audit indépendant. La porte, la licence et la limite de sécurité ci-dessus sont le même texte vu sous trois angles : c'est un instrument de recherche, et il est publié à cette condition.
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.
À ne pas confondre avec la famille 27B : Qwen3.8-27B-Uncensored est un modèle différent, abliterated à partir d'une base différente, avec sa propre collection et ses propres runbooks. Même technique, des poids différents.
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.
