Bonsai 2 è arrivato su Ollama prima che chiunque annunciasse che sarebbe successo

A un certo punto, nelle prime ore del 17 ottobre 2026, Ollama ha iniziato a servire Bonsai 2 — una voce di libreria con nove tag che comprende Ternary Bonsai 2 2B, Ternary Bonsai 2 4B, Ternary Bonsai 2 9B e Bonsai 2 27B, ciascuno in due pacchetti più un alias predefinito. Prism ML non ha detto nulla al riguardo. Non c'è alcun post sulla pagina delle notizie del fornitore, nessuna riga nell'annuncio del 15 ottobre dei modelli piccoli — quel post indica llama.cpp e MLX come runtime e una console ospitata come demo, e non menziona mai Ollama. La voce esiste semplicemente, con tutti e nove i tag che riportano la stessa età di poche ore, che è l'aspetto di un push appena effettuato e non quello di un rilascio graduale.

Quindi la distinzione onesta è questa. Noto già adesso, dal registry e dai file: i tag, i loro nomi, le loro dimensioni esatte in byte, i loro digest dei contenuti e — poiché Ollama distribuisce GGUF — l'architettura e le stringhe di metadati all'interno dei pesi stessi. Non confermato: chi li ha confezionati, perché l'annuncio del fornitore omette la piattaforma, se i kernel ternari siano upstream nel motore di Ollama stesso o integrati da terzi, e se qualcuno dei numeri del fornitore sopravviva al tragitto. Sono domande separate e questo pezzo le tiene separate.

Cosa c'è effettivamente sullo scaffale

Nove tag, quattro dimensioni, tre confezioni degli stessi pesi. La pagina della libreria di Ollama elenca un alias predefinito per dimensione e una -q2_0 variante per dimensione:

• bonsai-2:latest — 3,2 GB, corrisponde al 9B (digest c8b5462f8688)

• bonsai-2:2b e bonsai-2:2b-q2_0 — 911 MB, stesso digest de2ccb4e7328

• bonsai-2:4b e bonsai-2:4b-q2_0 — 1,6 GB, stesso digest 93edd652c932

• bonsai-2:9b e bonsai-2:9b-q2_0 — 3,2 GB, stesso digest c8b5462f8688

• bonsai-2:27b e bonsai-2:27b-q2_0 — 8,3 GB, stesso digest f3c4f4208659

La denominazione fa più lavoro di quanto sembri. Due tag per dimensione che condividono un digest non sono un duplicato — è un'affermazione su quale packing abbia scelto Ollama. Estrai il manifest per bonsai-2:9b e il layer del modello è di 2,557 GB. Quello è il file Q2_0 di Ternary Bonsai 2 9B, misurato su Hugging Face a 2,557 GB al byte. Il PQ2_0 pacchetto è di 2,417 GB e il PTQ1_0 pacchetto — il più piccolo, a 1,997 GB — non è affatto qui.

Questa scelta ha una conseguenza che vale la pena dichiarare apertamente, perché è il tipo di cosa che finisce in un thread di supporto. Sulla model card del fornitore, llama.cpp upstream esegue esattamente uno dei tre packing: Q2_0, "master recente, che include il runtime di attivazione Hadamard". Rifiuta PQ2_0 e PTQ1_0 come tipi sconosciuti, perché richiedono il fork Prism ML di llama.cpp. Ollama serve il proprio motore. Q2_0 è il pack che un consumer GGUF standard può plausibilmente caricare — e Q2_0 è esattamente il pack che Ollama ha distribuito. Se Ollama abbia sviluppato kernel ternari propri o si affidi a una build vendored non è qualcosa che il registry ti dica. Quello che ti dice è che non hanno distribuito il file che non può essere caricato.

I metadati GGUF ti dicono più di quanto faccia la pagina.

La pagina di Ollama riporta quattro fatti per ogni tag: una dimensione in byte, un badge di contesto "256K", un tipo di input testo e immagine, e un timestamp relativo. Tutto il resto è dentro il file. La lettura dell'intestazione GGUF di ogni livello del modello fornisce quanto segue, e vale la pena leggerla per un motivo specifico: è l'unica parte di questa storia che non è un'affermazione di marketing di qualcuno.

• general.architecture — qwen35 su tutte e quattro le dimensioni

• general.name — Ternary-Bonsai-2-2B, -4B, -9B sui tre piccoli; il layer 27B riporta la stringa generica Hf con general.basename = folded

• general.file_type — 41 su tutti e quattro, con general.quantization_version = 2

• general.size_label — 2B, 4B, 9B, 27B, corrispondenti ai nomi dei tag

• Numero di tensori — 320 per il 2B, 426 per il 4B, 427 per il 9B, 851 per il 27B

