Bonsai su occhiali intelligenti: un VLM da 2B a 1 bit in esecuzione su Snapdragon AR1 Gen 1

Il numero che decide a cosa serve davvero questo annuncio non è 4x e non è 2x. È 1.024 — la lunghezza del contesto del modello che PrismML ha messo su un paio di occhiali intelligenti allo Snapdragon Summit del 23 settembre 2026. Il modello visione-linguaggio Bonsai 2B a 1 bit, un sistema da 2 miliardi di parametri costruito su Bonsai 1.7B, funziona localmente su occhiali intelligenti AI alimentati dalla Snapdragon AR1 Gen 1 Platform, e le cifre che PrismML mette in evidenza riguardano memoria e velocità: 0,43 GB di pesi LLM contro 1,66 GB per il corrispondente modello 1.7B a 4 bit, una riduzione di 3,83x, e 15,36 token al secondo contro 7,44, un miglioramento di 2,06x. Entrambe le cifre sono del fornitore stesso, entrambe sono state misurate su una piattaforma di test da 4 GB, ed entrambe sono misurate rispetto a un modello Qwen 3 1.7B a 4 bit. Non sono misurate rispetto ad alcun Bonsai 27B, e non sono misurate rispetto a nulla di ospitato. Leggerle come un'affermazione sulla qualità di Bonsai sarebbe un errore; leggerle come un'affermazione su ciò che entra in un budget di memoria di classe occhiali è quella giusta.

Cosa è stato annunciato, in un unico posto

L'annuncio di PrismML — datato Pasadena, legato allo Snapdragon Summit di Qualcomm — colloca un modello visione-linguaggio da 2 miliardi di parametri sulla piattaforma per occhiali AR1 Gen 1. La suddivisione è un modello linguistico da 1,7B a 1 bit più un encoder visivo da 0,3B a 4 bit, con una lunghezza di contesto di 1.024 token. È basato su Bonsai 1.7B di PrismML, quindi rappresenta l'estremità piccola della famiglia Bonsai anziché una nuova architettura, ed è stato compilato per la NPU Qualcomm Hexagon utilizzando un SDK QNN interno con supporto ai kernel a 1 bit.

Il titolo sostiene, come dichiarato dal fornitore:

• Permette di ospitare un modello con 4 volte il numero di parametri entro gli stessi vincoli di memoria su alcuni fattori di forma di occhiali.

• Fornisce all'incirca l'intelligenza equivalente dello stesso modello a precisione a 4 bit, usando circa 4 volte meno memoria.

• Genera token a una velocità più che doppia.

Quelle tre frasi sono il comunicato. Le misurazioni specifiche dietro le affermazioni su memoria e velocità sono 0,43 GB contro 1,66 GB e 15,36 contro 7,44 token al secondo, entrambe su una piattaforma configurata con 4 GB di memoria. L'AR1 Gen 1 stesso è indicato con un picco di 6 TOPS e 2.304 MAC per ciclo — un dato per la piattaforma, non per l'inferenza del modello linguistico, una distinzione che gli stessi numeri dell'annuncio rendono chiara citando i token al secondo separatamente.

Il 4x è un'affermazione sulla memoria, e la baseline è un modello diverso

Questa è la parte su cui vale la pena soffermarsi, perché «4x» è il tipo di cifra che viaggia più lontano della frase da cui proviene. Ogni confronto pubblicato da PrismML per il modello per occhiali è con una quantizzazione a 4 bit di Qwen 3 1.7B — la stessa classe di parametri, lo stesso compito, una quantizzazione diversa. Si tratta di un confronto legittimo e utile: è il confronto che un OEM di occhiali deve effettivamente affrontare, in cui la domanda è se un percorso a 1 bit recuperi abbastanza memoria da valere il lavoro sui kernel. Non è un confronto con una versione a 4 bit di Bonsai, né un confronto con un Bonsai più grande in esecuzione altrove.

La nota a piè di pagina sui benchmark allegata all'annuncio è cauta allo stesso modo. PrismML ha valutato il LLM a 1 bit Bonsai 1.7B rispetto al modello a 4 bit Qwen 3 1.7B a settembre 2026 su BFCL v3, HumanEval+, MMLU Redux, IFEval, IFBench, MuSR, GSM8K e GPQA Diamond, e il risultato riportato è che le due configurazioni "hanno ottenuto risultati comparabili nei benchmark". Comparabili, non superiori. Non ci sono punteggi per singolo benchmark nell'annuncio né alcuna riproduzione indipendente di nulla di tutto ciò, il che è normale per un rilascio edge della settimana di lancio ed è esattamente il motivo per cui i numeri dovrebbero essere considerati come riportati dal fornitore finché qualcuno al di fuori di PrismML non li esegue.

1.024 token è la specifica che dà forma al prodotto

Un modello visione-linguaggio su occhiali è un carico di lavoro diverso da un modello visione-linguaggio in una finestra di chat, e la lunghezza del contesto è il punto in cui questo si manifesta. A 1.024 token, il modello può contenere una breve istruzione più ciò che una telecamera sta attualmente inquadrando. Non può contenere una cronologia di conversazione, un documento o una lunga catena di turni precedenti. Non è un difetto della release — è il vincolo che ha reso possibile la release, perché la KV cache e le attivazioni devono risiedere negli stessi 4 GB dei pesi, e un modello di classe 27B con un contesto di 262K token necessita di ordini di grandezza in più di spazio per quello stato.

Quindi la descrizione onesta di ciò che è stato rilasciato è quella di un assistente capace con contesto breve che funziona interamente sul dispositivo. Compiti a forma di occhiali — riconosci questo, leggi quello, traduci il cartello davanti a me, rispondi a una domanda su ciò che sto guardando — rientrano in 1.024 token. Qualsiasi cosa che debba ricordare gli ultimi dieci minuti non ci rientra, e nessuna quantità di compressione a 1 bit lo cambia, perché il limite è lo stato, non i pesi.

Cosa dovrebbe trarre l'ecosistema edge da tutto questo

La vera novità ingegneristica in questo annuncio non è il modello. È il percorso del kernel: un LLM a 1 bit compilato per l'NPU Hexagon tramite un QNN SDK con supporto ai kernel a 1 bit. I pesi a basso numero di bit sono eseguibili su CPU e GPU già da un po', e le stesse release di Bonsai 27B di PrismML lo hanno dimostrato su silicio Apple e hardware NVIDIA. Portare kernel a pesi binari su un'NPU mobile è un problema diverso, perché il data path dell'acceleratore, il suo formato di packing e la sua schedulazione devono tutti adattarsi a una rappresentazione che non è affatto un tipo float.

Se quel percorso si generalizza oltre questo singolo modello — e il linguaggio dell'SDK suggerisce che PrismML intenda farlo — allora la conseguenza interessante è che la famiglia a 1 bit smette di essere una storia da laptop e telefono e diventa una storia da dispositivi sempre attivi. La piattaforma da 4 GB nell'annuncio è il limite attuale. Qualunque cosa riduca l'impronta dei pesi a qualità fissa aumenta la dimensione del modello che rientra sotto quel limite.

L'affermazione sull'elaborazione sul dispositivo merita un'avvertenza

L'inferenza multimodale completamente locale su un paio di occhiali è un'affermazione forte, e vale la pena distinguere ciò che è dimostrato da ciò che è implicito. L'AR1 Gen 1 è una piattaforma per occhiali progettata per il rilevamento e l'audio sempre attivi; l'impostazione di Qualcomm stessa per i modelli linguistici on-device è stata generalmente ibrida, con il dispositivo che gestisce ciò che può e affida il resto a un telefono abbinato o al cloud. La prima dimostrazione pubblica di Qualcomm di un piccolo modello linguistico on-device era legata alla piattaforma AR1+ Gen 1 anziché all'AR1 Gen 1. Nessuno dei due punti contraddice l'annuncio di PrismML — l'annuncio afferma che il modello viene eseguito localmente sull'AR1 Gen 1, e i dati di throughput e memoria forniti dal venditore sono coerenti con un modello piccolo che fa esattamente questo — ma significano che il prodotto pratico costruito su questo sarà quasi certamente un livello locale con un percorso di escalation, non un dispositivo che non comunica mai con nient'altro.

Comunque, questa è l'architettura giusta. Un modello locale da 1,024 token è molto bravo con le richieste che rientrano in 1,024 token e non può rispondere a quelle che non ci rientrano.

Dove va il percorso di escalation

Per chiunque sviluppi su una release come questa, la domanda di progettazione non è se il modello degli occhiali sia valido — è cosa succede alla richiesta che non può servire. Se risolta nel codice applicativo, diventa un mucchio di casi speciali che devono essere riscritti ogni volta che il modello on-device cambia dimensione o contesto. Se risolta come politica di routing, diventa una sola regola: le richieste oltre il budget di contesto del livello locale, o che richiedono strumenti o ragionamento che il livello locale non possiede, passano a un modello ospitato. Quella politica è il tipo di cosa per cui esiste OrcaRouter — un endpoint davanti a oltre 200 modelli ospitati, con failover e la politica espressa nella configurazione anziché nel client. Bonsai stesso non viene instradato qui; è un download che esegui sul tuo hardware. Ciò che il livello di routing copre è il confine al di sopra di esso, e quel confine è dove un deployment di occhiali spenderà la maggior parte del suo tempo di ingegneria.

Cosa guardare dopo

Tre cose farebbero passare questo da un annuncio a una piattaforma. Una ripartizione per benchmark dietro la riga {{1}}risultati comparativi{{/1}}, così che il compromesso rispetto ai 4-bit sia visibile anziché riassunto. Una finestra di contesto più ampia sullo stesso percorso NPU, che è un problema di memoria di stato più che di pesi e quindi il {{2}}più difficile{{/2}} dei due. E una valutazione indipendente del {{3}}1-bit 1.7B LLM{{/3}} rispetto alla sua controparte {{4}}4-bit{{/4}}, perché ogni cifra in questa versione proviene attualmente dalla parte che l'ha costruita.

Fino ad allora il riassunto accurato è ristretto e utile: un modello multimodale da 2 miliardi di parametri ora gira su un dispositivo di classe occhiali con 0,43 GB di pesi linguistici, a circa il doppio della velocità e circa un quarto della memoria dell'equivalente a 4 bit, su un budget di contesto di 1.024 token. Questo è un vero passo per l'inferenza on-device e un piccolo passo per la capacità del modello, e le due cose non sono la stessa affermazione.