Ternary Bonsai 2 27B Uncensored vs Qwen3.8-27B-Uncensored-MLX: Due modi per rimuovere una direzione di rifiuto

OrcaRouter Ternary Bonsai 2 27B Uncensored e Qwen3.8-27B-Uncensored-MLX rispondono alla stessa domanda — come si rimuove una direzione di rifiuto da un modello linguistico — e lo fanno in due punti diversi. La linea Qwen3.8-27B-Uncensored-MLX è abliterazione convenzionale: le matrici dei pesi vengono ortogonalizzate rispetto a una direzione di rifiuto appresa, e i pesi modificati vengono salvati come nuovo checkpoint. OrcaRouter Ternary Bonsai 2 27B Uncensored esegue invece la proiezione equivalente al momento dell'inferenza, sottraendo la componente di ogni scrittura residua che giace lungo la direzione di rifiuto, così il pacchetto Bonsai sottostante non viene mai modificato e resta identico bit per bit. Entrambe sono nostre release, e la separazione tra loro non è una preferenza sui runtime. Deriva da un'aritmetica specifica dei pesi ternari.

L'oggetto di questo confronto ha un giorno di vita. Prism ML ha annunciato Bonsai 2 27B il 17 settembre 2026; i repository di Hugging Face sono stati creati la sera prima, alle 23:40–23:41 UTC del 16 settembre 2026, con licenza Apache-2.0. La build MLX abliterata con cui viene confrontato è attiva da metà agosto. Nulla di quanto segue costituisce uno storico di risultati per il più recente dei due — laddove qualcosa non è stato misurato, questo articolo lo dichiara.

Lo stesso trucco, applicato in due posti diversi

L'abliterazione ordinaria è una modifica dei pesi. Si stima una direzione di rifiuto, poi la si proietta fuori dalle matrici che scrivono nel residual stream: W ← W - r(rᵀW). Qualche moltiplicazione tra matrici, nessun ottimizzatore, nessuna loss. È così che è stato creato Qwen3.8-27B-Uncensored-MLX — la model card lo descrive come "abliteration (rimozione della direzione di rifiuto), poi quantizzazione affine MLX", con la direzione ortogonalizzata fuori dal residual stream e il risultato salvato come un nuovo insieme di pesi. Quello che viene distribuito è un checkpoint in cui la direzione è già sparita.

OrcaRouter Ternary Bonsai 2 27B Uncensored lascia invariati i pesi e interviene dove viene prodotto ciascun contributo residuo, in float32, con la direzione di rifiuto memorizzata r:

• y ← y - alpha · dot(y, r) · r

Con alpha 1 — il valore predefinito — la componente parallela a r viene rimossa da quella scrittura. Con alpha 0 la proiezione è disattivata e il modello si comporta come il pacchetto pubblicato. I valori intermedi conferiscono una forza parziale, i valori superiori a 1 sovra-proiettano, il che, secondo il progetto, può degradare la qualità. Anche la selezione dei layer è esposta, così puoi ablare un sottoinsieme anziché l'intero stack. La direzione stessa è un normale vettore a 5120 dimensioni — circa 20 KB in float32 — senza alcuna rotazione aggiuntiva di Hadamard applicata, perché la proiezione opera sugli output di proiezione, che sono già nella normale base nascosta.

Il dettaglio della copertura è la parte che le persone sbagliano quando provano a farlo da soli. Avvolgendo self_attn.o_proj da solo cattura 16 punti. Questa implementazione avvolge 129 scrittori residui: 64 mlp.down_proj, 48 linear_attn.out_proj, 16 self_attn.o_proj, e model.embed_tokens. Un incluso selfcheck.py verifica che la proiezione riduce la componente rimanente fino a circa 1e-6 della norma residua, e avverte se 129 punti non vengono rilevati.

Perché i pesi ternari rendono questa una scelta obbligata anziché una preferenza

Ecco la parte che è effettivamente specifica di questo modello, ed è il motivo per cui i due approcci non sono intercambiabili qui, anche se calcolano quasi la stessa cosa.

