LLM TERNARIE (1,58 bit): BitNet riduce i pesi di circa 10 volte rispetto a FP16

Prima di tutto correggiamo il numero: 20 volte no, almeno non rispetto a FP16

Se avete letto che BitNet permette di ridurre di venti volte la memoria rispetto ad un normale LLM FP16 o BF16, saprete certamente perché la notizia attira subito l'attenzione, ma qui conviene sistemare il dato prima di andare oltre, perché tre possibili valori per ogni peso, cioè -1, 0 e +1, contengono teoricamente log2(3), quindi circa 1,585 bit di informazione, ed il rapporto fra 16 bit e 1,585 è circa 10,1. Il famoso fattore venti compare invece se il confronto viene fatto con FP32, perché 32 diviso 1,585 vale poco più di 20, mentre nella pratica il risparmio complessivo è inferiore al rapporto teorico poiché non tutto il modello vive necessariamente in forma ternaria, rimangono scale, embedding, metadati, attivazioni, cache KV ed altre strutture che occupano memoria. La tecnologia però è assolutamente reale, nasce da una linea di ricerca di Microsoft Research iniziata con BitNet nel 2023, proseguita con BitNet b1.58 nel 2024, pubblicata anche sul Journal of Machine Learning Research nel 2025 ed arrivata ad un modello ufficiale open-weight da circa 2,4 miliardi di parametri addestrato su 4 trilioni di token.

Questo dettaglio mi interessa molto perché evita di trasformare un risultato tecnico notevole nell'ennesimo miracolo raccontato male, dato che BitNet non rende magicamente ogni LLM venti volte più piccolo, ma dimostra qualcosa che fino a pochi anni fa sembrava quasi controintuitivo, ovvero che una rete Transformer può imparare a funzionare mantenendo nella parte più costosa dei propri layer soltanto TRE STATI POSSIBILI per ciascun peso, continuando tuttavia ad ottenere prestazioni sorprendentemente vicine a quelle di modelli della stessa classe addestrati in FP16 o BF16.

Che cosa significa quantizzare un modello senza entrare subito nella matematica pesante

Se avete mai salvato una fotografia riducendo la profondità colore, avrete già incontrato intuitivamente lo stesso problema, perché un valore che prima poteva assumere moltissime sfumature viene costretto ad appartenere ad un insieme molto più piccolo di valori possibili. Nei normali LLM i pesi sono numeri che durante l'addestramento possono assumere una quantità enorme di valori, spesso rappresentati in FP32, FP16 oppure BF16, ed ogni peso contribuisce un poco al modo in cui il modello trasforma l'informazione mentre attraversa i layer; quantizzare significa rappresentare quegli stessi numeri con meno bit, per esempio 8, 4 oppure 2, riducendo memoria e banda necessaria per spostarli.

La quantizzazione tradizionale avviene spesso DOPO l'addestramento, quindi prendiamo un modello già formato in precisione elevata e cerchiamo di comprimere i suoi pesi in INT8, INT4 oppure in formati ancora più aggressivi, accettando un errore di approssimazione che può essere quasi invisibile quando la quantizzazione è moderata ma diventa sempre più difficile da controllare quando ci avviciniamo ad uno o due bit. Se un peso vale 0,13742 ed io possiedo soltanto pochi livelli numerici disponibili, devo sostituirlo con il livello più vicino, e ripetendo questa operazione miliardi di volte posso finire per cambiare in maniera sensibile il comportamento della rete.

BitNet prende invece la questione molto più a monte, perché non si limita a comprimere alla fine un modello convenzionale, ma addestra il Transformer SAPENDO FIN DALL'INIZIO che durante il forward i pesi dei layer BitLinear dovranno diventare ternari. Durante il training esistono comunque pesi master a precisione maggiore, necessari affinché l'ottimizzatore possa effettuare piccoli aggiornamenti numerici, ma quando la rete esegue il passaggio in avanti quei pesi vengono quantizzati attraverso una scala basata sulla media dei valori assoluti e poi arrotondati nei tre stati -1, 0 e +1; la retropropagazione usa tecniche come lo Straight-Through Estimator per permettere ai gradienti di attraversare un'operazione di arrotondamento che, matematicamente, non sarebbe differenziabile nel modo normale. In altre parole non stiamo prendendo un cervello FP16 già costruito e schiacciandolo a forza dentro 1,58 bit, stiamo insegnando al cervello a crescere fin dall'inizio sapendo che dovrà parlare quel linguaggio estremamente povero.

