Gemma 4 QAT : mémoire, contexte et usage local (2026)

Google a publié une déclinaison quantifiée de sa famille Gemma 4, conçue pour tourner sur mobile, laptop et poste de travail. Le modèle E2B descend sous 1 Go de mémoire en format mobile, tandis que cinq tailles couvrent des besoins allant du smartphone au GPU consumer. Ce comparatif s’appuie sur la documentation officielle de Google, la fiche modèle Hugging Face, la page LM Studio et la documentation technique d’Unsloth, arrêtées entre juin et août 2026. Il ne remplace pas votre propre test avant déploiement.

Ce qu’il faut retenir
– Le format mobile du modèle Gemma 4 E2B (texte seul, sans Per-Layer Embeddings) descend sous 1 Go de mémoire, selon le blog officiel de Google.
– Cinq tailles sont proposées — E2B, E4B, 12B, 26B A4B et 31B — avec des besoins RAM documentés par Unsloth allant de 3 à 18 Go en configuration QAT.
– Le modèle 12B introduit une architecture « Unified » sans encodeur séparé pour l’image et l’audio, projetés directement dans l’espace d’embedding du LLM.
– La fenêtre de contexte atteint 256K tokens sur les tailles moyennes et 128K sur les petits modèles, avec un support de plus de 140 langues.

Fiche comparative des cinq tailles Gemma 4 QAT

Source des besoins mémoire et fenêtres de contexte : documentation Unsloth, août 2026, et fiche modèle Hugging Face, juillet 2026. Il ne s’agit pas d’une grille tarifaire : les modèles Gemma 4 sont distribués en poids ouverts, téléchargeables gratuitement sur Hugging Face ; le coût réel dépend de l’infrastructure locale ou du fournisseur d’inférence choisi, non communiqué de façon uniforme par Google.

Cinq tailles, du mobile au poste de travail

Gemma 4 QAT se décline en cinq formats : E2B, E4B, 12B, 26B A4B et 31B. D’après la fiche Hugging Face du modèle, ces tailles ciblent des scénarios de déploiement distincts, du mobile et de l’edge (E2B, E4B) jusqu’aux GPU consumer et stations de travail (12B, 26B A4B, 31B).

Les modèles sont multimodaux : ils traitent le texte et l’image avec un support de ratio et de résolution variables sur l’ensemble des tailles, tandis que l’audio et la vidéo sont pris en charge nativement sur E2B, E4B et 12B. Google a introduit récemment un mécanisme de prédiction multi-tokens (MTP) pour accélérer l’inférence, puis publié le modèle 12B pour combler l’écart entre les formats E4B et le modèle 26B en mélange d’experts, selon le blog officiel.

Le modèle 12B repose sur une architecture que Google qualifie d’« Unified » : contrairement aux approches classiques qui passent par des encodeurs séparés pour l’image et l’audio, Gemma 4 12B élimine ces encodeurs et projette directement les patchs d’image bruts et les formes d’onde audio dans l’espace d’embedding du LLM, via des couches linéaires légères. Cette conception réduit la complexité du pipeline multimodal par rapport à des architectures à encodeurs multiples, d’après la documentation Hugging Face.

Le modèle 26B A4B illustre une autre logique d’efficacité : le « A » désigne les paramètres actifs, distincts du nombre total de paramètres. En n’activant qu’un sous-ensemble de 4 milliards de paramètres sur les 26 milliards totaux, ce modèle en mélange d’experts (Mixture-of-Experts) tourne presque aussi vite qu’un modèle dense de 4 milliards de paramètres, tout en s’appuyant sur une base bien plus large. C’est, selon la documentation, un compromis pensé pour l’inférence rapide face à un modèle dense de 31B, plus lourd mais structurellement plus simple.

Quantification QAT : comment Google compresse la mémoire jusqu’à 1 Go

La quantification consciente de l’entraînement (Quantization-Aware Training, QAT) consiste à simuler la quantification pendant la phase d’entraînement du modèle, plutôt que de l’appliquer après coup sur des poids déjà figés. Cette approche limite la perte de qualité lorsque le modèle est ensuite compressé pour l’inférence, selon le blog Google.

