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 la quantification Q8_0 ?
Q8_0 est un format de quantification GGUF 8 bits pratiquement sans perte — moins de 0.5% de dégradation de qualité par rapport à FP16 — pour environ la moitié de la taille du fichier. Chaque poids est stocké sur 8 bits plus une petite échelle par bloc, donc un modèle 7B fait ~7.7 GB au lieu de ~14 GB en FP16. Contrairement aux K-quants (Q4_K_M, Q5_K_M), Q8_0 utilise une précision uniforme de 8 bits pour chaque poids — il n'existe pas de variante mixte "K", car 8 bits préservent déjà la quasi-totalité de l'information.
- Q8_0 utilise ~7.7 GB de RAM pour un modèle 7B — environ 45% de moins que FP16 — avec une perte de qualité négligeable
- Meilleur choix avec 16+ GB de VRAM lorsque vous visez une fidélité maximale (codage, mathématiques, agents)
- Peu d'avantage mesurable par rapport à Q6_K pour le chat général, mais le choix le plus sûr quand la qualité prime
- Exécutez avec `ollama run model:q8_0`, ou sélectionnez la GGUF Q8_0 dans LM Studio
Q4_0 vs Q4_K_M : quel format 4 bits est meilleur ?
Choisissez Q4_K_M plutôt que Q4_0. Les deux font en moyenne 4 bits par poids, mais Q4_K_M est un K-quant qui stocke les couches les plus sensibles en 6 bits, récupérant 5 à 8% de qualité pour le même encombrement d'environ 4.5 GB sur un modèle 7B. Q4_0 est le format 4 bits uniforme d'origine des premières versions de llama.cpp et n'existe aujourd'hui que pour la compatibilité héritée. Aucune raison de taille ou de vitesse ne justifie Q4_0 lorsque Q4_K_M est disponible.
| Format | Méthode | RAM (7B) | Qualité | À choisir quand |
|---|---|---|---|---|
| Q4_0 | 4 bits uniforme (hérité) | ~4.0 GB | ~5–8% pire que Q4_K_M | Uniquement si Q4_K_M est indisponible |
| Q4_K_M | K-quant, 4/6 bits mixte | ~4.5 GB | 1–3% de perte vs FP16 | Par défaut pour presque tout le monde |
Q4_K_M vs Q4_K_S : K-quant moyen vs petit
Q4_K_M et Q4_K_S sont deux K-quants 4 bits ; la différence tient au nombre de couches conservées en haute précision. Q4_K_M (Medium) garde davantage de couches sensibles en 6 bits, tandis que Q4_K_S (Small) pousse plus de poids en 4 bits pour économiser ~0.3–0.4 GB sur un modèle 7B. Mesuré sur llama.cpp, Q4_K_S ajoute environ +0.11 de perplexité à 7B contre +0.05 pour Q4_K_M — soit environ 3 à 5% de perte de qualité supplémentaire. Ne choisissez Q4_K_S que lorsque ces quelques centaines de mégaoctets déterminent si le modèle tient en VRAM.
| Format | Variante | RAM (7B) | Perte de qualité | À choisir quand |
|---|---|---|---|---|
| Q4_K_S | Small | ~4.1 GB | ~4–6% (faible mais réelle) | Besoin de ~0.4 GB pour tenir en VRAM |
| Q4_K_M | Medium | ~4.5 GB | 1–3% (équilibré) | Par défaut — meilleure qualité pour ~0.4 GB de plus |
Q8_0 vs Q4_K_M : le 8 bits vaut-il le double de VRAM ?
Pour la plupart des tâches de chat et de rédaction, Q4_K_M est le meilleur compromis — il utilise ~4.5 GB pour un modèle 7B contre ~7.7 GB pour Q8_0, avec seulement 1 à 3% de perte de qualité en plus. Choisissez Q8_0 (16+ GB de VRAM requis) lorsque vous visez une fidélité maximale pour le codage, les mathématiques ou l'usage agentique d'outils, où les petites erreurs s'accumulent. Q8_0 perd moins de 0.5% par rapport à FP16 ; Q4_K_M perd 1 à 3%. L'écart est imperceptible à l'usage quotidien mais peut compter sur du raisonnement numérique précis.
| Format | Bits | RAM (7B) | Perte de qualité | Idéal pour |
|---|---|---|---|---|
| Q4_K_M | ~4 | ~4.5 GB | 1–3% | 6–16 GB VRAM, usage général |
| Q8_0 | 8 | ~7.7 GB | <0.5% | 16+ GB VRAM, codage/maths/agents |
Q8_0 vs Q8_K_XL : 8 bits standard vs upcast dynamique
Q8_0 est le quant 8 bits standard de llama.cpp — chaque poids en 8 bits, ~7.7 GB pour un modèle 7B, moins de 0.5% de perte par rapport à FP16. Q8_K_XL n'est pas un type natif de llama.cpp : c'est une variante GGUF "Dynamic" d'Unsloth qui conserve une base 8 bits mais upcaste les couches les plus sensibles (embeddings, attention et sortie) en 16 bits (BF16/F16), rapprochant la qualité du FP16 complet pour une taille de fichier légèrement supérieure. Q8_K_XL vise les utilisateurs qui veulent la dernière fraction de pourcent de précision et disposent de VRAM en réserve.
Les tailles exactes des fichiers Q8_K_XL varient selon le modèle et le nombre de couches upcastées par Unsloth ; vérifiez donc la taille affichée dans votre outil (LM Studio ou Hugging Face) avant le téléchargement. Pour un modèle 7B–8B, attendez-vous à un peu plus que Q8_0 ; sur les très grands modèles, l'écart est plus large. Comme Q8_0 est déjà pratiquement sans perte pour la plupart des utilisateurs, Q8_K_XL ne se justifie que si vous avez spécifiquement besoin d'une fidélité maximale et que la VRAM supplémentaire est gratuite.
| Format | Type | Précision | Qualité | À choisir quand |
|---|---|---|---|---|
| Q8_0 | llama.cpp standard | 8 bits uniforme | <0.5% de perte vs FP16 | Qualité maximale, outillage standard |
| Q8_K_XL | GGUF Dynamic Unsloth | 8 bits + couches clés upcastées en 16 bits | Quasi sans perte (plus grande option 8 bits) | Vise les derniers 0.5% de fidélité, VRAM disponible |
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.3 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.
- Maison connectée et appareils edge : Q4_K_M (4–8 Go VRAM) est la quantification idéale pour l'IA domotique toujours active sur un mini PC. Voir meilleurs LLM locaux pour maison connectée →.
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 Qwen3 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 (Qwen3, 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.
Étapes suivantes
- Combien de VRAM me faut-il ? — Appliquez vos connaissances en quantification à votre budget VRAM →
- Meilleurs LLM sur CPU uniquement — Meilleurs modèles quantifiés pour l'inférence CPU →
- Meilleurs modèles open source sur Ollama — Maintenant que vous connaissez les niveaux de quant, choisissez un modèle →
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.3 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%.
Quelle est la différence entre Q8_0 et Q8_K_XL ?
Q8_0 est la quantification 8 bits standard de llama.cpp -- chaque poids en 8 bits, environ 7.7 GB pour un modèle 7B, moins de 0.5% de perte de qualité par rapport à FP16. Q8_K_XL n'est pas un type natif de llama.cpp ; c'est une variante GGUF "Dynamic" d'Unsloth qui conserve une base 8 bits mais upcaste les couches les plus sensibles (embeddings, attention, sortie) en 16 bits, rapprochant la qualité du FP16 complet pour une taille de fichier légèrement supérieure. Q8_0 étant déjà pratiquement sans perte pour la plupart des utilisateurs, Q8_K_XL n'aide que si vous avez besoin de la dernière fraction de pourcent de précision et disposez de VRAM en réserve. Les tailles de fichier varient selon le modèle -- vérifiez la taille dans LM Studio ou sur Hugging Face avant le téléchargement.
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
Journal de mises à jour
- 2026-06-15 : Ajout de sections comparatives directes (Q4_0 vs Q4_K_M, Q4_K_M vs Q4_K_S, Q8_0 vs Q4_K_M, Q8_0 vs Q8_K_XL) et d'une réponse dédiée « Qu'est-ce que Q8_0 ? » ; ajout de la couverture de Q8_K_XL ; faits revérifiés en juin 2026.
- 2026-05-17: Titre mis à jour pour refléter une intention orientée vers la décision ; contenu inchangé.