Benchmark multi-GPU: B200 vs H200 vs H100 vs MI300X

Depuis plus de deux décennies, l’optimisation des performances de calcul est une pierre angulaire de mon travail. Nous avons évalué les GPU NVIDIA B200, H200, H100 et le MI300X d’AMD afin d’évaluer leur capacité de mise à l’échelle pour l’inférence de grands modèles de langage (LLM). En utilisant le framework vLLM avec le modèle meta-llama/Llama-3.1-8B-Instruct, nous avons exécuté des tests sur 1, 2, 4 et 8 GPUs.

Nous avons analysé le débit et l’efficacité de mise à l’échelle pour illustrer comment chaque architecture GPU gère les charges de travail parallélisées et intensives en calcul.

Résultats du benchmark multi-GPU

Débit total en fonction du nombre de GPU

• Débit total (tokens/seconde) : Cette métrique représente la puissance de traitement brute de l’ensemble du système multi-GPU. Elle mesure le nombre total de tokens d’entrée et de sortie traités par seconde, ce qui en fait l’indicateur le plus important de performance maximale dans une charge de travail saturée et hors ligne.

Pour comprendre comment nous avons calculé le score, consultez notre méthodologie de benchmark multi-GPU.

Principaux enseignements en matière de performance :

Analyse des performances : Le NVIDIA H200 offre le débit le plus élevé dans toutes les configurations testées, avec des améliorations de performance de 9 à 10 % par rapport au H100. Le système atteint une efficacité de mise à l’échelle de 99,8 % avec des configurations à deux GPU, ce qui indique une utilisation quasi optimale des ressources.

AMD MI300X : caractéristiques de performance : Le AMD MI300X atteint un débit en mono-GPU de 18 752 tokens par seconde, soit environ 74 % des performances du H200. Le système maintient des efficacités de mise à l’échelle de 95 % et 81 % pour les configurations à deux GPU et à quatre GPU, respectivement.

Latence d’inférence moyenne en fonction du nombre de GPU

• Latence d’inférence moyenne (millisecondes) : Cette métrique mesure le temps moyen nécessaire pour traiter une seule requête du début à la fin. Une latence plus faible se traduit par une expérience plus rapide et plus réactive pour les utilisateurs finaux.

Principaux enseignements en matière de performance :

Analyse des performances de latence : Le NVIDIA B200 présente les latences mesurées les plus faibles dans toutes les configurations évaluées, atteignant 2,40 ms avec des implémentations à huit GPU. Ces caractéristiques de performance le destinent aux applications exigeant des temps de réponse minimaux, comme les systèmes interactifs en temps réel où une latence inférieure à 3 ms est une exigence de conception.

Observations sur l’efficacité de mise à l’échelle : L’analyse révèle des rendements décroissants dans la réduction de la latence à mesure que le nombre de GPU augmente sur toutes les plateformes. La plus forte réduction de latence se produit lors du passage de configurations mono-GPU à bi-GPU (environ 50 % selon les plateformes). Les configurations avec plus de 4 GPUs présentent des améliorations de latence progressivement plus faibles.

Analyse comparative H200 et H100 : Le H200 présente une latence inférieure de 5 à 8 % par rapport au H100 à toutes les échelles, la différence absolue diminuant à des nombres de GPU plus élevés (2,81 ms contre 2,86 ms avec huit GPUs, soit une différence de 0,05 ms). Cet écart de performance marginal, comparé à la différence de prix de 41 %, suggère que le H100 peut offrir des caractéristiques coût-performances plus favorables pour les déploiements sensibles à la latence.

AMD MI300X : caractéristiques de latence : Le MI300X présente des valeurs de latence supérieures de 37 à 75 % à celles du H200 dans les configurations testées, ce qui peut être attribué aux différences actuelles de maturité des piles logicielles entre les implémentations vLLM ROCm et CUDA. À l’échelle de huit GPU, le MI300X atteint une latence de 4,20 ms, qui reste dans des paramètres acceptables pour de nombreuses applications de production malgré l’écart de performance par rapport aux plateformes NVIDIA.

