Comment la quantification LLM réduit vos coûts d’inférence ?

La quantification LLM réduit la mémoire, le coût GPU et souvent la latence, sans forcément sacrifier l’usage métier. Le vrai sujet, c’est de compresser proprement. Je vous montre où la quantification aide, quand le pruning complète, et comment éviter un modèle rapide mais inutilisable.

Que réduisent vraiment ces méthodes ?

Quand je regarde un checkpoint de 140 GB avec un client, je commence souvent par cette phrase toute simple : La quantification réduit la taille de chaque nombre, le pruning réduit le nombre de choses à stocker ou à calculer.

La quantification ne change pas le nombre de paramètres du modèle. Si votre LLM a 70 milliards de paramètres, il garde ses 70 milliards de paramètres. Ce qui change, c’est la précision numérique utilisée pour stocker les poids. Un poids, c’est une valeur apprise pendant l’entraînement. La précision, c’est le format de cette valeur. Par exemple FP16 veut dire nombre flottant sur 16 bits. INT8 veut dire entier sur 8 bits. 4-bit veut dire encore plus compressé, sur 4 bits.

Donc si vous passez de FP16 à INT8, vous ne rendez pas le modèle “plus petit” au sens architectural. Vous stockez juste chaque poids dans une boîte plus petite. C’est un peu comme garder exactement la même bibliothèque, mais remplacer les gros classeurs par des fiches plus compactes. Le contenu est toujours là, mais il est représenté avec moins de détails.

Le pruning, lui, fait autre chose. Il supprime directement des éléments du modèle : des poids, des connexions, des têtes d’attention, parfois même des couches. Une tête d’attention, pour faire simple, c’est un mécanisme qui aide le modèle à regarder certaines parties du contexte plutôt que d’autres. Là, on ne compresse pas seulement les nombres. On retire des morceaux jugés peu utiles.

C’est pour ça que ces méthodes ne résolvent pas exactement le même problème. La quantification attaque surtout la mémoire consommée par les poids et peut accélérer l’inférence si le matériel sait bien exécuter ces formats. Le pruning attaque plutôt la structure et parfois le volume de calcul. Les deux peuvent se compléter, mais mal appliquées, elles peuvent aussi casser la qualité du modèle.

Le calcul brut donne déjà une idée très claire. 70 milliards de paramètres en FP16, c’est environ 140 GB rien que pour les poids. Et là, on n’a pas encore parlé du cache KV, la mémoire utilisée pour garder le contexte pendant la génération, ni du runtime, ni de la marge GPU nécessaire pour que ça tourne sans planter. Donc non, un checkpoint de 140 GB n’est pas “prêt prod” juste parce qu’il tient sur un disque.

Méthode	Ce qui change	Ce qui ne change pas	Bénéfice principal	Risque principal
Quantification	La précision numérique des poids, par exemple FP16 vers INT8 ou 4-bit.	Le nombre de paramètres et l’architecture globale du modèle.	Moins de mémoire GPU consommée, inférence souvent moins chère.	Perte de qualité si la compression est trop agressive ou mal calibrée.
Pruning	Des poids, connexions, têtes d’attention ou couches peuvent être supprimés.	Le principe général du modèle et sa tâche cible.	Moins de calcul et parfois un modèle réellement plus léger.	Dégradation forte si on retire des composants utiles.
Quantification + pruning	La taille des nombres et certains composants du modèle.	Le besoin de tester la qualité sur vos vrais cas d’usage.	Réduction plus ambitieuse des coûts d’inférence.	Accumulation des pertes si les deux méthodes sont appliquées à l’aveugle.

Pourquoi ça change le déploiement ?

Ces méthodes changent le déploiement parce qu’elles transforment un modèle réservé à plusieurs GPU chers en modèle utilisable sur une machine beaucoup plus réaliste. C’est ça le vrai sujet. Pas juste “on compresse un peu”. On change la catégorie d’infrastructure nécessaire.

Prenez un LLM 70B, donc un modèle avec environ 70 milliards de paramètres. En FP16, c’est-à-dire avec des poids stockés sur 16 bits, on tourne vite autour de 140 GB de VRAM rien que pour les poids. La VRAM, c’est la mémoire de la carte graphique. Et 140 GB, dans la vraie vie, ça veut souvent dire plusieurs GPU type A100, avec toute la complexité qui va avec : coût, orchestration, consommation, latence entre cartes.

