Quantification de modèles Ollama : format GGUF et perte de précision expliqués

RTX 3060, 12 Go de VRAM, envie de faire tourner Llama 3 70B ? CUDA out of memory — même un 14B ne passe pas. La quantification compresse un modèle 70B de 140 Go à 40 Go, mais quelle est la perte de précision ?

Les 500 000 évaluations de Red Hat apportent une réponse : la quantification 8-bit restaure >99 % de la précision, la 4-bit 98,9 %. En usage quotidien, la différence est quasi imperceptible ; seuls des benchmarks académiques extrêmes révèlent un écart minime.

Cet article détaille les principes de la quantification GGUF, la comparaison des niveaux de précision et les recommandations pour GPU grand public. Si la VRAM vous manque ou si vous doutez de la qualité après quantification, vous trouverez ici les réponses.

1. Qu’est-ce que la quantification : la technique qui « allège » les grands modèles

Une analogie rapide : une photo HD pèse plusieurs Mo, WeChat la compresse en quelques centaines de Ko. Perte de qualité ? Oui. Mais reste-t-elle lisible ? Oui.

La quantification de modèle fonctionne sur le même principe.

1.1 L’essence de la quantification

Les poids d’un grand modèle sont stockés en FP16 (flottants 16 bits). Un modèle 7B en FP16 requiert environ 14 Go de mémoire — chaque paramètre occupe 2 octets.

La quantification convertit ces valeurs haute précision en formats basse précision. Par exemple INT4 (entiers 4 bits) : 0,5 octet par paramètre. Un modèle de 14 Go peut ainsi descendre à ~3,5 Go.

En image : FP16 enregistre des décimales très précises, comme 0,12345678 ; après quantification INT4, on ne garde qu’un entier approximatif, comme 3. La précision diminue, mais l’information subsiste.

1.2 Quel gain de compression ?

Voici des données (source : tests Will It Run AI) sur la consommation mémoire d’un modèle 7B selon le niveau de quantification :

Niveau	VRAM requise	Économie mémoire	Qualité
F16 (original)	14,0 Go	Référence	Optimale
Q8_0	7,4 Go	47 %	Excellent
Q5_K_M	4,8 Go	65 %	Bonne
Q4_K_M	3,9 Go	72 %	Acceptable
Q3_K_M	3,1 Go	78 %	Faible
Q2_K	2,6 Go	81 %	Très faible

Q4_K_M réduit la mémoire de 72 %. Concrètement : un modèle qui demandait 14 Go de VRAM tourne sur une carte 4 Go.

La première fois que j’ai fait tourner un 7B sur ma RTX 3060, c’était comme turbocharger une vieille voiture : avant limité au 3B, je pouvais enfin utiliser un modèle intermédiaire.

1.3 Quel est le coût de la quantification ?

Comme pour les photos, une compression excessive floute l’image et ajoute du bruit. Idem pour les modèles :

• Perte de précision : les valeurs basse précision n’expriment pas exactement l’original, d’où une erreur
• Perte de continuité : INT4 est discret, FP16 est continu — certaines variations fines disparaissent

La vraie question : cette perte est-elle acceptable ? Les 500 000 évaluations ci-dessous y répondent. Continuons.

2. Format GGUF : pourquoi c’est le standard des modèles quantifiés

En téléchargeant des modèles quantifiés, vous avez sans doute remarqué l’extension .gguf. Qu’a-t-elle de spécial ?

2.1 Qu’est-ce que GGUF ?

GGUF signifie GPT-Generated Unified Format — un format d’encapsulation conçu pour l’inférence.

Créé par l’équipe llama.cpp avec une approche pragmatique : un modèle entraîné doit pouvoir s’exécuter facilement. GGUF en est le résultat.

Trois avantages majeurs :

Encapsulation monofichier. Avant, Hugging Face imposait de récupérer poids, tokenizer, config.json… GGUF regroupe tout en un seul fichier .gguf.

Chargement par memory mapping (mmap). Le fichier est mappé en mémoire et lu à la demande. Pas besoin de tout charger d’abord — utile pour les 70B : quelques secondes au lieu de dizaines pour démarrer l’inférence.

