Comment alléger un LLM avec quantification et pruning VRAM ?

On allège un LLM en réduisant la précision de ses poids ou en supprimant des parties inutiles du modèle. La vraie question, c’est jusqu’où compresser sans casser la qualité. Je vous montre comment raisonner entre quantification, pruning, coût GPU, latence et risques en production.

Que fait vraiment la quantification ?

La quantification, c’est simple dans l’idée : je garde le même modèle, avec le même nombre de paramètres, mais je stocke ses poids avec moins de précision numérique. Le modèle ne devient pas plus petit parce qu’on lui enlève des neurones. Il devient plus léger parce que chaque nombre prend moins de place en mémoire.

Un LLM en FP16 utilise des nombres flottants sur 16 bits. 16 bits, ça fait 2 octets. Donc un modèle de 70 milliards de paramètres coûte environ 70 milliards × 2 octets, soit 140 Go rien que pour les poids. Et je ne parle même pas encore du cache d’attention, des activations, du runtime, ni de la marge nécessaire pour servir plusieurs utilisateurs. C’est souvent là que le projet bloque en vrai.

Avec de l’INT8, chaque poids est représenté sur 8 bits, donc environ 1 octet. Avec du 4-bit, on descend à un demi-octet par poids en théorie. Dans la pratique il y a toujours un peu de surcoût, parce qu’il faut stocker des échelles, parfois des zéros, parfois des métadonnées. Mais l’ordre de grandeur reste énorme : un 70B qui était irréaliste en FP16 peut devenir beaucoup plus crédible en 4-bit sur une machine bien équipée.

Les approches qu’on voit souvent en production ont chacune leur logique :

• GPTQ compresse les poids après entraînement, en essayant de limiter la perte couche par couche.
• AWQ protège les poids jugés importants pour garder une meilleure qualité, surtout sur les modèles conversationnels.
• Weight-only quantization quantifie surtout les poids, sans forcément toucher aux activations, ce qui simplifie souvent le déploiement.
• Post-training quantization se fait après l’entraînement, sans réentraîner complètement le modèle.
• Quantization aware training entraîne ou ajuste le modèle en simulant la quantification, pour qu’il apprenne à vivre avec cette précision réduite.

La quantification peut toucher seulement les poids, parfois aussi les activations, c’est-à-dire les valeurs intermédiaires calculées pendant l’inférence. Le principe reste le même : représenter les nombres avec moins de bits. Ce n’est pas magique. On gagne en VRAM, parfois en vitesse, mais on peut perdre un peu en qualité, surtout sur des tâches fines.

J’ai vu le cas avec un chatbot interne RH. En FP16, le modèle ne passait pas sur l’infrastructure existante. Trop de VRAM, trop cher, trop compliqué. En 4-bit, le même modèle est devenu déployable sur une machine beaucoup plus raisonnable, avec une qualité suffisante pour répondre sur les procédures internes. Pas parfait, mais utile. Et surtout exploitable.

Format	Mémoire	Qualité attendue	Complexité de mise en production
FP16	Environ 2 octets par paramètre	Très bonne, référence courante	Simple, mais demande beaucoup de VRAM
8-bit	Environ 1 octet par paramètre	Souvent très proche du FP16	Modérée, outils assez matures
4-bit	Environ 0,5 octet par paramètre, avec surcoûts	Bonne si la quantification est bien faite	Plus sensible, nécessite des tests sérieux

Que supprime le pruning ?

Le pruning, c’est la partie un peu plus radicale de l’allègement d’un LLM. Avec la quantification, je garde les poids du modèle, mais je les représente avec moins de précision, par exemple en 8 bits ou 4 bits au lieu de 16 bits. Avec le pruning, j’enlève vraiment des morceaux du modèle. Des poids, des neurones, des têtes d’attention, parfois même des couches entières.

La différence est importante, parce qu’on ne touche pas au modèle de la même manière.

Quantification	Je compresse la représentation des poids. Le modèle garde globalement la même structure.
Pruning	Je supprime des éléments du modèle. Sa capacité réelle peut changer.

