GGUF, Q4, Q8, fp16 : le guide du pleb sur la quantification des LLM

Vous naviguez Hugging Face ou la bibliothèque d’Ollama et vous voyez des étiquettes de modèles comme llama3.1:8b-instruct-q4_K_M et llama3.1:70b-instruct-q5_0. Vous savez que c’est un modèle Llama. Vous savez que 8B et 70B renvoient au nombre de paramètres. Mais c’est quoi au juste q4_K_M et q5_0, et pourquoi chaque modèle est-il livré en une douzaine de saveurs ?

Voici la réponse en une phrase : la quantification est de la compression avec perte pour les poids des LLM — la même idée que le JPEG pour les images ou l’AAC pour l’audio. Elle rétrécit le modèle pour qu’il tienne dans moins de VRAM, et le coût en qualité est d’ordinaire assez faible pour passer inaperçu.

À la fin de ce billet, vous saurez ce que veulent dire fp16, bf16, int8 et int4, ce qu’est le GGUF et pourquoi il a mangé le monde, et quelle quantification précise télécharger (Q4_K_M vs Q5_0 vs Q6_K vs Q8_0 vs fp16) pour la machine que vous opérez.

Pourquoi la quantification existe

Les grands modèles de langage ont des milliards de paramètres — des nombres qui encodent tout ce que le modèle « sait ». Chaque paramètre est un nombre à virgule flottante.

En pleine précision (fp16, flottant 16 bits, 2 octets par poids), le calcul est brutal :

• Un modèle 7B = 7 milliards × 2 octets = 14 Go
• Un modèle 70B = 70 milliards × 2 octets = 140 Go

140 Go de VRAM, c’est quatre H100 dans une baie serveur. Ce n’est pas un budget de pleb.

Maintenant, quantifiez ces poids à 4 bits chacun au lieu de 16 :

• 7B à 4 bits ≈ 3,5 Go — tient sur un téléphone
• 70B à 4 bits ≈ 35 Go — tient sur deux 3090

Même modèle. Presque même comportement. Vous venez de jeter 75 % de la taille du fichier et 75 % de l’empreinte mémoire. La perte de qualité sur la plupart des tâches ? Quelques points de pourcentage sur les bancs d’essai. Pour le clavardage et le raisonnement général, la plupart des humains ne font pas la différence en test aveugle.

C’est littéralement le même compromis que vous faites chaque fois que vous enregistrez une photo en JPEG plutôt qu’en RAW, ou que vous rippez un CD en AAC plutôt qu’en FLAC. Vous échangez une fidélité minime contre une réduction massive de taille — et pour 99 % des cas, l’arbitrage coule de source.

Le spectre :

• Plus de compression → fichier plus petit, inférence plus rapide, tient sur du matériel moins cher, légère baisse de qualité
• Moins de compression → fichier plus gros, chargement plus lent, exige plus de VRAM, fidélité complète du modèle

Chaque quantification que vous croiserez se situe quelque part sur cette courbe.

Le zoo des précisions

Avant de déchiffrer les étiquettes, il faut connaître les formats numériques bruts. Voici la famille au complet :

fp32 — flottant 32 bits

Précision scientifique pleine. Chaque poids fait 4 octets. Presque personne ne fait tourner l’inférence en fp32 — c’est le territoire de l’entraînement. Pensez-y comme le RAW sorti du capteur de l’appareil : techniquement juste, beaucoup plus de données que nécessaire pour l’image finale.

fp16 / bf16 — flottant 16 bits

La référence « pleine qualité » pour l’inférence. Chaque poids fait 2 octets. Quand la fiche d’un modèle sur Hugging Face dit « original » ou « pleine précision », c’est presque toujours l’un des deux.

• fp16 a plus de précision mais une plage plus étroite
• bf16 (« brain float ») a moins de précision mais une plage plus large — meilleur pour l’entraînement, fonctionnellement équivalent pour l’inférence

Voyez fp16/bf16 comme l’export TIFF non compressé. Personne ne se plaint de la qualité. Le fichier est juste gros.

int8 / Q8 — entier 8 bits

Deux fois moins gros que fp16. La qualité est d’ordinaire indiscernable de fp16 pour la plupart des tâches. C’est le « JPEG-100 visuellement sans perte » de la quantification — vous pourriez l’opposer à la pleine précision en A/B et peiner à désigner un gagnant.

