Quantization Aware Training : guide pour améliorer l’inférence locale de Gemma 4

Qu’est-ce que la quantification ?

La quantification est une technique de compression de modèle qui réduit la précision des poids.

Les grands modèles de langage sont généralement stockés dans des formats haute précision comme BF16 ou FP16, qui préservent la qualité mais nécessitent beaucoup de mémoire. La quantification convertit ces poids vers des formats à plus faible précision, comme 8 bits ou 4 bits, afin que le modèle consomme moins de VRAM et s’exécute plus facilement en local. Hugging Face indique qu’une quantification en 8 bits peut, en gros, diviser par deux l’usage mémoire, tandis que le 4 bits le réduit encore davantage.

Le compromis est que la plus faible précision peut parfois dégrader la qualité des sorties, surtout si le modèle n’a pas été optimisé pour la quantification. En simplifiant, BF16 et FP16 offrent en général la meilleure qualité mais consomment plus de mémoire ; les modèles en 8 bits sont plus compacts tout en conservant souvent une bonne qualité, et les modèles en 4 bits sont beaucoup plus petits mais peuvent perdre en précision ou en stabilité.

Pour l’inférence locale, ce compromis vaut souvent la peine car il permet d’exécuter des modèles plus grands sur des GPU grand public sans recourir à un matériel de centre de données coûteux.

Qu’est-ce que la Quantization Aware Training ?

La Quantization-Aware Training (QAT) est une technique où l’on entraîne ou affine le modèle tout en simulant le comportement en faible précision. Cela aide le modèle à rester plus stable après quantification et peut améliorer les performances d’inférence locale à faible nombre de bits.

Qu’est-ce qui différencie la QAT ?

L’approche classique, la quantification post-entraînement, compresse un modèle une fois l’entraînement terminé. C’est simple et pratique, mais le modèle peut perdre en qualité car il n’a pas été entraîné pour gérer des poids en faible précision.

D’après la documentation de Google AI Edge, la quantification post-entraînement est une étape de conversion qui peut réduire la taille du modèle et améliorer la latence, généralement avec peu de perte de précision. Toutefois, la qualité finale peut encore dépendre du modèle et du niveau de quantification.

La Quantization-Aware Training, ou QAT, adopte une autre approche. Au lieu de ne quantifier qu’après entraînement, la QAT simule le comportement en faible précision pendant l’entraînement ou l’affinage. Le modèle apprend ainsi à rester stable lorsqu’il sera converti ensuite dans un format plus compact. Elle minimise la perte de qualité lors de la compression.

C’est pourquoi Gemma 4 QAT est utile pour l’IA locale. Conçu avec la quantification à l’esprit, il conserve davantage la qualité du modèle d’origine tout en utilisant moins de mémoire. Pour celles et ceux qui exécutent des modèles sur des GPU grand public, cela peut se traduire par une meilleure stabilité en bas nombre de bits, une VRAM réduite et une inférence locale plus pratique.

Étape 1 : installer les dépendances et compiler llama.cpp

Avant de télécharger les modèles, préparons l’environnement local. Ce tutoriel a été testé sur une machine équipée d’un GPU NVIDIA RTX 4090 et de 24 Go de VRAM. Nous utiliserons llama.cpp comme moteur d’inférence, GGUF comme format de modèle, et les fichiers quantifiés UD-Q4_K_XL.

Configuration testée :

• GPU : NVIDIA RTX 4090
• VRAM : 24 Go
• Runtime : llama.cpp
• Format du modèle : GGUF
• Quantification : UD-Q4_K_XL

Nous comparerons les deux modèles Unsloth GGUF suivants :

• unsloth/gemma-4-12B-it-GGUF
• unsloth/gemma-4-12B-it-qat-GGUF

Commencez par vérifier que votre GPU est disponible.

nvidia-smi

Installez ensuite les paquets système nécessaires pour compiler llama.cpp.

apt-get update
apt-get install pciutils build-essential cmake curl libcurl4-openssl-dev -y

Clonez le dépôt officiel llama.cpp.

git clone https://github.com/ggml-org/llama.cpp

Compilez maintenant llama.cpp avec la prise en charge CUDA activée. Cela permet d’exécuter les couches du modèle sur le GPU plutôt que seulement sur le CPU.

cmake llama.cpp -B llama.cpp/build \
    -DBUILD_SHARED_LIBS=OFF \
    -DGGML_CUDA=ON

Compilez les binaires requis.

