Migrer de Gemma 2 à Gemma 3 : pièges et vérifications

#Ce qui change vraiment entre Gemma 2 et Gemma 3

Trois changements structurels affectent une application existante : le contexte maximal, la structure des messages envoyés au modèle et la présence d'une entrée image. Un simple changement de nom de modèle dans votre code (gemma2 vers gemma3) ne suffit pas à garantir un comportement identique, même si le format de sortie reste du texte.

Gemma 2 n'existait qu'en 9 et 27 milliards de paramètres. Gemma 3 ajoute un 1B et un 4B, et redéfinit le contexte de chaque taille : ce n'est pas seulement « plus grand », c'est une architecture différente en interne. Si votre choix de taille de modèle était calé sur les contraintes de Gemma 2, il mérite d'être reconsidéré plutôt que reconduit à l'identique.

#Tailles et contexte : le vrai saut

Gemma 2 a un contexte fixe de 8 192 tokens, quelle que soit la taille du modèle. Gemma 3 porte ce contexte à 32 768 tokens pour le 1B et à 131 072 tokens pour les 4B, 12B et 27B : un facteur 16 pour les tailles moyennes et grandes. C'est la donnée la plus utile pour dimensionner un usage RAG ou un long historique de conversation, mais ce contexte annoncé est un plafond du modèle, pas la mémoire réellement allouée par votre runtime : Ollama et les serveurs d'inférence limitent souvent le contexte par défaut à une valeur bien plus basse (souvent 4096 ou 8192 tokens) tant qu'on ne l'augmente pas explicitement.

#Chat template : le piège le plus fréquent

La cause la plus fréquente de réponses dégradées après une migration n'est pas la qualité du modèle, mais un chat template mal appliqué. Chaque famille de modèle attend une mise en forme précise des tours de conversation (balises de début/fin de tour, position du prompt système). Si votre application construit elle-même le prompt final plutôt que de laisser le runtime appliquer le template du modèle, un template resté calé sur Gemma 2 produit des réponses tronquées, hors sujet ou qui continuent à générer après la fin attendue.

1. 01
   Identifier qui construit le prompt

   Vérifier si votre code assemble lui-même le texte envoyé au modèle ou s'il passe par l'API chat du runtime (Ollama /api/chat, llama.cpp server), qui applique automatiquement le bon template.
2. 02
   Comparer les templates

   Récupérer le fichier de template embarqué dans le modèle Gemma 3 utilisé (GGUF ou Hugging Face) et le comparer à celui de Gemma 2 utilisé jusqu'ici, plutôt que de supposer qu'ils sont identiques.
3. 03
   Rejouer un jeu de prompts de référence

   Passer les mêmes 10 à 20 prompts de test sur Gemma 2 puis Gemma 3 avec le nouveau template, et comparer la longueur, la pertinence et la présence d'une fin de génération propre.

#Multimodalité : 4B, 12B et 27B acceptent des images

Contrairement à Gemma 2, entièrement texte, les modèles Gemma 3 4B, 12B et 27B intègrent un encodeur d'images SigLIP qui traite des images redimensionnées en 896×896 pixels ; seul le 1B reste texte seul. Concrètement, si votre application migre vers un 12B ou un 27B, elle hérite d'une capacité d'entrée image même si elle ne l'utilise pas : cela change le format d'API attendu par certains runtimes (champ image en plus du texte) et peut légèrement augmenter la mémoire nécessaire au chargement, même sans image envoyée.

Cette bascule vers le multimodal a une conséquence pratique souvent oubliée en migration : un pipeline qui validait strictement le format des messages entrants (schéma JSON, typage strict) peut rejeter ou mal interpréter un champ image absent ou vide si le client API du nouveau modèle l'ajoute par défaut. À l'inverse, un pipeline qui filtrait déjà les entrées non textuelles avant l'appel au modèle n'a rien à changer : la capacité image de Gemma 3 reste inactive tant qu'aucune image n'est transmise, elle n'est jamais imposée.

#Quantification QAT : mémoire divisée par 3 à 4

Google publie des checkpoints Gemma 3 entraînés avec prise en compte de la quantification (QAT), en plus des versions Q4_0 classiques pour Ollama, llama.cpp et MLX. L'intérêt : une perte de qualité nettement plus faible qu'une quantification appliquée après coup sur un modèle non préparé pour ça.

Ces chiffres sont ceux publiés par Google au lancement des checkpoints QAT ; ils décrivent la mémoire nécessaire pour charger les poids, pas la mémoire totale utilisée en génération (le contexte et le KV cache s'ajoutent). Une mesure sur votre propre machine reste le seul moyen de confirmer un chiffre pour votre cas d'usage.

La méthode retenue par Google applique environ 5 000 pas de quantization aware training en utilisant les probabilités du modèle non quantifié comme cible, ce qui réduit la chute de perplexité de 54 % par rapport à une quantification appliquée après coup sur un modèle qui n'a pas été préparé pour ça. Pour une application migrée depuis Gemma 2, cela veut dire qu'un même niveau de quantification (par exemple Q4) donne, sur Gemma 3, un résultat généralement plus proche du modèle en pleine précision que ce que produisait Gemma 2 quantifié de façon classique — un gain qui vient de la préparation du modèle, pas d'un réglage à faire côté utilisateur.

#Checklist avant de basculer en production

Version du runtime

Vérifier que Ollama, llama.cpp ou MLX supportent la version de Gemma 3 visée (support ajouté après la sortie du modèle, pas toujours immédiat sur une version ancienne du runtime).

Contexte réellement configuré

Ne pas confier au hasard la valeur de contexte du serveur : la régler explicitement selon vos besoins réels, pas selon le plafond du modèle.

Format d'entrée image

Si vous migrez vers 4B, 12B ou 27B, vérifier que votre client API n'envoie pas un format d'image incompatible avec le nouvel endpoint.

Choix de la quantification

Comparer un GGUF Q4_K_M classique et un checkpoint QAT officiel sur vos propres prompts avant de figer un choix, les deux existent pour Gemma 3.

Fenêtre de rollback

Garder le modèle Gemma 2 et sa configuration disponibles pendant la phase de bascule, le temps de confirmer l'absence de régression.

#Détecter une régression sur vos prompts

Une migration de modèle ne se valide pas sur un ressenti après deux ou trois questions. Un jeu de prompts de référence, représentatif de l'usage réel de l'application, rejoué à l'identique sur l'ancien et le nouveau modèle, est le seul moyen de repérer une régression silencieuse : réponse plus longue mais moins précise, perte d'un format de sortie attendu (JSON, liste), ou dérive de ton. Conserver ces sorties de référence permet aussi de documenter la décision de migration plutôt que de s'appuyer sur une impression.

#Prévoir un retour arrière

Le scénario le plus sûr pour une application en production consiste à déployer Gemma 3 en parallèle de Gemma 2 (nom de modèle distinct dans le runtime), à router une partie du trafic vers la nouvelle version, et à ne couper l'ancienne que lorsque les mesures de qualité sur vos prompts de référence sont au moins équivalentes. Cela coûte un peu de mémoire disque et de RAM le temps de la transition, mais évite une coupure de service si le nouveau chat template ou le nouveau contexte produit un comportement inattendu en conditions réelles.

• Installer Gemma 3 en local pas à pas
• Comprendre les formats GGUF et safetensors
• Comparer IA locale et ChatGPT
• Source : présentation officielle de Gemma 3 (Hugging Face)
• Source : checkpoints QAT Gemma 3 (Google Developers Blog)
• Source : présentation officielle de Gemma 2 (Hugging Face)