int4 / Q4 — entier 4 bits

C’est là que la plupart des plebs vivent réellement. Quatre fois moins gros que fp16. Coût en qualité faible, économies de taille massives. Le « sweet spot » pour les GPU grand public.

int2 / int3 — quantification agressive

2 ou 3 bits par poids. On les voit sur de très grands modèles (70B+) où « jeter 90 % des bits » laisse encore assez d’information pour fonctionner. Sur des petits modèles (≤7B), ces quantifications abîment visiblement la qualité de sortie.

fp8 — flottant 8 bits

Format plus récent, pris en charge nativement sur H100, H200 et RTX série 50 (Blackwell). Très utilisé par FLUX et certains déploiements de LLM. Meilleure plage dynamique que int8 pour le même budget en bits. Vous en verrez davantage en 2026 et au-delà, à mesure que le matériel de classe Blackwell ruisselle vers le marché de l’usagé.

Le tableau des tailles

Les tailles sont approximatives — les fichiers GGUF incluent des métadonnées, le tokenizer et les données de mise à l’échelle k-quant, ce qui les rend quelques pour cent plus lourds que ne le suggère le calcul brut.

GGUF — le format qui a gagné

Si vous avez téléchargé un modèle pour de l’inférence locale depuis deux ans, vous avez touché un fichier .gguf. GGUF est le standard de facto pour la distribution de LLM sur matériel grand public. Comprendre comment il en est arrivé là est une petite leçon d’histoire de l’IA open source.

La filiation passe par Georgi Gerganov, le développeur derrière llama.cpp — le petit moteur d’inférence C++ agressif qui a rendu possible l’exécution de LLaMA sur un MacBook dans les 48 heures suivant la fuite des poids début 2023. llama.cpp avait besoin d’un format de modèle compact, et Gerganov a bâti GGML pour le servir. GGML était bon, mais il avait des limites de conception : les métadonnées étaient maladroites, l’info de quantification était fragile, ajouter de nouvelles architectures cassait le format.

En août 2023, Gerganov et les contributeurs de llama.cpp ont publié le successeur : GGUF (GPT-Generated Unified Format). Même esprit — un seul binaire autonome que l’on peut mmap directement — avec chaque verrue de GGML corrigée.

Pourquoi GGUF a gagné

• Fichier unique. Poids, tokenizer, indices d’architecture, gabarit de chat, métadonnées — tout dans un seul .gguf. Plus de valse de quinze fichiers à télécharger.
• mmap-able. Le SE peut mapper le fichier en mémoire sans tout charger d’un coup. On peut faire tourner un modèle plus gros que la RAM, moyennant patience.
• Capable CPU + GPU. Le même fichier tourne en CPU seul, en déchargement GPU partiel ou en GPU complet — selon ce que vous avez.
• Métadonnées intégrées. Longueur de contexte, mise à l’échelle RoPE, vocabulaire, tokens BOS/EOS, gabarit de chat — le runtime lit simplement l’info. Pas de chasse au bon tokenizer.json.
• Sûr en boutisme et versionné. Fonctionne sur ARM, x86, Apple Silicon. De nouveaux types de quantification peuvent être ajoutés sans casser les anciens fichiers.
• Conçu pour le matériel grand public. Pas pour les grappes de recherche. Pas pour les API infonuagiques. Pour votre portable, votre poste de travail, votre nœud auto-hébergé.

Tout modèle sérieux à poids ouverts en 2025–2026 — Llama, Qwen, DeepSeek, Gemma, Mistral, Phi — publie ses quantifications GGUF quelques jours après la sortie, habituellement téléversées par les comptes communautaires de « quant-maker » (bartowski, les successeurs de TheBloke, l’équipe unsloth) directement sur Hugging Face.

Ce qu’il y a dans un GGUF

Ouvrez-en un et vous y trouverez :

• Tous les poids du modèle à la quantification choisie
• Le tokenizer complet (vocabulaire, fusions, tokens spéciaux)
• La déclaration d’architecture (variante transformer, têtes d’attention, nombre de couches, paramètres RoPE)
• La longueur de contexte, les indices de coupure d’entraînement
• Le gabarit de chat (le wrapper de prompt style Jinja)
• Le type de quantification par tenseur (tous les tenseurs n’ont pas à être au même quant — les k-quants sont astucieuses là-dessus)

