12 novembre 2026 · Équipe VRAMfarm

H200 ou H100 : quand 141 Go valent le prix, et quand 80 Go suffisent

Llama 3.3 70B en fp8 se charge sur une H100 avec seulement 4 à 8 Go de reste. Cela laisse de la place pour environ 12 000 à 25 000 tokens de KV cache en 16 bits, partagés entre toutes les conversations que le serveur gère. Sur une H200, le même modèle laisse environ 60 Go, assez pour le contexte complet de 128 000 tokens ou vingt conversations parallèles de 8 000 tokens chacune. Voilà l’argument de la H200 en un exemple : elle a le même calcul que la H100, avec 141 Go de mémoire au lieu de 80 et 4,8 To/s de bande passante au lieu de 3,35. Elle se loue à partir de 5,43 € de l’heure, la H100 à partir de 3,90 €. La mémoire supplémentaire vaut-elle le coup ? Tout dépend si votre tâche manque de mémoire sur la H100, et c’est facile à vérifier.

La même puce, avec plus de mémoire et plus rapide

Les deux cartes font tourner exactement les mêmes logiciels : passer un projet de l’une à l’autre ne demande aucune modification. Le catalogue regroupe plusieurs versions sous chaque nom : la H100 peut être SXM, PCIe (environ 2 To/s, fréquences plus basses) ou la H100 NVL de 94 Go ; la H200 peut être SXM ou la H200 NVL, basée sur le PCIe. Le nom exact de chaque machine s’affiche avant le lancement.

Le tableau a deux conséquences. Tout ce qui est limité par le calcul tourne à la même vitesse sur les deux : l’entraînement d’un modèle qui tient sur les deux, la génération d’images et de vidéos, le traitement du prompt. Tout ce qui est limité par la mémoire tourne jusqu’à 1,4 fois plus vite sur la H200, car 4,8 ÷ 3,35 ≈ 1,43. Il s’agit surtout de la génération de texte, où chaque nouveau token lit tous les poids du modèle.

Quand 80 Go ne suffisent plus

C’est sur la mémoire que les deux cartes diffèrent vraiment. Les estimations ci-dessous reprennent la formule du guide de la VRAM : les poids, plus le KV cache, plus quelques gigaoctets pour l’environnement d’exécution. Pour Llama 3.3 70B, le cache prend environ 0,33 Mo par token en 16 bits, et moitié moins en fp8.

La tendance : la H200 compte pour les modèles 70B en fp8, le long contexte sur n’importe quel grand modèle, et les gros modèles mixture-of-experts. Un modèle mixture-of-experts comme Qwen3 235B-A22B ne calcule qu’avec environ 22B de paramètres par token : il génère donc du texte rapidement, mais ses 235B de paramètres doivent tous résider en mémoire. Sur une seule H200, une version 4 bits compacte tient avec un contexte modéré ; les formats 4 bits plus lourds, non, et la solution est alors une B200 de 192 Go ou deux cartes.

Pourquoi le fp8 plutôt que le 4 bits pour un modèle 70B ? Le fp8 est très proche du modèle d’origine en qualité et tourne vite sur les cœurs tensoriels fp8 de Hopper. Le 4 bits est plus petit et convient très bien au chat, mais perd un peu plus en code, en maths et en raisonnement long. Si le 4 bits suffit pour votre usage, la H100 a la place pour lui et c’est la carte la moins chère (voir la section suivante).

Pour un modèle 70B avec un contexte normal, vous n’avez peut-être besoin d’aucune des deux : un 70B en 4 bits tourne sur une carte de 48 Go avec 8 000 à 12 000 tokens de contexte, pour une fraction du prix.

Vitesse : ce que la bande passante supplémentaire apporte

Pour un seul flux de texte, la H200 est environ 1,3 à 1,4 fois plus rapide : un modèle 70B en fp8 génère environ 25 à 38 tokens par seconde sur une H100 et 35 à 55 sur une H200, selon l’environnement d’exécution et la longueur du contexte.