Perché si chiama 1,58 bit se i valori possibili sono tre

Un bit puro possiede due stati, 0 oppure 1, quindi un peso binario potrebbe essere rappresentato teoricamente con un solo bit, mentre BitNet b1.58 usa tre stati e per distinguere tre simboli servono log2(3), cioè circa 1,585 bit di informazione per peso. Naturalmente la memoria di un computer non ci offre una comoda cella fisica da 1,585 bit, perciò l'implementazione deve impacchettare più valori ternari insieme, usare rappresentazioni come I2_S oppure tabelle di lookup ed aggiungere le scale necessarie alla ricostruzione numerica.

Questa differenza fra limite teorico e formato reale è fondamentale, perché il modello ufficiale Microsoft BitNet b1.58 2B4T occupa circa 1,18 GB nel checkpoint packed distribuito per l'inferenza, mentre il checkpoint BF16 con i master weights pesa circa 4,83 GB, quindi il rapporto fra i due FILE reali è poco superiore a quattro, non dieci. Nel paper Microsoft il confronto sulla sola memoria dei pesi non-embedding attribuisce invece circa 0,4 GB a BitNet b1.58 2B4T, contro 2,6 GB per Qwen2.5 1.5B in BF16, e qui il vantaggio sale a circa 6,5 volte pur mettendo a confronto architetture e dimensioni leggermente differenti. Il rapporto di 10,1 rimane quindi il limite informativo molto utile per capire l'ordine di grandezza, NON una promessa secondo la quale la RAM totale di ogni applicazione verrà sempre divisa esattamente per dieci.

Nel settembre 2026 è arrivato perfino un lavoro che prova a scendere sotto la rappresentazione convenzionale di 1,58 bit effettivi sfruttando il fatto che nei modelli ternari reali i tre simboli non compaiono con la stessa probabilità, ed il metodo BITCOS ha misurato fino al 51,5 per cento di zeri nei modelli analizzati, ottenendo sul più sparso circa 1,485 bit per peso ed incrementi di throughput misurati fino a circa 1,18 volte su CPU e 1,27 volte su GPU. Questo non cambia BitNet in un modello da mezzo bit, naturalmente, ma mostra che anche il modo con cui immagazziniamo i tre stati è ancora un terreno di ricerca attivo.

Dove spariscono le moltiplicazioni

La parte più elegante di BitNet appare quando guardiamo una moltiplicazione fra matrice dei pesi ed attivazioni, perché se un peso può essere soltanto +1, 0 oppure -1 allora moltiplicare un'attivazione per quel peso significa rispettivamente lasciarla invariata, ignorarla oppure cambiarne il segno. Gran parte delle costose moltiplicazioni generiche dei layer lineari può quindi trasformarsi in somme, sottrazioni, salti condizionali oppure accessi a tabelle precalcolate, ed è precisamente il motivo per cui bitnet.cpp utilizza kernel specializzati come Ternary Lookup Table ed I2_S invece di trattare il modello come se fosse un normale Transformer FP16.

Non significa però che l'intera rete smetta di moltiplicare, perché restano normalizzazioni, scale di quantizzazione, attenzione, operazioni sulle attivazioni ed altre parti che non diventano improvvisamente gratuite, inoltre BitNet b1.58 2B4T usa attivazioni INT8 e quindi la notazione corretta del suo schema è W1.58A8, cioè pesi a circa 1,58 bit ed attivazioni ad 8 bit. Il guadagno più importante nasce comunque dal fatto che i pesi occupano molta meno memoria e devono percorrere una quantità molto inferiore di banda fra RAM, cache ed unità di calcolo, e durante la generazione autoregressiva degli LLM proprio il traffico di memoria rappresenta spesso uno dei limiti principali.

Non basta convertire un Llama in tre valori ed aspettarsi che continui a funzionare

