Qwen3.8-Flash-Next-Uncensored: Esegui il MoE abliterato su llama.cpp e Apple Silicon

Prima di scaricare qualsiasi cosa: Qwen3.8-Flash-Next-Uncensored non è Qwen3.8-27B-Uncensored. Condividono un nome di famiglia e una tecnica di abliterazione, ma sono modelli diversi da versioni di pesi differenti, e ogni precedente post "Qw​en uncensored" su questo blog riguarda la 27B. L'argomento qui è la coppia che OrcaRouter ha pubblicato su Hugging Face il 26 agosto 2026 — orcarouter/Qwen3.8-Flash-Next-Uncensored-GGUF e orcarouter/Qwen3.8-Flash-Next-Uncensored-MLX — build abliterate di Qwen3.8-Flash-Next, il modello di Alibaba a mixture-of-experts con routing, con 176B di parametri memorizzati e 6B attivi, che anticipa l'architettura Qwen4. Abbiamo annunciato il rilascio come "GGUF + MLX nativo, fino a 262K di contesto", pensato per ricercatori di sicurezza, red team e blue team. Questo runbook è scritto a partire dalle nostre stesse model card: cosa fa la rimozione del rifiuto all'interno di un MoE con routing, quanto costa realmente in memoria la pretesa dei 262K di contesto, come servire entrambe le linee di file e dove si colloca la linea di ricerca. Se sei arrivato cercando il primer sull'abliteration o la matematica dei quant della 27B, i post precedenti di questa serie li trattano.

Prima, il cancello

Entrambi i repository sono soggetti a gating su Hugging Face (gated: auto). Nessun download di file finché non hai effettuato l'accesso e accettato i termini del repository su ciascun repository — i repository GGUF e MLX hanno ciascuno il proprio gate. Questa è la differenza più pratica rispetto a una linea GGUF non gated: il semplice one-liner "just hf download" fallisce con un errore di autenticazione prima di scaricare un byte. Il flusso è:

• Accedi a Hugging Face (o registrati) e installa huggingface_hub, poi esegui hf auth login una volta così il tuo token è salvato su disco.

• Apri orcarouter/Qwen3.8-Flash-Next-Uncensored-GGUF nel browser, accetta i termini, poi ripeti per orcarouter/Qwen3.8-Flash-Next-Uncensored-MLX.

• Da allora, il download con hf tramite il tuo token autenticato funziona come qualsiasi altro repository. Ogni quant che scarichi, e i pesi MLX, è un artefatto di ricerca sotto Apache-2.0 — la stessa licenza del modello base — e il gate fa parte dell'accordo: leggere i termini è il primo passo per usare il modello.

Cosa fa l'abliteration a un MoE instradato

La tecnica è la modifica dei pesi in stile Arditi di cui abbiamo già parlato altrove in questo blog; la parte interessante è ciò che fa a questa architettura in particolare. Sul 27B denso erano 131 matrici residue. Su Qwen3.8-Flash-Next-Uncensored, la scheda del modello MLX documenta l'abliteration applicata a 149 tensori di scrittura residui, e i componenti che rendono questo modello ciò che è — il router MoE, la tabella di embedding n-gram da 51B, la torre di visione — non sono mai stati toccati.

Quel "mai toccato" è l'intera storia per un modello instradato. Ogni token attiva 10 dei 512 esperti; nessun singolo esperto possiede il rifiuto. Il comportamento di rifiuto vive nel flusso residuo che compone l'output finale, che è precisamente la direzione che l'ortogonalizzazione rimuove. Quindi il router continua a instradare gli stessi esperti, la tabella n-gram continua a produrre gli stessi embedding, e ciò che cambia è ciò che il modello dice una volta eseguita la proiezione di output. I controlli pubblicati sulla scheda del modello GGUF definiscono la forma di questo cambiamento come un calo del rifiuto di prompt dannosi dal 64–100% sulla base a circa 0–3,3% in questa build, iper-rifiuto benigno vicino allo 0% e capacità entro ±2 punti dalla base nei controlli in stile MMLU-Pro / GSM8K / CMMLU. Questi sono i numeri della scheda stessa, auto-dichiarati piuttosto che riprodotti in modo indipendente.

