Passare da Gemma 2 a Gemma 3: insidie e verifiche

#Cosa cambia davvero tra Gemma 2 e Gemma 3

Tre cambiamenti strutturali influiscono su un’applicazione esistente: il contesto massimo, la struttura dei messaggi inviati al modello e la presenza di un input immagine. Cambiare semplicemente il nome del modello nel tuo codice (da gemma2 a gemma3) non basta a garantire un comportamento identico, anche se il formato di output rimane testo.

Gemma 2 esisteva solo con 9 e 27 miliardi di parametri. Gemma 3 aggiunge un 1B e un 4B, e ridefinisce il contesto per ogni dimensione: non si tratta semplicemente di «più grande», ma di un'architettura diversa internamente. Se la vostra scelta di dimensione del modello era basata sulle limitazioni di Gemma 2, merita di essere riconsiderata piuttosto che ripetuta identicamente.

#Dimensioni e contesto: il vero salto

Gemma 2 ha un contesto fisso di 8.192 token, indipendentemente dalle dimensioni del modello. Gemma 3 estende questo contesto a 32.768 token per il modello da 1B e a 131.072 token per quelli da 4B, 12B e 27B: un fattore 16 per i modelli medi e grandi. È il dato più utile per dimensionare un uso RAG o una lunga cronologia di conversazione, ma questo contesto dichiarato è un limite massimo del modello, non la memoria effettivamente allocata dal tuo runtime: Ollama e i server di inferenza limitano spesso il contesto predefinito a un valore molto più basso (spesso 4096 o 8192 token), finché non lo si aumenta esplicitamente.

#Chat template: l'insidia più comune

La causa più frequente del peggioramento delle risposte dopo una migrazione non è la qualità del modello, ma un template di chat applicato male. Ogni famiglia di modelli richiede una formattazione precisa dei turni di conversazione (tag di inizio/fine turno, posizione del prompt di sistema). Se la tua applicazione costruisce autonomamente il prompt finale anziché lasciare che il runtime applichi il template del modello, un template rimasto configurato per Gemma 2 produce risposte troncate, fuori tema o che continuano a essere generate oltre il punto di fine previsto.

1. 01
   Identificare chi costruisce il prompt

   Verificare se il tuo codice assembla autonomamente il testo inviato al modello o passa attraverso l'API chat del runtime (Ollama /api/chat, server llama.cpp), che applica automaticamente il template corretto.
2. 02
   Confrontare i template

   Recuperare il file di template integrato nel modello Gemma 3 utilizzato (GGUF o Hugging Face) e confrontarlo con quello di Gemma 2 utilizzato finora, anziché supporre che siano identici.
3. 03
   Eseguire di nuovo un set di prompt di riferimento

   Eseguire gli stessi 10–20 prompt di test su Gemma 2 e poi su Gemma 3 con il nuovo template, e confrontare la lunghezza, la pertinenza e la presenza di una terminazione corretta della generazione.

Il ruolo di sistema illustra bene questa insidia. Presentando Gemma 4, Google indica che questa nuova famiglia «utilizza i ruoli standard system, assistant e user, a differenza di Gemma 3»: una conferma ufficiale del fatto che Gemma 3 (come Gemma 2) non gestisce il prompt di sistema esattamente come i runtime che espongono un ruolo system nativo. In pratica, il codice che invia un messaggio separato con ruolo system basandosi sulle convenzioni di altre famiglie di modelli deve verificare, nello specifico per Gemma 3, come il runtime utilizzato tratta quel messaggio, anziché presumere che sia isolato.

#Multimodalità: 4B, 12B e 27B accettano immagini

A differenza di Gemma 2, che elabora esclusivamente testo, i modelli Gemma 3 4B, 12B e 27B integrano un encoder di immagini SigLIP che elabora immagini ridimensionate a 896×896 pixel; solo il modello 1B rimane esclusivamente testuale. In pratica, se la tua applicazione passa a un 12B o a un 27B, acquisisce la capacità di ricevere immagini in ingresso anche se non la utilizza: ciò modifica il formato dell'API atteso da alcuni runtime (un campo per le immagini oltre al testo) e può aumentare leggermente la memoria necessaria al caricamento, anche senza inviare immagini.

Questo passaggio al multimodale ha una conseguenza pratica spesso dimenticata durante la migrazione: una pipeline che validava rigorosamente il formato dei messaggi in ingresso (schema JSON, tipizzazione rigorosa) può rifiutare o interpretare male un campo immagine assente o vuoto se il client API del nuovo modello lo aggiunge per impostazione predefinita. Al contrario, una pipeline che filtrava già gli input non testuali prima della chiamata al modello non deve cambiare nulla: la capacità di elaborare immagini di Gemma 3 rimane inattiva finché non viene trasmessa alcuna immagine e non viene mai imposta.

#Quantizzazione QAT: memoria divisa per un fattore da 3 a 4

Google pubblica checkpoint di Gemma 3 addestrati tenendo conto della quantizzazione (QAT), oltre alle versioni Q4_0 classiche per Ollama, llama.cpp e MLX. Il vantaggio: una perdita di qualità nettamente inferiore rispetto a una quantizzazione applicata a posteriori a un modello non preparato a questo scopo.

