GPU H200 : architecture, performances et guide de déploiement cloud

GPU H200 : architecture, performances et guide de déploiement cloud

Le GPU NVIDIA H200 est un accélérateur de centre de données de génération Hopper dont la principale caractéristique de déploiement est la mémoire : 141 Go de HBM3e et 4,8 To/s de bande passante mémoire par GPU. Cela change la manière de planifier l’inférence à long contexte, les lots volumineux et les tâches HPC limitées par la mémoire, mais ne rend pas facultatives la planification de capacité ni la validation dans le cloud.

Ce guide explique ce qu’est le GPU H200, en quoi les H200 SXM et H200 NVL diffèrent, à quels cas d’usage il convient et comment valider un déploiement cloud avant de s’engager sur un parc plus important. Il évite délibérément les instantanés de prix variables des fournisseurs. Utilisez la liste de contrôle ci-dessous avec la région, le type de machine, la topologie et le contrat exacts auxquels vous avez accès.

Réponse courte

Choisissez un GPU H200 lorsque votre charge de travail est contrainte par la capacité ou la bande passante de la mémoire GPU, et lorsque vous pouvez valider le système environnant, pas seulement l’accélérateur. Pour un serveur de modèles à un seul GPU, cela signifie démontrer que les poids du modèle, l’espace de travail d’exécution et le cache KV tiennent avec une marge. Pour l’entraînement ou le service multi-GPU, cela signifie démontrer la connectivité entre GPU et, le cas échéant, le réseau entre les nœuds.

Le GPU H200 n’est pas une mise à niveau universelle. Si les requêtes sont courtes, les tailles de lots faibles, ou si la charge de travail est limitée par le CPU, le stockage ou le réseau, sa mémoire supplémentaire peut ne pas modifier le résultat qui compte. Commencez par une description de la charge de travail, puis testez une trace représentative.

Spécifications du GPU H200 : ce qui change votre plan de déploiement

NVIDIA présente le H200 comme un GPU d’architecture Hopper doté de 141 Go de mémoire HBM3e et de 4,8 To/s de bande passante mémoire. Il est disponible en H200 SXM et H200 NVL, avec les mêmes caractéristiques mémoire principales mais des formats, des enveloppes de puissance et des options de montée en charge différents. Les performances de pointe Tensor Core publiées par NVIDIA sont utiles pour comparer les configurations de produits, mais elles ne constituent pas une promesse de débit applicatif : ces chiffres incluent les conditions de test indiquées et des hypothèses de parcimonie. Consultez les spécifications actuelles du produit H200 avant de sélectionner une référence.

Il s’agit de chiffres publiés par le fournisseur, et NVIDIA les qualifie de préliminaires sur sa page produit. Utilisez-les comme référence de configuration, puis vérifiez la référence cloud exacte et sa topologie dans l’environnement où vous exécuterez la charge de travail.

Pourquoi la HBM3e est importante pour l’inférence de LLM

Pour le service de LLM, la mémoire GPU est consommée par bien plus que les poids du modèle. Une équation utile pour une première estimation de capacité est :

required GPU memory = weights + runtime workspace + KV cache at p95 context and concurrency + operational headroom

Le GPU H200 peut être intéressant lorsque le cache KV devient le facteur limitant : des invites plus longues, davantage de séquences simultanées ou un lot plus important peuvent tous l’augmenter. La HBM supplémentaire n’élimine pas le risque de manque de mémoire, car la politique de cache, le comportement de l’allocateur, la quantification, le parallélisme de modèle et la forme du trafic restent importants. Pour les déploiements à long contexte, associez cette décision à un plan de déchargement et de hiérarchisation du cache KV plutôt que de supposer que davantage de mémoire locale constitue toute la réponse.

H200 SXM ou H200 NVL : choisissez la topologie, pas seulement la carte

Le format est un choix de déploiement.

• H200 SXM convient aux conceptions de systèmes HGX H200 et NVIDIA-Certified comportant quatre ou huit GPU. C’est généralement le bon point de départ lorsqu’une charge de travail nécessite un système multi-GPU étroitement couplé et que l’application échangera fréquemment des données entre les GPU.
• H200 NVL est une conception PCIe double emplacement refroidie par air. NVIDIA indique des configurations avec pont NVLink à 2 ou 4 voies, tandis que les systèmes partenaires et certifiés peuvent contenir jusqu’à huit GPU. Ne déduisez pas que chaque serveur à huit GPU offre le même chemin direct de GPU à GPU ; inspectez la topologie réelle et mesurez les opérations collectives utilisées par votre environnement d’exécution.
• Répliques indépendantes n’ont pas automatiquement besoin de l’interconnexion la plus étroitement couplée. Si chaque réplique traite ses propres requêtes, privilégiez la capacité, la disponibilité, les ressources hôtes et une séparation nette de l’ordonnancement avant de payer pour une topologie que la charge de travail n’utilisera pas.

