Comprendre la quantification pour exécuter des LLM sur du matériel grand public
La quantification est une technique de compression qui réduit la précision des nombres utilisés dans un modèle de deep learning. Les poids et les activations d'un modèle sont normalement stockés en float32 (FP32), soit 32 bits par valeur. La quantification réduit ce nombre de bits (8, 4, 3, etc.) pour diminuer la taille du modèle et accélérer l'inférence, au prix d'une perte de précision souvent minime.
Imaginez que vous prenez une photo : en haute résolution (FP32), chaque pixel a 16 millions de couleurs possibles. En basse résolution (INT4), chaque pixel n'a que 16 couleurs. L'image est moins détaillée, mais elle est beaucoup plus légère et se transmet plus vite. Pour un modèle IA, c'est pareil : on sacrifie un peu de finesse pour gagner en efficacité.
Les grands modèles de langage comme Qwen3.6-35B-A3B sont énormes. En FP16, le modèle pèse 70.5 Go. Cela nécessite une carte GPU professionnelle avec 80 Go de VRAM. La quantification rend l'exécution locale possible sur du matériel grand public.
70.5 Go — Nécessite un GPU A100/H100 (plusieurs milliers d'euros). Qualité maximale, coût prohibitif pour un particulier.
21.9 Go — Tourne sur une RTX 3090/4090, MacBook M2/M3 24 Go. Pertes de qualité quasi-inexistantes pour l'usage courant.
15.8 Go — Peut tourner sur des cartes 16 Go. Qualité significativement dégradée, mais modèle utilisable sur matériel limité.
La quantification ne se résume pas à une simple réduction de bits. Les formats GGUF (le standard utilisé par Ollama et llama.cpp) emploient des techniques sophistiquées :
Au lieu de quantifier chaque poids individuellement, les poids sont regroupés par blocs (généralement 32 ou 64 poids par groupe). Chaque groupe a sa propre valeur de scaling (facteur d'échelle) et de décalage (offset). Cela permet de préserver la distribution des données originales bien mieux qu'une quantification par poids unique.
Les formats Q4_K_M, Q5_K_M, etc. utilisent des tailles de bits différentes selon l'importance des poids. Les poids les plus sensibles (ceux qui impactent le plus la sortie du modèle) sont conservés en haute précision, tandis que les moins importants sont quantifiés plus agressivement. C'est ce qui rend ces formats si efficaces : on ne sacrifie pas uniformément, mais de manière intelligente.
GGUF est le format de fichier développé par llama.cpp. Il stocke les poids quantifiés avec leur métadonnée (scaling, offset, shape) de manière à pouvoir restaurer les valeurs originales (approximativement) lors de l'inférence. C'est le format supporté par défaut par Ollama.
Qwen3.6-35B-A3B est disponible en 14 formats. Voici ce que chaque famille signifie :
Les formats IQ3_XXS, IQ3_XS, IQ3_M utilisent une quantification extrêmement agressive. Ils sont conçus pour tourner sur du matériel avec très peu de VRAM (8-16 Go). La qualité est notablement dégradée : le modèle perd en cohérence, peut halluciner plus, et sa capacité de raisonnement est réduite. Utile en dernier recours.
Q3_K_S et Q3_K_M offrent un bon compromis entre taille et qualité. Avec 3.64 à 4.0 bits par poids, le modèle tient dans 16-18 Go de VRAM. La qualité reste correcte pour de nombreux usages, mais commence à montrer des signes de dégradation sur des tâches complexes (raisonnement mathématique, coding agentic).
C'est la zone idéale. Les formats Q4_K_S et Q4_K_M offrent le meilleur équilibre. La différence entre Q4_K_S (4.5 bits) et Q4_K_M (4.89 bits) est subtile : le Q4_K_M utilise une distribution de bits plus fine (certains poids à 5 bits, d'autres à 4), ce qui lui donne un léger avantage en qualité pour seulement 1.7 Go de plus. C'est le choix recommandé pour la plupart des utilisateurs.
Q5_K_S et Q5_K_M offrent une qualité quasi-identique au FP16 pour la plupart des tâches. Si vous avez la VRAM disponible (25 Go+), c'est le choix optimal si vous voulez minimiser la perte de qualité. La différence avec Q4 est perceptible sur des tâches de raisonnement complexe, mais imperceptible sur du chat quotidien.
Q8_0 (8.5 bits) et FP16 (16 bits) sont des formats sans perte significative. FP16 est le format original du modèle. Ces formats nécessitent 37.7 Go (Q8) à 70.5 Go (FP16) de VRAM. Ils sont utiles pour l'entraînement, le fine-tuning, ou les benchmarks officiels. Pour l'inférence locale sur matériel grand public, ils sont inaccessibles.
| Famille | Formats | BPW | VRAM min. | Qualité | Usage recommandé |
|---|---|---|---|---|---|
| IQ | IQ3_XXS, IQ3_XS, IQ3_M | 3.25 - 3.72 | 14.7 Go | Faible | Matériel très limité |
| Q3 | Q3_K_S, Q3_K_M, Q3_K_L | 3.64 - 4.25 | 16.4 Go | Faible-Moyen | Compromis taille/qualité |
| Q4 | Q4_K_S, Q4_K_M | 4.5 - 4.89 | 20.2 Go | Bonne | Recommandé |
| Q5 | Q5_K_S, Q5_K_M | 5.57 - 5.7 | 24.9 Go | Excellente | Haute fidélité |
| Q8 | Q8_0 | 8.5 | 37.7 Go | Lossless | Benchmarks / Fine-tuning |
| FP16 | FP16 | 16.0 | 70.5 Go | Lossless | Entraînement / Serveur |
C'est la question la plus fréquente. Les deux formats offrent des performances très proches, mais avec des compromis différents :
20.2 Go de VRAM. Utilise une distribution de bits plus uniforme. Légèrement plus rapide à l'inférence car la quantification est plus régulière. Idéal si vous avez juste 20-24 Go de VRAM disponible.
21.9 Go de VRAM. Utilise une distribution mixte : certains poids à 5 bits, d'autres à 4 bits. Meilleure fidélité au modèle original (environ +0.3% en moyenne sur les benchmarks). Le choix recommandé par défaut.
En résumé : Si vous avez 24 Go de VRAM, prenez Q4_K_M. La différence de qualité (0.3-0.5% en moyenne) vaut les 1.7 Go supplémentaires. Si vous êtes à la limite avec 20 Go, Q4_K_S est un excellent choix.
La relation entre bits de quantification et qualité n'est pas linéaire. Voici ce que les benchmarks montrent :
Quasi-invisible en usage quotidien. Le modèle répond de manière cohérente, le coding et le raisonnement restent performants. C'est la zone où la quantification est recommandée.
Début des pertes perceptibles. Le modèle peut halluciner plus sur des questions complexes, la qualité du code généré baisse légèrement. acceptable pour du chat, moins pour du coding agentic.
Dégradation notable. Le modèle reste utilisable pour des tâches simples (résumé, traduction, questions factuelles), mais perd en capacité de raisonnement et de cohérence sur les longs contextes.
La quantification n'affecte pas seulement la taille, mais aussi la vitesse. Moins de bits = moins de données à transférer entre la VRAM et le GPU = plus de tokens par seconde.
| Quantification | Taille | VRAM | RTX 4090 (tok/s) | RTX 3090 (tok/s) |
|---|---|---|---|---|
| FP16 | 70.5 Go | 70.5 Go | — (ne tient pas) | — (ne tient pas) |
| Q8_0 | 37.7 Go | 37.7 Go | — (ne tient pas) | ~45 |
| Q4_K_M | 21.9 Go | 21.9 Go | ~120 | ~85 |
| Q3_K_M | 18.0 Go | 18.0 Go | ~135 | ~95 |
| IQ3_XS | 15.8 Go | 15.8 Go | ~145 | ~100 |
* Les vitesses sont des estimations basées sur les benchmarks publics de llama.cpp. Les performances réelles varient selon le système, le contexte et la charge GPU.
Le choix dépend de trois facteurs : votre VRAM disponible, vos besoins en qualité, et votre matériel.
Q4_K_M est le choix idéal. 21.9 Go laissent ~2 Go pour le contexte et le système. Qualité excellente, vitesse excellente.
Q4_K_S ou Q3_K_M. Q4_K_S (20.2 Go) ne tiendra pas. Q3_K_M (18 Go) est le compromis possible. Qualité acceptable.
IQ3_XS ou IQ3_M. Le modèle tournera en CPU+GPU mixte. Lent mais fonctionnel. Qualité dégradée.
Mon conseil : Si vous avez une RTX 3090/4090 ou un MacBook avec 24 Go+, foncez sur Q4_K_M. C'est le sweet spot : qualité quasi-identique au FP16, taille divisée par 3, et vitesse excellente. C'est le format que j'utilise pour tourner localement !