Partager un GPU sur Kubernetes : MIG, time-slicing et DRA

Le scénario se répète chez à peu près tous les clients qui mettent un GPU dans un cluster. Une équipe data achète ou loue une carte, la branche sur Kubernetes via le device plugin NVIDIA, et découvre trois semaines plus tard que six notebooks Jupyter monopolisent six cartes pour tourner à 4 % d'occupation. Le nvidia-smi affiche 2 Go de VRAM utilisés sur 80. Et pendant ce temps, le job d'inférence qui attend en Pending ne trouve pas de GPU libre.

La cause est structurelle, pas humaine. Le device plugin historique de Kubernetes ne sait compter qu'en entiers. Un pod demande nvidia.com/gpu: 1, il obtient une carte entière, exclusivement, jusqu'à sa terminaison. Il n'existe aucune notion de fraction de GPU dans ce modèle, aucun équivalent des 500m de CPU. Un GPU, c'est un bloc atomique.

Trois mécanismes cassent cette atomicité, avec trois niveaux de garantie radicalement différents. Les confondre coûte cher, dans les deux sens : soit on gaspille du matériel, soit on met en production une isolation qui n'existe pas.

Multi-Instance GPU découpe la carte au niveau du silicium. Sur un A100 80 Go ou un H100 80 Go, on obtient jusqu'à sept instances indépendantes, chacune avec sa propre mémoire HBM, ses propres tranches de cache L2, sa propre bande passante mémoire et sa propre fraction de multiprocesseurs.

Les profils sont figés par le constructeur, pas paramétrables au gigaoctet près. Sur A100 80 Go et H100 80 Go, la grille va de 1g.10gb (un septième des SM, 10 Go de mémoire, sept instances maximum) à 7g.80gb (la carte entière). Entre les deux : 2g.20gb, 3g.40gb, 4g.40gb. Sur un A100 40 Go, la même grille existe en 1g.5gb jusqu'à 7g.40gb. Le profil 1g.10gb exige un driver R525 ou supérieur, détail qui pique quand on hérite d'un parc en R470.

Ce qui rend MIG intéressant en exploitation, c'est ce que le mot isolation recouvre vraiment ici. Deux pods sur deux instances MIG distinctes ne partagent aucun chemin d'accès mémoire. Un pod qui remplit sa VRAM ne fait pas tomber le voisin par OOM. Un kernel CUDA qui part en vrille et déclenche un Xid sur son instance n'affecte pas les six autres. Du point de vue du conteneur, chaque instance est une carte séparée avec son propre UUID.

Le prix à payer est double. D'abord, le matériel : MIG n'existe que sur les GPU datacenter à partir d'Ampere. Une L40S, une RTX 6000 Ada, une T4 ne font pas de MIG, quelle que soit la version du GPU Operator. Ensuite, la rigidité : reconfigurer la géométrie MIG d'une carte impose de vider tous les workloads qui tournent dessus. Ce n'est pas une opération à chaud, c'est un drain de nœud. Sur un cluster où les profils changent au rythme des projets, ça devient un chantier récurrent.

Le piège classique : découper systématiquement en 1g parce que sept vaut mieux qu'un. Un modèle de 13 milliards de paramètres en FP16 réclame environ 26 Go de poids, sans compter le KV-cache. Il ne rentre pas dans 10 Go. On se retrouve avec sept instances inutilisables et un GPU à zéro. Le dimensionnement mémoire se fait avant la découpe, pas après, comme détaillé dans notre guide de dimensionnement d'infrastructure GPU pour l'IA.

Le time-slicing ne partitionne rien. Il ment au scheduler.

Concrètement, on configure le device plugin NVIDIA pour déclarer des réplicas d'un même GPU physique. Une carte devient quatre ou dix ressources nvidia.com/gpu aux yeux de Kubernetes. Quatre pods se voient attribuer chacun un GPU, et tournent en réalité sur la même carte. L'ordonnanceur matériel alterne les contextes CUDA entre les processus, tour à tour.

