La quantification consiste à représenter certaines valeurs numériques d’un modèle avec moins de bits. Dans un LLM, on parle souvent des poids : passer de FP16 à 8 bits, 4 bits ou autre format réduit la taille des poids chargés. Mais ce n’est pas toute la RAM ou toute la VRAM : il faut aussi compter activations, KV cache, runtime, buffers et contexte.
Repère documentaire : documentation officielle du fonctionnement présenté.
Calcul théorique simple
Un modèle de 7 milliards de paramètres en FP16 utilise théoriquement 7 milliards × 16 bits = 112 milliards de bits. Divisé par 8, cela fait 14 milliards d’octets, environ 14 Go en notation décimale avant surcoûts. En 4 bits, les poids représenteraient environ 3,5 Go théoriques. En pratique, le fichier ou la mémoire utilisée peut différer à cause des métadonnées, groupes de quantification, couches non quantifiées, alignements et caches.
Poids, activations et KV cache
Les poids sont les paramètres appris. Les activations sont les valeurs intermédiaires produites pendant le calcul. Le KV cache stocke des clés/valeurs d’attention pour accélérer la génération token par token. Plus le contexte est long et plus il y a de requêtes concurrentes, plus le KV cache peut peser lourd. C’est pourquoi “modèle 4 bits” ne signifie pas “tourne forcément dans 4 Go”.
Qualité : préserver les tâches, pas juste un prompt
Une quantification peut très bien marcher pour du résumé court et dégrader une extraction JSON stricte, du code, des maths ou une langue minoritaire. Il faut évaluer sur vos tâches : dix prompts représentatifs, formats attendus, erreurs bloquantes, latence et coût. Un modèle plus petit mais fiable peut battre un grand modèle trop compressé sur une tâche métier précise.
Exemple de décision
- Prototype CPU local : quantification agressive acceptable si la qualité suffit.
- Production avec extraction contractuelle : tester plusieurs niveaux et valider le JSON.
- Long contexte : surveiller KV cache autant que taille du fichier.
- Comparaison modèle A/B : même prompts, même seed si disponible, même runtime.
La quantification est donc un levier mémoire/performance, pas un bouton magique. Elle réduit souvent le coût de chargement des poids, mais la décision finale dépend du matériel, de la longueur de contexte, du débit attendu et des erreurs acceptables.
Calibration et formats
Certaines méthodes de quantification utilisent des données de calibration pour réduire la perte de précision ; d’autres convertissent plus directement. Les formats ne sont pas interchangeables entre tous les runtimes. Un modèle GPTQ, AWQ, bitsandbytes ou GGUF peut viser un écosystème différent. Le bon choix dépend autant du moteur d’inférence que du nombre de bits.
Erreur de raisonnement fréquente
Dire “4 bits divise la RAM par quatre” est faux si l’on parle du système complet. La mémoire des poids diminue, mais le contexte, les buffers, le runtime et la concurrence restent à compter ; certaines matrices de poids peuvent aussi conserver une précision supérieure. Pour une application agentique avec long contexte, le KV cache peut devenir le poste qui fait tomber la machine.
Test représentatif
Pour choisir une quantification, préparez trois cas : une réponse courte, un format JSON strict et un prompt long. Comparez les erreurs, pas seulement la vitesse. Si la version compressée rate le format ou perd une information clé, l’économie mémoire ne compense pas forcément.
Pour les bases : définition d’un modèle de langage.