Performance par rapport au prix : une analyse coût-efficacité

Si les indicateurs de performance bruts sont cruciaux, la décision finale pour toute organisation repose sur la rentabilité. Pour analyser le retour sur investissement (ROI) de chaque plateforme, nous avons rapproché nos résultats de débit des tarifs horaires à la demande de RunPod au moment des tests. Cela nous permet de calculer un score de « performance par dollar », révélant quelle configuration offre le plus de puissance de calcul au coût le plus bas.

Remarque : toutes les informations tarifaires reflètent les tarifs à la demande disponibles sur la plateforme RunPod Cloud au moment du benchmark (septembre 2025) et sont susceptibles d’être modifiées. Les coûts sont présentés à des fins d’analyse comparative et n’incluent pas les frais de stockage ou de réseau.

Comment nous avons calculé le débit par dollar

Pour générer ce graphique, nous avons traité nos données de performance brutes en regard des coûts horaires. La formule de calcul est la suivante :

• Préparation des données : Pour chaque point de données de notre tableau de résultats, nous avons récupéré le coût horaire correspondant pour la configuration GPU spécifique (par exemple, 4x H100 coûte $10,76).
• Calcul : Nous avons ensuite appliqué la formule pour calculer la valeur throughput_per_dollar. Par exemple, le H100 avec 1x GPU a fourni 23 243 tokens/s pour un coût de $2,69/h, ce qui donne un score de 8 642 tokens/s par dollar.

Ce score d’efficacité fournit un outil d’aide à la décision, faisant passer la conversation de « quel est le plus rapide ? » à « quel est l’investissement le plus intelligent pour notre charge de travail ? »

Qu’est-ce que la mise à l’échelle multi-GPU ?

La mise à l’échelle multi-GPU désigne la capacité d’un système à augmenter ses performances en répartissant une seule grande tâche sur plusieurs GPUs. Pour l’inférence de LLM, cela peut être réalisé grâce au parallélisme de données, dans lequel des copies indépendantes du modèle s’exécutent sur chaque GPU, un équilibreur de charge répartissant les requêtes entrantes entre toutes les instances.

Idéalement, l’utilisation de deux GPUs offrirait le double des performances d’un seul GPU (accélération de 2x). Cependant, en réalité, les gains de performance sont limités par les CPU et les goulots d’étranglement système, le temps que le système hôte consacre à la gestion de plusieurs processus simultanés, les contraintes de bande passante mémoire et les conflits de ressources. Notre benchmark mesure avec quelle efficacité chaque plateforme gère ces contraintes au niveau du système, un facteur essentiel pour construire des serveurs d’inférence IA rentables et performants pour les modèles de petite et moyenne taille.

Quels sont les défis des tests de mise à l’échelle multi-GPU ?

Le benchmark des systèmes multi-GPU pose des défis uniques qui peuvent affecter considérablement les performances.

Surcharge de communication et goulots d’étranglement de l’interconnexion

Lorsqu’un modèle est réparti sur plusieurs GPUs, l’interconnexion, comme le NVIDIA NVLink ou l’AMD Infinity Fabric, devient un goulot d’étranglement critique pour les performances. L’efficacité de la communication inter-GPU a un impact direct sur la mise à l’échelle. Si le temps passé à attendre les données d’un autre GPU dépasse le temps gagné en parallélisant le calcul, les gains de performance diminuent. Cet effet est particulièrement prononcé pour les modèles qui ne sont pas assez grands pour saturer pleinement la capacité de calcul de chaque GPU.

Maturité de l’écosystème logiciel

La performance n’est pas uniquement fonction du matériel. La pile logicielle, notamment les pilotes, les bibliothèques de communication (comme NCCL pour NVIDIA et RCCL pour AMD), et le moteur d’inférence (vLLM), joue un rôle considérable. Nous avons constaté que les performances d’une plateforme sont profondément liées à la maturité de son support logiciel. Un écosystème établi comme CUDA de NVIDIA bénéficie souvent d’années de réglage fin et d’optimisation, ce qui peut conduire à une efficacité de mise à l’échelle supérieure à celle d’intégrations plus récentes comme ROCm d’AMD, même sur du matériel puissant.

