Bonsai 27B: il modello 27B della famiglia Bonsai, spiegato

Bonsai 27B è il modello da 27 miliardi di parametri della famiglia Bonsai di PrismML, ed è quello che le persone intendono quando digitano "bonsai 27b" — ma il nome da solo non ti ci porterà, perché tre cose diverse rispondono a qualcosa di molto simile. Bonsai 27B è una ricostruzione a basso numero di bit di Qwen3.6-27B, datata 14 luglio 2026 dall'annuncio del fornitore stesso, e viene distribuito come due pacchetti dello stesso modello: Bonsai 27B a 1 bit, che memorizza pesi binari {−1, +1} in circa 3,9 GB, e Ternary Bonsai 27B, che memorizza pesi ternari {−1, 0, +1} a 1,71 bit effettivi per peso — 5,9 GB nella cifra di punta del fornitore, 7,165 GB come il pacchetto viene effettivamente distribuito. Non è Ternary Bonsai 2 27B, la seconda generazione con nome distinto costruita su Qwen3.8-27B, e non è il modello visione-linguaggio da 2 miliardi di parametri che PrismML ha realizzato per gli occhiali intelligenti Snapdragon AR1 Gen 1. Entrambi i pacchetti di Bonsai 27B offrono un contesto di 262.000 token, una torre di visione compatta a 4 bit e una licenza Apache 2.0. Il modello è Bonsai 27B; la decisione che ne segue è quale dei suoi due pacchetti si adatta al tuo budget di memoria.

Questa pagina è il riferimento per quel modello. Non è un annuncio: Bonsai 27B è disponibile da luglio 2026, e le domande a cui vale la pena rispondere ora sono quelle con cui arriva un lettore — che cos'è esattamente, cosa distingue il nome, e quanto costa davvero eseguirlo.

Qual è il 27B

La confondibilità qui è reale, e vale la pena risolverla prima di ogni altra cosa, perché una supposizione sbagliata ti manda a un modello da 2 miliardi di parametri o alla generazione sbagliata di quello giusto.

• Bonsai — il nome della famiglia, e il nome con cui il fornitore la indica. Da solo non identifica nulla che si possa scaricare. PrismML ha rilasciato Bonsai 1.7B, Bonsai 4B, Bonsai 8B, Bonsai 27B e Bonsai Image, oltre al modello per occhiali da 2 miliardi di parametri, e una release precedente dell'aprile 2026 chiamata Ternary Bonsai per la linea più piccola. Una ricerca della sola parola finisce a caso in quell'insieme.

• Bonsai 27B — l'oggetto di questa pagina. Prima generazione della linea 27B, derivata da Qwen3.6-27B, datata 14 luglio 2026. Quando una pagina dice "Bonsai 27B" senza altri qualificatori e senza "2", è questo il modello che intende, e questo è il nome da usare.

• Ternary Bonsai 27B — non è un modello diverso. È il pacchetto orientato alla qualità di Bonsai 27B: lo stesso modello 27B, la stessa architettura e la stessa base, con pesi ternari invece che binari. Il repository si chiama Ternary-Bonsai-27B-gguf, e la sua model card indica Qwen3.6-27B come base esattamente come fa la card binaria. "Ternary" qui è un formato di pesi, non una versione.

• Ternary Bonsai 2 27B — un modello davvero diverso. La seconda generazione della linea 27B, basata su Qwen3.8-27B e annunciata il 17 settembre 2026, con una diversa suddivisione dei parametri e una diversa dichiarazione di qualità. Il "2" racchiude tutta la distinzione.

• 1-bit Bonsai 2B — un membro diverso della famiglia a una scala diversa: un modello visione-linguaggio da 2 miliardi di parametri per hardware di classe occhiali, non un modello da 27B a qualsiasi precisione.