Un pacchetto ternario memorizza valori in {-1, 0, +1} moltiplicati per una scala FP16 per gruppo, con dimensione di gruppo 128, in una base ruotata. Ortogonalizza una matrice ternaria rispetto a una direzione di rifiuto e ottieni una matrice densa a precisione completa. Non esiste una matrice ternaria che sia uguale a W - r(rᵀW) in generale. Quindi salvare nuovamente i pesi modificati significa riquantizzarli — e riquantizzare i pesi modificati non riproduce l'addestramento consapevole della quantizzazione che ha prodotto il pacchetto originale. Il comportamento di arrotondamento che Prism ML ha addestrato il modello a tollerare è una proprietà della procedura di addestramento, non del quantizzatore, e non è possibile rieseguirla a posteriori.

Su un checkpoint BF16 denso quel problema non si presenta. Arrotonda i pesi modificati a 4 bit e ottieni un modello a 4 bit leggermente peggiore, che è il normale compromesso che tutti accettano già. Su un pacchetto ternario butteresti via l'unica proprietà che il pacchetto esiste per avere.

Quindi la formulazione onesta non è «il runtime è meglio». È che la proiezione a runtime è l'unica delle due che preserva ciò che rende speciale questo particolare modello. La direzione di rifiuto è 20 KB. Il pacchetto è 8,005 GiB.

Quel valore di 8,005 GiB è specificamente il pacchetto MLX — prism-ml/Ternary-Bonsai-2-27B-mlx-2bit, il cui model.safetensors misura 8.595.477.990 byte sull'API di Hugging Face (8,595 GB, 8,005 GiB), un contenitore affine MLX con codici a 2 bit più una scala e un bias FP16 per gruppo. È un artefatto diverso dalle build GGUF distribuite da Prism ML, e i numeri non si trasferiscono tra loro. Il dato principale di Prism ML, 5,93 GB / 1,76 bit per peso, descrive il loro PTQ1_0 GGUF, che misura 5,947 GB; il loro formato True Ternary è indicato a 1,72 bit per peso e 5,80 GB. Nessuno di questi valori descrive il pacchetto MLX su cui questo runtime esegue l'ablazione.

Dove l'approccio checkpoint vince ancora, e in alcuni casi vince davvero

Sarebbe facile scrivere questo come un giro d'onore per il metodo più recente. Sarebbe sbagliato, perché l'abliteration convenzionale è in vantaggio sugli assi che decidono la maggior parte dei deployment.

• Un unico artefatto, qualsiasi runtime compatibile. Un checkpoint abliterato è un normale insieme di pesi. Caricalo in qualsiasi loader compatibile con MLX che già usi, e funziona. L'approccio runtime richiede il runtime incluso nel pacchetto stesso — e il progetto avverte esplicitamente che un normale loader MLX può sembrare caricare il pacchetto mentre calcola silenziosamente la cosa sbagliata. È uno spazio di manovra molto più ristretto.

• Hardware.Qwen3.8-27B-Uncensored-MLX è offerto in build a 2, 4, 6 e 8 bit, con una copia a 4 bit rispecchiata nella radice del repo, così gli strumenti che trattano un repo come un singolo modello lo caricano senza configurazione. Ternary Bonsai 2 27B Uncensored è Apple Silicon / MLX. La matmul quantizzata del pacchetto ha kernel Metal e CPU ma nessuna implementazione CUDA tramite mlx-cuda, quindi su una macchina NVIDIA questo pacchetto MLX attualmente non ottiene alcuna accelerazione GPU — l'inferenza su CPU funziona, e un forward pass da 27B può richiedere minuti. Questo rende il percorso CPU Linux utile per il test dell'implementazione e la riproducibilità, non per il serving.

• Strumenti e familiarità. L'abliterazione ha anni di strumenti alle spalle — ricette ottimizzate, ricerca dell'intervallo di layer, varianti pubblicate con cui confrontarsi. Il metodo runtime qui ha una sola implementazione, su un solo modello, rilasciata ieri.

• Distribuzione.Un singolo checkpoint è un singolo download. L'ablation runtime distribuisce un pacchetto più un file di direzione più un runtime, e il lettore deve tenere tre cose al passo.

• Prove. L'abliterazione al checkpoint dispone di misurazioni di terze parti su questa famiglia di modelli base. L'ablazione a runtime su un pacchetto ternario ha solo i nostri numeri, e il suo presupposto centrale non è verificato — ulteriori dettagli di seguito.

Che cosa si guadagna in cambio con l’ablazione a runtime