NVIDIA documente la capacité MIG du H200, mais ne considérez pas les modes de partage de GPU comme interchangeables. Dans Kubernetes, MIG crée des instances GPU isolées matériellement, tandis que le découpage temporel entrelace les tâches et ne fournit ni isolation mémoire ni isolation des pannes entre les réplicas. Le guide de partage du GPU Operator explique ce compromis et les limites de sa supervision.

Pour une comparaison d’achat plus approfondie, consultez H200 vs. H100. Cette comparaison est utile pour la décision ; cette page est le guide de déploiement une fois le H200 retenu comme candidat.

Quand un GPU H200 est le bon choix

Il vaut généralement la peine de tester un GPU H200 lorsque l’une de ces contraintes est réelle en production :

1. Inférence LLM limitée par la mémoire. Votre longueur de contexte p95 ou votre concurrence épuise le budget mémoire pratique avant que la puissance de calcul ne soit pleinement utilisée.
2. IA ou HPC sensible à la bande passante. Le profilage montre que la tâche passe une part importante de son temps à attendre les transferts de données en mémoire plutôt qu’à simplement saturer les calculs des Tensor Cores.
3. Un ensemble de travail plus important résidant en mémoire. Vous avez besoin de davantage d’espace pour un modèle, un contexte de récupération, un lot, un cache ou une structure de données scientifique sans ajouter immédiatement un autre GPU.
4. Charges de travail multi-GPU étroitement couplées. Vous pouvez utiliser un système de type H200 SXM/HGX et disposez d’éléments prouvant que l’application bénéficie de son fabric.
5. Une exigence de partitionnement contrôlé. Vous avez une raison claire d’utiliser les configurations MIG répertoriées, ainsi qu’un planificateur et un modèle de refacturation adaptés.

Ne sélectionnez pas le GPU H200 sur la seule base du nombre de paramètres du modèle. Un nombre de paramètres indique peu de choses sur la précision, l’espace de travail d’exécution, la politique de cache KV, le contexte maximal, la forme des lots et la marge de disponibilité. Il ne dit rien non plus sur le goulot d’étranglement du CPU hôte, de la RAM, du stockage ou du réseau qui peut dominer une charge de travail cloud.

Élaborez un plan de capacité H200 avant de louer un GPU cloud

Utilisez ce résumé d’une page avant de créer une instance ou de demander un pool de nœuds de cluster.

La valeur de ce résumé est de rendre rapidement visible une mauvaise adéquation. Par exemple, une configuration à un GPU peut échouer en raison de la pression du contexte p95 et du cache, même lorsqu’un test synthétique avec des prompts courts paraît excellent. À l’inverse, une configuration multi-GPU peut être moins performante si elle est répartie sur un fabric que le runtime n’utilise pas efficacement.

Déploiement cloud : un guide opérationnel H200 GPU par étapes

1. Confirmez la configuration cloud exacte

Demandez au fournisseur ou à l’équipe plateforme le format exact de l’accélérateur, le nombre de GPU, l’allocation CPU/RAM, le stockage local et persistant, les caractéristiques réseau et la topologie GPU. Consignez la réponse dans le ticket de déploiement. « H200 » seul ne fournit pas suffisamment d’informations pour anticiper les performances multi-GPU.

Avant de réserver de la capacité, validez ces détails dans un pilote de courte durée :

• H200 SXM ou H200 NVL
• Nombre de GPU et sortie de nvidia-smi topo -m
• si l’instance est exclusive, partitionnée ou partagée en tranches de temps
• versions du pilote, de CUDA, du runtime de conteneur et du framework
• RAM hôte disponible, cœurs de CPU, débit de stockage et chemin réseau
• durées de récupération de l’image, de téléchargement du modèle, de checkpoint et de redémarrage

2. Installez une pile logicielle prise en charge

Pour un déploiement Kubernetes, le GPU Operator de NVIDIA peut gérer le pilote NVIDIA, le toolkit de conteneur, le plugin de périphérique, GPU Feature Discovery, la supervision basée sur DCGM et les composants associés. Le guide d’installation officiel souligne la nécessité d’assurer la cohérence du système d’exploitation des nœuds lorsque l’Operator gère les pilotes, ainsi que les prérequis liés au runtime de conteneur et à la sécurité des espaces de noms. Suivez les instructions d’installation actuelles du GPU Operator plutôt que de copier une version obsolète d’un chart.

Une installation initiale suit ce modèle ; remplacez la version par une version que vous avez validée par rapport à votre cluster et à votre politique de pilotes :

helm install --wait gpu-operator \
  -n gpu-operator --create-namespace \
  oci://nvcr.io/nvidia/cloud-native-charts/gpu-operator \
  --version=<validated-operator-version>

