Paliers de quantization GGUF, pesés en direct : Q4_K_M vs Q8_0 sur taille, VRAM et qualité

■ espace · la presse à blocs · fig 1

■ la réponse d'abord

Q4_K_M par défaut — ~4,85 bits par poids, ~1 % de coût de perplexité, ~30 % de la taille plein-précision.

Monter à Q6_K pour code et maths ; garder Q8_0 pour les runs de référence ; sous Q4, c'est une ration d'urgence pour les gros modèles.

La décision entière est une ligne : size_GB ≈ bits_per_weight × params / 8.

4.85bits par poids — le palier par défaut

~1%coût de perplexité à Q4_K_M

30%de la taille plein-précision

01LA PRESSE

une caisse, quatre tampons — le pont-bascule répond taille, la jauge répond coût

FIG 1 · LA PRESSE À BLOCS GGUFtouches 1–5 — ou les boutons · le bouton règle les params

~1 % de perplexité — LE défautLe défaut. Le meilleur compromis qualité-par-gigaoctet qui soit.

PALIER Q4_K_M · 4,85 BPW · ÉCHELLE 4.85 GB / FP16 16.0 GB · TAILLE 30% · PARAMÈTRES 8B

la caisse est le modèle : mêmes poids à chaque passe — seul le tampon change. Tapez 5 et regardez la jauge de coût plonger

02TOUS LES PALIERS

la machine embarque quatre paliers — le registre en livre huit

palier	bpw	qualité — le verdict	quand l'utiliser
Q2_K la ration	~3.4	sévère sous 13B — une ration d'urgencela cohérence commence à s'effondrer sur les petits modèles	Rien d'autre ne rentre, gros modèles seulement. Testez avant de faire confiance.
Q3_K_M la squeeze	~3.9	visible — la squeeze de VRAMperte visible — seulement pour VRAM juste sur ≥14B	VRAM étroite, modèles ≥14B seulement.
Q4_K_S le repli	~4.6	petite pertepetite perte — quand Q4_K_M ne rentre pas de justesse	Le repli quand Q4_K_M ne rentre pas — et que ça joue serré.
IQ4_XS l'i-quant	~4.3	≈ Q4_K_M — la squeeze codebookqualité ≈ Q4_K_M, plus petit — si votre backend tourne les i-quants	Q4_K_M un poil trop gros, backend qui supporte les i-quants. Un peu plus lent sur certains backends.
Q4_K_M le défaut	~4.85	~1 % de perplexité — LE défautmeilleure qualité-par-gigaoctet — tous les dépôts le livrent	Le défaut. Le meilleur compromis qualité-par-gigaoctet qui soit.
Q5_K_M la réserve	~5.7	~0,5 % de perplexitéperte quasi nulle, encore confortable	De la réserve avec confort — la qualité comptait plus que le dernier gigaoctet.
Q6_K le cheval de bataille	~6.6	presque indiscernablepresque indiscernable — le palier code et maths	Code, maths, extraction — tout ce qui punit le bruit.
Q8_0 la référence	~8.5	aucun en pratique (~0,02 % vs pleine)aucun en pratique (~0,02 %) — A/B et bases de fine-tune	Runs de référence, A/B, bases de fine-tune — pas un conducteur quotidien.

la ligne unique—size_GB ≈ bits_per_weight × params / 8 — chaque affichage de la presse le calcule en direct

exemple travaillé—8B en Q4_K_M : 4,85 × 8 / 8 = 4.85 GB ; FP16 ferait 16.0 GB — la caisse part à 30% de la pleine précision

poids seuls—ajoutez le cache KV, les activations, les buffers : un modèle « 4,9 Go » veut une carte de 6 Go à 4k de contexte — flash-attention + cache KV quantisé gardent une fenêtre 16k sur cette carte. À une fenêtre pleine de 128k, le cache seul veut ~16 GiB.

sur le hub—préférez un seul Q4_K_M.gguf aux splits éclatés, sauf si seul ce dernier est livré. Destination vLLM plutôt que llama.cpp ? Son plugin GGUF prend les mêmes fichiers — la règle GPU-only s'applique. Quoi qu'il en soit, le moteur est un axe distinct de la quant.

03CE QUE LE TAMPON ENLÈVE

la caisse rétrécit — voici ce que le tampon fait réellement aux bits

entraîné en 16 bits—chacun des milliards de poids d'un modèle est un nombre de 2 octets en virgule flottante 16 bits ; la quantisation tasse chaque poids dans moins de bits

