AMD MI300X vs H100 : deux accélérateurs pour des usages différents

Le MI300X est un accélérateur AMD Instinct fondé sur l'architecture CDNA 3. Selon la documentation d'acceptation système AMD, chaque GPU combine 8 XCD (Accelerator Complex Dies) et 192 Go de HBM3. La plateforme de référence UBB 2.0 regroupe huit modules OAM, soit 1,5 To de HBM3, reliés par une interconnexion Infinity Fabric entièrement maillée.

Le H100 se lit mieux à travers un déploiement concret. Le CNRS décrit l'extension de Jean Zay : 364 serveurs bi-processeurs Intel Sapphire Rapids, chacun équipé de 512 Go de mémoire et de quatre H100 SXM5 de 80 Go. Chaque serveur dispose de quatre adaptateurs InfiniBand ConnectX-7 à 400 Gb/s.

Élément AMD MI300X (doc. AMD) NVIDIA H100 (Jean Zay, CNRS)
Mémoire par GPU 192 Go HBM3 80 Go (SXM5)
Configuration décrite 8 GPU par carte UBB 2.0 4 GPU par serveur
Interconnexion Infinity Fabric maillée InfiniBand ConnectX-7 400 Gb/s
Pile logicielle ROCm CUDA

Ce tableau compare des configurations documentées, pas des performances. Les performances réelles exigent des benchmarks reproductibles sur vos propres charges.

Deux philosophies logicielles

CUDA est l'écosystème propriétaire de NVIDIA, très largement adopté par les frameworks, les bibliothèques et les outils de serving. ROCm est la pile ouverte d'AMD, orientée HPC et IA. L'un offre une profondeur d'outillage accumulée sur de nombreuses années, l'autre une ouverture du code et une alternative de fournisseur.

Ce qui compte pour une installation IAPRO

Le choix pertinent dépend de critères concrets :

  • le modèle visé (Mistral 7B, Llama 3, Qwen) et sa taille réelle une fois quantifié ou non ;
  • le framework et le serveur d'inférence utilisés, ainsi que leurs versions officiellement supportées ;
  • la précision de calcul retenue, le type de parallélisme et la latence attendue par les utilisateurs ;
  • la capacité de l'équipe à opérer une infrastructure maîtrisée, documentée et reconstructible.

Les termes techniques sont définis dans notre glossaire de l'IA.

ROCm contre CUDA : la vraie question de compatibilité logicielle

Dans une comparaison AMD MI300X vs H100, la couche logicielle pèse davantage que le silicium. Avant toute migration, j'audite huit éléments : système d'exploitation, version du pilote, version de ROCm ou de CUDA, compilateur, bibliothèques de calcul, support du framework, conteneurs, outils de supervision.

Les dépendances cachées

Un code PyTorch ou JAX semble portable, mais il peut dépendre indirectement de kernels CUDA écrits à la main, de cuDNN, de TensorRT, d'extensions C++ compilées ou d'opérateurs absents sous ROCm. À l'inverse, les frameworks récents offrent une vraie voie de portage lorsque les versions utilisées figurent dans les matrices de support officielles. Ces matrices doivent être consultées pour chaque version précise, au moment du projet.

Les équivalences à examiner

Côté NVIDIA Côté AMD Point de vigilance
CUDA HIP portage du code natif
cuBLAS rocBLAS couverture des formats
cuDNN MIOpen opérateurs disponibles
NCCL RCCL communications multi-GPU

Trois niveaux de compatibilité

  1. Syntaxique : le code compile et se lance. C'est nécessaire, mais insuffisant pour une mise en production.
  2. Fonctionnelle : les sorties numériques restent dans une tolérance définie à l'avance, comparées à une exécution de référence.
  3. Opérationnelle : la pile tient la charge, se supervise, se met à jour et redémarre proprement après un incident.

Le protocole proposé

Je recommande un environnement figé, des images conteneurisées versionnées, des tests unitaires, une validation numérique, des essais multi-GPU et une mesure de régression à chaque montée de version. Pour les modèles génératifs, les points sensibles sont la quantification, les kernels d'attention dont Flash Attention, le parallélisme tensoriel, le serveur d'inférence et le format des poids.

La documentation AMD impose elle-même, en prérequis d'acceptation, un système d'exploitation supporté, une version ROCm compatible, la vérification de la compatibilité du fabricant du serveur et l'installation de toutes les dépendances requises.

La règle est simple : on ne choisit pas une marque sur sa fiche technique. On choisit une pile logicielle testée de bout en bout, du pilote jusqu'à l'interface utilisateur OpenWebUI.

Entraînement, inférence et HPC : quel GPU pour quelle charge IAPRO ?