Pour un serveur avec de nombreux utilisateurs, le gain peut être bien plus grand, mais pour une autre raison. Le traitement par lots permet à la carte de générer des tokens pour de nombreuses conversations avec une seule lecture des poids, et la taille du lot est limitée par la quantité de KV cache qui tient en mémoire. Sur une H100 avec un modèle 70B en fp8, le cache ne contient que quelques conversations à la fois ; sur une H200, il en contient plusieurs fois plus. NVIDIA annonce jusqu’à environ 1,9 fois le débit de la H100 en inférence sur un 70B ; la part que vous en verrez dépend de la mesure dans laquelle votre lot était limité par la mémoire sur la H100.

Pour l’entraînement et la génération d’images, attendez-vous à la même vitesse à quelques pour cent près, sauf si la mémoire supplémentaire change votre configuration. Le fine-tuning complet d’un modèle de 7 à 8B avec AdamW standard demande environ 16 octets par paramètre, soit 112 à 128 Go avant les activations. Sur une H200, cela peut tenir sur une seule carte avec le gradient checkpointing et des séquences courtes ; sur une H100, il faut un optimiseur 8 bits ou deux cartes. Supprimer le partitionnement ou le déchargement fait gagner du temps, mais le calcul par étape reste le même.

Le prix par token utile

Ce qui compte, c’est le coût par tâche terminée, pas par heure. Les chiffres sont des tokens générés dans un long lot vLLM, donnés en fourchettes car ils dépendent de la longueur des prompts et des réponses, des requêtes parallèles et de la version de vLLM. Les mêmes hypothèses servent dans l’article sur le coût par million de tokens.

Les colonnes de coût utilisent les prix en direct : elles donnent donc la réponse du jour. Avec les prix de novembre 2026, le résultat était le suivant :

• 70B en fp8 : la H200 est nettement moins chère par token, car la H100 manque de mémoire pour le cache et ne peut pas traiter par lots.
• 70B en 4 bits : la H100 est généralement moins chère, car elle a assez de place pour le cache et le gain de bande passante de la H200 est inférieur à son écart de prix.
• Petits modèles : la H100, car les deux cartes y sont surtout limitées par le calcul.

Une tâche courte paie quand même le minimum de 15 minutes par lancement : ces tarifs comptent donc pour des lots de dizaines de millions de tokens, pas pour un test rapide.

Une H200 ou deux H100 ?

Deux H100 donnent 160 Go et deux fois plus de calcul pour 7,80 € de l’heure, contre 5,43 € pour une H200. Sur le papier, la paire l’emporte. En pratique, cela dépend de la machine et du logiciel :

• Sur une machine SXM avec NVLink, un modèle 70B réparti sur deux H100 avec l’option --tensor-parallel-size 2 de vLLM offre un débit élevé et beaucoup de place pour le cache. Si la paire coûte à peu près autant qu’une H200, c’est généralement l’option la plus rapide pour servir un modèle.
• Sur des H100 PCIe sans pont, répartir un modèle sur deux cartes fait transiter des données entre elles à chaque couche, et une bonne partie du gain est perdue. Après le lancement, nvidia-smi topo -m montre comment les cartes sont reliées ; les bases de l’entraînement multi-GPU expliquent comment le lire.
• Une seule H200, c’est plus simple. Aucun réglage de parallélisme, aucun trafic entre les cartes, et elle fonctionne avec les outils qui n’utilisent qu’un GPU. Pour un modèle mixture-of-experts qui tient sur une carte, le garder sur une seule carte évite d’envoyer les tokens d’une carte à l’autre pour atteindre leurs experts.

Laquelle louer

• 70B en fp8, longs documents, nombreux utilisateurs en parallèle, ou modèle MoE 235B dans une version 4 bits compacte : la H200.
• 70B en 4 bits, modèles 32B, fine-tuning d’un modèle qui tient dans 80 Go, image ou vidéo : la H100, ou une carte moins chère. Pour les images, une carte grand public revient bien moins cher par image (voir H100, A100 ou RTX 4090).
• Vous hésitez : lancez la H100 avec vos vrais réglages. Si vLLM refuse de démarrer avec le contexte dont vous avez besoin, ou si la « maximum concurrency » qu’il affiche au démarrage ne dépasse pas quelques requêtes, passez à la H200. Avec la facturation à la minute, le test coûte le minimum de 15 minutes, soit environ 0,98 €.

Les pages H200 et H100 montrent les machines disponibles en ce moment, avec pour chacune la version exacte de la carte, le pays, le pilote et la version de CUDA.