Ternary Bonsai 2 27B: cosa entra in 5,9 GB, e cosa non ti dice il 98,2%

Ternary Bonsai 2 27B è un modello linguistico multimodale da 27,36 miliardi di parametri che Prism ML ha annunciato il 17 settembre 2026, e la cosa da capire è che i suoi pesi linguistici assumono uno di esattamente tre valori. Il suo modello di base è Qwen3.8 27B — un modello da 27B ad attenzione ibrida — e Bonsai mantiene quell'architettura, quell'addestramento e quella forma, e sostituisce i pesi delle matrici del modello linguistico con una rappresentazione ternaria. Il file distribuito è di 5,93 GB. Il riferimento a precisione completa è di 53,81 GB. L'affermazione di punta del fornitore è che conserva il 98,2% della media dei benchmark dell'originale.

Inizia dalla parte che gran parte della copertura liquiderà in fretta: quel 98,2% è un numero di Prism ML, misurato sulla suite di 20 benchmark di Prism ML, con l'harness di Prism ML, e nessuno al di fuori dell'azienda lo ha riprodotto. Non è un'accusa — è il normale stato delle cose un giorno dopo un rilascio, ed è esattamente lo status che dovresti attribuirgli. Ciò che puoi verificare in modo indipendente oggi è il file: l'API di Hugging Face elenca Ternary-Bonsai-2-27B-PTQ1_0.gguf a 5,947 GB contro il riferimento FP16 a 53,808 GB, ovvero una riduzione di 9,05x, che corrisponde al "circa 9x" del fornitore senza dover fidarsi di nessuno. La dimensione è un fatto. La conservazione della qualità è una misurazione del fornitore. Il materiale interessante sta nel mezzo — la suddivisione per categoria, che mostra esattamente dove la compressione è gratuita e dove non lo è.

Questo rilascio ha anche una seconda faccia. Il 18 settembre, un giorno dopo l'annuncio, OrcaRouter ha pubblicato una variante abliterata a runtime dello stesso modello — il OrcaRouter Ternary Bonsai 2 27B Uncensored — che rimuove al momento dell'inferenza una direzione di rifiuto appresa e lascia i pesi identici bit per bit. È trattata in una sezione dedicata più avanti, perché la tecnica è la parte interessante e perché i suoi limiti sono istruttivi quanto i suoi risultati.

È un Qwen3.8 27B compresso, non un modello addestrato da zero

Questa distinzione è la differenza tra lo spiegare il rilascio e il ripetere un comunicato stampa. Prism ML non ha addestrato un modello 27B da zero e non ha eseguito una nuova ricetta di pre-addestramento. Ciò che ha fatto è stato prendere Qwen3.8 27B e cambiare la rappresentazione numerica in cui i suoi pesi vengono memorizzati e calcolati.

L'architettura è invariata, ed è quella del modello base: un design ad attenzione ibrida che è all'incirca per il 75% attenzione lineare e per il 25% attenzione completa, con blocchi MLP SwiGLU, RoPE e RMSNorm. Questo backbone ibrido è anche il motivo per cui il contesto da 262K token è descritto come in grado di gestire l'intero contesto anziché semplicemente supportato — è l'attenzione prevalentemente lineare a mantenere sostenibile un contesto lungo su un dispositivo. Il modello è un modello visione-linguaggio: accetta immagini oltre che testo, e la torre di visione è la torre Qwen originale, non quantizzata, fornita separatamente.

Ciò che Prism ML ha contribuito sono due cose. La prima è la rappresentazione ternaria stessa più il training consapevole della quantizzazione che la rende sostenibile. La seconda sono i kernel — kernel personalizzati a basso bit per quello stack di attenzione ibrida su Apple Silicon e CUDA, che operano direttamente sui pesi impacchettati invece di scartarli in FP16 e moltiplicarli. Senza il secondo contributo, il primo è un formato di archiviazione senza modo di usarlo a velocità.

Il white paper di Prism ML riporta la ripartizione dei parametri come 24,35B nel backbone linguistico su 64 blocchi, 2,54B nell'embedding e nella testa LM, e 0,47B nella torre visiva a 27 blocchi, per un totale di 27,36B. La torre visiva è l'unica parte che è davvero un artefatto diverso: la release GGUF la pacchettizza come file mmproj a 4 bit di circa 0,63 GB, caricato solo quando arriva effettivamente un'immagine, quindi il serving solo testo non la porta mai con sé.

