AMD MI300X dépasse le NVIDIA H100 en inférence LLM

 (blog.tensorwave.com)
1 points par GN⁺ 2024-06-14 | 1 commentaires | Partager sur WhatsApp
  • Dans une comparaison d’inférence Mixtral 8x7B menée par TensorWave et MK1, la combinaison MI300X + MK1 Flywheel a affiché un débit 33 % supérieur à H100 SXM + vLLM sur un cas d’usage réel de chat
  • Le point clé du test portait sur les modèles MoE : Mixtral 8x7B tient sur une seule carte MI300X avec 192 Go de VRAM, alors qu’un H100 avec 80 Go de VRAM nécessite deux cartes et un tensor parallelism de 2
  • En inférence batch hors ligne, la combinaison MI300X est arrivée en tête pour toutes les tailles de batch, avec un écart de performance allant de 1,22x à 2,94x
  • Le test de distribution de chat en ligne utilisait des requêtes avec en moyenne 573 tokens en entrée et 50 tokens en sortie ; avec un objectif de latence moyenne de 5 secondes, 2 MI300X traitaient 33 % de requêtes par seconde de plus que 2 H100
  • TensorWave estime qu’au-delà du seul débit, la compétitivité coût et la disponibilité du matériel font du MI300X un candidat sérieux pour l’exploitation d’inférence cloud à grande échelle

Le cœur de la comparaison : le MI300X peut-il dépasser le H100 en inférence MoE ?

  • Le test s’est concentré sur une question centrale : l’accélérateur phare d’AMD, le MI300X, peut-il dépasser l’architecture Hopper de NVIDIA sur de vraies charges de travail IA ?
  • TensorWave et MK1 ont collaboré pendant un mois pour tirer le maximum des performances d’inférence IA sur le matériel AMD
  • L’accent initial a été mis sur l’architecture Mixture of Experts (MoE)
    • Le MoE a été choisi pour son efficacité de calcul et sa popularité
    • Il est présenté comme l’architecture utilisée dans de puissants LLM open source de Mistral, Meta, Databricks et X.ai
  • Avec le logiciel d’inférence MK1, le MI300X a atteint un débit 33 % supérieur à la combinaison H100 SXM + vLLM sur un cas d’usage réel de chat basé sur Mixtral 8x7B
  • TensorWave reconnaît que l’écosystème logiciel de NVIDIA est plus mature, tout en estimant qu’AMD est déjà un concurrent solide sur le marché de l’IA

Configuration du benchmark

  • Tous les benchmarks ont été réalisés avec le modèle Mixtral 8x7B
  • Les frameworks d’inférence étaient tous configurés pour utiliser le chemin de calcul FP16
    • L’activation du calcul FP8 est laissée à de futurs travaux
  • Le débit du MI300X a été extrapolé par un facteur 2 afin de comparer différentes configurations de tensor parallelism

  • Système AMD

    • Le nœud TensorWave testé était équipé de 8 accélérateurs MI300X, de 2 processeurs AMD EPYC CPU, pour un total de 192 cœurs, et de 2,3 To de RAM DDR5
    • Les caractéristiques de l’accélérateur MI300X sont les suivantes
      • 192 Go de VRAM
      • 5,3 To/s
      • Environ 1300 TFLOPS en FP16
    • La configuration logicielle est la suivante
      • ROCm 6.1.2
      • Moteur d’inférence MK1 Flywheel v0.9.2
      • Fork vLLM optimisé AMD ROCm rocm/vllm v0.4.0
    • Comme l’intégralité du modèle Mixtral 8x7B tient dans les 192 Go de VRAM d’un seul MI300X, le tensor parallelism est réglé sur 1 (tp=1)

  • Système NVIDIA

    • Le système H100 testé était composé de 8 accélérateurs H100 SXM5 avec NVLink, de 160 cœurs CPU et de 1,2 To de RAM DDR5
    • Les caractéristiques de l’accélérateur H100 SXM5 sont les suivantes
      • 80 Go de VRAM
      • 3,35 To/s
      • Environ 986 TFLOPS en FP16
    • La configuration logicielle est la suivante
      • CUDA 12.2
      • vLLM v4.3
        • Afin de faire tenir Mixtral 8x7B sur deux H100 de 80 Go de VRAM, le tensor parallelism est réglé sur 2 (tp=2)