cmake --build llama.cpp/build \
    --config Release \
    -j \
    --clean-first \
    --target llama-cli llama-mtmd-cli llama-server llama-gguf-split

Une fois la compilation terminée, le binaire principal que nous utiliserons est llama-server. Il permet d’exécuter le modèle GGUF en local et expose un point de terminaison d’API compatible OpenAI que l’on peut interroger avec curl.

Étape 2 : télécharger les modèles Gemma 4 12B non QAT et QAT

Maintenant que llama.cpp est prêt, nous pouvons télécharger les deux variantes du modèle Gemma 4 12B depuis Hugging Face. Nous allons récupérer le modèle instruction-tuned classique ainsi que la version QAT au format GGUF.

Commencez par installer la CLI Hugging Face Hub avec la prise en charge des téléchargements accélérés.

pip install -U "huggingface_hub[hf_xet]" hf-xet hf_transfer

Activez les téléchargements Xet haute performance.

export HF_XET_HIGH_PERFORMANCE=1

Téléchargez le modèle Gemma 4 12B instruction en format GGUF.

hf download unsloth/gemma-4-12B-it-GGUF \
  --local-dir models/gemma-4-12B-it-GGUF \
  --include "*mmproj-BF16*" \
  --include "*UD-Q4_K_XL*"

Ensuite, téléchargez la version QAT en utilisant le même format de quantification.

hf download unsloth/gemma-4-12B-it-qat-GGUF \
  --local-dir models/gemma-4-12B-it-qat-GGUF \
  --include "*mmproj-BF16*" \
  --include "*UD-Q4_K_XL*"

Les options --include garantissent que nous ne téléchargeons que les fichiers nécessaires à ce tutoriel, sans récupérer l’intégralité du dépôt. Ici, nous téléchargeons les fichiers de modèle GGUF UD-Q4_K_XL et les fichiers mmproj-BF16 utilisés par le package du modèle.

Après les téléchargements, vérifiez que les deux dossiers de modèles sont présents.

ls models

Sortie attendue :

gemma-4-12B-it-GGUF
gemma-4-12B-it-qat-GGUF

À ce stade, les modèles non QAT et QAT sont disponibles en local, et nous pouvons commencer à les servir avec llama-server.

Étape 3 : exécuter le modèle non QAT avec llama-server

Nous allons commencer par exécuter le modèle Gemma 4 12B instruction classique. Cela nous donnera une base de référence à comparer ensuite avec la version QAT en conservant les mêmes paramètres.

Démarrez le modèle non QAT avec llama-server.