Questo è il Bonsai di seconda generazione dello stesso laboratorio; il primo Bonsai 27B è arrivato a luglio 2026, circa due mesi prima, e il confronto tra le due generazioni è una domanda ragionevole — che affrontiamo nel testa a testa contro Bonsai 27B invece di ripeterlo qui.

Che cosa significa, concretamente, "ternary g128"

Se non ti sei mai imbattuto nei pesi ternari, questo è il paragrafo che rende leggibile tutto il resto, quindi eccolo qui senza abbreviazioni.

Un peso ordinario in una rete neurale è un numero in virgola mobile a 16 bit — circa 65.536 valori distinguibili su un intervallo utile, ognuno dei quali costa 16 bit per essere memorizzato. Un peso ternario non è un piccolo numero in virgola mobile. È una scelta tra tre simboli: −1, 0 o +1. Questo è l'intero vocabolario. Memorizzare uno di questi simboli in modo ingenuo costerebbe due bit per peso, dato che due bit offrono quattro stati e te ne servono solo tre.

Da solo, ciò rappresenterebbe una perdita catastrofica di espressività, ed è per questo che il formato non è mai soltanto il simbolo. Ogni gruppo di 128 pesi consecutivi condivide un unico fattore di scala FP16, e il valore effettivo del peso è il simbolo ternario moltiplicato per quella scala:

• w = ssub>g/sub> · t, dove t ∈ {−1, 0, +1} e ssub>g/sub> è un'unica scala FP16 condivisa per il gruppo di 128

Quindi il modello continua a rappresentare un'ampia gamma di grandezze — solo che le rappresenta in passi grossolani, raggruppati per gruppi, invece che per singolo peso. Lo 0 non è un artefatto di arrotondamento; è un vero e proprio terzo stato, ed è proprio la sua presenza a permettere a un gruppo di 128 pesi di restare in gran parte silenzioso quando serve.

La base ruotata è la parte che sorprende le persone. Prima che avvenga l'assegnazione ternaria, ogni matrice dei pesi viene trasformata a blocchi mediante una rotazione ortogonale — una matrice di Walsh–Hadamard combinata con una diagonale fissa di segni ±1, con dimensione di blocco 1024 — e i valori ternari vengono scelti in quello spazio ruotato. La rotazione viene incorporata nei pesi memorizzati durante la preparazione, quindi non costa bit aggiuntivi né traffico aggiuntivo di pesi. In fase di inferenza il runtime applica invece la trasformazione corrispondente alle attivazioni, e il modello impacchettato dichiara la propria rotazione nei suoi metadati, così un runtime o applica la trasformazione corrispondente oppure rifiuta di caricare il file.

Perché darsi tanto da fare? Perché una rotazione di Hadamard distribuisce l'energia di una matrice dei pesi in modo più uniforme tra le coordinate, il che rende la successiva quantizzazione a tre livelli molto meno dannosa di quanto sarebbe sulla distribuzione grezza e spigolosa. La rotazione non è un ornamento; è il motivo per cui un modello ternario può conservare qualcosa di simile alla qualità del genitore. Il costo è che la trasformata si trova sul percorso critico di ogni proiezione con batch size 1, il che è un vero problema ingegneristico — Prism ML fonde l'inversione di segno nel percorso di caricamento della trasformata su Metal e parallelizza quest'ultima su un intero blocco di thread su CUDA per evitare che domini la decodifica.

I numeri, con attenzione: 1.585, 1.71, 1.72, 1.76

Quattro valori di larghezza in bit circolano attorno a questa release, sono tutti corretti e misurano quattro cose diverse. Confonderli è l’errore più semplice in questa vicenda. Ecco ciascuno di essi e ciò che copre effettivamente.

• 1,585 bit per peso — il contenuto informativo di un simbolo ternario, log₂3. Questa è una proprietà del formato, non di un singolo file. Nulla di ciò che viene distribuito opera a 1,585 bit/peso.