Qui BitNet introduce una distinzione che trovo essenziale, perché una quantizzazione post-training estrema ed un modello nativamente addestrato in ternario possono avere lo stesso numero nominale di bit ma NON sono la stessa cosa. Microsoft ha confrontato il proprio BitNet b1.58 2B4T, addestrato da zero in questa forma, con modelli più grandi convertiti successivamente a 1,58 bit, fra cui Falcon3 e Llama 3, ed il modello nativo da circa 2 miliardi di parametri ha ottenuto nel confronto complessivo risultati superiori nonostante il minor numero di parametri.

Il motivo intuitivo è abbastanza semplice, perché una rete addestrata per mesi usando valori continui può aver costruito rappresentazioni che dipendono proprio dalle piccole differenze fra quei valori, quindi distruggerle alla fine può costare capacità, mentre una rete che durante ogni forward vede già i propri pesi ridotti a -1, 0 e +1 impara progressivamente a distribuire l'informazione in un modo compatibile con quel vincolo. Quello che SACRIFICHIAMO è quindi la precisione del singolo peso, ma in cambio lasciamo all'addestramento il compito di riorganizzare miliardi di pesi affinché la precisione del singolo numero conti meno della struttura complessiva della rete.

Può davvero competere con FP16 e BF16

La risposta corretta è sì, MA soltanto se precisiamo in quale fascia di modelli e su quali test. Nel lavoro originario su BitNet b1.58 i ricercatori avevano mostrato che, a parità di dimensione del modello e di token di addestramento nelle scale sperimentate, la versione ternaria poteva raggiungere perplexity e risultati finali comparabili al Transformer FP16 o BF16, ed il lavoro successivo del 2025 ha reso la prova molto più concreta pubblicando BitNet b1.58 2B4T, un modello reale, scaricabile ed addestrato su 4 trilioni di token.

Nel confronto ufficiale con Llama 3.2 1B, Gemma 3 1B, Qwen2.5 1.5B, SmolLM2 1.7B e MiniCPM 2B, BitNet ha ottenuto una media aggregata di 54,19, molto vicina al 55,23 di Qwen2.5 1.5B e superiore agli altri modelli del gruppo, con risultati particolarmente forti su alcuni benchmark di ragionamento e matematica. Questo permette di affermare seriamente che la precisione ternaria NON condanna automaticamente un LLM ad essere molto peggiore di un modello BF16 della stessa fascia, ma non permette di estendere la conclusione a qualunque dimensione, a qualunque dataset ed a qualunque compito, perché la stessa Microsoft indica ancora come ricerca futura la verifica delle scaling law su modelli nativi da 7B, 13B ed oltre.

Programmazione complessa, qui la risposta diventa meno spettacolare

Se la domanda è quale sia oggi il BitNet più convincente per programmazione informatica complessa, io eviterei di inventare un vincitore che i benchmark non dimostrano. Il riferimento scientificamente più solido fra i modelli NATIVI rimane BitNet b1.58 2B4T di Microsoft, perché è il modello ufficiale addestrato da zero in W1.58A8 e valutato anche sul codice, ma su HumanEval+ ottiene un Pass@1 del 38,40 per cento, mentre Qwen2.5 1.5B in BF16 arriva al 50,60 per cento, MiniCPM 2B al 43,90 e Gemma 3 1B al 37,20. Quindi BitNet compete bene nella media generale, ma sul benchmark di programmazione NON batte il miglior modello FP16 o BF16 del confronto.

Esistono modelli più grandi compatibili con bitnet.cpp, compreso Falcon3-10B-Instruct-1.58bit, che è certamente interessante perché porta la rappresentazione ternaria fino alla classe dei 10 miliardi di parametri, ma qui dobbiamo distinguere ancora una volta fra un BitNet nativo ed un modello convenzionale compresso successivamente, dato che Falcon3 appartiene alla seconda categoria. Il repository ufficiale Microsoft lo supporta per l'inferenza, ma non esiste al momento una batteria di benchmark indipendenti e sufficientemente completa sulla programmazione complessa che mi permetta di dire con serietà che sia il miglior coding model BitNet disponibile, e la sua scheda pubblica riporta soprattutto benchmark generali, matematici ed instruction-following.

