PrismML Bonsai 2 27B riduce l'AI locale, ma i test più difficili contano ancora

PrismML ha lanciato Bonsai 2 27B il 17 settembre, comprimendo un modello da 27 miliardi di parametri in un pacchetto da 5,9GB destinato all'hardware consumer. L'azienda afferma che PrismML Bonsai 2 27B conserva il 98,2% delle prestazioni aggregate nei benchmark della controparte a piena precisione.

Questa combinazione cambia i termini dell'AI locale. In precedenza, gli sviluppatori dovevano scegliere tra modelli più piccoli, che si adattano facilmente all'hardware disponibile, e modelli più grandi con capacità di ragionamento superiori. Bonsai 2 mette in discussione questo compromesso, portando un sistema multimodale di classe 27B nella fascia di memoria di laptop e schede grafiche consumer.

Tuttavia, far entrare i pesi in memoria è solo il primo test. I risultati aggregati di PrismML sono riportati dal fornitore, diversi formati di pacchettizzazione occupano più di 5,9GB e il modello dipende attualmente da componenti runtime personalizzati. La domanda principale è se modelli locali compatti possano restare affidabili durante attività lunghe e guidate da strumenti.

PrismML Bonsai 2 27B inserisce AI di classe 27B in 5,9GB

Il lancio è rilevante perché PrismML ha ridotto l'ingombro del modello linguistico senza modificare l'architettura 27B sottostante.

Bonsai 2 deriva da Qwen3.8-27B, un modello multimodale in grado di gestire testo e immagini. PrismML ha mantenuto l'architettura convertendo la maggior parte dei pesi del modello linguistico in una rappresentazione ternaria.

I pesi ternari usano tre possibili valori: meno uno, zero e più uno. Un valore di scala condiviso consente al runtime di tradurre questi valori compatti in operazioni numeriche utili durante l'inferenza.

Questa rappresentazione differisce dalla semplice eliminazione di parametri o dalla sostituzione del modello con un'architettura più piccola. Bonsai 2 contiene ancora circa 27 miliardi di parametri, ma ogni peso compresso richiede molto meno spazio rispetto a un valore convenzionale a 16 bit.

L'annuncio di lancio di PrismML descrive un modello da 27,8 miliardi di parametri addestrato usando TPU Google v5. I materiali più dettagliati sul modello indicano 27,36 miliardi di parametri totali, inclusi il backbone linguistico, i livelli di embedding, la testa di output e la torre visiva.

Il più piccolo pacchetto GGUF pubblicato usa il formato PTQ1_0 di PrismML. Memorizza il componente linguistico in circa 5,95GB, rispetto a circa 54GB per il riferimento a piena precisione.

Un secondo pacchetto GGUF, chiamato PQ2_0, occupa circa 7,21GB. I pesi linguistici MLX per dispositivi Apple usano circa 7,67GB perché quel contenitore memorizza ulteriori informazioni di scala.

Il pacchetto MLX completo raggiunge 8,60GB dopo l'aggiunta della torre visiva non compressa da 0,92GB. Pertanto, il dato di 5,9GB in evidenza descrive la più piccola configurazione del modello testuale, non ogni configurazione scaricabile.

Questa distinzione non cancella il risultato. Anche i pacchetti più grandi restano ben al di sotto del fabbisogno di memoria del modello a piena precisione. Tuttavia, influenza ciò che acquirenti e sviluppatori dovrebbero aspettarsi da uno specifico download.

Secondo la documentazione, il modello conserva una capacità di contesto di 262.144 token. Una finestra di contesto è la quantità di testo o di altre informazioni tokenizzate che un modello può elaborare in una singola interazione.

Bonsai 2 conserva anche l'architettura ad attenzione ibrida di Qwen3.8-27B. Circa tre quarti dei suoi livelli usano attenzione lineare, che limita la crescita della memoria associata ai prompt lunghi.

PrismML ha rilasciato i pesi con licenza Apache 2.0. L'azienda fornisce build GGUF per distribuzioni basate su llama.cpp e una versione MLX per hardware Apple.