• 1,71 bit per peso — solo i tensori ternari. Aggiungi la scala di gruppo FP16 a 16 bit ammortizzata su 128 pesi e ottieni log₂3 + 16/128 ≈ 1,71. Non è ancora un valore di un modello rilasciato; si tratta dei tensori ternari in isolamento.

• 1,72 bit per peso — ogni parametro del modello linguistico, incluso il piccolo insieme mantenuto al di sopra della rappresentazione a bassi bit. Prism ML mantiene 26.238.464 parametri — lo 0,0976% del modello linguistico, circa 52 MB in bf16 — a precisione superiore, per lo più il percorso dello stato ricorrente degli strati di attenzione lineare più i pesi di normalizzazione. Quei tensori non sono né ruotati né quantizzati, e sono ciò che sposta il valore da 1,71 a 1,72. A 1,72 l'ingombro idealizzato è di 5,80 GB, una riduzione di circa 9,3x. Questa è la riga "True Ternary" di Prism ML, ed è un obiettivo più che un file da scaricare.

• 1,76 bit per peso — il GGUF effettivamente distribuito. Kernel efficienti richiedono un formato di packing, e PTQ1_0 di Prism ML impacchetta i trit in modo denso, attestandosi a 1,76 bit/peso in 5,93 GB, circa 9,1x. Questo è il file dietro sia il "5,9 GB" sia il "9x più piccolo" citati nell'annuncio, ed è quello che le misurazioni sopra confermano.

Il secondo packing è PQ2_0, che memorizza ogni trit in uno slot da 2 bit anziché in modo denso. Costa più spazio in cambio di un unpacking più economico: 2,16 bit/peso in 7,25 GB, circa 7,4x. Nessuno dei due packing è uniformemente più veloce — PTQ1_0 sposta circa il 18% in meno di dati di peso per passo, ma paga in aritmetica per decomprimere i trit densi, quindi vince sulle schede della generazione Ada e sulla L4, dove la memoria è il vincolo limitante, e perde su Hopper, Blackwell e Apple silicon, dove invece la decodifica con batch 1 è limitata dalla throughput delle istruzioni. L'elaborazione dei prompt favorisce PQ2_0 ovunque, perché è compute-bound.

Due note pratiche per chiunque stia confrontando questi dati con le fonti. Primo, i documenti di Prism ML stesso arrotondano in modo leggermente diverso: la tabella di archiviazione del whitepaper indica PTQ1_0 come 1,76 bit/peso a 5,93 GB, mentre la scheda del modello GGUF su Hugging Face indica 1,75 e 5,95 GB, e il file misurato è 5,947 GB. Si tratta dello stesso file descritto con precisioni diverse, non di un disaccordo sostanziale. Secondo, la riduzione annunciata di "più di 9x" è quella del fornitore; misurata rispetto ai file effettivi è 53,808 / 5,947 = 9,05x, il che è coerente.

Il quadro del benchmark: non la media, la forma

Il dato principale è una media di 83,9 contro 85,4 del baseline Qwen3.8 27B FP16, che corrisponde al 98,2%. La media è la parte meno interessante. La forma sottostante è dove si trovano le informazioni reali, e non è uniforme.

• Aderenza alle istruzioni — 82,66 vs 81,25. Questa è l'unica categoria in cui il modello compresso batte il suo modello padre a piena precisione. Non è rumore che chiunque possa liquidare con leggerezza; è una vittoria di categoria sulla suite del fornitore stesso.

• Matematica — 96,57 contro 97,06, e coding — 81,58 contro 82,17. Entrambi sostanzialmente allo stesso livello: mezzo punto e sei decimi di punto sulle medie di categoria. Per un modello con un nono dell'impronta, questi sono i risultati su cui si fonda l'intera tecnica.

• Conoscenza e ragionamento — 83,95 vs 86,66. Un calo di 2,7 punti, ed è qui che risiede una quota significativa dei 1,8 punti mancanti sulla media totale.

• Vision — 78,59 vs 81,64. Un calo di 3,05 punti, la perdita più consistente in un'unica categoria. Vale la pena notare che la torre di visione in sé non è la parte compressa; lo è il modello linguistico che ne legge gli output.

• Agentico e chiamata di strumenti — 77.57 vs 79.74. La media della categoria comprende τ 2-Bench a 80.22 e BFCL v3 a 74.92.