La documentation NVIDIA est honnête sur ce point : contrairement à MIG, il n'y a ni isolation mémoire ni isolation de faute entre les réplicas. Un pod peut allouer toute la VRAM et provoquer l'échec des autres. Un crash driver emporte l'ensemble. Et le nombre de réplicas n'est pas une limite de consommation : c'est juste un nombre de jetons distribués par le scheduler.

Les conséquences en production sont prévisibles. La latence devient non déterministe. Un job d'inférence qui répondait en 40 ms se met à osciller entre 40 et 200 ms selon ce que font les colocataires, parce que chaque changement de contexte insère une attente. Pour un batch de nuit, tout le monde s'en moque. Pour une API synchrone derrière un SLO au 99e percentile, c'est disqualifiant.

Il y a aussi un coût pur de commutation. Alterner des contextes CUDA n'est pas gratuit : le GPU sérialise les kernels des différents processus au lieu de les exécuter concurremment. Sur des workloads qui saturent réellement les SM, mettre quatre pods sur une carte ne divise pas le débit par quatre, il le divise par un peu plus, à cause de cet overhead.

MPS, la variante Multi-Process Service, atténue le problème : les clients partagent un même contexte CUDA, les kernels s'exécutent concurremment, le débit agrégé remonte. Mais l'isolation reste absente au niveau matériel, et le mode de défaillance est pire : une exception fatale chez un client peut faire tomber les autres clients qui partagent le serveur MPS. On échange de la performance contre un point de défaillance unique.

La règle qu'on applique : time-slicing pour des notebooks, du dev, des tests, des workloads d'une même équipe qui se font mutuellement confiance. Jamais entre deux clients ou deux environnements dont l'un est en production.

Dynamic Resource Allocation a été promu GA dans Kubernetes 1.34, publié en septembre 2025. Le cœur des API, ResourceClaim, DeviceClass et ResourceSlice, est passé en v1 stable, activé par défaut sans feature gate. La communauté annonce l'absence de changement cassant à venir, ce qui rend l'adoption défendable.

Le changement de modèle est réel. Avec le device plugin, un pod demande un entier et le nœud publie un compteur. Avec DRA, le pod décrit ce dont il a besoin, et l'ordonnanceur cherche le matériel qui correspond. Une ResourceClaim exprime une contrainte du type "un GPU avec au moins 20 Go de mémoire" ou "deux GPU reliés par NVLink". La DeviceClass porte les critères de sélection, la ResourceSlice décrit ce que chaque nœud expose réellement.

Trois fonctionnalités en beta depuis 1.34 changent la donne côté ops. L'admin access, qui restreint l'accès privilégié aux devices via un label de namespace, évite qu'un développeur récupère par accident une vue complète du matériel. Les prioritized lists, qui permettent de déclarer plusieurs allocations acceptables par ordre de préférence : un H100, sinon deux L40S. Et la remontée des ressources DRA dans l'API PodResources du kubelet, sans quoi les exporters de supervision de cluster Kubernetes restent aveugles sur ce qui est réellement alloué.

Le partage fin, lui, reste en alpha : partitionable devices et consumable capacity sont les briques qui permettront à un driver DRA de découper un device et de suivre la capacité restante. C'est exactement ce qu'il faut pour faire du MIG dynamique piloté par la demande, et c'est aussi la raison pour laquelle je ne mettrais pas ce scénario précis en production aujourd'hui. Le cœur est stable, le partage granulaire ne l'est pas encore.

Côté prérequis, DRA exige un driver spécifique au constructeur déployé dans le cluster, et un control plane à jour. Sur un cluster figé en 1.28 parce que personne n'ose toucher aux montées de version Kubernetes, le sujet ne se pose même pas.

La question revient systématiquement quand l'infra sous-jacente est virtualisée. Un GPU passthrough vers une VM Proxmox et une instance MIG dans un pod ne répondent pas à la même question, et les deux se combinent.

Le passthrough résout le découpage entre tenants au niveau de l'hyperviseur : une carte, une VM, un client, une isolation garantie par l'IOMMU. C'est le bon outil quand la frontière de confiance est la VM, typiquement du multi-tenant réel ou un environnement soumis à des contraintes de cloisonnement.

