Google ha pubblicato i checkpoint addestrati con quantizzazione consapevole (QAT, Quantization-Aware Training) per la famiglia Gemma 4, un passaggio pensato per far girare modelli generativi di buona qualità non più solo su server, ma direttamente su smartphone, dispositivi edge e GPU di fascia consumer. Il risultato più appariscente è la compressione della variante più piccola fino a circa 1 GB di memoria, una soglia che cambia in modo concreto cosa è realisticamente eseguibile in locale, senza una connessione al cloud e senza hardware specializzato.
Per capire perché il metodo conta, vale la pena distinguere due approcci alla quantizzazione. La quantizzazione consiste nel ridurre la precisione numerica dei pesi del modello per diminuirne le dimensioni in memoria. L’approccio più diffuso è la quantizzazione post-addestramento (PTQ), che comprime un modello già addestrato: è semplice, ma introduce errori di arrotondamento che il modello non ha mai imparato a gestire, e questo si traduce in un calo di qualità. La QAT inverte la logica: simula la quantizzazione già durante l’addestramento, così che il modello impari a compensare da solo la perdita di precisione e arrivi alla compressione finale in una forma per cui è stato preparato. A parità di dimensione su disco, un modello QAT tende quindi a comportarsi meglio di uno ottenuto con PTQ.
Google ha quantificato questo vantaggio in un punto specifico. Partendo dai checkpoint non quantizzati ed eseguendo circa 5.000 passi aggiuntivi di addestramento QAT, l’aumento di perplexity tipicamente provocato dalla compressione Q4_0, cioè il peggioramento nella capacità del modello di prevedere il testo e quindi un indicatore indiretto del degrado di qualità, è stato ridotto del 54% rispetto al comportamento precedente. È un dato di processo, non un benchmark applicativo: numeri di prestazione su task concreti non sono stati diffusi, e questo limite va tenuto presente nel valutare il rilascio.
La distribuzione avviene in tre formati, ciascuno tarato su una classe di hardware diversa. Il formato BF16 è il riferimento di qualità, ma resta pesante: la variante E2B richiede circa 9,6 GB di memoria e la E4B circa 15 GB, valori che lo collocano su server e PC ad alte prestazioni più che su un telefono. Il formato Q4_0 QAT è pensato per l’esecuzione locale comune e riduce la E2B a circa 3,2 GB e la E4B a circa 5 GB, abbastanza da girare su GPU consumer; la E2B è stata fatta funzionare perfino su un Raspberry Pi 5 in configurazione INT4, che è probabilmente la dimostrazione più eloquente di quanto si sia abbassata l’asticella hardware. Il terzo formato, quello specifico per mobile, è quello che porta la E2B intorno a 1 GB e scendendo a una versione solo testuale, cioè rimuovendo gli encoder audio e di visione. si arriva anche sotto il gigabyte.
Quel risultato sul mobile non nasce da una singola scorciatoia ma dalla combinazione di quattro accorgimenti tarati sull’hardware dei telefoni. Le attivazioni statiche precalcolano i valori di scala già in fase di addestramento, alleggerendo il carico di calcolo a tempo di esecuzione sul dispositivo. La quantizzazione per canale (channel-wise) è strutturata per adattarsi agli acceleratori AI mobili anziché trattare il tensore in modo uniforme. A questi si aggiunge una compressione a 2 bit applicata in modo selettivo ai soli livelli di generazione dei token, insieme all’ottimizzazione degli embedding e della cache KV per tagliare ulteriormente l’occupazione di memoria. A fare da contrappeso, i livelli centrali dell’inferenza mantengono una precisione relativamente più alta: è la scelta deliberata che evita di spingere la compressione fin dove farebbe crollare la qualità.
La logica complessiva dei tre formati disegna una scala di compromessi piuttosto leggibile: il formato mobile è ottimizzato per smartphone e acceleratori AI mobili, mentre Q4_0 QAT resta l’opzione più pratica per notebook e GPU consumer, e BF16 presidia il vertice qualitativo dove la memoria non è un vincolo. Resta però un’avvertenza esplicita e non trascurabile: i dati pubblicati riflettono obiettivi di progettazione e valutazioni interne, non una verifica indipendente delle prestazioni del Gemma 4 QAT. La conseguenza pratica è chiara per chi sviluppa: prima di costruire un servizio reale conviene misurare il comportamento del modello sul proprio hardware e per il proprio caso d’uso, perché il margine tra una compressione che regge e una che degrada dipende molto dal contesto di esecuzione.