NVIDIA H200 vs H100 : capacité mémoire, débit et coût

Si vous comparez H100 vs H200, la version courte est simple : le H200 est le meilleur choix lorsque la charge de travail est limitée par la mémoire, à contexte long, ou difficile à faire tenir sur des H100 de 80 Go. Le H100 reste la base pratique lorsque la capacité est moins chère, déjà disponible, ou que la tâche est suffisamment limitée par le calcul pour que le HBM3e supplémentaire ne réduise pas le temps d’exécution.

L’astuce, c’est le coût. Le H200 n’est pas automatiquement moins cher simplement parce qu’il dispose de plus de mémoire. Il l’emporte lorsque le pool mémoire de 141 Go, la bande passante mémoire de 4,8 To/s, ou une taille de lot plus élevée vous permettent de terminer la tâche avec moins de GPU, moins de réplicas, moins de compromis de quantification, ou moins d’exécutions ratées.

H100 vs H200 : décision rapide

Choisissez H200 lorsque :

• Votre modèle, la longueur du contexte, le cache KV ou la taille de lot visée sont proches de la limite des H100 de 80 Go.
• Vous servez une inférence LLM où la bande passante mémoire et la taille de lot comptent plus que le pic brut des tensor cores.
• Vous voulez moins de partitions en parallélisme de tenseurs pour une inférence de classe 70B, du RAG avec de longues invites, ou un service à forte concurrence.
• La prime de location du H200 est inférieure aux économies réalisées grâce à moins de GPU, un débit accepté plus élevé, ou des opérations plus simples.

Choisissez H100 lorsque :

• La charge de travail tient déjà proprement dans 80 Go, avec de la marge pour les activations, le cache KV, l’état de l’optimiseur ou la surcharge de service.
• Vous optimisez la capacité disponible, des images matures, un comportement de cluster connu, ou un prix horaire plus bas.
• Le goulot d’étranglement est le prétraitement CPU, le stockage, le réseau, la mise en file d’attente, la surcharge logicielle ou la qualité du modèle plutôt que la mémoire GPU.
• Vous pouvez obtenir du H100 SXM ou NVL à un prix effectif bien meilleur que celui du H200.

Pour la plupart des équipes IA, le premier test n’est pas un classement de benchmark. C’est cette question : le H200 réduit-il suffisamment le nombre de GPU, le compromis de précision ou le temps d’attente en file pour surpasser la disponibilité généralement plus large du H100 ?

Spécifications NVIDIA H200 vs H100 qui comptent

NVIDIA présente le H200 comme une mise à niveau de la génération Hopper axée sur une mémoire plus grande et plus rapide. La page produit du H200 indique 141 Go de mémoire HBM3e et 4,8 To/s de bande passante mémoire. La page H100 de NVIDIA indique que le H100 SXM dispose de 80 Go de HBM3 et de 3,35 To/s de bande passante mémoire, et que le H100 NVL dispose de 94 Go et de 3,9 To/s.

Ces différences de mémoire sont au cœur de la comparaison nvidia h200 vs h100. Le H200 dispose d’environ 76 % de mémoire en plus que le H100 SXM et d’environ 43 % de mémoire en plus que le H100 NVL. Sa bande passante est d’environ 43 % supérieure à celle du H100 SXM et d’environ 23 % supérieure à celle du H100 NVL.

Cela ne signifie pas que chaque tâche est 23 à 76 % plus rapide. Cela signifie que le sous-système mémoire donne au H200 davantage de marge pour conserver de grands ensembles de travail sur le GPU et alimenter les cœurs de calcul. Le gain de performance dépend de la taille du modèle, de la longueur du contexte, de la précision, du framework de service, de la stratégie de lot, de l’interconnexion et du fait que la charge de travail soit réellement limitée par la mémoire.

Mémoire H200 vs H100 : pourquoi 141 Go changent le service LLM

L’expression h200 vs h100 memory apparaît généralement lorsqu’une équipe essaie d’éviter un compromis désagréable :

• une quantification agressive qui nuit à la qualité des sorties,
• davantage de partitions en parallélisme de tenseurs que l’équipe ne souhaite en exploiter,
• des lots plus petits qui gaspillent la capacité de service,
• des fenêtres de contexte plus courtes que ce dont le produit a besoin,
• ou des tâches échouées lorsque les vraies invites sont plus grandes que les invites de benchmark.