Questa disponibilità offre agli sviluppatori un maggiore controllo rispetto a un servizio esclusivamente cloud. I team possono ispezionare i file, eseguire l'inferenza nel proprio ambiente e testare il modello senza inviare ogni prompt a un fornitore esterno.

Il rilascio si basa sul primo modello Bonsai 27B di PrismML, presentato nel luglio 2026. Quella generazione precedente ha definito l'approccio di compressione dell'azienda, mentre Bonsai 2 lo applica a un modello base Qwen più recente.

Il nuovo lancio aumenta la conservazione delle prestazioni aggregate dichiarata da circa il 95% al 98,2%. Ancora più importante, sposta la proposta di PrismML dall'esecuzione locale di un grande modello alla conservazione di qualità sufficiente per un lavoro serio.

Perché un modello locale da 27B mette sotto pressione le alternative più piccole

Bonsai 2 mette sotto pressione l'idea che il deployment locale richieda di scendere a un modello di classe 8B.

Gli utenti di modelli locali devono di solito bilanciare tre vincoli interconnessi: memoria, velocità di risposta e qualità dell'output. Aumentare le dimensioni del modello può migliorarne le capacità, ma aumenta anche i requisiti di archiviazione, larghezza di banda della memoria e runtime.

La quantizzazione convenzionale riduce questi requisiti rappresentando i pesi del modello con meno bit. Tuttavia, una quantizzazione aggressiva può danneggiare le prestazioni in modo disomogeneo, soprattutto nelle attività che richiedono ragionamenti estesi o il rispetto preciso delle istruzioni.

PrismML sostiene che il suo approccio ternario cambi questa curva. La sua scheda del modello riporta una media reale di 1,72 bit per peso per la rappresentazione principale.

Nella valutazione in modalità di ragionamento di PrismML su 14 benchmark, la build Bonsai da 5,9GB ha ottenuto un punteggio medio di 84,78. Il riferimento Qwen3.8-27B a piena precisione ha ottenuto 86,32.

Una build convenzionale IQ2_XXS occupava 9,4GB nello stesso confronto e ha ottenuto 72,59. Una build UD-Q4_K_XL più grande ha raggiunto 85,18 usando 17,6GB.

Questi dati sostengono un'affermazione circoscritta ma importante. Nella configurazione di test di PrismML, Bonsai 2 ha conservato una qualità aggregata sostanzialmente maggiore rispetto al confronto convenzionale a basso numero di bit.

La compressione consente inoltre al modello linguistico completo di restare in memoria veloce su più dispositivi. Quando i pesi finiscono nella memoria di sistema più lenta, l'inferenza può diventare troppo lenta per un uso interattivo.

PrismML riporta fino a 143 token generati al secondo su una Nvidia GeForce RTX 5090. Le sue misurazioni Apple includono circa 47 token al secondo su un M5 Max e 28,7 su un M5 Pro.

Questi risultati dipendono dall'hardware e provengono dall'azienda. Non dovrebbero essere trattati come velocità universali, poiché lunghezza del prompt, formato di pacchettizzazione, runtime e condizioni termiche incidono tutti sul throughput.

Ciononostante, la gamma di deployment è significativa. Uno sviluppatore potrebbe potenzialmente eseguire un assistente di coding privato su una workstation, mentre un laptop Apple può ospitare un valido modello locale per ricerca o documenti.

Questo crea pressione sui modelli general-purpose più piccoli. Un modello da 8B mantiene vantaggi in termini di tempo di avvio, overhead di memoria e supporto su hardware meno recente. Tuttavia, la sola dimensione della memoria diventa una ragione più debole per sceglierlo se un modello compresso da 27B entra nello stesso dispositivo.

I fornitori cloud affrontano una pressione diversa. L'inferenza locale può eliminare la latenza di rete e mantenere i prompt entro il perimetro di sicurezza di un'organizzazione.

Si consideri un team di ingegneria che lavora con codice sorgente proprietario. Un modello locale può revisionare file, generare test e cercare documenti tecnici senza trasmettere il repository a un servizio di inferenza remoto.