Interopérabilité. Un même GGUF fonctionne dans Ollama, LM Studio, llama.cpp, KoboldCPP, etc. Pas de re-téléchargement en changeant d’outil.

2.2 GGUF vs autres formats

Format	Usage	Caractéristiques	Outils
GGUF	Inférence	Monofichier, quantification native	Ollama, LM Studio, llama.cpp
Safetensors	Entraînement/fine-tuning	Sécurisé, sans risque pickle	PyTorch, Hugging Face
GGML	Inférence (ancien)	Obsolète	llama.cpp (anciennes versions)
PyTorch (.pt/.bin)	Entraînement	Flexible mais moins sûr	PyTorch

En bref : GGML est l’ancêtre de GGUF, abandonné. Safetensors sert à l’entraînement, avec conversion pour l’inférence. GGUF est optimisé pour l’inférence — Ollama l’utilise par défaut.

Pour faire de l’inférence uniquement, GGUF est le bon choix.

2.3 Ollama et GGUF

Ollama exécute les modèles via llama.cpp, qui ne reconnaît que GGUF. Tous les modèles Ollama sont donc au fond des GGUF.

Avec ollama pull llama3, Ollama télécharge un fichier GGUF déjà quantifié — par défaut en Q4_K_M.

Plus loin, nous verrons comment récupérer d’autres niveaux depuis Hugging Face. Comprendre le format facilite la suite.

3. Niveaux de quantification : de Q2 à Q8, lequel vous convient

Point central : Q4_K_M ou Q5_K_M ? Que signifient S, M, L ? Voici le détail.

3.1 Tableau comparatif

Données Will It Run AI, modèle Llama 3 8B testé :

Niveau	VRAM	Qualité	Scénario
Q8_0	~8,5 Go	Excellent	VRAM confortable, qualité maximale
Q6_K	~6,1 Go	Très bonne	Bon compromis, proche de l’original
Q5_K_M	~5,3 Go	Bonne	Point d’équilibre, recommandé
Q5_K_S	~5,0 Go	Bonne	Légèrement plus agressif que Q5_K_M
Q4_K_M	~4,4 Go	Acceptable	Choix mainstream, bon rapport qualité/prix
Q4_K_S	~4,1 Go	Acceptable	Plus agressif, qualité légèrement inférieure
Q3_K_M	~3,5 Go	Faible	Dernier recours, perte visible
Q3_K_S	~3,2 Go	Faible	Déconseillé sauf VRAM très limitée
Q2_K	~2,7 Go	Très faible	Généralement déconseillé

Les deux niveaux en gras sont mes recommandations principales : Q5_K_M et Q4_K_M.

3.2 K-quant et suffixes S/M/L

Le K indique k-quant, une stratégie de précision mixte : toutes les couches ne sont pas quantifiées pareil. Les couches sensibles (attention) gardent une précision plus élevée ; les autres (FFN) sont plus compressées.

Les suffixes S, M, L représentent trois degrés d’agressivité :

• S (Small) : le plus agressif, compression maximale, plus grande perte
• M (Medium) : équilibré, recommandé
• L (Large) : conservateur, meilleure qualité, fichier plus volumineux

Q5_K_M et Q5_K_S sont tous deux en Q5, mais Q5_K_M offre une meilleure qualité et un fichier plus grand.

Mon conseil : privilégiez M dans la plupart des cas. S est trop agressif, L gaspille de la mémoire. M est le bon équilibre.

3.3 Sensibilité selon la tâche

Selon Will It Run AI, du plus au moins sensible à la précision :

1. Coding (programmation) : très sensible. Une erreur peut casser tout le code. Recommandé : Q5_K_M minimum.
2. Reasoning/Math (raisonnement/maths) : très sensible. Recommandé : Q5_K_M minimum.
3. Creative writing (écriture créative) : sensibilité moyenne. Q4_K_M acceptable.
4. Chat (conversation) : peu sensible. Q4_K_M convient parfaitement.
5. Summarization (résumé) : peu sensible. Q4_K_M suffit.