Avec une quantification 4-bit, on peut ramener l’ordre de grandeur vers 35 à 40 GB pour les poids, selon le format utilisé, les métadonnées ajoutées et le moteur d’inférence. Ce n’est pas magique, mais c’est énorme. D’un coup, on peut envisager une seule carte haut de gamme, ou une configuration bien plus accessible. J’ai vu ce basculement chez des clients : le sujet passe de “il nous faut un cluster” à “on peut tester ça sur une machine interne”. Ce n’est pas le même budget, ni le même délai de décision.

Cas	Ordre de grandeur mémoire pour les poids
LLM 70B en FP16	Environ 140 GB de VRAM
LLM 70B en 4-bit	Souvent autour de 35 à 40 GB, selon l’implémentation

Sur le terrain, les approches comme AWQ et GPTQ reviennent souvent. AWQ cherche à quantifier intelligemment en protégeant les poids les plus sensibles. GPTQ applique une quantification post-entraînement, donc après que le modèle a déjà été entraîné. Côté outils, on retrouve Hugging Face Transformers, bitsandbytes, AutoGPTQ, et llama.cpp quand on veut faire tourner des modèles de façon très pratique, parfois même sur CPU ou sur des machines modestes.

Les gros acteurs vont dans le même sens. Google propose Gemma avec des variantes 4-bit beaucoup plus légères. Apple pousse aussi des usages mobiles avec de la quantification-aware training, c’est-à-dire un entraînement qui anticipe la quantification dès le départ pour limiter la perte de qualité.

Il faut rester prudent sur les chiffres. La mémoire réelle dépend aussi du batch size, donc du nombre de requêtes traitées en parallèle, de la taille du contexte, du KV cache, qui stocke les clés et valeurs d’attention pendant la génération, et du framework utilisé. Mais côté business, l’impact est clair : moins de GPU, moins de coût d’inférence, une latence souvent plus basse, et beaucoup plus de possibilités en edge ou en on-premise.

Quelle quantification choisir ?

Le bon choix dépend surtout de quatre choses : le modèle, le matériel disponible, votre tolérance à la perte de qualité, et le niveau de contrôle que vous voulez garder. Je le vois souvent en mission : deux modèles de même taille peuvent réagir très différemment à la quantification. Donc je ne pars jamais du principe que “4-bit = jackpot”. Je teste.

Méthode	Quand je l’utilise
Post-training quantization	Quand le modèle est déjà entraîné et qu’on veut réduire vite la mémoire et les coûts, sans toucher à l’entraînement.
GPTQ	Quand je veux une compression assez précise après entraînement, souvent pour servir un modèle sur GPU avec moins de VRAM.
AWQ	Quand je veux protéger les poids les plus importants. AWQ regarde les activations, c’est-à-dire les valeurs produites quand le modèle traite des exemples.
Quantization-aware training	Quand on peut réentraîner ou fine-tuner. C’est plus lourd, mais souvent plus propre côté qualité.

Dans l’écosystème Transformers, bitsandbytes est souvent le chemin le plus simple pour charger un modèle en 8-bit ou 4-bit. Exemple en 4-bit :

from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig

model_id = "mistralai/Mistral-7B-Instruct-v0.2"

bnb_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=bnb_config,
    device_map="auto"
)

Le piège, c’est de regarder uniquement si le modèle répond. Moi je compare avant / après sur des prompts métier, pas sur trois questions génériques.

prompts = [
    "Résume ce contrat en 5 risques opérationnels.",
    "Extrais les champs client, montant, date et échéance au format JSON.",
    "Réponds à cette réclamation avec un ton professionnel."
]

for prompt in prompts:
    print("Prompt :", prompt)
    print("Réponse modèle original :", run_model(original_model, prompt))
    print("Réponse modèle quantifié :", run_model(quantized_model, prompt))

Le 4-bit peut être excellent, surtout pour réduire la VRAM et faire tourner des modèles plus gros sur la même machine. Mais ce n’est pas magique. Certains modèles encaissent très bien, d’autres perdent sur le raisonnement, les langues moins représentées, l’extraction structurée ou les sorties longues.