La stessa logica si applica a dati personali, note di riunioni interne e documenti regolamentati. I team possono abbinare un modello locale a una base di conoscenza ricercabile, mantenendo recupero e generazione vicino al materiale sorgente.

I modelli cloud resteranno preferibili per molte attività impegnative. Possono offrire capacità più solide, scalabilità gestita e supporto operativo maturo.

La sfida immediata non è quindi che l'AI locale sostituisca il cloud. È che i modelli locali diventino abbastanza capaci da gestire una quota maggiore del lavoro ordinario, privato e sensibile alla latenza.

La compressione ternaria è il meccanismo alla base dell'ingombro ridotto

Bonsai 2 riduce il traffico di memoria memorizzando la maggior parte dei pesi linguistici come codici compatti a tre valori, elaborati direttamente da kernel personalizzati.

L'inferenza standard a piena precisione memorizza tipicamente ogni peso con 16 bit. Per un modello denso con decine di miliardi di parametri, questi valori creano un grande ingombro di memoria prima ancora di considerare lo stato del runtime.

Bonsai 2 assegna a ogni peso compresso uno di tre valori. PrismML raggruppa 128 pesi sotto una scala condivisa a 16 bit, portando la rappresentazione effettiva dichiarata a circa 1,71 bit per peso.

Un piccolo insieme di tensori a precisione più elevata aumenta la media dell'intero modello a 1,72 bit. PrismML afferma che tali tensori rappresentano circa lo 0,098% del modello linguistico.

La conversione usa anche una rotazione di Hadamard, una trasformazione matematica applicata prima dell'assegnazione ternaria. Essa ridistribuisce valori insolitamente grandi che altrimenti possono rendere meno accurata la quantizzazione a basso numero di bit.

In fase di runtime, una trasformazione corrispondente viene applicata alle attivazioni, ovvero i valori intermedi generati mentre l'input attraversa la rete. I pesi impacchettati restano compressi invece di espandersi nuovamente a piena precisione.

Questo design è importante perché l'inferenza locale è spesso limitata dalla larghezza di banda della memoria. Il processore sposta ripetutamente i pesi dalla memoria durante la produzione dei token, quindi ridurre i byte mossi a ogni passaggio può migliorare velocità e consumo energetico.

Il repository del runtime supporta deployment CUDA, Metal, Vulkan, ROCm e orientati alla CPU attraverso diverse generazioni Bonsai. Fornisce inoltre integrazioni per serving locale, visione e strumenti.

Al lancio, Bonsai 2 presenta una limitazione di compatibilità. La trasformazione di attivazione Hadamard richiesta non è ancora stata integrata nel progetto standard llama.cpp.

Al momento, gli utenti devono affidarsi al fork di PrismML o ai binari installati dai suoi script di configurazione. Questo crea una dipendenza dall'implementazione e dalla cadenza di rilascio dell'azienda.

La differenza tra i formati di pacchettizzazione aggiunge un ulteriore livello. PTQ1_0 usa una memorizzazione più densa e raggiunge la dimensione in evidenza di 5,95GB, mentre PQ2_0 colloca ciascun valore ternario in uno slot da due bit.

Un impacchettamento più denso riduce il traffico di memoria, ma la sua decodifica richiede più calcoli. Le misurazioni di PrismML mostrano che nessuno dei due formati è sempre più veloce su ogni processore grafico.

La versione Apple MLX presenta un altro compromesso. Il suo contenitore memorizza sia una scala sia un bias per ogni gruppo, aumentando il pacchetto del modello linguistico a 7,67GB.

Gli sviluppatori dovrebbero quindi scegliere un formato in base al runtime effettivo invece di scaricare automaticamente il file più piccolo. La build ottimale dipende dalla memoria disponibile, dai kernel supportati, dalla generazione del processore e dalle esigenze di elaborazione dei prompt.

Anche il sistema visivo resta al di fuori della narrazione principale sulla compressione. PrismML include la torre visiva Qwen da 0,92GB a piena precisione invece di convertirla in pesi ternari.