Le profil 80 Go du H100 reste solide pour de nombreuses tâches d’inférence et de fine-tuning. Mais 80 Go disparaissent rapidement lorsqu’on ajoute les poids du modèle, le cache KV, la surcharge du framework, les tampons de décodage spéculatif, les adaptateurs, les embeddings et les requêtes simultanées.

La mémoire de 141 Go du H200 offre davantage d’options aux équipes d’infrastructure. Un modèle qui ne tient que sur plusieurs H100 peut tenir avec moins de H200. Un niveau de service qui doit garder un contexte court sur H100 peut prendre en charge des requêtes plus longues sur H200. Une tâche d’entraînement ou de fine-tuning qui bascule vers des micro-lots plus petits sur H100 peut utiliser des réglages de lot plus efficaces sur H200.

C’est pourquoi la décision h100 vs h200 doit être modélisée autour du travail réellement terminé, et non du seul prix horaire du GPU.

Comparaison des performances NVIDIA H200 vs H100

Pour une nvidia h200 vs h100 performance comparison, distinguez trois cas.

1. Inférence LLM limitée par la mémoire

C’est le cas le plus favorable au H200. NVIDIA indique que la plus grande mémoire HBM3e du H200 et sa bande passante de 4,8 To/s sont conçues pour accélérer les charges de travail d’IA générative et de LLM, et sa page montre des exemples de débit d’inférence supérieurs pour Llama 2 et des modèles de type GPT par rapport au H100, dans des réglages spécifiques de lot et de séquence.

Utilisez d’abord le H200 pour :

• le service de modèles de classe 70B,
• le RAG à contexte long,
• les charges de décodage à lot élevé,
• les routes de service avec une forte pression sur le cache KV,
• et les charges de travail produit où les requêtes échouées ou dégradées sont coûteuses.

Ne copiez pas le multiplicateur d’exemple de NVIDIA dans votre propre prévision sans test. Le gain dépend de la longueur de l’invite, de la longueur de la sortie, de la taille du lot, de la quantification, des réglages du moteur et du fait que la base H100 était déjà optimisée.

2. Entraînement et fine-tuning

Le H100 reste un excellent choix par défaut pour les clusters d'entraînement, car il est largement déployé, bien pris en charge et disponible dans des configurations cloud managées et de clusters dédiés matures. Le H200 peut toutefois encore être utile lorsque la pression mémoire limite la taille du micro-lot, la longueur de séquence, les विकल्प de checkpointing des activations ou la stratégie d'optimiseur.

Pour l'entraînement complet, la décision dépend souvent moins d'un GPU que de la structure du cluster :

• combien de GPU par nœud,
• topologie NVLink/NVSwitch,
• réseau inter-nœuds,
• débit du stockage,
• temps de checkpointing,
• maturité du framework,
• et disponibilité des réservations.

Si une exécution d'entraînement s'adapte déjà bien sur H100 et ne rencontre pas de pression mémoire, le H200 peut ne pas justifier sa prime. Si le H200 vous permet d'éviter du parallélisme supplémentaire, d'éviter la recomputation ou de réduire les exécutions échouées, l'économie peut s'inverser.

3. Tâches limitées par le calcul ou le pipeline

Certaines tâches ne se soucient pas beaucoup de la mémoire supplémentaire. Si le prétraitement, le chargement des données, les transformations CPU, le stockage objet, le transfert réseau ou l'orchestration de l'application constituent le goulot d'étranglement, le H200 peut rester inactif, tout comme le H100.

Avant de payer pour un H200, exécutez un profil :

• utilisation du GPU,
• mémoire allouée et réservée,
• utilisation de la bande passante HBM,
• tokens par seconde,
• requêtes acceptées par minute,
• temps d'attente en file,
• taux d'échec/de nouvelle tentative,
• et coût par sortie acceptée.

Si le graphe mémoire est plat et que le pipeline attend ailleurs, le H100 est généralement l'achat le plus prudent.

Coût : comparer H200 et H100 par charge de travail terminée

Les prix de location des GPU évoluent rapidement, et la disponibilité des places de marché change selon la région et le moment. Considérez ce qui suit comme des instantanés de page source vérifiés le 12 octobre 2026, et non comme des promesses de prix permanentes.

