Modèles Gemma 4 QAT : optimisation de la compression pour l’efficacité sur mobile et ordinateur portable

• Les checkpoints d’entraînement sensible à la quantification (QAT) de Gemma 4 optimisent les besoins mémoire et les performances on-device afin de faciliter une exécution locale sur les appareils edge du quotidien et les GPU grand public
• Le QAT simule la quantification pendant l’entraînement afin de réduire la perte de qualité lors de la compression, et produit une qualité globale supérieure à la référence PTQ standard
• Les checkpoints publiés ciblent le format Q4_0 et un format spécialisé pour le mobile, ce dernier ramenant l’empreinte mémoire de Gemma 4 E2B à 1 Go
• Le schéma mobile réduit la charge de travail et l’usage de mémoire active des puces mobiles grâce aux activations statiques, à la quantification par canal, à la quantification sélective en 2 bits, ainsi qu’aux optimisations des embeddings et du cache KV
• La prise en charge de Hugging Face, llama.cpp, Ollama, LM Studio, LiteRT-LM, Transformers.js, SGLang, vLLM, MLX et Unsloth permet l’exécution locale, le déploiement on-device et le fine-tuning

---

Contexte de la publication et périmètre

• Deux mois après la sortie de Gemma 4, Google publie des checkpoints QAT après Multi-Token Prediction (MTP) pour l’accélération de l’inférence et un modèle 12B venant combler l’écart entre les modèles MOE E4B et 26B
• Ces nouveaux checkpoints s’inscrivent dans un effort d’optimisation visant à permettre l’exécution locale de Gemma 4 sur des appareils edge courants et des GPU grand public
• Le QAT consiste à simuler la quantification pendant l’entraînement afin de minimiser la perte de qualité lors de la compression du modèle
• Cette publication fournit des checkpoints QAT pour le format de quantification Q4_0, très populaire, ainsi qu’un nouveau format de quantification spécialisé pour les usages mobiles

Compromis entre compression et qualité

• La quantification est une technologie clé pour exécuter des modèles sur du matériel grand public, car elle réduit l’empreinte mémoire et augmente la vitesse de décodage
• La quantification post-entraînement standard (PTQ) entraîne souvent une baisse des performances, alors que le QAT intègre directement le processus de quantification dans l’entraînement
• Le PTQ est lui aussi efficace pour préserver la qualité, mais les résultats du QAT offrent une qualité globale supérieure à la référence PTQ standard
• Google a appliqué une recette QAT au format Q4_0 afin de maximiser les performances de tous les modèles, et a conçu séparément un schéma de quantification spécialisé mobile pour les modèles edge E2B et E4B

Structure d’optimisation mobile

• Les formats de compression standard sont souvent difficiles à exécuter efficacement sur les processeurs mobiles ; Gemma 4 utilise donc un schéma de quantification mobile sur mesure pour le matériel edge
• Les activations statiques précalculent pendant l’entraînement les réglages d’échelle des données afin de réduire la charge de travail des puces mobiles et d’améliorer la rapidité de réponse
• La quantification par canal organise les données compressées selon l’architecture des accélérateurs mobiles afin de permettre des calculs natifs sans recourir à des méthodes de contournement lentes
• La quantification sélective en 2 bits compresse fortement en 2 bits la partie génération de tokens tout en conservant une précision plus élevée pour les couches d’inférence essentielles, ce qui économise l’espace de stockage
• Les optimisations des embeddings et du cache KV concentrent la compression sur le vocabulaire du modèle et sa mémoire à court terme afin de réduire fortement l’empreinte mémoire active et de permettre des conversations longues
• Pour les cas d’usage ne nécessitant ni encodeur audio ni vision, il est possible de ne déployer que les modalités nécessaires afin de réduire encore l’empreinte mémoire ; un modèle texte seul Gemma 4 E2B sans Per-Layer Embeddings nécessite moins de 1 Go de mémoire

