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

Pendant plus de deux décennies, l'optimisation des performances de calcul a été une pierre angulaire de mon travail. Nous avons effectué des benchmarks des GPU B200, H200, H100 de NVIDIA et MI300X de AMD pour évaluer leur évolutivité 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 de GPU gère les charges de travail parallèles et intensives en calcul.

Résultats du benchmark Multi-GPU

Débit total vs. 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 la 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 informations sur les performances :

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 à double-GPU, indiquant une utilisation des ressources presque optimale.

Caractéristiques de performance du AMD MI300X : Le AMD MI300X atteint un débit à GPU unique de 18 752 tokens par seconde, proxy 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 moyenne d'inférence vs. nombre de GPU

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

Principales informations sur les performances :

Analyse des performances de latence : Le NVIDIA B200 présente les mesures de latence 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 positionnent pour des applications nécessitant des temps de réponse minimaux, tels que 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 grande réduction de latence se produit lors de la transition des configurations à un seul vers deux-GPU (environ 50 % sur toutes les plateformes). Les configurations avec plus de 4 GPU montrent des améliorations de latence progressivement plus faibles.

Analyse comparative H200 et H100 : Le H200 affiche une latence de 5 à 8 % inférieure à celle du H100 à toutes les échelles, avec une différence absolue diminuant à des nombres de GPU plus élevés (2,81 ms contre 2,86 ms à huit GPU, soit une différence de 0,05 ms). Cette différence de performance marginale, comparée à la différence 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 du AMD MI300X : Le MI300X affiche des valeurs de latence de 37 à 75 % supérieures à celles du H200 dans les configurations testées, ce qui peut être attribué aux différences actuelles de maturité de la pile logicielle entre les implémentations vLLM ROCm et CUDA. À une échelle à 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é la différence de performance par rapport aux plateformes NVIDIA.

Performance vs. prix : Une analyse d'efficacité des coûts

Bien que les métriques de performance brute soient cruciales, la décision ultime pour toute organisation dépend de l'efficacité des coûts. Pour analyser le retour sur investissement (ROI) de chaque plateforme, nous avons cartographié nos résultats de débit par rapport aux 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 puissance de calcul la plus élevée pour le coût le plus faible.

Remarque : Toutes les informations de prix reflètent les tarifs à la demande disponibles sur la plateforme RunPod Cloud au moment du benchmark (septembre 2025) et sont sujettes à modification. Les coûts sont présentés pour une 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 par rapport aux coûts horaires. La formule de calcul est :

• Préparation des données : Pour chaque point de données dans notre tableau de résultats, nous avons récupéré le coût horaire correspondant pour la configuration de 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 à 1x GPU a délivré 23 243 tokens/s à 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, passant de « quel est le plus rapide ? » à « quel est le meilleur investissement pour notre charge de travail ? »

Qu'est-ce que la mise à l'échelle Multi-GPU ?

La mise à l'échelle Multi-GPU fait référence à la capacité d'un système à augmenter ses performances en distribuant une seule tâche importante sur plusieurs GPU. Pour l'inférence LLM, cela peut être réalisé par parallélisme de données, où des copies indépendantes du modèle s'exécutent sur chaque GPU, avec un équilibreur de charge distribuant les requêtes entrantes sur toutes les instances.

Idealement, l'utilisation de deux GPU offrirait le double des performances d'un seul GPU (accélération 2x). Cependant, en réalité, les gains de performance sont limités par les goulots d'étranglement du CPU et du système, le temps que le système hôte passe à gérer plusieurs processus concurrents, les contraintes de bande passante mémoire et la contention des ressources. Notre benchmark mesure l'efficacité avec laquelle chaque plateforme gère ces contraintes au niveau du système, un facteur critique pour construire des serveurs d'inférence IA rentables et haute performance pour des modèles de petite à 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 des interconnexions

Lorsqu'un modèle est réparti sur plusieurs GPU, l'interconnexion, telle que NVLink de NVIDIA ou Infinity Fabric de AMD, devient un goulot d'étranglement critique pour les performances. L'efficacité de la communication inter-GPU impacte directement 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 diminueront. Cet effet est particulièrement prononcé dans les modèles qui ne sont pas assez grands pour saturer complètement la capacité de calcul de chaque GPU.

