Comment alléger un LLM par quantification et pruning ?

J’allège un LLM en réduisant sa précision numérique et parfois sa structure. C’est souvent ce qui sépare une belle démo d’un vrai déploiement. On va voir quand utiliser la quantification, quand utiliser le pruning, et pourquoi le faire mal coûte vite cher.

C’est quoi la quantification ?

La quantification réduit la précision des nombres utilisés par le modèle sans forcément changer son architecture.

Concrètement, un LLM stocke ses poids avec des nombres. Ces poids peuvent être en FP16, c’est-à-dire des nombres flottants sur 16 bits, ou en INT8, INT4, parfois encore plus bas selon les méthodes. Plus on descend en bits, moins le modèle prend de place en mémoire. Et ça change vite la facture.

Un modèle 70B en FP16 peut occuper autour de 140 Go de VRAM, rien que pour les poids. C’est énorme. En 4-bit, avec des méthodes comme AWQ ou GPTQ, on peut descendre autour de 35 à 40 Go, selon le modèle, le format exact et le runtime utilisé. J’ai déjà vu des équipes bloquées juste à cause de ça : le modèle était bon, mais impossible à servir proprement sans exploser le budget GPU.

Le point important, c’est que la quantification ne supprime pas les paramètres. Elle ne dit pas “ce poids n’existe plus”. Elle dit plutôt “je vais représenter ce poids avec moins de bits”. C’est une compression de la représentation numérique, pas une coupe dans le modèle.

Il y a deux grandes familles à connaître :

• La quantification post-training se fait après l’entraînement. On prend un modèle déjà entraîné, puis on compresse ses poids. C’est le plus pratique en production.
• Le quantization-aware training intègre la quantification pendant l’entraînement ou le fine-tuning. Le modèle apprend avec cette contrainte, donc il peut mieux encaisser la baisse de précision.

Les modèles compacts récents vont clairement dans ce sens. Les variantes de Gemma, et certains travaux d’Apple sur les modèles embarqués, montrent bien que la compression devient centrale. Si on veut faire tourner de l’IA sur un laptop, un téléphone, ou un petit serveur, on ne peut pas juste empiler des milliards de paramètres en FP16 et espérer que ça passe.

Précision	Taille mémoire approximative	Intérêt	Risque principal
FP16	Très élevée, environ 140 Go pour un 70B	Bonne qualité, format courant	Coût GPU important
INT8	Environ moitié moins que FP16	Bon compromis qualité mémoire	Légère perte possible
INT4	Environ 35 à 40 Go pour un 70B	Gros gain mémoire et coût	Dégradation si mauvaise méthode
Plus bas	Encore plus compact	Utile sur matériel très contraint	Perte de qualité plus visible

C’est quoi le pruning ?

Le pruning, ou élagage, consiste à retirer ce qui contribue peu au résultat du modèle. Au lieu de seulement réduire la précision des nombres comme avec la quantification, on enlève carrément une partie du modèle, ou on la rend inactive.

Dit simplement, on cherche les morceaux qui pèsent dans le calcul, mais qui changent peu la réponse finale. Ça peut se faire à plusieurs niveaux, sans rentrer dans une théorie interminable :

• Poids individuels : On met à zéro certains coefficients du modèle.
• Neurones : On retire des unités complètes qui apportent peu d’information.
• Têtes d’attention : Dans un Transformer, certaines têtes analysent les relations entre tokens, mais toutes ne sont pas forcément utiles.
• Blocs ou couches entières : On supprime des parties plus grosses du réseau, ce qui peut donner des gains plus visibles.

La différence avec la quantification est importante. La quantification garde globalement le même nombre de paramètres, mais stockés avec moins de précision, par exemple en 8 bits au lieu de 16. Le pruning, lui, réduit la structure du modèle ou sa densité. On ne compresse pas juste les nombres, on coupe dans le modèle.