Questa scelta aiuta a spiegare perché un pacchetto multimodale completo occupi più spazio del dato testuale di 5,9GB. Potrebbe inoltre proteggere la qualità visiva da ulteriori perdite dovute alla quantizzazione.

In termini pratici, Bonsai 2 non è semplicemente un file minuscolo che funziona ovunque. È un sistema coordinato di modello e runtime, i cui vantaggi dipendono da kernel low-bit compatibili.

Questo rende il rilascio tecnicamente più interessante di un normale caricamento di quantizzazione post-addestramento. Rende anche l'adozione nell'ecosistema una parte essenziale della storia.

L'affermazione del 98,2% richiede una lettura più attenta

Il risultato aggregato dei benchmark è incoraggiante, ma non significa che Bonsai 2 conservi il 98,2% di ogni capacità o flusso di lavoro.

L'annuncio pubblico di PrismML cita un punteggio aggregato di 83,9 su una suite di 20 benchmark. Confronta tale risultato con 85,4 per Qwen3.8-27B, producendo il dato di conservazione del 98,2% riportato.

La scheda modello dettagliata presenta una diversa aggregazione di 14 benchmark. Qui, Bonsai 2 ottiene 84,78 contro 86,32 a piena precisione, pari anch’esso a circa il 98,2%.

Entrambi i calcoli sono riportati dall’azienda. Le diverse suite e i diversi totali non dovrebbero essere combinati come se rappresentassero un unico test riprodotto in modo indipendente.

Le prestazioni variano anche per categoria. Nei risultati dei 14 benchmark, Bonsai 2 ottiene 96,57 nei quattro test di matematica, rispetto a 97,06 a piena precisione.

La sua categoria di coding raggiunge 89,42, leggermente al di sopra del punteggio di riferimento di 89,07. Anche il rispetto delle istruzioni sale da 81,25 a 82,66.

Questi piccoli miglioramenti non dimostrano che la compressione migliori il modello sottostante. Il campionamento dei benchmark, le variazioni di valutazione e il comportamento di decodifica possono produrre modeste inversioni.

Le perdite maggiori emergono in conoscenza, ragionamento e visione. Bonsai 2 registra 79,86 nella categoria combinata di conoscenza e ragionamento, rispetto a 85,55 del riferimento.

La sua media nella visione scende a 66,19 da 71,36. In OCR Bench v2, che testa il riconoscimento di testo nelle immagini, Bonsai 2 ottiene 56,88 contro 60,99.

Queste differenze contano per i flussi di lavoro ricchi di documenti. Un modello può restare forte in matematica e coding, perdendo però precisione nell’interpretazione di screenshot, moduli scansionati, grafici o prove visive dettagliate.

Anche il risultato agentico richiede cautela. Bonsai 2 ottiene 74,92 su BFCL v3, un benchmark di chiamata agli strumenti, rispetto a 76,74 a piena precisione.

Si tratta di un divario aggregato relativamente piccolo. Tuttavia, un singolo test di chiamata agli strumenti non può stabilire l’affidabilità attraverso cicli agentici prolungati.

I sistemi agentici amplificano gli errori. Una selezione leggermente errata di file, comando o conclusione intermedia può modificare ogni passaggio successivo.

La capacità di contesto lungo crea una distinzione simile. Supportare 262.144 token significa che l’architettura e il runtime possono accettare tale quantità. Non garantisce un richiamo o un ragionamento coerenti in ogni posizione.

I test indipendenti saranno particolarmente importanti in questo ambito. I revisori dovrebbero confrontare gli stessi set di prompt, versioni del runtime, dimensioni del contesto e impostazioni di decodifica tra Bonsai 2 e Qwen a piena precisione.

I primi resoconti pratici sono già contrastanti. Un utente ha riferito di eseguire completamente il modello su un Mac mini M2 da 8GB a circa 7,6 token al secondo, a sostegno dell’affermazione di compatibilità di base.

Altri primi utenti hanno messo in dubbio il suo comportamento con prompt complessi e ragionamenti prolungati. Questi resoconti sono aneddotici, specifici dell’hardware e troppo precoci per stabilire un profilo qualitativo stabile.

