Bonsai vs Bonsai 27B: Un nome di famiglia, sedici volte i parametri

Chiunque acquisti questa famiglia in base al nome otterrà il modello sbagliato, e il motivo è che il semplice nome "Bonsai" non è un modello. È la famiglia e, da questa settimana, la famiglia contiene un modello vision-linguaggio da 2 miliardi di parametri che gira su un paio di smart glasses e un modello da 27 miliardi di parametri che gira su un telefono, un laptop o un desktop. Il primo è il modello vision-linguaggio Bonsai 2B a 1 bit annunciato il 23 settembre 2026 — un modello linguistico da 1,7B a 1 bit più un encoder visivo da 0,3B a 4 bit, contesto di 1.024 token, basato su Bonsai 1.7B. Il secondo è Bonsai 27B, rilasciato il 14 luglio 2026 con licenza Apache 2.0, basato su Qwen3.6-27B con un contesto di 262.000 token e la scelta tra una build ternaria da 5,9 GB o una build binaria da 3,9 GB. Condividono un nome, un fornitore, una filosofia di compressione e quasi nient'altro. Sedici volte i parametri, duecentocinquantasei volte il contesto e due dispositivi completamente diversi.

Questa pagina è per la persona che ne ha cercato uno ed è finita sull'altro.

Il problema della denominazione, detto chiaramente

Il menu dei modelli di PrismML attualmente elenca Bonsai 2 27B, Bonsai 27B, Bonsai 8B, Bonsai 4B, Bonsai 1.7B e Bonsai Image. L'annuncio degli occhiali aggiunge un modello visione-linguaggio da 2 miliardi di parametri alla linea Bonsai 1.7B. Quindi "Bonsai" da solo può indicare una qualsiasi di almeno quattro classi di parametri e due generazioni, e il suffisso di dimensione è l'unica cosa che disambigua. Non è una critica alla denominazione — è la normale conformazione di una famiglia di modelli — ma significa che il nome della famiglia non fornisce alcuna informazione su ciò che si sta scaricando.

Il taglio utile non è la generazione, è la classe di dispositivo. Tutto nella linea 27B presuppone che tu abbia tra 4 GB e 8 GB di memoria da dare a un modello linguistico e che sia disposto a spenderla. Tutto nella linea 1.7B presuppone che tu abbia qualche centinaio di megabyte e non di più. Quel singolo fatto determina quale metà della famiglia è rilevante per te prima che qualsiasi benchmark possa farlo.

Cosa sia in realtà ognuno

• Parametri — LLM 1-bit da 1,7B più un encoder visivo 4-bit da 0,3B nel modello degli occhiali, contro un modello di classe 27B derivato da Qwen3.6-27B in Bonsai 27B.

• Contesto — 1.024 token sul modello occhiali, rispetto a un contesto completo di 262.000 token su Bonsai 27B.

• Pesi del modello linguistico — 0,43 GB per il 1.7B a 1 bit, contro 5,9 GB per il Bonsai 27B ternario e 3,9 GB per la sua build a 1 bit.

• Rappresentazione — pesi binari {−1, +1} con scaling group-wise in FP16 in entrambi, che è la ricetta a 1 bit su cui si fonda la famiglia; Bonsai 27B offre inoltre una build ternaria {−1, 0, +1} a 1,71 bit effettivi per peso.

• Silicio target — la NPU Qualcomm Hexagon sulla piattaforma per occhiali Snapdragon AR1 Gen 1, compilata tramite un QNN SDK con supporto ai kernel a 1 bit, contro Apple silicon tramite MLX e NVIDIA tramite CUDA per Bonsai 27B.

• Throughput di decodifica — 15,36 token al secondo su una piattaforma di test AR1 Gen 1 da 4 GB per il modello degli occhiali, contro circa 11 token al secondo su un iPhone 17 Pro, 87 su un Apple M5 Max e 163 su una RTX 5090 per il Bonsai 27B a 1 bit.

Ognuno di quei valori è del fornitore, e i due insiemi sono stati misurati su hardware diverso rispetto a baseline diverse, quindi descrivono due prodotti anziché due punti su una curva.

Dove Bonsai 27B vince, e non c'è partita

Il contesto è al primo posto, e il margine non è una sfumatura. Una finestra da 262.000 token contiene una base di codice, un documento lungo, una trascrizione o una sessione di agente in corso con spazio in abbondanza. Una finestra da 1.024 token contiene una breve istruzione e un'immagine. Se il tuo carico di lavoro prevede la lettura di qualsiasi cosa più lunga di una pagina, Bonsai 27B è l'unico dei due che possa fare il lavoro, e nessuna quantità di prompting intelligente sul modello per occhiali colmerà quel divario, perché il limite è la memoria riservata allo stato chiave-valore, non la dimensione dei pesi.