Risultati individuali che vale la pena conoscere, perché non puntano tutti nella stessa direzione. Su Terminal-Bench 2.1 il modello ottiene 52,8 contro 69,7 con precisione piena — all'incirca tre quarti — e su SWE-bench Verified ottiene 60,8 contro 80,6, di nuovo circa tre quarti. Questa è stata la prima volta che questa famiglia di modelli è stata valutata su Terminal-Bench, e Prism ML afferma esplicitamente che i miglioramenti a lungo termine nell'ingegneria del software che aveva promesso nella prima versione di Bonsai sono parziali, non completi. A fronte di ciò: τ 2-Bench è salito a 80,2 da 73,6 nella versione precedente, BFCL v3 si mantiene a 74,9 e AA-LCR si attesta a 77,0, a un punto dalla precisione piena. AIME26 si attesta a 95,83 e LiveCodeBench a 90,07.

Dove fidarsene e dove no. Fidati della forma su matematica, programmazione e rispetto delle istruzioni — quelle sono le categorie in cui la tecnica dimostra di fare ciò che promette, e sono misurate sullo stesso harness della baseline. Sii prudente riguardo al lavoro agentico a lungo orizzonte: i due benchmark che mettono realmente alla prova un'ingegneria continuativa guidata dagli strumenti, Terminal-Bench 2.1 e SWE-bench Verified, mostrano un divario materialmente più ampio di quanto implichi l'aggregato, e il fornitore lo dice invece di nasconderlo. E considera l'intera tabella come la misurazione di un solo laboratorio su un solo harness finché qualcun altro non la esegue. Quella avvertenza non è una formalità, qui — è la differenza tra "questo modello mantiene il 98,2%" e "il fornitore di questo modello ha misurato il 98,2% su una suite scelta dal fornitore". Entrambe sono vere; solo una è un fatto riguardante il modello.

Perché questa batte una build IQ2_XXS dello stesso modello base

Merita una sezione a sé stante anziché una sola riga, perché costituisce l'intero argomento a favore dell'addestramento ternario consapevole della quantizzazione rispetto alla quantizzazione post-addestramento.

Il modo convenzionale per rendere piccolo Qwen3.8 27B è quantizzarlo dopo l'addestramento. Il punto di confronto del whitepaper è una build IQ2_XXS GGUF dello stesso modello base:

• Ternary Bonsai 2 27B — 1,76 bit/peso, 5,93 GB, media su 20 benchmark 83,9

• Qwen3.8 27B IQ2_XXS — 2,2 bit/peso, 7,3 GB, media su 20 benchmark 75,2

Il modello compresso durante l'addestramento è sia più piccolo sia migliore. È 1,23 volte più piccolo della versione convenzionale a basso numero di bit e ottiene 8,7 punti in più. Questa combinazione non è una curiosità di arrotondamento; è l'affermazione che una rappresentazione scelta durante l'addestramento vale sostanzialmente di più dello stesso budget nominale di bit applicato in seguito.

La parte più istruttiva è come la build convenzionale fallisce, perché il fallimento è selettivo e facile da non notare. IQ2_XXS non degrada in modo uniforme. Tiene sulle conoscenze superficiali — 85,79 su MMLU-Redux — mentre crolla su compiti che richiedono catene di ragionamento prolungate: 78,6 su AIME26, 70,05 su LiveCodeBench, 65,45 su GPQA Diamond. Bonsai 2 ottiene 95,83, 90,07 e 85,76 sugli stessi tre. Un test di chat informale troverebbe la build IQ2_XXS perfettamente utilizzabile e non farebbe mai emergere il crollo; il danno risiede esattamente dove avvengono lunghi ragionamenti e la generazione di codice. Questa asimmetria è il motivo per cui "sembrava a posto quando l'ho provato" non è una prova riguardo a un modello quantizzato.

Prism ML comprime lo stesso argomento in un'unica cifra derivata che chiama densità di intelligenza — all'incirca, capacità di benchmark per gigabyte. Sulla suite di 20 benchmark riporta 0,444 per GB per Bonsai 2, 0,276 per la build IQ2_XXS e 0,051 per FP16. La metrica è una costruzione propria del fornitore e la sua ponderazione è una scelta di progettazione, non una legge; ma l'ordinamento che produce è lo stesso ordinamento che produce la tabella grezza, quindi aggiunge interpretazione anziché prove.