La copertura di SiliconANGLE inquadra correttamente le cifre su prestazioni ed efficienza come affermazioni dell’azienda. Questa distinzione dovrebbe restare visibile finché le valutazioni indipendenti non matureranno.

PrismML ha chiaramente dimostrato un rilascio insolitamente compatto, con pesi pubblici e file riproducibili. Non ha ancora stabilito che ogni carico di lavoro impegnativo subisca soltanto una perdita di capacità dell’1,8%.

L'AI locale migliora la privacy, ma il deployment ha ancora costi

Bonsai 2 amplia ciò che può restare locale, anche se l’auto-ospitalità trasferisce la responsabilità operativa dal fornitore all’utente.

Il caso d’uso più evidente è l’elaborazione privata dei documenti. Un utente potrebbe riassumere note locali, estrarre informazioni da file interni o cercare in una raccolta di conoscenze sensibili senza caricare il materiale di origine.

Lo sviluppo software è un altro obiettivo logico. Un assistente di coding ospitato localmente può ispezionare un repository, proporre patch, chiamare strumenti di sviluppo e generare test entro il perimetro di accesso già esistente della workstation.

Il supporto multimodale aggiunge attività basate sulle immagini. I team potrebbero analizzare screenshot di interfacce, estrarre testo dai documenti o combinare diagrammi con istruzioni scritte.

Tuttavia, il divario nei benchmark di visione implica che questi scenari richiedono validazione. Il riconoscimento ottico dei caratteri ad alta criticità non dovrebbe basarsi su un punteggio aggregato generale.

L’inferenza locale può ridurre l’esposizione a terze parti, ma non rende automaticamente sicura un’applicazione. Un server del modello può comunque essere configurato in modo errato, esposto a una rete o dotato di permessi eccessivi su file e comandi.

Secondo la documentazione di PrismML, il server demo si collega per impostazione predefinita a un indirizzo locale. Gli utenti che modificano tale indirizzo possono esporre il servizio oltre la macchina.

Gli agenti che utilizzano strumenti introducono rischi aggiuntivi. Un modello in grado di modificare file o eseguire comandi necessita di confini di autorizzazione, registrazione e revisione umana.

I team devono inoltre gestire gli aggiornamenti del modello. Un fornitore cloud può sostituire centralmente l’infrastruttura, mentre le distribuzioni locali possono accumulare binari, versioni dei pesi e impostazioni di configurazione differenti tra i dispositivi.

Il requisito del runtime personalizzato amplifica questo onere. Le correzioni di sicurezza e le modifiche di compatibilità devono raggiungere il fork di PrismML prima che gli utenti le ricevano attraverso il percorso supportato.

La compatibilità hardware dovrebbe essere valutata anche con l’applicazione completa. I pesi del modello sono solo una parte del consumo di memoria.

Il runtime richiede memoria di lavoro, la cache chiave-valore conserva lo stato del contesto e i componenti multimodali consumano risorse aggiuntive. Prompt lunghi possono quindi portare un dispositivo nominalmente compatibile oltre il suo limite confortevole.

Il funzionamento a batteria presenta un altro compromesso. PrismML riporta circa 27,5 watt di potenza GPU e 34,1 watt complessivi tra CPU e GPU durante la decodifica su un M5 Pro.

Queste misurazioni non includono tutti i componenti del sistema e non possono essere confrontate direttamente con le misurazioni delle schede Nvidia. Mostrano comunque che l’inferenza locale non è gratuita.

Il miglior schema di deployment potrebbe essere ibrido. Il lavoro ordinario e sensibile può restare sul dispositivo, mentre i compiti eccezionalmente difficili possono passare a un modello gestito più potente secondo regole esplicite.

Questa configurazione consente a un’organizzazione di controllare quando i dati lasciano la macchina. Evita inoltre di costringere un modello compatto a gestire attività in cui la qualità conta più della privacy o della latenza.

La decisione dovrebbe basarsi sulle prestazioni misurate delle attività, non solo sul numero di parametri. Un team dovrebbe testare il proprio codice, i documenti, le immagini e le sequenze di strumenti prima di sostituire un servizio esistente.

