LLM Quantification: BF16 vs FP8 vs INT4
Nous avons effectué des benchmarks de Qwen3-32B à 4 niveaux de précision (BF16, FP8, GPTQ-Int8, GPTQ-Int4) sur un seul NVIDIA H100 80GB GPU. Chaque configuration a été évaluée sur 2 benchmarks (~12,2K questions) couvrant les connaissances et la génération de code, ainsi que sur plus de 2 000 exécutions d'inférence pour mesurer le débit. Int4 est 2,7 fois plus rapide que BF16 tout en perdant moins de 2 points sur MMLU-Pro, mais la génération de code (HumanEval) chute de 8 points.
Résultats du benchmark de quantification
MMLU-Pro teste le raisonnement large sur 14 domaines (~12K questions, 5-shot). Il s'agit de la version plus difficile de MMLU avec des questions à 10 choix au lieu de 4.
HumanEval teste la génération de code (164 problèmes, pass@1). Le modèle écrit des fonctions Python qui s'exécutent contre des tests unitaires. C'est le seul benchmark où la sortie est exécutée, et non simplement notée.
Le débit est le nombre de tokens de sortie par seconde avec une taille de lot de 1.
Taille du modèle est la mémoire GPU consommée uniquement par les poids, mesurée après le chargement.
Répartition de MMLU-Pro par catégorie
L'ingénierie et le droit montrent les plus grandes baisses en Int4. Les mathématiques restent stables sur toutes les précisions.
Capacité mémoire et concurrence
Les outils de surveillance GPU comme nvidia-smi signalent une utilisation presque totale quelle que soit la taille du modèle car vLLM pré-alloue toute la mémoire disponible. La vraie question est de savoir comment cette mémoire se divise entre les poids du modèle et le cache KV, car le cache KV détermine le nombre d'utilisateurs que vous pouvez servir simultanément.
Le nombre maximal d'utilisateurs est le plafond limité par la mémoire avant OOM : capacité totale en tokens divisée par la longueur de contexte par utilisateur. C'est le maximum théorique. En pratique, les frais de gestion réduisent légèrement ce chiffre.
Cela a des implications directes pour les modèles de raisonnement. DeepSeek-R1 et Qwen-QwQ génèrent des milliers de tokens internes de « pensée » (souvent 2K-5K) avant de produire une réponse finale. En BF16, une seule requête de raisonnement pourrait consommer toute la capacité de 17K tokens, bloquant un deuxième utilisateur. En Int4, la capacité de 193K permet d'accueillir plusieurs sessions de raisonnement simultanées.
Principales conclusions
FP8 ne perd aucune précision mesurable
FP8 obtient 69,64 % sur MMLU-Pro contre 70,24 % pour BF16, soit une différence de 0,6 point sur 12 000 questions. Sur HumanEval, FP8 et BF16 obtiennent tous deux le même score de 39,02 %. FP8 vous offre un débit 1,5 fois supérieur et réduit votre taille de modèle de moitié pour un coût de 0,6 point.
GPTQ-Int8 obtient 70,32 % sur MMLU-Pro mais perd 1,8 point sur HumanEval (37,20 %). Si la génération de code est importante, FP8 est le choix plus sûr.
Int4 dégrade davantage la génération de code que les connaissances
MMLU-Pro perd 1,6 point en Int4 (de 70,24 % à 68,66 %). HumanEval perd 8 points (de 39,02 % à 31,10 %). La génération de code nécessite des prédictions de tokens précises où de petites erreurs de poids s'accumulent à travers les corps de fonctions.
Le vrai gain est la concurrence, pas la vitesse
Int4 est 2,7 fois plus rapide que BF16. Mais l'effet plus important concerne la mémoire. BF16 ne laisse que 4,4 Go pour le cache KV, suffisant pour environ 4 utilisateurs simultanés avec un contexte de 4K. Int4 libère 47,3 Go, suffisant pour 47 utilisateurs, soit une augmentation de 12 fois de la capacité de service à partir du même GPU.
Les scores de mathématiques se maintiennent sur toutes les précisions
Les scores de mathématiques bougent à peine : 81,87 % en BF16, 81,87 % en FP8, 81,87 % en Int8, 80,24 % en Int4. L'ingénierie (de 49,64 % à 43,45 %) et le droit (de 43,05 % à 40,60 %) sont plus sensibles.
Coût par token
En utilisant les prix SXM H100 sur RunPod (2,69 $/heure) avec une taille de lot de 1 :
Ces chiffres reflètent la génération en temps réel pour un seul utilisateur. Le traitement par lot réduit encore le coût.
Ajouter comme source préféréeLLM méthodologie du benchmark de quantification
Environnement
- GPU : Unique NVIDIA H100 80GB HBM3 (SXM) via RunPod (2,69 $/h)
- Logiciel : vLLM 0.17.0, lm-evaluation-harness 0.4.11, PyTorch 2.8.0, CUDA 12.8, Python 3.11
- Modèle : Qwen3-32B (post-entraîné/instruction-tuned) de HuggingFace. Aucun fine-tuning appliqué.
Évaluation de la précision
- Toutes les évaluations sont exécutées via
lm-evaluation-harnessavecbatch_size="auto". - Chaque tâche s'exécute dans un sous-processus séparé. Le modèle est chargé à neuf à chaque fois, le GPU est entièrement nettoyé entre les tâches. Cela empêche les OOM dus à la fragmentation de la mémoire.
- HumanEval s'exécute avec
HF_ALLOW_CODE_EVAL=1(exécution de code activée). - Les résultats de MMLU-Pro incluent une répartition par catégorie (biologie, mathématiques, physique, droit, etc.).
- Le mode de réflexion de Qwen3 n'était pas actif pendant les évaluations. lm-evaluation-harness envoie des invites brutes formatées sans appliquer le modèle de chat du modèle (
apply_chat_template=Falsepar défaut), de sorte que le token<think>n'est jamais injecté.
Évaluation des performances
- 5 invites rotatives dans différents domaines (sciences, codage, connaissances générales)
- 10 itérations de warmup (non mesurées), puis 500 itérations mesurées
- Sortie fixe :
max_tokens=256, temperature=0.7, top_p=0.9, batch_size=1 - Métriques : débit (tokens/sec), utilisation de la mémoire GPU (Go)
Configuration vLLM par précision
Toutes les précisions utilisent gpu_memory_utilization=0.90, max_model_len=4096.
Architecture à processus séparés
Chaque benchmark s'exécute en deux processus séparés pour éviter les OOM :
- Étape 1 : Charger le modèle, warmup, benchmark du débit, sauvegarder dans un fichier temporaire, quitter.
- Nettoyage : Tuer force vLLM et les processus Ray, attendre 10 secondes.
- Étape 2 : Charger le modèle à neuf, exécuter chaque tâche d'évaluation dans un sous-processus séparé, fusionner avec les métriques de l'étape 1, sauvegarder le JSON final.
Variables contrôlées
Pour éliminer les facteurs externes, les paramètres suivants ont été fixés pour toutes les exécutions :
Invites de test
Les 5 invites de test :
- « Expliquez la théorie de la relativité en termes simples. » (Science/Abstrait)
- « Écrivez une fonction Python pour trouver la plus longue sous-chaîne palindrome. » (Codage)
- « Quelles sont les principales causes du changement climatique et leurs effets ? » (Raisonnement complexe)
- « Décrivez le processus de la photosynthèse étape par étape. » (Description de processus)
- « Comment un réseau de neurones apprend-il à partir de données ? » (Explication technique)
Vérification des données : télémétrie d'exécution vLLM
Les chiffres de mémoire et de concurrence de cet article ont été dérivés directement des journaux d'initialisation du moteur vLLM lors de l'exécution du benchmark.
Initialisation BF16 :
Initialisation GPTQ-Int4 :
Limitations
Tous les tests utilisent une taille de lot de 1. Dans les scénarios à haut débit, l'écart de performance entre Int4 et BF16 s'élargit car la saturation de la bande passante mémoire devient le goulot d'étranglement dominant.
Les résultats sont spécifiques au H100 SXM. Les anciens GPU (A100, A10) ne prennent pas en charge nativement le FP8. Les GPU grand public (RTX 4090) ont des caractéristiques de bande passante mémoire différentes.
Les modèles GPTQ (JunHowie) sont des quantifications fournies par la communauté. Les versions officielles peuvent utiliser des ensembles de données de calibration ou des paramètres différents, ce qui peut affecter la précision.
Nous avons testé uniquement GPTQ. D'autres méthodes de quantification (AWQ, BitsAndBytes NF4, GGUF, HQQ) pourraient offrir des compromis différents.
Conclusion
Pour Qwen3-32B sur un H100, FP8 est le choix par défaut. Vous obtenez 1,5 fois le débit, la moitié de l'empreinte mémoire et un coût de précision de 0,6 point.
Int4 a du sens lorsque vous avez besoin d'un débit ou d'une concurrence maximale : vitesse 2,7 fois supérieure, concurrence 12 fois supérieure, au prix de 1,6 point sur MMLU-Pro et 8 points sur HumanEval.
Int8 se situe au milieu et n'offre pas d'avantage clair par rapport à FP8 dans cette configuration. Le gain de débit par rapport à FP8 est faible (43,3 contre 37,9 tok/s) et la précision est comparable. FP8 est plus simple car il est officiellement fourni par les auteurs du modèle et ne nécessite pas de point de contrôle quantifié tiers.
Le plus grand impact pratique de la quantification n'est pas la vitesse, c'est la concurrence. BF16 peut servir 4 utilisateurs avec un contexte de 4K sur un seul H100. Int4 peut en servir 47. À 2,69 $/heure, cela ramène le coût par 1M de tokens de 28,73 $ à 10,69 $.
Citer cette recherche
Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.
@misc{sar2026,
author = {Sarı, Ekrem and Ermut, Sıla},
title = {{LLM Quantification: BF16 vs FP8 vs INT4}},
year = {2026},
month = mar,
howpublished = {\url{https://aimultiple.com/llm-quantization}},
note = {AIMultiple. Consulté le 17 Mars 2026}
}
Soyez le premier à commenter
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.