Bonsai 27B: PrismML porta un modello da 27 miliardi di parametri su un telefono, a un bit per peso

Il 14 luglio PrismML ha annunciato Bonsai 27B, presentato come «il primo modello della sua classe di capacità a girare su un telefono». Non è un modello addestrato da zero: è Qwen3.6-27B di Alibaba, architettura invariata, con i pesi trasformati in una rappresentazione a pochissimi bit. Le varianti sono due. Ternary Bonsai 27B ammette per ogni peso tre valori, −1, 0 e +1, più un fattore di scala per gruppo: 1,71 bit effettivi per peso, circa 5,9 GB. 1-bit Bonsai 27B ne ammette due, −1 e +1: 1,125 bit per peso, circa 3,9 GB. Il modello originale in FP16 ne occupa circa 54. Pesi su Hugging Face, licenza Apache 2.0.

Che cosa dichiara PrismML

Il ragionamento del whitepaper parte da un vincolo concreto: iOS concede a una singola app circa metà della memoria fisica, quindi un iPhone da 12 GB ne lascia al modello circa 6, da dividere con la cache e le attivazioni. La variante ternaria, anche ai suoi 5,9 GB teorici, li esaurirebbe; quella a un bit ci sta con margine. Sull’iPhone 17 Pro Max, dice l’azienda, genera circa 11 token al secondo. Il contesto dichiarato è di 262.000 token, che una cache quantizzata a 4 bit fa stare nella memoria di un portatile; sul telefono, dice lo stesso whitepaper, ci stanno «decine di migliaia» di token.

Sulla qualità, nella media di 15 benchmark valutati in modalità di ragionamento la variante ternaria e quella a un bit tengono il 95 e il 90 per cento della base, arrotondati. La perdita non è uniforme: in matematica le due varianti restano vicine all’originale, nell’uso di strumenti e nella visione scendono di più.

Il confronto che PrismML mette in evidenza è con le quantizzazioni convenzionali: la build IQ2_XXS dello stesso Qwen pesa 9,4 GB e si ferma a 72,7.

Che cosa manca per verificarlo

Tutti i numeri sono di PrismML, misurati da PrismML. Il metodo che porta i pesi sotto i due bit non è descritto: il whitepaper lo dice costruito «su proprietà intellettuale esclusiva del Caltech», non un codice da rifare a casa. Pesi e runtime si possono provare, la ricetta no. E la demo su iPhone, avverte la didascalia, parte con il contesto dell’immagine già in cache.

I due documenti, poi, non coincidono ovunque. L’annuncio scrive che l’uso di strumenti resta «a pochi punti» dalla piena precisione; la sua stessa tabella dà 6 punti in meno alla variante ternaria e 14 a quella a un bit. Per l’M5 Max cita «fino a» 87 token al secondo a un bit e 58 in ternario; la tabella standardizzata del whitepaper, senza decodifica speculativa, dà circa 66 e 44, e lo stesso whitepaper avverte che sui Mac la decodifica speculativa non porta ancora guadagni. Da dove venga la differenza, nessuno dei due lo spiega. Soprattutto, la variante ternaria oggi occupa in pratica circa 7,2 GB, perché ogni valore sta in uno slot da 2 bit: i 5,9 GB sono un obiettivo dei kernel nativi, non ancora raggiunto. Il whitepaper, fra i limiti, ammette anche che la programmazione agentica su lunghi orizzonti è una capacità che questa versione «non punta ancora con decisione».

Perché interessa a chi lavora in Italia

Un modello di questa taglia che sta in 4 GB cambia il conto di chi deve tenere i dati in casa: un portatile al posto di un server (per ora un Mac con Apple Silicon o un PC con GPU NVIDIA, i due backend supportati), e con licenza Apache 2.0. Il prezzo va misurato sul proprio compito. I quattordici punti che il modello a un bit perde nell’uso di strumenti sono tanti per un agente, meno per un riassunto; e nessuno dei 15 benchmark misura l’italiano. Prima di sostituire un modello quantizzato a 4 bit, conviene rifare la prova sui propri dati.