Ma règle simple : si la qualité est critique, je teste le 8-bit d’abord. Si le coût ou la VRAM bloquent vraiment, je teste ensuite le 4-bit, avec une vraie évaluation métier avant de valider.

Quand le pruning devient utile ?

Le pruning devient utile quand réduire la précision ne suffit plus, ou quand on veut aussi réduire une partie de la structure du modèle. La quantification baisse le poids des nombres, par exemple passer de FP16 à INT8 ou INT4. Le pruning, lui, essaie de supprimer ce qui semble moins utile dans le modèle.

Il y a deux grandes familles. Le pruning non structuré met certains poids à zéro. Sur le papier, c’est séduisant. En pratique, ça n’accélère pas toujours l’inférence, parce que beaucoup de GPU ne savent pas profiter efficacement de ces zéros sans moteur spécialisé. Vous avez un modèle plus “creux”, mais pas forcément plus rapide.

Le pruning structuré est plus exploitable. Là, on retire des éléments entiers : des neurones, des têtes d’attention, parfois des couches. Une tête d’attention, c’est une partie du modèle qui apprend à regarder certaines relations dans le texte. Quand on en supprime une, le gain est plus clair côté calcul, mais le risque est plus fort côté qualité.

Je le dis franchement, sur les LLM modernes, le pruning est souvent plus délicat que la quantification. On peut casser des comportements subtils sans le voir tout de suite. Le modèle répond encore bien sur trois prompts de démo, puis il rate une règle métier, une nuance juridique, une exception dans un workflow interne. J’ai vu ça chez un client avec un assistant interne. En test technique, tout allait plus vite. En usage réel, il commençait à zapper des cas spécifiques que les équipes support connaissaient par cœur.

Les outils à connaître existent. Dans PyTorch, torch.nn.utils.prune permet de comprendre les bases du pruning, surtout sur des modèles plus simples. Pour les LLM, je regarde souvent aussi la distillation. La distillation consiste à entraîner un modèle plus petit à imiter un gros modèle. Et parfois, le meilleur choix reste simplement de partir d’un modèle plus petit dès le départ.

Le vrai point, c’est l’évaluation. Il faut tester sur vos vrais cas d’usage, vos données, vos erreurs critiques, vos prompts longs, vos formats de sortie. Pas seulement sur une démo propre en réunion.

Approche	Principe	Avantage	Risque
Pruning non structuré	Met des poids individuels à zéro	Réduit la sparsité théorique du modèle	Accélération limitée sans moteur adapté
Pruning structuré	Retire neurones, têtes d’attention ou couches	Gains plus exploitables en calcul	Dégradation plus visible ou plus sournoise
Distillation	Fait apprendre un petit modèle à partir d’un gros	Souvent plus stable pour produire un modèle compact	Demande des données et un entraînement sérieux
Modèle plus petit	Choisit directement une architecture plus légère	Simple, robuste, facile à servir	Moins performant si le besoin est complexe

Comment valider sans casser la qualité ?

La validation se fait en comparant le modèle compressé au modèle de référence sur la qualité, la mémoire, la latence et le coût réel. Pas uniquement sur la taille du fichier. Un modèle 4-bit peut être très léger sur disque et pourtant perdre trop de précision, casser vos JSON, ou répondre moins bien sur les sujets qui rapportent vraiment.

En production, je fais simple. Je mesure d’abord le modèle original, souvent en FP16 ou BF16. FP16 et BF16, ce sont des formats de nombres utilisés pour faire tourner le modèle avec une bonne précision. Puis j’applique la compression, par exemple 8-bit ou 4-bit, et je rejoue exactement les mêmes prompts. Même température, mêmes paramètres, même limite de tokens. Sinon on compare du bruit.

Le jeu de test doit ressembler à votre vraie vie. Pas seulement trois questions génériques. Je mets des cas faciles, des cas limites, des sorties longues, des réponses attendues en JSON, des questions en français, et surtout des demandes proches du business. J’ai vu un modèle rester très correct sur des benchmarks publics, puis rater des extractions de clauses contractuelles chez un client. Sur la moyenne il était bon. Sur le travail utile, il ne l’était plus.