la voie naïve—arrondir tout en entier 4 bits — détruit les petites valeurs importantes

mise à l'échelle par blocs—poids groupés par blocs de 32, chaque bloc portant son facteur d'échelle, si bien qu'une large amplitude de magnitudes survit

les k-quants, le K—super-blocs d'échelles sensibles à l'importance — couches d'attention et feed-forward traitées différemment, car leur tolérance à la compression inégale

la famille IQ—codebooks empruntés à la compression d'images — moins de bits à qualité semblable, un peu plus lent sur certains backends

intact—architecture, tokenizer, gestion du contexte : la quantisation ne change que les poids stockés

Un fichier Q4 et un fichier Q8 du même modèle sont le même modèle, avec des manteaux différents.

04L'ORDRE DE DÉCISION

le mécanisme est honnête — alors quel palier pour quel job

Contexte + budget KV d'abord, poids ensuite. Un contexte qui ne rentre pas est pire qu'une qualité qu'on ne peut pas mesurer — en contexte long, le cache peut dépasser le modèle.
Par défaut, Q4_K_M. ~1 % de perplexité pour ~30 % de la taille ; le défaut de la communauté, pour une raison.
Montez à Q6_K quand la tâche punit le bruit — code, maths, extraction, tout ce qui tourne sans surveillance.
Q8_0 pour référence uniquement — tests A/B, mesure de dégâts, bases de fine-tune. En conducteur quotidien, ça n'achète que des capteurs de VRAM au chaud.
Sous Q4 uniquement sous contrainte, gros modèles seulement — et testez avec un prompt connu-confus avant de faire confiance.

plus haut, mieux ?—techniquement oui ; perceptiblement à peine — Q8_0 atterrit à ~0,02 % de la pleine précision : lossless pour tout usage pratique ; Q6_K est presque indiscernable

l'arrondi naïf—Q4_0 coûte un peu plus que les ~1–2 % de Q4_K_M

la taille achète de la réserve—un 70B survit au Q3 comme retouche ; un 7B en Q2, c'est une amputation — les gros modèles sont plus redondants

le plancher bouge—le chat tolère Q4 ; code exact, maths et RAG sur documents précis exposent le bruit plus tôt — si un modèle Q4 écrit du code subtilement faux, testez le même modèle en Q6_K avant de blâmer le modèle

05MESUREZ VOUS-MÊME LES DÉGÂTS

les cadrans montent les verdicts de llama.cpp — faites voter votre propre matériel

construire llama.cpp une fois

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build && cmake --build build --config Release -j

tirer deux paliers — perplexité, puis vitesse

huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF \
  Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf Meta-Llama-3.1-8B-Instruct-Q8_0.gguf \
  --local-dir models
# perplexity (lower = closer to the original model)
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q8_0.gguf  -ngl 99
# and speed on the same hardware
./build/bin/llama-bench -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99

verify : le chiffre du Q4_K_M atterrit quelques centièmes de point plus mal — et le fichier est ~40 % plus petit. Mêmes données, chaque palier

La perplexité est la surprise du token suivant sur un jeu de données fixe : un proxy, pas une note — et votre vraie tâche peut la contredire.

la vieille erreur—s'acharner sur Q4-contre-Q5 en ignorant la longueur de contexte : budgétisez le cache KV d'abord ; le palier est la partie facile

vie privée—la quantisation est de l'arithmétique sur les poids, entièrement hors-ligne : un run Q4_K_M en local fuit exactement autant que le modèle plein-précision — rien ne quitte la machine. La variable vie privée, c'est où tourne l'inférence, pas la largeur en bits

provenance—tranche identique sur tous les paliers : un fine-tune « uncensored » à base volée en Q8 n'est pas plus sain que les mêmes poids en Q4

■ tampon honnête Des verdicts de qualité venus de runs de perplexité, pas de on-dit. Testé sur : llama.cpp llama-perplexity · llama-bench · GGUF Q2_K → Q8_0 · fichiers Hugging Face. Les chiffres de l'échelle sont les mesures propres de llama.cpp sur les modèles de référence de la famille Llama ; le calcul de taille est la ligne unique — chaque affichage de la presse ci-dessus est cette ligne. Tournez les commandes et remplacez mes chiffres par les vôtres.

fin de la presse à blocs · rien n'a été téléchargé · tout est local