Comment la quantization allège-t-elle un LLM ?

La quantization allège un LLM en codant ses poids sur moins de bits, et le pruning va plus loin en supprimant ce qui sert peu. Le gain est très concret : moins de mémoire, moins de GPU, moins de latence. Mais mal fait, ça casse la qualité sans prévenir.

Que réduit vraiment la quantization ?

La quantization réduit la précision numérique des poids du modèle, pas le nombre de paramètres. C’est le point le plus important à garder en tête. Un modèle 70B reste un modèle avec environ 70 milliards de poids. On ne lui enlève pas des neurones comme on taillerait une haie. On change surtout la manière dont ces poids sont stockés et utilisés pendant l’inférence.

Beaucoup de LLM sont entraînés ou stockés en FP16. FP16 veut dire “floating point 16 bits”, donc un nombre décimal représenté sur 16 bits, soit environ 2 octets. Si je prends un modèle 70B, ça donne 70 milliards de poids x 2 octets = environ 140 Go rien que pour les poids. Et là, on n’a pas encore parlé du cache KV, des buffers mémoire, du runtime, ni de tout ce que le framework garde autour pour faire tourner le modèle.

Quand on passe en 8-bit, on représente chaque poids avec 1 octet au lieu de 2. Quand on descend en 4-bit, on descend à un demi-octet par poids, en simplifiant un peu. L’idée est simple : on remplace des nombres très précis par des représentations plus compactes. On accepte une petite perte de précision pour gagner beaucoup en mémoire.

Je vois souvent la confusion chez les clients. Ils pensent qu’on compresse un modèle comme un fichier zip, puis qu’on le décompresse au moment de l’utiliser. Ce n’est pas ça. En réalité, on change la représentation numérique des poids pendant l’inférence. Le modèle travaille directement avec ces poids quantifiés, parfois avec des calculs intermédiaires dans une précision plus haute pour éviter trop de casse.

Les méthodes courantes essaient justement de réduire cette casse.

• GPTQ quantifie après l’entraînement. Son objectif est de limiter l’erreur de reconstruction, c’est-à-dire garder un comportement le plus proche possible du modèle original.
• AWQ protège davantage certains poids jugés importants pour les activations. Les activations, ce sont les valeurs produites à l’intérieur du modèle quand il traite votre prompt.
• Bitsandbytes et les formats open source récents ont rendu le 4-bit beaucoup plus accessible, sans devoir être chercheur CUDA pendant trois semaines.

Format	Mémoire	Qualité attendue	Complexité de déploiement
FP16	Élevée	Très proche du modèle original	Simple, mais coûteux en GPU
8-bit	Environ divisée par 2	Très bonne dans la plupart des cas	Plutôt simple aujourd’hui
4-bit	Environ divisée par 4	Bonne, mais plus sensible aux cas limites	Un peu plus technique, selon le modèle et le runtime

Que supprime vraiment le pruning ?

Le pruning réduit le modèle en supprimant des poids, des connexions ou parfois des structures entières. C’est littéralement une coupe dans le réseau. Là où la quantization compresse la façon dont les nombres sont stockés, le pruning enlève une partie du modèle.

Je le sépare toujours en deux familles, parce que ça change tout côté performance réelle.

• Le pruning non structuré enlève des poids isolés. Par exemple, certains nombres dans les matrices du modèle passent à zéro parce qu’ils sont jugés peu utiles. Sur le papier, ça crée de la sparsité, c’est-à-dire beaucoup de zéros dans les calculs. Le problème, c’est que tous les GPU ou moteurs d’inférence ne savent pas profiter de ces zéros. Vous pouvez donc réduire la taille théorique sans forcément accélérer le modèle en production.
• Le pruning structuré retire des morceaux plus propres à exécuter. On peut enlever des têtes d’attention, des neurones, des canaux, des couches ou des composants complets selon l’architecture. C’est souvent plus intéressant pour servir un modèle, parce que le matériel voit vraiment moins de calcul à faire.

La différence avec la quantization est simple. La quantization garde le même nombre de paramètres, mais les encode avec moins de bits. Un poids qui était stocké en 16-bit peut passer en 8-bit ou 4-bit. Le pruning, lui, retire des poids ou des blocs. Il ne compresse pas seulement les nombres, il coupe dans le modèle.