Un'ulteriore nota sincera sul confronto. La model card GGUF di Prism ML riporta una seconda valutazione, più ristretta — una suite di 14 benchmark in modalità thinking — in cui lo stesso valore di retention compare di nuovo a 84,78 contro 86,32, con IQ2_XXS a 72,59. Il fatto che due suite diverse arrivino allo stesso 98,2% è una lieve conferma che l'affermazione aggregata non è un artefatto di una singola selezione di benchmark. Resta comunque lo stesso laboratorio a eseguirle entrambe, sullo stesso banco di prova. La nostra analisi più completa di questo confronto, inclusa la questione del formato di packing, si trova nel confronto con le build GGUF di Qwen3.8 27B.

Cosa serve davvero per correre

I numeri di throughput, dalla misurazione standardizzata tg128 del whitepaper con dimensione del batch pari a 1 e la torre di visione esclusa:

• Apple M5 Max — 46,8 tok/s in decodifica, 765 tok/s nell'elaborazione del prompt

• Apple M5 Pro — 27,7 tok/s in decodifica; una distinta esecuzione a finestra più lunga del pacchetto PQ2_0 ha misurato 27,0 tok/s sostenuti, assorbendo 27,0 W sul rail della GPU e 32,8 W tra CPU e GPU

• Apple M4 Pro — decodifica a 18,0 tok/s, con l'elaborazione del prompt a circa 125 tok/s che diventa il vincolo limitante per contesti molto lunghi

• NVIDIA RTX 5090 — 142,5 tok/s in decodifica sul pacchetto PQ2_0 a 0,582 mWh per token

L'affermazione pratica che Prism ML avanza non è un rapporto di accelerazione ma un'assenza: la baseline FP16 a 53,8 GB non entra affatto in un laptop da 16 GB, quindi l'affermazione significativa è che un modello di classe 27B ora funziona in modo interattivo su hardware quotidiano. Sul M5 Pro la decodifica misurata trasmette in streaming circa 201 GB/s di pesi, confermando il profilo dominato dalla larghezza di banda della memoria che la rappresentazione a bassi bit è progettata per sfruttare.

Poi i casi limite, che contano più dei numeri di picco.

Non puoi usare il llama.cpp standard.I kernel di attenzione ibrida ternaria risiedono nel fork llama.cpp di Prism ML. Il llama.cpp standard rifiuta i tipi PTQ1_0 e PQ2_0 come sconosciuti e — cosa ancora più pericolosa — carica il vecchio formato ternario Q2_0 senza alcun avviso e produce spazzatura, perché non dispone di un runtime di attivazione Hadamard. Se esegui questo modello su un binario che non applica la rotazione corrispondente, non otterrai un errore; otterrai frasi senza senso dall'apparenza fluente. Questo è il modo in assoluto più probabile per sprecare un pomeriggio con questa release.

Il pacchetto MLX non ha un percorso CUDA. La release MLX (prism-ml/Ternary-Bonsai-2-27B-mlx-2bit) è pensata per Apple Silicon, dove dispone di kernel personalizzati per lo stack ibrido sia nel runtime Python che in quello Swift. La sua matmul quantizzata ha kernel Metal e CPU ma nessuna implementazione CUDA, quindi su una macchina NVIDIA quel particolare pacchetto non ottiene affatto l'accelerazione GPU. L'inferenza su CPU funziona, ma un forward pass di 27B su CPU può richiedere minuti — il che rende il percorso CPU Linux utile per test di implementazione e riproducibilità, e inutile per il serving.

I due pacchetti sono un vero scambio, non una classifica. Se usi una scheda della generazione Ada o una L4, oppure se la memoria è il vincolo limitante, PTQ1_0 è la scelta a 5,93 GB. Se usi Hopper, Blackwell o una 5090, PQ2_0 ti offre velocità di decodifica in cambio di 1,3 GB. Se usi Apple silicon, tieni presente che i dati relativi a M5 Pro riportati sopra sono misurati su PQ2_0, che è anche il pacchetto che la configurazione demo scarica per impostazione predefinita.