La page de tarification de RunPod indiquait le H200 à 3,59 $/h sur Community Cloud et à 4,59 $/h sur Secure Cloud. La même page indiquait le H100 PCIe à 1,99 $/h en community et à 2,89 $/h en secure, le H100 SXM à 2,69 $/h en community et à 3,49 $/h en secure, et le H100 NVL à 2,59 $/h en community et à 3,19 $/h en secure.

La page de tarification de Lambda indiquait 1x H100 SXM à 4,29 $/GPU/h et 1x H100 PCIe à 3,29 $/GPU/h, avec des exemples de cluster H100 SXM à coût par GPU inférieur pour des nombres de nœuds plus élevés. Le tableau public de Lambda n'exposait pas de ligne H200 à la demande comparable dans l'instantané de page utilisé pour cet article.

La page de la famille P5 d'AWS est utile pour le contexte de déploiement : elle présente P5, P5e et P5en comme des familles d'instances NVIDIA H100 et H200 pour l'entraînement ML à grande échelle, l'inférence et le HPC, avec P5e exposant 8 GPU H200 et 1 128 Go de HBM3e par instance p5e.48xlarge. Pour les travaux budgétaires, vérifiez la région AWS exacte, l'option d'achat et le plan de support avant d'utiliser un chiffre dans un modèle.

La feuille de calcul pratique :

coût de la charge de travail terminée =
  prix horaire du GPU
  x nombre de GPU
  x heures d'horloge
  + stockage
  + sortie réseau
  + temps d'inactivité/attente en file
  + coût des exécutions échouées et des nouvelles tentatives
  + temps d'ingénierie pour le sharding, la quantification et le débogage

Le H200 peut coûter plus cher par heure et tout de même l'emporter s'il réduit le nombre de GPU, diminue la complexité du sharding, augmente le débit accepté ou évite une défaillance liée à la mémoire. Le H100 peut être moins cher lorsque la tâche s'adapte proprement et que la prime du H200 ne modifie pas le calcul du coût de la charge de travail terminée.

Pour une feuille de calcul des coûts plus complète, utilisez le guide Flatkey associé sur les prix de location des GPU.

Recommandation workload par workload

Un plan de test simple H100 vs H200

Exécutez la même charge de travail réelle sur les deux types de GPU avant de vous engager dans un cluster réservé. Les benchmarks synthétiques sont utiles pour se repérer, mais les décisions d'achat doivent utiliser des invites, des paramètres de lot et des règles d'échec représentatifs de la production.

1. Définissez le résultat cible. Utilisez des tokens par seconde, des tâches terminées par jour, le coût par réponse acceptée, le coût par étape d’entraînement ou le temps de passage en horloge réelle pour atteindre la qualité visée.
2. Utilisez des entrées de taille production. Incluez la longueur réelle du prompt, le contexte de recherche, la longueur de sortie, la variation des lots et la concurrence.
3. Maintenez la qualité du modèle constante. Ne laissez pas un GPU utiliser une quantification de qualité inférieure simplement pour tenir dans la mémoire.
4. Mesurez le nombre de GPU et l’utilisation. Un seul H200 peut battre plusieurs H100 pour certains niveaux de service ; un H100 peu coûteux peut battre un H200 sous-utilisé pour des modèles plus petits.
5. Suivez les reprises et les échecs mémoire. Les reprises après manque de mémoire, les lots plus petits et le découpage d’urgence ont un coût réel.
6. Incluez le temps d’inactivité. Un H100 moins cher qui attend dans une file pendant des heures peut perdre face à un H200 disponible.
7. Répétez sur plusieurs fenêtres temporelles. Les prix du marché et la capacité peuvent varier entre les pics en semaine et les heures creuses.

Les recommandations de coût plus larges de Flatkey sont les mêmes pour les GPU et les API de modèles : comparez le chemin qui produit le résultat accepté, et pas seulement le prix unitaire affiché. La même idée apparaît dans AI model pricing comparison, AI API pricing comparison, et how to compare AI model prices.

Quand une API de modèle est meilleure que l’un ou l’autre GPU

La décision H200 vs H100 suppose que vous devez gérer les GPU directement. Ce n’est pas toujours vrai.

