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 NVIDIA B200, H200, H100 et AMD MI300X pour mesurer leur capacité de mise à l’échelle pour l’inférence de Large Language Model (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 GPU.

Nous avons analysé le débit et l’efficacité de mise à l’échelle pour illustrer comment chaque architecture GPU gère des 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 le principal indicateur de performance maximale sous 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.

Principales observations 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 performances de 9-10 % par rapport au H100. Le système atteint une efficacité de mise à l’échelle de 99,8 % avec les configurations à deux GPU, ce qui indique une utilisation des ressources quasi optimale.

Caractéristiques de performance de l’AMD MI300X : L’AMD MI300X atteint un débit 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 % respectivement pour les configurations à deux GPU et à quatre GPU.

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 requête complè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.

Principales observations de performance :

Analyse des performances de latence : Le NVIDIA B200 présente les mesures de latence les plus faibles parmi toutes les configurations évaluées, atteignant 2.40ms 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 à 3ms 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 baisse de latence se produit lors du passage d’une configuration à un seul GPU à une configuration à deux GPU (environ 50 % selon les plateformes). Les configurations à plus de 4 GPU affichent des améliorations de latence progressivement plus faibles.

Analyse comparative du H200 et du H100 : Le H200 affiche une latence inférieure de 5-8 % par rapport au H100 à toutes les échelles, la différence absolue diminuant à mesure que le nombre de GPU augmente (2.81ms contre 2.86ms à huit GPU, soit une différence de 0.05ms). Ce différentiel de performance marginal, comparé à l’écart de prix de 41 %, suggère que le H100 peut offrir des caractéristiques coût-performance plus favorables pour les déploiements sensibles à la latence.

Caractéristiques de latence de l’AMD MI300X : Le MI300X affiche des latences 37-75 % supérieures à 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.20ms, qui reste dans des paramètres acceptables pour de nombreuses applications de production malgré le différentiel de performance par rapport aux plateformes NVIDIA.

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

Bien que les métriques de performance brutes soient cruciales, la décision finale d’une organisation repose sur l’efficacité des coûts. Pour analyser le retour sur investissement (ROI) de chaque plateforme, nous avons mis en correspondance nos résultats de débit avec les 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 la plus grande puissance de calcul pour le coût le plus faible.

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 de changer. Les coûts sont présentés à des fins d’analyse comparative et n’incluent pas les frais de stockage ni 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 avec les 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 à 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 en configuration 1x GPU a fourni 23 243 tokens/s pour un coût de $2,69/heure, ce qui donne un score de 8 642 tokens/s par dollar.

Ce score d’efficacité constitue un outil d’aide à la décision, faisant passer la conversation de « quel est le plus rapide ? » à « quel est l’investissement le plus judicieux 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 grande tâche unique sur plusieurs GPU. Pour l’inférence de LLM, cela peut être réalisé grâce au parallélisme de données, où 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 GPU 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 goulets d’étranglement du CPU et du système, par le temps que le système hôte consacre à la gestion de plusieurs processus simultanés, par les contraintes de bande passante mémoire et par les conflits de ressources. Notre benchmark mesure l’efficacité avec laquelle chaque plateforme gère ces contraintes au niveau du système, un facteur essentiel pour construire des serveurs d’inférence d’IA performants et rentables pour les modèles de petite et moyenne taille.

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

L’évaluation comparative des systèmes multi-GPU pose des défis uniques qui peuvent affecter considérablement les performances.

Surcoût de communication et goulets d’étranglement des interconnexions

Lorsqu’un modèle est réparti sur plusieurs GPU, l’interconnexion, comme le NVLink de NVIDIA ou Infinity Fabric d’AMD, devient un goulot d’étranglement critique. L’efficacité de la communication inter-GPU a un impact direct sur la mise à l’échelle. Si le temps passé à attendre des 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

Les performances ne dépendent pas uniquement 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 étroitement liées à la maturité de son support logiciel. Un écosystème établi comme CUDA de NVIDIA bénéficie souvent d’années de fine-tuning et d’optimisation, ce qui peut conduire à une efficacité de mise à l’échelle supérieure par rapport aux 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é, l’obtention de performances optimales nécessite souvent des configurations spécifiques à la plateforme. Utiliser 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 kernels 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 rend les comparaisons équitables « de pomme à pomme » un défi technique important.

Méthodologie du benchmark multi-GPU

Nous avons testé les dernières architectures GPU haute performance de NVIDIA et d’AMD pour évaluer leurs capacités de mise à l’échelle. Notre benchmark a mesuré les performances des configurations à un seul 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 de test et processus

• Plateforme : Tous les benchmarks ont été exécutés sur RunPod Cloud pour garantir un accès cohérent au matériel.
• Moteur d’inférence : vLLM (l’outil vllm bench throughput) a été utilisé comme moteur standardisé.
• Modèle : meta-llama/Llama-3.1-8B-Instruct.
• Dataset : dataset ShareGPT Vicuna (25 000 prompts) pour simuler une charge de travail conversationnelle.
• Stratégie : parallélisme de données ; chaque test multi-GPU exécutait 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) comme 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

L’obtention de 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 des sources (pip install -e .) pour permettre la prise en charge native 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 : un réglage approfondi a 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 assigner les instances à des GPU spécifiques.

Phases d’exécution du benchmark

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

Phase 1 : échauffement

Avant chaque test de configuration multi-GPU, nous avons effectué une phase d’échauffement 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 kernels CUDA/ROCm
• Sortie : ignorée (non incluse dans les mesures)
• Comportement spécifique à la plateforme :
  • NVIDIA (CUDA) : compilation des kernels et optimisation du graphe CUDA (~30-60 secondes)
  • AMD (ROCm) : compilation des kernels et réglage optionnel TunableOp (varie selon le paramètre PYTORCH_TUNABLEOP_ENABLED)

Phase 2 : initialisation de la surveillance du 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 d’énergie
• 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 de l’échauffement, toutes les instances GPU ont été lancées simultanément :

• Chaque GPU a traité une part égale des 25 000 prompts au total
• Toutes les instances ont démarré dans la même seconde pour simuler l’équilibrage de charge en production
• Le débit total est mesuré comme la somme des sorties de tous les GPU
• Le temps d’exécution est 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 performances en conditions réelles à partir des tests

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

Pour aller plus loin

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

• Top 30 des fournisseurs Cloud GPU et leurs GPU
• 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  = jun,
  howpublished    = {\url{https://aimultiple.com/multi-gpu}},
  note   = {AIMultiple. Consulté le 30 juin 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