Les deux techniques peuvent très bien se cumuler. Par exemple, je peux quantifier un modèle 70B en 4-bit pour faire baisser fortement la mémoire nécessaire, puis pruner certaines structures pour réduire une partie du calcul. Dans la vraie vie, je ne le ferais pas à l’aveugle. J’ai déjà vu des modèles “optimisés” perdre exactement ce qui faisait leur valeur sur une tâche métier précise. Le pruning propre demande des tests, parfois du fine-tuning, c’est-à-dire un petit réentraînement pour récupérer de la qualité, et surtout une mesure sur vos vrais cas d’usage.

Approche	Nombre de paramètres	Précision des poids	Impact mémoire	Impact vitesse	Risque qualité
Quantization	Identique	Réduite, par exemple 16-bit vers 4-bit	Fort	Variable, souvent bon si le matériel suit	Modéré si bien calibré
Pruning non structuré	Réduit en théorie	Identique pour les poids restants	Variable	Pas garanti sans support de la sparsité	Modéré à élevé
Pruning structuré	Réduit réellement	Identique pour les poids restants	Bon	Souvent meilleur car moins de blocs à calculer	Élevé si on coupe les mauvais composants

Pourquoi c’est devenu indispensable ?

C’est devenu indispensable parce qu’un LLM non compressé coûte vite trop cher à servir.

Quand je parle de coût, je ne parle pas juste du prix du modèle ou du GPU affiché sur une grille cloud. Je parle de mémoire, de débit, de latence, de disponibilité, et de cette réalité assez brutale : si le modèle ne rentre pas dans la mémoire disponible, il ne part pas en production.

Prenez un modèle de 70 milliards de paramètres. En FP16, c’est-à-dire avec des poids stockés sur 16 bits, il faut environ 140 Go rien que pour les poids du modèle. Ça veut dire plusieurs GPU, ou une carte très spécialisée, avec toute la complexité qui va avec. En 4-bit, on descend plutôt autour de 35 à 40 Go en pratique, parce qu’il faut ajouter les métadonnées, les échelles de quantization, parfois des contraintes d’alignement mémoire, et tout ce qui vit autour du modèle.

Ce changement paraît technique, mais il change tout côté infra.

• Un modèle qui demandait un petit cluster GPU peut parfois passer sur une seule carte haut de gamme.
• Une carte moins saturée laisse plus de place au cache KV, la mémoire utilisée pour garder le contexte pendant la génération.
• Plus de cache KV veut dire plus d’utilisateurs simultanés, ou des contextes plus longs, sans exploser la latence.
• Moins de mémoire utilisée veut aussi dire moins de facture cloud, et souvent moins de galères d’orchestration.

Bien sûr, ça dépend du contexte. La longueur de contexte, la taille des batchs, le niveau de disponibilité attendu, tout ça compte. Servir un assistant interne à 20 personnes, ce n’est pas servir une API publique avec des pics de trafic.

Les acteurs industriels ne font pas des modèles compacts et des versions quantifiées pour le plaisir. Des familles comme Gemma existent aussi parce qu’il faut des modèles plus simples à déployer. Apple pousse beaucoup l’exécution locale et les modèles plus petits pour la même raison : la contrainte économique et matérielle est réelle.

Sur le terrain, je vois souvent la même chose. Beaucoup de projets IA ne bloquent pas vraiment à cause du modèle. Ils bloquent quand les premiers utilisateurs arrivent, que l’inférence tourne en continu, et que la facture commence à ressembler à un vrai sujet business.

Quels risques si on compresse mal ?

Une mauvaise compression peut rendre le modèle moins fiable sans que ça se voie tout de suite. C’est le piège classique avec les LLM : on gagne en vitesse, en mémoire, en coût… mais parfois on perd juste assez de qualité pour que les vrais problèmes arrivent en production, pas pendant la démo.

Je vois deux échecs assez fréquents.

