Une carte H200 dans un serveur, c'est 141 Go de mémoire — et un problème d'exploitation : comment faire cohabiter un modèle de chat, un modèle d'embeddings et un modèle d'OCR sans qu'ils se gênent ? La réponse s'appelle MIG, et elle se configure en quelques commandes.
Ce que MIG fait exactement
Chaque partition reçoit sa mémoire, son cache et ses unités de calcul : ce sont des GPU indépendants, pas un partage de temps.
MIG découpe la carte en instances matériellement isolées. Trois notions à distinguer :
- le profil — la taille d'une partition, notée sous la forme
3g.71gb: trois tranches de calcul, 71 Go de mémoire ; - la GPU Instance (GI) — la partition matérielle elle-même : mémoire, cache, ordonnanceur ;
- la Compute Instance (CI) — l'unité d'exécution CUDA créée à l'intérieur d'une GI. Sans elle, la partition existe mais aucun calcul ne peut y tourner.
C'est l'oubli classique : créer les GI et s'arrêter là. La carte affiche des partitions, et rien ne fonctionne.
Choisir la découpe
La découpe doit correspondre aux modèles prévus, car elle ne se modifie pas à chaud : changer de profil suppose de détruire les partitions, donc d'arrêter ce qui tourne dessus.
Sur la plateforme décrite ici, chaque carte est découpée ainsi :
- 1 × 3g.71gb — pour un gros modèle de chat ;
- 1 × 2g.35gb — pour un modèle moyen ;
- 2 × 1g.18gb — pour les embeddings et l'OCR, peu gourmands.
Avec deux cartes, cela donne huit partitions : deux grandes, deux moyennes et quatre petites. Un compromis délibéré entre « une carte entière pour un seul modèle » et « trop de petites partitions où rien ne tient ».
Le partitionnement, commande par commande
Lister les profils, créer les GPU Instances, créer les Compute Instances, vérifier — la seconde carte se traite en une seule commande grâce à l'option -C.
On commence par lister les profils disponibles, qui portent chacun un identifiant numérique :
nvidia-smi mig -lgip MIG 1g.18gb ID 19 MIG 2g.35gb ID 14 MIG 3g.71gb ID 9
Puis on crée les partitions en donnant la liste des profils voulus :
sudo nvidia-smi mig -i 0 -cgi 9,19,14,19 # GPU 0 : 3g + 1g + 2g + 1g sudo nvidia-smi mig -cci -i 0 # les Compute Instances
L'option -i 0 désigne la carte. Sur la seconde, l'option -C enchaîne les deux étapes :
sudo nvidia-smi mig -i 1 -cgi 9,19,14,19 -C
Le contrôle final doit montrer quatre périphériques MIG par carte :
nvidia-smi -L GPU 0: MIG 3g.71gb Device 0 MIG 2g.35gb Device 1 MIG 1g.18gb Device 2 MIG 1g.18gb Device 3
Deux points qui font perdre du temps
- L'ordre des profils compte peu, mais la place disponible oui. Les partitions se placent sur des emplacements physiques prédéfinis : certaines combinaisons sont impossibles même si le total tient en mémoire. Si la création échoue, c'est généralement là qu'il faut chercher.
- Le mode MIG doit être actif sur la carte, et son activation peut demander un redémarrage — ou au minimum qu'aucun processus n'utilise le GPU. À faire avant la mise en service, pas après.
Une découpe n'est pas définitive, mais elle est engageante
Rien n'interdit de repartitionner : on détruit les instances et on recrée. Mais toute la chaîne en dépend — Kubernetes expose les partitions comme des ressources nommées, et les manifestes des modèles réclament un profil précis. Changer de découpe, c'est donc modifier tous les services concernés.
D'où le conseil : consacrer une heure à lister les modèles à héberger et leur empreinte mémoire avant de taper la première commande. C'est une heure qui en économise beaucoup.
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
- Partitionner une H200 avec MIG — vous y êtes
- 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.