LLM allégés : chiffrer les gains et éviter les pièges

Charger 70 milliards de paramètres en FP16 réclame environ 140 Go de VRAM et jusqu’à quatre A100, soit 80 000 à 100 000 dollars de matériel immobile avant la première requête. La quantification et l’élagage réduisent ces exigences à des tailles tenables, mais leur impact sur la qualité varie fortement selon les modèles et les tâches. Tour d’horizon des gains, des écueils et d’une mise en œuvre immédiate en 4 bits.

Des pertes de qualité hétérogènes imposent une évaluation ciblée

La qualité d’un modèle compressé ne se résume pas à une règle universelle. Red Hat a analysé plus de 500 000 évaluations de modèles quantifiés et constaté que la perte de performance varie selon le modèle, la tâche et la méthode employée. Certains modèles supportent bien une compression agressive, d’autres voient leur qualité chuter rapidement. Pour juger de la robustesse d’un modèle compressé, il faut l’évaluer sur des tâches proches de l’usage prévu, et non se limiter à vérifier la grammaticalité des sorties. Concernant l’élagage, la méthode par magnitude, historiquement simple, échoue sur les LLM même à des niveaux de parcimonie modestes, comme l’a documenté l’équipe à l’origine de Wanda. Les grands modèles sont plus difficiles à élaguer sans perte que les réseaux plus petits pour lesquels cette technique avait été conçue.

La facture matérielle d’un LLM non compressé explose vite

Une équipe peut passer trois semaines à peaufiner un modèle et se retrouver, au moment du déploiement, avec un point de contrôle de 140 Go. À ce stade, la plupart des GPU en rack deviennent inutilisables, le plan de déploiement doit être revu et la semaine de lancement se transforme en recherche de quatre A100 non prévus au budget. Charger 70 milliards de paramètres en FP16 nécessite environ 140 Go de VRAM et, en pratique, quatre A100, soit 80 000 à 100 000 dollars de matériel immobilisé avant la moindre requête. Faire l’impasse sur la compression conduit souvent à un modèle impossible à héberger sur le matériel existant, à une facture d’inférence trop élevée ou à des latences incompatibles avec des usages comme le chat en direct, l’assistant vocal ou la saisie automatique.

Quantifier à 4 bits : du cluster à la station de travail, et au-delà du smartphone

Réduire un modèle de 70 milliards à 4 bits via AWQ ou GPTQ ramène sa taille à environ 35 à 40 Go, ce qui permet de le charger sur une carte de station de travail haut de gamme plutôt que sur un cluster, selon un guide de 2026. Cette évolution se concrétise chez les grands laboratoires : Gemma 3 de Google (27 milliards de paramètres) passe de 54 Go à environ 14 Go en 4 bits, tout en divisant par deux la perte de qualité par rapport à une quantification post-formation classique. Gemma 4 va plus loin en proposant des points de contrôle sensibles à la quantification ; sa plus petite variante de 2 milliards atteint environ 1 Go, assez compacte pour fonctionner sur un téléphone. Apple applique une logique similaire sur iPhone, compressant les poids à 2 bits grâce à une formation adaptée, plutôt qu’en ajustant les échelles après coup. Les bénéfices concrets sont multiples : moins de GPU à acquérir ou louer, une latence par requête réduite car moins de données transitent en mémoire, et la possibilité d’exécuter des modèles sur du matériel qui n’aurait pas supporté la version complète.

Ce que font la quantification et l’élagage, et pourquoi les combiner

La quantification consiste à réduire la précision numérique des poids, par exemple en passant d’un flottant 16 bits à un entier 8 ou 4 bits, sans modifier le nombre de paramètres. Cela diminue la mémoire nécessaire et peut accélérer les calculs. L’élagage, lui, supprime des poids ou des structures entières – connexions, têtes d’attention, voire couches – ce qui réduit le nombre total de paramètres. Les deux techniques allègent les modèles selon des axes différents et peuvent être combinées. Elles restent pourtant sous-employées, souvent par crainte d’une baisse de qualité, alors qu’il s’agit surtout de choisir la méthode adaptée au contexte.

Aperçu des méthodes : calibration seule, parcimonie 2:4 et gains typiques

Plusieurs familles d’approches existent. Pour la quantification, certaines méthodes ne nécessitent qu’une calibration et s’appuient sur des services GPU en production, avec une large disponibilité de modèles pré-quantifiés et un bon rendement sur les noyaux récents. Pour l’élagage, un objectif courant est la parcimonie structurée 2:4, qui permet des accélérations matérielles réelles. Il existe aussi des schémas one-shot avec mise à jour des poids, ainsi que des méthodes à passage unique adaptées aux très grands modèles lorsque la vitesse d’élagage est un critère. En pratique, certaines méthodes d’élagage permettent de réduire la taille d’un facteur 2 à 50% de parcimonie.

bitsandbytes NF4 et QLoRA : une implémentation immédiate en 4 bits

La quantification 4 bits NF4 de bitsandbytes est souvent le meilleur point d’entrée. NF4 (NormalFloat4) exploite la distribution normale des poids en concentrant les valeurs de 4 bits là où ils se regroupent. C’est la seule méthode citée qui prend en charge QLoRA, ce qui permet de charger un modèle en 4 bits et de l’affiner avec de petits adaptateurs à faible rang, sans toucher aux poids gelés. Pour la mise en œuvre, load_in_4bit=True convertit les poids au chargement ; bnb_4bit_quant_type="nf4" sélectionne le format ; le calcul s’effectue en bfloat16 via bnb_4bit_compute_dtype, car il n’existe pas encore de noyaux 4 bits natifs ; bnb_4bit_use_double_quant=True quantifie aussi les constantes, économisant environ 0,4 bit par paramètre. device_map="auto" répartit les couches entre GPU et CPU si besoin. Un exemple de configuration utilise meta-llama/Llama-3.1-8B-Instruct.