Derrière le nom d'une carte accélératrice, quelques chiffres seulement déterminent ce qu'on pourra en faire. Voici ce qu'il faut retenir de la NVIDIA H200 quand l'objectif est d'héberger des modèles de langage — et pourquoi certaines caractéristiques comptent bien plus que la puissance de calcul brute.
Mémoire, bande passante, calcul : les trois chiffres qui déterminent ce qu'une carte peut héberger et à quelle vitesse.
La mémoire, avant tout le reste
La H200 embarque 141 Go de mémoire HBM3e. C'est la caractéristique décisive, parce qu'un modèle doit tenir entièrement en mémoire pour être servi efficacement : les poids, plus le cache d'attention qui grandit avec le nombre et la longueur des conversations, plus une marge.
Un ordre de grandeur utile : un modèle de 27 milliards de paramètres en précision 16 bits occupe environ 54 Go rien que pour ses poids. Sur une carte de 80 Go, il passe mais laisse peu de place au cache ; sur 141 Go, il tourne confortablement — ou partage la carte avec d'autres modèles.
C'est le vrai apport de la H200 face à la génération précédente : non pas « plus rapide », mais « ce qui tient enfin sur une seule carte ».
La bande passante, qui décide de la vitesse
Environ 4,8 To/s. Ce chiffre gouverne la vitesse de génération de texte, parce que produire un jeton demande de relire l'intégralité des poids du modèle. Un modèle de 54 Go lu à 4,8 To/s donne un plafond théorique d'environ 90 passages par seconde — d'où le débit observé.
Il faut le retenir, car il contredit une intuition répandue : l'inférence est majoritairement limitée par la mémoire, pas par le calcul. Acheter de la puissance de calcul supplémentaire sans bande passante ne rend pas un modèle plus rapide à générer.
Le calcul : Hopper et le FP8
L'architecture Hopper apporte des Tensor Cores de quatrième génération et surtout le calcul en FP8 — une précision réduite à 8 bits pour les opérations où elle suffit. Le gain est double : les poids occupent deux fois moins de mémoire qu'en 16 bits, et les opérations vont plus vite.
Concrètement, un modèle qui ne tiendrait pas en 16 bits tient en 8 bits, avec une dégradation de qualité souvent imperceptible sur des tâches internes. C'est un levier à connaître avant d'envisager une seconde carte.
MIG : plusieurs GPU dans une carte
C'est la fonction qui change tout en exploitation partagée. MIG (Multi-Instance GPU) découpe la carte en jusqu'à sept instances matériellement isolées : chacune reçoit sa part de mémoire, de cache et d'unités de calcul.
Sans MIG, deux modèles sur une même carte se disputent la mémoire et se ralentissent mutuellement — et un plantage peut emporter les deux. Avec MIG, chaque partition se comporte comme un GPU indépendant. Un article de la série y est consacré.
NVLink : quand une carte ne suffit pas
Pour les modèles trop volumineux pour une seule carte, NVLink fournit un lien direct entre cartes, bien plus rapide que le bus PCIe : le modèle est réparti et les cartes échangent en permanence. C'est une réponse aux très grands modèles — pas une nécessité quand le besoin est d'héberger plusieurs modèles moyens, où MIG est plus pertinent.
Ce qu'on oublie de regarder
- L'enveloppe électrique — de l'ordre de 600 à 700 W par carte selon le format. Deux cartes dans un serveur, ce sont des alimentations, un châssis et une climatisation dimensionnés en conséquence. Ce point arrête plus de projets que le prix des cartes.
- Le format — SXM pour les châssis prévus pour, PCIe (dit NVL) pour les serveurs classiques. Le second s'intègre plus facilement dans l'existant.
- Le stockage — les modèles pèsent de quelques gigaoctets à plusieurs centaines. Un NVMe rapide et généreux fait partie de la machine, sous peine de démarrages interminables.
- Les pilotes — une pile GPU se maintient : pilote, bibliothèques, moteur d'inférence. C'est un sujet d'exploitation à part entière.
Comment choisir, en pratique
La démarche qui évite les mauvaises surprises consiste à partir des modèles, pas du matériel :
- lister les modèles à héberger et leur taille en mémoire, précision comprise ;
- ajouter le cache d'attention nécessaire au nombre d'utilisateurs simultanés visé ;
- en déduire la découpe MIG souhaitable ;
- puis seulement choisir la carte et vérifier qu'elle entre dans le serveur, électriquement et thermiquement.
Une carte trop petite oblige à quantifier fortement ou à renoncer à des modèles ; une carte surdimensionnée immobilise un budget. La mémoire disponible reste le critère structurant.
La série « IA en interne »
Cinq articles, du choix d'architecture à la mise en service :
- Pourquoi internaliser l'exécution des modèles
- La H200 : anatomie d'un accélérateur — vous y êtes
- Partitionner une H200 avec MIG
- Présenter des GPU à Kubernetes
- Exécuter des modèles sur K3s avec vLLM
Ces articles s'appuient sur une plateforme réellement exploitée. Les éléments d'infrastructure — noms de machines, adresses internes, espaces de noms — ont été neutralisés ; les principes, commandes et manifestes, eux, sont ceux qui tournent.