Utilisez une API de modèle hébergée ou un routeur au lieu de louer des GPU lorsque :

• le trafic est irrégulier,
• le choix du modèle change souvent,
• vous avez besoin de plusieurs fournisseurs plutôt que d’un seul modèle à poids ouverts fixe,
• le temps d’exploitation compte plus que l’utilisation absolue du GPU,
• ou vous avez besoin de journaux d’utilisation par requête, de contrôles budgétaires et de basculement.

Flatkey est conçu pour ce côté de la décision : une clé, un solde, une facture, des points de terminaison officiels de modèles, des journaux d’utilisation au niveau des requêtes et un routage entre fournisseurs de modèles. Pour les équipes qui n’ont besoin que de la sortie de modèles de pointe ou de modèles ouverts hébergés, une API de modèle peut éviter les dépenses GPU inutilisées et la surcharge opérationnelle. Pour les équipes qui servent des poids propriétaires avec une charge soutenue, une capacité H100 ou H200 directe peut encore être la bonne couche d’infrastructure.

Recommandation finale

Pour H100 vs H200, achetez ou louez un H200 lorsque la mémoire est le goulot d’étranglement et que le GPU plus grand modifie la forme de la charge de travail. Les meilleurs cas d’usage du H200 sont l’inférence LLM à long contexte, le service de modèles de classe 70B, le HPC gourmand en mémoire, et tout cas où 141 Go de HBM3e vous permettent d’utiliser moins de GPU ou une architecture de service plus simple.

Utilisez un H100 lorsque la charge de travail tient, que la disponibilité compte et que l’écart de prix est réel. Le H100 reste le choix par défaut le plus sûr pour les piles d’entraînement matures, le développement, l’inférence à contexte modéré et les équipes qui connaissent déjà leur profil d’utilisation.

Le critère décisif n’est pas « quel GPU est le plus rapide ». C’est le coût par résultat accepté après prise en compte de l’adéquation mémoire, du débit, du temps d’attente en file, des reprises et de la complexité d’ingénierie.

Foire aux questions

Le H200 est-il plus rapide que le H100 ?

Pour l’inférence LLM limitée par la mémoire et le HPC gourmand en mémoire, le H200 peut être plus rapide car il dispose de 141 Go de mémoire HBM3e et d’une bande passante de 4,8 To/s. Pour les tâches limitées par le calcul ou le pipeline, le gain peut être faible. Testez avec des prompts et des tailles de lots représentatifs de la production.

Le H200 vaut-il le coût supplémentaire ?

Le H200 vaut la prime lorsqu’il réduit le nombre de GPU, évite les échecs liés à la mémoire, améliore le débit accepté ou simplifie le sharding. Si votre modèle tient déjà sur H100 et que la tâche n’est pas limitée par la mémoire, le H100 est généralement plus rentable.

Quelle quantité de mémoire le H200 a-t-il par rapport au H100 ?

NVIDIA indique 141 Go pour le H200. Le H100 SXM est indiqué à 80 Go, tandis que le H100 NVL est indiqué à 94 Go. Cette mémoire supplémentaire est la principale raison pour laquelle les acheteurs comparent la mémoire du H200 vs H100 pour les charges de travail LLM.

Dois-je utiliser un H100 ou un H200 pour Llama 2 70B ?

Le H200 est attrayant pour l’inférence de classe 70B, car le pool de mémoire et la bande passante plus importants peuvent prendre en charge des lots plus grands, un contexte plus long ou moins de shards. Le H100 NVL et le H100 SXM peuvent néanmoins rester de bons choix lorsque la disponibilité et le prix horaire sont meilleurs.

Dois-je louer des GPU ou utiliser des API de modèles ?

Louez des GPU lorsque vous avez une utilisation soutenue, des poids propriétaires ou des exigences de service personnalisées. Utilisez des API de modèles lorsque le trafic est irrégulier, que le choix du fournisseur change souvent, ou lorsque vous avez besoin de routage, de journaux d’utilisation, de factures et de basculement sans exploiter de serveurs GPU.

Sources

• NVIDIA H200 GPU
• NVIDIA H100 Tensor Core GPU
• AWS EC2 P5 instances
• RunPod GPU cloud pricing
• Lambda GPU cloud pricing