Utilisation et prise en charge des outils

• Google propose sur Hugging Face les poids des modèles Q4_0 et mobile
• Le format GGUF peut être utilisé directement dans llama.cpp, les tenseurs compressés sont fournis pour vLLM, et pour d’autres workflows Google partage des checkpoints non quantifiés pouvant être convertis et quantifiés vers des formats compatibles Q4_0
• Les méthodes de déploiement sont détaillées dans la documentation
• Sur desktop, il est possible de télécharger, gérer et exécuter localement les modèles Gemma 4 QAT avec llama.cpp, Ollama et LM Studio
• Pour le déploiement on-device, il est possible d’utiliser le runtime léger LiteRT-LM de Google, et sur le web les modèles peuvent être exécutés directement avec Transformers.js
• Pour le serving de grands modèles, il est possible d’utiliser SGLang et vLLM, tandis que MLX peut être utilisé pour l’optimisation sur Apple Silicon
• Les checkpoints MTP QAT conservent les gains de vitesse de MTP tout en quantifiant le modèle, et les poids peuvent être fine-tunés directement avec Hugging Face Transformers et Unsloth

[GN⁺]

Avis sur Hacker News

• J’ai essayé d’exécuter Gemma 4 E2B en local sur Mac avec uvx litert-lm run, et au premier lancement il a téléchargé 3,2 Go dans ~/.cache/huggingface/hub/models--litert-community--gemma-4-E2B-it-litert-lm
  C’est assez impressionnant qu’un modèle de cette taille puisse aussi traiter des entrées audio et image ; pour une image on peut lancer --attachment image.jpg --prompt describe, et pour l’audio --attachment audio.wav --prompt transcribe
  Le rendu SVG du pélican n’était pas terrible en soi, mais le fait qu’un fichier de 3,2 Go produise un SVG valide était surprenant : https://gist.github.com/simonw/94b318afde4b1ce5ff67d4b5d0362...

  • Je ne suis pas sûr qu’il s’agisse réellement de quantization-aware training (QAT)
    Les modèles de MLX Community l’indiquent dans leur nom, mais pas ceux-ci, et les dates d’upload ne semblent pas non plus parfaitement correspondre
  • C’est aussi surprenant qu’il existe une version de 0,8 Go uniquement textuelle
    On en arrive désormais à des conversations basiques en temps réel avec reconnaissance vidéo et audio directement sur l’appareil
  • À part ça, uvx est vraiment très pratique à utiliser
    J’aimerais aussi que Nvidia le prenne en charge en natif au lieu d’obliger les gens à passer par la procédure de contournement avec Docker

• Il y a aussi la collection Unsloth [0], et les résultats sont publiés [1]
  Par rapport au modèle BF16 non quantifié, on dirait qu’on est très proche de 100 % de précision, et la quantification d’Unsloth semble meilleure que le QAT original de Google présenté dans l’article
  Personnellement, j’utilise aussi le modèle 2B via Unsloth Studio et l’API pour la recherche web et la sortie JSON structurée, tout en l’ayant embarqué sur mon téléphone, et pour cet usage ça marche très bien
  [0] https://huggingface.co/collections/unsloth/gemma-4-qat
  [1] https://unsloth.ai/docs/models/gemma-4/qat#qat-analysis

  • Je pense que tu interprètes mal ce graphique
    Ce qu’on y voit, ce n’est pas du BF16 classique mais du BF16 QAT Q4_0
    En gros, Google a quantifié le modèle en 4 bits, puis a stocké le résultat au format BF16 pour des raisons de compatibilité et de commodité avec les packers en aval
    C’est un peu comme stocker de petits entiers 8 bits dans des entiers 32 bits, donc cela ne veut pas dire qu’on est proche de 100 % du BF16 non quantifié
    Cela dit, je me demande pourquoi le QAT Q4_0 4 bits publié par Google n’atteint pas exactement 100 % du BF16 QAT Q4_0. La conversion entre les deux packings semble pouvoir se faire par simple manipulation de bits, sans quantification supplémentaire, mais Unsloth parle d’un problème d’alignement de grille
    Indépendamment de ça, je n’aime pas que Google, Qwen et d’autres fabricants de petits modèles ne montrent que des benchmarks BF16 quand ils sortent un nouveau modèle. En pratique, les gens font tourner des quantifications 4 à 8 bits, et il est beaucoup trop difficile de savoir ce qu’on perd réellement en 4 bits et en 6 bits
  • Je suis un peu perdu : le modèle Unsloth fait environ 600 Mo, et celui de Google 7 Go ?

