Qwen3.8-Flash-Next-Uncensored: Voer de Abliterated MoE uit op llama.cpp en Apple Silicon

Voordat je iets downloadt: Qwen3.8-Flash-Next-Uncensored is niet Qwen3.8-27B-Uncensored. Ze delen een familienaam en een abliteratietechniek, maar het zijn verschillende modellen van verschillende weight drops, en elke eerdere "Qw​en uncensored" post op deze blog gaat over de 27B. Het onderwerp hier is het paar dat OrcaRouter op 26 augustus 2026 op Hugging Face publiceerde — orcarouter/Qwen3.8-Flash-Next-Uncensored-GGUF en orcarouter/Qwen3.8-Flash-Next-Uncensored-MLX — geablitereerde builds van Qwen3.8-Flash-Next, Alibaba's 176B-opgeslagen / 6B-actief gerouteerd mixture-of-experts-model dat vooruitblikt op de Qwen4-architectuur. We kondigden de drop aan als "GGUF + native MLX, tot 262K context," gericht op beveiligingsonderzoekers, red teams en blue teams. Dit runbook is geschreven op basis van onze eigen modelkaarten: wat refuseverwijdering doet binnen een gerouteerde MoE, wat de 262K-contextclaim daadwerkelijk aan geheugen kost, hoe je beide bestandslijnen serveert, en waar de onderzoekslijn zich bevindt. Als je hierheen kwam voor de abliteratie-inleiding of de 27B-quantmath, dan behandelen de eerdere posts in deze serie die.

Eerst de poort

Beide repos zijn gated op Hugging Face (gated: auto). Er worden geen bestanden gedownload totdat je bent ingelogd en de repositoryvoorwaarden op elk repo hebt geaccepteerd — de GGUF- en MLX-repos hebben elk hun eigen gate. Dit is het meest praktische verschil met een niet-gated GGUF-lijn: de naïeve one-liner 'just hf download' mislukt met een authenticatiefout voordat er ook maar één byte wordt opgehaald. De flow is:

• Log in bij Hugging Face (of meld je aan) en installeer huggingface_hub, voer daarna eenmalig hf auth login uit zodat je token op schijf staat.

• Open orcarouter/Qwen3.8-Flash-Next-Uncensored-GGUF in de browser, accepteer de voorwaarden en herhaal dit voor orcarouter/Qwen3.8-Flash-Next-Uncensored-MLX.

Vanaf dat moment werkt hf download met je geverifieerde token net als elke andere repo. Elke quant die je binnenhaalt, en de MLX-gewichten, is een onderzoeksartefact onder Apache-2.0 — dezelfde licentie als het basismodel — en de poort is onderdeel van de deal: het lezen van de voorwaarden is stap één bij het gebruik van het model.

Wat abliteration doet met een gerouteerde MoE

De techniek is de Arditi-stijl gewichtsbewerking die we elders op deze blog hebben behandeld; het interessante deel is wat het specifiek met deze architectuur doet. Op de dichte 27B waren het 131 residu-matrices. Op Qwen3.8-Flash-Next-Uncensored vermeldt de MLX-modelkaart abliteratie toegepast op 149 residu-schrijver-tensoren, en de componenten die dit model tot wat het is maken — de MoE-router, de 51B n-gram inbedtabel, de vision-toren — werden expliciet nooit aangeraakt.

Dat 'nooit aangeraakt' is het hele verhaal voor een gerouteerd model. Elke token activeert 10 van de 512 experts; geen enkele expert is eigenaar van de weigering. Het weigeringsgedrag huist in de residustroom die de uiteindelijke output samenstelt, en dat is precies de richting die de orthogonalisatie verwijdert. Dus de router blijft dezelfde experts routeren, de n-gramtabel blijft dezelfde embeddings produceren, en wat verandert is wat het model zegt zodra de outputprojectie draait. De gepubliceerde evaluaties op de GGUF-modelkaart geven de vorm van die verandering weer als: weigering op schadelijke prompts die daalt van 64–100% op de basisversie naar ongeveer 0–3,3% op deze build, overmatige weigering bij goedaardige prompts nabij 0%, en prestaties binnen ±2 punten van de basisversie op MMLU-Pro / GSM8K / CMMLU-achtige evaluaties. Dit zijn de eigen cijfers van de kaart, zelfgerapporteerd in plaats van onafhankelijk gereproduceerd.

