Contexte technique
Je me suis plongé dans l'annonce de Google non pas pour la formule accrocheuse sur l'efficacité, sondern parce que ces avancées impactent directement l'AI automation en production. S'il est possible de compresser un modèle sans dégradation notable, des scénarios auparavant bloqués par la VRAM, la latence et le coût du matériel deviennent soudainement réalisables.
Le fond de l'histoire est simple : Google a mis en ligne des checkpoints QAT officiels pour Gemma 4. Le QAT (Quantization-Aware Training) se distingue de la quantification post-entraînement classique (PTQ) par le fait que le modèle, dès sa phase d'apprentissage, intègre et s'adapte à la future perte de précision.
Et c'est un point crucial. Après une PTQ classique, je constate souvent le même problème : le modèle est certes plus léger, mais commence à perdre pied sur les requêtes complexes. Avec le QAT, les chances de préserver la qualité sont bien supérieures, car le compromis est anticipé lors de l'entraînement, et non ajouté à la va-vite à la fin.
Google propose au moins deux versions : des checkpoints Q4_0 et un format mobile. Pour vLLM, c'est très pratique : la quantification est directement prise en compte à partir du checkpoint, sans avoir besoin de manipulations complexes dans la configuration.
Côté chiffres, le plus impressionnant reste ceci : Gemma 4 31B en QAT W4A16 peut passer de 59 Go à environ 19,8 Go. Cela représente une économie de mémoire d'environ 66 %. Avec de telles statistiques, je ne vois plus cela comme 'une simple mise à jour pour développeurs'.
La version mobile n'est pas non plus un simple gadget. Google met particulièrement l'accent sur les activations statiques et une quantification sélective à 2 bits des couches de décodage, avec une empreinte mémoire annoncée d'environ 1 Go pour Gemma 4 E2B. Pour les architectures edge, cela devient une option d'ingénierie tout à fait viable.
Impact sur les entreprises et l'automatisation
Les grands gagnants sont ceux qui souhaitent rapprocher l'inférence de l'utilisateur final : applications mobiles, copilotes on-device, assistants locaux et scénarios soucieux de la confidentialité. Les perdants, comme d'habitude, restent les pipelines paresseux où le modèle est choisi uniquement sur benchmark, en remettant le déploiement réel à plus tard.
En pratique, cela apporte trois avantages : des besoins en mémoire réduits, une infrastructure moins coûteuse et une AI implementation simplifiée là où il fallait auparavant soit amputer des fonctionnalités, soit tout envoyer dans le cloud.
Cependant, je ne présenterais pas cela comme une solution miracle pour remplacer toutes les configurations FP16 et BF16. Il faut étudier attentivement l'architecture, la longueur de contexte, le KV cache, le type de charge de travail et le comportement du modèle une fois intégré au produit. Chez Nahornyi AI Lab, nous résolvons ces problématiques de manière pragmatique et concrète, pas seulement sur des diapositives.
Si la mémoire, la latence ou le coût du matériel freinent le déploiement de votre modèle local, c'est le moment idéal pour repenser votre AI architecture pour des besoins réels. Analysons ensemble votre cas d'usage afin d'orienter l'AI solution development pour que votre modèle apporte une valeur tangible sans faire exploser vos coûts de serveurs.