Questi numeri sono quelli pubblicati da Google al lancio dei checkpoint QAT; descrivono la memoria necessaria per caricare i pesi, non la memoria totale utilizzata durante la generazione (a questa si aggiungono il contesto e la cache KV). Una misurazione sulla tua macchina resta l'unico modo per confermare un valore per il tuo caso d'uso.

Il metodo adottato da Google applica circa 5.000 passi di quantization aware training utilizzando le probabilità del modello non quantizzato come obiettivo, riducendo così il calo della perplessità del 54% rispetto a una quantizzazione applicata a posteriori a un modello non preparato a tale scopo. Per un'applicazione migrata da Gemma 2, ciò significa che lo stesso livello di quantizzazione (ad esempio Q4) su Gemma 3 produce generalmente un risultato più vicino al modello a piena precisione rispetto a quello prodotto da Gemma 2 quantizzato in modo classico — un vantaggio che deriva dalla preparazione del modello, non da un'impostazione da modificare da parte dell'utente.

#Passare a Gemma 3 o aspettare Gemma 4?

Gemma 4 è già disponibile su Ollama al momento della stesura di questa guida, il che pone una vera domanda a chi sta ancora migrando da Gemma 2: conviene fermarsi a Gemma 3 o puntare direttamente alla generazione successiva? La scheda Ollama di Gemma 4 annuncia taglie diverse da quelle di Gemma 3 (varianti E2B e E4B con un numero ridotto di parametri effettivi, un modello 12B, una variante MoE 26B con 3,8 miliardi di parametri attivi e un modello denso 31B), pensate per il ragionamento, i workflow agentici e il codice: un ambito più ampio della sola sostituzione di Gemma 2.

Per un’applicazione già in produzione con Gemma 2, questa guida resta incentrata sulla migrazione a Gemma 3: le verifiche di contesto, template e regressione descritte qui si applicano allo stesso modo se il modello di destinazione finale è Gemma 4, ma il passaggio diretto comporta più cambiamenti (ruoli di chat standard, nuove dimensioni, architettura MoE sulla variante 26B) rispetto a una migrazione Gemma 2 → Gemma 3. Una guida dedicata descrive in dettaglio l’installazione e le prestazioni di Gemma 4 in locale.

#Checklist prima di passare in produzione

Versione del runtime

Verificare che Ollama, llama.cpp o MLX supportino la versione di Gemma 3 desiderata (supporto aggiunto dopo l'uscita del modello, non sempre immediato su una versione precedente del runtime).

Contesto effettivamente configurato

Non lasciare al caso il valore del contesto del server: impostarlo esplicitamente in base alle tue esigenze reali, non al limite massimo del modello.

Formato delle immagini in ingresso

Se passi a 4B, 12B o 27B, verificare che il tuo client API non invii un formato di immagine incompatibile con il nuovo endpoint.

Scelta della quantizzazione

Confrontare un GGUF Q4_K_M classico e un checkpoint QAT ufficiale sui tuoi prompt prima di rendere definitiva la scelta: entrambi sono disponibili per Gemma 3.

Finestra di rollback

Mantenere disponibili il modello Gemma 2 e la sua configurazione durante la fase di transizione, fino a confermare l'assenza di regressioni.

#Rilevare una regressione sui tuoi prompt

Una migrazione di modello non si convalida sulla base di un'impressione dopo due o tre domande. Un insieme di prompt di riferimento, rappresentativo dell'uso reale dell'applicazione ed eseguito in modo identico sul vecchio e sul nuovo modello, è l'unico modo per individuare una regressione silenziosa: una risposta più lunga ma meno precisa, la perdita di un formato di output atteso (JSON, elenco) o una deriva del tono. Conservare questi output di riferimento permette anche di documentare la decisione di migrazione anziché basarsi su un'impressione.

#Prevedere la possibilità di tornare indietro

Lo scenario più sicuro per un'applicazione in produzione consiste nel distribuire Gemma 3 in parallelo con Gemma 2 (con un nome di modello distinto nel runtime), nell'instradare parte del traffico verso la nuova versione e nel disattivare quella precedente solo quando le misure di qualità sui tuoi prompt di riferimento sono almeno equivalenti. Questo richiede un po' di spazio su disco e di RAM durante la transizione, ma evita un'interruzione del servizio se il nuovo template di chat o il nuovo contesto produce un comportamento imprevisto in condizioni reali.

• Installa Gemma 3 localmente passo passo
• Capire i formati GGUF e safetensors
• Confronta l'IA locale e ChatGPT
• Gemma 4 in locale: installazione, VRAM e prestazioni
• Scegliere la quantizzazione (Q4, Q5, Q8, FP16)
• Quantizzare la cache KV per risparmiare VRAM con contesti lunghi
• Fonte: presentazione ufficiale di Gemma 3 (Hugging Face)
• Fonte: checkpoint QAT Gemma 3 (Google Developers Blog)
• Fonte: presentazione ufficiale di Gemma 2 (Hugging Face)
• Fonte: scheda Gemma 4 su Ollama