En résumé : code et raisonnement → Q5+ ; chat et résumé → Q4 acceptable.

Mon expérience : en Q4_K_M pour coder, des erreurs bizarres apparaissent parfois — noms de fonctions mal orthographiés, logique incohérente. En Q5_K_M, nettement moins. Pour le chat, Q4 et Q5 se ressemblent.

4. La vérité sur la perte de précision : 500K+ évaluations Red Hat

Données concrètes. Beaucoup craignent que la quantification « abrutisse » le modèle — j’avais la même inquiétude, jusqu’au rapport Red Hat.

4.1 Ce qu’a fait Red Hat

En octobre 2024, Red Hat a publié « We ran over half a million evaluations on quantized LLMs » — plus de 500 000 évaluations comparant modèles quantifiés et originaux.

"We ran over half a million evaluations on quantized LLMs to determine the impact of quantization on model quality across multiple benchmarks and real-world tasks."

Évaluation systématique à grande échelle, avec plusieurs frameworks :

• Benchmarks académiques : OpenLLM Leaderboard v1/v2 (MMLU, HellaSwag, ARC, etc.)
• Tâches réelles : Arena-Hard, HumanEval, HumanEval+
• Similarité textuelle : ROUGE, BERTScore, STS

Modèles testés : Llama 2 7B, 13B, 70B ; Mixtral 8x7B MoE ; série Qwen…

4.2 Découverte clé : taux de restauration de précision

Pour la méthode llama.cpp :

Niveau	Précision moyenne restaurée	Confiance
8-bit	>99 %	IC 95 % chevauche BF16
4-bit	98,9 %	Légèrement sous la baseline, écart minime
3-bit	~96 %	Baisse notable, mais utilisable

Conclusion : 8-bit quasi sans perte, 4-bit restaure 98,9 % de la précision en moyenne.

« IC 95 % chevauche BF16 » signifie qu’en 8-bit, les performances ne diffèrent pas significativement de l’original BF16 sur le plan statistique.

4.3 Grands vs petits modèles : impact différent

Plus le modèle est grand, moins la quantification affecte la précision.

Un 70B en 4-bit se comporte presque comme l’original. Un 7B en 4-bit montre une baisse perceptible.

Raison : les grands modèles ont plus de paramètres et de redondance — la perte de précision est compensée. Les petits modèles, plus fragiles après compression.

Conséquences :

• Grands modèles : Q4 acceptable — 70B Q4_K_M proche de l’original
• Petits modèles : Q5+ recommandé — pour un 7B, Q5_K_M ou Q6_K si la VRAM le permet

4.4 Idée reçue : pourquoi certains disent que la quantification « abrutit » ?

Red Hat analyse ce phénomène : le problème vient souvent de la méthode d’évaluation, pas de la quantification elle-même.

Un seul benchmark académique (ex. MMLU) peut montrer −5 % et conduire à conclure que le modèle s’est dégradé. Un benchmark isolé ne représente pas l’usage réel.

Avec des tâches réelles (Arena-Hard, HumanEval), les modèles quantifiés performent quasi comme l’original.

En pratique (chat, code, résumé), la perte est rarement perceptible. Seuls certains benchmarks extrêmes révèlent un écart.

Mon ressenti : Q4_K_M chatte et résume fluidement ; en code, erreurs de détail plutôt qu’une dégradation globale. Q5_K_M corrige la plupart de ces cas.

5. Ollama en pratique : choisir et exécuter des modèles quantifiés

Passons à l’opérationnel : comment choisir le niveau de quantification dans Ollama ?

5.1 Comportement par défaut d’Ollama

ollama pull ou ollama run sur un modèle officiel télécharge par défaut une version Q4_K_M.

ollama pull llama3

Cette commande récupère Llama 3 8B en Q4_K_M — le compromis mémoire/qualité privilégié par Ollama.

Pour un autre niveau ?

5.2 Récupérer un modèle quantifié précis depuis Hugging Face

Ollama peut tirer directement des GGUF depuis Hugging Face :

ollama run hf.co/{utilisateur}/{dépôt}:{niveau}

