Polydesk-logotype
Polydesk.ai — Header

NVIDIA H200

Le NVIDIA H200 est un GPU de data center basé sur l’architecture Hopper qui se distingue du H100 par une mémoire HBM3e de 141 Go à 4,8 TB/s de bande passante, soit 76% de capacité en plus et 43% de bande passante en plus que le H100.

Le H200 utilise le même die GPU que le H100. Les performances de calcul (TFLOPS en FP8, BF16, FP32) sont identiques. Ce qui change, c’est la mémoire. Et en matière d’inférence de LLM, la mémoire est tout : un modèle de 70 milliards de paramètres en FP16 pèse environ 140 Go, ce qui dépasse les 80 Go du H100 mais tient confortablement dans les 141 Go du H200. Cette différence élimine la nécessité de distribuer le modèle sur plusieurs GPU, ce qui simplifie le déploiement et réduit les coûts. NVIDIA présente le H200 comme le premier GPU équipé de mémoire HBM3e, et il est devenu le choix de référence pour l’inférence de gros LLM à grande échelle.

NVIDIA H200 en bref
Architecture
Hopper (même die que H100)
Année
2024
VRAM
141 Go HBM3e (6 stacks de 24 Go)
Bande passante mémoire
4,8 TB/s
CUDA Cores
16 896
Tensor Cores
528 (4ème gén., FP8/BF16/TF32/INT8)
FP8 Tensor
~3 958 TFLOPS (identique H100)
TDP
700 W (SXM) / 600 W (NVL PCIe)
NVLink
900 GB/s (SXM)
Prix achat
$30 000 à $40 000 (mars 2026)
Prix cloud
~$2,50 à $10,60/GPU-heure
Variantes
H200 SXM, H200 NVL (PCIe Gen5)

La mémoire HBM3e : le changement qui compte

De la HBM3 à la HBM3e

Le H100 utilise 5 stacks de HBM3 de 16 Go chacun, pour un total de 80 Go à 3,35 TB/s. Le H200 utilise 6 stacks de HBM3e de 24 Go chacun, pour un total de 141 Go à 4,8 TB/s. Le « e » de HBM3e signifie « extended » : c’est une version améliorée de la HBM3 avec des puces mémoire de plus grande capacité et une fréquence de fonctionnement plus élevée, fabriquées par Samsung et SK Hynix.

Cette augmentation de mémoire a des conséquences directes et mesurables sur les workloads IA :

WorkloadH100 (80 Go)H200 (141 Go)Impact
Llama 3 70B FP16 (~140 Go)2 GPU minimum1 seul GPUSimplicité, coût réduit
Llama 3 70B INT8 (~70 Go)1 GPU (serré)1 GPU (confortable)Plus de marge pour KV-cache
Modèle 100B+ en INT4Possible mais limitéConfortableBatch sizes plus grands
Inférence long-context (128K+)KV-cache limitéKV-cache spacieuxJusqu’à 3,4× plus de throughput
Multi-model serving MIG7 instances × ~11 Go7 instances × ~20 GoModèles plus gros par instance
Pourquoi 141 Go et pas 128 ou 192 ? La capacité de 141 Go est dictée par la technologie de packaging. Le H200 utilise 6 stacks HBM3e de 24 Go chacun (6 × 24 = 144 Go bruts). Après réservation de mémoire pour l’ECC et le management GPU, il reste 141 Go utilisables. Le B200 (Blackwell) utilise 8 stacks de 24 Go pour atteindre 192 Go, et le futur Rubin est annoncé avec de la HBM4 à 288 Go.

Bande passante : le nerf de l’inférence

Pour l’inférence de LLM, la vitesse de génération de tokens dépend directement de la bande passante mémoire. Chaque token nécessite la lecture de tous les poids du modèle depuis la HBM. Avec 4,8 TB/s (vs 3,35 TB/s pour le H100), le H200 peut lire les poids du modèle 43% plus vite, ce qui se traduit directement en 40 à 80% de tokens par seconde en plus pour les workloads memory-bound (ce qui est le cas de la plupart des inférences de LLM avec un petit batch size).

