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

Depuis plus de vingt ans, l'optimisation des performances de calcul est au cœur de mon travail. Nous avons comparé les performances des GPU B200, H200 et H100 (référence NVIDIA) et MI300X (référence AMD) afin d'évaluer leur capacité à gérer l'inférence de modèles de langage complexes (LLM). À l'aide du framework vLLM et du modèle meta-llama/Llama-3.1-8B-Instruct, nous avons effectué des tests sur des configurations à 1, 2, 4 et 8 GPU.

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

Résultats des tests de performance multi-GPU

Débit total en fonction du nombre de GPU

• Débit total (jetons/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 jetons d’entrée et de sortie traités par seconde, ce qui en fait l’indicateur le plus important des performances maximales sous une charge de travail hors ligne saturée.

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

Principaux indicateurs de performance :

Analyse des performances : Le H200 (référence NVIDIA) offre le débit le plus élevé sur toutes les configurations testées, avec des performances améliorées 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 du MI300X (réf. 991259_1693) : Le MI300X (réf. 991259_1693) atteint un débit mono-GPU de 18 752 jetons par seconde, soit environ 74 % des performances du H200. Le système conserve des gains d’efficacité de 95 % et 81 % pour les configurations à deux 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 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.

Principaux indicateurs de performance :

Analyse des performances de latence : Le B200 (référence NVIDIA) présente les latences les plus faibles parmi toutes les configurations évaluées, atteignant 2,40 ms avec une architecture à huit GPU. Ces performances le rendent idéal pour les applications exigeant des temps de réponse minimaux, telles que les systèmes interactifs temps réel où une latence inférieure à 3 ms est une exigence de conception.

Observations sur l'efficacité de la mise à l'échelle : L'analyse révèle une diminution des gains de latence à mesure que le nombre de GPU augmente, et ce, sur toutes les plateformes. La réduction de latence la plus importante est observée lors du passage d'une configuration à un seul GPU à une configuration à deux GPU (environ 50 % sur toutes les plateformes). Les configurations comportant plus de quatre GPU présentent des améliorations de latence progressivement plus faibles.

Analyse comparative des H200 et H100 : Le H200 affiche une latence inférieure de 5 à 8 % à celle du H100, et ce, quelle que soit la configuration. L’écart absolu diminue avec l’augmentation du nombre de GPU (2,81 ms contre 2,86 ms pour huit GPU, soit une différence de 0,05 ms). Ce faible écart de performance, comparé à la différence de prix de 41 %, suggère que le H100 pourrait offrir un meilleur rapport coût-performance pour les déploiements sensibles à la latence.

Caractéristiques de latence du MI300X : Le MI300X présente des valeurs de latence de 37 à 75 % supérieures à celles du H200 sur l’ensemble des configurations testées. Ceci peut être attribué aux différences actuelles de maturité des piles logicielles entre les implémentations vLLM ROCm et CUDA. Avec une configuration à huit GPU, le MI300X atteint une latence de 4,20 ms, ce qui reste acceptable pour de nombreuses applications de production malgré l’écart de performances par rapport aux plateformes mentionnées précédemment.

Performance et prix : une analyse coût-efficacité

Bien que les indicateurs de performance bruts soient essentiels, la décision finale pour toute organisation repose sur le rapport coût-efficacité. Afin d'analyser le retour sur investissement (ROI) de chaque plateforme, nous avons comparé nos résultats de débit aux tarifs horaires à la demande de RunPod en vigueur au moment des tests. Cela nous permet de calculer un score de « performance par dollar », révélant ainsi la configuration offrant la plus grande puissance de calcul au coût le plus bas.

Remarque : Les tarifs indiqués correspondent aux prix à la demande disponibles sur la plateforme RunPod Cloud au moment de l’évaluation comparative (septembre 2025) et sont susceptibles d’évoluer. Ces coûts sont présentés à titre indicatif 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 brutes de performance en fonction 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 à la configuration GPU spécifique (par exemple, 4x H100 coûtent 10,76 $).
• Calcul : Nous avons ensuite appliqué la formule pour calculer le rendement par dollar. Par exemple, le H100 avec un GPU dédié a fourni 23 243 jetons/s pour un coût de 2,69 $/h, soit un rendement de 8 642 jetons/s par dollar.

Ce score d'efficacité constitue un outil d'aide à la décision, faisant passer le débat 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 à accroître ses performances en répartissant une tâche complexe sur plusieurs GPU. Pour l'inférence LLM, cela peut être réalisé grâce au parallélisme des données : 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 permettrait de doubler les performances d'un seul GPU (accélération de 2x). Cependant, en pratique, les gains de performance sont limités par les goulots d'étranglement du processeur et du 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 la contention des ressources. Notre test de performance mesure l'efficacité avec laquelle chaque plateforme gère ces contraintes système, un facteur essentiel pour la conception de serveurs d'inférence IA performants et économiques pour les modèles de petite et moyenne taille.

Quels sont les défis rencontrés lors 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.

Surcharge de communication et goulots d'étranglement d'interconnexion

Lorsqu'un modèle est réparti entre plusieurs GPU, l'interconnexion, telle que NVLink (NVIDIA) ou Infinity Fabric (AMD), devient un goulot d'étranglement critique en termes de performances. L'efficacité de la communication inter-GPU influe directement sur la mise à l'échelle. Si le temps d'attente des données provenant d'un autre GPU dépasse le temps gagné grâce à la parallélisation des calculs, les gains de performance seront moindres. Cet effet est particulièrement marqué pour les modèles dont la taille est insuffisante 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, incluant les pilotes, les bibliothèques de communication (telles que NCCL pour NVIDIA et RCCL pour AMD) et le moteur d'inférence (vLLM), joue un rôle primordial. 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 pour NVIDIA bénéficie souvent d'années de mise au point et d'optimisation, ce qui peut se traduire par une efficacité de mise à l'échelle supérieure à celle d'intégrations plus récentes comme ROCm pour AMD, même sur du matériel puissant.

Optimisations spécifiques à la plateforme

Comme l'ont révélé nos tests, l'obtention de performances optimales requiert souvent des configurations spécifiques à la plateforme. Une approche générique et universelle peut conduire à des performances trompeusement faibles. L'image Docker appropriée, les variables d'environnement (par exemple, l'activation des noyaux personnalisés AMD) et même les types de données du modèle (par exemple, bfloat16 pour Blackwell) sont essentiels pour exploiter pleinement le potentiel du matériel. De ce fait, les comparaisons équitables constituent un défi technique majeur.

Méthodologie d'évaluation comparative multi-GPU

Nous avons testé les dernières architectures GPU hautes performances issues des protocoles NVIDIA et AMD afin d'évaluer leurs capacités de mise à l'échelle. Notre test de performance a mesuré les performances de configurations mono-GPU et multi-GPU (1x, 2x, 4x, 8x) à l'aide de l'instruction standard meta-llama/Llama-3.1-8B-Instruct. ¹ modèle et le vLLM ² moteurs d'inférence.

Environnement et processus de test

• Plateforme : Tous les tests de performance ont été exécutés sur RunPod Cloud afin de garantir un accès matériel constant.
• Moteur d'inférence : vLLM (outil de débit de banc vllm) a été utilisé comme moteur standardisé.
• Modèle : méta-llama/Llama-3.1-8B-Instruct.
• Jeu de données : Jeu de données ShareGPT Vicuna (25 000 invites) pour simuler une charge de travail conversationnelle.
• Stratégie : Parallélisme des données ; chaque test multi-GPU a exécuté une instance vLLM indépendante sur chaque GPU. La charge totale a été répartie uniformément entre les instances, exécutées simultanément afin de simuler un environnement de production à charge équilibrée. Cette approche élimine la communication inter-GPU (NVLink/PCIe) comme facteur limitant, déplaçant les limitations 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

L'obtention de performances optimales nécessitait des configurations sur mesure pour chaque architecture.

NVIDIA plateformes (H100, H200, B200)

• Image de base : runpod/pytorch:2.8.0-py3.11-cuda12.8.1.
• Installation vLLM :
  • H100/H200 (Trompette) : Installation standard via pip install vllm.
  • B200 (Blackwell) : vLLM a été compilé à partir de la source (pip install -e .) pour activer la prise en charge native de la nouvelle architecture, résolvant les erreurs « aucune image du noyau ».
• Paramètres clés :

• Variable environnementale critique :

AMD plateforme (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 permis d’identifier les paramètres non par défaut suivants comme étant essentiels pour obtenir un débit maximal :

• AMD-variables d'environnement spécifiques :

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

Phases d'exécution de référence

Chaque test de performance a suivi un protocole d'exécution en trois phases afin de garantir des résultats précis et reproductibles :

Phase 1 : Échauffement

Avant chaque test de configuration multi-GPU, nous avons effectué une phase de préchauffage dédiée afin d'éliminer les effets du démarrage à froid :

• Durée : 100 requêtes traitées sur le GPU 0
• Objectif : Chargement du modèle, initialisation du cache KV et compilation du noyau CUDA/ROCm
• Sortie : Rejetée (non incluse dans les mesures)
• Comportement spécifique à la plateforme :
  • NVIDIA (CUDA) : Compilation du noyau et optimisation du graphe CUDA (~30-60 secondes)
  • AMD (ROCm) : Compilation du noyau et réglage optionnel de TunableOp (varie en fonction du paramètre PYTORCH_TUNABLEOP_ENABLED)

Phase 2 : Initialisation de la surveillance du GPU

Parallèlement à l'exécution des tests de performance, nous avons lancé des processus de surveillance dédiés pour chaque GPU :

• Fréquence d'échantillonnage : intervalles de 1 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 : fichiers journaux CSV pour l’analyse ultérieure

Phase 3 : Exécution parallèle des tests de performance

Une fois la phase de préchauffage terminée, toutes les instances GPU ont été lancées simultanément :

• Chaque GPU a traité une part égale des 25 000 requêtes totales.
• Toutes les instances ont démarré simultanément afin de simuler l'équilibrage de charge en production.
• Le débit total est mesuré comme la somme de toutes les sorties GPU.
• Temps d'exécution mesuré entre le démarrage de la première instance et la fin de la dernière instance

Impact réel des tests sur les performances

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

Pour en savoir plus

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

• Les 20 principaux fabricants de puces IA : NVIDIA et ses concurrents
• GPU cloud pour l'apprentissage profond : disponibilité et prix/performances
• Les 10 meilleurs clouds GPU sans serveur et 14 GPU économiques
• Test de concurrence GPU

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.

Nom

Adresse email

Commentaire

0/450

Publier un commentaire