Google DeepMind ha rilasciato Gemma 4 il 2 aprile 2026. Quattro dimensioni di modello, supporto multimodale completo, licenza Apache 2.0 e punteggi nei benchmark che mettono in difficoltà modelli 20 volte più grandi. La variante più piccola gira su un Raspberry Pi 5. La più grande, un modello denso da 31B, si piazza al terzo posto tra tutti i modelli open nella classifica Arena AI.
Non è un aggiornamento incrementale. È un argomento radicalmente diverso su quanto debba essere grande un modello.
Ho passato l’ultimo giorno ad analizzare ogni dettaglio tecnico dal blog di integrazione di Hugging Face, dall’annuncio ufficiale di Google, dalla guida al deployment edge di NVIDIA, dalla model card di DeepMind, dalla classifica Chatbot Arena e da 445 commenti su Hacker News. Ecco tutto quello che ho trovato.
La famiglia completa Gemma 4: quattro modelli, un’unica linea architetturale
Gemma 4 è disponibile in quattro dimensioni, tutte rilasciate sia come checkpoint base che instruction-tuned:
- E2B: 2,3B parametri effettivi (5,1B totali con embeddings), 128K di contesto, sliding window da 512 token
- E4B: 4,5B parametri effettivi (7,9B totali con embeddings), 128K di contesto, sliding window da 512 token
- 26B-A4B: Mixture-of-Experts, 3,8B attivi su 25,2B totali (128 expert, 8 attivi + 1 condiviso), 256K di contesto
- 31B: completamente denso, 30,7B parametri, 256K di contesto, sliding window da 1024 token
Tutti e quattro gestiscono testo, immagini e video. L’E2B e l’E4B supportano anche l’input audio nativo (riconoscimento e comprensione vocale, fino a 30 secondi). Ogni modello include function calling nativo, output JSON strutturato, system instructions e modalità di thinking/reasoning. Supportano oltre 140 lingue con un vocabolario di 262K token.
La “E” in E2B ed E4B sta per “Effective”. Questi modelli usano Per-Layer Embeddings (PLE), un’architettura ereditata da Gemma 3n, che rende il conteggio totale dei parametri superiore a quello effettivo. I parametri aggiuntivi sono tabelle di embedding, non pesi del decoder, quindi non contribuiscono al calcolo per l’inferenza allo stesso modo.
La svolta Apache 2.0
Ogni precedente rilascio di Gemma utilizzava una licenza proprietaria Google. Tecnicamente consentiva l’uso commerciale, ma includeva clausole che permettevano a Google di limitare l’utilizzo a determinate condizioni. Gli sviluppatori che costruivano sistemi in produzione su modelli Gemma avevano un’incertezza legale incorporata nel loro stack.
Gemma 4 è Apache 2.0. Punto. Potete usare questi modelli commercialmente, modificarli, ridistribuirli, creare opere derivate, integrarli con codice proprietario e costruire prodotti senza chiedere permesso né preoccuparvi di futuri cambiamenti di licenza. Per i settori regolamentati (sanità, finanza, pubblica amministrazione), dove la revisione legale delle licenze dei modelli può richiedere mesi, questo rimuove un ostacolo significativo all’adozione.
La decisione Apache 2.0 apre anche la porta a modifiche della community che prima erano in una zona grigia legale: varianti abliterated/senza censura, fine-tune specifici per dominio con profili di sicurezza personalizzati e integrazione in progetti copyleft. Almeno una variante senza censura di Gemma 4 è apparsa entro poche ore dal rilascio.
Il denso 31B: il modello che ha cambiato la conversazione
Gemma 4 31B è un transformer completamente denso. Ognuno dei suoi 30,7 miliardi di parametri si attiva su ogni token. Nessun routing, nessuna selezione di expert, nessun trucco di sparsità. E ottiene un punteggio stimato di 1452 su Arena AI (testo), piazzandosi al terzo posto tra tutti i modelli open-source al mondo e diventando il primo modello open-source statunitense.
Per capire perché è importante, guardate cosa c’è intorno a lui nella classifica:
- GLM-5 (Z.ai/Zhipu): punteggio Arena 1452, licenza MIT, circa ~750B parametri stimati. 24 volte più grande di Gemma 4 31B.
- Kimi-K2.5-Thinking (Moonshot AI): punteggio Arena 1451, Modified MIT. Oltre 1T di parametri totali stimati. 34 volte più grande.
- Qwen 3.5-397B-A17B (Alibaba): punteggio Arena 1450, Apache 2.0. 397B parametri totali, 17B attivi. 13 volte più grande in parametri totali.
- Gemma 4 31B (Google): punteggio Arena 1452, Apache 2.0. 31B denso. Pareggia o batte tutti quelli sopra.
Sotto di lui: DeepSeek-R1-0528 a 1426, GPT-5-high a 1444, Grok-4 a 1442. Si tratta di modelli proprietari accessibili solo via API, sviluppati da laboratori con finanziamenti enormi. Un modello open da 31B che li eguaglia non è normale.
Analisi approfondita dei benchmark
Ecco la tabella completa dei benchmark per i modelli instruction-tuned con thinking abilitato, confrontati con Gemma 3 27B (la generazione precedente):
Ragionamento e conoscenza:
- MMLU-Pro (Q&A multilingue): Gemma 4 31B 85,2% | 26B-A4B 82,6% | E4B 69,4% | E2B 60,0% | Gemma 3 27B 67,6%
- AIME 2026 (matematica competitiva, senza strumenti): 31B 89,2% | 26B 88,3% | E4B 42,5% | E2B 37,5% | Gemma 3 20,8%
- GPQA Diamond (scienze a livello dottorale): 31B 84,3% | 26B 82,3% | E4B 58,6% | E2B 43,4% | Gemma 3 42,4%
- Tau2 Bench (uso agentico di strumenti, media di 3): 31B 76,9% | 26B 68,2% | E4B 42,2% | E2B 24,5% | Gemma 3 16,2%
- BigBench Extra Hard: 31B 74,4% | 26B 64,8% | E4B 33,1% | E2B 21,9% | Gemma 3 19,3%
- MMMLU (multilingue): 31B 88,4% | 26B 86,3% | E4B 76,6% | E2B 67,4% | Gemma 3 70,7%
Codice:
- LiveCodeBench v6: 31B 80,0% | 26B 77,1% | E4B 52,0% | E2B 44,0% | Gemma 3 29,1%
- Codeforces ELO: 31B 2150 | 26B 1718 | E4B 940 | E2B 633 | Gemma 3 110
- HLE (Humanity’s Last Exam, senza strumenti): 31B 19,5% | 26B 8,7%
- HLE con ricerca: 31B 26,5% | 26B 17,2%
Visione:
- MMMU Pro (ragionamento multimodale): 31B 76,9% | 26B 73,8% | E4B 52,6% | E2B 44,2% | Gemma 3 49,7%
- MATH-Vision: 31B 85,6% | 26B 82,4% | E4B 59,5% | E2B 52,4% | Gemma 3 46,0%
- OmniDocBench 1.5 (edit distance, più basso è meglio): 31B 0,131 | 26B 0,149 | E4B 0,181 | E2B 0,290 | Gemma 3 0,365
- MedXPertQA MM (multimodale medico): 31B 61,3% | 26B 58,1% | E4B 28,7% | E2B 23,5%
Audio (solo E2B ed E4B):
- CoVoST (traduzione vocale): E4B 35,54 | E2B 33,47
- FLEURS (riconoscimento vocale, più basso è meglio): E4B 0,08 | E2B 0,09
Contesto lungo:
- MRCR v2 8-needle 128K (media): 31B 66,4% | 26B 44,1% | E4B 25,4% | E2B 19,1% | Gemma 3 13,5%
Il salto generazionale da Gemma 3 27B a Gemma 4 31B è impressionante. AIME passa dal 20,8% all’89,2%. LiveCodeBench dal 29,1% all’80,0%. Codeforces ELO da 110 a 2150. Non sono miglioramenti marginali. Sono salti qualitativi verso un livello di capacità completamente diverso.
Gemma 4 31B vs Qwen 3.5 27B: confronto diretto
La community non ha perso tempo a costruire confronti fianco a fianco. Ecco il quadro consolidato da più tester indipendenti:
- MMLU-Pro: Gemma 4 85,2% vs Qwen 3.5 86,1% (Qwen vince di poco)
- GPQA Diamond: Gemma 4 84,3% vs Qwen 3.5 85,5% (Qwen vince di poco)
- LiveCodeBench v6: Gemma 4 80,0% vs Qwen 3.5 80,7% (pareggio)
- Codeforces ELO: Gemma 4 2150 vs Qwen 3.5 1899 (Gemma vince nettamente)
- TAU2-Bench: Gemma 4 76,9% vs Qwen 3.5 79,0% (Qwen vince)
- MMMLU (multilingue): Gemma 4 88,4% vs Qwen 3.5 85,9% (Gemma vince)
- HLE (senza strumenti): Gemma 4 19,5% vs Qwen 3.5 24,3% (Qwen vince)
Sui benchmark automatizzati puri, è quasi un pareggio con Qwen 3.5 leggermente in vantaggio sui task di ragionamento e Gemma 4 che prevale nella programmazione competitiva e nel multilingue. Ma l’ELO di Arena AI (che misura la preferenza umana da milioni di confronti alla cieca) favorisce Gemma 4: 1452 vs 1450. Il divario tra ELO e benchmark automatizzati suggerisce che Gemma 4 produce risposte che gli umani effettivamente preferiscono, anche quando i numeri di accuratezza grezza sono simili. Questo è un segnale sulla qualità dei dati di addestramento e del RLHF, non sull’architettura.
Un early adopter su dev.to ha sintetizzato bene: “La valutazione onesta è che Gemma 4 pareggia con Qwen, se non che Qwen è leggermente avanti. E Qwen 3.5 è anche più efficiente in termini di calcolo.” Ma un altro ha osservato: “Gemma 4 fa sembrare translategemma obsoleto all’istante” per i task non in inglese. La dimensione multilingue è dove Gemma 4 si distacca chiaramente dal resto.
Architettura: come 31B parametri riescono a competere così al di sopra della loro classe
Gemma 4 non raggiunge questi risultati semplicemente scalando un transformer standard. Il blog di integrazione di Hugging Face descrive diverse innovazioni architetturali che lavorano insieme per spremere la massima intelligenza da ogni parametro. Google ha rimosso caratteristiche complesse o inconcludenti come Altup che apparivano nella ricerca precedente su Gemma, optando per una combinazione più pulita e altamente compatibile con le librerie di inferenza.
Dual Attention: Sliding Window + Full-Context globale
Gemma 4 alterna due tipi di layer di attention:
- Attention locale a sliding window: ogni token attende solo ai token vicini entro una finestra fissa. I modelli 31B e 26B usano finestre da 1024 token; l’E2B e l’E4B usano finestre da 512 token. È economico perché la matrice di attention è piccola.
- Attention globale full-context: attention standard sull’intera sequenza. Costosa nei contesti lunghi, ma necessaria per catturare dipendenze a lungo raggio.
Alternando queste due modalità, il modello ottiene il beneficio della consapevolezza dell’intero contesto (attraverso i layer globali) senza pagare il costo quadratico completo su ogni layer. Ogni tipo di attention ha anche la propria configurazione RoPE: RoPE standard per i layer a sliding window, RoPE proporzionale per i layer globali. La variante proporzionale abilita la finestra di contesto da 256K sui modelli più grandi senza che la codifica posizionale si deteriori alle posizioni estreme.
KV Cache condivisa
Questa è un’ottimizzazione di efficienza che riduce direttamente sia il calcolo che la memoria durante l’inferenza. Gli ultimi num_kv_shared_layers layer del modello non calcolano le proprie proiezioni key e value. Invece, riutilizzano i tensori K/V dall’ultimo layer non condiviso dello stesso tipo di attention (sliding o full).
In pratica, questo significa che il modello ha meno KV cache distinte da mantenere durante la generazione. Per l’uso con contesto lungo (la finestra da 256K) e il deployment su dispositivo, è significativo. È la differenza tra stare in memoria e non starci. L’impatto sulla qualità, secondo i test di Hugging Face, è minimo.
Un commentatore su Hacker News ha fatto notare che il comportamento della KV cache del 31B non è un bug (come alcuni avevano inizialmente sospettato) ma riflette un costo statico della sliding window di 3,6GB. Con una quantizzazione IQ4_XS a 15,2GB per i pesi, si arriva a circa 64K di contesto su una GPU da 24GB, o oltre 100K con quantizzazione KV a 8-bit dopo una recente ottimizzazione in llama.cpp.
Per-Layer Embeddings (PLE)
Questa è la caratteristica architetturale più distintiva nei modelli Gemma 4 più piccoli (E2B ed E4B), ereditata da Gemma 3n. I transformer standard assegnano a ogni token un singolo vettore di embedding in input. Quel singolo vettore deve anticipare tutto ciò di cui il modello potrebbe aver bisogno attraverso tutti i layer. È un collo di bottiglia.
PLE aggiunge un percorso di condizionamento parallelo a dimensionalità inferiore accanto al flusso residuo principale. Per ogni token, PLE produce un piccolo vettore dedicato per ogni layer combinando due segnali:
- Una componente di identità del token: da una seconda tabella di lookup degli embedding
- Una componente consapevole del contesto: da una proiezione appresa degli embedding principali
Ogni layer del decoder usa poi il suo vettore PLE corrispondente per modulare gli hidden state tramite un blocco residuo leggero dopo l’attention e il feed-forward. Questo dà a ogni layer il proprio canale per ricevere informazioni specifiche del token esattamente quando diventano rilevanti, anziché richiedere che tutto sia compresso in un singolo embedding iniziale.
Poiché la dimensione PLE è molto più piccola della dimensione nascosta principale, questo aggiunge una specializzazione significativa per layer a un costo modesto in parametri. Ecco perché il conteggio totale dei parametri (5,1B per E2B) è superiore al conteggio effettivo (2,3B): le tabelle di embedding PLE aggiungono parametri, ma sono economiche al momento dell’inferenza.
Per gli input multimodali (immagini, audio, video), PLE viene calcolato prima che i soft token vengano uniti alla sequenza di embedding. Le posizioni multimodali usano il pad token ID, quindi ricevono segnali per-layer neutri. Il modello impara a distinguere il testo dal contenuto multimodale in parte attraverso questo meccanismo.
Vision Encoder
L’encoder per le immagini utilizza embedding posizionali 2D appresi con RoPE multidimensionale. Due miglioramenti critici rispetto a Gemma 3:
- Rapporti d’aspetto variabili: niente più ritagli quadrati forzati. Le immagini vengono elaborate nelle loro dimensioni naturali, preservando informazioni che il ritaglio quadrato distrugge.
- Budget di token configurabili: l’encoder può produrre 70, 140, 280, 560 o 1120 token immagine per immagine. Si sceglie il proprio compromesso velocità/memoria/qualità per ogni richiesta. Un’analisi rapida di una miniatura potrebbe usare 70 token; un compito OCR dettagliato potrebbe usarne 1120.
Il team di Hugging Face ha testato tutte e quattro le dimensioni di modello su object detection, rilevamento di elementi GUI, didascalie di immagini e riproduzione HTML da screenshot. Tutti i modelli hanno funzionato bene, con il 31B che ha prodotto le risposte più dettagliate e accurate. Anche l’E2B ha identificato correttamente i bounding box per gli elementi UI e generato HTML accettabile da screenshot, il che è notevole per un modello da 2,3B parametri effettivi.
Audio Encoder
I modelli E2B ed E4B includono un audio encoder conformer in stile USM, la stessa architettura base utilizzata in Gemma 3n. Gestisce il riconoscimento vocale, la trascrizione speech-to-text e il question-answering audio per clip fino a 30 secondi. Nei test di Hugging Face, entrambi i modelli hanno trascritto accuratamente un estratto di un discorso di Obama e risposto a domande sul contenuto audio di un video di un concerto dal vivo (anche se l’E2B ha allucinato alcuni dettagli audio).
I modelli più grandi 31B e 26B non includono il supporto audio. Gestiscono il video elaborando i fotogrammi visivi senza la traccia audio. Questa è presumibilmente una decisione di budget parametrico: inserire un encoder audio completo in un modello da 31B avrebbe aggiunto parametri significativi senza un beneficio proporzionale per il caso d’uso primario di testo/codice/ragionamento.
L’E2B: IA di frontiera su un Raspberry Pi 5
Il membro più sorprendente della famiglia è il più piccolo. Gemma 4 E2B ha 2,3 miliardi di parametri effettivi e sta comodamente su dispositivi con 4GB+ di RAM. Google elenca esplicitamente Raspberry Pi, telefoni Android e NVIDIA Jetson Orin Nano come hardware target.
Lasciate che il dato faccia effetto. Questo è un modello che:
- Gestisce input di testo, immagini, audio e video
- Ha una finestra di contesto da 128K token
- Supporta function calling nativo per flussi di lavoro agentici
- Supporta oltre 140 lingue
- Include modalità di thinking/reasoning
- Funziona completamente offline con latenza quasi nulla
- Ottiene il 60% su MMLU-Pro e il 37,5% su AIME 2026
Per confronto, il modello completo da 27B di Gemma 3 (che richiedeva una GPU potente) otteneva il 67,6% su MMLU-Pro e il 20,8% su AIME 2026. L’E2B ottiene quasi lo stesso punteggio sui benchmark di conoscenza e quasi il doppio in matematica rispetto a un modello 12 volte più grande della generazione precedente. Un modello da 2,3B di aprile 2026 supera un modello da 27B del 2025 nella matematica competitiva. Il ritmo di miglioramento è vertiginoso.
Eseguirlo è banale:
ollama run gemma4:e2bSi tratta di un download quantizzato da 7,2GB (Q4_K_M) che vi dà un’IA multimodale con function calling nativo su un computer a scheda singola da 80 dollari. O sul telefono che avete in tasca. O in una scheda del browser tramite WebGPU.
Cosa si può fare concretamente con l’E2B
Il blog di Hugging Face include test approfonditi su tutte le modalità. Ecco cosa funziona immediatamente con il modello più piccolo:
Object detection e GUI pointing: Dategli uno screenshot e chiedete “Qual è il bounding box dell’elemento ‘view recipe’?” Risponde in formato JSON con le coordinate, senza bisogno di prompt speciali. Le coordinate si riferiscono a uno spazio immagine 1000×1000 relativo alle dimensioni di input.
Trascrizione audio: Dategli un MP3 e chiedete una trascrizione. L’E2B ha prodotto: “This week I traveled to Chicago to deliver my final farewell address to the nation following in the tradition of presidents before me It was an opportunity to say thank you whether we’ve seen eye to eye or rarely agreed at all…” Pulito, accurato, senza anomalie nella punteggiatura.
Comprensione video: L’E2B ha identificato correttamente l’esibizione di un concerto dal vivo dal video, inclusi l’ambientazione (festival all’aperto), i performer, l’allestimento del palco, e ha tentato di descrivere i testi, anche se ha allucinato alcuni dettagli audio. L’E4B ha gestito la cosa con maggiore accuratezza.
Didascalie immagini: “A medium shot captures a weathered seagull perched atop a stone pedestal in what appears to be a bustling European square, with a grand, classical-style building featuring ornate columns and architectural details dominating the right side of the frame.” Questo viene dal modello da 2,3B. Accurato, dettagliato, ben strutturato.
Function calling multimodale: Dategli un’immagine di un tempio tailandese e il prompt “Qual è la città in questa immagine? Controlla il meteo lì adesso” insieme alla definizione di uno strumento get_weather. L’E2B identifica correttamente Bangkok dallo stile architettonico, ragiona passo dopo passo sul suo approccio e genera la chiamata di funzione corretta: get_weather(city="Bangkok").
Deployment su Raspberry Pi 5
Il Raspberry Pi 5 ha varianti con 4GB o 8GB di RAM, un Broadcom BCM2712 quad-core Cortex-A76 a 2,4GHz e nessuna GPU in senso tradizionale. Eseguire un modello E2B quantizzato (Q4_K_M a ~3,5GB in memoria) sul Pi 5 da 8GB lascia abbastanza margine per il sistema operativo e una finestra di contesto ragionevole.
Google e NVIDIA puntano esplicitamente a questo deployment. Il Jetson AI Lab di NVIDIA fornisce container e tutorial per eseguire Gemma 4 E2B ed E4B su Jetson Orin Nano, che ha un profilo hardware comparabile al Pi 5 ma con una piccola GPU. Le caratteristiche architetturali che lo rendono possibile sono i Per-Layer Embeddings (che possono essere memorizzati in cache per caricamento più rapido e uso ridotto della memoria) e la KV cache condivisa (che riduce l’overhead di memoria per il contesto).
Le implicazioni per IoT, robotica e edge computing sono significative. Una telecamera di sicurezza con un Raspberry Pi può ora fare ragionamento multimodale sul proprio flusso video. Un hub per la casa intelligente può comprendere comandi vocali ed elaborare immagini dalle telecamere senza mai connettersi a internet. Un drone agricolo può classificare la salute delle colture da foto aeree usando il calcolo a bordo.
iPhone e Android: Google AI Edge Gallery
Quattro giorni dopo il lancio di Gemma 4, Google ha pubblicato Google AI Edge Gallery, un’app gratuita che esegue Gemma 4 E2B interamente sul vostro iPhone o telefono Android. Niente cloud. Niente API key. Niente account Google. Il modello si scarica una volta (~3,5GB) e gira in locale usando il runtime LiteRT-LM di Google.
L’app ha raggiunto 719 punti e 201 commenti su Hacker News in meno di 18 ore. E a buon motivo: non si limita a far girare un chatbot. Include le mobile actions, chiamate a strumenti che permettono al modello on-device di attivare funzioni native del telefono. Accendere la torcia, aprire Maps su una posizione, impostare un timer. Tutto deciso dal LLM, tutto eseguito localmente.
Le prestazioni sono sorprendentemente utilizzabili. I benchmark ufficiali di Google mostrano 56 token/s su iPhone e 52 tok/s su Qualcomm. I risultati della community variano per dispositivo: ~40 tok/s via MLX sugli iPhone recenti, 29 tok/s su un Samsung Galaxy S25 edge e ~12 tok/s su un iPhone 14 (chip A15 meno recente). Un utente ha costruito una demo in tempo reale audio/video-in e voce-out su un MacBook con l’E2B e ha stimato che la stessa pipeline potrebbe girare su un iPhone 17 Pro.
I primi tester su HN stanno già immaginando cosa questo rende possibile. Uno sviluppatore che costruisce app con privacy prioritaria per insegnanti lo ha descritto come esattamente ciò che gli serviva: IA locale che rispetta le severe normative sulla privacy scolastica senza che nessun dato lasci il dispositivo. Un altro ha segnalato che Apple starebbe lavorando con Google per integrare Gemma in una futura versione di Siri. L’autore originale del post ha riassunto: “Questo mi dà speranza per una futura Siri, in stile ‘Her’.”
L’app è disponibile anche su Android e fa parte della più ampia iniziativa AI Edge di Google. Attualmente gira sulla GPU, ma il supporto per NPU (il Neural Engine di Apple ha 35 TOPS contro i 7 TFLOPS della GPU) potrebbe portare un altro significativo salto in velocità.
Prima di provare: controllate canirun.ai
Prima di tentare di eseguire qualsiasi variante di Gemma 4 in locale, controllate canirun.ai. Il sito rileva la vostra GPU, VRAM, bandwidth di memoria, RAM e core CPU, poi mostra esattamente quali modelli e livelli di quantizzazione il vostro hardware può effettivamente eseguire. Elenca tutte le varianti Gemma con i requisiti di memoria a ogni livello di quantizzazione da Q2_K a F16.
Questo è particolarmente utile per Gemma 4 perché i requisiti di memoria variano enormemente all’interno della famiglia:
- E2B Q4_K_M: ~3,5GB (gira su un Raspberry Pi 5 da 8GB)
- E4B Q4_K_M: ~5GB (gira su telefoni con 8GB di RAM)
- 26B-A4B Q4_K_XL: ~14GB (sta su una GPU da 16GB con contesto limitato)
- 31B Q4_K_XL: ~18GB (necessita di una GPU da 24GB, contesto limitato)
- 31B BF16: ~62GB (necessita di una H100 da 80GB o equivalente)
La differenza tra “gira veloce” e “si impalla nello swap” può essere qualche centinaio di megabyte di VRAM. canirun.ai elimina il rischio. Raccomanda inoltre Ollama (versione 0.6+) come runtime predefinito e mostra i comandi esatti per iniziare.
Il MoE 26B-A4B: la variante veloce
Il modello 26B Mixture-of-Experts è il primo rilascio MoE di Gemma. Attiva solo 3,8 miliardi di parametri per token su 25,2B totali, usando 128 expert con 8 attivi più 1 expert condiviso per ogni forward pass. Ottiene 1441 su Arena AI, solo 11 punti dietro il denso 31B, piazzandosi al sesto posto tra i modelli open.
Il 26B è progettato per l’uso interattivo sensibile alla latenza. Su un MacBook Air M4 con 32GB di RAM, gli utenti riferiscono di eseguire la quantizzazione Q4_K_XL con 32K di contesto senza problemi. Un utente su HN ha fatto benchmark con una RX 7900 XTX da 24GB ottenendo risultati impressionanti:
llama-batched-bench -hf unsloth/gemma-4-26B-A4B-it-GGUF:UD-Q4_K_XL
| Context | TG tok/s |
|---------|-----------|
| 1K | 120.29 |
| 2K | 119.04 |
| 4K | 117.08 |
| 8K | 114.87 |
| 16K | 107.65 |
| 32K | 100.12 |
| 64K | 88.12 |
| 128K | 71.25 |Oltre 100 token/sec a 32K di contesto e 71 tok/s all’intero 128K su una singola GPU consumer. Abbastanza veloce per l’uso interattivo in tempo reale, anche con contesti molto lunghi. La velocità di elaborazione del prompt è ancora più impressionante: 2.650 token/sec a 2K di contesto, restando sopra i 960 tok/s anche all’intero 128K.
Sia i pesi non quantizzati bfloat16 del 31B che del 26B stanno su una singola NVIDIA H100 da 80GB. Le versioni quantizzate girano su GPU consumer dalla RTX 4060 in su.
Capacità multimodali: cosa funziona davvero
Il team di Hugging Face ha eseguito test approfonditi su tutte le modalità. Ecco un’analisi dettagliata di cosa funziona a ogni dimensione di modello.
Generazione HTML da screenshot
Hanno dato a ogni modello uno screenshot di una landing page chiedendo “Scrivi il codice HTML per questa pagina” con thinking abilitato e 4000 token massimi. Tutti e quattro i modelli hanno prodotto HTML funzionante. Le versioni 31B e 26B erano riproduzioni quasi pixel-perfect. Anche l’E2B ha prodotto un’approssimazione riconoscibile. Questo ha applicazioni ovvie per i workflow design-to-code e il testing UI automatizzato.
Comprensione video
I modelli più piccoli (E2B, E4B) elaborano il video con l’audio. I modelli più grandi elaborano solo i fotogrammi video (senza traccia audio). Nonostante non siano stati esplicitamente post-addestrati su dati video, tutti i modelli dimostrano comprensione video. L’E4B ha descritto correttamente la scena di un concerto, inclusi i temi lirici della canzone (“lotte e disillusione della vita moderna, in particolare la sensazione di essere bloccati”). Il 31B, lavorando senza audio, ha comunque descritto accuratamente la scena visiva, le azioni dei performer e l’allestimento del palco.
Function calling multimodale con thinking
È qui che Gemma 4 diventa interessante per chi costruisce agenti IA. Si possono definire strumenti, mostrare al modello un’immagine e chiedergli di usare gli strumenti in base a ciò che vede. La traccia del thinking mostra la catena di ragionamento del modello: “Analizzare l’immagine… identificare il punto di riferimento… determinare che la città è Bangkok… formulare la chiamata alla funzione.” Anche l’E2B segue questo schema, anche se il suo ragionamento è più prolisso.
Combinato con l’output JSON strutturato e le system instructions native, questo rende Gemma 4 una base pronta per la produzione per agenti multimodali. Il fatto che il function calling funzioni su un modello abbastanza piccolo da girare su un telefono significa che si possono costruire agenti che operano interamente offline.
Ecosistema di inferenza: supporto ovunque dal primo giorno
Una delle migliori notizie del lancio di Gemma 4 è l’ampiezza dell’integrazione dal primo giorno. Google ha chiaramente investito per assicurarsi che ogni motore di inferenza principale funzionasse al rilascio.
llama.cpp
Supporto immagine+testo dal primo giorno. Avviate un server compatibile OpenAI con un singolo comando:
llama-server -hf ggml-org/gemma-4-E2B-it-GGUFFunziona con LM Studio, Jan e agenti di coding come Pi. I checkpoint GGUF quantizzati sono disponibili sia da ggml-org ufficiale che da Unsloth. Le quantizzazioni “Dynamic 2.0” di Unsloth sono particolarmente interessanti: analizzano ogni layer e regolano selettivamente il tipo di quantizzazione per layer, usando un dataset di calibrazione curato a mano con oltre 1,5M di token. Gli utenti riferiscono che offrono una qualità migliore rispetto ai quant GGUF standard alla stessa ampiezza in bit.
Configurazioni per agenti di coding
Il blog di Hugging Face include file di configurazione completi per quattro agenti di coding:
- Hermes: basta eseguire
hermes modeldopo aver avviato il server llama.cpp - OpenClaw: eseguire
openclaw onboard - Pi: definire
~/.pi/agent/models.jsonpuntando alocalhost:8080/v1 - Open Code: definire
~/.config/opencode/opencode.jsoncon il provider compatibile OpenAI
Questo significa che potete trasformare il vostro laptop in un assistente di coding IA completamente locale. Nessuna chiave API, nessuna dipendenza dal cloud, nessun dato che lascia la vostra macchina. Combinato con la finestra di contesto da 256K sul 31B, potete passare interi repository in un singolo prompt.
MLX (Apple Silicon)
Supporto multimodale completo tramite mlx-vlm. La caratteristica degna di nota: TurboQuant, che offre la stessa accuratezza della baseline non compressa usando ~4 volte meno memoria attiva e girando significativamente più veloce end-to-end. Questo rende l’inferenza a contesto lungo pratica sui Mac senza sacrificare la qualità:
mlx_vlm.generate
--model "mlx-community/gemma-4-26B-A4B-it"
--prompt "Your prompt here"
--kv-bits 3.5
--kv-quant-scheme turboquanttransformers (Python)
La nuova classe AutoModelForMultimodalLM e la pipeline any-to-any rendono l’inferenza immediata. Il chat template integrato gestisce la formattazione, la modalità thinking, l’estrazione audio dal video e le definizioni degli strumenti. Questo è il percorso per il fine-tuning con TRL, PEFT e bitsandbytes.
WebGPU
L’E2B gira nel browser tramite transformers.js. Hugging Face ha rilasciato una demo funzionante. Questo apre pattern di deployment completamente nuovi: applicazioni IA che girano lato client con zero infrastruttura backend.
Infrastruttura NVIDIA
NVIDIA ha pubblicato guide al deployment per tutto il proprio stack hardware:
- DGX Spark: GB10 Grace Blackwell Superchip con 128GB di memoria unificata. Esegue il 31B in BF16 nativamente. Include ricette NeMo Automodel per il fine-tuning.
- Jetson Orin Nano: E2B ed E4B per robotica e IA edge. Container disponibili presso il Jetson AI Lab.
- GPU RTX: inferenza quantizzata tramite Ollama e llama.cpp. Gli utenti RTX Pro possono usare anche vLLM.
- NVIDIA NIM: microservizi pre-confezionati e ottimizzati per il deployment in produzione. API gratuita disponibile per la prototipazione su build.nvidia.com.
- NVFP4: checkpoint quantizzato a 4-bit per GPU Blackwell usando NVIDIA Model Optimizer. Precisione a 4-bit con accuratezza quasi identica agli 8-bit.
Fine-tuning: disponibile dal primo giorno, con qualche intoppo
Il supporto al fine-tuning esiste ma ha avuto un lancio accidentato. Diversi early adopter hanno segnalato problemi entro poche ore:
- HuggingFace Transformers non riconosceva inizialmente l’architettura
gemma4. Richiedeva l’installazione da sorgente. - PEFT non gestiva
Gemma4ClippableLinear, un nuovo tipo di layer nel vision encoder. Richiedeva un monkey-patch. - Un nuovo campo
mm_token_type_idsè richiesto durante il training anche per dati di solo testo. Richiedeva un data collator personalizzato.
Tutti e tre i problemi hanno avuto bug report e risposte entro poche ore. Unsloth Studio ha fornito supporto al fine-tuning dal primo giorno con una UI che gestisce questi casi particolari. Il team TRL di HuggingFace ha anche rilasciato una demo notevole: addestrare Gemma 4 a guidare nel simulatore di guida CARLA, dove il modello vede la strada attraverso una telecamera, decide le azioni e impara dai risultati. Dopo il training, cambia costantemente corsia per evitare i pedoni.
Per il fine-tuning in produzione, NVIDIA NeMo Automodel fornisce ricette per il supervised fine-tuning (SFT) e LoRA efficiente in memoria direttamente dai checkpoint HuggingFace, senza necessità di conversione del formato.
Cosa significa per Qwen, Llama e il paradigma “più grande è meglio”
Il panorama dei modelli open a inizio aprile 2026 presenta un quadro di efficienza netto. Ecco i migliori modelli open per punteggio Arena AI:
- GLM-5 (Z.ai): 1452, ~750B parametri, MIT
- Kimi-K2.5-Thinking (Moonshot): 1451, ~1T+ parametri, Modified MIT
- Gemma 4 31B (Google): 1452, 31B denso, Apache 2.0
- Qwen 3.5-397B-A17B (Alibaba): 1450, 397B MoE (17B attivi), Apache 2.0
- Qwen 3-235B-A22B-Instruct: 1418, 235B MoE (22B attivi), Apache 2.0
- DeepSeek-R1-0528: 1426, dimensione sconosciuta, MIT
Gemma 4 31B eguaglia o batte ognuno di loro con 10-30 volte meno parametri totali. Le implicazioni si propagano attraverso ogni livello dello stack IA.
Costo di servizio e infrastruttura
Servire un modello denso da 31B costa una frazione rispetto a un MoE da 397B. Meno VRAM, meno banda, meno elettricità, meno soldi per token. Il 31B sta su una singola H100 in BF16; un modello da 397B necessita di un setup multi-GPU anche con quantizzazione. Per le aziende che fanno deployment su larga scala, questa è potenzialmente la differenza tra un modello di business sostenibile e uno in perdita.
Questo è particolarmente rilevante man mano che la curva dei costi per l’inferenza di frontiera riceve maggiore attenzione. Se due modelli producono output di qualità equivalente, quello 13 volte più piccolo vince sull’economia unitaria ogni volta.
Accessibilità del fine-tuning
Si può fare fine-tuning di un modello da 31B con LoRA su una singola GPU consumer (24GB di VRAM sono sufficienti per Q4 + LoRA). Il fine-tuning di un MoE da 397B richiede un cluster multi-GPU con centinaia di gigabyte di VRAM aggregata. Questa non è solo una differenza di costo; è una differenza di accessibilità. Ricercatori universitari, startup senza cluster GPU e sviluppatori individuali possono ora fare fine-tuning di un modello di qualità frontier sulla propria workstation. Con i modelli più grandi non era possibile.
Deployment edge
Nessun modello MoE con 397B parametri totali gira su un telefono. Punto. Anche con solo 17B parametri attivi, il modello da 397B ha bisogno di tutti i pesi degli expert caricati (o frequentemente swappati) in memoria. L’E2B di Gemma 4 gira su un telefono, un Raspberry Pi, un Jetson Nano e nel browser. L’E4B gira su qualsiasi laptop di fascia media. Il 26B MoE gira su una GPU da gaming. Il 31B denso gira su una workstation.
Questa diversità di dimensioni significa che una singola famiglia di modelli può servire ogni livello di deployment, dal cloud all’edge, con comportamento coerente e compatibilità di fine-tuning.
Il controargomento della velocità
Gemma 4 non è privo di punti deboli. I benchmark della community rivelano gap di prestazioni significativi rispetto a Qwen 3.5:
- Velocità di generazione token: un utente ha misurato 11 tok/s per Gemma 4 26B-A4B contro 60+ tok/s per Qwen 3.5 35B-A3B sulla stessa RTX 5060 Ti 16GB. Il denso 31B raggiunge 18-25 tok/s su GPU NVIDIA doppie. Ragionevole ma non veloce.
- VRAM per il contesto: un test ha mostrato che Gemma 4 27B Q4 entra solo con 20K di contesto su una 5090, mentre Qwen 3.5 27B Q4 ne supporta 190K sulla stessa scheda. La KV cache è più esigente.
- Efficienza computazionale complessiva: Qwen 3.5-397B attiva solo 17B parametri per token (il 45% dei 31B di Gemma 4). A qualità equivalente, Qwen 3.5 fa meno calcolo per token.
Sono problemi reali per i deployment in produzione dove latenza e throughput contano. Il modello MoE di Gemma 4 (26B-A4B) affronta teoricamente il problema computazionale attivando solo 3,8B parametri, ma la velocità di inferenza attuale non riflette quel vantaggio nella pratica.
Possibili spiegazioni: supporto alla quantizzazione ancora immaturo (i modelli QAT non sono ancora stati rilasciati), le ottimizzazioni dei motori di inferenza non si sono ancora adeguate alla nuova architettura, oppure la KV cache condivisa e PLE aggiungono overhead che compensa la riduzione dei parametri. I parametri di sampling raccomandati da Google (temperature 1.0, top_p 0.95, top_k 64) potrebbero anche influire sul throughput.
L’argomento della traiettoria
I problemi di velocità e VRAM tendono a migliorare col tempo. I modelli con quantization-aware training (QAT) sono arrivati settimane dopo Gemma 3 e hanno migliorato drasticamente la qualità dell’inferenza quantizzata. L’ecosistema dei motori di inferenza (llama.cpp, vLLM, SGLang) ottimizza costantemente per i modelli popolari. Le ottimizzazioni specifiche per l’architettura della KV cache condivisa e PLE sono presumibilmente in corso.
Ciò che è più difficile da correggere è l’intelligenza grezza per parametro. Se la ricetta di addestramento di Google riesce a estrarre prestazioni da 1452-ELO da 31B parametri oggi, la domanda diventa: cosa succede quando applicano la stessa ricetta a 100B parametri? O 200B? L’estrapolazione lineare è scomoda per ogni altro laboratorio nella corsa ai modelli open.
Il verdetto della community dopo 24 ore
Il thread su Hacker News ha raggiunto 1.678 punti e 445 commenti in un giorno. Ecco le opinioni più significative.
Gli entusiasti
Daniel Hanchen (fondatore di Unsloth), che lavora a stretto contatto con ogni grande laboratorio di modelli, ha definito Gemma 4 “sooooo good!!!” e ha detto che Google è “senza dubbio” il laboratorio più collaborativo con cui lavorare, seguito da Qwen, Meta e Mistral. Alla domanda su quale modello open source sia il migliore, ha risposto: “Tbh Gemma-4 haha.”
Un utente che fa OCR, ricerca full-text, embedding e riassunti di documenti catastali del 1800 in locale ha descritto l’impatto: “Le persone sono così entusiaste di poter cercare nei documenti in più lingue che un minuto di attesa per elaborare il documento sembra niente.” Stava usando modelli Qwen della generazione precedente; aveva intenzione di passare immediatamente a Gemma 4.
Un altro utente che testava la generazione di codice Nix ha trovato Gemma 4 26B-A4B “significativamente migliore di qwen3.5-35b-a3b” e ha condiviso la propria configurazione llama-cli per un MacBook Air M4 32GB.
Gli scettici
Un commentatore di Hugging Face l’ha definito un “rilascio un po’ deludente” e avrebbe voluto che “le grandi aziende tech prendessero esempio da OpenAI e rilasciassero modelli OSS davvero competitivi.” Ha aggiunto: “Ma i modelli sono stabili. Sicuramente più consistenti e con migliore efficienza dei token rispetto a Qwen.”
Diversi utenti hanno notato il gap nella velocità di inferenza e si sono chiesti se i punteggi Arena AI raccontino tutta la storia. Un’analisi su dev.to ha concluso: “Per deployment solo in inglese, ottimizzati per i benchmark e critici sulla velocità, Qwen 3.5 è ancora la scelta migliore.”
I modelli mancanti
Diversi commentatori hanno espresso delusione per ciò che non è stato rilasciato:
- Nessun modello denso da 9-12B. Il 12B di Gemma 3 era popolare e non c’è un percorso di upgrade diretto. Il divario tra l’E4B (4,5B effettivi) e il 26B MoE è troppo ampio per molti casi d’uso.
- Nessun modello da 100B+. Circolavano voci su un 120B che non si è materializzato. Diversi utenti hanno notato che sarebbe stato rivoluzionario data le prestazioni del 31B.
- Nessun modello QAT al lancio. Le varianti QAT di Gemma 3 hanno migliorato significativamente la qualità dell’inferenza quantizzata. La community se le aspetta per Gemma 4 ma non sono ancora disponibili.
Casi d’uso reali emergenti
Entro 24 ore, le persone stavano già facendo deployment di Gemma 4 per:
- OCR e traduzione di documenti storici (documenti catastali del 1800, multilingue)
- Analisi PDF in locale con automazione dei workflow n8n e Ollama
- Generazione di codice come assistente di coding locale (Nix, Python, uso generico)
- Piattaforme educative per bambini (un utente ha detto “questo si adatta esattamente al nostro dominio di educazione per bambini”)
- Elaborazione di documenti sensibili per la privacy dove le API cloud richiedono la redazione
- Analisi finanziaria (un utente ha riportato che l’E2B dà “risposte significativamente migliori di Qwen 3.5 4B” per la finanza)
Cosa viene dopo
La community sta aspettando diverse cose che determineranno se Gemma 4 consolida la sua posizione o viene superato:
Modelli QAT (quantization-aware training): sono arrivati settimane dopo Gemma 3 e hanno migliorato drasticamente l’inferenza quantizzata. L’E2B e l’E4B ne beneficeranno di più, dato che i dispositivi edge si basano interamente sull’inferenza quantizzata. Attesi entro giorni o settimane.
Ottimizzazioni dei motori di inferenza: l’attuale gap di velocità rispetto a Qwen 3.5 potrebbe ridursi man mano che llama.cpp, vLLM e altri motori aggiungono ottimizzazioni specifiche per l’architettura della KV cache condivisa, PLE e routing MoE.
Un modello denso da 9-12B: colmerebbe il più grande vuoto nella lineup e darebbe agli utenti di Gemma 3 12B un percorso di upgrade diretto.
Varianti abliterated: ora pienamente legali sotto Apache 2.0. Almeno una esiste già. Altre seguiranno man mano che i ricercatori sulla sicurezza e le community di modelli senza censura lavoreranno sull’architettura.
La domanda più grande: se Google riesce a eguagliare modelli MoE da 400B con un modello denso da 31B, come sarà la prossima generazione? Un Gemma 5 da 100B che usa questa ricetta di addestramento potrebbe potenzialmente eguagliare modelli proprietari di frontiera come Gemini 3 Pro (Arena 1492) o Claude Opus 4.6 (Arena 1490). Sarebbe la prima volta che un modello open compete davvero con le migliori offerte proprietarie.
In conclusione
Gemma 4 è il modello open con la più alta intelligenza per parametro mai rilasciato. Il modello denso da 31B pareggia nella classifica Arena AI con modelli 10-30 volte più grandi. L’E2B porta l’IA multimodale su un Raspberry Pi da 80 dollari. L’intera famiglia è Apache 2.0, il che significa nessuna trappola legale per l’uso commerciale.
Non è perfetto. La velocità di inferenza è inferiore a Qwen 3.5. Il consumo di VRAM per il contesto è peggiore. Gli strumenti di fine-tuning hanno avuto bisogno di patch al lancio. Non c’è un modello da 9-12B nella lineup.
Ma la traiettoria è chiara. La corsa ai modelli open si è appena spostata da “chi riesce ad addestrare più parametri” a “chi riesce a estrarre più intelligenza per parametro.” Google, attingendo alla stessa ricerca di Gemini 3 che alimenta i propri modelli proprietari, sembra stare vincendo quella corsa in modo convincente.
Per gli sviluppatori, il risvolto pratico: ora potete eseguire un modello IA multimodale di qualità frontier sul vostro laptop, sul vostro telefono o su un computer a scheda singola da 80 dollari. Comprende immagini, audio, video e 140 lingue. Può chiamare funzioni, ragionare su problemi a più passaggi e generare codice di qualità produzione. È gratuito, è aperto ed è Apache 2.0.
Questa combinazione non esisteva 48 ore fa.
The user wants me to translate a long HTML blog post from English to Italian, keeping all HTML tags intact, not translating brand names, technical terms, benchmark names, etc. Let me produce the translation directly.