Le résultat le plus marquant concerne le format mobile du modèle E2B. Google indique avoir réduit son empreinte mémoire à 1 Go grâce à ce format, une baisse rendue possible par l’application de la recette QAT au format de quantification Q4_0, largement utilisé dans l’écosystème llama.cpp. Plus précisément, le modèle Gemma 4 E2B en version texte seul, sans les Per-Layer Embeddings (PLE), nécessite moins d’1 Go de mémoire selon la documentation officielle.

Ce chiffre de 1 Go concerne un format d’exécution mobile spécifique. Pour la version GGUF distribuée via Hugging Face et destinée à llama.cpp, les besoins mémoire documentés par Unsloth sont différents : environ 3 Go pour E2B, 5 Go pour E4B, 7 Go pour le 12B, 15 Go pour le 26B A4B et 18 Go pour le 31B. Cette différence s’explique par le format d’exécution et les composants embarqués (Per-Layer Embeddings, multimodalité complète), pas par une contradiction entre les deux sources.

Unsloth précise par ailleurs que la quantification QAT en 4 bits permet une réduction d’environ 72 % de l’usage mémoire par rapport à une précision native, tout en conservant des performances proches de l’original. La documentation Unsloth distingue toutefois une quantification Q4_0 « naïve » appliquée après coup d’une quantification optimisée par sa propre méthode dynamique : sur le modèle 26B A4B, la quantification naïve n’atteint que 70,2 % de précision top-1, contre 85,6 % avec la méthode dynamique d’Unsloth, soit un gain de 15,6 points, pour un fichier même 200 Mo plus léger. Ces écarts illustrent que la manière dont la quantification est appliquée après le QAT influence sensiblement la qualité finale, au-delà du seul format de base publié par Google.

Déploiement local : format GGUF et llama.cpp

Les checkpoints Gemma 4 QAT sont distribués au format GGUF sur Hugging Face, sous des identifiants comme google/gemma-4-12B-it-qat-q4_0-gguf. La fiche modèle documente l’usage avec plusieurs librairies, fournisseurs d’inférence, notebooks et applications locales, ainsi qu’un mode d’emploi spécifique pour llama.cpp.

Concrètement, un serveur d’inférence local peut être lancé directement en ligne de commande, par exemple via llama-server -hf google/gemma-4-12B-it-qat-q4_0-gguf:Q4_0 pour exécuter le modèle depuis le terminal, ou via le binaire compilé /build/bin/llama-server pour la même opération sur une installation locale de llama.cpp. Le serveur expose ensuite une interface compatible avec les appels au format http://localhost:8080/v1, ce qui permet de brancher des clients existants sans réécrire l’intégration.

Selon la fiche Hugging Face, les formats de quantification Q4_0 en QAT sont disponibles pour l’ensemble des cinq tailles — E2B, E4B, 12B, 26B A4B et 31B — ainsi que pour leurs modèles « drafter » associés, utilisés pour accélérer l’inférence par décodage spéculatif. LM Studio référence également le modèle 12B QAT dans son catalogue, confirmant sa disponibilité au-delà du seul écosystème llama.cpp, avec la même architecture Unified qui route les entrées multimodales vers le socle décodeur du LLM via des couches de projection légères plutôt que des encodeurs séparés.

Cette disponibilité multi-outils compte pour l’usage local : un même checkpoint quantifié peut être servi par llama.cpp en ligne de commande, chargé dans LM Studio pour une interface graphique, ou intégré via des notebooks et fournisseurs d’inférence tiers cités dans la documentation Hugging Face.

Contexte 256K tokens et couverture de 140 langues

La fenêtre de contexte varie selon la classe de taille. D’après la fiche Hugging Face, les petits modèles (E2B, E4B) disposent d’une fenêtre de 128K tokens, tandis que les modèles de taille moyenne — dont le 12B — montent jusqu’à 256K tokens. Cette segmentation traduit un arbitrage mémoire/contexte cohérent avec les besoins RAM documentés plus haut : plus la fenêtre de contexte s’élargit, plus l’empreinte mémoire nécessaire augmente.