• Premier échec : ne pas compresser du tout. Le modèle tourne très bien en test, il répond proprement, tout le monde est content. Puis on essaie de le servir à grande échelle, avec de vrais utilisateurs, des pics de trafic, des contraintes de coût. Et là, ça coince. Trop lourd en mémoire, trop lent à répondre, trop cher par requête. Un modèle excellent mais impossible à exploiter correctement, ça reste un mauvais choix produit.
• Deuxième échec : compresser trop fort ou trop vite. Là, c’est plus dangereux parce que la baisse de qualité est souvent discrète. Le modèle répond toujours. Il a même l’air correct. Mais il devient moins précis, son raisonnement tient moins bien, les hallucinations augmentent, le ton varie davantage. Et sur certains cas métier, ceux qui comptent vraiment, les performances peuvent s’écrouler.

Le seul moyen de ne pas piloter à l’aveugle, c’est de tester avant et après compression avec des mesures proches du vrai usage. Pas juste un score théorique sur un benchmark générique. Il faut regarder ce qui compte vraiment pour votre application.

Métrique	Ce que je vérifie
Exactitude	Le modèle donne-t-il toujours la bonne réponse ?
Taux de refus	Refuse-t-il trop souvent, ou pas assez ?
Cohérence	Reste-t-il stable sur des demandes proches ?
Latence	Répond-il assez vite en conditions réelles ?
Coût par requête	Le gain économique est-il réel ?
Mémoire utilisée	Le modèle rentre-t-il mieux dans l’infrastructure ?
Qualité perçue	Les utilisateurs sentent-ils une dégradation ?

Attention aussi aux moyennes globales. Une moyenne propre peut cacher une catastrophe sur un segment important : les longues requêtes, les langues moins fréquentes, les documents techniques, ou les cas à forte valeur business. J’ai déjà vu un modèle “validé” sur le score global, puis mauvais sur les 5 % de demandes qui généraient le plus de valeur.

Ma logique est simple : je pars d’une quantization raisonnable, je mesure, je compare avec le modèle de référence, puis seulement après j’envisage le pruning, c’est-à-dire la suppression de certaines parties du modèle, si le gain économique justifie vraiment l’effort et le risque.

Alors, jusqu’où faut-il alléger votre LLM ?

J’allège un LLM quand le gain mémoire, coût et latence vaut plus que la petite perte de qualité possible. La quantization est souvent le premier levier, parce qu’elle réduit fortement l’empreinte sans changer l’architecture. Le pruning va plus loin, mais il demande plus de prudence, surtout si on touche à des structures importantes du modèle. Le bon réflexe, c’est de comparer avant et après sur vos vrais cas d’usage, pas sur une intuition. Si vous faites ça proprement, vous gardez un modèle utile, plus simple à déployer, et surtout beaucoup moins cher à faire tourner.

FAQ

• Quelle est la différence entre quantization et pruning ?
  La quantization réduit le nombre de bits utilisés pour stocker les poids du LLM, par exemple de FP16 vers 8-bit ou 4-bit. Le pruning supprime des poids ou des structures du modèle. La première change la précision numérique, le second change la taille réelle du modèle.
• Est-ce qu’un LLM quantifié perd forcément en qualité ?
  Il peut perdre un peu en qualité, mais ce n’est pas automatique ni toujours visible. Une quantization bien choisie, avec des méthodes comme GPTQ ou AWQ, peut garder un très bon niveau pour beaucoup d’usages. Le vrai sujet, c’est de tester sur vos cas métier.
• Pourquoi le 4-bit est autant utilisé pour les LLM ?
  Parce qu’il divise fortement l’empreinte mémoire. Un modèle 70B en FP16 représente environ 140 Go pour les poids, alors qu’en 4-bit il peut descendre autour de 35 à 40 Go selon l’implémentation. Ça change complètement les options de déploiement.
• Le pruning accélère-t-il toujours l’inférence ?
  Pas toujours. Le pruning non structuré peut réduire la taille théorique sans accélérer beaucoup si le matériel ne sait pas exploiter les poids supprimés. Le pruning structuré est souvent plus exploitable, parce qu’il retire des blocs entiers plus faciles à optimiser.
• Quelle approche choisir en premier pour alléger un LLM ?
  Je commence souvent par la quantization, parce qu’elle donne un gros gain mémoire avec un effort raisonnable. Ensuite je mesure la qualité, la latence et le coût par requête. Le pruning vient après si le modèle reste trop lourd ou trop cher à servir.

 

 

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 passer de la démo IA au vrai déploiement business, avec des contraintes très concrètes de coût, performance, données et industrialisation. 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 ou industrialiser vos projets IA, contactez-moi.