Ternary Bonsai 2 riduce Qwen3.8-27B da circa 54 GB a 5,95 GB — mantenendo il 98,2% del punteggio benchmark del modello FP16. Per la prima volta un modello di reasoning da 27B completo entra nella RAM che resta su una macchina comune da 16 GB e, secondo la demo di Prism ML, gira persino nel browser via WebGPU. Abbiamo confrontato i numeri di footprint con la nostra misura sul cluster e con lo stack da 16 GB.
TL;DR: i pesi ternari ({−1, 0, +1} più una scala FP16) comprimono Qwen3.8-27B a 5,95 GB anziché 53,8 GB — 9,2 volte più piccolo con 84,78 punti su 86,32. Su Mac Studio M4 Max il modello decodifica a 10,6 tok/s nell'uso quotidiano (34,5 tok/s di picco, limitato dalla banda memoria); su RTX 3090 Qwen3.8-27B in Q4 resta a 39,7 tok/s. L'inciampo: serve il fork Prism ML di llama.cpp, il percorso WebGPU è una demo e non un prodotto — e il vantaggio di velocità dei pesi più piccoli viene in parte risucchiato dall'unpacking ternario lento in prefill.
Cosa sono davvero i pesi ternari
Invece di memorizzare ogni peso come float a 16 bit, il formato ternario g128 ammette solo tre valori: −1, 0 e +1. Per ogni gruppo di 128 pesi c'è esattamente un fattore di scala FP16 condiviso. Un valore ternario trasporta log₂3 ≈ 1,585 bit di informazione; con il fattore di scala ammortizzato il formato arriva nella pratica a 1,72 bit per peso — una riduzione idealizzata di 9,3 volte rispetto ai 16 bit di FP16.
Tre dettagli separano il marketing dalla pratica:
- Ternario end-to-end: embedding, proiezioni di attenzione, proiezioni MLP e LM head sono tutti nello stesso formato. Non ci sono via di fuga FP16 nascoste — i 26,2 milioni di parametri sopra la rappresentazione ternaria (il percorso di stato ricorrente dell'attention lineare più le normalizzazioni) sono dichiarati e inclusi nel conteggio a 1,72 bit.
- Rotazione di Hadamard incorporata: prima dell'assegnazione ternaria ogni matrice viene ruotata a blocchi con una trasformazione ortogonale; la rotazione è ripiegata nei pesi offline e non costa né bit né banda di lettura aggiuntiva.
- Packed, non espansi: le varianti GGUF PTQ1_0 (1,75 bit/peso, 5,95 GB) e PQ2_0 (2,13 bit/peso, 7,21 GB) vengono consumate direttamente — i pesi non vengono mai riportati a FP16 a runtime.
Il confronto sul footprint
| Variante | Dimensione | Media benchmark (14 test) | Densità d'intelligenza |
|---|---|---|---|
| Qwen3.8-27B FP16 | 54,66 GB | 86,32 | 0,053 |
| Qwen3.8-27B UD-Q4_K_XL | 17,56 GB | 85,18 | 0,157 |
| Qwen3.8-27B IQ2_XXS | 7,27 GB | 72,59 | 0,257 |
| Bonsai 2 27B (PTQ1_0) | 5,95 GB | 84,78 | 0,457 |
| Ternary Bonsai 27B (precedente) | 5,75 GB | 80,98 | 0,416 |
La tabella è quella della model card ufficiale 1. La colonna interessante è quella destra: Prism ML divide la capacità per la dimensione deployments. Bonsai 2 arriva a 0,457 — quasi il doppio della densità di IQ2_XXS (0,257) a dimensione simile e molto più di Q4 (0,157). Il confronto con IQ2_XXS è la storia vera: la quantizzazione convenzionale a 2 bit crolla a 72,59 punti, la rappresentazione ternaria tiene 84,78 — con l'82% del footprint della build IQ2.
La nostra misura: 37,6 tok/s sul cluster DGX Spark
Per ancorare i numeri di Bonsai, il nostro punto di riferimento dalla produzione — lo stesso backbone Qwen3.8-27B in NVFP4 su vLLM:
| Metrica | Valore |
|---|---|
| Modello | qwen3.8-flash-next-nvfp4 (vLLM) |
| Decode, 1 stream (mediana) | 37,6 tok/s |
| Time to first token (mediana) | 0,495 s |
| Aggregato su 8 stream paralleli | 64,3 tok/s |
| Token output massimi per richiesta | 256 |
Fonte: nostra misurazione contro http://127.0.0.1:8212 (vLLM compatibile OpenAI), 20.10.2026, 16:04 CEST. L'endpoint serve anche le cronicazioni di produzione; sono valori operativi, non di laboratorio.
Cosa rende Bonsai 2 sull'hardware consumer — e cosa lo rallenta
Tre domande pratiche: ci sta? A che velocità? Con quali condizioni?
Ci sta. 5,95 GB di modello linguistico più KV cache: a 32K di contesto con KV q4_0 un run PTQ1_0 arriva a 7,1 GiB secondo i contatori della community — territorio da scheda 8 GB e comoda realtà da 16 GB. Su una RTX 2060 Super 8 GB sono stati riportati 16,8 tok/s a 32K. Per la classe 16 GB (RTX 4060 Ti 16G, SoC laptop) resta margine per contesti più lunghi o per la vision mmproj (0,63 GB, Q8_0, caricata solo per input immagine).
Velocità — due facce. Il decode è puro calcolo di banda: meno bit per peso significa meno byte spostati per token. Prism ML riporta 47 tok/s su un M5 Max (Metal); su Mac Studio M4 Max (ricetta della community, PQ2_0) rileviamo 10,6 tok/s nell'uso quotidiano e 34,5 tok/s di picco — il picco nelle stesse condizioni del nostro (thinking off, temp 0). Il fatto che il picco sia limitato dalla banda su Apple Silicon è un test diretto della tesi "meno bit = più token per GB/s". Il rovescio è nella ricetta: l'unpacking ternario rende il prefill più lento dei checkpoint 4-bit-affine (242 contro 274 tok/s sulla stessa GPU) — parte del risparmio in lettura si paga in decompressione.
Condizioni. Tre, e contano:
- Niente llama.cpp stock. I tensor type 142/143 (PTQ1_0/PQ2_0) non sono nel mainline — Ollama e LM Studio oggi non caricano i file. Serve il fork Prism ML con i kernel ternari dedicati all'attention ibrida.
- CUDA, Metal, CPU — nessun percorso ROCm. Chi ha setup AMD: aspettare o compilarsi il fork.
- Default di reasoning: xhigh attivo; medium accorcia le risposte. low non è supportato.
La domanda da 16 GB: browser, WebGPU e il reality check
Il percorso demo WebGPU (Xenova, 15.10.2026) carica le varianti piccole di Bonsai 2 interamente nel browser — 2B fino a 500 tok/s su M4 Max, senza server. Per la 27B significa: download come un film, esecuzione in una scheda. Questo è l'aspetto europeo della storia: 16 GB di RAM sono lo standard di fatto dei setup singoli, e un reasoner 27B che gira nella scheda senza GPU dedicata e senza installazione cambia la risposta d'archivio alla domanda "mi serve una GPU?".
Il reality check va detto nella stessa frase: la demo WebGPU è un dimostratore, non un prodotto. I backend testati sono llama.cpp (CUDA/Metal/CPU) e MLX. Per la produzione: bloccare il fork su una versione, budget per la KV cache, caricare la mmproj solo all'arrivo delle immagini. La coda 2B/4B/9B della famiglia è browser-ready; la 27B è la frontiera.
Verdetto: quando Bonsai 2 e quando Q4?
| Situazione | Scelta |
|---|---|
| 8 GB di VRAM, la 27B deve entrare | Bonsai 2 PTQ1_0 — l'unica classe 27B che entra con la KV in 8 GiB |
| 16 GB, uso quotidiano + vision | Bonsai 2 + mmproj Q8_0; anche la classe Q4 entra, con meno margine di contesto |
| Massimi tok/s su 3090, qualità | Qwen3.8-27B Q4_K_M/EXL3 — 39,7–42,8 tok/s, percorsi llama.cpp/vLLM consolidati, AA intelligence 33,7 |
| Apple Silicon senza fork da mantenere | Qwen3.8-27B oQ4e/MLX — 53,3 tok/s (M4 Max, con MTP), nessun kernel custom |
| Prodotto browser | Bonsai 2 2B/4B/9B oggi; 27B come demo |
La AA intelligence 33,7 si riferisce a Qwen3.8-27B (Artificial Analysis Index v4.3.2, al 26.09.2026); come modello derivato Bonsai 2 non ha un valore AA proprio — la media benchmark 84,78/86,32 della model card è il miglior proxy.
Conclusione
Ternary Bonsai 2 è la prova più convincente finora che il sub-4-bit non significa perdita di qualità se la rappresentazione è applicata in modo coerente. 84,78 punti su 86,32 a un nono del footprint è una classe a parte. Il prezzo è attrito nell'ecosistema: fork dedicato di llama.cpp, nessuna integrazione Ollama/LM Studio, ROCm aperto. Per le classi 16 GB e 8 GB non è uno svantaggio ma il biglietto d'ingresso — finora l'alternativa era "la 27B non ci sta".
Fonti
- Prism ML: Introducing Bonsai 2 27B — annuncio ufficiale con footprint e retention
- Model card prism-ml/Ternary-Bonsai-2-27B-gguf — rappresentazione dei pesi, tabelle dimensioni/benchmark, formati di packing
- Documentazione Bonsai: introduzione — lineup modelli, dimensioni 1-bit/ternarie
- Fork PrismML-Eng/llama.cpp — kernel custom necessari (CUDA/Metal)
- PrismML-Eng/Bonsai-demo — setup testati per backend, link al whitepaper
- Discussione ggml-org/llama.cpp #29263 — contatori VRAM della community (run 8 GB, numeri KV 32K)
- Weschera: Bonsai-2-27B-Mac — misure Mac Studio M4 Max (base della ricetta dell'hub)
- Xenova su X, 15.10.2026 — demo WebGPU, tok/s nel browser delle varianti piccole
- Artificial Analysis Intelligence Index v4.3.2 (26.09.2026) — AA intelligence 33,7 per Qwen3.8-27B
- 16 GB bastano: la tabella di misura GGUF di Qwen3.8-27B — la nostra base da 16 GB
- RTX 3090 usate per LLM locali — riferimento 3090 Q4
- Hub Local AI: Bonsai-2-27B su Mac e Qwen3.8-27B Mirai-S 16 GB su 3090 — le nostre righe con fonti
FAQ
Ternary Bonsai 2 27B funziona con Ollama o LM Studio?
Non con le versioni stock. I file GGUF usano i tensor type 142 e 143 (PTQ1_0/PQ2_0) non ancora integrati nel mainline di llama.cpp, quindi Ollama e LM Studio li rifiutano. Serve il fork Prism ML di llama.cpp con i kernel ternari dedicati. La model card e la repo demo restano le fonti autorevoli per il setup.
Quanta RAM/VRAM serve davvero a Bonsai 2 27B?
Il modello linguistico occupa 5,95 GB (PTQ1_0) o 7,21 GB (PQ2_0). A questo si aggiunge la KV cache: a 32K di contesto con KV q4_0 un run completo arriva a circa 7,1 GiB secondo i conti della community, 7,6 GiB con KV q8_0. Una scheda da 8 GB basta quindi per 32K di contesto; sui 16 GB resta margine per contesti più lunghi o per la vision mmproj da 0,63 GB.
Quanto è veloce nel quotidiano?
Dipende molto da hardware e packing. Su Mac Studio M4 Max (PQ2_0) misuriamo 10,6 tok/s nell'uso quotidiano e 34,5 di picco con thinking disattivato; Prism ML riporta 47 tok/s su M5 Max. Sulle NVIDIA PQ2_0 vince su H100/A100/Blackwell, PTQ1_0 sulle schede Ada — la scelta del packing è essa stessa una decisione di prestazioni. Il prefill è più lento dei checkpoint 4-bit perché l'unpacking ternario costa tempo.
Mantiene davvero il 98% della qualità?
Secondo la model card Bonsai 2 27B tiene 84,78 punti su 86,32 nella media a 14 benchmark — il 98,2%. Il divario di 1,54 punti è distribuito in modo disomogeneo: la matematica resta entro mezzo punto, il coding è pari, l'agentic tool calling si ferma a 74,92. Per confronto, il convenzionale IQ2_XXS arriva solo a 72,59 punti. Il 98% vale per la media, non per ogni singolo task.
Posso farlo girare nel browser?
Le varianti piccole (2B/4B/9B) girano oggi nel browser via WebGPU — la 2B arriva a 500 tok/s su M4 Max secondo la demo di Xenova. La 27B esiste come demo WebGPU, ma i percorsi di produzione testati sono llama.cpp (CUDA/Metal/CPU) e MLX. Per un uso browser della 27B considerate i ~6 GB di download, i limiti di memoria della scheda e il supporto WebGPU delle GPU di destinazione.
Convien rispetto alla quantizzazione Q4?
A 16 GB e oltre: sì, se serve capacità 27B su hardware piccolo o conta il margine di contesto — la qualità supera misurabilmente le build IQ2 e sta vicina alla Q4. Su una scheda da 24 GB piena con stack llama.cpp/vLLM consolidato la classe Q4 resta la scelta comoda: stessa lega AA (33,7), 39,7–42,8 tok/s, nessuna manutenzione di fork. La decisione è budget hardware contro semplicità operativa.
Footnotes
-
prism-ml/Ternary-Bonsai-2-27B-gguf, model card Hugging Face, consultata il 20.10.2026. ↩