Qwen3.8-27B-Uncensored Benchmark: il rifiuto crolla, le capacità restano

La storia dei benchmark di Qwen3.8 27B Uncensored (Aggressive) — la build abliterata di Qwen3.8 27B pubblicata come checkpoint FP8 il 15 agosto 2026 e come build GGUF il 16 agosto — non è che sia diventato più forte. È che ha smesso di rifiutare. La scheda del modello riporta un crollo dei rifiuti a prompt dannosi dal 64–99% sul modello base allo 0–6% sulla build abliterata con il pensiero disattivato, e pari o inferiore all'1,7% con il pensiero attivato, mentre ogni benchmark di capacità si attesta entro ±1,3 punti dal modello base e la perplexity su WikiText-2 è di 6,96. Se sei qui per i benchmark qwen uncensored, questi sono i numeri principali: non è un modello più intelligente, è un modello che non rifiuta.

Questa distinzione è importante, perché gran parte di ciò che compare nelle classifiche dei "benchmark non censurati" è o un superficiale listicle di punteggi di capacità o un post di hype che sostiene che il modello è "migliore". Nessuno dei due è ciò che fa l'abliteration. Questo articolo analizza i dati effettivamente misurati — collasso del rifiuto, eccesso di rifiuto, mantenimento delle capacità e perplexity — il metodo che li ha prodotti e il limite di sicurezza che dovresti leggere prima di toccare i pesi.

Cosa misura realmente una rassegna di benchmark non censurata

Una recensione ordinaria di un modello riporta un unico asse: capacità — MMLU, GSM8K, coding, ragionamento. Un modello abliterato è interessante su un asse diverso, e il punto centrale dell'etichetta "senza censura" è che l'asse della sicurezza si è spostato. Quindi la domanda utile per Qwen3.8-27B-Uncensored-FP8 non è "è più intelligente?" ma "quanto è costato rimuovere il meccanismo di rifiuto, e quanto è stato rimosso a fondo?"

Tre famiglie di numeri devono essere lette insieme. Tasso di rifiuto sui benchmark di prompt dannosi — quanto spesso il modello rifiuta; più alta è la base, più visibile è la rimozione. Over-rifiuto su prompt benigni — quanto spesso rifiuta erroneamente una richiesta innocente; più basso è, meglio è per tutti. E mantenimento delle capacità — se la modifica ha degradato il modello. Un riepilogo di benchmark che stampa solo i punteggi di capacità sta rispondendo alla domanda sbagliata.

Il metodo: abliteration è una modifica dei pesi, non un fine-tuning.

Ciò che distingue l'abliteration dai pacchetti "jailbreak" della community è il punto in cui avviene il cambiamento. Un jailbreak a livello di prompt avvolge l'input; l'abliteration modifica i pesi. Il metodo qui è quello di Arditi et al. (2024), "Refusal in Language Models Is Mediated by a Single Direction". Il risultato principale è che il comportamento di rifiuto in molti modelli è determinato da una singola direzione nel flusso residuo — stima quella direzione, rimuovila, e il modello smette di rifiutare senza essere riaddestrato.

Concretamente, la scheda descrive la stima di una direzione di rifiuto dalla differenza media mascherata per attivazioni massive dei residui dell'ultimo token dannosi meno innocui al livello 38 (round(0.6 × 64)), usando AdvBench come insieme dannoso e Alpaca come insieme innocuo. La modifica è un'ortogonalizzazione, W′ = W − r(rᵀW), calcolata in float32 e applicata a 131 matrici di scrittura dei residui — le proiezioni di output dell'attenzione, le proiezioni di output dell'attenzione lineare, le proiezioni down del MLP e uno spazio di righe dell'embedding. Non viene eseguito alcun passo di addestramento; la torre visiva viene lasciata intatta; la testa di decodifica speculativa MTP viene ablitterata coerentemente. È per questo che le capacità sopravvivono: rimuovere una direzione è un intervento di gran lunga più delicato che mettere a punto il modello perché si conformi.