Anche nella direzione opposta lo scambio è reale, e il primo elemento è quello che si generalizza al di là di questo modello.

• Provenienza bit-identica.Zero pesi modificati, zero ri-quantizzazione, zero errore di quantizzazione aggiuntivo. Non è uno slogan; è la proprietà che rende i numeri di capacità riportati di seguito interpretabili anziché un felice caso.

• Un alpha regolabile. La forza di ablazione è un parametro di runtime, non una proprietà del checkpoint. Puoi testarne diversi valori per il tuo carico di lavoro, disattivarla del tutto con alpha 0, oppure sovra-proiettare e misurare cosa si rompe — senza scaricare un secondo modello.

• Controllo selettivo dei layer. L'ablazione di un sottoinsieme di layer è un argomento, non una nuova cottura. Questo è importante per chiunque studi quali layer trasportano il comportamento, perché l'alternativa è produrre un checkpoint per ogni configurazione.

• Nessun secondo set di pesi. Il modello modificato è il modello originale. Per un pacchetto la cui intera tesi è l'ingombro, distribuire una copia abliterata parallela a circa 16 GB — la dimensione della build a 4-bit nel repo di confronto — vanificherebbe il punto.

• Reversibilità. Una modifica a un checkpoint è permanente per quell'artefatto. Un flag di runtime non lo è.

I numeri che abbiamo, e esattamente come sono stati misurati

Tutto in questa sezione è la valutazione di OrcaRouter di OrcaRouter Ternary Bonsai 2 27B Uncensored, e il metodo conta tanto quanto le cifre.

La misurazione è un classificatore di frasi d'apertura basato su regole, non un giudice LLM. Il thinking è disattivato, la decodifica è greedy, il budget è di 64 token, e base e ablated sono gli stessi pesi nello stesso processo ad alpha 0 rispetto ad alpha 1. Quest'ultimo punto è la parte più forte dell'impostazione: non c'è alcun confronto tra checkpoint né alcuna differenza di quantizzazione a confondere il risultato. È anche il motivo per cui i numeri dovrebbero essere letti come una misura di ciò che il modello dice nella sua frase d'apertura, e niente di più.

Tassi di rifiuto su set pubblicati di prompt dannosi, da base ad ablated:

• AdvBench (n=100) — dal 99,0% al 6,0%

• JailbreakBench (n=100) — dal 96,0% al 4,0%

• StrongREJECT (n=150) — da 99,3% a 3,3%

• HarmBench (n=150) — da 98,7% a 7,3%

• MaliciousInstruct (n=100) — da 97,0% a 0,0%

• ForbiddenQuestions (n=150) — dal 75,3% al 5,3%

• SimpleSafetyTests (n=50) — dal 96,0% al 18,0%, e questo è sottostimato

SimpleSafetyTests è sottostimato per un motivo specifico. Quel set è composto per lo più da prompt di autolesionismo, e il modello ablato risponde con un reindirizzamento alla crisi che inizia con "Sono profondamente dispiaciuto di sentire…". L'elenco esatto delle frasi del classificatore non contiene quell'apertura, quindi classifica un reindirizzamento come conforme. Il vero tasso residuo di rifiuto è superiore al 18,0%. Il classificatore è stato lasciato così com'è deliberatamente, affinché le cifre restino comparabili con le altre model card di OrcaRouter — ma un lettore non dovrebbe prendere il 18,0% per buono.

Nessuna risposta in nessuna di queste esecuzioni ha esaurito il proprio budget di token, ed è ciò che rende difendibile qui un budget di 64 token. Una colonna separata nei risultati completi conta le risposte che hanno risposto ma hanno racchiuso la risposta in un disclaimer; tale percentuale andava dal 42 al 60% a seconda del set.

Due risultati che vanno contro la semplice narrazione

Due dei risultati meritano una trattazione a sé, perché entrambi complicano la lettura più ovvia.

Anche il rifiuto eccessivo cala. Sui prompt benigni di JailbreakBench, il pacchetto pubblicato ne rifiuta il 25,0%. Dopo l'ablazione, rifiuta lo 0,0%. Su XSTest-safe passa dal 5,2% allo 0,4%.