Exemple — Llama 3.2 3B en Q8_0 :

ollama run hf.co/bartowski/Llama-3.2-3B-Instruct-GGUF:Q8_0

bartowski est un publieur actif de modèles quantifiés sur Hugging Face. Cherchez GGUF — par ex. Llama-3 GGUF.

Dépôts courants :

• bartowski : mises à jour fréquentes, large choix
• MaziyarPanahi : grands modèles (70B+)
• TheBloke : référence historique (certains modèles plus maintenus)

5.3 Recommandations matérielles

La VRAM détermine le niveau de quantification. Référence pour cartes NVIDIA :

VRAM	Modèle recommandé	Quantification	Remarque
4 Go	3B	Q4_K_M	Petit modèle, basse quantification, limite
6 Go	7B	Q4_K_M (serré)	3B en Q5_K_M plus stable
8 Go	7B	Q5_K_M	8B en Q4_K_M, marge conseillée
12 Go	7B	Q6_K / Q8_0	14B en Q5_K_M
16 Go	14B	Q6_K	7B en Q8_0, 30B MoE en Q4_K_M
24 Go	30B+	Q5_K_M	70B en Q4_K_M (quantification requise)

Points d’attention :

• La VRAM fluctue : KV cache et buffer de contexte s’ajoutent au modèle. Gardez 10-20 % de marge.
• Longueur de contexte : plus de contexte = plus de KV cache. Prévoyez en conséquence.
• Modèles MoE : Mixtral 8x7B (47B paramètres) n’active qu’une partie à l’inférence — empreinte mémoire inférieure à un dense équivalent.

5.4 Principe clé : petit modèle bien quantifié > grand modèle mal quantifié

Exemple avec 8 Go de VRAM :

• 7B Q5_K_M (~5,3 Go)
• 13B Q2_K (~5,0 Go)

Lequel performe le mieux ?

7B Q5_K_M > 13B Q2_K.

13B Q2_K est trop agressif — la qualité s’effondre malgré plus de paramètres. 7B Q5_K_M conserve la précision et surpasse globalement.

Conseil : priorisez le niveau de quantification, puis la taille. Si Q5 passe, ne descendez pas à Q3 ; si 7B Q5 passe, n’essayez pas 13B Q2.

5.5 Test réel : ma config RTX 3060

Ma RTX 3060 12 Go, configurations habituelles :

• Chat quotidien : Llama 3.2 3B Q8_0 (VRAM suffisante, qualité maximale)
• Programmation : Llama 3 8B Q5_K_M (qualité prioritaire)
• Tester un grand modèle : Mixtral 8x7B Q4_K_M (MoE, 12 Go juste suffisant)

Le 3B Q8_0 chatte parfois mieux qu’un 8B Q4_K_M (avantage du petit modèle bien quantifié). En code, Q5_K_M réduit nettement les erreurs vs Q4.

Conclusion

La quantification permet d’exécuter de grands modèles sur du matériel grand public. Un 70B qui exigeait 140 Go de VRAM descend à ~40 Go — technologie clé pour démocratiser les LLM.

L’inquiétude sur la perte de précision peut être levée : 8-bit quasi sans perte (>99 %), 4-bit maîtrisé (98,9 %). En usage courant, la différence est rarement perceptible.

Principes de choix :

• Dans la limite VRAM, privilégiez une quantification élevée : Q5 plutôt que Q3
• Adaptez à la tâche : Q5+ pour le code, Q4 pour le chat
• Grands modèles : quantification plus basse acceptable — 70B Q4 plus stable qu’un 7B Q4

Mon conseil : commencez par Q5_K_M — seulement ~20 % de mémoire en plus que Q4, qualité nettement supérieure. Testez, puis ajustez selon vos besoins.

Pour approfondir : Guide d’introduction Ollama et Paramètres Modelfile. Le Modelfile permet aussi de personnaliser la quantification — combinez avec cet article pour une configuration plus flexible.

La quantification n’est pas de la magie noire : un équilibre entre mémoire et qualité. Maîtrisez-le, et votre GPU fera tourner des modèles plus grands pour plus de tâches.