Quindi, se sei venuto qui per stabilire quale di questi sia il modello 27B, la risposta è che la terza e la quarta riga sopra sono lo stesso modello in due formati di pesi, e la quinta è quella che non lo è. In pratica: chiamalo Bonsai 27B e aggiungi il pacchetto quando conta.

La specifica, dalla scheda del modello

Ogni cifra in questa sezione proviene dalle model card pubblicate da PrismML per i due pacchetti, ed è una dichiarazione del fornitore stesso sul proprio modello. Laddove un numero è un'asserzione anziché una misurazione, viene etichettato come tale.

• Parametri — circa 27,3 miliardi in totale, e il "27B" si riferisce all'intero. La suddivisione vale la pena conoscerla perché spiega il comportamento della memoria: all'incirca 24,8 miliardi risiedono nel backbone linguistico attraverso 64 blocchi, circa 2,5 miliardi nell'embedding e nella LM head, e circa 0,46 miliardi in una torre di visione da 27 blocchi. La rappresentazione a bassi bit è applicata end-to-end — embedding, attenzione, MLP e LM head — senza alcuna via di fuga a precisione superiore nella rete linguistica.

• Contesto — ben 262.000 token, senza variante a contesto lungo e senza build a contesto ridotto. Il costo di quella finestra viene gestito anziché pagato per intero: il backbone è ibrido, quindi solo 16 dei suoi 64 layer mantengono una cache di attenzione completa, e quella cache è memorizzata in una forma a 4 bit quasi senza perdite. Alla finestra completa di 262K è la cache compressa a mantenere il modello entro circa 9,4 GB sul pacchetto binario e 12,8 GB su quello ternario.

• Modalità — testo e immagini, entrambi i pacchetti. La torre di visione viene fornita in una forma compatta a 4 bit (0,63 GB) con accanto una copia BF16 (0,93 GB). La visione è anche l'ambito in cui la compressione costa di più, aspetto trattato di seguito.

• Formato del peso e dimensione — Bonsai 27B a 1 bit utilizza pesi binari {−1, +1} con scaling group-wise in FP16, impacchettati come GGUF Q1_0_g128 a un valore reale di 1,125 bit effettivi per peso; il file distribuito è di 3,803 GB e la scheda arrotonda l'occupazione effettiva a circa 3,9 GB. Bonsai 27B ternario utilizza pesi ternari {−1, 0, +1} con lo stesso scaling group-wise; un valore ternario trasporta log₂3 ≈ 1,585 bit di informazione, quindi il limite inferiore della rappresentazione è di ~1,71 bit per peso, che corrisponde a 5,9 GB ideali. Il pacchetto ternario pubblicato è più grande di quel valore ideale, perché i kernel odierni memorizzano ogni valore ternario in uno slot da 2 bit — 2,125 bit per peso effettivamente impiegati — e il file distribuito è di 7,165 GB. PrismML dichiara entrambi i numeri anziché solo quello più lusinghiero, e il divario tra i due è una limitazione dei kernel, non una scelta di modellazione.

• Licenza — Apache 2.0 su entrambi i pacchetti, dichiarata su entrambi i repository e nell'annuncio del fornitore. Si tratta di una licenza permissiva senza restrizioni sull'ambito di utilizzo, il che a questa dimensione di pesi conta più che nella maggior parte dei casi.

• Modello base — Qwen3.6-27B in entrambi i casi. Questa è una ri-compressione del modello di qualcun altro anziché un modello addestrato da zero, e la conseguenza è che sia il tetto di capacità di Bonsai 27B sia la sua cadenza di aggiornamento seguono la linea 27B upstream anziché quella di PrismML.

La relazione ternaria, enunciata una volta

I due pacchetti sono un unico modello, e la sintesi onesta è che il ternario punta sulla qualità e il binario sull’ingombro, con un divario tra i due più piccolo di quanto suggerisca la differenza di dimensioni da 3,9 GB contro 7,2 GB.