La testa MTP: presente in MLX, rimossa in GGUF

Qwen3.8-Flash-Next include una testa speculativa multi-token-prediction da ~4B, e le due build non sono d'accordo al riguardo. Il repository GGUF la esclude — la scheda è esplicita: questi file non includono la testa speculativa MTP — perché il supporto di qwen4exp in llama.cpp non implementa ancora MTP, quindi la testa sarebbe un peso morto nel file. La build MLX la mantiene, quindi su Apple Silicon si ha ancora la decodifica speculativa. La conseguenza pratica, confermata da chi esegue il modello base: il ramo GGUF di llama.cpp oggi gira senza decodifica speculativa, mentre una configurazione SGLang con MTP più che raddoppia la decodifica sulla stessa classe di hardware. Se mai llama.cpp implementasse MTP per qwen4exp, la linea GGUF otterrebbe un aumento di velocità gratis — ma non comprate hardware aspettandovelo questa settimana.

L'affermazione sul contesto 262K e quanto costa la cache KV

Il contesto nativo è di 262.144 token (estendibile con YaRN verso 1M), e il vincolo che pesa davvero è la memoria. La buona notizia è che l'architettura mantiene piccola la cache KV: dei 48 strati, 36 utilizzano l'attenzione lineare Gated DeltaNet, che comprime la storia in uno stato ricorrente a dimensione fissa, e solo i 12 strati a piena attenzione hanno una cache KV convenzionale che cresce con la lunghezza della sequenza.

Due punti dati misurati dalla community, entrambi sul modello base, si applicano direttamente. Un deployment GGUF con 4× RTX 3090 ha riportato di passare da 65K a 131K di contesto con solo ~0.78 GB per scheda di KV aggiuntivo, e un singolo DGX Spark ha eseguito l'intero contesto di 262K con un file di classe Q4, mantenendo il modello residente a ~76.9 GB del suo pool di 128 GB, ancorando la tabella n-gram alla CPU e facendone la mmap da NVMe. La voce di budget della stessa model card GGUF è: totale = dimensione del file + cache KV + il mmproj di ~0.9 GB. Il punto chiave per la scelta della quantizzazione: a 262K la cache KV è una voce reale, ma i pesi sono la voce dominante, quindi la stessa logica VRAM-first della guida GGUF 27B si applica — la differenza qui sta nelle dimensioni dei file stessi, che vanno da IQ2_XXS a circa 52 GB a Q5_K_M a circa 125 GB.

La linea GGUF: 13 quantizzazioni, file divisi, mmproj e una build di llama.cpp.

Il repository GGUF mette a disposizione 13 livelli di quantizzazione — 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 — con i quanti IQ costruiti da una matrice di importanza su testo di calibrazione in inglese, cinese e codice. Ogni quanto è multi-parte, suddiviso con llama-gguf-split, quindi scarica l'intero set per un quanto e punta il caricatore alla parte ...-00001-of-000NN.gguf. Non esiste un livello Q6_K, Q8_0 o F16, e il motivo è strutturale anziché economico: la tabella di embedding n-gram (PLE) è un tensore troppo grande per soddisfare il limite di 50 GB per file di Hugging Face a 6 bit e superiori, e un singolo tensore GGUF non può essere suddiviso tra più file — quindi la linea arriva al massimo a Q5_K_M.

L'altro file che non devi saltare è mmproj-...-F16.gguf, circa 0,9 GB: questo è un modello visione-linguaggio, e llama.cpp richiede il proiettore per qualsiasi input immagine. Qwen3.8-Flash-Next è multimodale, e lo è anche questa build: l'abliteration non tocca la torre visiva.

Il supporto per llama.cpp non è ancora nel mainline. L'ID dell'architettura è qwen4exp, e le build standard falliscono con "unknown architecture 'qwen4_exp'"; è necessaria una build dalla PR #27742 (ramo qwen4exp/qwen3.8-flash-next), compilata con i target llama-cli, llama-mtmd-cli, llama-server e llama-gguf-split. Da lì, la modalità di servizio è il solito server llama.cpp con flag specifici per Qw​en, usando il nome quant dai file delle parti:

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