Maturité de l'écosystème logiciel

Les performances ne sont pas uniquement une fonction du matériel. La pile logicielle, y compris 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 monumental. Nous avons découvert 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 et d'optimisation, ce qui peut conduire à une efficacité de mise à l'échelle supérieure par rapport à des intégrations plus récentes comme ROCm de 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. L'utilisation d'une approche générique « taille unique » peut entraîner des performances trompeusement faibles. La bonne image Docker, 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 débloquer le véritable potentiel du matériel. Cela rend les comparaisons équitables « pomme à pomme » un défi technique majeur.

Découvrez davantage de nos benchmarks et analyses basées sur les données dans la recherche Google.

Ajouter comme source préférée

Méthodologie de benchmark Multi-GPU

Nous avons testé les dernières architectures de GPU haute performance de NVIDIA et AMD pour évaluer leurs capacités de mise à l'échelle. Notre benchmark a mesuré les performances des configurations à un seul et multi-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 pour 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.
• Ensemble de données : Ensemble de données ShareGPT Vicuna (25 000 invites) 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 d'invites a été répartie uniformément sur les instances, qui ont été exécutées simultanément pour simuler un environnement de production équilibré. Cette approche élimine la communication inter-GPU (NVLink/PCIe) en tant que goulot d'étranglement, déplaçant les limiteurs de performance 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 nécessitait des configurations adaptées pour 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 activer le 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'était 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 critiques pour atteindre un débit maximal :

• Variables d'environnement spécifiques à AMD :

• Visibilité des périphériques : ROCR_VISIBLE_DEVICES a été utilisé à la place de l'équivalent de CUDA pour attribuer des instances à des GPU spécifiques.

Phases d'exécution du benchmark

Chaque exécution de benchmark a suivi un protocole d'exécution 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 invites traitées sur le GPU 0
• Objectif : Chargement du modèle, initialisation du cache KV et compilation des noyaux CUDA/ROCm
• Sortie : Rejetée (non incluse dans les mesures)
• Comportement spécifique à la plateforme :
  • NVIDIA (CUDA) : Compilation des noyaux et optimisation des graphes CUDA (~30-60 secondes)
  • AMD (ROCm) : Compilation des noyaux et réglage optionnel TunableOp (varie selon le paramètre PYTORCH_TUNABLEOP_ENABLED)

Phase 2 : Initialisation de la surveillance des GPU

Concurrentement à l'exécution du benchmark, nous avons lancé des processus de surveillance dédiés pour chaque GPU :

• Taux d'échantillonnage : Intervalles de 1 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 post-analyse

Phase 3 : Exécution parallèle du benchmark

Après la fin de l'échauffement, toutes les instances de GPU ont été lancées simultanément :

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

Impact des performances réelles des tests

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

Pour aller plus loin

Découvrez d'autres recherches sur le matériel IA, telles que :

• Top 20 des fabricants de puces IA : NVIDIA et ses concurrents
• Cloud GPU pour l'apprentissage profond : Disponibilité et prix / Performance
• Meilleurs 10 clouds GPU sans serveur et 14 GPU rentables
• Benchmark de concurrence GPU

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}
}

Liens de référence

1.

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

2.

https://docs.vllm.ai/en/latest/

Sedat Dogan

CTO

Suivre

Sedat est un expert en technologies et sécurité de l'information, fort d'une expérience en développement logiciel, collecte de données web et cybersécurité. Sedat : - Possède 20 ans d'expérience en tant que hacker éthique et expert en développement, avec une vaste expertise des langages de programmation et des architectures serveur. - Conseille les dirigeants et membres du conseil d'administration d'entreprises dont les opérations technologiques critiques et à fort trafic sont telles que les infrastructures de paiement. - Allie un sens aigu des affaires à son expertise technique.

Voir le profil complet

Recherche effectuée par

Ekrem Sarı

Chercheur en IA

Suivre

Ekrem est chercheur en IA chez AIMultiple, spécialisé dans l'automatisation intelligente, les GPU, les agents IA et les frameworks RAG.

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