Trois scénarios évitent les conclusions générales et les comparaisons trompeuses.

Entraînement et fine-tuning

La capacité mémoire par GPU, la bande passante HBM, le parallélisme distribué et les communications entre accélérateurs dominent. Avec 192 Go de HBM3, le MI300X peut réduire certains découpages de modèle ou besoins d'offload. Cette hypothèse reste à valider sur le modèle, la longueur de séquence, le batch et la précision réellement utilisés, y compris pour un LoRA.

Inférence de grands modèles de langage

Les métriques utiles sont le débit, la latence, le nombre d'utilisateurs simultanés, la longueur de contexte, la quantification et la consommation énergétique. Une mémoire plus grande facilite le placement d'un modèle sur un seul GPU. En revanche, la maturité du serveur d'inférence et de ses kernels peut peser davantage que le débit théorique.

HPC et calcul scientifique

Les tests doivent mesurer la précision, les communications et la stabilité, pas seulement les FLOPS. AMD publie des critères d'acceptation : TransferBench P2P à au moins 33,9 Go/s en unidirectionnel, GEMM simple précision à au moins 94 100 GFLOPS, GEMM INT8 à au moins 162 700 GFLOPS. Ce sont des seuils de qualification matérielle, pas une mesure comparative face au H100.

La batterie de benchmarks proposée

  • Prétraitement des données et temps de chargement des poids, mesurés à froid puis à chaud.
  • Entraînement court sur données représentatives, avec suivi de la courbe de perte et de la mémoire.
  • Génération : temps au premier token, tokens par seconde, comportement sous montée en charge progressive.
  • Consommation électrique, taux d'erreur et temps de reprise après un incident provoqué volontairement.
  • Tests complémentaires sur modèles de vision ou multimodaux, uniquement si le périmètre réel les inclut.

Les résultats publiés par les fournisseurs ou par des tiers utilisent souvent des configurations différentes des vôtres : versions logicielles, taille de batch, précision ou réseau.

Charge Critère dominant Mesure décisive
Entraînement mémoire, réseau temps par époque
Inférence LLM serving, latence coût par million de tokens
HPC précision, stabilité résultat validé

La décision se prend par charge, sur données représentatives et avec des métriques métier, pas sur une fiche constructeur.

Déployer une infrastructure IAPRO souveraine sur MI300X ou H100

Un accélérateur ne se déploie jamais seul. Jean Zay le montre : ses H100 s'appuient sur un réseau InfiniBand et sur un stockage Lustre fourni par DDN. Ce stockage comprend 4,3 Po de flash à plus de 1 To/s et 39 Po de disque rapide à plus de 300 Go/s, selon le CNRS.

Les briques à dimensionner

Serveurs, interconnexion, stockage, orchestration, registre d'images, contrôle des accès, journalisation, sauvegardes, supervision et gestion des secrets. Chacune peut devenir le goulot d'étranglement, même avec le GPU le plus récent.

Qualifier une plateforme MI300X

AMD structure l'acceptation en quatre étapes :

  1. Prérequis : système d'exploitation supporté, version ROCm compatible, serveur validé par son fabricant, dépendances installées.
  2. Contrôles de santé : détection PCIe des huit GPU via lspci, état matériel de base de chaque accélérateur.
  3. Validation système : tests de stress et stabilité prolongée sous charge.
  4. Benchmarks : calcul, mémoire et interconnexion, comparés aux seuils publiés.

Une architecture indépendante du fournisseur

Je propose une architecture de référence neutre : images OCI versionnées, ordonnanceur compatible avec les deux piles, séparation des workloads, quotas, observabilité complète et procédure de rollback testée. Ollama, OpenWebUI et la couche RAG restent ainsi découplés du matériel.

La souveraineté, définie précisément

La souveraineté recouvre la localisation des données, la maîtrise des identités et des clés, la dépendance aux services cloud, les accès administrateur, la traçabilité et la capacité à reconstruire l'environnement. Elle ne se confond pas avec l'origine européenne du matériel : elle se construit par la gouvernance, l'opérabilité et la réversibilité.

Le contexte européen

L'Union européenne monte en capacité. La Commission indique que l'EuroHPC JU supervise 19 AI Factories et 13 antennes, et le dispositif s'élargit, comme le relève Interoperable Europe. Alice Recoque, future machine exascale française, utilisera des AMD Instinct MI430X selon AMD, et non des MI300X. Aucune compatibilité automatique avec une installation IAPRO n'en découle.

Avant toute mise en production, une checklist d'architecture et d'acceptation doit être signée.

Migrer de NVIDIA H100 vers AMD MI300X sans interrompre les services