Nella suite thinking-mode di 15 benchmark propria di PrismML, la baseline FP16 Qwen3.6-27B ottiene 85,07. Ternary Bonsai 27B ottiene 80,49 — una ritenzione del 94,6%, che il fornitore arrotonda a circa il 95%. 1-bit Bonsai 27B ottiene 76,11 — 89,5%, arrotondata a circa il 90%. Quindi il pacchetto orientato alla qualità recupera all'incirca metà della distanza tra il pacchetto binario e la piena precisione, costando circa 3,3 GB in più, e il pacchetto binario è quello che entra in un telefono da 12 GB. La stessa suite mostra una build 4-bit Q4_K_XL della stessa baseline a 84,99, ovvero una ritenzione del 99,9%, in 17,6 GB — che è il confronto che spiega perché esista anche solo uno dei due pacchetti low-bit, dato che li batte sulla qualità e perde su ogni dispositivo che ha meno di 18 GB da dare a un modello.

Dove il pacchetto binario cede terreno è in modo disomogeneo, e la suddivisione per categoria è la parte utile. Rispetto alla baseline FP16 scende da 95,33 a 91,66 sulla matematica e da 88,74 a 81,88 sul coding, ma da 78,47 a 65,74 sul rispetto delle istruzioni, da 80,00 a 66,03 sulle attività agentiche e di chiamata agli strumenti, e da 72,61 a 59,57 sulla visione. Se il tuo carico di lavoro è aritmetica o completamento di codice, 3,9 GB è quasi gratis. Se si tratta di agenti che chiamano strumenti o di comprensione delle immagini, è qui che la compressione viene effettivamente pagata.

La scheda del modello pubblica anche una metrica derivata che chiama densità di intelligenza — punteggio aggregato per gigabyte, normalizzata in modo che un punteggio perfetto tenda all'infinito. Su tale misura 1-bit Bonsai 27B raggiunge 0,530 e Ternary Bonsai 27B 0,400, contro 0,199 per una build a 2 bit IQ2_XXS dello stesso baseline, 0,155 per una build a 4 bit Q4_K_XL e 0,051 per il modello FP16. Il numero interessante in quell'elenco è il primo confronto: il pacchetto binario batte la build convenzionale a 2 bit sulla qualità aggregata con meno della metà dell'ingombro, che è l'intera tesi della famiglia in una riga.

Il confronto completo testa a testa tra i due pacchetti, e da dove derivano i numeri di ciascuno, è illustrato nella pagina Bonsai vs Bonsai 27B su questo blog, insieme al modello da 2 miliardi di parametri che condivide il nome della famiglia.

Una domanda che si presenta con questo modello merita una risposta fattuale e niente di più. I pacchetti sono codifiche a basso numero di bit dello stesso modello sottostante, non una variante riaddestrata, e i repository non pubblicano accanto ad essi alcun checkpoint ottimizzato separatamente o non censurato — l'unico artefatto a piena precisione offerto è una conversione FP16 spacchettata degli stessi pesi, pubblicata così che tu possa confrontare un pacchetto compresso con la sua stessa baseline negli strumenti standard.

Pesi e licenza, dai repository

I pesi di Bonsai 27B sono pubblicati su Hugging Face sotto l'organizzazione prism-ml, e l'elenco dei file è la cosa più concreta del rilascio. Il repository del pacchetto binario contiene il modello stesso a 3,803 GB, un GGUF FP16 dello stesso modello a 53,808 GB per confronto, un drafter DSpark per la decodifica speculativa a 1,787 GB in 4-bit e 7,292 GB in BF16, e le vision tower a 0,931 GB e 0,629 GB. Il repository ternario contiene il proprio pacchetto da 7,165 GB più un secondo packing da 7,585 GB, che è group-64 anziché group-128 e compatibile con upstream anziché ottimale, oltre agli stessi file del drafter e della vision. Entrambi i repository sono Apache 2.0 ed entrambi indicano Qwen3.6-27B come base.