Sur le papier, c’est très séduisant. En production, c’est souvent plus délicat. Un modèle élagué doit parfois être réentraîné pour récupérer de la qualité, recalibré pour éviter des sorties instables, ou servi avec un moteur d’inférence capable d’exploiter cette nouvelle structure. Sinon, le gain reste théorique.

Un exemple simple : si je retire des têtes d’attention peu utiles, je réduis normalement une partie du calcul. Mais si le runtime, c’est-à-dire le moteur qui exécute le modèle en production, ne sait pas tirer parti de cette structure modifiée, la latence peut à peine bouger. J’ai déjà vu des équipes annoncer une belle réduction théorique, puis mesurer presque aucun gain réel, juste parce que le déploiement n’était pas adapté.

Le pruning n’est donc pas magique. Il demande plus de validation que la quantification. Mais il ne s’y oppose pas. Les deux peuvent très bien se compléter : on peut élaguer un modèle pour enlever l’inutile, puis le quantifier pour réduire encore la mémoire et accélérer l’inférence.

Pourquoi ça change le coût ?

Ça change le coût parce que la mémoire GPU est souvent la vraie limite d’un LLM en production. Pas la théorie, pas le benchmark sympa en notebook. La VRAM, c’est-à-dire la mémoire disponible sur la carte graphique, décide très vite si votre modèle tourne, combien d’utilisateurs il peut servir, et combien la facture pique.

Je vois souvent le même scénario. Une équipe obtient de bons résultats en entraînement, tout le monde est content, puis arrive le moment de déployer. Et là, le checkpoint fait 140 Go. Sur le papier, le modèle est bon. Dans la vraie vie, l’infra prévue ne suit pas. Il faut plusieurs GPU haut de gamme, parfois changer de cloud, revoir le serving, exploser le budget, ou abandonner certaines fonctionnalités.

La quantification et le pruning changent ça parce qu’ils réduisent la taille utile du modèle. La quantification baisse la précision des poids, par exemple de FP16 vers 8-bit ou 4-bit. FP16 veut dire “floating point 16 bits”, une façon de stocker les nombres du modèle. Le pruning supprime des poids ou des parties moins utiles du réseau. Moins de poids, moins de mémoire, moins de calcul.

• Moins de GPU à louer ou acheter.
• Moins de VRAM nécessaire par instance.
• Moins de consommation électrique.
• Moins de machines à surveiller et maintenir.
• Une latence plus basse, donc une réponse plus rapide.
• Plus d’utilisateurs servis avec le même budget.

Un exemple simple. Un modèle 70B en FP16 demande souvent plusieurs GPU haut de gamme pour tourner correctement. Une version 4-bit peut parfois tenir sur une seule carte très équipée, selon le modèle, le contexte, le moteur d’inférence et le volume de trafic. Ce n’est pas magique, mais ça change totalement la discussion budgétaire.

Et ce n’est pas juste un sujet technique. Pour un chatbot, un assistant vocal ou de l’autocomplétion, quelques centaines de millisecondes changent l’expérience. Si l’utilisateur attend trop, il coupe, il reformule, ou il n’utilise plus l’outil. J’ai vu des projets où le “bon modèle” était simplement trop lent pour être acceptable.

from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig

model_id = "votre-modele-ici"

quant_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_compute_dtype="float16",
    bnb_4bit_quant_type="nf4"
)

tokenizer = AutoTokenizer.from_pretrained(model_id)

model = AutoModelForCausalLM.from_pretrained(
    model_id,
    quantization_config=quant_config,
    device_map="auto"
)

C’est un exemple de principe avec transformers et bitsandbytes. Il faut l’adapter au modèle, à sa licence, à votre GPU, à vos contraintes de sécurité et à votre infrastructure de déploiement.

Que se passe-t-il si on compresse mal ?

Mal compresser un LLM peut coûter autant que ne pas le compresser, parfois plus. On perd de la qualité, mais on ne récupère pas assez de performance pour que ça vaille le coup. C’est le pire scénario : un modèle moins fiable, pas vraiment plus rapide, et une équipe qui découvre les problèmes en production.

