Points clés
- La quantification convertit les poids 16 bits en 4 bits ou 8 bits, réduisant la RAM de 50-75%.
- Q4_K_M est le niveau standard recommandé -- meilleur équilibre entre qualité et RAM pour le matériel grand public.
- Un modèle 7B en FP16 = ~14 GB RAM. En Q4_K_M = ~4.5 GB. En Q8_0 = ~7 GB.
- La perte de qualité en Q4_K_M est de 1-3% sur les benchmarks MMLU par rapport à FP16 -- imperceptible dans la plupart des tâches pratiques.
- GGUF est le format de fichier qui stocke les modèles quantifiés pour llama.cpp, Ollama et LM Studio.
Qu'est-ce que la quantification LLM et pourquoi est-elle importante ?
Un grand modèle de langage stocke ses connaissances sous forme de milliards de poids numériques. Par défaut, ils sont stockés sous forme de nombres flottants 16 bits (FP16) -- deux octets par poids. Un modèle 7B a 7 milliards de poids, donc la taille du fichier FP16 est d'environ 14 GB.
La quantification remplace ces flottants 16 bits par des entiers de précision inférieure. Avec la quantification 4 bits, chaque poids utilise 0.5 octet au lieu de 2 -- réduisant la mémoire à ~3.5 GB pour les poids seuls. Avec la surcharge des métadonnées, un modèle 7B quantifié en Q4_K_M est d'environ 4.5 GB.
C'est important pour l'inférence locale car le matériel grand public a une RAM limitée. Sans quantification, un modèle 7B nécessite 16 GB de RAM. Avec la quantification Q4_K_M, le même modèle s'exécute sur 6 GB de RAM, le rendant accessible sur la plupart des ordinateurs portables modernes.
Qu'est-ce que la quantification Q4_K_M ?
Q4_K_M est un format de quantification GGUF 4-bit utilisé dans llama.cpp et Ollama. Le "K" signifie qu'il utilise K-quants (précision mixte), et "M" = moyen — un équilibre entre la taille du modèle, la vitesse et la perte de qualité. Q4_K_M stocke la plupart des poids à 4 bits mais utilise 6 bits pour les couches les plus sensibles, ce qui lui donne un meilleur rapport taille-qualité que le pur 4-bit Q4_0.
- Q4_K_M utilise ~4,5 GB RAM pour un modèle 7B — 70% moins que FP16 — avec seulement 1–3% de perte de qualité
- K-quants appliquent une précision différente à différents groupes de poids selon la sensibilité (les poids importants obtiennent plus de bits)
- La variante "M" est la version standard recommandée (des variantes plus légères "S" et plus lourdes "L" existent aussi)
- Q4_K_M est le choix standard pour le matériel grand public avec 6–16 GB VRAM
- Fonctionne avec Ollama (`ollama run model:q4_k_m`), LM Studio et llama.cpp
Comment Q4_K_M, Q5_K_M, Q8_0 et d'autres niveaux diffèrent-ils ?
Les noms de quantification suivent un schéma : Q{bits}_{variante}. Le nombre de bits est la précision des poids ; la variante affecte la façon dont la quantification est appliquée :
| Niveau | Bits | RAM (7B) | Perte de qualité | Utilisation |
|---|---|---|---|---|
| Q2_K | 2 | ~2.7 GB | Élevée | RAM < 4 GB, perte de qualité acceptable |
| Q3_K_S | 3 | ~3.3 GB | Modérée | RAM 4-5 GB |
| Q4_K_M | 4 | ~4.5 GB | Faible (1-3%) | Par défaut pour la plupart des utilisateurs |
| Q5_K_M | 5 | ~5.7 GB | Minimale (<1%) | 16 GB RAM, meilleure qualité désirée |
| Q6_K | 6 | ~6.6 GB | Quasi sans perte | 16 GB RAM, tâches de codage/mathématiques |
| Q8_0 | 8 | ~7.7 GB | Négligeable | 16+ GB RAM, qualité maximale |
Qu'est-ce que le format GGUF et comment se rapporte-t-il à la quantification ?
GGUF (GPT-Generated Unified Format) est le format de fichier utilisé pour stocker les poids LLM quantifiés pour l'inférence locale. Il a été créé par le projet llama.cpp et remplace le format GGML plus ancien.
Un fichier GGUF contient : les poids du modèle quantifiés, toutes les métadonnées du modèle (architecture, tokenizer, longueur du contexte) et un numéro de version du format. Cette conception autonome signifie qu'un seul fichier `.gguf` est tout ce qui est nécessaire pour exécuter le modèle -- pas de fichiers tokenizer séparés, pas de JSON de configuration.
En avril 2026, GGUF est le format standard pour Ollama, LM Studio, Jan AI et GPT4All. Lorsque vous exécutez `ollama pull llama3.1:8b`, Ollama télécharge en interne un fichier GGUF. Lorsque LM Studio affiche les tailles de modèle, ce sont les tailles de fichier GGUF.
Le niveau de quantification fait partie du nom de fichier : `Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf` est une GGUF quantifiée en Q4_K_M de Llama 3.1 8B.
Combien de RAM la quantification économise-t-elle pour différentes tailles de modèles ?
| Taille du modèle | FP16 | Q8_0 | Q4_K_M | Q3_K_S |
|---|---|---|---|---|
| 3B | ~6 GB | ~3.8 GB | ~2 GB | ~1.6 GB |
| 7B | ~14 GB | ~7.7 GB | ~4.5 GB | ~3.3 GB |
| 13B | ~26 GB | ~14 GB | ~8.5 GB | ~6 GB |
| 34B | ~68 GB | ~36 GB | ~22 GB | ~16 GB |
| 70B | ~140 GB | ~70 GB | ~40 GB | ~30 GB |
Quelle qualité perdez-vous vraiment avec la quantification ?
La perte de qualité de la quantification est mesurée en exécutant les mêmes benchmarks sur le modèle en précision complète et la version quantifiée, puis en comparant les scores. En avril 2026, les conclusions établies sont :
La quantisation réduit l'utilisation de la mémoire mais peut dégrader la qualité des sorties. Des prompts bien conçus compensent : les techniques comme les exemples few-shot et les contraintes de sortie explicites aident les modèles quantisés à maintenir leur précision. Consultez les techniques de prompt engineering pour des méthodes qui fonctionnent à tout niveau de quantisation.
- Q4_K_M vs FP16 : dégradation de 1-3% sur MMLU. Sur un modèle 7B marquant 73% en FP16, Q4_K_M marque 71-72%. Dans les tâches pratiques, cette différence est imperceptible.
- Q3_K_S vs FP16 : dégradation de 5-10%. Notable sur les tâches de raisonnement complexe et mathématiques. Un modèle qui résout correctement un problème mathématique en FP16 peut échouer en Q3_K_S.
- Q2_K vs FP16 : dégradation de 15-25%. Perte de qualité significative pour tous les types de tâches. Utilisez uniquement si la contrainte de RAM est absolue.
- Q8_0 vs FP16 : dégradation inférieure à 0.5% -- pratiquement identique pour tous les objectifs pratiques.
- Les variantes K_M (K-Quant Medium) utilisent une approche de précision mixte qui préserve mieux la qualité que la quantification Q4_0 plus ancienne au même nombre de bits. Préférez toujours Q4_K_M à Q4_0 lorsque les deux sont disponibles.
Quel niveau de quantification devriez-vous utiliser ?
- 4-8 GB de RAM disponibles : Q4_K_M -- le meilleur équilibre pour le matériel limité.
- 8-16 GB de RAM disponibles : Q5_K_M ou Q6_K -- meilleure qualité avec un coussin de RAM confortable.
- 16+ GB de RAM disponibles : Q8_0 -- qualité quasi sans perte, aucune raison d'utiliser une quantification inférieure.
- GPU avec 24+ GB de VRAM : Q8_0 ou Q6_K aux tailles de modèles qui s'adaptent au VRAM.
- Traitement par lots / tâches nocturnes : Q4_K_M -- maximise le débit et la taille du modèle par RAM disponible.
- Tâches de codage ou mathématiques spécifiquement : utilisez Q5_K_M ou supérieur -- les effets de quantification sont plus visibles sur le raisonnement numérique et algorithmique précis. Pour un setup de codage air-gapped de bout en bout qui associe Qwen3-Coder en Q5_K_M à un fonctionnement totalement hors-ligne, voir LLM de codage local sans Internet.
- La quantisation affecte la précision ; la température affecte l'aléatoire : Un modèle Q4 à température 0,3 produit des sorties plus déterministes qu'un modèle pleine précision à température 1,0. Pour ajuster ces paramètres indépendamment, voir température et top-p : contrôler la créativité de l'IA.
Offloading : utiliser la RAM CPU comme extension du VRAM
L'offloading déplace une partie des poids du modèle du VRAM GPU vers la RAM système lorsque le modèle ne tient pas entièrement en VRAM. Le GPU continue de calculer les couches les plus actives ; le CPU prend en charge le reste.
Sur une RTX 4090 (24 GB VRAM) avec 64 GB de RAM système, Llama 3.3 70B Q4_K_M (~40 GB) peut s'exécuter par offloading : ~24 GB en VRAM, ~16 GB en RAM système. La vitesse chute à 5-10 tokens/sec (contre 40-50 tokens/sec en charge GPU totale), suffisant pour de nombreux cas d'usage batch.
ollama run llama3.3:70b
# Ollama gère automatiquement l'offloading selon le VRAM disponible
# Offloading explicite avec llama.cpp :
./llama-server -m llama-3.3-70b-q4_k_m.gguf --n-gpu-layers 40 --port 8080
# --n-gpu-layers contrôle combien de couches sont chargées en VRAM
# Les couches restantes sont déchargées vers le CPULayer splitting : répartir les poids du modèle sur plusieurs GPU
Le layer splitting distribue les couches du modèle sur plusieurs GPU, permettant une inférence avec des modèles dépassant le VRAM d'un seul GPU. Deux RTX 4090 de 24 GB chacune donnent 48 GB de VRAM combinés.
Pour Llama 3.3 70B Q5_K_M (~47 GB) sur deux RTX 4090 : couches 0-39 sur GPU 0, couches 40-79 sur GPU 1. Cela donne ~100 tokens/sec -- bien plus rapide que l'offloading, mais nécessite NVLink ou une bande passante PCIe-x16 entre les GPU.
# vLLM avec parallélisme tensoriel sur 2 GPU :
python -m vllm.entrypoints.openai.api_server \
--model meta-llama/Llama-3.3-70B-Instruct \
--tensor-parallel-size 2 \
--port 8000
# llama.cpp avec répartition explicite des couches GPU :
./llama-server \
-m llama-3.3-70b-q5_k_m.gguf \
--n-gpu-layers 80 \
--split-mode row \
--main-gpu 0Approche hybride : combiner quantification + offloading + layer splitting
La configuration la plus puissante combine les trois techniques. Trois scénarios typiques :
- RTX 4090 unique + offloading : Llama 3.3 70B Q4_K_M fonctionne avec 24 GB VRAM + 16 GB RAM système. Idéal pour une utilisation 70B occasionnelle sans configuration multi-GPU. 5-10 tokens/sec.
- 2× RTX 4090 layer split : Llama 3.3 70B Q5_K_M tient entièrement en VRAM (48 GB combinés). Pas de ralentissement par offloading. ~100 tokens/sec. Nécessite NVLink ou bande passante PCIe suffisante.
- Mac Studio M2 Ultra : exécution native 70B avec 192 GB de mémoire unifiée -- pas d'offloading requis. ~35 tokens/sec avec une faible complexité système.
Compromis de performance : quantification vs. offloading vs. layer splitting
| Technique | Économie VRAM | Impact vitesse | Impact qualité |
|---|---|---|---|
| Quantification seule | Jusqu'à 75% | Aucun | Perte 1-3% pour Q4_K_M |
| Offloading seul | Jusqu'à 60% | Élevé (5-10×) | Aucune perte |
| Layer splitting | 50% par GPU | Faible (<10%) | Aucune perte |
| Q4 + offloading | Jusqu'à 85% | Modéré (3-5×) | Légère perte |
Mac Studio M2 Ultra : 70B natif sans offloading
Mac Studio M2 Ultra avec 192 GB de mémoire unifiée exécute Llama 3.3 70B en Q4 nativement -- aucun offloading, aucun layer splitting requis.
Physique de la bande passante mémoire : la mémoire unifiée accède au CPU et au GPU à ~800 GB/s, contre 90 GB/s pour la RAM système DDR5 en offloading.
| Configuration | Modèle | Vitesse | Complexité |
|---|---|---|---|
| 1× RTX 4090 + offloading | Llama 3.3 70B Q4 | 5-10 tok/sec | Moyenne |
| 2× RTX 4090 layer split | Llama 3.3 70B Q5 | ~100 tok/sec | Élevée |
| 1× RTX 5090 (32 GB) | Llama 3.3 70B Q4 | 10-12 tok/sec | Faible |
| Mac Studio M2 Ultra | Llama 3.3 70B Q4 | 35 tok/sec | Faible |
Station de travail 2× RTX 4090 : ~4 500 €. Mac Studio M2 Ultra (192 GB) : ~6 600 €.
Contexte régional pour la quantification LLM locale
Les considérations de quantification varient selon la juridiction en raison des cadres réglementaires, de souveraineté et de conformité :
- UE/RGPD -- Les organisations opérant dans l'UE préfèrent exécuter localement les modèles quantifiés pour éviter le transfert de données transfrontalier en vertu des articles 5 et 44 du RGPD. La quantification permet aux modèles 7B de s'exécuter sur des appareils edge avec 6 GB de RAM, soutenant les principes RGPD de "minimisation des données". Pas besoin d'API cloud pour l'inférence. La CNIL (Commission Nationale de l'Informatique et des Libertés) recommande l'inférence locale lors du traitement de données professionnelles sensibles (données financières, médicales, juridiques).
- Japon/METI -- Le Ministère japonais de l'économie, du commerce et de l'industrie (METI) promeut la souveraineté de l'IA intérieure. Les modèles quantifiés Qwen2.5 et Llama s'exécutent sur l'infrastructure d'entreprise japonaise sans traitement tiers. La quantification Q4_K_M rend les modèles 13B+ viables sur les serveurs d'entreprise 16 GB.
- Chine -- L'exploitation locale est légalement requise pour la plupart des applications d'IA en vertu de la réglementation CAC. La quantification soutient l'exécution de grands modèles natifs chinois (Qwen2.5, Baichuan) sur du matériel national avec des coûts d'infrastructure réduits. La quantification Q4_K_M et Q5_K_M permet la conformité on-premises locale.
Quelles sont les erreurs courantes avec la quantification LLM ?
- Télécharger Q4_0 au lieu de Q4_K_M -- Q4_0 est une méthode de quantification plus ancienne sans améliorations K-Quant. Q4_K_M est 5-8% meilleure qualité au même encombrement de RAM. Choisissez toujours Q4_K_M lorsque les deux sont disponibles.
- Supposer qu'une quantification plus élevée signifie toujours une pire qualité -- Les chiffres sont contre-intuitifs : nombre Q plus élevé = plus de bits = meilleure qualité. Q8_0 est meilleur que Q4_K_M. Un modèle 70B Q4_K_M surpassera un modèle 7B Q8_0 sur la plupart des tâches.
- Ne pas vérifier l'espace RAM avant de charger un modèle -- La taille du modèle n'est pas le seul consommateur de RAM. L'OS, le navigateur et les autres applications utilisent aussi RAM. Sur une machine 8 GB, un modèle 4.5 GB Q4_K_M 7B ne laisse que 3.5 GB pour le reste -- ce qui est serré. Fermez les navigateurs avant de charger les modèles 7B sur les machines 8 GB. Règle : taille du fichier modèle + 2 GB surcharge OS + 1 GB marge = RAM requise minimum.
Questions fréquemment posées sur la quantification LLM
Ollama utilise-t-il automatiquement la meilleure quantification ?
Oui -- lorsque vous exécutez `ollama pull llama3.1:8b`, Ollama télécharge la variante Q4_K_M par défaut. Pour tirer une quantification spécifique, ajoutez le tag : `ollama pull llama3.1:8b-instruct-q5_K_M`. Les tags de quantification disponibles pour chaque modèle sont listés sur la page du modèle sur ollama.com/library.
Puis-je quantifier un modèle moi-même au lieu de télécharger une version pré-quantifiée ?
Oui -- llama.cpp inclut un binaire `quantize` qui convertit les fichiers GGUF à n'importe quel niveau de quantification pris en charge. Le processus prend 5-30 minutes selon la taille du modèle. La plupart des utilisateurs devraient télécharger les fichiers GGUF pré-quantifiés de Hugging Face plutôt que de quantifier eux-mêmes, car les résultats sont équivalents.
La quantification affecte-t-elle la fenêtre de contexte du modèle ?
Non -- la quantification n'affecte que la précision des poids du modèle, pas la longueur du contexte. Un modèle Llama 3.1 8B prend en charge 128K tokens, qu'il soit quantifié en Q4_K_M ou exécuté en FP16. Cependant, traiter des contextes plus longs nécessite plus de RAM indépendamment de la quantification.
Quelle est la différence entre la quantification GGUF et GPTQ ?
GGUF (format llama.cpp) et GPTQ sont deux approches différentes. GGUF utilise K-Quants et s'exécute sur CPU et GPU. GPTQ est uniquement GPU et nécessite PyTorch. Pour l'inférence locale avec Ollama, LM Studio ou Jan AI, GGUF est le format correct. GPTQ est utilisé avec des frameworks d'inférence GPU comme AutoGPTQ et vLLM.
Y a-t-il une différence de qualité entre les modèles Q4_K_M de différents fournisseurs sur Hugging Face ?
L'algorithme de quantification est standardisé dans llama.cpp, donc les quantifications Q4_K_M du même modèle de base devraient être pratiquement identiques indépendamment du créateur du fichier GGUF. Cependant, certains fournisseurs appliquent des ajustements supplémentaires (quantification imatrix) qui améliorent la qualité.
Qu'est-ce que la quantification imatrix ?
La quantification imatrix (matrice d'importance) utilise les données d'étalonnage pour assigner différents niveaux de précision aux poids selon leur importance pour la sortie du modèle. Les poids qui affectent le plus les prédictions sont quantifiés avec plus de bits ; les poids moins importants utilisent moins de bits. Résultat : meilleure qualité au même nombre de bits par rapport à la quantification uniforme.
Quelle est la différence entre Q4_K_M et Q4_K_S ?
Les deux sont une quantification 4 bits, mais K_M (Medium) et K_S (Small) diffèrent dans l'allocation de mémoire par bloc de quantification. Q4_K_M utilise plus de métadonnées pour une meilleure reconstruction de qualité. Q4_K_S est plus agressif -- économise 300-400 MB comparé à K_M mais avec perte de qualité 3-5%.
Puis-je basculer entre les niveaux de quantification sans retélécharger le modèle ?
Non -- basculer entre les niveaux de quantification nécessite de télécharger un fichier GGUF différent ou de re-quantifier le modèle de base vous-même. Une fois qu'un modèle est quantifié en Q4_K_M, vous ne pouvez pas le reconvertir en Q5_K_M sans le modèle FP16 original.
Comment la quantification affecte-t-elle la vitesse d'inférence ?
La quantification augmente généralement la vitesse d'inférence de 10-40% car charger et traiter les poids 4 bits est plus rapide que les flottants 16 bits. Un modèle 7B Q4_K_M s'exécute à ~8-12 tok/s sur une CPU grand public ; le même modèle en FP16 s'exécute à ~1-2 tok/s.
Quel niveau de quantification Ollama utilise-t-il par défaut ?
Ollama utilise par défaut Q4_K_M pour tous les modèles de sa bibliothèque. Lorsque vous exécutez `ollama pull llama3.1:8b`, vous téléchargez la variante Q4_K_M. Ce défaut équilibre bien la qualité et les exigences de RAM pour la plupart des utilisateurs. Pour tirer une quantification différente, ajoutez le tag : `ollama pull llama3.1:8b:q5_k_m` ou `ollama pull llama3.1:8b:q8_0`.
Puis-je exécuter Llama 3.3 70B sur une seule RTX 4090 ?
Oui, avec l'offloading. Llama 3.3 70B Q4_K_M nécessite ~40 GB -- plus que les 24 GB VRAM de la RTX 4090. Avec l'offloading CPU : ~24 GB en VRAM, ~16 GB en RAM système. La vitesse est de 5-10 tokens/sec contre 40-50 tokens/sec en charge GPU totale. Pour de meilleures performances : 2× RTX 4090 avec layer splitting (~100 tokens/sec) ou Mac Studio M2 Ultra (35 tokens/sec sans offloading).
Quelle est la différence entre quantification et offloading ?
La quantification réduit la précision numérique des poids du modèle (FP16 → 4 bits), réduisant les besoins en mémoire de 50-75%. L'offloading déplace des parties d'un modèle vers la RAM système ou le CPU quand il ne tient pas en VRAM. La quantification réduit la taille totale ; l'offloading permet d'exécuter des modèles plus grands que le VRAM avec une perte de vitesse.
Le Mac Studio M2 Ultra nécessite-t-il une quantification pour les modèles 70B ?
Non -- Mac Studio M2 Ultra avec 192 GB de mémoire unifiée exécute Llama 3.3 70B en FP16 (140 GB) ou Q4_K_M nativement. Pas d'offloading requis. Q4_K_M est recommandé pour ~35 tokens/sec contre ~15-20 tokens/sec en FP16, car la bande passante mémoire est le facteur limitant.
Quelle combinaison de techniques est la meilleure pour mon matériel ?
Pour 8 GB VRAM (RTX 4060 Ti) : Q4_K_M pour les modèles jusqu'à 7B. Pour 24 GB VRAM (RTX 4090) : Q4_K_M nativement pour 7-13B ; pour 70B avec offloading et 64 GB RAM. Pour 2× 24 GB VRAM : layer splitting pour 70B en Q5_K_M avec ~100 tokens/sec. Pour Apple Silicon : utilisez la mémoire unifiée directement -- Q4_K_M pour l'optimisation de la vitesse.
Sources
- Documentation de quantification llama.cpp -- github.com/ggerganov/llama.cpp/blob/master/examples/quantize/README.md
- Discussion technique K-Quants -- github.com/ggerganov/llama.cpp/pull/1684 (PR K-Quant original)
- Spécification du format GGUF -- github.com/ggerganov/ggml/blob/master/docs/gguf.md
- Benchmarks de quantification Open LLM Leaderboard -- huggingface.co/spaces/open-llm-leaderboard/open_llm_leaderboard