./llama.cpp/llama-server \
  -m models/gemma-4-12B-it-GGUF/*UD-Q4_K_XL*.gguf \
  --host 0.0.0.0 \
  --port 8001 \
  --ctx-size 8192 \
  --n-gpu-layers 99 \
  --temp 1.0 \
  --top-p 0.95 \
  --top-k 64

Cela lance un serveur local compatible OpenAI à l’adresse http://localhost:8001.

Ouvrez un autre terminal et envoyez une requête au serveur local.

time curl http://localhost:8001/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
  "model": "gemma-4-12B-it",
  "messages": [
    {
      "role": "system",
      "content": "You are a helpful local AI assistant."
    },
    {
      "role": "user",
      "content": "Explain why quantization-aware training is useful for running LLMs on consumer GPUs."
    }
  ],
  "temperature": 1.0,
  "top_p": 0.95,
  "max_tokens": 512
}'

Dans cette commande, nous utilisons le point de terminaison local /v1/chat/completions, compatible avec l’API OpenAI. L’invite demande au modèle d’expliquer la QAT, et max_tokens est fixé à 512 pour s’assurer que les deux variantes soient testées avec la même longueur de sortie.

Sur notre RTX 4090, le modèle non QAT a donné les résultats de timing suivants :

• Jetons de l’invite : 40
• Jetons générés : 512
• Vitesse d’invite : 510,22 jetons/s
• Vitesse de génération : 94,65 jetons/s
• Temps total : 5,516 s

L’usage mémoire GPU était :

9247 MiB / 24564 MiB

Cela nous donne la référence de performance pour le modèle Gemma 4 12B classique. À l’étape suivante, nous exécuterons la version QAT avec la même configuration et comparerons les résultats.

Étape 4 : exécuter et tester le modèle QAT

Nous allons maintenant exécuter la version QAT de Gemma 4 12B en utilisant les mêmes paramètres llama-server. Veillez à arrêter le serveur non QAT précédent avant de démarrer celui-ci, car les deux commandes utilisent le même port.

Démarrez le modèle QAT.

./llama.cpp/llama-server \
  -m models/gemma-4-12B-it-qat-GGUF/*UD-Q4_K_XL*.gguf \
  --host 0.0.0.0 \
  --port 8001 \
  --ctx-size 8192 \
  --n-gpu-layers 99 \
  --temp 1.0 \
  --top-p 0.95 \
  --top-k 64

Cela lance le modèle QAT sur le même point de terminaison local compatible OpenAI, http://localhost:8001.

Envoyez maintenant la même invite de test au modèle QAT.

time curl http://localhost:8001/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
  "model": "gemma-4-12B-it-qat",
  "messages": [
    {
      "role": "system",
      "content": "You are a helpful local AI assistant."
    },
    {
      "role": "user",
      "content": "Explain why quantization-aware training is useful for running LLMs on consumer GPUs."
    }
  ],
  "temperature": 1.0,
  "top_p": 0.95,
  "max_tokens": 512
}'

Sur notre RTX 4090, le modèle QAT a produit les résultats de timing suivants :

1. Jetons de l’invite : 40
2. Jetons générés : 512
3. Vitesse d’invite : 593,93 jetons/s
4. Vitesse de génération : 101,65 jetons/s
5. Temps total : 5,114 s

L’usage mémoire GPU était :

8627 MiB / 24564 MiB

Vous pouvez aussi copier l’URL du serveur local (http://localhost:8001) et la coller dans votre navigateur :

Cela ouvre l’interface web intégrée de llama.cpp, une interface type ChatGPT simple pour tester le modèle local. Vous pouvez discuter avec le modèle QAT directement dans le navigateur, expérimenter des prompts et l’utiliser comme assistant IA local au quotidien.

Comparer les résultats QAT vs non QAT

Après avoir testé les deux modèles avec la même invite et les mêmes réglages serveur, nous pouvons comparer directement leurs performances sur la RTX 4090.

Dans ce test, le modèle QAT s’est révélé à la fois plus rapide et plus léger que la version non QAT. Il a utilisé 620 MiB de VRAM en moins, soit une réduction d’environ 6,7 %. C’est précieux pour l’inférence locale, car chaque Mo économisé compte lors de l’exécution de grands modèles sur des GPU grand public.

Le modèle QAT a également généré les jetons plus vite, passant de 94,65 jetons/s à 101,65 jetons/s. Cela représente environ +7,4 % de vitesse de génération, réduisant le temps total de 5,516 s à 5,114 s.

Au quotidien, le modèle QAT paraît plus fluide et réactif. La qualité des réponses s’est aussi montrée plus stable dans ce test, ce qui est l’intérêt principal de la QAT : elle aide le modèle à mieux supporter la quantification en faible nombre de bits avec moins de perte de qualité, tout en conservant les gains de mémoire et de vitesse d’un modèle compressé.

Conclusion

Google fait un travail remarquable pour la communauté de l’IA locale. Avec des modèles comme Gemma 4 et des techniques comme la QAT, le rêve d’exécuter des modèles puissants en local, totalement hors ligne, et même sur du matériel grand public, devient réalité.

Le plus enthousiasmant, c’est que l’objectif ne se limite pas à réduire la taille des modèles. Avec la QAT, il ne s’agit pas simplement d’accepter une baisse de qualité pour faire tenir le modèle. Nous obtenons des modèles conçus pour mieux fonctionner en formats bas-bit, ce qui améliore l’expérience globale de l’IA locale. Dans ce test, la version QAT s’est révélée plus rapide, plus légère et plus agréable à utiliser que la version non QAT.

J’ai désormais hâte de tester la version MTP du modèle, qui pourrait encore accélérer les performances, potentiellement par 2. Cela faciliterait grandement le passage d’une plus grande partie de mon flux de travail à l’IA locale. Je pourrais l’exécuter en local, le connecter à des outils comme OpenCode, et commencer à éditer des fichiers de projet directement avec un assistant local privé.

Cette nouvelle vague d’IA locale change notre façon d’envisager l’usage des systèmes d’IA. Des tâches qui nécessitaient autrefois des environnements cloud lourds, en particulier les workflows multimodaux avec texte, image et vidéo, deviennent peu à peu possibles sur des machines locales. Pour les développeurs, chercheurs et bâtisseurs attachés à la confidentialité, à la vitesse et au contrôle, c’est une évolution très prometteuse.