Il y a deux grandes familles de pruning. Le pruning non structuré supprime ou met à zéro des poids individuels. Sur le papier, c’est séduisant, parce qu’on peut retirer beaucoup de petits poids jugés peu utiles. Dans la vraie vie, ce n’est pas toujours plus rapide. Si le matériel ou la librairie d’inférence ne sait pas exploiter ces zéros efficacement, vous avez juste un modèle plus “creux”, mais pas forcément plus rapide.

Le pruning structuré est plus lisible pour la machine. Là, je retire des blocs entiers : une tête d’attention, un canal, un groupe de neurones, parfois une couche. Une tête d’attention, pour faire simple, c’est une partie du modèle qui apprend à regarder certaines relations entre les tokens. Quand on retire des blocs complets, les gains de latence sont souvent plus concrets, parce que le moteur d’inférence a moins de calculs à faire pour de vrai.

Le piège, c’est de croire qu’un modèle pruné reste automatiquement bon. Non. Il faut le réévaluer, et souvent le fine-tuner, c’est-à-dire le réentraîner légèrement sur des données ciblées pour récupérer de la qualité. J’ai déjà vu des tests où retirer quelques têtes d’attention ne changeait presque rien sur une petite démo. Puis sur des réponses longues, du raisonnement ou des cas métier un peu tordus, le modèle devenait moins stable.

En production, j’ai aussi vu des équipes regarder uniquement la taille du modèle. C’est rarement le vrai sujet. Le vrai sujet, c’est la latence bout en bout : chargement du modèle, longueur du contexte, batching, vitesse de génération, appels réseau, contraintes GPU. Un modèle plus petit qui génère lentement ne règle pas grand-chose.

Pour moi, pruning et quantification sont complémentaires. La quantification réduit le coût de stockage et de calcul en compressant les poids. Le pruning réduit la structure à exécuter. Les deux peuvent se combiner, mais ils ne sont pas interchangeables.

Pourquoi le sujet devient urgent ?

Le problème arrive souvent au même moment : le prototype marche, tout le monde est content, puis on essaie de le mettre en production. Et là, le modèle qui répondait tranquillement sur une machine de test devient une vraie ligne de coût.

Prenons un modèle 70B. En FP16, c’est-à-dire avec des poids stockés sur 16 bits, il faut déjà environ 140 Go de VRAM rien que pour les poids. Et ça, c’est avant les activations, le KV cache, le contexte long, les batchs, la marge d’exploitation. Dans la vraie vie, on finit vite avec plusieurs GPU haut de gamme, donc une infra chère, plus complexe à maintenir, et pas forcément simple à scaler.

La compression change l’équation. Un modèle qui demandait une machine lourde peut parfois tourner sur un seul GPU. Et selon la taille du modèle, le niveau de quantification et l’usage, on peut même descendre sur du matériel beaucoup plus accessible. Avec la quantification 4-bit, certains modèles passent de dizaines de Go à des tailles bien plus basses. Je reste prudent : la qualité ne reste pas identique dans tous les cas. Ça dépend du modèle, des données, de la tâche, et de la manière dont la compression est faite.

Ce n’est pas un débat théorique. Ça touche directement les usages que je vois chez les clients :

• Les assistants internes, où une réponse lente casse vite l’adoption.
• Le support client, où chaque seconde ajoute du coût et de la frustration.
• L’extraction d’information, où on veut traiter beaucoup de documents sans exploser le budget.
• Les agents IA, qui enchaînent plusieurs appels au modèle et amplifient chaque milliseconde perdue.
• La recherche documentaire et la génération de texte en temps réel, où la latence devient visible immédiatement.

La latence, ce n’est pas juste un détail d’ingénieur. C’est ce qui décide si l’utilisateur garde l’outil ouvert ou retourne à ses vieilles habitudes. C’est aussi ce qui fait varier le coût par requête, surtout quand le volume monte.

On voit bien que l’industrie a déjà basculé. Hugging Face, bitsandbytes, llama.cpp avec GGUF, TensorRT-LLM, ou encore les outils mobiles d’Apple et Google ont rendu les modèles quantifiés beaucoup plus courants. Pas parce que c’est élégant sur le papier. Parce que ça permet de déployer.

Mais compresser un modèle, ce n’est pas magique. Si c’est mal contrôlé, on peut gagner en VRAM et perdre exactement ce qui faisait la valeur du modèle.

