Zubnet AIApprendreWiki › Quantification
Infrastructure

Quantification

Aussi appelé : GGUF, GPTQ, AWQ
Réduire la précision d'un modèle pour le rendre plus petit et plus rapide. Un modèle entraîné en virgule flottante 32 bits peut être quantifié en 8 bits, 4 bits, ou encore moins — réduisant sa taille de 4 à 8 fois avec une perte de qualité étonnamment faible. GGUF est le format populaire pour l'inférence locale via llama.cpp.

Pourquoi c’est important

La quantification est ce qui rend possible l'exécution d'un modèle de 14 milliards de paramètres sur un seul GPU ou même un ordinateur portable. Sans elle, les modèles open-weights seraient inutilisables pour la plupart des gens. Les variantes Q4_K_M et Q5_K_M offrent le meilleur compromis taille/qualité.

En profondeur

Pour comprendre la quantification, il faut comprendre ce qu'elle compresse. Les « connaissances » d'un réseau de neurones sont stockées sous forme de milliards de paramètres numériques (poids), chacun étant un nombre à virgule flottante. Pendant l'entraînement, ceux-ci sont typiquement stockés en FP32 (virgule flottante 32 bits) ou BF16 (bfloat16, 16 bits). Un modèle de 7 milliards de paramètres en BF16 occupe 7G × 2 octets = 14 Go de mémoire. La quantification réduit la précision de chaque poids — le représentant avec moins de bits. En INT8 (entier 8 bits), ce même modèle se réduit à environ 7 Go. En INT4 (4 bits), c'est environ 3,5 Go. L'idée clé est que les poids des réseaux de neurones sont étonnamment redondants — on n'a pas réellement besoin de 16 bits de précision pour les représenter utilement. La plupart des poids se regroupent autour de zéro et peuvent être approximés avec des représentations beaucoup plus grossières.

Formats et méthodes

Les principaux formats de quantification que vous rencontrerez adoptent chacun des approches techniques différentes. GPTQ (optimisé GPU, quantification post-entraînement) a été l'une des premières méthodes pratiques — il analyse comment les poids interagissent pendant l'inférence réelle sur des données de calibration et les quantifie de manière à minimiser la propagation des erreurs. AWQ (Activation-aware Weight Quantization) a amélioré cela en se concentrant sur le faible pourcentage de poids qui comptent le plus pour la qualité du modèle et en les protégeant avec une précision supérieure. GGUF est le format utilisé par llama.cpp et est conçu pour une quantification flexible à précision mixte sur CPU et GPU. La convention de nommage dans les fichiers GGUF vous indique ce que vous obtenez : Q4_K_M signifie quantification 4 bits utilisant la méthode K-quant en qualité moyenne. Q5_K_M est 5 bits. Q2_K est une quantification agressive à 2 bits (perte de qualité notable). Q8_0 est 8 bits (pratiquement sans perte).

Qualité vs. compression

La perte de qualité due à la quantification est réelle mais souvent surestimée. Passer de BF16 à Q8 (8 bits) est essentiellement gratuit — les benchmarks montrent typiquement moins de 0,5 % de dégradation sur les évaluations standards. Q5_K_M conserve encore la majorité des capacités du modèle et est souvent le meilleur compromis pour l'inférence locale. Q4_K_M est le seuil où l'on commence à remarquer des différences subtiles : le modèle pourrait être légèrement moins précis avec les nombres, perdre occasionnellement le fil sur de très longues sorties, ou être marginalement moins bon pour suivre des instructions complexes. En dessous de 4 bits, la qualité se dégrade plus notablement — les quantifications Q2 et Q3 peuvent rendre un modèle visiblement moins performant, surtout sur les tâches de raisonnement. La règle générale est : quantifiez en Q4_K_M ou Q5_K_M pour un usage quotidien, et ne descendez plus bas que si vous ne pouvez littéralement pas faire tenir le modèle dans votre VRAM autrement.

Le bonus de vitesse

Il y a une deuxième dimension de la quantification souvent négligée : elle ne se contente pas d'économiser de la mémoire, elle accélère aussi l'inférence. C'est contre-intuitif si on pense au calcul quantifié comme « approximatif » et donc plus lent. Mais pour l'inférence LLM, le goulot d'étranglement pendant la génération de tokens est la lecture des poids du modèle depuis la VRAM (bande passante mémoire), pas le calcul lui-même. Un modèle Q4 a la moitié des données à lire comparé à Q8, donc les tokens sortent à peu près deux fois plus vite — à condition que votre moteur d'inférence prenne correctement en charge le calcul quantifié. C'est pourquoi llama.cpp exécutant un modèle Q4_K_M sur un GPU de bureau peut parfois égaler les tokens par seconde d'une API dans le nuage : le modèle quantifié est véritablement plus efficace par unité de matériel. Le compromis est toujours le même — vous échangez un peu de qualité contre la vitesse et l'accessibilité — mais pour de nombreuses applications, c'est un compromis qui en vaut la peine.

Nés quantifiés

Le dernier développement à connaître est l'entraînement conscient de la quantification (QAT), où le modèle est entraîné en tenant compte de la quantification dès le départ plutôt que d'être quantifié après coup. Meta a publié des versions QAT des modèles Llama qui surpassent les équivalents quantifiés post-entraînement à la même largeur de bits. Cette approche produit des modèles qui sont « nés » pour fonctionner à précision réduite plutôt que de se la voir imposée, et c'est probablement la direction que prend le domaine à mesure que l'inférence locale continue de croître.

Concepts connexes

← Tous les termes
← Ingénierie de prompts RAG →
ESC