La capacità è il secondo punto. Si dice che la build ternaria di Bonsai 27B mantenga circa il 95% della sua baseline a piena precisione su una suite di 15 benchmark in modalità thinking, e che la sua build a 1 bit ne mantenga circa il 90%, con le perdite maggiori nella visione e nell'uso degli strumenti. Quelli sono dati del fornitore sulla suite del fornitore stesso, e restano comunque una categoria diversa rispetto a un modello da 2 miliardi di parametri la cui unica dichiarazione pubblicata sulla qualità è di aver ottenuto "risultati comparativi nei benchmark" rispetto a Qwen 3 1.7B a 4 bit. Il modello per gli occhiali non viene confrontato con un modello da 27B dal suo stesso produttore, perché il confronto non sarebbe utile.

L'ecosistema è il terzo. Bonsai 27B arriva in pacchetti GGUF, MLX e AWQ con runtime documentati, quindi esiste un percorso per eseguirlo su hardware che già possiedi. Il modello per gli occhiali esiste all'interno di una toolchain NPU di Qualcomm.

Dove 2B vince, ed è questo l'intero punto

Un modello linguistico da 0,43 GB entra in posti in cui uno da 5,9 GB non può andare, e la piattaforma degli occhiali è uno di questi. Questo è l'intero argomento, ed è un argomento più forte di quanto il contrasto tra le specifiche lo faccia sembrare, perché i dispositivi in questione non hanno alternative: un paio di occhiali con 4 GB di memoria condivisa della piattaforma non può ospitare Bonsai 27B in nessuna build, e un telefono non può ospitare la build ternaria senza rinunciare alla maggior parte di ciò per cui il telefono serve.

C'è un secondo vantaggio che riceve meno attenzione: la rappresentazione a 1 bit non è un compromesso in questa classe di dispositivi, è il trucco che rende tutto possibile. Secondo la stessa impostazione di PrismML, il percorso a 1 bit offre all'incirca un'intelligenza equivalente a quella dello stesso modello a precisione a 4 bit, usando circa un quarto della memoria e generando token a più del doppio della velocità. Per un dispositivo sempre attivo, in cui ogni milliwatt e ogni megabyte sono contesi, quel compromesso è il prodotto.

Quindi i due modelli non sono in competizione. Il 2B è quello che viene eseguito quando non c'è nessun altro posto in cui farlo. Il 27B è quello che viene eseguito quando c'è.

Il confine del livello è la vera decisione

Quasi nessuno sceglie tra questi due. Una distribuzione realistica li prevede entrambi: un piccolo modello sempre attivo sul dispositivo per le richieste che rientrano in 1.024 token, e qualcosa di più grande dietro di esso per tutto il resto. Una volta accettata questa struttura, la domanda ingegneristica smette di essere «quale Bonsai» e diventa «dov'è il confine, e chi lo fa rispettare».

Se applicata nel codice dell'applicazione, quella riga diventa un ramo che deve essere riscritto ogni volta che il modello sul dispositivo cambia lunghezza del contesto o capacità — cosa che, stando alle evidenze degli ultimi tre mesi, avviene più o meno ogni mese. Se applicata come politica di routing, diventa un'unica regola sul budget di contesto e sulla capacità richiesta, e il tier locale resta un tier invece di trasformarsi in un presupposto incorporato in tutto il client. È questo il livello a cui opera OrcaRouter: un unico endpoint davanti a oltre 200 modelli ospitati, con failover e la politica di escalation espressa nella configurazione. Nessuno dei due Bonsai viene instradato qui — entrambi sono download che esegui sul tuo hardware — quindi la formulazione onesta è che il livello di routing copre il tier al di sopra di quello locale, e con un modello locale da 1.024 token è in quel tier che finirà la maggior parte del traffico.

Se devi sceglierne uno

• Stai sviluppando per occhiali, dispositivi indossabili o qualsiasi dispositivo sempre attivo — il modello visione-linguaggio 1-bit Bonsai 2B è l'unica opzione qui, e il contesto di 1.024 token è il vincolo di progettazione su cui costruisci, non contro cui combatti.

• Stai sviluppando per un telefono — 1-bit Bonsai 27B a 3,9 GB è il modello più grande di questa famiglia che rientra in un budget di memoria di classe iPhone, e ti offre un contesto da 262K che il modello per occhiali non può neanche avvicinare.

• Stai sviluppando per un laptop o un desktop — la build ternary Bonsai 27B è la scelta orientata alla qualità all'interno della famiglia, mentre la build a 1 bit offre velocità anziché capacità.

• Stai costruendo un ibrido — decidi prima la regola di escalation e solo dopo il modello. Il modello puoi scambiarlo; il confine no, una volta che è nel client.

Ciò che vale la pena osservare è se il percorso NPU che ha reso possibile il lancio degli occhiali si estende verso l’alto. Se i kernel a 1 bit sugli acceleratori mobili si generalizzano, la linea da 1,7B diventa più grande e la tesi a favore di un modello da 27B su un telefono si rafforza. Fino ad allora, le due metà della famiglia restano nettamente separate per classe di dispositivo, il che rende la scelta più facile di quanto suggerisca il nome condiviso.