C'è poi un limite molto concreto nel modello Microsoft, ovvero il contesto massimo di 4096 token, che per completare una funzione isolata può bastare ma per comprendere repository, stack trace lunghi, più file, framework moderni e refactoring importanti diventa presto stretto. Per questo, se il criterio è QUALITÀ DEL CODICE COMPLESSO oggi sceglierei ancora un modello specializzato più grande in BF16, FP16 oppure quantizzato a 4 o 8 bit, mentre sceglierei BitNet quando memoria, CPU, consumo energetico ed esecuzione locale contano più della capacità assoluta di programmazione.

Quanto chiede davvero BitNet b1.58 2B4T

Facciamo due conti molto semplici, perché 2,4 miliardi di parametri memorizzati idealmente a 16 bit richiedono circa 4,8 GB soltanto per i pesi, mentre a 1,585 bit il limite teorico scende a circa 475 MB. Il checkpoint BF16 ufficiale di Microsoft pesa infatti circa 4,83 GB, mentre quello packed destinato all'inferenza pesa circa 1,18 GB, ed il paper stima circa 0,4 GB per la parte non-embedding realmente ternaria; queste tre cifre non sono in contraddizione, descrivono livelli diversi, cioè il file BF16 completo, il file distribuito per l'inferenza con parti non ternarie e metadati, e la sola memoria dei pesi BitLinear esclusi gli embedding.

Durante l'esecuzione dobbiamo poi aggiungere altro, perché servono memoria per attivazioni, buffer temporanei, tokenizer e soprattutto KV cache, che cresce con lunghezza del contesto, numero di layer e numero di token già elaborati. Dire che un modello possiede 400 MB di pesi ternari NON equivale quindi a dire che l'intero programma userà 400 MB di RAM, così come un modello FP16 da 5 GB non consuma soltanto 5 GB una volta messo realmente al lavoro.

Un GPT-3 da 175 miliardi di parametri sul telefono? No, almeno non con questi numeri

La frase secondo cui BitNet permetterebbe ad un modello potente come GPT-3 di girare tranquillamente su uno smartphone è quella che eliminerei senza esitazione, perché basta la matematica a mostrarne il problema. GPT-3 nella configurazione famosa possiede circa 175 miliardi di parametri, quindi in FP16 i soli pesi richiederebbero circa 350 GB, mentre al limite teorico di 1,585 bit scenderebbero a circa 34,7 GB; è un risultato enorme, perché abbiamo eliminato oltre 300 GB, ma rimangono quasi 35 GB PRIMA di aggiungere embedding non ternari, scale, cache KV, attivazioni e memoria del runtime.

Su un notebook ben dotato oppure su una workstation CPU con molta RAM il quadro cambia radicalmente, ed infatti bitnet.cpp nasce proprio per rendere efficienti questi modelli su x86 ed ARM senza obbligare ad avere una GPU enorme. Microsoft ha mostrato nei benchmark dell'infrastruttura speedup fino a 6,17 volte su x86 e 5,07 volte su ARM rispetto alle baseline full precision, con riduzioni energetiche massime riportate rispettivamente dell'82,2 e del 70 per cento, ma quando il repository parla della possibilità di eseguire un BitNet da 100B su una singola CPU a circa 5 o 7 token al secondo bisogna aggiungere un dettaglio importantissimo, perché quei test di scala hanno utilizzato anche modelli DUMMY costruiti per misurare il runtime, non un ipotetico GPT-3 BitNet da 100 miliardi di parametri addestrato e pronto all'uso.

Il sogno del telefono rimane comunque tutt'altro che assurdo se riduciamo la scala. Un modello da 7 miliardi di pesi ternari richiede teoricamente circa 1,39 GB per i soli pesi, un 13B circa 2,58 GB ed un 70B circa 13,9 GB, quindi telefoni con molta RAM, notebook economici, single-board computer ed Edge device possono entrare in territori che con FP16 erano semplicemente impossibili. Ma per piccoli elettrodomestici, sensori indossabili oppure microcontrollori parliamo ancora di modelli molto più piccoli, distillati e specializzati, non di un LLM generalista da centinaia di miliardi di parametri.

La velocità dipende anche dall'hardware che ancora non esiste