Il rifiuto crolla: i numeri

Misurato sulla build FP8 servita da vLLM e pubblicato sulla scheda del modello Hugging Face (2026-08-15), il tasso di rifiuto sui benchmark di prompt dannosi scende dal 64–99% sulla base allo 0–6% sulla build non censurata con il ragionamento disattivato:

• AdvBench — 99.0% → 0.0%

• JailbreakBench (dannoso) — 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%

Con il ragionamento abilitato, il rifiuto non si verifica praticamente mai — 1,7% su AdvBench e 0,0% sulla maggior parte del resto. La scheda aggiunge un'avvertenza onesta: il 30–50% delle risposte antepone ancora un breve disclaimer. Questo è un artefatto dell'addestramento, non un rifiuto — il modello risponde, ma attenua l'esordio. Sembra attrito, non sicurezza.

Anche il rifiuto eccessivo è un difetto.

Il dato meno pubblicizzato si trova sull'altro lato dell'asse della sicurezza. Su XSTest-safe — 250 prompt innocui che i modelli allineati a volte rifiutano per errore — il modello base rifiuta in modo eccessivo il 5,6% delle volte. La versione non censurata, invece, solo lo 0,4%. Rimuovere la direzione del rifiuto non solo impedisce al modello di rifiutare richieste dannose, ma gli impedisce anche di rifiutare quelle innocue che in precedenza segnalava per eccessiva generalizzazione. Per chiunque costruisca strumenti di valutazione o red-team in cui una baseline priva di rifiuti è il punto centrale, questo è un vero miglioramento dello strumento, non un effetto collaterale di cui scusarsi.

La capacità è preservata, non migliorata.

È qui che la narrazione "non censurato = più forte" muore. La scheda del modello riporta la build FP8 abliterata rispetto alla FP8 base ufficiale, con gli stessi script e le stesse impostazioni:

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

• GSM8K (CoT) — 90.0% → 88.7%

• MMLU-Pro (CoT) — 77.6% → 76.8%

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

Ogni punteggio si colloca entro ±1,3 punti dalla base, e la perplessità grezza di WikiText-2 si attesta a 6,96 — l'evidenza sulla scheda che la modellazione del linguaggio in sé non è degradata. La lettura onesta: l'abliteration è quasi neutrale rispetto alle capacità su questa architettura. Non ottieni un modello migliore; ottieni lo stesso modello senza il comportamento di rifiuto.

Lo stesso avvertimento vale per l'ecosistema più ampio: le affermazioni di "senza perdite e senza censura" sulle build della community meritano una lettura scettica. Un confronto a tre su una build open-weight da 4B su Hugging Face ha rilevato che la tecnica che affermava di essere senza perdite in realtà ha fatto calare TruthfulQA di circa 7 punti e Lambada di circa 4, mentre il suo tasso di successo degli attacchi HarmBench ha raggiunto il 100%; gli altri due metodi si sono attestati al 99,2% e al 95,5%. E una prova aggressiva su una build diversa ha ottenuto zero rifiuti ma ha prodotto un'insalata di parole incoerente, quindi la versione distribuita ha fatto marcia indietro, adottando parametri per-layer più morbidi. I risultati dell'abliteration sono specifici del metodo: questi numeri sono specificamente i dati della scheda della build FP8.

Ciò che la carta non afferma

Leggi la metodologia prima di citare i numeri. La scheda etichetta la sua misurazione del rifiuto come "indicativa, non un numero da LLM-judge / di livello pubblicabile": il rifiuto è stato giudicato da un classificatore a regole basato sulla frase di apertura, con un bucket separato "caveat" per le risposte che rispettavano la richiesta ma anteponevano una dichiarazione di non responsabilità. I benchmark sono solo testuali, eseguiti sulla build FP8 servita da vLLM con il solo modello linguistico, e la suite di capacità ha usato script di valutazione standard. La giusta prospettiva: questi sono dati misurati dal fornitore stesso, riproducibili dalla scheda pubblicata — non una esecuzione indipendente da terze parti, e non una dichiarazione sulla build GGUF, che viene distribuita quantizzata per llama.cpp e dovrebbe essere valutata separatamente.

