Les points de contrôle officiels utilisent un schéma W4A16 : des poids en entiers 4 bits avec des activations en 16 bits, une taille de groupe (group_size) de 32 et le format compressed-tensors . C'est la même approche que Google documente pour l'inférence basée sur vLLM, où la combinaison de poids en faible précision et d'activations en haute précision équilibre les économies de mémoire et le débit
.
Cinq tailles de modèles ont reçu des points de contrôle QAT, ainsi que des modèles « brouillons » (drafters) pour le décodage spéculatif. Chacun est disponible en plusieurs formats (discutés ci-dessous), et les empreintes mémoire pratiques changent considérablement entre BF16 et QAT 4 bits .
| Modèle | Architecture | Paramètres actifs | Mémoire BF16 | Mémoire QAT 4 bits | Configuration matérielle clé |
|---|---|---|---|---|---|
| E2B | Dense + PLE | ~2,3B effectifs (5,1B avec embeddings) | ~9,6 Go | ~3,2 Go (Q4_0) ; 1 Go (format mobile) | Smartphones, appareils en périphérie, navigateurs |
| E4B | Dense + PLE | ~4,5B effectifs (8B avec embeddings) | ~15 Go | ~5 Go (Q4_0) | GPU de milieu de gamme, appareils mobiles avec plus de RAM |
| 12B | Dense, multimodal unifié sans encodeur | 11,95B | ~24 Go | ~7 Go (Q4_0) | GPU de 8 Go, PC portables avec carte graphique dédiée |
| 26B A4B | Mélange d'Experts (MoE) | ~3,8B actifs (26B au total) | ~48 Go | ~15 Go (Q4_0) | GPU de 12–16 Go, stations de travail haut de gamme |
| 31B | Dense | 30,7B | ~58 Go | ~17–18 Go (Q4_0) | GPU de 24 Go (RTX 3090/4090), configurations avec beaucoup de VRAM |
Les chiffres de mémoire proviennent de l'aperçu officiel du modèle par Google et de la documentation Unsloth, les valeurs Q4_0 correspondant au niveau de quantification GGUF populaire . Le chiffre d'environ 1 Go pour le format mobile E2B est celui qui fait les gros titres — Google a spécifiquement conçu un schéma personnalisé avec des couches de décodage ciblées en 2 bits et des caches KV optimisés pour y parvenir
. Pour les modèles texte uniquement sans Per-Layer Embeddings, l'empreinte pourrait même passer sous la barre du gigaoctet
.
Le modèle 26B A4B mérite une attention particulière. Il s'agit d'une architecture de Mélange d'Experts (Mixture of Experts, ou MoE) qui n'active qu'environ 3,8 milliards de paramètres par token, bien qu'il en compte 26 milliards au total. Cela signifie qu'il offre un comportement de calcul plus proche de celui d'un modèle de 4B, tout en fournissant une qualité de raisonnement à peu près comparable à celle d'un modèle dense bien plus grand . En version 4 bits, il tient sur des GPU de 12-16 Go — le type de matériel que de nombreux développeurs possèdent déjà
.
Google a publié les points de contrôle QAT sous quatre formes distinctes, et le choix du format affecte directement la qualité :
group_size de 32. C'est l'option recommandée si vous souhaitez rester dans l'enveloppe de qualité de Google La mise en garde la plus importante de toute cette publication concerne la conversion naive de format. Convertir les poids QAT directement en Q4_0 sans une gestion appropriée peut réduire drastiquement la précision. Selon la documentation d'Unsloth, une conversion Q4_0 naïve du modèle 26B QAT n'atteint qu'environ 70,2 % de précision top-1 . Leur propre méthode dynamique fait monter ce score à 85,6 %, soit une amélioration de 15,4 points de pourcentage — mais l'essentiel est que la sélection du format et la méthodologie de conversion sont essentielles pour préserver la qualité que le QAT est censé garantir
.
Pour la plupart des utilisateurs, les points de contrôle officiels en tenseurs compressés ou en GGUF sont le point de départ le plus sûr.
Le QAT ne fait pas que réduire la mémoire — il remodèle le paysage matériel pour l'inférence locale de l'IA. Des modèles qui nécessitaient auparavant des GPU de centre de données peuvent désormais fonctionner sur du matériel grand public, voire sur des smartphones.
Smartphones et appareils en périphérie : Le E2B est conçu pour le mobile. Le framework LiteRT-LM de Google peut exécuter le E2B avec moins de 1,5 Go de RAM en quantification 2 et 4 bits, et l'application AI Edge Gallery de Google, disponible sur le Play Store, permet aux utilisateurs de sélectionner et d'exécuter E2B ou E4B entièrement sur l'appareil . Les deux modèles prennent en charge le texte, l'image et l'audio — traduction vocale en temps réel, réponse visuelle à des questions et assistants sur appareil deviennent plausibles sans connexion cloud
.
GPU de 8 Go : Le point idéal pour les déploiements QAT. E2B (~3,2 Go), E4B (~5 Go) et le modèle 12B (~7 Go) tiennent tous confortablement dans 8 Go de VRAM en quantification Q4_0 . Cela signifie qu'un PC portable de milieu de gamme avec une RTX 4060 mobile ou un ancien PC de bureau avec une RTX 2070 peut désormais exécuter un modèle multimodal unifié avec une fenêtre de contexte de 256K — une chose qui aurait nécessité 24 Go ou plus en précision 16 bits.
GPU de 12–16 Go : Le modèle MoE 26B A4B se situe ici, à environ 15 Go en version Q4_0, tenant sur des cartes comme la RTX 3080, la 4070 Ti ou la 4080 . Son architecture MoE signifie également qu'il maintient une latence d'inférence plus faible qu'un modèle dense d'empreinte similaire, car seule une fraction des paramètres s'active par token
.
GPU de 20–24 Go : Le modèle dense 31B nécessite environ 17–18 Go en quantification Q4_0, ce qui le met à portée des possesseurs de RTX 3090 et 4090 avec un peu de marge pour le cache KV et la taille des lots . En précision 16 bits complète, ce modèle exige près de 60 Go — totalement hors de portée pour les GPU grand public. Le QAT rend le plus grand modèle Gemma 4 véritablement utilisable sur une seule carte grand public haut de gamme.
Rappel important : Les chiffres de mémoire discutés ici représentent la taille des poids du modèle, et non la consommation totale de VRAM. La surcharge d'exécution — en particulier le cache KV pour les longues fenêtres de contexte — peut ajouter des gigaoctets supplémentaires. Le modèle 31B avec un contexte de 256K consommera significativement plus de mémoire que la taille de base des poids, et les retours de la communauté suggèrent que les charges de travail utilisant beaucoup de contexte pourraient pousser les besoins dans la fourchette basse de 20 Go . Prévoyez toujours une marge supplémentaire par rapport à l'empreinte Q4_0 indiquée.
La promesse centrale du QAT est une performance quasi-originale avec une réduction drastique de la mémoire — et les benchmarks confirment largement cette promesse. La documentation de Google décrit la performance comme « quasi-originale » avec une réduction de mémoire d'environ 72 %, et les benchmarks de la communauté suggèrent une perte de qualité de l'ordre de 3 à 5 % pour une quantification Q4 par rapport au BF16 .
Mais le diable est dans les détails. L'avertissement sur la conversion naïve par Unsloth — 70,2 % de précision top-1 sur le modèle 26B contre 85,6 % après leur optimisation dynamique — démontre que la qualité obtenue dépend fortement de la façon dont les poids QAT sont convertis et déployés . Si vous prenez simplement un point de contrôle QAT et le passez dans un convertisseur GGUF standard sans gestion adaptée au QAT, vous pourriez ne pas obtenir la qualité attendue.
Pour une utilisation en production, l'approche la plus sûre consiste à utiliser les points de contrôle QAT officiels de Google directement dans leur format de tenseurs compressés (pour vLLM) ou les fichiers GGUF officiels sur Hugging Face . Si vous avez besoin d'une quantification personnalisée au-delà de ce que Google fournit, prévoyez du temps pour les benchmarks — les poids QAT sont plus sensibles à la méthodologie de conversion que les poids quantifiés post-entraînement standard.
Sur le plan pratique, cette publication change la réponse par défaut à la question « puis-je faire tourner ce modèle en local ? ». Pour la première fois, une famille majeure de modèles aux poids ouverts est livrée avec des points de contrôle QAT en tant qu'élément de premier ordre, et non comme une réflexion après coup. Les implications se répercutent sur plusieurs catégories d'applications :
Travaux sensibles à la vie privée : Les applications d'assistance médicale, juridique et personnelle qui nécessitaient auparavant une API cloud peuvent désormais s'exécuter entièrement sur l'appareil, que ce soit un ordinateur portable ou un téléphone, le QAT préservant suffisamment de qualité pour rendre l'inférence locale réellement utile .
Déploiement hors ligne et en périphérie : La recherche sur le terrain, la réponse aux catastrophes et les environnements industriels sans connectivité fiable peuvent déployer des modèles multimodaux performants sur du matériel standard. La prise en charge de l'audio sur le E2B, associée à la quantification mobile à 1 Go, fait de la traduction vocale en temps réel sur un téléphone de milieu de gamme une réalité pratique .
Outillage de développement et IDE : Les modèles 12B et 26B tiennent sur le matériel que les développeurs possèdent déjà, permettant la complétion de code, la refactorisation et la génération de documentation qui s'exécute localement sans latence ni contrainte de coût. Google a spécifiquement positionné les versions quantifiées pour « les IDE, les assistants de codage et les flux de travail agentiques » .
Expérimentation et ajustement fin : Les petites équipes de recherche et les développeurs indépendants qui n'avaient pas les moyens de s'offrir des clusters A100 ou H100 peuvent désormais travailler avec des modèles de 12B à 31B sur du matériel grand public, abaissant considérablement la barrière à l'entrée pour la personnalisation de modèles et l'ajustement fin spécifique à un domaine.
Google a publié les points de contrôle sous la même licence Apache 2.0 que les modèles de base Gemma 4, et ils sont disponibles immédiatement sur Hugging Face pour les cinq tailles de modèles .