Quels risques si on compresse mal ?

Compresser un LLM, c’est un compromis. Je gagne en VRAM, en vitesse, en coût, mais je peux aussi perdre une partie de ce qui rend le modèle utile. Le piège, c’est qu’un modèle mal compressé ne devient pas forcément mauvais partout. Il devient parfois juste un peu moins fiable, et c’est là que ça devient dangereux.

Je vois surtout deux erreurs classiques.

• Ne pas compresser du tout. Le modèle reste propre, mais il coûte trop cher, il consomme trop de VRAM, il répond trop lentement, et au final personne ne l’utilise vraiment en production.
• Compresser trop fort. Le modèle tourne enfin sur la bonne machine, mais il perd en qualité. Et si vous ne mesurez pas cette perte, vous avez juste déplacé le problème.

La dégradation est souvent discrète. Le modèle répond avec plus de flou. Il se trompe davantage sur les nombres. Il tient moins bien le contexte. Son raisonnement devient moins stable. Il hallucine plus souvent sur certains cas métier. Il baisse en qualité sur les prompts longs, là où justement vous aviez besoin de lui.

Une simple démo ne suffit pas. Franchement, j’ai déjà vu des modèles compressés passer une démo de 5 minutes sans souci, puis échouer sur des cas clients très ordinaires. Un prompt court, bien formulé, ce n’est pas la vraie vie.

La validation simple, c’est de comparer le modèle d’origine et le modèle compressé sur un jeu de prompts représentatif de votre business. Pas 3 prompts choisis à la main. Un vrai petit échantillon avec des demandes faciles, longues, ambiguës, sensibles, chiffrées, et proches de vos usages réels. Je mesure la qualité de réponse, la latence, le coût par requête, la consommation mémoire, et surtout les erreurs critiques. Les métriques automatiques peuvent aider, par exemple pour noter la similarité ou détecter des réponses vides, mais sur les cas sensibles, une évaluation métier reste obligatoire.

Élément à tester	Pourquoi c’est important	Signal d’alerte
VRAM	La VRAM, c’est la mémoire de la carte graphique utilisée pour charger et exécuter le modèle.	Le modèle dépasse la mémoire disponible ou force des ralentissements.
Latence	Un modèle trop lent casse l’expérience utilisateur, même s’il répond bien.	Les réponses deviennent imprévisibles ou trop longues aux heures de charge.
Qualité métier	Le modèle doit réussir vos cas réels, pas seulement des prompts génériques.	Les réponses semblent correctes mais ratent les contraintes métier.
Réponses longues	La compression peut réduire la tenue du contexte sur les prompts détaillés.	Le modèle oublie des consignes ou mélange des informations.
Coûts d’inférence	L’inférence, c’est le coût d’exécution du modèle à chaque requête.	Le gain mémoire ne réduit pas vraiment le coût global.
Stabilité en production	Un modèle doit rester fiable avec du volume, pas seulement en test local.	Les erreurs augmentent selon la charge, la longueur ou certains types de prompts.

Comment choisir la bonne méthode ?

Pour beaucoup de projets, je teste d’abord une quantification post-training en 8-bit ou 4-bit, parce que c’est souvent le chemin le plus rapide pour réduire la VRAM, la mémoire vidéo du GPU. Ça évite de repartir dans un gros chantier, et on voit vite si le modèle tient encore la route.

Je privilégie la quantification quand le modèle est déjà bon, mais trop lourd. Typiquement, vous avez un LLM qui répond bien, sauf qu’il ne rentre pas sur votre GPU, ou alors il coûte trop cher à servir dans le cloud. La quantification réduit la précision des poids du modèle, par exemple en passant de nombres très précis à des nombres plus compacts. On perd parfois un peu en qualité, mais sur beaucoup d’usages, la perte reste acceptable.

Je regarde plutôt le pruning quand j’ai besoin de réduire réellement l’architecture. Le pruning consiste à supprimer des poids, des neurones, parfois des blocs entiers du modèle. Là, on cherche un gain plus structurel, pas juste une compression numérique. Mais il faut accepter de réévaluer sérieusement le modèle, et souvent de le fine-tuner, c’est-à-dire le réentraîner légèrement sur vos données pour récupérer de la qualité.