Questa è la metà della tecnica di cui si parla troppo poco. Il Bonsai pack pubblicato respinge un quarto di un set di prompt benigni; qualunque cosa stia facendo la direzione di rifiuto nel modello QAT, si sta attivando su prompt che non avrebbero mai dovuto farla scattare. Rimuovere la direzione elimina anche quei rifiuti, e questo è un vero guadagno di capacità, non un costo per la sicurezza. Lo stesso effetto emerge in lavori indipendenti su altri modelli: l'harness di Atomic Chat ha misurato il rifiuto eccessivo dei prompt benigni di Gemma 2 9B crollare dal 44% allo 0,5% dopo l'abliteration, con MMLU sostanzialmente invariato da 68,4 a 68,0. La loro misurazione, il loro modello, autodichiarati sul loro blog; il punto è il pattern, non le cifre esatte.

L'impostazione che segue è scomoda ma onesta: il rifiuto eccessivo e il rifiuto sono la stessa manopola. Non puoi abbassare solo i rifiuti che non ti piacciono.

Il mantenimento delle capacità è stabile, e non è fortuna. I controlli delle capacità, dalla base all'ablato:

• MMLU (n=300) — da 76,7% a 77,7%, +1,0

• GSM8K (n=150) — da 87,3% a 86,0%, -1,3

• CMMLU (n=500) — da 76,2% a 75,6%, -0,6

Ogni variazione rientra nel rumore a queste dimensioni campionarie — una domanda GSM8K vale 0,7 punti. MMLU-Pro è stato escluso anziché riportato: il suo prompt richiede un ragionamento prima della risposta, e il 63–64% delle risposte da entrambe le parti non aveva raggiunto una risposta entro il budget di token, quindi qualsiasi cifra di accuratezza sarebbe un limite inferiore fissato dal budget anziché una misurazione.

Una capacità invariata deriva direttamente da pesi bit-identici, e vale la pena essere precisi sul perché. Il modello che fornisce le risposte è lo stesso modello. Il runtime aggiunge un prodotto scalare e un AXPY per ogni scrittura residua e non cambia nulla nei pesi, nella quantizzazione o nei kernel che li leggono. Un approccio basato su checkpoint deve guadagnarsi quell'invarianza — e spesso non ci riesce. Una batteria di test di terze parti su una diversa abliterazione della stessa base Qwen3.8-27B, pubblicata il 17 agosto 2026 da un ingegnere di SMF Works, ha misurato un valore composito che scende dal 79,0% al 72,0%, con la matematica in calo dal 50,0% al 33,3%. Si tratta di una ricetta diversa, di una toolchain diversa e di una misurazione diversa, quindi non è un punteggio per questo confronto. È un promemoria del fatto che l'abliterazione su checkpoint applicata a questa base ha comportato perdite a due cifre percentuali in almeno un test accurato e strumentato, e che «l'abliterazione è quasi gratuita» è un'affermazione che dipende interamente dalla ricetta.

L'ipotesi che nessuno ha ancora verificato

Questa è la parte della storia che va detta chiaramente, e appartiene a un confronto tra metodi di rimozione della censura piuttosto che a una nota a piè di pagina.

La direzione di rifiuto usata qui è stata stimata dal modello base BF16 da cui è stato addestrato il pacchetto Bonsai. L'architettura e la base nascosta sono identiche, quindi il vettore è dimensionalmente corretto e la proiezione è matematicamente esatta — il runtime può dimostrare, e in effetti verifica, che rimuove la direzione fornita dal flusso residuo.

Ciò che questo non dimostra è che la direzione significhi ancora la stessa cosa nel modello addestrato quantization-aware. Non è stato misurato appieno quanto bene la direzione sopravviva all'addestramento quantization-aware. Rimuovere esattamente un vettore non equivale a rimuovere il comportamento che si presumeva rappresentasse, e la seconda affermazione è quella che conta. Ogni numero nella sezione precedente è un risultato empirico coerente con un buon trasferimento; nessuno di essi dimostra che il trasferimento sia completo, e il progetto stesso lo afferma, raccomandando di effettuare una sweep di alpha e della selezione dei layer prima di trarre conclusioni.

Qualsiasi confronto onesto tra metodi di uncensoring deve ammetterlo. L'abliteration convenzionale ha il problema speculare: modifica i pesi e poi misura il risultato, quindi la sua direzione non deve mai trasferirsi tra versioni del modello, ma la sua modifica è permanente e irrecuperabile se la ricetta era sbagliata.