Passez un GGUF à llama.cpp, ollama ou LM Studio et ça tourne. Pas de fichiers de configuration, pas de dépendances Python, pas d’installation de la bibliothèque transformers.

Les alternatives (brièvement)

GGUF domine mais n’est pas seul. Vous croiserez :

• GPTQ — Méthode de quantification post-entraînement du papier GPTQ original (Frantar et coll.). Plus ancienne que les k-quants mais encore largement utilisée, surtout avec les runtimes exllama / exllamav2 sur GPU NVIDIA. Bonne vitesse sur des kernels CUDA bien réglés.
• AWQ — Activation-aware Weight Quantization. Au lieu de quantifier chaque poids uniformément, AWQ regarde quels poids comptent le plus pour les activations du modèle et les protège. Qualité par bit compétitive. Courant dans les déploiements vLLM sur serveurs.
• EXL2 — Le format d’exllamav2. Débit binaire variable : des couches différentes peuvent utiliser des largeurs en bits différentes, choisies pour atteindre une moyenne cible. Très compact, très rapide sur NVIDIA. Moins portable que GGUF.
• MLX — Le format natif d’Apple pour Apple Silicon. Exploite l’architecture de mémoire unifiée des puces série M. Sur Mac, les versions MLX tournent souvent plus vite que les équivalents GGUF. Consultez l’organisation mlx-community sur Hugging Face.
• Safetensors fp16 / bf16 — Le format « original » non quantifié. Ce que les créateurs de modèles téléversent en premier. Toutes les autres quantifications en dérivent.

Si vous opérez une boîte grand public avec une 3090 ou de l’Apple Silicon, vous passerez 90 % et plus de votre temps en GGUF (et MLX sur Mac). Les opérateurs de serveurs et les chercheurs dérivent vers AWQ et EXL2.

Déchiffrer les suffixes de quantification GGUF

Place à la partie cryptique. Quand vous voyez Q4_K_M ou Q5_0 ou Q6_K, voici ce que signifie chaque morceau.

Le chiffre

Q4, Q5, Q6, Q8 — bits par poids, en gros. En gros, parce que les k-quants modernes utilisent différentes largeurs de bits pour différents tenseurs dans un même fichier, et l’étiquette reflète la moyenne effective. Une moyenne pondérée Q4_K_M se situe autour de 4,8 bits par poids, pas un 4 bien plat.

Le suffixe

• _0 / _1 — Quantifications « type 0 » et « type 1 » héritées d’avant 2023. Mise à l’échelle simple par bloc (un facteur d’échelle par groupe de 32 poids). Toujours utilisées pour Q4_0, Q5_0, Q8_0 — ce dernier étant en pratique la « référence 8 bits ».
• _K — Famille k-quant, introduite à la mi-2023. Bien plus futée : précision mixte à l’intérieur d’un fichier, plus petits blocs, meilleur calcul de mise à l’échelle. À nombre de bits égal, les k-quants battent les quantifications héritées sur les bancs d’essai de qualité.
• _S / _M / _L — Variantes Small, Medium, Large dans la famille k-quant. Différents mélanges de précisions sur les tenseurs du modèle. Les variantes plus grandes protègent davantage les tenseurs critiques à plus haute précision, donc la qualité est meilleure pour un petit surcoût de taille.

La fiche mémo des quantifications

Si vous ne retenez rien d’autre : Q4_K_M est la valeur par défaut. Q5_K_M si vous avez de la VRAM à dépenser. Q6_K ou Q8_0 pour le code, les maths ou les petits modèles où les dommages de quantification ressortent davantage.

Quelle quantification un pleb doit-il choisir ?

La réponse honnête dépend de votre matériel. Voici l’arbre de décision par rig.

24 Go de VRAM (RTX 3090, RTX 4090, RTX 3090 Ti)

Le classique du pleb. Voyez notre billet RTX 3090 usagée pour LLM pour savoir pourquoi c’est encore le meilleur rapport qualité-prix en 2026.