MIG, time-slicing et DRA résolvent le découpage à l'intérieur d'un même périmètre de confiance, entre les pods d'un cluster. En pratique, une architecture propre empile les deux : passthrough d'une carte vers une VM qui porte un nœud Kubernetes, puis découpe MIG à l'intérieur pour les workloads de ce nœud. Ce qu'il ne faut pas faire, c'est utiliser le time-slicing comme substitut de cloisonnement entre clients. L'hyperviseur isole, le device plugin non.

Le critère de décision n'est pas la technologie, c'est la nature du workload et la frontière de confiance.

Inférence en production, multi-équipes, SLO de latence. MIG, sans discussion, à condition d'avoir le matériel. Découpe en 2g.20gb ou 3g.40gb selon la taille du modèle, jamais en 1g par défaut. La latence reste prédictible parce que personne ne partage vos SM.

Notebooks, dev, expérimentation. Time-slicing avec quatre à huit réplicas, sur un pool de nœuds étiqueté et dédié à ça. Un taint sur ces nœuds évite qu'un déploiement de production y atterrisse par erreur. C'est le cas d'usage pour lequel le mécanisme a été conçu.

Training distribué, batchs longs. GPU entier, pas de partage. Un job qui sature une carte pendant six heures n'a rien à partager, et le time-slicing ne ferait qu'ajouter du bruit.

Cluster en 1.34 ou plus, matériel hétérogène. DRA pour l'allocation, avec des prioritized lists pour absorber le mélange de générations de cartes. Sur un parc où cohabitent des L40S et des A100, décrire le besoin plutôt que compter des unités élimine une classe entière de bricolage à base de node selectors.

Et la mesure d'abord, dans tous les cas. Avant de partitionner quoi que ce soit, il faut le taux d'occupation réel des cartes, pas l'intuition d'une équipe. DCGM-exporter remonte l'utilisation SM, l'occupation mémoire et la consommation par instance MIG dans Prometheus. Un GPU à 8 % d'utilisation SM et 15 % de VRAM sur une semaine glissante est un candidat évident au partage. Un GPU à 85 % ne se partage pas, on en achète un deuxième. Rapprocher ces métriques d'une analyse de coût par namespace transforme le débat sur le partitionnement en arbitrage chiffré au lieu d'une bagarre entre équipes.

Le vrai gaspillage n'est jamais celui qu'on croit. Ce n'est pas la carte à 25 000 euros qui tourne à 8 %, c'est les trois mois passés à ne pas savoir qu'elle tournait à 8 %.

Faire tenir des workloads GPU hétérogènes sur le même parc, c'est un travail de capacity planning autant que de configuration : profils MIG cohérents avec les modèles servis, supervision DCGM branchée avant la mise en production, séparation nette entre les pools partagés et les pools dédiés. C'est ce qu'on met en place sur les infrastructures GPU qu'on opère, dans le DC Fullsave de Toulouse et sur le site TDF de Bordeaux. Si vos cartes sont sous-utilisées sans que personne ne sache de combien, on peut instrumenter le parc et cadrer le partitionnement avant d'en racheter une de plus.

• Time-Slicing GPUs in Kubernetes, NVIDIA GPU Operator : documentation officielle du partage temporel, absence d'isolation mémoire et de faute entre réplicas.
• Supported MIG Profiles, NVIDIA Multi-Instance GPU User Guide : grille exhaustive des profils A100 40 Go, A100 80 Go et H100 80 Go, fractions de SM et prérequis driver.
• Kubernetes v1.34: DRA has graduated to GA : passage en GA des API ResourceClaim, DeviceClass et ResourceSlice, état beta et alpha des fonctionnalités associées.
• Multi-Process Service, documentation NVIDIA : fonctionnement de MPS, partage de contexte CUDA et propagation des fautes entre clients.
• Getting Started with MIG, NVIDIA : procédure d'activation, contraintes de reconfiguration et matériel supporté.