De MTP-head: aanwezig in MLX, verwijderd in GGUF

Qwen3.8-Flash-Next wordt geleverd met een speculatieve head van ~4B voor multi-token-predictie, en de twee builds zijn het er niet over eens. De GGUF-repo sluit deze uit — de modelkaart vermeldt expliciet dat deze bestanden de mtp-speculatieve-draft-head niet bevatten — omdat llama.cpp's qwen4exp-ondersteuning MTP nog niet implementeert, dus de head zou dood gewicht in het bestand zijn. De MLX-build behoudt deze, dus op Apple Silicon krijg je nog steeds speculatieve decoding. Het praktische gevolg, bevestigd door gebruikers die het basismodel draaien: de llama.cpp GGUF-lijn draait vandaag zonder speculatieve decoding, terwijl een met MTP uitgeruste SGLang-opstelling de decode op dezelfde klasse hardware meer dan verdubbelt. Als llama.cpp ooit MTP voor qwen4exp implementeert, krijgt de GGUF-lijn een gratis snelheidswinst — maar koop geen hardware in de verwachting dat het deze week gebeurt.

De 262K contextclaim, en wat de KV-cache kost

De native context is 262.144 tokens (via YaRN uitbreidbaar naar 1M), en de beperking die daadwerkelijk knelpunten vormt is geheugen. Het goede nieuws is dat de architectuur de KV-cache klein houdt: van de 48 lagen gebruiken er 36 Gated DeltaNet lineaire aandacht, die geschiedenis comprimeert in een recurrente toestand van vaste grootte, en slechts de 12 volledige-aandachtlagen dragen een conventionele KV-cache die met de sequentielengte meegroeit.

Twee door de community gemeten datapunten, beide op het basismodel, zijn direct overdraagbaar. Een 4× RTX 3090 GGUF-implementatie meldde een toename van 65K naar 131K context met slechts ~0,78 GB per kaart aan extra KV, en een enkele DGX Spark draaide volledige 262K context met een Q4-klasse bestand, terwijl het model in het geheugen bleef met ~76,9 GB van zijn 128 GB pool door de n-gram-tabel aan de CPU te pinnen en deze via mmap vanaf NVMe te laden. De eigen budgetregel van de GGUF-modelkaart is totaal = bestandsgrootte + KV-cache + de ~0,9 GB mmproj. De conclusie voor de quant-keuze: bij 262K is de KV-cache een echte budgetpost, maar de gewichten zijn de dominante factor, dus dezelfde VRAM-eerst-logica uit de 27B GGUF-gids is van toepassing — het verschil hier zit in de bestandsgroottes zelf, die variëren van IQ2_XXS met ongeveer 52 GB tot Q5_K_M met ongeveer 125 GB.

De GGUF-lijn: 13 quants, gesplitste bestanden, mmproj en een llama.cpp-build

De GGUF-repo bevat 13 quantisatieniveaus — 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 — waarbij de IQ-quants zijn gebouwd op basis van een importantiematrix met Engelse, Chinese en code-kalibratietekst. Elk quant is meerdelig, gesplitst met llama-gguf-split, dus download de volledige set voor een quant en wijs de loader naar het onderdeel ...-00001-of-000NN.gguf. Er is geen Q6_K-, Q8_0- of F16-niveau, en de reden is structureel in plaats van economisch: de n-gram (PLE) embeddingtabel is één tensor te groot om te voldoen aan de 50 GB-per-bestandslimiet van Hugging Face bij 6-bit en hoger, en een enkele GGUF-tensor kan niet over bestanden worden gesplitst — dus eindigt de reeks bij Q5_K_M.

Het andere bestand dat je niet mag overslaan is mmproj-...-F16.gguf, ongeveer 0,9 GB: dit is een visuele-taalmodel, en llama.cpp heeft de projector nodig voor elke afbeelding als invoer. Qwen3.8-Flash-Next is multimodaal, en dat geldt ook voor deze build — de abliteration raakt de vision-toren niet.

llama.cpp-ondersteuning zit nog niet in de mainline. De architectuur-id is qwen4exp, en standaard builds mislukken met "unknown architecture 'qwen4_exp'"; je hebt een build nodig van PR #27742 (branch qwen4exp/qwen3.8-flash-next), gecompileerd met de targets llama-cli, llama-mtmd-cli, llama-server en llama-gguf-split. Van daaruit heeft de serving de gebruikelijke vorm van een llama.cpp-server met Qw​en-specifieke vlaggen, met behulp van de quant-naam uit de partbestanden:

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