Da quell'elenco derivano due cose. La prima è che 53,808 GB contro 3,803 GB è il rapporto di 14,2x con cui esordisce la scheda del modello, ed è verificabile anziché asserito — il file a piena precisione è proprio lì. La seconda è che il rilascio è più pesante del modello: se si prendono in considerazione anche il drafter e la torre di visione, che il percorso multimodale richiede, si aggiungono circa 2,4 GB a un modello da 3,9 GB. Il dato di 3,9 GB in evidenza riguarda i pesi del linguaggio, non il deployment.

I download sono l'unico ambito in cui il pacchetto orientato alla qualità è in vantaggio: a ottobre 2026 il repository GGUF ternario ha superato i 590.000 download contro poco più di 400.000 del pacchetto binario, mentre i contenitori MLX di entrambi si attestano oltre il milione ciascuno. La forma di questi dati suggerisce che la maggior parte di questo modello venga eseguita su hardware Apple anziché su server, e che le persone che lo scaricano stiano comprando i cinque punti di ritenzione in più anziché il file più piccolo possibile — che è all'incirca ciò per cui il fornitore ha progettato la coppia.

Eseguendolo

Quello che puoi ottenere oggi sono quattro tipi di artefatto per pacchetto, e quale ti serve è deciso dal tuo runtime, non dalla qualità.

• GGUF per llama.cpp — il percorso principale, e quello per cui sono stati scritti i kernel a basso numero di bit. Entrambi i pacchetti sono build di llama.cpp per CUDA, Metal e CPU, ma i kernel a 1 bit e ternari risiedono nel fork proprietario di PrismML anziché upstream, quindi llama.cpp standard non riesce ancora a caricarli correttamente. Il packing ternario group-64 esiste proprio per i casi in cui serve la compatibilità upstream e si è disposti ad accettare 7,585 GB invece di 7,165 GB per ottenerla.

MLX per Apple silicon — container rilasciati a 5,031 GB per il pacchetto binario e 8,491 GB per il container binario MLX, che è una differenza di overhead del container piuttosto che un modello diverso.

• AWQ 4-bit per framework server — una build a 4 bit di ciascun modello per i framework di serving che richiedono un checkpoint AWQ, in nove shard per un totale di 18,70 GB, inclusa una ricetta multi-GPU. Questo non è un artefatto a basso bit; è lo stesso modello a una precisione che ha senso su un rack, e sacrifica l'intera ragione per cui il modello esiste.

• Safetensors FP16 scompattati — il modello completo da ~54 GB nel formato Hugging Face standard, pubblicato esplicitamente per i framework che non supportano ancora nativamente i pesi a 1 bit. Il fornitore afferma che questo artefatto verrà ritirato non appena i kernel a basso bit arriveranno upstream.

La velocità di decodifica misurata sul pacchetto binario, dalla tabella della scheda modello stessa, è di 66,4 token al secondo su un M5 Max, 44,2 su un M5 Pro, 26,0 su un M4 Pro e 104,8 su un H100, con prefill a 874, 421, 133 e 2.755 token al secondo rispettivamente. La pagina di annuncio cita picchi superiori — fino a 87 token al secondo su un M5 Max e 163 su un RTX 5090 — che sono la configurazione ottimale del fornitore stesso piuttosto che quella della tabella. Considera i due insiemi come condizioni di misurazione diverse, non come una contraddizione, e considera entrambi come dichiarati dal fornitore. La memoria di picco, sempre dalla scheda, è di 5,2 GB con un contesto 4K, 5,6 GB a 10K e 11,6 GB a 100K sul pacchetto binario, e 8,4, 8,7 e 14,7 GB sul pacchetto ternario — con l'avvertenza che quei dati precedono la KV cache a 4 bit, che è ciò che porta l'intera finestra di 262K a gigabyte a una sola cifra.