• Modèles jusqu’à 14B : Optez pour Q6_K ou Q8_0. Aucune raison de comprimer davantage — vous avez la marge.
• Modèles 27-32B (Gemma 3, Qwen 2.5 32B) : Q5_K_M est le « sweet spot ». Laisse place à une fenêtre de contexte décente.
• Modèles 70B : Une seule 3090 force du Q2_K ou du déchargement CPU — deux options pénibles. Meilleur plan : ajouter une seconde 3090 (48 Go au total) ou accepter la perte de vitesse.

48 Go de VRAM (double 3090, RTX 5090)

Territoire confortable du pleb.

• Modèles 70B : Q4_K_M tourne sans à-coups avec un contexte complet de 8K+. Q5_K_M si vous n’avez pas besoin d’un gros contexte.
• Modèles 32B : Q8_0 — pratiquement sans perte, laisse encore de la VRAM pour un gros contexte et une cache KV.
• 13-14B : Q8_0 ou fp16, peu importe — vous avez la marge.

12 Go de VRAM (RTX 3060, RTX 4070, RTX 4070 Super)

Auto-hébergement d’entrée de gamme.

• Modèles 8B : Q5_K_M ou Q6_K. Tient avec un contexte de 8K-16K.
• Modèles 14B : Q4_K_M passe de justesse avec une fenêtre de contexte réduite (~4K). Poussez le contexte plus haut et vous déborderez vers la RAM système.
• N’essayez pas 32B+ sur 12 Go. Prenez plutôt un modèle plus petit à meilleure qualité.

8 Go de VRAM / Apple Silicon 16-24 Go de mémoire unifiée

Territoire portable et Mac Mini.

• Modèles 7B / 8B : Q4_K_M est votre ami. Llama 3.1 8B, Qwen 2.5 7B, Mistral 7B — tous confortables.
• Petits modèles (Gemma 3 4B, Phi-3.5 3.8B) : Q5_K_M ou Q6_K. Ces petits modèles tapent au-dessus de leur catégorie en 2026 et méritent des quantifications de meilleure qualité.
• Note Apple Silicon : Vérifiez les versions MLX sur Hugging Face. Le MLX natif est souvent 15-30 % plus rapide que le GGUF sur les puces série M.

CPU seul / 64+ Go de RAM système

Possible mais lent. L’inférence CPU est 10 à 50 fois plus lente que le GPU pour la plupart des modèles.

• N’importe quel modèle à n’importe quelle quantification se chargera techniquement, mais les tokens/s pratiques sont bas.
• Tenez-vous-en à Q4_K_M — les fichiers plus petits se paginent plus vite en mémoire, et le débit CPU est de toute façon le goulot.
• Un montage économique avec un vieux Xeon et 128 Go de DDR4 peut faire tourner un 70B Q4_K_M à 1-3 tokens/s. Utilisable pour du lot en arrière-plan, pénible pour du clavardage interactif.

Pour une marche à suivre de bout en bout, voyez Installer Ollama en 10 minutes.

Quand la quantification fait mal (honnête)

La quantification n’est pas gratuite. Voici où les fissures apparaissent :

Génération de code. La qualité sur les bancs d’essai de code (HumanEval, MBPP, SWE-bench) chute de façon mesurable sous Q5. Si vous utilisez votre modèle local comme copilote de code, optez pour Q6_K ou Q8_0. Les économies de taille de Q4 ne valent pas les bogues supplémentaires que vous introduirez.

Raisonnement à long contexte. Les quantifications agressives dégradent le raisonnement à plusieurs étapes plus vite que le questions-réponses à réponse courte. Les modèles Q2 / Q3 oublient le milieu des longs contextes. Si vous faites du RAG sur de gros documents, restez à Q5+.

Petits modèles. Un 7B en Q2_K est bien pire qu’un 70B en Q2_K. Les gros modèles ont plus de capacité « redondante » qui tolère une compression agressive. Les petits, non. Ne quantifiez pas les petits modèles sous Q4_K_M.

Maths. Sensibles au bruit de quantification. DeepSeek R1, les modèles de raisonnement de classe « o », les fine-tunes spécialisés en maths — gardez-les à Q5+. Les erreurs d’arithmétique invisibles à Q8 deviennent des réponses hallucinées à Q3.