• Rien qu’en regardant cette semaine, il est impressionnant de voir à quelle vitesse l’écosystème Gemma a évolué
  Gemma 12B, prédiction multi-token, modèles quantifiés officiels sont sortis, et on sent que Google met vraiment du poids derrière ce rythme de publication, donc c’est prometteur

• On est le vendredi juste avant la WWDC, et il est frappant qu’Apple soit censé annoncer une Siri “améliorée” basée sur des modèles Google
  C’est peut-être un partenariat encore verrouillé, mais Google est peut-être aussi en train de dévoiler à l’avance le modèle qu’Apple montrera la semaine prochaine
  Je n’ai rien de certain, c’est juste une supposition

• J’ai fait tourner hf.co/google/gemma-4-12B-it-qat-q4_0-gguf:Q4_0 avec ollama sur un portable AMD Ryzen 9 8940HX, NVIDIA GeForce RTX 5060 8GB, 14 Go de RAM, et c’est plus rapide que je ne l’aurais pensé

• Sortir Gemma 4 12B (https://news.ycombinator.com/item?id=48385906), puis quelques jours plus tard sortir officiellement Q4_0 Gemma 4 12B, c’est un peu étrange
  Cela dit, j’apprécie que l’article indique une utilisation VRAM estimée à 6,7 Go pour Q4_0 Gemma 4 12B, et cela confirme que l’affirmation de Google selon laquelle ça tient confortablement dans 16 Go n’est vraie qu’en pratique pour la version quantifiée
  À ce sujet, dans le nouvel Edge Gallery pour macOS publié par Google, il est précisé que Gemma 4 12B n’est pas pris en charge sur les machines 16 Go à cause d’un manque de RAM, alors qu’au vu de l’utilisation VRAM estimée ici, la variante Q4_0 devrait clairement passer ; Google doit corriger ça

  • Je ne vois pas vraiment pourquoi avoir plusieurs publications serait étrange
    Je trouve préférable de publier les modèles et variantes au fur et à mesure qu’ils sont prêts, plutôt que de tout retenir jusqu’à ce que l’ensemble soit prêt d’un coup
    Q4_0 n’est pas juste une simple quantification de Gemma 4 12B, c’est un checkpoint entraîné en quantization-aware training
  • Si j’ai bien compris, 4Q et QAT 4Q sont deux choses différentes

• Google Pixel Intelligence pourrait battre Apple Intelligence

• Le fait de pouvoir faire tourner un modèle 12B dans 8 Go de VRAM est un gros changement
  C’est impressionnant de voir à quelle vitesse les petits modèles locaux progressent

• J’ai assez bien fait tourner Gemma 4 E2B Unsloth 4Q : https://youtube.com/shorts/XLsAnz5aAAI
  Le modèle E4B ne tient pas sur le TPU de mon téléphone, donc il bascule en swap sur la RAM, et je suis content qu’une version QAT améliore la précision

  • Je me demande comment tu as réussi à en tirer quelque chose d’utile
    De notre côté, nous avons trouvé que même le modèle E2B non quantifié était totalement inutilisable pour les tâches de classification réelles les plus simples
  • Je me demande comment tu as su si ça tournait sur le TPU ou si ça basculait sur la RAM
    J’aimerais tester ça aussi sur mon Pixel