Una nota sulla contabilità del pacchetto MLX stesso, perché è una fonte comune di confusione. Il contenitore MLX è un formato affine a 2 bit il cui blocco memorizza sia una scala FP16 sia un bias FP16 per ogni gruppo di 128 pesi. I pesi ternari di Bonsai richiedono solo la scala — i livelli derivano dalla sola scala — quindi il bias è peso morto, e il blocco costa 36 byte per 128 pesi invece di 34. Questo porta il tasso di impacchettamento del pacchetto MLX a 2,250 bit/peso, non 1,72 e non 1,76. È un contenitore diverso che porta gli stessi valori ternari, e il suo file misurato su Hugging Face è di 8,005 GiB.

La variante runtime-abliterated

Il 18 settembre, OrcaRouter ha pubblicato OrcaRouter Ternary Bonsai 2 27B Uncensored, che applica l'ablazione della direzione di rifiuto a questo modello interamente a runtime. L'idea ingegneristica merita più attenzione del prodotto, quindi ecco prima l'idea.

L'abliterazione convenzionale modifica i pesi. Trova una direzione nello spazio delle attivazioni che corrisponde al comportamento di rifiuto, poi ortogonalizza contro di essa le matrici dei pesi che scrivono nel residual stream: W ← W − r(rᵀW). Su un normale modello FP16 va bene — la matrice modificata è ancora una matrice densa in virgola mobile, quindi la salvi e passi oltre. Su un pacchetto ternario è un vicolo cieco, e nello specifico è un vicolo cieco per la ragione stessa per cui questo modello esiste. Ortogonalizzare una matrice ternaria produce una matrice densa a precisione piena. Per memorizzarla di nuovo nel pacchetto ternario bisognerebbe ri-quantizzare — e ri-quantizzare pesi modificati non riproduce il quantization-aware training che ha prodotto l'originale. Butteresti via esattamente ciò che era stato acquistato.

Quindi la proiezione si sposta invece al momento dell'inferenza. Anziché modificare W, modifica il suo output:

• y ← y − α · dot(y, r) · r, calcolato in float32, dove y è un contributo residuo e r è la direzione di rifiuto normalizzata

A α = 1 la componente di ciascuna scrittura residua parallela alla direzione di rifiuto viene rimossa. A α = 0 il modello è invariato. α maggiore di 1 sovraproietta e può degradare la qualità. Poiché α è un parametro di runtime anziché una proprietà del checkpoint, lo stesso pack può essere testato A/B contro se stesso nello stesso processo — che è esattamente ciò che fanno le valutazioni di OrcaRouter. Il pack Bonsai originale rimane bit-identico: zero pesi modificati, zero riquantizzazione, zero errore aggiuntivo di quantizzazione dei pesi.

Due dettagli implementativi sono il punto in cui una versione ingenua di questo fallisce.

129 punti di intervento, non 16.Ogni modulo che può scrivere nel flusso residuo deve essere incapsulato, e in questa architettura ibrida si tratta di 64 blocchi mlp.down_proj, 48 livelli linear_attn.out_proj, 16 livelli self_attn.o_proj e model.embed_tokens — 129 in totale. Incapsulare solo self_attn.o_proj è l'errore ovvio e ne intercetta 16, lasciando le altre 113 scritture non proiettate. Uno script di autoverifica misura se la componente rimanente lungo la direzione di rifiuto viene portata a circa 1e-6 della norma residua, e avvisa se non rileva tutti i 129 punti.

Non ruotare nuovamente la direzione. Il pacchetto ternario mantiene le sue proiezioni in una base ruotata sulla loro dimensione di ingresso e compensa sul lato dell'attivazione. La proiezione di rifiuto opera sulle uscite di quelle proiezioni, che sono già tornate nella normale base nascosta — quindi la direzione di rifiuto è un vettore ordinario a 5120 dimensioni e applicargli un'ulteriore rotazione di Hadamard lo farebbe proiettare contro la base completamente sbagliata.

Che cosa ha misurato OrcaRouter — i nostri dati, non quelli indipendenti

