--- title: "Déployer des workloads IA sur une instance 8x NVIDIA H200 NVL" description: "Découvrez comment déployer des workloads IA sur une instance GPU 8x NVIDIA H200 NVL en tenant compte de sa topologie NVLink" url: https://docs.ovhcloud.com/fr/guides/public-cloud/compute/deploy-8-h200-nvl-gpu-instance lang: fr lastUpdated: 2026-10-01 --- > For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/fr/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/fr/llms-full.txt. # Déployer des workloads IA sur une instance 8x NVIDIA H200 NVL ## Objectif Nous vous recommandons de suivre ce guide si vous disposez d'une instance **h200-1920-eph** ou **h200-1920**. Les instances 8x NVIDIA H200 NVL (modèles **h200-1920** et **h200-1920-eph**) sont organisées en deux groupes de 4 GPU, avec une connectivité NVLink uniquement au sein de chaque groupe et une liaison PCIe entre les deux groupes. Tenir compte de cette topologie vous permet d'obtenir les meilleures performances et une stabilité optimale pour vos workloads IA. :::info Actuellement, les instances 8x NVIDIA H200 NVL sont uniquement disponibles dans la région de Paris (**EU-WEST-PAR**). ::: **Ce guide vous explique comment déployer et exploiter des workloads IA sur une instance GPU 8x NVIDIA H200 NVL** ## Prérequis - Disposer d'un [projet Public Cloud](https://docs.ovhcloud.com/fr/guides/public-cloud/cross-functional/create-a-public-cloud-project.md) avec accès à la région où les modèles d'instance **h200-1920** et **h200-1920-eph** sont disponibles (**EU-WEST-PAR**). - Disposer d'une [clé SSH](https://docs.ovhcloud.com/fr/guides/public-cloud/compute/creating-ssh-keys.md) créée pour déployer une instance GPU Linux. *** ### Accès à l'espace client OVHcloud - **Lien direct :** Tous mes projets Public Cloud - **Pour accéder à vos services :** Public Cloud > Sélectionnez votre projet > Instances *** ## En pratique Vous trouverez ci-dessous les informations nécessaires pour déployer une instance 8x NVIDIA H200 NVL, comprendre sa topologie, puis y exécuter et surveiller vos workloads IA. ### Déployer l'instance Dans la section **Accès rapide** , cliquez sur `Créer une instance `. Sélectionnez ensuite la région **EU-WEST-PAR** et choisissez le modèle d'instance **h200-1920** ou **h200-1920-eph** dans la catégorie **Cloud GPU** . Suivez ensuite les étapes restantes, comme détaillé dans le guide « [Comment créer une instance Public Cloud et s'y connecter](https://docs.ovhcloud.com/fr/guides/public-cloud/compute/getting-started.md#%C3%A9tape-4--cr%C3%A9er-linstance) ». Ce processus peut prendre quelques minutes. Une fois l'instance livrée, installez le driver NVIDIA comme indiqué dans le guide « [Déployer une instance GPU](https://docs.ovhcloud.com/fr/guides/public-cloud/compute/deploy-a-gpu-instance.md) ». ### Présentation du matériel | Caractéristique | h200-1920 | h200-1920-eph | | ---------------------------- | ------------------------------------------------------- | ----------------------------------------------- | | GPU | 8x NVIDIA H200 NVL | 8x NVIDIA H200 NVL | | Mémoire GPU | 141 Go HBM3e par GPU (1 128 Go au total) | 141 Go HBM3e par GPU (1 128 Go au total) | | Topologie GPU | 2 groupes de 4 GPU | 2 groupes de 4 GPU | | Interconnexion intra-groupe | NVLink, au sein de chaque groupe de 4 GPU | NVLink, au sein de chaque groupe de 4 GPU | | Interconnexion inter-groupes | PCIe | PCIe | | vCores | 224 | 224 | | Mémoire (RAM) | 1 920 Go | 1 920 Go | | Stockage | 400 Go (disque système) + **4x 7,68 To en passthrough** | 400 Go (disque système) + **1x 20 To éphémère** | | Réseau public | 25 Gbit/s | 25 Gbit/s | | Réseau privé | Jusqu'à 25 Gbit/s | Jusqu'à 25 Gbit/s | ### Disque éphémère (h200-1920-eph) Le disque éphémère du modèle d'instance **h200-1920-eph** est déjà formaté avec un système de fichiers Ext4. Il peut déjà être monté automatiquement sous `/mnt` par [cloud-init](https://docs.cloud-init.io/en/latest/reference/modules.html#mounts). Pour vérifier si le disque éphémère est monté, exécutez la commande suivante : ```sh lsblk -f ``` Si le disque de 20 To affiche `/mnt` comme point de montage, il est prêt à l'emploi. Sinon, montez-le manuellement en remplaçant `/dev/` par le nom du périphérique affiché par `lsblk -f` : ```sh sudo mount /dev/ /mnt ``` :::warning Les données stockées sur le disque éphémère ne sont pas incluses dans les [sauvegardes d'instance](https://docs.ovhcloud.com/fr/guides/public-cloud/compute/save-an-instance.md) et sont perdues lorsque l'instance est supprimée ou suspendue (_shelved_). Nous vous recommandons de sauvegarder vos données importantes sur une solution de stockage externe, telle que l'[Object Storage](https://docs.ovhcloud.com/fr/guides/storage-and-backup/object-storage/s3-getting-started-with-object-storage.md). ::: ### Topologie GPU et architecture NVLink Les 8 GPU sont organisés comme suit : ![Schéma des deux groupes NVLink de 4 GPU, reliés entre eux par PCIe](/images/public-cloud/compute/deploy-8-h200-nvl-gpu-instance/h200-gpu-topology.png) | Groupe NVLink | GPU | Interconnexion au sein du groupe | Interconnexion entre les groupes | | ------------- | -------------- | ------------------------------------------- | -------------------------------- | | Groupe A | GPU 0, 1, 2, 3 | NVLink (les 4 GPU sont tous interconnectés) | PCIe | | Groupe B | GPU 4, 5, 6, 7 | NVLink (les 4 GPU sont tous interconnectés) | PCIe | Pour répartir vos workloads sur cette instance, nous vous recommandons de : - exécuter, dans la mesure du possible, chaque job au sein d'un seul groupe NVLink (4 GPU). - traiter les deux groupes comme deux clusters distincts lorsqu'un même modèle nécessite les **8 GPU** : conserver les parallélismes les plus gourmands en communications (comme le _tensor parallelism_) au sein de chaque groupe, et n'utiliser entre les deux groupes que des modes de communication plus légers (comme le _pipeline parallelism_). Un exemple est présenté dans les configurations recommandées ci-dessous. - garder à l'esprit que les gains de performance du NVLink ne s'appliquent **qu'au sein de chaque groupe de 4 GPU**. :::info Conserver les opérations gourmandes en communications au sein de chaque groupe NVLink évite un trafic important sur le bus PCIe, ce qui garantit à la fois de meilleures performances et une meilleure stabilité. ::: Avant de lancer un workload, nous vous recommandons de vérifier quels GPU appartiennent à quel groupe NVLink : ```sh nvidia-smi topo -m ``` Dans la matrice affichée, les GPU reliés par NVLink présentent une valeur `NV#` entre eux (# correspondant au nombre de liens NVLink). Les GPU reliés uniquement en PCIe affichent à la place un type de chemin PCIe (par exemple `PHB`, `NODE` ou `SYS`). Les 4 GPU présentant des valeurs `NV#` entre eux forment un groupe NVLink. Vous pouvez également afficher l'état des liens NVLink d'un GPU donné (ici le GPU 0) : ```sh nvidia-smi nvlink --status -i 0 ``` ### Configurations recommandées Les exemples ci-dessous utilisent [vLLM](https://docs.vllm.ai/) pour illustrer le déploiement d'un modèle sur 4 ou 8 GPU dans le respect de la topologie NVLink. **4 GPU (un seul groupe NVLink)** Pour déployer sur 4 GPU, indiquez explicitement les identifiants des périphériques à utiliser, afin de vous assurer qu'ils appartiennent tous au même groupe NVLink : ```sh # Numéroter les GPU dans le même ordre que nvidia-smi (ordre du bus PCI) export CUDA_DEVICE_ORDER=PCI_BUS_ID # Limiter le déploiement au premier groupe NVLink (utilisez 4,5,6,7 pour le second groupe) export CUDA_VISIBLE_DEVICES=0,1,2,3 # Définir la taille du tensor parallelism à 4 vllm serve --tensor-parallel-size 4 ... ``` **8 GPU (les deux groupes NVLink)** Pour déployer des modèles de très grande taille sur les 8 GPU, combinez _pipeline parallelism_ et _tensor parallelism_ : ```sh # Numéroter les GPU dans le même ordre que nvidia-smi (ordre du bus PCI) export CUDA_DEVICE_ORDER=PCI_BUS_ID # Définir à la fois la taille du pipeline parallelism et celle du tensor parallelism vllm serve --pipeline-parallel-size 2 --tensor-parallel-size 4 ... ``` En supposant que les GPU 0–3 et 4–7 forment les deux groupes NVLink (voir `nvidia-smi topo -m`), cette configuration répartit les couches du modèle en deux étages (_pipeline parallelism_), un par groupe NVLink : les GPU 0–3 exécutent le premier étage et les GPU 4–7 le second. Au sein de chaque groupe, les poids de chaque couche sont répartis sur les 4 GPU (_tensor parallelism_). Les échanges fréquents liés au _tensor parallelism_ restent sur le NVLink, tandis que ce sont principalement les activations transmises d'un étage à l'autre qui transitent par le PCIe. :::warning Évitez d'utiliser `--tensor-parallel-size 8`, qui appliquerait le _tensor parallelism_ entre les deux groupes. ::: **Deux replicas (un par groupe NVLink)** Si le modèle tient sur 4 GPU, vous pouvez également exécuter deux replicas indépendants du modèle, un par groupe NVLink, et répartir les requêtes entre eux. Vous doublez ainsi le débit, sans aucun trafic entre les deux groupes. Lancez chaque commande dans un terminal distinct, car `vllm serve` reste au premier plan : ```sh export CUDA_DEVICE_ORDER=PCI_BUS_ID # Premier replica sur le premier groupe NVLink CUDA_VISIBLE_DEVICES=0,1,2,3 vllm serve --tensor-parallel-size 4 --port 8000 ... # Second replica sur le second groupe NVLink CUDA_VISIBLE_DEVICES=4,5,6,7 vllm serve --tensor-parallel-size 4 --port 8001 ... ``` ### Bonnes pratiques d'exploitation Nous vous recommandons de : - vérifier la correspondance entre les GPU et les groupes NVLink avant de lancer un workload (`nvidia-smi topo -m`). - conserver tous les GPU utilisés par un même job au sein du même groupe NVLink, sauf si vous utilisez une configuration inter-groupes comme celle en _pipeline parallelism_ décrite ci-dessus. - surveiller l'état du NVLink et les logs du noyau (`dmesg`) pendant l'exécution de vos workloads. - sauvegarder régulièrement vos données importantes. ### Monitoring recommandé Nous vous recommandons de surveiller les métriques suivantes pendant l'exécution de vos workloads : | Métrique | Méthode | Recommandation | | ---------------------------------- | ----------------------------------------------------- | -------------- | | État et erreurs du NVLink | `nvidia-smi nvlink --status` / `nvidia-smi nvlink -e` | Recommandé | | Détection et état de santé des GPU | `nvidia-smi -q` / NVIDIA DCGM (`dcgmi health`) | Recommandé | | Erreurs GPU dans les logs du noyau | `sudo dmesg -T \| grep -iE "xid\|nvrm"` | Recommandé | :::info Le driver NVIDIA signale les erreurs GPU et NVLink dans les logs du noyau sous forme de messages **Xid**. Pour un monitoring en continu, [NVIDIA DCGM](https://developer.nvidia.com/dcgm) permet d'exporter ces métriques vers votre outil de monitoring. Les commandes `smartctl` et `nvme` sont fournies par les paquets `smartmontools` et `nvme-cli` (par exemple `sudo apt-get install smartmontools nvme-cli` sous Debian ou Ubuntu). ::: ## Aller plus loin [Déployer une instance GPU](https://docs.ovhcloud.com/fr/guides/public-cloud/compute/deploy-a-gpu-instance.md) Échangez avec notre [communauté d'utilisateurs](https://community.ovhcloud.com/).