Pour les longs contextes (prompts de 32K, 64K ou 128K tokens), le KV-cache (qui stocke les résultats intermédiaires de l’attention) peut consommer des dizaines de Go de mémoire. Le H200, avec ses 141 Go, offre beaucoup plus de marge pour ces workloads, évitant le recours à des techniques de compression du KV-cache qui dégradent les performances. NVIDIA rapporte des gains allant jusqu’à 3,4× pour le traitement de longs contextes par rapport au H100.

Spécifications comparées

SpecH100 SXMH200 SXMDifférence
VRAM80 Go HBM3141 Go HBM3e+76%
Bande passante3,35 TB/s4,8 TB/s+43%
FP8 Tensor3 958 TFLOPS3 958 TFLOPSIdentique
FP16/BF16 Tensor1 979 TFLOPS1 979 TFLOPSIdentique
CUDA Cores16 89616 896Identique
NVLink900 GB/s900 GB/sIdentique
TDP700 W700 WIdentique
MIG7 instances7 instancesInstances plus grandes
Prix cloud~$2,50-$3,50/h~$3,50-$5,50/h~15-50% plus cher

Le message est clair : si votre workload est compute-bound (entraînement de gros modèles avec de grands batch sizes), le H200 n’apporte rien par rapport au H100 en termes de FLOPS. Si votre workload est memory-bound (inférence de LLM, longs contextes, modèles qui ne tiennent pas dans 80 Go), le H200 est un saut qualitatif significatif.

Variantes : SXM vs NVL

Le H200 existe en deux formats. La version SXM (700 W) est le module haute performance pour serveurs HGX, avec NVLink à 900 GB/s et refroidissement liquide. C’est la version pour les clusters de training et d’inférence à grande échelle. Un système HGX H200 8-GPU fournit plus de 32 pétaFLOPS en FP8 et 1,1 To de HBM3e agrégée.

La version NVL (PCIe Gen5, 600 W) est plus accessible et compatible avec des serveurs standard. Elle utilise des ponts NVLink 2 ou 4 voies (plutôt que le NVSwitch complet du SXM) et supporte le refroidissement par air. Le H200 NVL est présenté comme un remplacement drop-in du A100 et du H100 dans les infrastructures existantes.

Prix et marché en mars 2026

Le H200 se négocie entre $30 000 et $40 000 à l’achat unitaire, soit environ 15 à 20% de plus que le H100. Les systèmes 8-GPU (HGX H200 ou équivalent OEM) atteignent $300 000 à $500 000 selon la configuration complète. Les délais de livraison sont de 4 à 8 semaines pour les commandes standard, mais peuvent s’allonger significativement en raison de la tension sur l’approvisionnement en HBM3e et de la forte demande chinoise (plus de 2 millions d’unités commandées pour livraison en 2026 par les géants tech chinois).

En cloud, les tarifs varient fortement selon le fournisseur. Les GPU clouds spécialisés proposent le H200 à partir de $2,50-$3,80/GPU-heure, tandis que les hyperscalers (AWS p5e, Azure) facturent $5 à $10+/GPU-heure (souvent en instances 8-GPU uniquement, ce qui ne convient pas au prototypage).

H200 vs H100 : quand le surcoût vaut le coup Le H200 vaut le surcoût de 15 à 50% (selon fournisseur cloud) si vos modèles dépassent 80 Go (70B+ en FP16, 140B+ en INT8), si vous servez des modèles avec de longs contextes (32K+ tokens), si vous maximisez le throughput d’inférence et que la bande passante mémoire est votre facteur limitant, ou si vous voulez simplifier le déploiement en évitant le multi-GPU pour des modèles qui tiendraient sur un seul H200 mais pas sur un seul H100.

Cas d’usage en 2026

Inférence de LLM 70B+ sur un seul GPU : C’est le cas d’usage phare du H200. Un modèle 70B en FP16 (~140 Go) tient dans un seul H200, éliminant la complexité du tensor parallelism multi-GPU. Pour les entreprises qui déploient des modèles 70B en production, cela se traduit par une infrastructure plus simple, un coût opérationnel réduit, et une latence plus faible (pas de communication inter-GPU).