• Mesurer le modèle de référence : VRAM utilisée, tokens par seconde, temps de première réponse, coût par mille requêtes.
• Compresser le modèle : 8-bit, 4-bit, pruning ou autre méthode, sans changer le reste de l’environnement.
• Rejouer les mêmes prompts : Cas simples, cas ambigus, formats JSON, longues réponses, français, vocabulaire métier.
• Comparer la qualité : Exactitude métier, taux de réponses invalides, hallucinations, respect du format attendu.
• Fixer un seuil : Par exemple accepter 1 à 3 % de régression si le coût baisse fortement, mais pas 10 % sur une tâche critique.

Les benchmarks publics sont utiles pour filtrer. Mais ils ne suffisent pas. Un modèle peut garder une bonne note moyenne et devenir mauvais sur vos devis, vos tickets support, vos rapports médicaux ou vos règles internes. C’est là que le test métier tranche.

Situation	Décision
Qualité critique, faible tolérance aux erreurs, génération complexe	Garder FP16 ou BF16
Besoin de réduire la VRAM sans trop risquer la qualité	Passer en 8-bit
Coût GPU trop élevé, volume important, tâches assez simples	Tester 4-bit
Modèle trop lent avec beaucoup de parties peu utiles	Tenter le pruning
La compression dégrade trop la qualité malgré les réglages	Choisir directement un modèle plus petit

Et maintenant, vous compressez quoi en premier ?

La quantification LLM et le pruning ne sont pas des astuces de fin de projet. C’est souvent ce qui décide si un modèle peut vraiment partir en production. La quantification baisse la précision des poids et fait tomber la VRAM. Le pruning va plus loin en retirant des parties du modèle, mais il demande plus de prudence. Mon conseil simple, c’est de mesurer avant, compresser progressivement, puis tester sur vos vrais usages. Pas sur trois prompts propres. Bien fait, vous gardez un modèle utile, plus rapide, moins cher, et déployable sur une infrastructure beaucoup plus raisonnable.

FAQ

• Qu’est-ce que la quantification LLM ?
  La quantification LLM consiste à représenter les poids du modèle avec moins de précision numérique, par exemple en passant de FP16 à 8-bit ou 4-bit. Le modèle garde le même nombre de paramètres, mais il prend beaucoup moins de place en mémoire. C’est souvent la première piste à tester pour réduire les coûts GPU.
• Quelle est la différence entre quantification et pruning ?
  La quantification compresse la façon dont les poids sont stockés. Le pruning supprime des poids, des connexions ou des blocs du modèle. En clair, la quantification rend les nombres plus légers, le pruning retire des morceaux. Les deux peuvent se compléter, mais le pruning est souvent plus risqué à valider.
• Un modèle 4-bit est-il toujours moins bon ?
  Pas forcément. Beaucoup de modèles tiennent très bien en 4-bit avec des méthodes comme AWQ ou GPTQ, surtout pour des usages simples ou bien cadrés. Mais la perte peut apparaître sur le raisonnement, les formats stricts, les sorties longues ou les cas métier complexes. Il faut tester sur vos données, pas seulement sur un benchmark général.
• Pourquoi un LLM 70B demande autant de VRAM ?
  En FP16, chaque poids prend environ 2 octets. Un modèle de 70 milliards de paramètres demande donc autour de 140 GB rien que pour stocker les poids. En pratique, il faut aussi compter le moteur d’inférence, le contexte, le cache KV et la marge de fonctionnement. C’est pour ça que la compression change tout.
• Comment savoir si mon modèle compressé est prêt pour la production ?
  Je regarde quatre choses. La qualité sur les vrais cas d’usage, la VRAM consommée, la latence et le coût par requête. Si le modèle répond vite mais rate les formats attendus ou les cas métier sensibles, il n’est pas prêt. La bonne compression, c’est celle qui baisse les coûts sans casser votre valeur business.

 

 

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’aide les entreprises à industrialiser leurs sujets Data, IA, tracking server-side, Analytics Engineering, automatisation No/Low Code avec n8n, SEO et GEO. J’ai accompagné des équipes chez Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football, Texdecor et d’autres. Mon angle est simple, rendre les systèmes mesurables, fiables et exploitables en production. Si vous voulez cadrer ou déployer un projet IA sans exploser vos coûts, contactez-moi.