Le risque le plus visible, c’est l’augmentation des hallucinations. Le modèle invente plus facilement, ou devient plus flou quand il n’est pas sûr. Mais il y a aussi des effets moins évidents : une baisse sur des tâches rares, des réponses plus courtes, une génération moins stable d’un appel à l’autre, ou des régressions invisibles dans des tests trop simples. J’ai déjà vu un modèle quantifié qui passait très bien les prompts classiques, mais qui cassait dès qu’on lui demandait du JSON strict avec des champs optionnels.

Il ne faut surtout pas juger une compression seulement avec une métrique globale. Une moyenne peut cacher des dégâts énormes sur vos vrais cas d’usage. Ce qui compte, c’est votre métier, vos prompts, vos contraintes, vos utilisateurs.

• Tester des conversations longues, parce que le contexte révèle souvent les pertes de stabilité.
• Tester l’extraction structurée, surtout si le modèle doit remplir des champs précis.
• Tester la génération JSON, avec validation stricte derrière.
• Tester du raisonnement simple, pas des énigmes absurdes, juste vos vrais raisonnements métier.
• Tester le multilingue si vos utilisateurs changent de langue.
• Tester les prompts sensibles, ambigus, ou proches des limites de sécurité.
• Tester le temps de réponse sous charge, pas juste une requête isolée sur une machine tranquille.

Certains modèles supportent très bien l’INT8, c’est-à-dire une représentation numérique plus légère que le format classique, avec une perte minime. Le 4-bit est souvent un bon compromis pour réduire fortement la mémoire, mais ça dépend vraiment du modèle, des données et du niveau d’exigence. Le pruning, lui, peut être très efficace, mais seulement s’il est validé sérieusement.

Approche	Résultat probable	Risque principal
Absence de compression	Qualité conservée, coûts élevés, latence parfois trop forte.	Infrastructure surdimensionnée et passage à l’échelle difficile.
Quantification trop agressive	Modèle plus léger, mais réponses moins fiables.	Hallucinations, JSON cassé, raisonnement dégradé.
Pruning non validé	Modèle amputé sans certitude sur l’impact réel.	Perte sur des cas rares ou métiers, difficile à détecter.
Compression bien testée	Bon équilibre entre coût, vitesse et qualité.	Risque maîtrisé grâce aux tests réels et au monitoring.

Comment choisir la bonne méthode ?

Je choisis rarement une méthode de compression “parce qu’elle est à la mode”. Je pars de trois contraintes très concrètes : la qualité minimale acceptable, le budget d’inférence et le matériel cible. Dit autrement : qu’est-ce que le modèle a le droit de perdre, combien chaque requête peut coûter, et sur quoi ça doit tourner.

Ma logique est simple. Je commence avec une baseline en FP16 ou BF16, donc un modèle peu compressé, assez fiable, qui me sert de référence. Je mesure la qualité, la latence, la VRAM consommée. Puis je teste INT8. INT8 veut dire que les poids du modèle sont encodés sur 8 bits au lieu de 16, donc ça réduit la mémoire sans trop casser la qualité dans beaucoup de cas.

Si INT8 passe bien, je tente le 4-bit avec AWQ ou GPTQ. Là, on compresse plus fort. AWQ et GPTQ sont deux méthodes de quantification pensées pour garder les poids importants du modèle aussi propres que possible. C’est souvent très efficace, mais je ne le valide jamais juste sur un benchmark générique. J’ai déjà vu un modèle 4-bit impeccable sur des tests publics, puis moyen sur les prompts réels d’un client, surtout avec du vocabulaire métier.

Le pruning, je l’envisage seulement si l’architecture et le runtime donnent un vrai gain. Pruner, c’est retirer des connexions, des neurones ou des blocs jugés moins utiles. Sur le papier c’est séduisant. Dans la vraie vie, si le moteur d’inférence ne sait pas exploiter cette sparsité, vous avez surtout gagné de la complexité.