Stel -c in op de context die je kunt gebruiken; het voorbeeld van de kaart begint bij 8192. Reasoning is standaard ingeschakeld en wordt geretourneerd in reasoning_content, en tool calling werkt via de OpenAI-compatibele endpoint. De bovenstaande samplingwaarden zijn de aanbeveling van de modelkaart; gebruikers van het basismodel gebruiken temp 0.7 / top-p 0.80 / top-k 20 met een presence penalty van 1.5 in instructiemodus zonder denken, en stemmen de redeneerdiepte af met --chat-template-kwargs {"reasoning_effort":"medium"}.

De MLX-build op Apple Silicon

De MLX-repo is het native Apple-Silicon-pad: dezelfde gewichten, dezelfde verwijdering van weigeringen, een Metal-native runtime. Het levert 4-bit als standaard (~163 GB), de aangekondigde 6-bit-build (~192 GB) en een 8-bit-niveau (~221 GB), en omdat de fused-3D-experts en de n-gram-tabel op hogere precisie worden gehouden dan de nominale tag, ligt de effectieve precisie ruim boven uniforme 4-bit — de kaart vermeldt ~7,85 effectieve bits per gewicht voor de "4-bit"-tag. Dit is waarom de omvang van de repo groot lijkt: de n-gram-tabel wordt niet zo platgewalst als community-quants dat doen.

Hardware is de beperkende factor. MLX draait alleen op Apple Silicon (Metal), en je hebt unified memory nodig voor de gewichten — de modelkaart vermeldt: "een Mac met genoeg unified memory voor de 163 GB aan gewichten (bijv. M-series Ultra)". Beschouw de 4-bit-variant als een machine uit de 192 GB-klasse en de 6-bit-build als uit de 256 GB-klasse. De tags op de kaart geven de volledige featureset weer — qwen4_exp, MoE, MTP, function calling, vision-language — en voor beeldinvoer wordt het aangestuurd via mlx-vlm. De MTP-speculatieve head is hier inbegrepen, wat het stille voordeel van de MLX-build is ten opzichte van de GGUF-lijn.

Het visiepad, voor degenen die het gebruiken

Omdat dit een vision-taalmodel is, is het multimodale pad onderdeel van het runbook in plaats van een extra. Bij llama.cpp vereist beeldinvoer zowel de mmproj-projector als een build die llama-mtmd-cli / llama-server bevat. Bij MLX gebruik je mlx-vlm in plaats van de mlx-lm-driver die alleen tekst ondersteunt. Voor red teams is het vision-pad waar het interessante eval-werk zit: multimodale guardrails, prompt-injectie via een afbeelding, OCR op screenshots van je eigen systemen en adversarial images die op de hele pipeline zijn gericht. Aangezien de abliteration het volledige model bestrijkt en de vision-toren intact laat, komt een afbeelding die in de tekst-head een weigering zou hebben opgeroepen simpelweg terecht op een model zonder enig weigeringsgedrag. De GGUF-kaart vermeldt dat vision en multi-turn tool calling op deze build zijn geverifieerd; er wordt geen aparte vision-evalsuite gepubliceerd.

Waarvoor dit dient, en waar de grens ligt.

Deze build bestaat voor één klasse van werk: evalueren wat een model zonder weigeringen kan doen, ten dienste van het begrijpen en verdedigen van systemen. Voor een red team betekent dat het testen van je eigen beveiligingsmaatregelen tegen een model dat niet beleefd zal weigeren — resistentie tegen prompt-injectie, exfiltratiescenario's, misbruik van toolgebruik, en de kloof tussen "het basismodel weigert" en "het model kan dit feitelijk niet doen." Die kloof is de volledige onderzoekswaarde van een abliterated build: het vertelt je wat de weigeringslaag verborg, wat het verschil is tussen beveiliging door beleid en beveiliging door capaciteit. Voor een blue team zijn dezelfde gewichten het plausibele uitgangspunt van de tegenstander: als een vijandige actor dit kan downloaden en draaien, moeten je verdedigingen standhouden tegen een model dat antwoordt in plaats van weigert. Evaluaties die erop gebaseerd zijn, vormen een ondergrens voor wat een aangepast, nooit-aligned model zou kunnen doen — behandel ze zo, niet als een plafond.