Inférence long-context : Les applications de RAG, d’analyse de documents longs, et de conversation multi-tour avec historique volumineux bénéficient directement de la mémoire supplémentaire du H200 pour stocker un KV-cache plus grand.

Multi-model serving haute capacité : Avec MIG, chaque instance dispose d’environ 20 Go de HBM (vs ~11 Go sur H100), ce qui permet de servir des modèles plus gros par partition ou de gérer des KV-caches plus volumineux par instance.

Fine-tuning de modèles massifs : Le fine-tuning complet d’un modèle 70B en BF16 nécessite environ 280 Go de mémoire (modèle + optimiseur + gradients). Sur H100, cela nécessite 4+ GPU. Le H200 réduit ce besoin, bien que le fine-tuning complet d’un 70B nécessite encore du multi-GPU même avec 141 Go.

HPC et simulation scientifique : Les simulations mémoire-intensives (dynamique moléculaire, modélisation climatique) bénéficient directement de la bande passante accrue.

H200 vs B200 (Blackwell)

Le B200 est le vrai successeur du H100/H200, avec un nouveau die GPU (architecture Blackwell), 192 Go de HBM3e, 8 TB/s de bande passante, et des performances de calcul ~2,5× supérieures en FP8. Le H200 est un upgrade mémoire incrémental du H100, pas un saut générationnel.

Pour les organisations qui ont besoin du maximum de performance en 2026, le B200 est le meilleur choix (quand il est disponible). Pour celles qui veulent plus de mémoire que le H100 sans attendre ou payer le premium Blackwell, le H200 est le compromis pragmatique. Les prix cloud du H200 devraient baisser de 15% environ au second semestre 2026 à mesure que l’offre Blackwell se normalise.

H200 vs AMD MI300X

L’AMD Instinct MI300X est le concurrent direct du H200, avec 192 Go de HBM2e (vs 141 Go HBM3e sur le H200) et une bande passante mémoire comparable. Sur le papier, le MI300X offre plus de mémoire. En pratique, le H200 conserve plusieurs avantages.

Le premier est la mémoire plus rapide : la HBM3e du H200 est plus rapide en bande passante par Go que la HBM2e du MI300X, ce qui se traduit par de meilleures performances d’inférence à taille de modèle égale. Le second est l’écosystème CUDA : vLLM, TensorRT-LLM, et toute la pile logicielle NVIDIA sont immédiatement disponibles et optimisés sur le H200. Le MI300X nécessite ROCm, dont le support est fonctionnel mais moins mature. Le troisième est le Transformer Engine avec FP8 dynamique, absent du MI300X sous cette forme exacte.

Le MI300X reste un choix valable si la capacité mémoire brute est votre priorité absolue (192 Go vs 141 Go) ou si le coût par Go de VRAM est le critère déterminant. Pour la majorité des déploiements, le H200 offre une expérience plus fluide grâce à la maturité de l’écosystème NVIDIA.

Limites

Le H200 est pleinement supporté par l’écosystème logiciel NVIDIA. CUDA 12.3+ reconnaît le H200 de manière transparente (même Compute Capability 9.0 que le H100). PyTorch, TensorFlow, JAX, vLLM, TensorRT-LLM, et tous les frameworks optimisés pour le H100 fonctionnent sur le H200 sans modification. C’est l’avantage d’un upgrade purement mémoire : aucune adaptation logicielle n’est nécessaire. Google Cloud propose le H200 via les VMs A3 Ultra, tandis qu’AWS le propose en instances p5e. La plupart des GPU clouds spécialisés (CoreWeave, Lambda, Jarvislabs, RunPod) ont ajouté le H200 à leur catalogue début 2025.

Adoption

Le H200 a été adopté rapidement par les hyperscalers et les entreprises IA pour les workloads où la mémoire du H100 était insuffisante. Les benchmarks NVIDIA montrent des gains d’inférence allant jusqu’à 1,8× pour Llama 2 70B par rapport au H100, principalement grâce à la bande passante mémoire accrue. Pour les entreprises qui servaient déjà des modèles 70B sur des paires de H100 en tensor parallelism, la migration vers un seul H200 par modèle a permis de diviser les coûts d’inférence tout en améliorant les latences.

