Quantification LLM : BF16 vs FP8 vs INT4
Nous avons évalué les performances de Qwen3-32B à quatre niveaux de précision (BF16, FP8, GPTQ-Int8 et GPTQ-Int4) sur un seul GPU H100 de 80 Go (NVIDIA). Chaque configuration a été évaluée sur deux benchmarks (environ 12 200 questions) couvrant la génération de connaissances et de code, ainsi que sur plus de 2 000 inférences pour mesurer le débit. Le niveau Int4 est 2,7 fois plus rapide que le niveau BF16 tout en perdant moins de 2 points sur MMLU-Pro, mais la génération de code (HumanEval) perd 8 points.
Résultats de référence de la quantification
MMLU-Pro évalue le raisonnement logique dans 14 domaines (environ 12 000 questions, 5 tentatives). 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, réussite au test 1). Le modèle génère des fonctions Python qui sont exécutées par des tests unitaires. Il s'agit du seul test où le résultat est exécuté, et non simplement évalué.
Le débit correspond au nombre de jetons produits par seconde pour une taille de lot de 1.
La taille du modèle correspond à la mémoire GPU consommée uniquement par les poids, mesurée après chargement.
Répartition de MMLU-Pro par catégorie
Les domaines de l'ingénierie et du droit enregistrent les baisses les plus importantes à Int4. Les mathématiques restent stables quelle que soit la précision.
capacité de mémoire et concurrence
Les outils de surveillance du GPU, comme nvidia-smi, indiquent une utilisation quasi-intégrale quelle que soit la taille du modèle, car vLLM pré-alloue toute la mémoire disponible. La véritable question est de savoir comment cette mémoire est répartie entre les poids du modèle et le cache KV, car ce dernier détermine le nombre d'utilisateurs pouvant être servis simultanément.
Le nombre maximal d'utilisateurs correspond à la limite de mémoire avant la saturation : capacité totale des jetons divisée par la longueur du contexte par utilisateur. Il s'agit du maximum théorique. En pratique, la surcharge liée à l'ordonnancement le réduit légèrement.
Cela a des implications directes pour les modèles de raisonnement. DeepSeek-R1 et Qwen-QwQ génèrent des milliers de jetons de « pensée » internes (souvent entre 2 000 et 5 000) avant de produire une réponse finale. Sur BF16, une seule requête de raisonnement pouvait consommer la totalité de la capacité de 17 000 jetons, bloquant ainsi un deuxième utilisateur. Sur Int4, la capacité de 193 000 permet plusieurs sessions de raisonnement simultanées.
Principales conclusions
FP8 ne perd aucune précision mesurable
FP8 obtient un score de 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 un score identique de 39,02 %. FP8 offre un débit 1,5 fois supérieur et réduit de moitié la taille du modèle pour un surcoût de 0,6 point.
GPTQ-Int8 obtient un score de 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 le plus sûr.
Int4 dégrade davantage la génération de code que la connaissance
MMLU-Pro perd 1,6 point à Int4 (de 70,24 % à 68,66 %). HumanEval perd 8 points (de 39,02 % à 31,10 %). La génération de code exige des prédictions de jetons précises, car de petites erreurs de pondération s'accumulent dans les corps de fonctions.
Le véritable avantage réside dans la concurrence, et non dans la vitesse.
Int4 est 2,7 fois plus rapide que BF16. Mais son principal avantage réside dans la mémoire. BF16 ne réserve que 4,4 Go au cache KV, soit suffisamment pour environ 4 utilisateurs simultanés en contexte 4K. Int4 libère 47,3 Go, soit assez pour 47 utilisateurs, ce qui représente une multiplication par 12 de la capacité de traitement avec le même GPU.
Les résultats en mathématiques restent constants quelle que soit la précision.
Les scores en mathématiques bougent à peine : 81,87 % à BF16, 81,87 % à FP8, 81,87 % à Int8, 80,24 % à Int4. L'ingénierie (de 49,64 % à 43,45 %) et le droit (de 43,05 % à 40,60 %) sont plus sensibles.
Coût par jeton
Utilisation du tarif H100 SXM sur RunPod (2,69 $/heure) pour une taille de lot de 1 :
Ces chiffres correspondent à une génération en temps réel pour un seul utilisateur. Le traitement par lots permet de réduire encore davantage les coûts.
méthodologie de référence de quantification LLM
Environnement
- GPU : Unique NVIDIA H100 80 Go HBM3 (SXM) via RunPod (2,69 $/h)
- Logiciels : 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înement/réglage des instructions) de HuggingFace. Aucun réglage fin n'a été 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 distinct . Le modèle est rechargé à chaque fois et le GPU est entièrement nettoyé entre chaque tâche. Cela évite les erreurs de mémoire insuffisante dues à 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 comprennent une ventilation par catégorie (biologie, mathématiques, physique, droit, etc.).
- Le mode de réflexion de Qwen3 n'était pas actif lors des évaluations. lm-evaluation-harness envoie des invites formatées brutes sans appliquer le modèle de chat (
apply_chat_template=Falsepar défaut), de sorte que le jeton<think>n'est jamais injecté.
Évaluation des performances
- 5 questions à choix multiples, réparties dans différents domaines (sciences, programmation, culture générale).
- 10 itérations d'échauffement (non mesurées), puis 500 itérations mesurées
- Sortie corrigée :
max_tokens=256, temperature=0.7, top_p=0.9, batch_size=1 - Métriques : débit (jetons/s), 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 divisés
Chaque test de performance s'exécute en deux processus distincts pour éviter les erreurs de mémoire insuffisante :
- Étape 1 : Charger le modèle, préchauffer, évaluer le débit, enregistrer dans un fichier temporaire, quitter.
- Nettoyage : Forcer l’arrêt des processus vLLM et Ray, attendre 10 secondes.
- Étape 2 : Charger le modèle à nouveau, exécuter chaque tâche d’évaluation dans un sous-processus séparé, fusionner avec les métriques de l’étape 1, enregistrer le JSON final.
Variables contrôlées
Afin d'éliminer les facteurs externes, les paramètres suivants ont été fixés pour toutes les exécutions :
invites de test
Les 5 questions du test :
- «Expliquez la théorie de la relativité en termes simples.» (Science/Résumé)
- « Écrivez une fonction Python pour trouver la plus longue sous-chaîne palindromique. » (Programmation)
- « Quelles sont les principales causes du changement climatique et leurs effets ? » (Raisonnement complexe)
- « Décrivez le processus de photosynthèse étape par étape. » (Description du processus)
- « Comment un réseau neuronal apprend-il à partir des données ? » (Explication technique)
Vérification des données : télémétrie d’exécution vLLM
Les chiffres relatifs à la mémoire et à la concurrence présentés dans cet article proviennent directement des journaux d'initialisation du moteur vLLM lors de l'exécution des tests de performance.
Initialisation BF16 :
Initialisation GPTQ-Int4 :
Limites
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 principal goulot d'étranglement.
Ces résultats concernent spécifiquement le H100 SXM. Les GPU plus anciens (A100, A10) ne prennent pas en charge nativement le FP8. Les GPU grand public (RTX 4090) présentent 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 jeux de données ou des paramètres d'étalonnage différents, ce qui peut affecter la précision.
Nous n'avons testé que GPTQ. D'autres méthodes de quantification (AWQ, BitsAndBytes NF4, GGUF, HQQ) pourraient présenter des compromis différents.
Conclusion
Pour Qwen3-32B sur un H100, le format FP8 est le choix par défaut. Vous obtenez un débit 1,5 fois supérieur, une empreinte mémoire deux fois moindre et une perte de précision de 0,6 point.
Int4 est judicieux lorsque vous avez besoin d'un débit ou d'une concurrence maximale : vitesse 2,7x, concurrence 12x, au prix de 1,6 point sur MMLU-Pro et de 8 points sur HumanEval.
Dans cette configuration, Int8 se situe entre les deux et n'offre pas d'avantage significatif par rapport à FP8. Le gain de débit est faible (43,3 contre 37,9 tok/s) et la précision est comparable. FP8 est plus simple car il est fourni officiellement par les auteurs du modèle et ne nécessite pas de point de contrôle quantifié tiers.
L'impact pratique le plus important de la quantification n'est pas la vitesse, mais la concurrence. BF16 peut gérer 4 utilisateurs avec un contexte de 4K sur un seul H100. Int4 peut en gérer 47. À 2,69 $/heure, le coût par million de jetons passe ainsi de 28,73 $ à 10,69 $.
Soyez le premier à commenter
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires.