La promessa è forte: un LLM ternario da 27B capace di conservare il 98,2% dell'intelligenza del modello originale. Poi apri il whitepaper e trovi un'altra storia. Ternary Bonsai 2 27B ottiene 52,8 su Terminal-Bench 2.1 e 60,8 su SWE-bench Verified. Il documento li confronta con 69,7 e 80,6 attribuiti a Qwen3.5-27B, concludendo che il modello mantiene circa tre quarti della prestazione a piena precisione. Ma c'è un dettaglio: quel nome sarebbe un refuso, perché i valori sarebbero di Qwen3.8. Prendendo i numeri corretti di Qwen3.5, il framework cambia: 52,8 contro 41,6 (126,9%) su Terminal-Bench e 60,8 contro 72,4 (84,0%) su SWE-bench.

Non è solo una questione nominale. Per chi guarda alla Quantization come leva per ridurre la VRAM e portare modelli self-hosted, la distanza tra "98,2% di intelligenza mantenuta" e "tre quarti su coding agentico" è il cuore della decisione. Terminal-Bench e SWE-bench misurano capacità di agire su codice e tool a orizzonte lungo, non semplici metriche linguistiche. Se il costo hardware scende ma la capacità di completare attività di software engineering cala più del previsto, il risparmio in VRAM può essere compensato da un TCO meno favorevole e da cicli di correzione più lunghi.

La vicenda segnala uno slittamento strutturale: la Quantization non si valuta più solo con test di fluency, ma con benchmark agentici. I fornitori che pubblicano headline senza rendere espliciti baseline e refusi alimentano un confronto opaco. Chi invece documenta con precisione i modelli di partenza può trasformare l'onestà tecnica in vantaggio commerciale, soprattutto nell'on-premise dove la scelta di una quantization ternaria incide sulla progettazione dell'hardware e sulla sostenibilità del deployment.

Resta un punto concreto: il whitepaper è su GitHub, pagina 7. Chi valuta il modello può verificare i numeri senza passare dalla headline.