La quantification LLM permet de faire entrer un modèle d’intelligence artificielle dans moins de mémoire. C’est souvent la condition pour l’exécuter sur un PC personnel, mais ce gain n’est jamais gratuit. Entre 8 bits, 6 bits, 5 bits et 4 bits, le bon choix dépend de la tâche, du modèle, du moteur et du matériel.
Je vois trop souvent la quantification résumée à une course au fichier le plus petit. Or un modèle qui démarre n’est pas forcément un modèle agréable, fidèle ou rapide. Voici une méthode concrète pour choisir sans confondre compression, vitesse et qualité.
Quantification LLM : ce qui est réellement réduit
Un modèle contient des milliards de paramètres représentés par des nombres. Une précision élevée conserve davantage d’information, mais elle occupe aussi davantage de mémoire. La quantification encode ces valeurs avec moins de bits afin de diminuer la taille des poids et, selon le moteur, d’accélérer certains calculs.
Passer d’une représentation 16 bits à 8 ou 4 bits ne divise pourtant pas toujours la consommation totale dans les mêmes proportions. Le cache du contexte, les activations, certains composants laissés en précision supérieure et les buffers du moteur s’ajoutent aux poids. La taille du fichier téléchargé reste donc un repère, pas une promesse de VRAM.
8 bits : la marge de qualité confortable
Une quantification 8 bits conserve généralement une représentation plus fine des poids. Elle demande davantage de mémoire qu’un format 4 bits, mais constitue une base rassurante lorsque la fidélité des réponses est prioritaire : code, extraction structurée, raisonnement long ou comparaison de documents proches.
Elle ne garantit pas la qualité. Un mauvais modèle en 8 bits ne devient pas supérieur à un modèle mieux adapté en 4 bits. En revanche, si la machine possède assez de VRAM et si le débit est satisfaisant, descendre plus bas uniquement pour économiser quelques gigaoctets n’apporte pas toujours de bénéfice pratique.
4 bits : le compromis qui démocratise l’IA locale
Le 4 bits rend des modèles plus grands accessibles à des cartes graphiques modestes. Il peut offrir une excellente expérience pour le dialogue, le résumé, l’aide à l’écriture et de nombreux usages quotidiens. Les écarts ne sont pas constants : ils varient selon l’architecture, la méthode de quantification, la calibration et la tâche.
La contrepartie apparaît surtout dans les cas exigeants. Des nuances peuvent disparaître, une sortie structurée peut devenir moins régulière et certaines capacités rares peuvent se dégrader. Un résultat convaincant sur trois prompts ne suffit donc pas à valider un format.
Pourquoi deux fichiers « 4 bits » peuvent être très différents
L’étiquette 4 bits ne décrit pas toute la recette. Les formats GGUF proposés dans l’écosystème llama.cpp disposent de variantes qui répartissent différemment la précision entre les tenseurs. D’autres moteurs utilisent GPTQ, AWQ, bitsandbytes ou des implémentations propres au matériel.
La documentation officielle de l’outil de quantification de llama.cpp et la documentation de quantification de Transformers montrent cette diversité. Il faut noter le nom complet du fichier et du format, pas seulement « Q4 ».
| Choix | Avantage courant | Risque à surveiller |
|---|---|---|
| 8 bits | fidélité et stabilité | empreinte mémoire élevée |
| 5 ou 6 bits | compromis intermédiaire | gain parfois faible face au 4 bits |
| 4 bits | modèles plus grands accessibles | dégradation variable selon la tâche |
| moins de 4 bits | empreinte minimale | perte de qualité plus probable |
Modèle plus grand quantifié ou petit modèle mieux préservé ?
Il n’existe pas de réponse universelle. Un modèle plus grand en 4 bits peut dépasser un modèle compact en 8 bits sur une tâche générale. Le plus petit peut pourtant être plus rapide, plus stable et suffisant pour un usage ciblé. Le choix doit se faire sur des essais reproductibles, pas sur le nombre de paramètres.
Le guide BlackFury pour dimensionner la VRAM, la RAM et le contexte d’un LLM local aide à vérifier si les poids, le cache et le reste du système tiennent réellement ensemble.
Mesurer la qualité utile plutôt qu’un score isolé
Je prépare un petit jeu de tests correspondant à mes usages : une consigne de synthèse, une extraction en tableau, un problème de code, une reformulation et une question qui exige de conserver plusieurs contraintes. Chaque modèle reçoit exactement le même prompt, les mêmes documents, le même contexte et les mêmes paramètres d’échantillonnage.
- noter la version exacte du modèle et du fichier ;
- mesurer le temps de chargement et le débit de génération ;
- relever la VRAM et la RAM maximales ;
- vérifier chaque contrainte de la réponse ;
- répéter les cas sensibles plusieurs fois ;
- conserver les sorties pour comparer sans se fier au souvenir.
Une réponse plus élégante n’est pas toujours plus exacte. Pour une extraction, je compte les champs corrects et les omissions. Pour le code, j’exécute les tests. Pour un résumé, je vérifie les faits et les exclusions demandées.
La vitesse ne suit pas toujours la taille du fichier
Un modèle plus léger peut être plus rapide parce qu’il tient entièrement dans la VRAM. Mais certaines quantifications demandent des noyaux spécifiques ou des conversions qui réduisent le gain. Le processeur, la bande passante mémoire, le pilote et le moteur changent aussi le résultat.
Je mesure donc sur la machine finale. Copier le débit obtenu par un autre utilisateur avec un GPU différent, une autre version de CUDA ou un autre contexte produit une comparaison fragile.
Le contexte peut annuler le bénéfice
La quantification réduit surtout les poids. Si la conversation accumule des dizaines de milliers de jetons, le cache associé peut devenir la nouvelle limite. Il faut tester le format à la longueur de contexte réellement utilisée, et non uniquement avec une question courte.
Pour des documents, je préfère sélectionner les passages pertinents au lieu d’injecter tout le corpus. Cette sobriété améliore souvent la vitesse et évite de noyer l’instruction.
Une procédure de choix simple
- commencer par une version 8 bits ou une variante 5/6 bits si elle tient confortablement ;
- tester une bonne variante 4 bits avec les mêmes cas ;
- comparer la qualité utile et le débit ;
- vérifier la marge de mémoire avec le contexte habituel ;
- garder le plus petit format qui ne dégrade pas les tâches importantes.
Je conserve aussi une copie des paramètres, de la licence et de la carte du modèle. L’article sur les coûts cachés de l’IA locale rappelle que les mises à jour, le stockage et la maintenance font partie du prix réel.
Les erreurs que je veux éviter
- comparer des formats provenant de modèles ou de versions différents ;
- confondre taille du fichier et consommation totale ;
- juger sur un seul prompt flatteur ;
- oublier le contexte et les autres applications ;
- choisir le modèle le plus grand même s’il devient lent ;
- ignorer la licence ou la provenance du fichier ;
- présenter une estimation de VRAM comme une garantie.
Verdict BlackFury
La quantification LLM n’est pas une dégradation à craindre automatiquement. C’est un outil de dimensionnement. En 4 bits, elle ouvre l’IA locale à davantage de PC ; en 8 bits, elle laisse souvent plus de marge à la fidélité. Le bon format est celui qui tient avec le contexte réel, reste rapide et réussit les tâches qui comptent.