Résultats de l’inférence hors ligne

  • Le test hors ligne génère des prompts de taille fixe, les envoie directement au modèle, puis mesure le débit maximal de chaque solution d’inférence
  • Le batching hors ligne améliore l’efficacité matérielle en traitant plusieurs prompts simultanément
    • Quand la taille du batch augmente, le débit progresse
    • Comme davantage de requêtes sont traitées en même temps, la latence augmente aussi
  • Conformément aux pratiques standard, les requêtes d’un même batch étaient limitées à une taille d’entrée identique et une taille de sortie identique
  • Le test a été mené en modifiant benchmark_throughput.py du dépôt vLLM
    • Le code a été refactoré pour inclure Flywheel comme backend
    • Les prompts du batch ont été générés aléatoirement afin de supprimer les mécanismes de cache
  • La combinaison MI300X + MK1 Flywheel a affiché de meilleures performances que H100 + vLLM pour toutes les tailles de batch
    • Le gain de performance se situe entre 1,22x et 2,94x

Test de distribution de chat en ligne

  • Le benchmark en ligne a été conçu pour simuler une application de chat généraliste réaliste
  • Le test s’est déroulé en créant des workers indépendants envoyant des requêtes vers l’endpoint, puis en augmentant leur nombre pour accroître la concurrence
  • Les requêtes ont été générées à partir d’une distribution standard de chat textuel
    • Nombre moyen de tokens en entrée : 573
    • Nombre moyen de tokens en sortie : 50
  • L’outil de benchmark prend en charge des distributions de données arbitraires
  • Trois métriques ont été mesurées
    • Débit : nombre de requêtes traitables par seconde pour une charge donnée
    • Latence moyenne : temps moyen nécessaire pour générer la réponse complète à chaque requête
    • TPOT (Time Per Output Token) : temps moyen nécessaire pour générer chaque token après le premier, ce qui influe sur la vitesse de génération des réponses longues

  • Résultats non streaming

    • Le premier benchmark en ligne testait un cas d’usage non streaming
    • Il mesurait le débit et la latence nécessaires pour fournir la réponse complète
    • Avec un objectif de latence moyenne de 5 secondes, 2 MI300X (tp=1) traitaient 33 % de requêtes par seconde de plus que 2 H100 (tp=2)
    • Il est donc possible de servir le même nombre d’utilisateurs avec moins d’accélérateurs à qualité de service équivalente

  • Résultats en streaming

    • Le second benchmark en ligne activait le streaming et mesurait le débit ainsi que le TPOT pendant le flux des tokens
    • Le MI300X a montré un débit supérieur à celui du H100 pour tous les niveaux de TPOT
    • Le MI300X peut ainsi générer du texte plus rapidement, même sous des volumes de trafic plus élevés

Conclusion et recommandations de déploiement

  • D’après les résultats du benchmark, l’AMD MI300X surpasse le NVIDIA H100 pour les tâches d’inférence hors ligne et en ligne sur des architectures MoE comme Mixtral 8x7B
  • Le MI300X a également obtenu de meilleurs résultats dans des scénarios réels exigeant non seulement un fort débit, mais aussi des temps de réponse rapides
  • TensorWave recommande le MI300X, utilisé avec le logiciel MK1, comme option adaptée à la montée en charge de l’inférence IA en entreprise, en tenant compte des performances, de la compétitivité coût et de la disponibilité du matériel
  • TensorWave indique proposer le MI300X avec le logiciel d’inférence MK1 et invite les utilisateurs à le tester par eux-mêmes

À lire aussi