Optimisations spécifiques à la plateforme

Comme nos tests l’ont révélé, atteindre des performances optimales nécessite souvent des configurations spécifiques à la plateforme. Une approche générique « taille unique » peut conduire à des performances trompeusement faibles. L’image Docker correcte, les variables d’environnement (par exemple, l’activation de noyaux AMD personnalisés) et même les types de données du modèle (par exemple, bfloat16 pour Blackwell) sont essentiels pour libérer le véritable potentiel du matériel. Cela fait des comparaisons équitables « de pomme à pomme » un défi technique important.

Méthodologie de benchmark multi-GPU

Nous avons testé les dernières architectures GPU hautes performances de NVIDIA et d’AMD afin d’évaluer leurs capacités de mise à l’échelle. Notre benchmark a mesuré les performances des configurations à un et plusieurs GPU (1x, 2x, 4x, 8x) en utilisant le modèle standard meta-llama/Llama-3.1-8B-Instruct¹ et le moteur d’inférence vLLM².

Environnement et processus de test

• Plateforme : Tous les benchmarks ont été exécutés sur RunPod Cloud afin de garantir un accès matériel cohérent.
• Moteur d’inférence : vLLM (outil vllm bench throughput) a été utilisé comme moteur standardisé.
• Modèle : meta-llama/Llama-3.1-8B-Instruct.
• Dataset : le dataset ShareGPT Vicuna (25 000 prompts) pour simuler une charge de travail conversationnelle.
• Stratégie : Parallélisme de données ; chaque test multi-GPU a exécuté une instance vLLM indépendante sur chaque GPU. La charge totale de prompts a été répartie uniformément entre les instances, qui ont été exécutées simultanément pour simuler un environnement de production équilibré en charge. Cette approche élimine la communication inter-GPU (NVLink/PCIe) en tant que goulot d’étranglement, déplaçant les facteurs limitants vers le système hôte (CPU, RAM).
• Automatisation : Des scripts Bash personnalisés ont été utilisés pour automatiser la configuration de l’environnement, l’exécution des tests, la surveillance des ressources (nvidia-smi, rocm-smi) et l’agrégation des résultats.

Configurations spécifiques à la plateforme

Atteindre des performances optimales a nécessité des configurations adaptées à chaque architecture.

Plateformes NVIDIA (H100, H200, B200)

• Image de base : runpod/pytorch:2.8.0-py3.11-cuda12.8.1.
• Installation de vLLM :
  • H100/H200 (Hopper) : Installation standard via pip install vllm.
  • B200 (Blackwell) : vLLM a été compilé à partir du code source (pip install -e .) pour permettre un support natif de la nouvelle architecture, résolvant les erreurs « no kernel image ».
• Paramètres clés :

• Variable d’environnement critique :

Plateforme AMD (MI300X)

• Image de base : rocm/vllm:rocm6.4.1_vllm_0.10.1_20250909
• Installation de vLLM : Aucune installation n’a été nécessaire, car la version optimisée était incluse dans l’image.
• Paramètres clés et optimisations : Des réglages approfondis ont identifié les paramètres non par défaut suivants comme essentiels pour atteindre un débit maximal :

• Variables d’environnement spécifiques à AMD :

• Visibilité des périphériques : ROCR_VISIBLE_DEVICES a été utilisé au lieu de l’équivalent CUDA pour attribuer des instances à des GPUs spécifiques.

Phases d’exécution du benchmark

Chaque exécution du benchmark a suivi un protocole d’exécution en trois phases afin de garantir des résultats précis et reproductibles :

Phase 1 : Warmup

Avant chaque test de configuration multi-GPU, nous avons effectué une phase de warmup dédiée pour éliminer les effets de démarrage à froid :