Après l’installation, validez les pods de l’Operator et l’état de ClusterPolicy avant de soumettre la première charge de travail. Le guide de l’Operator montre également comment confirmer que les nœuds signalent une ressource nvidia.com/gpu allouable.

3. Rendez l’ordonnancement explicite

Commencez par demander un GPU complet exclusif, sauf si vous avez délibérément conçu votre système pour un mode de partage :

resources:
  limits:
    nvidia.com/gpu: 1

Utilisez un libellé de pool de nœuds géré par la plateforme ou un sélecteur cloud pour cibler des nœuds H200 vérifiés ; ne codez pas en dur un libellé de produit issu d’un cluster d’exemple. Kubernetes documente la planification des GPU au moyen de plugins de périphériques et de ressources étendues, y compris le modèle de limite de ressources ci-dessus. Consultez la documentation Kubernetes sur la planification des GPU pour connaître le contrat actuel.

Si vous activez MIG, drainez ou cordonnez d’abord les nœuds concernés. NVIDIA indique que la modification du mode ou de la géométrie MIG exige qu’aucune charge utilisateur ne s’exécute sur les GPU et peut nécessiter un redémarrage dans certains environnements cloud. Examinez la procédure MIG du GPU Operator avant de considérer les changements de partition comme une opération en ligne.

4. Validez une charge de travail simple, puis votre charge de travail réelle

Exécutez trois contrôles dans l’ordre :

1. Contrôle de plateforme : le pilote et CUDA se chargent ; l’ordonnanceur détecte le nombre attendu de GPU ; le conteneur peut créer un contexte CUDA.
2. Contrôle de l’interconnexion : la topologie correspond à la conception prévue ; les runtimes multi-GPU s’initialisent et terminent un test collectif représentatif.
3. Contrôle applicatif : une relecture de prompts représentatifs, de tailles de lots, de longueurs de contexte, de schémas de checkpoint ou d’entrées de simulation atteint la cible requise de latence, de débit et d’erreurs.

Le troisième contrôle est celui qui détermine la décision. Un benchmark générique peut vous indiquer que le GPU fonctionne ; il ne peut pas vous dire si votre distribution de trafic, votre serveur de modèles et votre politique de cache fonctionnent.

Validez les performances avant le passage à l’échelle

Construisez des tests d’acceptation autour du goulot d’étranglement attendu, puis examinez le résultat susceptible d’invalider cette hypothèse.

NVIDIA DCGM distingue la surveillance passive de l’état de santé des diagnostics actifs. Ses workflows de diagnostic peuvent tester les chemins de déploiement, de mémoire, PCIe, NVLink, de calcul, d’alimentation, thermiques et de communication, mais ils consomment des ressources et peuvent entrer en conflit avec les charges de production. Drainez les nœuds ou planifiez une fenêtre de maintenance avant d’exécuter un diagnostic invasif. Utilisez les instructions de diagnostic actuelles de DCGM pour sélectionner le niveau de test approprié.

Pour les services LLM, suivez à la fois les signaux applicatifs et d’infrastructure :

• temps jusqu’au premier jeton p50/p95 et latence inter-jetons
• jetons de sortie acceptés par seconde et requêtes terminées par seconde
• profondeur de file d’attente, annulations, nouvelles tentatives et taux d’erreur
• mémoire GPU allouée par rapport à réservée, utilisation du GPU, puissance et température
• comportement des accès au cache/des déchargements et échecs liés au cache
• saturation du CPU hôte, pression sur la RAM, E/S de modèle/checkpoint et latence réseau

Si une métrique s’améliore tandis qu’une autre se dégrade, n’effectuez pas encore de montée en charge. Un débit de jetons plus élevé avec une latence p95 ou des nouvelles tentatives en hausse peut constituer une régression pour le service destiné aux clients.

Optimisez le coût par travail terminé, et non par temps GPU horaire

Les tarifs des GPU H200 dans le cloud varient selon la région, la durée de réservation, la configuration de l’hôte et l’offre disponible ; un tableau de prix statique devient donc rapidement obsolète. Utilisez plutôt une unité de charge de travail qui met en évidence le temps d’inactivité et le travail échoué :

fully loaded hourly cost = accelerator + attached CPU/RAM + storage + network + licenses + operating overhead

cost per completed request = fully loaded hourly cost / completed requests per hour

cost per million accepted output tokens = fully loaded hourly cost / accepted output tokens per hour × 1,000,000

Calculez ce coût pour le mix de trafic que vous prévoyez de lancer, et non pour une démonstration de débit maximal. Incluez la capacité réservée au basculement, au chargement des modèles, aux checkpoints et à la maintenance. Pour un modèle plus détaillé, consultez Coût par million de jetons d’un LLM auto-hébergé.