Une migration CUDA vers ROCm est un projet de qualification progressive, pas un remplacement de cartes un week-end.

Inventaire et classement

L'inventaire couvre les modèles, frameworks, versions, images, extensions natives, bibliothèques, scripts de lancement, métriques, jeux de données et exigences de conformité. Chaque composant est ensuite classé dans l'une de trois catégories : portage direct, adaptation nécessaire, blocage à traiter avant toute décision.

La trajectoire en huit étapes

  1. Sélection d'un modèle pilote représentatif mais non critique pour l'activité.
  2. Reproduction fidèle de l'environnement dans une image conteneurisée versionnée.
  3. Portage des kernels et des extensions natives, de CUDA vers HIP.
  4. Tests numériques comparés à la référence, avec tolérances fixées à l'avance.
  5. Benchmark mono-GPU sur les métriques métier retenues.
  6. Validation multi-GPU, notamment des communications RCCL.
  7. Déploiement canari sur une faible part du trafic réel.
  8. Comparaison en production, puis bascule ou retour arrière documenté.

Conserver un environnement H100 de référence est indispensable : c'est lui qui permet de distinguer un écart dû au matériel d'un écart dû au logiciel ou à la configuration.

Points de contrôle par usage

Pour les modèles génératifs : poids, tokenizer, mécanismes d'attention, quantification, batching, cache KV et serveur d'inférence. Pour l'entraînement : convergence, reproductibilité, consommation mémoire, points de reprise et vitesse des communications distribuées.

Critères de sortie

Chaque étape définit ses seuils : précision minimale, latence maximale, débit cible, disponibilité, consommation, coût par requête ou par époque. Sans critère écrit, une étape n'est pas validée.

Ce qui ne se transpose pas

Le portage peut exiger une version spécifique de ROCm ou du framework. Un kernel optimisé pendant des mois pour CUDA ne délivre pas forcément les mêmes performances sous HIP sans travail d'optimisation dédié. Il faut budgéter ce travail.

La migration s'accompagne d'une documentation d'exploitation, d'une formation des équipes et d'un plan de retour arrière testé. Notre positionnement est une expertise de compatibilité mesurée, réversible et auditée, pas une promesse de substitution universelle. Les impacts par secteur sont détaillés dans nos fiches métiers.

Coût total, conformité et décision d'achat pour IAPRO

Le coût total de possession

Il additionne l'achat ou la location des GPU, les serveurs, le réseau, le stockage, l'énergie, le refroidissement, les licences, le support, l'ingénierie de portage, l'exploitation, le renouvellement et le coût d'immobilisation. Le chiffre qui compte reste le coût par unité métier : un entraînement, un million de tokens générés, une heure d'inférence ou un projet livré. Notre calculateur de ROI IA aide à poser ces hypothèses. Aucun ROI ne se déduit du nombre de GPU ou d'une performance théorique ; il faut des mesures sur vos charges, taux d'utilisation et coûts d'administration inclus.

La conformité

Elle couvre la localisation et le contrôle des données, la journalisation, la gestion des accès, la confidentialité des prompts, la traçabilité des modèles, la réversibilité et la dépendance fournisseur. Ces éléments documentent aussi la gouvernance attendue par le Règlement (UE) 2024/1689 et par le RGPD, quel que soit le GPU retenu.

Les investissements publics comme repères

L'extension H100 de Jean Zay a bénéficié de 40 M€ de France 2030, pour la recherche et l'industrie sous conditions souveraines. Alice Recoque affiche un budget d'environ 355 M€ selon la Commission, et un coût global de 554 M€ selon AMD, les périmètres annoncés différant. L'appel AI Factories d'EuroHPC plafonnait la contribution européenne à 15 M€ par AI Factory sur 3 ans. Ces exemples montrent que la souveraineté est aussi une affaire d'accès, de compétences et de gouvernance.

Recommandation conditionnelle

  • H100 est souvent préférable lorsque la compatibilité CUDA, la disponibilité des outils et le support opérationnel priment.
  • MI300X peut être pertinent lorsque la mémoire par GPU, la bande passante, l'ouverture de ROCm et la diversification apportent un avantage démontré par benchmark.
Critère Pondération indicative
Technique 25 %
Logiciel 25 %
Économique 20 %
Réglementaire 15 %
Humain 15 %

Ces pondérations sont un point de départ à ajuster selon votre contexte. La décision finale se documente par un pilote, un benchmark reproductible, une analyse de risques et un plan de réversibilité.

FAQ — AMD MI300X vs H100

Le MI300X est-il compatible avec les modèles développés pour NVIDIA H100 ?