Wees duidelijk over wat het verwijderen van weigeringen wel en niet verandert. Het verandert het outputgedrag — het model weigert niet langer — en het verandert de capaciteit niet. Geen nieuwe kennis, geen nieuwe vaardigheden, geen nieuwe rekenkracht; dezelfde training, dezelfde grenzen aan wat het model daadwerkelijk kan produceren. Een 'abliterated' model kan geen malware ontwikkelen waartoe het eerder niet in staat was; het antwoordt gewoon in plaats van te ontwijken, en de uitvoer is niet meer waarheidsgetrouw omdat ze permissiever is. De ±2-punts capaciteitsband van de kaart en het instorten van de weigeringsaantallen zijn hetzelfde feit vanuit twee kanten gezien.

Waar de grens ligt, is vastgelegd in de gated-repo-overeenkomst, en het is geen standaardtekst. Legitiem gebruik: het evalueren van uw eigen systemen, openbaar kwetsbaarheidsonderzoek naar modellen, het bouwen van detectie- en verdedigingsevaluaties, het bestuderen van weigeringsmechanismen. Niet legitiem: dit inzetten als een gebruikersgerichte assistent, werkende malware of exploits genereren tegen systemen die u niet bezit of waarvoor u geen toestemming hebt om te testen, fraude, wapenmateriaal. De Apache-2.0-licentie en het toepasselijke recht vormen de ondergrens; de poort is de expliciete onderzoeksdoelovereenkomst daarboven. Als uw gebruiksscenario "een chatbot aan gebruikers leveren" is, is dit niet uw model — en dat is met opzet, geen vergissing.

Hoe de geserveerde baseline op te halen

Deze gewichten zijn bewust alleen lokaal: {{1}}de probe-payloads van een red team mogen nooit via een API van derden gaan{{/1}}, en self-hosting is precies de bedoeling. Wanneer je de gecensureerde, gehoste basislijn wilt vergelijken — {{2}}Alibaba's Qwen3.8-Flash voor $0,16 per miljoen invoertokens en $0,47 per miljoen uitvoertokens{{/2}} — routeert OrcaRouter die tegen de lijstprijs van de provider, met 0% opslag en automatische failover. Zo kan een eval-harness met één API-sleutel en zonder tweede contract schakelen tussen de gehoste basis en jouw lokale ongecensureerde build. De open Qwen3.8-Flash-Next-gewichten staan nog niet in onze catalogus; zodra een runtime die wij routeren ze draagt, komen ze in diezelfde opzet met één sleutel en lijstprijs terecht.

Begin hier

Bepaal welke regel bij je hardware past en lees dan de relevante poort. Op een Mac met 128 GB+ unified memory geeft de MLX-build je MTP en vision op één plek — accepteer de voorwaarden van de MLX-repo, haal de 4-bit- of 6-bit-gewichten op en gebruik ze met mlx-vlm. Op NVIDIA, AMD of een cpu-box bouw llama.cpp vanaf PR #27742, accepteer de voorwaarden van de GGUF-repo, haal een quant die past en vergeet het mmproj-bestand niet. In beide gevallen zijn de weigeringsaantallen en de capaciteitsband die van de repo zelf, gepubliceerd op de modelkaart en op het moment van schrijven niet gereproduceerd — de eerlijke manier om ze te lezen is als de meting door de leverancier van zijn eigen aanpassing, niet als een onafhankelijke audit. De poort, de licentie en de veiligheidsgrens hierboven zijn dezelfde tekst vanuit drie invalshoeken: dit is een onderzoeksinstrument en het wordt onder die voorwaarde vrijgegeven.

Alle vijf Flash-Next builds — BF16, GGUF, MLX, FP8 en NVFP4 — zijn verzameld in de Qwen3.8-Flash-Next-Uncensored collectie op Hugging Face.

Niet te verwarren met de 27B-familie: Qwen3.8-27B-Uncensored is een ander model dat vanaf een ander basismodel is geabliteerd, met zijn eigen collectie en zijn eigen runbooks. Zelfde techniek, andere gewichten.

Deze gewichten zijn bewust alleen lokaal beschikbaar. Voor een gehoste basislijn om de abliterated build tegen af te meten wordt Qwen3.8-Flash op OrcaRouter aangeboden tegen de lijstprijs van de provider met 0% opslag — het standaardmodel, met intacte safety alignment.