RunPod passe en revue 4 méthodes de quantification : de FP16 à INT4, la mémoire est divisée par 4

RunPod, fournisseur cloud de GPU, a publié un panorama de quatre façons de compresser les modèles avant leur déploiement : la quantification post-training (PTQ), le quantization-aware training (QAT), la précision mixte et la quantification dynamique. L'article ne contient aucun benchmark original : il s'agit d'une comparaison de référence des compromis. Mais le sujet influe directement sur la facture d'inférence. Les poids d'un modèle de 70 milliards de paramètres occupent environ 140 Go en FP16, environ 70 Go en INT8 et environ 35 Go en INT4. La différence entre « il faut deux accélérateurs de 80 Go » et « un seul suffit » tient à ces chiffres.

Quatre façons de perdre un peu de précision

Le PTQ prend un modèle déjà entraîné, lui fait traiter un petit jeu de données de calibration, puis convertit les poids, et parfois les activations, en INT8 ou en INT4. Aucun réentraînement n'est nécessaire : le processus prend quelques minutes ou quelques heures. C'est ainsi que fonctionnent les populaires GPTQ et AWQ. Le prix à payer : une baisse de qualité, surtout en 4 bits et sur les petits modèles.

Le QAT emprunte une autre voie. La quantification est émulée pendant l'entraînement ou le fine-tuning, et le modèle apprend à fonctionner avec des poids grossiers. Le résultat reste généralement plus proche de la précision d'origine, mais il faut des données, du temps et des heures de GPU, ce qui représente un poste de dépense sensible pour un grand modèle.

La précision mixte conserve la majorité des opérations en FP16 ou en BF16, et laisse les points sensibles, comme les accumulateurs, la normalisation et le softmax, dans une précision plus élevée. La quantification dynamique stocke les poids en entiers et calcule les plages des activations à la volée, pendant l'exécution. C'est la méthode la plus simple à brancher sur un modèle existant, et elle convient bien à l'inférence sur CPU, mais le surcoût du calcul des plages absorbe une partie du gain.

Repères par précision numérique

La vitesse et la mémoire s'améliorent à mesure que la précision baisse, mais pas de façon uniforme. Quelques valeurs de référence aident à estimer les besoins :

• FP16/BF16 : 2 octets par paramètre, précision de base ; un modèle 70B nécessite environ 140 Go pour les seuls poids.
• INT8 : 1 octet par paramètre, mémoire réduite de moitié ; la perte de qualité reste généralement faible sur la plupart des tâches.
• INT4 : 0,5 octet par paramètre, environ 35 Go pour un 70B ; risque notable de dégradation sur le raisonnement et le code.
• Surcoûts : le KV-cache et les activations ne sont pas inclus dans ces chiffres, et ils augmentent avec la longueur du contexte et le nombre de requêtes parallèles.
• Support matériel : seul ce que les tensor cores savent calculer nativement apporte une accélération. Sur H100, il s'agit du FP8 et de l'INT8 ; pour l'INT4, des kernels spécialisés sont souvent nécessaires.

Où est le piège

Le principal piège : compresser les poids ne revient pas à accélérer. L'inférence des grands modèles est le plus souvent limitée par la bande passante mémoire, si bien que des poids plus légers accélèrent effectivement la génération de tokens. Mais si le runtime déquantifie en permanence sans kernels optimisés, le gain disparaît. Second problème : les métriques moyennes comme la perplexité masquent les défaillances sur des tâches précises, comme l'arithmétique, le contexte long, les langues rares ou la génération de code.

De là découle une marche à suivre pratique. Pour un premier essai, prenez du PTQ en INT8, ou dans le format 8 bits pris en charge par votre matériel, et comparez-le au FP16 sur vos propres données, pas sur des tests publics. Si la qualité tient, essayez l'INT4 et regardez les pires cas plutôt que la moyenne.

Si la baisse de qualité est critique et que vous disposez d'un budget de fine-tuning, passez au QAT. La quantification dynamique convient lorsqu'il n'y a pas de GPU du tout ou qu'il faut vérifier rapidement une hypothèse. Calculez séparément le KV-cache : un modèle INT8 de 70 Go sur une carte de 80 Go ne laisse qu'environ 10 Go pour le contexte et les requêtes parallèles, et c'est alors que l'INT4 l'emporte, non par la vitesse, mais par la mémoire libre.