Il drafter DSpark è opzionale e vale la pena capirlo prima di abilitarlo, perché non cambia nulla negli output: è un transformer block-parallel a sei strati, condizionato su stati nascosti prelevati da cinque strati target equidistanti, aggiunge circa 0,5 GB alla precisione di serving e verifica rispetto al modello target invece di campionare autonomamente. Ecco perché il fornitore può citare un speedup di 1,37x su CUDA senza toccare i valori di qualità. Non è abilitato per impostazione predefinita su Apple silicon.

Il punto in cui il modello locale esaurisce la strada è la domanda ingegneristica interessante, e si tratta di una questione di instradamento più che di modello. Un modello da 3,9 GB su un laptop gestisce ciò che rientra nel suo contesto; tutto il resto deve pur andare da qualche parte, e quel "qualche parte" è un modello ospitato dietro un'API. OrcaRouter è quello strato — un unico endpoint su oltre 200 modelli ospitati con markup dello 0% sui prezzi di listino dei provider, failover automatico tra provider, e la regola di escalation da un livello locale a uno ospitato espressa come configurazione anziché assemblata a mano. È lo strato sopra un modello locale, non un suo sostituto.

L'indice di confronto

Bonsai 27B fa parte di una famiglia in cui ogni vicino risponde a una domanda diversa, e queste sono le pagine che si occupano di ciascuna — nessuna di esse viene qui argomentata di nuovo.

• Bonsai vs Bonsai 27B — il modello per occhiali da 2 miliardi di parametri contro questo: sedici volte i parametri e duecentocinquantasei volte il contesto, e perché il nome della famiglia non fornisce alcuna informazione su ciò che stai scaricando. La pagina è un post di blog qui, non un modello ospitato, una distinzione che vale la pena tenere a mente in questa famiglia.

• Bonsai 27B contro Qwen3.8-27B — il confronto diretto tra questo modello e la base più recente che non utilizza. Una pagina dedicata in questa serie contiene quel confronto, e poiché i due modelli hanno nomi simili e distano una generazione l'uno dall'altro, vale la pena leggerla di per sé anziché come estensione di questa specifica.

• Bonsai vs Ternary Bonsai 2 27B — il salto generazionale, e il fatto che le due versioni riportino la loro qualità rispetto a due metri diversi: il mantenimento di una baseline in un caso, un'affermazione comparativa nell'altro.

• Ternary Bonsai 2 27B — la seconda generazione a sé stante, su Qwen3.8-27B, per i lettori che hanno deciso di volere il modello più recente anziché questo.

Ciò che non è stabilito

Ogni dato di qualità in questa pagina è di PrismML, misurato sulla suite di 15 benchmark di PrismML stessa, e nessuno al di fuori dell'azienda ne ha pubblicato una riproduzione. Questa è la più grande lacuna in ciò che si sa di Bonsai 27B: le affermazioni sulla compressione sono insolitamente specifiche e insolitamente verificabili, e restano non verificate da terzi. Il fornitore è anche esplicito nel dire che il coding agentico — flussi di lavoro a lungo orizzonte, multi-file, di esecuzione e riparazione — non è un obiettivo forte di questa release e che una variante ottimizzata per esso è la prossima cosa nella roadmap, il che è coerente con le perdite nel tool calling e nel seguire le istruzioni nella suddivisione per categoria sopra. Finché non esisterà una valutazione indipendente, sia il dato di ritenzione sia la classifica di densità dovrebbero essere letti come la posizione del fornitore, non come un risultato consolidato.

Ciò che è assodato è più ridotto e più utile: i pesi esistono, le dimensioni sono verificabili rispetto all'elenco dei file, la licenza è Apache 2.0, e i due pacchetti differiscono di circa 3,3 GB in cambio di circa cinque punti di qualità mantenuta. Questo basta per scegliere tra i due. Quale dei due sia adatto a te dipende dal fatto che il tuo carico di lavoro assomigli più all'aritmetica o più all'invocazione di strumenti, e i numeri per categoria sopra riportati sono la migliore evidenza disponibile oggi per quella decisione.