1 commentaires

 
GN⁺ 2024-06-14
Avis de Hacker News

  • Étant donné que TensorWave est un fournisseur de cloud spécialisé dans les charges de travail IA et qu’il utilise AMD Instinct MI300X, il faut prendre ce rapport avec un certain recul

    • Il fait une comparaison typique à la manière d’AMD : 8x AMD MI300X (192 Go, 750 W) contre 8x H100 SXM5 (80 Go, 700 W)
      Une comparaison plus équitable serait avec 8x H100 NVL (188 Go, <800 W)
      Le prix en dit aussi long. Si les performances d’AMD étaient au niveau de celles de Nvidia, il n’y aurait aucune raison de vendre les cartes à un quart du prix
    • Le point positif, c’est qu’ils indiquent précisément comment les benchmarks ont été exécutés. Avec le matériel, il est facile de les reproduire pour les contester ou les confirmer
    • Je ne suis pas sûr que ce billet aurait été meilleur s’ils avaient utilisé des puces Nvidia

  • Je ne comprends pas pourquoi, en 2024, on fait encore des benchmarks avec 128 tokens d’entrée. Cela ne représente pas la plupart des charges de travail, et les performances de pré-remplissage (prefill) sont très importantes

    • Je me demande quelle longueur d’entrée serait considérée comme appropriée
      Selon que les requêtes réelles sont plus courtes ou plus longues, les raisons pour lesquelles 128 serait inadapté changent aussi
      Si l’on considère qu’un mot correspond à un token, la plupart de mes requêtes font moins de 128 mots

  • J’essaie de voir cela avec optimisme. Ce secteur a absolument besoin de concurrence, et la capitalisation boursière de $NVDA est actuellement anormalement élevée. Elle dépasse celle de l’ensemble de la Bourse de Francfort d’environ 600 milliards de dollars

    • C’est plutôt la valorisation de la Bourse de Francfort qui est trop faible. On se demande sans cesse pourquoi les développeurs européens sont moins payés qu’aux États-Unis pour le même travail : la raison est là
    • La Bourse de Francfort ou le DAX ne signifient pas grand-chose dans l’ensemble. L’Allemagne compte beaucoup de solides entreprises familiales du Mittelstand, qui ne sont pas cotées
      Il existe aussi de gigantesques entreprises non cotées détenues par de riches Allemands, comme les géants du discount Lidl et Aldi, ou l’équipementier automobile Bosch
    • Nous sommes en plein milieu de la bulle des LLM
      Le problème Nvidia a de fortes chances de se résoudre naturellement dans les mois ou les années à venir

  • En tant que scientifique en IA qui entraîne beaucoup de modèles, je pense personnellement qu’AMD est sous-évalué par rapport à Nvidia
    Leurs puces ne sont pas aussi rapides que les derniers produits de Nvidia, et il y a encore des obstacles à franchir pour les faire fonctionner
    Mais pour la plupart des charges de travail dans la plupart des industries, si l’on met de côté la question de savoir si l’IA elle-même est un bon usage du capital, AMD est bien plus rentable et peut produire quasiment les mêmes résultats

  • Le marché et les prix de vente reflètent la valeur perçue des solutions Nvidia et AMD. Cela englobe les outils, le logiciel, le coût total de possession et la facilité d’administration
    Je me demande aussi combien d’entreprises achètent des accélérateurs aussi chers pour exécuter en parallèle huit modèles à 7B paramètres
    On entend aussi dire qu’il est possible d’entraîner un modèle 14B sur un seul accélérateur ; j’aimerais voir des charges de travail « entraînement et inférence utilisant tout l’accélérateur », par exemple le débit d’inférence obtenu sur une charge 4x14B après l’entraînement d’un modèle 14B
    AMD et la plupart des entreprises qui revendiquent jusqu’ici des performances d’inférence, en particulier Intel et Apple, ont choisi uniquement les benchmarks qu’elles pouvaient gagner et ont ignoré le reste, où Nvidia est devant. Comme plusieurs commentaires l’ont signalé ici, l’article utilise aussi un modèle de comparaison de génération intermédiaire

    • MI300X gagne sur certaines charges de travail d’inférence, tandis que H100 gagne sur l’entraînement et certaines autres charges de travail d’inférence. Par exemple, le H100 est solide en inférence FP8 avec TensorRT-LLM, et ROCm est encore jeune mais progresse rapidement
      Dans un système unique, c’est-à-dire une configuration à 8 accélérateurs pour les LLM, le MI300X est très compétitif face au H100 sur le coût total de possession de l’inférence
      Selon Microsoft, l’AMD Instinct MI300X offre le meilleur rapport prix/performances sur GPT-4, et AMD vise une amélioration de 100x des performances par watt d’ici 2027
      https://wccftech.com/amd-instinct-mi300x-best-price-performa...
    • Le marché et les prix de vente intègrent aussi la stratégie commerciale. Pour entrer dans un domaine dominé par un acteur puissant qui emploie une stratégie commerciale assez « intelligente », un produit moins mature, en particulier côté logiciel, a besoin d’une tarification et d’une stratégie d’allocation des volumes adaptées
      https://www.techspot.com/news/102056-nvidia-allegedly-punish...
    • La production de MI300X est en hausse. Lors de la dernière publication de résultats, Lisa Su a déclaré que la production avait été limitée au premier semestre 2024, mais qu’elle augmentait au second semestre et qu’il restait encore des volumes disponibles à la vente. C’est probablement grâce à l’amélioration de l’approvisionnement en CoWoS et en HBM3/HBM3E
      Les grosses commandes de ce type d’accélérateurs sont passées plusieurs mois à l’avance
      De son côté, la capacité MI300X de Microsoft est déjà entièrement réservée
      https://techcommunity.microsoft.com/t5/azure-high-performanc...
      « Ces VM, ainsi que le logiciel qui les alimente, ont été conçus spécifiquement pour les charges de travail de production réelles des services Azure AI. Nous avons déjà optimisé GPT-4 Turbo, le modèle de langage naturel le plus puissant au monde, pour ces VM. Les VM ND MI300X v5 offrent un coût-performance de premier plan sur les modèles populaires d’OpenAI et open source. »

  • Je me demande si la configuration du parallélisme tensoriel influe sur les performances. Mon intuition naïve serait que oui, mais je n’en suis pas certain.
    D’après l’article, la configuration AMD peut faire tenir l’intégralité de Mixtral 8x7B dans les 192 Go de VRAM d’un seul MI300X, donc avec un parallélisme tensoriel tp=1, tandis que la configuration NVIDIA doit la répartir sur les 80 Go de VRAM de deux H100, ce qui nécessite tp=2.

    • Personnellement, je ne trouve pas ce type de comparaison équitable. Une bonne comparaison devrait être optimisée pour chaque configuration matérielle.
      Autrement dit, il faudrait utiliser un modèle qui tient dans la limite de VRAM, et appliquer par exemple une quantification 8 bits quand cela améliore les performances, afin de ne pas exposer inutilement les faiblesses de chaque matériel.

  • AMD semble avoir un meilleur matériel, mais n’a pas encore la capacité de production nécessaire pour concurrencer Nvidia. Si une vraie concurrence arrive, il sera intéressant de voir les marges se réduire.
    Tout le monde pense que la domination de Nvidia vient de CUDA, mais ce n’est pas le cas. Près de 40 % de son chiffre d’affaires cette année vient d’hyperscalers qui utilisent leur propre stack sur mesure pour interagir avec les GPU.
    Ce n’est qu’une question de temps avant que des concurrents rattrapent leur retard et proposent des GPU moins chers.

    • L’expression « leur propre stack sur mesure pour interagir avec les GPU » ressemble presque à une pure invention.
      Il semble y avoir confusion entre la plateforme CUDA et le langage proche du C/C++ que les gens écrivent dans des fichiers .cu.
      Il est vrai que certains n’écrivent pas directement de fichiers .cu, mais personne ne contourne le reste de la stack CUDA, comme nvcc, PTX, SASS, le runtime et les pilotes.
      Je travaille moi-même dans l’un de ces « hyperscalers ». Si vous n’y croyez pas, regardez combien de kernels CUDA il y a dans PyTorch : https://github.com/pytorch/pytorch/tree/main/aten/src/ATen/n...
      Ce qui rend Nvidia dominant, c’est à 100 % CUDA.
    • J’aimerais savoir si quelqu’un peut expliquer plus précisément à quoi ressemblerait une stack sans CUDA, ou fournir une source.
    • La capacité de production est au final une question de négociation avec TSMC ou avec les quelques concurrents existants.
      Il me semble que TSMC a aussi commencé à produire dans certaines usines aux États-Unis ou dans l’UE.
      Nvidia utilise TSMC, et AMD utilise aussi TSMC.

  • C’est un bon départ pour AMD. Je m’intéresse aussi à Groq, une autre option d’inférence qui n’est pas Nvidia, et je l’utilise parfois.
    Nvidia dépend de TSMC pour la fabrication. Le fait que Samsung construise aussi une infrastructure de fabrication concurrente est une bonne chose, car cela évite que Taïwan devienne un point de défaillance unique.

  • Sans indicateurs statistiques appropriés, en particulier si l’on utilise la moyenne au lieu du 95e percentile largement employé, et sans performance par watt, la comparaison ne sert à rien.

    • Et il faut aussi le rapport performance/prix. C’est finalement l’essentiel.
    • J’ai l’impression que la moyenne est un meilleur indicateur du débit.
      Ce serait bien d’avoir aussi le 95e percentile.

  • Il aurait aussi été bien d’avoir des benchmarks INT8/FP8. Les deux cartes auraient probablement pu charger le modèle avec environ 60 Go de VRAM, sans utiliser tp=2 sur les H100.