Ma logique est assez simple. Je mesure d’abord le modèle de base avec les vrais cas d’usage. Je quantifie ensuite en 8-bit, puis parfois en 4-bit. Je compare la qualité, la latence, la mémoire, le coût. J’ajuste les paramètres si besoin. Si ça ne suffit pas, seulement là je regarde le pruning. J’ai vu trop d’équipes commencer par des méthodes complexes alors qu’une quantification propre réglait déjà 80% du problème.

Pour la production, je ne me fie jamais uniquement à un benchmark générique. Il faut tester avec la vraie longueur de contexte, le vrai trafic attendu et les vrais prompts. Un modèle peut être parfait sur un test court, puis exploser en VRAM dès qu’on lui donne 12 000 tokens de contexte.

Situation	Méthode à tester en premier	Point de vigilance
Manque de VRAM	Quantification 8-bit, puis 4-bit si nécessaire	Vérifier la qualité sur vos prompts longs
Latence trop élevée	Quantification, puis pruning si le gain reste faible	Mesurer aussi le temps de génération token par token
Déploiement mobile ou edge	Quantification 4-bit ou formats spécialisés	Tester sur le vrai matériel, pas seulement sur serveur
Qualité métier très sensible	Quantification 8-bit prudente	Prévoir une évaluation humaine ou métier avant validation
Coût cloud trop élevé	Quantification, puis pruning si besoin de réduire plus fort	Comparer le coût complet, GPU, latence et volume de requêtes

Vous voulez un LLM plus léger sans perdre le contrôle ?

Alléger un LLM, ce n’est pas juste chercher le plus petit fichier possible. La quantification réduit la précision des poids, le pruning retire des parties du modèle. Les deux peuvent baisser la VRAM, les coûts et la latence, mais ils doivent être testés sérieusement. Je partirais presque toujours d’une mesure propre du modèle de base, puis d’une quantification contrôlée, avant de toucher à l’architecture avec du pruning. Le bénéfice pour vous est simple : déployer des modèles plus réalistes, moins chers, plus rapides, sans découvrir trop tard que la qualité s’est écroulée.

FAQ

• Quelle est la différence entre quantification et pruning d’un LLM ?
  La quantification réduit la précision des nombres utilisés pour stocker les poids du modèle, par exemple de FP16 vers 8-bit ou 4-bit. Le pruning supprime vraiment des éléments du modèle, comme des poids, des têtes d’attention ou des couches. Les deux réduisent l’empreinte, mais pas de la même manière.
• Pourquoi un LLM 70B demande autant de VRAM ?
  En FP16, chaque paramètre prend environ 2 octets. Un modèle de 70 milliards de paramètres demande donc environ 140 Go rien que pour les poids. En production, il faut aussi compter le contexte, le KV cache, les activations et la marge nécessaire pour servir les requêtes.
• La quantification 4-bit détruit-elle toujours la qualité ?
  Pas toujours. Sur beaucoup d’usages, une bonne quantification 4-bit peut garder une qualité correcte tout en réduisant fortement la mémoire. Mais ça dépend du modèle, de la méthode utilisée, des prompts et du niveau d’exigence métier. Il faut comparer avec le modèle original sur vos vrais cas d’usage.
• Le pruning accélère-t-il forcément l’inférence ?
  Pas forcément. Le pruning structuré peut produire des gains plus faciles à exploiter, car il retire des blocs entiers. Le pruning non structuré peut réduire le nombre de poids, mais ne pas accélérer beaucoup si le matériel ou les librairies ne savent pas en profiter correctement.
• Quelle méthode tester en premier pour alléger un LLM ?
  Je testerais d’abord une quantification post-training en 8-bit ou 4-bit, parce que c’est souvent le plus rapide pour réduire la VRAM. Ensuite seulement, si les gains ne suffisent pas ou si l’architecture reste trop lourde, je regarderais le pruning avec une vraie évaluation qualité.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en Tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. Avec webAnalyste et Formations Analytics, j’accompagne des équipes qui veulent rendre leurs systèmes data et IA vraiment exploitables, pas juste jolis en démo. J’ai travaillé pour des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez cadrer, automatiser ou industrialiser vos usages IA, contactez-moi.