Il confine di sicurezza

Questa è la parte che non può essere aggirata. Un modello abliterato è un modello a cui è stato sostanzialmente rimosso il meccanismo di rifiuto. Concretamente: eseguirà richieste dannose, non etiche o illegali che il modello base Qwen3.8 27B rifiuterebbe, e non ha significative protezioni integrate. Gli usi legittimi sono la ricerca — interpretabilità (studiare come sono codificate le direzioni di rifiuto), sicurezza dell'IA e studio dei meccanismi di rifiuto, red-teaming (testare i modelli con input che tentano di aggirare le loro protezioni) e valutazione della robustezza. È rilasciato sotto licenza Apache 2.0, ereditata dal modello base, strettamente come artefatto di ricerca. Ti assumi piena responsabilità e ogni onere per l'uso che ne fai e per tutto ciò che genera. Non distribuirlo a utenti finali né in produzione senza i tuoi livelli di sicurezza, moderazione e prevenzione degli abusi — e per qualsiasi uso in produzione o rivolto ai consumatori, il modello standard Qwen3.8 27B è quello che vuoi realmente.

Quando un benchmark non censurato è la cosa sbagliata da cercare

Se la tua domanda è "quale modello è il più forte in matematica o programmazione?", stai leggendo i numeri sbagliati — la build non censurata non è un potenziamento delle capacità. Se la tua applicazione deve rifiutare richieste dannose, questo modello è l'opposto di ciò che vuoi. Se stai lanciando un prodotto, non costruire su un checkpoint abliterato. E se ciò che cerchi davvero è un jailbreak, quella è tutta un'altra cosa — i pacchetti a livello di prompt stanno al di fuori dell'intervento a livello di pesi discusso qui e non sono l'oggetto di questo articolo. I dati di benchmark in questo articolo esistono per una sola domanda ristretta e legittima: cosa fa la rimozione del rifiuto a un Qwen3.8 27B, misurata.

Come accedervi

Entrambe le build sono su Hugging Face con licenza Apache 2.0: orcarouter/Qwen3.8-27B-Uncensored-FP8 (block-FP8 E4M3, circa 30,9 GB di pesi, servito sul percorso kernel FP8 standard di vLLM con contesto 262K, strumenti, pensiero e MTP intatti) e orcarouter/Qwen3.8-27B-Uncensored-GGUF (F16 più 12 livelli di quantizzazione per llama.cpp, con Q4_K_M a 16,8 GB come default consigliato per una GPU da 24 GB). La scheda del modello su OrcaRouter riporta i prezzi e i dettagli dei benchmark — la build non censurata è elencata lì come obsidian/Qwen3.8-27B a $0,40 per milione di token di input e $4,21 per milione di token di output, con contesto 262K, e l'accesso è riservato a ricercatori di sicurezza, red team e ricercatori di sicurezza AI.

La conclusione

I benchmark qwen uncensored rispondono a una domanda ristretta, e la risposta è netta: rimuovere il rifiuto da Qwen3.8 27B tramite abliteration lascia la capacità entro ±1,3 punti, mentre il rifiuto su prompt dannosi crolla dal 64–99% allo 0–6%, il rifiuto eccessivo scende dal 5,6% allo 0,4% e la perplessità si attesta a 6,96. Leggi questi numeri come "non rifiuta", mai come "più forte". Per la ricerca su interpretabilità, sicurezza e red-team, è esattamente lo strumento descritto nella scheda del modello. Per qualsiasi cosa che si rivolga a un utente, è il modello sbagliato per costruzione.

Per un uso legittimo di ricerca, i pesi si trovano su Hugging Face con licenza Apache 2.0 — orcarouter/Qwen3.8-27B-Uncensored-FP8 (la build GGUF per llama.cpp è su orcarouter/Qwen3.8-27B-Uncensored-GGUF).