Sur le plan linguistique, l’ensemble de la famille Gemma 4 maintient un support multilingue annoncé à plus de 140 langues, un socle inchangé quelle que soit la taille du modèle sélectionnée.

Côté multimodalité, la fiche technique mentionne un traitement étendu : texte, image avec ratio et résolution variables sur l’ensemble des tailles, ainsi que vidéo et audio, ces deux dernières modalités étant nativement intégrées sur E2B, E4B et 12B seulement. Sur le benchmark public MRCR v2 à 8 aiguilles en contexte 128K, la fiche Hugging Face indique un score moyen proche de 66 points — un repère utile pour évaluer la capacité du modèle à retrouver une information précise noyée dans un contexte long, bien que la méthodologie complète de ce benchmark ne soit pas détaillée dans la documentation consultée.

Ce qui distingue vraiment les cinq tailles

Le choix entre les tailles Gemma 4 QAT ne se résume pas à un arbitrage linéaire « plus de mémoire, plus de qualité ». Le modèle 26B A4B illustre une alternative structurelle : en n’activant que 4B de paramètres sur les 26B disponibles, il vise une vitesse d’inférence proche d’un modèle dense de 4B, tout en s’appuyant sur une base de connaissances issue d’un entraînement à 26B. Face à lui, le 31B dense mobilise davantage de mémoire (18 Go contre 15 Go) sans ce mécanisme d’activation partielle.

L’autre différence qui compte est moins visible dans les fiches techniques : la qualité de la quantification appliquée après le QAT. Les écarts documentés par Unsloth entre une quantification Q4_0 naïve et une quantification dynamique optimisée (70,2 % contre 85,6 % de précision top-1 sur le 26B A4B) montrent que deux fichiers portant la même étiquette « QAT Q4_0 » peuvent livrer des résultats sensiblement différents selon l’outil de conversion utilisé en aval du checkpoint officiel Google.

Enfin, l’architecture Unified du modèle 12B — sans encodeurs séparés pour l’image et l’audio — le distingue des autres tailles multimodales sur le plan de la simplicité d’intégration, même si la documentation ne fournit pas de comparaison chiffrée de qualité multimodale entre cette approche et des architectures à encodeurs dédiés.

Pour quel profil choisir quelle taille

Débutant sur mobile ou laptop grand public : le format E2B, avec une empreinte mémoire descendant sous 1 Go en configuration mobile texte seul, correspond aux appareils aux ressources limitées. E4B, à environ 5 Go de RAM en GGUF selon Unsloth, offre une marge supplémentaire pour les laptops standards.

Usage professionnel quotidien sur poste de travail : le modèle 12B, avec ses 7 Go de RAM documentés et sa fenêtre de contexte jusqu’à 256K tokens, correspond à un usage régulier de documents longs sur un GPU consumer ou une station de travail, sans nécessiter l’infrastructure d’un modèle 31B.

Développeur-intégrateur cherchant vitesse et volume : le 26B A4B, à 15 Go de RAM pour une inférence proche d’un modèle 4B grâce à l’activation partielle des paramètres, convient aux intégrations où la latence prime. Pour les cas où la qualité brute prime sur la vitesse, le 31B dense, à 18 Go de RAM, reste l’option la plus lourde mais la plus directe en architecture.

Questions fréquentes

Comment lancer Gemma 4 QAT en local avec llama.cpp ?

Après avoir installé llama.cpp, la commande llama-server -hf google/gemma-4-12B-it-qat-q4_0-gguf:Q4_0 télécharge et sert le modèle directement depuis Hugging Face, avec une API compatible exposée en local. La documentation Hugging Face détaille aussi l’usage via des notebooks et des fournisseurs d’inférence tiers pour les intégrations qui ne passent pas par la ligne de commande.

Pourquoi le modèle E2B affiche-t-il deux chiffres de mémoire différents (1 Go et 3 Go) ?

Le chiffre d’1 Go, cité par Google, correspond à un format mobile optimisé pour un usage texte seul, sans les Per-Layer Embeddings. Les 3 Go documentés par Unsloth concernent la version GGUF complète destinée à llama.cpp, qui embarque davantage de composants pour la même taille de modèle.