C'è un aspetto quasi paradossale in BitNet, perché questa architettura nasce proprio per rendere più economico il calcolo ma le CPU e soprattutto le GPU che utilizziamo oggi sono state progettate per lavorare molto bene con FP16, BF16, INT8 ed ormai INT4, NON con aritmetica ternaria nativa. Il kernel GPU ufficiale deve quindi impacchettare quattro valori ternari in un byte, caricarli dalla memoria, spacchettarli nella shared memory e trasformarli in una rappresentazione adatta al calcolo, e questo introduce lavoro che un futuro acceleratore pensato direttamente per -1, 0 e +1 potrebbe evitare.

Su CPU bitnet.cpp usa invece kernel molto specifici, tabelle di lookup e rappresentazioni compatte che sfruttano AVX oppure NEON, ed è qui che la riduzione della banda di memoria produce già risultati notevoli senza aspettare un nuovo processore. A mio parere questa è una delle conseguenze più interessanti del progetto, perché se i modelli ternari dovessero realmente crescere fino a decine o centinaia di miliardi di parametri mantenendo la qualità, avrebbe senso progettare NPU ed ASIC nei quali il percorso dati, le cache ed i moltiplicatori tradizionali vengano ripensati attorno ad un'aritmetica che per la maggior parte dei pesi deve soltanto scegliere fra zero, valore positivo e valore negativo.

Cosa stiamo sacrificando davvero

La risposta più corretta è che sacrifichiamo RISOLUZIONE NUMERICA nel singolo parametro, perché un peso BF16 può assumere migliaia di valori rappresentabili mentre un peso BitNet ne possiede tre, ma non è detto che sacrifichiamo nella stessa proporzione la capacità dell'intero modello. Una rete neurale distribuisce l'informazione attraverso miliardi di parametri, ed addestrarla nativamente sotto questo vincolo significa permetterle di imparare una rappresentazione diversa invece di obbligarla a conservare esattamente quella di un modello full precision.

Paghiamo però in altri punti, perché il training richiede ancora master weights ad alta precisione e non diventa improvvisamente dieci volte più economico, la toolchain è più specializzata, il supporto hardware è ancora immaturo, alcuni operatori rimangono a precisione superiore ed i risultati pubblicati non dimostrano ancora che la parità continui indefinitamente salendo a 70B, 100B o 400B parametri. Ed inoltre il modello ufficiale da 2,4B mostra molto chiaramente che essere competitivo nella media NON significa essere il migliore in ogni specialità, visto che proprio nel coding perde parecchi punti rispetto a Qwen2.5 1.5B.

La rivoluzione è reale, ma è diversa da quella raccontata negli slogan

Io penso che BitNet sia molto più interessante quando smettiamo di venderlo come il trucco che mette GPT-3 dentro un telefono e lo guardiamo per ciò che ha già dimostrato, perché un Transformer nativo con pesi ternari può essere addestrato seriamente, può raggiungere prestazioni vicine a modelli full precision della stessa classe, può essere eseguito su CPU con kernel specializzati ed abbassa in maniera drastica il costo di muovere e conservare miliardi di pesi. Microsoft ha già pubblicato modello, runtime CPU, kernel GPU e dati sperimentali, mentre nel 2026 la ricerca sta lavorando perfino su rappresentazioni ternarie più compatte e su hardware dedicato.

La prossima domanda quindi non è più se un LLM a 1,58 bit POSSA ESISTERE, perché quello ormai lo abbiamo davanti e possiamo scaricarlo, ma quanto bene scalerà quando i modelli nativi passeranno dai circa 2 miliardi attuali a 7B, 13B, 70B ed oltre, quanto hardware verrà progettato espressamente per questa aritmetica e soprattutto se la quasi parità osservata nelle scale attuali riuscirà a sopravvivere quando chiederemo ragionamento lungo, contesti enormi e programmazione veramente complessa. Se quella risposta sarà positiva, allora la conseguenza non sarà semplicemente avere lo stesso chatbot che consuma un po' meno RAM, ma poter spostare una quantità di Intelligenza Artificiale oggi legata a GPU costose direttamente su CPU, notebook, smartphone ed Edge device, portando molta più AI dove oggi no ci sta.