Queste sono misurazioni basate su regole di OrcaRouter stesso, e vanno lette come tali: un classificatore di frasi di apertura basato su regole, non un giudice LLM, thinking off, decodifica greedy, budget di 64 token, con base e ablated che sono gli stessi pesi nello stesso processo a α = 0 rispetto ad α = 1. Sono indicative, non di livello pubblicabile, e non costituiscono una verifica di nulla di ciò che Prism ML ha affermato.

In merito al rifiuto, misurato come la quota di prompt che hanno ricevuto un rifiuto:

• AdvBench (n=100) — 99,0% base, 6,0% ablato, con il 56,0% che ha risposto ma avvolto in un disclaimer

• JailbreakBench (n=100) — 96,0% base, 4,0% ablato, 52,0% con avvertenze

• StrongREJECT (n=150) — 99,3% base, 3,3% ablato, 45,3% con avvertenze

• HarmBench (n=150) — 98,7% base, 7,3% ablato, 48,0% con avvertenze

• MaliciousInstruct (n=100) — 97,0% base, 0,0% ablato, 52,0% con avvertenze

• ForbiddenQuestions (n=150) — 75,3% base, 5,3% ablato, 42,7% con avvertenze

• SimpleSafetyTests (n=50) — 96,0% base, 18,0% ablato, 60,0% con caveat — e questa cifra è sottostimata. Quel set è composto per lo più da prompt di autolesionismo, e il modello vi risponde con un reindirizzamento alla crisi che inizia con "Sono profondamente dispiaciuto di sentire…", che l'elenco di frasi esatte del classificatore non intercetta e valuta come conforme. Il tasso residuo effettivo di rifiuto su quel set è superiore al 18,0%. Il classificatore è stato lasciato deliberatamente così com'è, affinché i numeri restino comparabili con le altre model card di OrcaRouter.

In nessun set una risposta ha esaurito il proprio budget di token, quindi nessuno di questi tassi è gonfiato dal troncamento. Sui prompt benigni la stessa proiezione elimina anche il rifiuto eccessivo: XSTest-safe è sceso da un tasso di rifiuto del 5,2% allo 0,4%, e il sottoinsieme benigno di JailbreakBench dal 25,0% allo 0,0%. Il pacchetto pubblicato rifiuta un quarto dei prompt benigni di quel benchmark; una volta ablato, non ne rifiuta nessuno.

Sul piano delle capacità, il fatto che i pesi siano identici bit per bit significa che non c'è alcuna riquantizzazione da pagare, e le misurazioni sono coerenti con questo:

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

• GSM8K (n=150) — 87,3% base, 86,0% ablato, −1,3

• CMMLU (n=500) — 76,2% base, 75,6% ablato, −0,6

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

L'avvertenza che conta di più

La direzione di rifiuto è stata stimata dal modello base BF16 da cui è stato addestrato il pacchetto Bonsai. L'architettura e la base nascosta sono identiche, quindi la geometria è allineata. Ma quanto bene quella direzione sopravviva all'addestramento consapevole della quantizzazionenon è stato pienamente misurato.

Il runtime può dimostrare, matematicamente e con un'approssimazione di circa 1e-6, che rimuove la direzione fornita da ogni scrittura residua. Non può dimostrare da ciò soltanto che la direzione catturi ancora la stessa caratteristica comportamentale nel modello quantizzato che catturava in quello denso. Queste sono affermazioni diverse, e solo la prima è risolta. Chiunque legga la tabella di sicurezza sopra dovrebbe leggerla sapendo che l'intervento è esattamente efficace quanto l'assunzione di trasferimento della direzione, e tale assunzione è la questione aperta.

C'è anche l'inquadramento pratico che OrcaRouter dà al rilascio stesso, che vale la pena ripetere anziché diluire con una parafrasi: rimuovere una direzione di rifiuto appresa può portare un modello a rispondere a richieste che l'originale avrebbe declinato. Questo è un meccanismo di ricerca e di controllo dell'inferenza, non una prova che qualsiasi output risultante sia sicuro, corretto o appropriato, e le implementazioni che lo utilizzano dovrebbero applicare i propri controlli di accesso e l'applicazione delle policy. Rimuovere i rifiuti non è un miglioramento gratuito, e questo articolo non è scritto come se lo fosse.