Fidélité au suivi d’instructions. À très basse quantification (Q2, Q3), les modèles commencent à ignorer des parties du prompt système ou à halluciner du formatage JSON. C’est surtout un problème pour les flux agentiques / d’utilisation d’outils, moins pour le clavardage.

Rien de tout ça n’est une raison d’éviter la quantification. C’est une raison de choisir la bonne quantification pour la charge. Dans le doute, montez d’un cran.

En pratique — comment télécharger une quantification précise ?

Les mécaniques dépendent du runtime. Voyez LM Studio vs Ollama vs llama.cpp pour la comparaison complète des runtimes.

Ollama

La quantification est cuisinée dans l’étiquette :

ollama pull llama3.1:70b-instruct-q4_K_M
ollama pull qwen2.5:14b-instruct-q5_K_M

Si vous omettez la quantification, Ollama choisit une valeur par défaut (habituellement Q4_0 ou Q4_K_M). Précisez toujours la quantification explicitement — vous voulez savoir ce que vous faites tourner.

llama.cpp

Téléchargez n’importe quel .gguf directement depuis Hugging Face, puis lancez :

llama-cli -m ./models/llama-3.1-70b-instruct-q4_k_m.gguf -p "prompt ici"

Les comptes communautaires de quant-maker sur Hugging Face (cherchez bartowski ou parcourez lmstudio-community) publient l’échelle complète des quantifications pour tout modèle populaire — typiquement de Q2_K à Q8_0 et fp16, tous en fichiers .gguf distincts.

LM Studio

Navigateur de modèles intégré. Cherchez un modèle, déroulez sa liste de fichiers, et chaque quantification disponible est sélectionnable. LM Studio affiche un indicateur d’adéquation taille-VRAM pour que vous voyiez en un coup d’œil ce que votre rig peut faire tourner.

vLLM / TGI / déploiements serveur

Utilisez le format AWQ ou GPTQ depuis le dépôt Hugging Face du modèle. Ce sont les standards des piles d’inférence auto-hébergées sur GPU infonuagique.

Pour conclure

La quantification est la seule plus grande raison pour laquelle l’IA open source sur matériel grand public fonctionne vraiment. C’est pourquoi une 3090 usagée reste les 700 $ les plus productifs que vous puissiez dépenser sur un lab maison. C’est pourquoi les MacBook Apple Silicon font tourner des modèles 30B. C’est pourquoi un portable 8 Go peut clavarder avec Phi-3.5 sans incendier le SE.

Recommandations par défaut pour la plupart des plebs, la plupart du temps :

• Serré en VRAM : Q4_K_M
• Confortable en VRAM : Q5_K_M
• Charges de code ou de maths : Q6_K ou Q8_0
• Très petits modèles (≤ 4B) : Q6_K minimum

Chaque guide matériel, chaque comparatif de runner, chaque question « est-ce que ce modèle rentre ? » sur ce site finit par se réduire à un choix de quantification. Vous pouvez maintenant lire l’étiquette et trancher.

Pour le contexte plus large sur la place qu’occupe la quantification dans l’exploitation de votre propre pile IA, revenez au Guide du pleb pour l’IA auto-hébergée. Quand ça casse, le guide de dépannage d’IA auto-hébergée couvre les suspects habituels d’OOM et de dépassement de contexte — la plupart remontent à un mauvais choix de quantification pour la machine.

Empilez peu profond. Vérifiez tout. Faites-le tourner vous-même.

Références et lectures complémentaires :

• Dépôt llama.cpp et spécification GGUF
• Hub de modèles Hugging Face — source de chaque quantification discutée
• Bibliothèque de modèles Ollama — quantifications GGUF préemballées avec des valeurs par défaut sensées
• Papier QLoRA (Dettmers et coll.) — le travail fondateur sur la quantification 4 bits pour LLM, et LLM.int8() avant lui; la plupart des techniques modernes descendent de cette lignée de recherche
• Spécification du format GGUF — le document de spécification des internes du format

Pour aller plus loin : faire tourner ce modèle localement est une des couches du Manifeste pour une IA souveraine des Bitcoiners. Le côté matériel de l’argument vit dans notre catalogue de minage — commencez avec Du S19 à votre premier Hashcenter IA ou Comment utiliser une chaufferette Bitcoin.