• Durée : 100 prompts traités sur le GPU 0
• Objectif : Chargement du modèle, initialisation du cache KV et compilation des noyaux CUDA/ROCm
• Sortie : Ignorée (non incluse dans les mesures)
• Comportement spécifique à la plateforme :
  • NVIDIA (CUDA) : Compilation des noyaux et optimisation des graphes CUDA (environ 30-60 secondes)
  • AMD (ROCm) : Compilation des noyaux et réglage facultatif TunableOp (varie selon le paramètre PYTORCH_TUNABLEOP_ENABLED)

Phase 2 : Initialisation de la surveillance des GPU

Parallèlement à l’exécution du benchmark, nous avons lancé des processus de surveillance dédiés pour chaque GPU :

• Fréquence d’échantillonnage : intervalles d’une seconde
• Métriques collectées : utilisation du GPU, utilisation de la mémoire, température, consommation électrique
• Outils : nvidia-smi (NVIDIA) ou rocm-smi (AMD)
• Sortie : journaux CSV pour l’analyse ultérieure

Phase 3 : Exécution parallèle du benchmark

Après la fin du warmup, toutes les instances GPU ont été lancées simultanément :

• Chaque GPU a traité une part égale des 25 000 prompts totaux
• Toutes les instances ont démarré dans la même seconde pour simuler l’équilibrage de charge en production
• Débit total mesuré comme la somme des sorties de tous les GPU
• Temps d’exécution mesuré du démarrage de la première instance à la fin de la dernière instance

Ne manquez pas nos benchmarks et analyses basées sur les données. Le bouton ouvre Google ; sélectionner AIMultiple confirme que vous souhaitez voir AIMultiple plus souvent dans les résultats de recherche Google.

Ajouter comme source préférée

Impact des tests sur les performances en conditions réelles

Nos tests ont révélé que de petites erreurs de configuration peuvent conduire à des résultats de performance significatifs et trompeurs. Le tableau suivant illustre l’impact des mauvaises configurations spécifiques à la plateforme :

Lectures complémentaires

Explorez d’autres recherches sur le matériel IA, telles que :

• Top 30 fournisseurs Cloud de GPU et leurs GPUs
• Benchmark de concurrence GPU
• Top 25+ fabricants de puces IA : NVIDIA et ses concurrents

Citez ce benchmark

Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.

@misc{dogan2026,
  author = {Dogan, Sedat and Sarı, Ekrem},
  title  = {{Benchmark multi-GPU: B200 vs H200 vs H100 vs MI300X}},
  year   = {2026},
  month  = sep,
  howpublished    = {\url{https://aimultiple.com/multi-gpu}},
  note   = {AIMultiple. Consulté le 21 septembre 2026}
}

Journal des modifications

2 mises à jour

2025

1. 8 oct

   Mise à jour du jeu de données dans la section des résultats du benchmark multi-GPU.

2. 6 oct

   Suppression de la métrique « Requêtes par seconde » de la section « Débit total vs. nombre de GPU ».

Liens de référence

1.

meta-llama/Llama-3.1-8B-Instruct · Hugging Face

2.

vLLM easy, fast, and cheap LLM serving for everyone

Sedat Dogan

CTO

Suivre

Sedat est un leader en technologie et en sécurité de l’information avec 20 ans d’expérience en développement logiciel, infrastructure réseau et cybersécurité. Sedat :
- A 20 ans d’expérience en tant que hacker white-hat et gourou du développement, avec une expertise approfondie des langages de programmation et des architectures de serveurs.
- Est conseiller d’administration auprès d’un VC qui investit dans des entreprises technologiques en phase de démarrage et chez Ödeal, une plateforme de paiement numérique régionale servant 125 000 commerçants.
- A dirigé l’infrastructure technologique et la cybersécurité de sept élections nationales, et a été reconnu au Hall of Fame de la cybersécurité par des leaders technologiques mondiaux dont Twitter.

Voir le profil complet

Recherche effectuée par

Ekrem Sarı

Chercheur en IA

Suivre

Ekrem est chercheur en IA et scientifique des données chez AIMultiple. Il conçoit et exécute des benchmarks pratiques pour les systèmes d'IA et de LLM.

Voir le profil complet

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.

Nom

Adresse email

Commentaire

0/450

Publier un commentaire