La stringa dell'architettura è quella interessante. qwen35 è il backbone ad attenzione ibrida di Qwen3.5, e conferma dall'artefatto stesso ciò che le model card dicono in prosa: i tre piccoli sono Qwen3.5-2B, -4B e -9B con l'architettura invariata e i pesi sostituiti. Espone anche una cucitura di denominazione che le note di rilascio del fornitore stesso maschera. Il post del 15 ottobre dice che i nuovi modelli sono «basati su Qwen3.5». Il 27B è una base completamente diversa — Qwen3.8-27B, annunciato il 17 settembre. Quattro dimensioni, un nome di famiglia, due modelli di base. Qualsiasi cosa leggiate sul comportamento di «Bonsai 2» che sia stata misurata sul 27B non si trasferisce automaticamente al 9B, e l'header GGUF è il punto in cui potete vedere perché.

Anche i metadati del 27B sono visibilmente meno ordinati rispetto al resto: general.name = Hf, un general.basename = folded, un general.version = v5, e una chiave di campionamento extra che i tre piccoli non hanno. È questo l'aspetto dell'output intermedio di una pipeline di conversione quando viene pubblicato senza un passaggio finale di rinomina. Non è un difetto — i tensori sono i tensori — ma è un'impronta digitale, e suggerisce che il tag 27B sia arrivato da un percorso diverso rispetto ai tre piccoli.

Cosa non significano i numeri di Ollama

Ecco dove la maggior parte delle trattazioni dell'elenco della libreria sbaglia, quindi vale la pena soffermarsi. Le dimensioni in byte sulla pagina di Ollama sono dimensioni dei container, e per ogni dimensione sono più grandi del file del modello al suo interno. Il tag 2B indica 911 MB contro uno strato del modello da 0,547 GB e un proiettore di visione da 0,365 GB. Il tag 27B indica 8,3 GB contro uno strato del modello da 7,626 GB e un proiettore da 0,629 GB. Aggiungendo i blob della licenza e dei parametri, l'aritmetica quadra: Ollama riporta l'intero artefatto scaricato, torre di visione inclusa.

Ciò significa che i 3,2 GB della pagina Ollama per il 9B non sono confrontabili con il valore "2GB" del fornitore per lo stesso modello, e il divario non è una discrepanza da segnalare — sono due misurazioni diverse di due cose diverse. I 0,43 GB / 0,95 GB / 2 GB di Prism ML sono solo i modelli linguistici. La torre di visione viene offloadata e caricata solo quando arriva effettivamente un'immagine, quindi un deployment solo testo non ne paga mai il costo, ma un ollama pull sì. Se stai dimensionando un dispositivo in base ai numeri del fornitore e poi esegui il pull da Ollama, sarai fuori budget di 0,5-1 GB prima ancora di eseguire qualcosa.

La stessa cautela vale per il badge "256K". Il contesto sottostante è di 262.144 token, ereditato dal backbone Qwen3.5 — 24 layer di attenzione lineare e 8 di attenzione completa sul 9B — e il badge di Ollama lo arrotonda per difetto per la visualizzazione. Il contesto è reale ed è ereditato, non qualcosa che Ollama ha aggiunto. Ciò che non è indicato da nessuna parte nella pagina è quanta memoria costa un contesto lungo, e su un modello ad attenzione ibrida con una cache di attenzione completa su un sottoinsieme di layer non è un numero piccolo. Nulla nella pagina di Ollama ti dice se 262K entri effettivamente ovunque tu intenda eseguirlo.

Chi ha pacchettizzato questo, e conta?

Senza risposta, e andrebbe contrassegnato come senza risposta invece che indovinato. Tre possibilità: Prism ML l'ha caricato, Ollama l'ha prelevato dai repository GGUF pubblici del fornitore nell'ambito del proprio lavoro di catalogazione, oppure l'ha fatto una terza parte. Il registro non può dirti quale.

Ciò che si può verificare è la provenienza dell'artefatto, e coincide. La descrizione del modello di Ollama stessa dice "Bonsai 2 di Prism ML è una famiglia di modelli di visione progettati per pesi ternari (−1, 0 o +1): circa la metà delle dimensioni dei modelli standard a 4 bit, con una qualità vicina a quella a piena precisione" e rimanda all'organizzazione Hugging Face del fornitore, al whitepaper di Bonsai 2 27B e ad Apache 2.0. Il blob di licenza incorporato in ognuno dei quattro manifest di dimensione è il testo Apache 2.0 letterale. Il blob dei parametri per il 2B, il 4B e il 9B riporta {"presence_penalty":1,"temperature":1,"top_k":20,"top_p":0.95} — che è quella consigliata dal fornitore, in modalità di pensiero: la ricetta di campionamento dalle model card, con min_p omesso esattamente come la card del 27B dice che i file GGUF lo omettono. Non è un'ipotesi fatta da qualcuno; è una conversione che ha letto la card.

Che è rassicurante e comunque non ti dice nulla sulla cosa che decide davvero la tua esperienza: se i kernel ternari sono presenti nel motore che stai eseguendo. La posizione onesta è che un pull riuscito dimostra che il file è un GGUF ben formato, e nulla più. Verifica sul tuo hardware prima di costruirci sopra.

Le affermazioni del fornitore e ciò che è stato verificato