Imposta -c al contesto massimo che puoi gestire; l'esempio della scheda parte da 8192. Il ragionamento è attivo di default e viene restituito in reasoning_content, e la chiamata agli strumenti funziona tramite l'endpoint compatibile con OpenAI. I valori di campionamento sopra indicati sono la raccomandazione della scheda del modello; chi utilizza il modello base imposta temp 0.7 / top-p 0.80 / top-k 20 con una penalità di presenza di 1.5 in modalità instruct non-thinking, e regola la profondità di ragionamento con --chat-template-kwargs {"reasoning_effort":"medium"}.

La build di MLX su Apple Silicon

Il repo MLX è il percorso nativo per Apple Silicon: stessi pesi, stessa rimozione dei rifiuti, un runtime nativo Metal. Include la versione a 4-bit come predefinita (~163 GB), la build a 6-bit annunciata (~192 GB) e un livello a 8-bit (~221 GB), e poiché gli esperti fused-3D e la tabella n-gram sono mantenuti a una precisione superiore rispetto all'etichetta nominale, la precisione effettiva supera di gran lunga il 4-bit uniforme — la scheda elenca circa 7,85 bit effettivi per peso per l'etichetta "4-bit". Questo è il motivo per cui le dimensioni del repo sembrano grandi: la tabella n-gram non viene compressa come fanno le quantizzazioni della community.

L'hardware è il vincolo stringente. MLX funziona solo su Apple Silicon (Metal) e serve memoria unificata per i pesi — la scheda del modello riporta: "un Mac con memoria unificata sufficiente per i pesi da 163 GB (es. M-series Ultra)". Considera il livello a 4 bit come una macchina di classe 192 GB e la build a 6 bit come di classe 256 GB. I tag della scheda del modello registrano il set completo di funzionalità — qwen4_exp, MoE, MTP, function calling, vision-language — ed è eseguito tramite mlx-vlm per l'input di immagini. La testa speculativa MTP è inclusa qui, che è il vantaggio silenzioso della build MLX rispetto alla linea GGUF.

Il percorso di visione, per coloro che lo utilizzano

Poiché questo è un modello visione-linguaggio, il percorso multimodale fa parte del runbook piuttosto che essere un extra. Su llama.cpp, l'input di immagini richiede sia il proiettore mmproj sia una build che includa llama-mtmd-cli / llama-server. Su MLX, lo si guida con mlx-vlm invece del driver solo-testo mlx-lm. Per i red team, il percorso della visione è dove risiede il lavoro di valutazione interessante: guardrail multimodali, prompt injection veicolata in un'immagine, OCR su screenshot dei propri sistemi e immagini avversarie mirate all'intera pipeline. Poiché l'abliteration copre l'intero modello e lascia intatta la torre di visione, un'immagine che avrebbe innescato un rifiuto nella testa testuale semplicemente finisce su un modello senza comportamenti di rifiuto da colpire. La scheda GGUF afferma che la visione e il tool calling multi-turno sono stati verificati su questa build; nessuna suite di valutazione separata per la visione è stata pubblicata.

A cosa serve e dove si colloca il limite

Questa build esiste per una sola classe di lavoro: valutare ciò che può fare un modello a cui è stato rimosso il rifiuto, al servizio della comprensione e della difesa dei sistemi. Per un red team, ciò significa testare le proprie protezioni contro un modello che non declinerà educatamente — resistenza all'iniezione di prompt, scenari di esfiltrazione, abuso degli strumenti e il divario tra «il modello base rifiuta» e «il modello in realtà non può farlo». Quel divario è tutto il valore di ricerca di una build abliterata: ti dice cosa nascondeva lo strato di rifiuto, che è la differenza tra sicurezza per policy e sicurezza per capacità. Per un blue team, gli stessi pesi sono la baseline plausibile dell'avversario: se un attore ostile può scaricare ed eseguire questa build, le tue difese devono reggere contro un modello che risponde invece di tirarsi indietro. Le valutazioni costruite su di essa sono un limite inferiore a ciò che un modello personalizzato, mai allineato, potrebbe fare — trattale così, non come un tetto.