En production, je préfère presque toujours une compression un peu moins agressive mais stable, plutôt qu’un modèle minuscule qui casse sur les cas clients. Le coût d’une mauvaise réponse peut vite dépasser l’économie GPU.

Mon plan de validation reste assez terre-à-terre :

• Je crée un jeu de prompts métiers, avec des cas simples, limites et sensibles.
• Je compare les réponses avant et après compression.
• Je mesure la VRAM, les tokens par seconde, la latence p95 et le coût pour 1 000 requêtes.
• Je fais relire les réponses sensibles par un humain, surtout si le modèle conseille, résume ou décide.

On peut pousser plus fort sur des prototypes, des assistants internes, du edge device, du mobile ou du traitement batch. Là, une petite perte de qualité peut être acceptable. Je suis beaucoup plus prudent sur le juridique, la santé, la finance et le support client exposé. Là, chaque approximation se voit.

Contrainte principale	Choix conseillé
Qualité prioritaire, faible risque accepté	INT8
VRAM très limitée, qualité encore correcte	INT4 avec AWQ ou GPTQ
Runtime optimisé pour la sparsité	Pruning
Matériel contraint et gros volume	INT4 + pruning, seulement après tests solides
Cas métier sensible ou exposé client	INT8 ou FP16/BF16, avec validation humaine

Alors, quel LLM pouvez-vous vraiment déployer ?

Je résume simplement : un LLM performant mais trop lourd reste un problème, pas une solution. La quantification réduit la précision des poids pour gagner vite en mémoire et en coût. Le pruning va plus loin en retirant une partie du modèle, mais il demande plus de prudence. Le bon choix dépend de votre matériel, de votre niveau de qualité attendu et de vos usages réels. Mon réflexe, c’est de mesurer avant et après, sur des prompts métiers, pas sur une impression. Le bénéfice pour vous est clair : déployer un modèle plus rapide, moins cher, et vraiment utilisable.

FAQ

• Quelle est la différence entre quantification et pruning ?
  La quantification réduit la précision numérique des poids, par exemple de FP16 vers INT8 ou INT4. Le pruning supprime une partie du modèle, comme des poids, des têtes d’attention ou des couches. Les deux techniques peuvent être combinées, mais elles ne résolvent pas exactement le même problème.
• Est-ce qu’un LLM quantifié est forcément moins bon ?
  Pas forcément. Une quantification bien faite, surtout en INT8 ou en 4-bit avec une méthode adaptée, peut garder une qualité très proche du modèle original. Le vrai sujet, c’est de tester sur vos cas d’usage réels, parce qu’une petite perte invisible sur un benchmark peut être gênante dans votre produit.
• Pourquoi le 4-bit est autant utilisé pour les LLM ?
  Le 4-bit offre souvent un bon compromis entre taille, coût et qualité. Il peut diviser fortement la mémoire nécessaire et rendre un grand modèle exploitable sur moins de GPU. Des méthodes comme AWQ ou GPTQ sont utilisées pour limiter la perte de performance, mais le résultat dépend toujours du modèle et du runtime.
• Le pruning réduit-il toujours la latence ?
  Non. Sur le papier, retirer des parties du modèle réduit le calcul. En pratique, le gain dépend du moteur d’inférence et du type de pruning. Un pruning non structuré peut réduire la taille théorique sans accélérer beaucoup l’exécution si le matériel ou le runtime ne l’exploite pas bien.
• Quelle méthode choisir pour déployer un LLM en production ?
  Je commence souvent par mesurer le modèle original, puis je teste INT8 et 4-bit avant de penser au pruning. Le bon choix dépend de votre budget GPU, de votre latence cible, de la qualité minimale acceptable et des usages métiers. Le meilleur modèle n’est pas le plus gros, c’est celui que vous pouvez servir proprement.

 

 

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. J’accompagne des équipes qui veulent rendre leurs systèmes data et IA plus fiables, plus mesurables et plus simples à exploiter en production. J’ai travaillé avec des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez cadrer un projet IA ou industrialiser vos automatisations, contactez-moi.