Le H200 NVL (version PCIe) a particulièrement séduit les entreprises qui souhaitaient upgrader des infrastructures H100/A100 PCIe existantes sans reconfigurer leurs racks : le H200 NVL est un remplacement drop-in dans les serveurs compatibles PCIe Gen5.

Limites détaillées

Le H200 partage les mêmes limitations de compute que le H100 puisque c’est le même die GPU. Si votre workload est limité par les FLOPS (entraînement compute-bound), le H200 ne vous apportera rien de plus qu’un H100.

Le prix premium de 15 à 50% par rapport au H100 n’est justifié que si la mémoire supplémentaire est effectivement utilisée. Pour un modèle 7B ou 13B, la VRAM du H100 est largement suffisante et le surcoût H200 est du gaspillage.

La disponibilité reste tendue en mars 2026, en partie à cause des commandes massives chinoises et des pénuries de HBM3e. Les délais de livraison peuvent s’étendre au-delà de 2 mois pour les acheteurs directs.

Enfin, le H200 est un produit de transition dans la roadmap NVIDIA. Le B200 le dépasse sur tous les plans (mémoire, bande passante, compute). Les investissements long terme devraient cibler Blackwell plutôt que Hopper. En résumé, le H200 est le meilleur GPU pour l’inférence de gros LLM disponible immédiatement, mais il sera supplanté par Blackwell pour les nouveaux déploiements au second semestre 2026. Sa valeur est maximale pour les workloads où la mémoire est le facteur critique et où les 80 Go du H100 ne suffisent plus.


Questions fréquentes sur le NVIDIA H200

Quelle est la différence entre le H100 et le H200 ?

Le même GPU (die Hopper), mais avec une mémoire différente. Le H100 a 80 Go de HBM3 à 3,35 TB/s. Le H200 a 141 Go de HBM3e à 4,8 TB/s. Les performances de calcul (TFLOPS, CUDA Cores, Tensor Cores) sont identiques. Le H200 excelle pour les workloads memory-bound (inférence de gros LLM, longs contextes), tandis que le H100 reste tout aussi performant pour les workloads compute-bound.

Le H200 peut-il exécuter un modèle 70B sans quantification ?

Oui, c’est son atout principal. Un modèle 70B en FP16 pèse environ 140 Go, ce qui tient (de justesse) dans les 141 Go du H200. Sur un H100 (80 Go), ce modèle nécessiterait 2 GPU en tensor parallelism. Le H200 simplifie ce déploiement en un seul GPU, ce qui réduit la latence et le coût opérationnel.

Faut-il choisir le H200 ou attendre le B200 ?

Si vous avez besoin de mémoire maintenant (modèles 70B+ en production, longs contextes), le H200 est disponible et éprouvé. Si vous pouvez attendre et que votre besoin est autant en compute qu’en mémoire, le B200 offre 192 Go HBM3e et ~2,5× plus de FLOPS. La plupart des équipes qui ont des workloads H100-compatibles n’ont pas besoin de passer au H200 : l’upgrade vers Blackwell directement est souvent plus judicieux.

Le H200 est-il un bon investissement long terme ?

Comme produit de transition Hopper → Blackwell, le H200 perdra de la valeur plus vite que le H100 (qui a un parc installé massif et stable). Pour l’achat, le H200 est un choix risqué à long terme. Pour la location cloud, c’est un excellent choix immédiat pour les workloads qui nécessitent plus de 80 Go de VRAM. Les prix cloud devraient baisser de 15% ou plus d’ici fin 2026.

Combien de modèles peut-on servir simultanément sur un H200 ?

Avec MIG activé, un H200 se partitionne en 7 instances de ~20 Go chacune. Chaque instance peut servir un modèle 7B quantifié en INT8 (~7 Go) avec de la marge pour le KV-cache, ou un modèle 13B quantifié en INT4 (~7 Go). En pratique, 5 à 7 modèles de petite taille ou 2 à 3 modèles de taille moyenne peuvent fonctionner simultanément avec des performances isolées et garanties.

Polydesk.ai — Footer