{{1}}Sii chiaro su ciò che la rimozione dei rifiuti cambia e ciò che non cambia.{{/1}} {{2}}Cambia il comportamento di output — il modello non rifiuta più — e non cambia le capacità.{{/2}} {{3}}Nessuna nuova conoscenza, nessuna nuova abilità, nessuna nuova potenza di calcolo; lo stesso addestramento, gli stessi limiti su ciò che il modello può effettivamente produrre.{{/3}} {{4}}Un modello abliterato non può progettare malware che prima non era in grado di creare; semplicemente risponde invece di tergiversare, e i suoi output non sono più veritieri per il fatto di essere più permissivi.{{/4}} {{5}}La banda di capacità di ±2 punti della scheda e il crollo dei numeri dei rifiuti sono lo stesso fatto visto da due lati.{{/5}}

Dove passa il confine è l'accordo sul repository soggetto a gate, e non è una clausola di stile. Usi legittimi: valutare i propri sistemi, ricerca pubblica sulle vulnerabilità dei modelli, creare eval di rilevamento e difesa, studiare i meccanismi di rifiuto. Non legittimi: distribuirlo come assistente rivolto agli utenti, generare malware o exploit funzionanti contro sistemi che non possiedi o per cui non sei autorizzato a testare, frode, materiale per armi. La licenza Apache-2.0 e la legge applicabile sono il livello minimo; il gate è l'accordo esplicito sullo scopo di ricerca che sta al di sopra. Se il tuo caso d'uso è "rilasciare un chatbot agli utenti", questo non è il tuo modello — ed è voluto, non una svista.

Come ottenere la baseline servita

Questi pesi sono esclusivamente locali di proposito: i payload di probe di un red team non dovrebbero mai transitare tramite un'API di terze parti, e il self-hosting è il punto. Quando vuoi il baseline servito e censurato per il confronto — Qwen3.8-Flash di Alibaba a $0.16 per milione in input e $0.47 per milione in output — OrcaRouter lo instrada al prezzo di listino del provider con markup 0% e failover automatico, così un harness di valutazione può passare dalla base ospitata alla tua build locale non censurata con una sola chiave e nessun secondo contratto. I pesi open di Qwen3.8-Flash-Next non sono ancora nel nostro catalogo; quando un runtime che instradiamo li ospita, finiscono nello stesso setup a chiave singola e prezzo di listino.

Inizia qui

Decidi quale riga corrisponde al tuo hardware, poi leggi il gate pertinente. Su un Mac con memoria unificata da 128 GB o superiore, la build MLX ti dà MTP e vision in un unico posto: accetta i termini del repository MLX, tira i pesi a 4 o 6 bit e guidali con mlx-vlm. Su NVIDIA, AMD o una macchina con CPU, compila llama.cpp dalla PR #27742, accetta i termini del repository GGUF, tira una quantizzazione che ci stia e non dimenticare il file mmproj. In entrambi i casi i numeri di rifiuto e la fascia di capacità sono quelli propri del repository, pubblicati sulla scheda e non riprodotti al momento in cui scrivo — il modo onesto di leggerli è come la misurazione che il venditore fa della propria modifica, non come un audit indipendente. Il gate, la licenza e il confine di sicurezza sopra sono lo stesso testo da tre angolazioni: questo è uno strumento di ricerca, ed è rilasciato a quella condizione.

Tutte e cinque le build Flash-Next — BF16, GGUF, MLX, FP8 e NVFP4 — sono raccolte nella collezione Qwen3.8-Flash-Next-Uncensored su Hugging Face.

Da non confondere con la famiglia 27B: Qwen3.8-27B-Uncensored è un modello diverso, abliterato da una base diversa, con la propria collection e i propri runbook. Stessa tecnica, pesi diversi.

Questi pesi sono solo locali per progettazione. Per una baseline hosted con cui confrontare la build abliterata, Qwen3.8-Flash è servito su OrcaRouter al prezzo di listino del provider con markup 0% — il modello stock, con l'allineamento di sicurezza intatto.