Les poids d'un modèle ne dépendent pas du GPU, mais la pile qui l'exécute, si. Un modèle servi via un framework supporté par ROCm peut fonctionner sur MI300X. Les extensions CUDA natives, TensorRT ou certains kernels d'attention exigent un portage. La compatibilité se vérifie par modèle, par version et par serveur d'inférence.

Quelle est la différence entre ROCm et CUDA pour une application d'IA ?

CUDA est la pile propriétaire de NVIDIA, trèslargement adoptée par les frameworks et les outils de serving. ROCm est la pile ouverte d'AMD, avec HIP pour le code natif, rocBLAS, MIOpen et RCCL pour les bibliothèques. Pour une application d'IA, la différence porte sur la couverture des opérateurs, la maturité des kernels optimisés et les versions officiellement supportées.

Le MI300X possède-t-il davantage de mémoire que le H100 80 Go ?

Oui. La documentation AMD indique 192 Go de HBM3 par MI300X, contre 80 Go pour les H100 SXM5 installés sur Jean Zay selon le CNRS. Cette capacité peut éviter de découper certains modèles sur plusieurs GPU. L'avantage réel dépend toutefois du contexte, du batch, de la précision et du serveur d'inférence.

Faut-il réécrire entièrement un code CUDA pour l'exécuter sur MI300X ?

Rarement en totalité. Le code de haut niveau en PyTorch ou JAX se porte souvent si les versions sont supportées par ROCm. Les kernels CUDA écrits à la main doivent être convertis vers HIP, puis réoptimisés. Les dépendances à TensorRT ou à des bibliothèques propriétaires constituent les principaux blocages à identifier dès l'inventaire.

Quel GPU choisir pour l'inférence de grands modèles de langage chez IAPRO ?

Aucun choix universel n'existe. Le H100 bénéficie de la maturité de l'outillage CUDA ; le MI300X offre davantage de mémoire par GPU pour placer de grands modèles ou de longs contextes. La décision se prend après benchmark : temps au premier token, tokens par seconde, utilisateurs simultanés et coût par million de tokens.

Comment comparer objectivement les performances d'un MI300X et d'un H100 ?

En figeant tout le reste : même modèle, mêmes poids, même précision, même batch, même longueur de contexte et versions logicielles documentées. Il faut mesurer des métriques métier sur données représentatives, répéter les essais et publier la configuration complète. Les chiffres fournisseurs ou tiers servent de repères, pas de preuve applicable à votre charge.

Le choix du MI300X améliore-t-il automatiquement la souveraineté d'une infrastructure IA ?

Non. La souveraineté dépend de la localisation des données, de la maîtrise des identités et des clés, des accès administrateur, de la traçabilité et de la capacité à reconstruire l'environnement. Diversifier ses fournisseurs de GPU réduit une dépendance, mais ne remplace ni la gouvernance, ni l'opérabilité, ni un plan de réversibilité testé.

Quels tests IAPRO doit-il réaliser avant de migrer une charge H100 vers MI300X ?

La méthode proposée comprend l'acceptation matérielle AMD, avec prérequis, contrôles de santé, validation système et benchmarks. Viennent ensuite les tests unitaires, la validation numérique contre une référence H100, un benchmark mono-GPU puis multi-GPU, un déploiement canari et des tests de reprise. Chaque étape suit des critères de sortie écrits à l'avance.

Pour aller plus loin avec IAPRO

Vous envisagez un MI300X, un H100 ou une diversification entre les deux ? Le bon point de départ est un inventaire précis de votre pile : modèles, frameworks, serveur d'inférence, extensions natives et exigences de conformité. Décrivez-nous votre environnement actuel pour cadrer une évaluation de compatibilité fondée sur des benchmarks reproductibles, avant tout engagement d'achat. Si votre projet inclut du conseil ou de la formation, le simulateur d'aides permet de vérifier les dispositifs auxquels votre entreprise peut prétendre.

Vérifiez vos aides en 2 minutes

Chaque dispositif (Bpifrance, France Num, aides régionales, OPCO) a ses propres critères d'éligibilité et ses propres délais. Notre simulateur croise votre profil avec les dispositifs actifs, ou échangez directement avec un expert IAPRO.

Vérifier mon éligibilité Demander un diagnostic gratuit de 30 min

Vérifiez vos aides en 2 minutes

Votre projet IA est peut-être finançable à 40-80 %. Le simulateur IAPRO croise 14 dispositifs (Bpifrance, Région Hauts-de-France, OPCO, CIR) et vous envoie le détail par email.

Vérifier mon éligibilité Demander un diagnostic gratuit de 30 min

Liens utiles