Il existe également une question de périmètre : devez-vous exploiter le runtime, ou avez-vous besoin d’un accès fiable aux sorties du modèle ? Si vous avez besoin de noyaux personnalisés, d’un runtime spécifique, d’une localité des données dédiée ou d’expérimentations matérielles contrôlées, un pilote de GPU H200 dans le cloud peut se justifier. Si vous avez principalement besoin d’une API de modèle, comparez la charge opérationnelle à l’option API avant de vous engager dans l’infrastructure. Le guide de déploiement de serveur GPU et le guide de cluster GPU Kubernetes peuvent aider à expliciter cette limite.

Checklist de déploiement du GPU H200

Avant de considérer un déploiement H200 comme prêt, vérifiez tous les éléments suivants :

• [ ] Facteur de forme H200 exact, nombre de GPU et topologie consignés
• [ ] Budget mémoire testé au contexte p95 et à la concurrence attendue
• [ ] Compatibilité du pilote, de CUDA, du framework et de l’image de conteneur validée
• [ ] État de santé de GPU Operator/device plugin confirmé lorsque Kubernetes est utilisé
• [ ] Le planificateur expose la capacité nvidia.com/gpu attendue
• [ ] Le test de collectif multi-GPU réussit sur la topologie de production
• [ ] Le test de charge représentatif atteint les objectifs de TTFT, de latence, de débit et d’erreurs
• [ ] La santé DCGM et des diagnostics adaptés aux fenêtres de maintenance font partie du runbook
• [ ] Les chemins de stockage, de réseau, de chargement de modèle, de checkpoint et de redémarrage sont mesurés
• [ ] Le coût est calculé par unité utile terminée, y compris la capacité inactive et de reprise

Questions fréquentes

Quelle quantité de mémoire possède un GPU H200 ?

NVIDIA indique 141 Go de mémoire HBM3e et 4,8 To/s de bande passante mémoire pour les H200 SXM et H200 NVL. Confirmez le SKU exact et la configuration du système auprès du fournisseur, car le facteur de forme de la carte et l’interconnexion diffèrent. Les spécifications H200 de NVIDIA sont la source des chiffres utilisés dans ce guide.

Un GPU H200 est-il meilleur qu’un H100 pour l’inférence de LLM ?

Cela peut être le cas, surtout lorsque la capacité mémoire ou la bande passante mémoire limite la charge de travail. La réponse pratique dépend de la précision du modèle, de la longueur de contexte, du comportement du cache KV, de la concurrence, du runtime de serving et de la topologie du système. Comparez la charge de travail avec une trace représentative ; ne considérez pas un benchmark fournisseur comme un substitut au SLO de votre service. Consultez la comparaison H200 vs. H100 pour le cadre de décision matériel.

Dois-je choisir H200 SXM ou H200 NVL ?

Choisissez en partant de la topologie. Le H200 SXM convient aux configurations multi-GPU étroitement couplées de type HGX. Le H200 NVL est une option PCIe refroidie par air, avec des configurations de pont NVLink à 2 ou 4 voies. Vérifiez la topologie, l’hôte et le modèle de communication de la charge de travail plutôt que de choisir uniquement en fonction de la mémoire.

Le GPU H200 prend-il en charge MIG ?

NVIDIA indique jusqu’à sept instances MIG pour H200 SXM et H200 NVL, avec des tailles de mémoire par instance indiquées différentes. Utilisez MIG lorsque vous avez besoin d’une isolation de la mémoire et des pannes garantie par le matériel. Ne remplacez pas cette approche par le partage temporel lorsque ces propriétés d’isolation sont requises.

De combien de GPU H200 ai-je besoin ?

Commencez par la plus petite configuration qui réussit un test représentatif de mémoire, de latence, de débit et de reprise. Ajoutez des GPU uniquement lorsque le budget mémoire, le nombre de réplicas ou le plan de parallélisme validé l’exigent. Un plus grand nombre de GPU sans charge de travail tenant compte de l’interconnexion peut augmenter le coût et la surface opérationnelle sans améliorer le résultat destiné aux clients.

Commencez par un pilote GPU H200 validé

Le bon déploiement de GPU H200 est un système mesuré : la mémoire de l’accélérateur, la topologie, le planificateur, le runtime, le chemin des données, l’observabilité et l’économie de la charge de travail doivent tous être cohérents. Commencez par un pilote instrumenté, rejouez un trafic réaliste, documentez les modes de défaillance et n’effectuez une montée en charge qu’après que les preuves justifient l’étape de capacité suivante.

Sources

• Spécifications du GPU NVIDIA H200
• Guide d’installation de NVIDIA GPU Operator
• Documentation sur la planification des GPU dans Kubernetes
• Documentation sur les diagnostics NVIDIA DCGM