Cosa rimane ancora da misurare

Oltre alla questione del trasferimento, tre lacune meritano di essere nominate invece di essere aggirate con le parole.

• Nessuna riproduzione indipendente. Ogni benchmark di Bonsai 2 27B in circolazione — la media di 83,9, la ritenzione del 98,2%, le suddivisioni per categoria — è dichiarato dal fornitore Prism ML, eseguito con EvalScope su un backend vLLM su H100 con sforzo di ragionamento "xhigh". Nessuno al di fuori di Prism ML li ha riprodotti. Anche le tabelle di sicurezza e capacità sopra riportate sono nostre e non sono indipendenti.

• Comportamento con pensiero attivo. Nelle nostre tabelle il pensiero è disattivato. Lavori indipendenti su altri modelli abliterated hanno rilevato che, anche con il 100% di successo dell'attacco, il modello ragiona comunque sulla sicurezza in una frazione sostanziale di risposte quando gli è consentito pensare. Se questo valga anche qui, e quali effetti abbia sui numeri delle frasi di apertura, non è stato misurato.

• Una sola direzione. Il metodo presuppone che il rifiuto sia mediato da un'unica direzione, che è il risultato di Arditi et al. e la base dell'intera tecnica. Lavori successivi su altri modelli hanno individuato direzioni geometricamente distinte per diverse categorie di rifiuto. Un solo vettore, fatto variare su un solo alpha, non basta a risolvere la questione.

Che cosa significa questo se stai scegliendo tra loro

Scegli il checkpoint se hai bisogno che il modello giri ovunque, su hardware che non controlli, tramite un loader che non hai scritto. Scegli il runtime se sei su Apple Silicon, ti interessa che l'artefatto che stai studiando sia l'artefatto addestrato da Prism ML, e vuoi che la forza di ablazione sia un parametro che puoi regolare invece di una decisione che devi riscaricare. Entrambe sono difendibili, e vengono scelte dai vincoli di deployment, non da quale metodo sia più recente.

Se stai cercando di decidere empiricamente, il metodo runtime ha un vantaggio pratico che vale la pena menzionare: alpha 0 e alpha 1 sono lo stesso processo e gli stessi pesi, quindi un confronto tra loro isola l'ablazione e nient'altro. È un esperimento più pulito rispetto al diffing di due checkpoint, ed è il motivo per cui la tabella sopra può essere letta come una misurazione della proiezione anziché come una misurazione di due sue quantizzazioni.

Uso responsabile

Rimuovere una direzione di rifiuto appresa può indurre il modello a rispondere a richieste che l'originale rifiuterebbe. Questo è il meccanismo che funziona, non un effetto collaterale, e non dovrebbe essere classificato come una funzionalità. Si tratta di un meccanismo di ricerca e di controllo dell'inferenza, e non è prova che qualsiasi output risultante sia sicuro, corretto o appropriato.

La scheda dello stesso pacchetto pubblicato sostiene lo stesso concetto dal lato opposto: la build MLX abliterated «ha subito una rimozione sostanziale del proprio allineamento di sicurezza», si conformerà a richieste che l'originale rifiuterebbe e non comporta alcuna salvaguardia integrata significativa. I suoi autori ne circoscrivono l'uso alla ricerca legittima — interpretabilità, ricerca sulla sicurezza, red-teaming, valutazione della robustezza — e dichiarano apertamente che i deployment devono prima aggiungere il proprio livello di moderazione e i propri controlli di accesso.

Nulla in questo articolo costituisce un argomento a sostegno del fatto che la rimozione del rifiuto sia priva di costi, o che un tasso di rifiuto inferiore sia un segnale di qualità. Un modello che risponde a più domande non è per questo un modello migliore, e un classificatore basato su regole che conta le frasi di apertura è una misura della formulazione, non della competenza. Entrambi questi artefatti sono strumenti di ricerca con annesso un dovere dell'operatore, e il dovere non si sposta su chi ha scritto il codice di ablazione.

Il codice di ablazione a runtime, la direzione di rifiuto e le tabelle di valutazione complete sono pubblicati da OrcaRouter, insieme alla piattaforma di routing che il team sviluppa.