Ogni numero di qualità associato a questa famiglia proviene da Prism ML, sull'harness di Prism ML, e nessuno di essi è riprodotto in modo indipendente. È normale a questo stadio, e dovrebbe essere detto apertamente anziché lasciato intendere. Il post del 15 ottobre riporta 19 benchmark in sei aree di competenza per i modelli piccoli, con la ritenzione rispetto ai baseline Qwen3.5 a piena precisione:

• 2B — agentico 95,5%, matematica 107,8%, seguire le istruzioni 121,5%, programmazione 115,0%, conoscenza 82,9%, visione 89,0%

• 4B — 90,0% / 99,3% / 106,0% / 100,7% / 90,9% / 91,3%

• 9B — 92,4% / 98,2% / 100,0% / 100,1% / 93,0% / 92,5%

Diversi di questi superano il 100%, il che non è un refuso né un artefatto di arrotondamento: significa che il modello ternario ha ottenuto un punteggio più alto del modello a piena precisione da cui è stato derivato in quella categoria. L'instruction following al 121,5% per il 2B è l'esempio più eclatante. Trattalo con il sospetto che merita: un modello compresso che batte il proprio baseline su un benchmark scelto dal fornitore dice qualcosa sull'addestramento e sull'harness almeno quanto sulla rappresentazione, e i punteggi delle categorie dei modelli piccoli sono molto più rumorosi di quelli del 27B. I numeri del 27B sono più conservativi e più credibili nella forma — 84,78 contro 86,32 per FP16, una retention del 98,2% su 14 benchmark in modalità thinking, con la matematica a 96,57 contro 97,06 e il livello di coding a 89,42 contro 89,07, e la perdita concentrata in knowledge/reasoning e vision. Quando una famiglia rinuncia a capacità sotto una rappresentazione a 1,7 bit, è proprio il profilo che ci si aspetterebbe.

L'unica affermazione nel post sul modello piccolo che non è un benchmark è quella da prendere più sul serio: il modello 9B «usa circa il 40% di token in meno nelle attività standard di instruction-following e di matematica quotidiana». Si tratta di un'affermazione sulla verbosità, non sulle capacità, ed è il tipo di cosa che puoi verificare in un pomeriggio sui tuoi stessi prompt. Si intreccia inoltre con un avviso presente nelle model card dello stesso fornitore: la modalità thinking può consumare oltre 3.000 token per una domanda banale, quindi imposta almeno 8.192 token di output e non usare la decodifica greedy con il thinking attivo, perché può bloccarsi a ragionare. Un modello che è il 40% meno verboso e ha comunque bisogno di un budget di 8.192 token ti sta dicendo che è verboso in un punto specifico.

Dove questo ti lascia

Se usi già Ollama e volevi provare un modello di classe 27B su un laptop senza una GPU da datacenter, i quattro tag sono il percorso più breve che esista al momento: un solo pull, nessun fork, nessuna compilazione del kernel. Se ti serve il packing che è effettivamente il più piccolo, oppure i drafter per speculative decoding che il fornitore distribuisce per i 4B e i 9B, la scheda di Ollama non li include — si tratta di un download da Hugging Face e della build Prism ML di llama.cpp, e lo è dal 15 ottobre.

L'altra cosa che vale la pena sapere è che l'esecuzione in locale non è l'unico modo per usare un modello low-bit, e non è sempre quello giusto. OrcaRouter mette un'unica API davanti a oltre 200 modelli ospitati con markup dello 0% — prezzo di listino del provider passato così com'è — più failover automatico tra provider, così puoi valutare un modello su un carico di lavoro reale prima di decidere se si merita un posto sul tuo laptop. Nessuna delle dimensioni di Bonsai 2 è servita tramite OrcaRouter oggi, e questo articolo non sostiene il contrario: la famiglia è un download che esegui tu stesso, e resta così finché il fornitore non pubblica un endpoint. Quello che il livello di routing ti offre è l'altra metà della decisione — i modelli ospitati con cui lo confronterai, dietro un'unica chiave, con la fusione di modelli e il DSL di routing disponibili quando un singolo modello non basta.

Cosa tenere d'occhio, in ordine di quanto cambierebbe il quadro: un tag Ollama che guadagna un ptq1_0 gemello, il che significherebbe che i kernel dense-trit sono arrivati upstream; un post del fornitore che riconosce la piattaforma, il che risponderebbe alla domanda sulla provenienza; e qualsiasi benchmark indipendente del 9B o del 27B, che è l'unica cosa che sposterebbe le cifre di retention fuori dalla colonna dei dati riportati dal fornitore. Finché uno di questi non arriva, l'inserzione è un meccanismo di distribuzione, non un nuovo modello — e il modello che distribuisce è pubblico dal 15 ottobre.

Niente di tutto ciò è ipotetico: i fallimenti documentati dell'IA e gli incidenti degli agenti alla base di rilasci come questo sono raccolti in l'OrcaRouter AI Incident Archive, dove ogni voce riporta le proprie fonti, la gravità, il grado di confidenza e il flag di contestazione.