Bonsai 2 rende questi test più accessibili perché i suoi pesi e le risorse di esecuzione sono pubblici. Il lavoro rimanente consiste nel dimostrare che i risparmi operativi superano i costi di integrazione e manutenzione.

Cosa osservare dopo il lancio di Bonsai 2 27B

Tre segnali determineranno se Bonsai 2 diventerà un’opzione di AI locale duratura: valutazioni indipendenti, supporto del runtime upstream e adozione sostenuta in produzione.

Il primo segnale è la riproduzione indipendente dei benchmark. I test più preziosi confronteranno Bonsai 2 con Qwen3.8-27B a piena precisione e quantizzazioni convenzionali in condizioni identiche.

I valutatori dovrebbero riportare più delle medie. Fallimenti per attività, lunghezza delle risposte, cicli di ragionamento, accuratezza visiva e richiamo del contesto lungo riveleranno dove la compressione modifica il comportamento.

Il coding agentico merita particolare attenzione. Un benchmark che richiede molte chiamate agli strumenti, navigazione del repository ed esecuzione dei test offre una prova di stress migliore rispetto al completamento di codice isolato.

Se Bonsai 2 resterà vicino alla piena precisione in queste valutazioni, l’argomento di PrismML sulla densità di intelligenza diventerà molto più forte. Grandi cali qualitativi restringerebbero gli utilizzi migliori del modello a compiti più semplici o più tolleranti.

Il secondo segnale è il supporto nei runtime mainstream. PrismML afferma che Bonsai 2 richiede attualmente il suo fork di llama.cpp perché la trasformazione di attivazione Hadamard non è upstream.

L’accettazione in progetti ampiamente utilizzati ridurrebbe l’attrito nell’installazione e la dipendenza dai binari di un solo fornitore. Esporrebbe inoltre l’implementazione a maggiori revisioni, ottimizzazioni e test hardware.

Un supporto runtime più ampio può contare quanto la qualità dei benchmark. Un formato tecnicamente impressionante farà fatica se gli sviluppatori non potranno distribuirlo tramite strumenti familiari.

Il terzo segnale è l’adozione reale al di fuori delle dimostrazioni. I conteggi dei download offrono un primo indizio, ma applicazioni ripetibili e integrazioni mantenute forniscono prove migliori.

Indicatori utili includono assistenti di coding stabili, sistemi di ricerca privati, ricerca multimodale locale e progetti pilota aziendali che proseguono oltre la valutazione. I resoconti dei fallimenti sono altrettanto preziosi perché identificano i carichi di lavoro per cui un modello compatto non è pronto.

Anche la concorrenza si intensificherà. I modelli convenzionali a quattro bit offrono già una forte qualità quando gli utenti dispongono di più memoria, mentre i modelli nativi più piccoli restano più facili da eseguire su hardware modesto.

Bonsai 2 non elimina queste opzioni. Introduce un nuovo punto sulla curva, abbinando un modello di base più grande a una compressione insolitamente aggressiva.

Per gli sviluppatori, il prossimo passo è il test pratico. Scaricare il pacchetto appropriato, riprodurre un piccolo benchmark sulla macchina di destinazione e valutare prompt reali prima di ampliare i permessi.

Per gli acquirenti aziendali, richiedere accuratezza a livello di attività, impegni di supporto del runtime e un chiaro modello di sicurezza. Non trattare la cifra del 98,2% come una garanzia generale di livello di servizio.

PrismML Bonsai 2 27B ha già stabilito il risultato di base: un modello della classe 27B può occupare meno di 6GB nel suo formato più piccolo, solo linguistico. La domanda aperta è se questa densità resti affidabile quando il lavoro reale diventa lungo, visivo e agentico.

Un modello locale privato migliorerebbe il vostro flusso di lavoro, o i suoi compromessi in termini di manutenzione e qualità supererebbero il controllo che offre? La risposta dipende ora meno dal fatto che un modello capace riesca a entrare e più da ciò che accade dopo.