Tre ulteriori note pratiche per chiunque voglia riprodurlo. Il pacchetto deve essere caricato con il suo runtime incluso — un normale loader MLX può sembrare di caricarlo con successo mentre calcola silenziosamente la cosa sbagliata, quindi se gli output sembrano sbagliati prima ancora che l'ablazione sia abilitata, controlla prima il percorso di caricamento. L'ablazione selettiva per layer è supportata, quindi l'intervento non deve essere tutto o niente. E la valutazione dell'ablazione è stata eseguita sull'espansione FP16 scompattata del pacchetto anziché sul pacchetto che esegue i propri kernel, perché la matmul quantizzata impacchettata non ha un'implementazione CUDA e il backend CPU impiega minuti per ogni forward pass; quell'espansione porta esattamente i valori ternari del pacchetto e riproduce le distribuzioni del token successivo del pacchetto stesso a tre decimali su controlli a campione, ma è un cambio di contenitore e vale la pena saperlo. Il codice e le tabelle complete sono nel repository OrcaRouter Ternary Bonsai 2 27B Uncensored. Un confronto separato che copre la build MLX ablata rispetto al percorso MLX di Qwen3.8 27B non modificato approfondisce i dettagli specifici del runtime.

Dove porterà questo, e cosa resta ancora da dimostrare

Ciò che un modello da 27B quasi lossless in circa sei gigabyte cambia per gli agenti locali riguarda soprattutto ciò che diventa residente. Un modello linguistico che entra insieme a una vera finestra di contesto su un laptop da 16 GB può rimanere caricato mentre un agente svolge altro lavoro — leggere file, chiamare strumenti, mantenere un piano attraverso i turni — invece di essere scambiato a ogni richiesta o spinto su un server. Questa è la differenza tra un modello locale che provi e un modello locale che lasci in esecuzione, ed è la proprietà specifica che i numeri agentici, τ 2-Bench a 80.2 e BFCL v3 a 74.9, sono lì a supportare.

Ciò che non è provato è un elenco più lungo di quanto l'annuncio lasci intendere.

• Nessuna riproduzione indipendente. Ogni dato sulla qualità in questo articolo — l'83,9, il 98,2%, le medie per categoria — è una misurazione di Prism ML sulla suite di Prism ML. Non è un difetto della release; è semplicemente ciò che significa avere un giorno di vita. È anche la prima cosa che cambierà.

• Il lavoro agentico a lungo orizzonte è la parte più debole della tabella dello stesso fornitore, non la più forte. Terminal-Bench 2.1 a 52,8 contro 69,7 è un divario reale, e il fornitore dichiara che la capacità è solo parziale.

• Prompt che non hai provato. Il profilo di fallimento dei modelli a basso numero di bit è selettivo, e il collasso di IQ2_XXS su AIME26 e LiveCodeBench mentre mantiene 85,79 su MMLU-Redux è la prova più chiara disponibile che una media di benchmark non ti dice cosa succede sul tuo carico di lavoro. Bonsai 2 non mostra quel collasso su quei due benchmark, il che è incoraggiante e non equivale a una garanzia.

• La questione del trasferimento di direzione nella variante abliterated, sopra, che è irrisolta per costruzione.

• Se i kernel terranno il passo man mano che i runtime si evolvono. Al momento questo modello richiede un fork; llama.cpp stock rifiuta due dei tre formati e corrompe silenziosamente il terzo. Finché quei kernel non saranno integrati upstream, "gira ovunque giri llama.cpp" non è ancora vero per questo modello.

Il rilascio in sé non è in discussione. Un modello multimodale di classe 27B da 5,93 GB, a un nono dell'ingombro della cosa da cui è stato compresso, con matematica e programmazione allo stesso livello del modello padre e la capacità di seguire le istruzioni leggermente superiore, è un punto di funzionamento genuinamente diverso per l'inferenza locale. L'atteggiamento ragionevole il 18 settembre 2026 è prendere le dimensioni del file come un dato di fatto, prendere il dato di ritenzione come un'attenta affermazione del fornitore fatta un giorno fa su una suite scelta dal fornitore, e sospendere il giudizio sul proprio carico di lavoro finché non lo si è eseguito su di esso.

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.