NVIDIA CUDA 13.4 découpe la mémoire des GPU dans Kubernetes
NVIDIA décrit le 27 octobre 2026 un opérateur Kubernetes open source, gpu-fractioning, hébergé sous l'organisation du planificateur KAI, qui applique sur chaque nœud la limite mémoire introduite par CUDA 13.4. Un conteneur demande une quantité exacte de mémoire, ou un minimum garanti avec un plafond qu'il peut franchir quand la carte est libre, et la carte ne porte qu'un mode de calcul à la fois : temps partagé ou partage des multiprocesseurs. KAI Scheduler 0.18.0 est le premier planificateur à écrire les annotations que l'opérateur lit.
par Gyom 28 octobre 2026 à 13:01 4 min de lecture rubrique : Machines et coûts
etiquettes : Hébergé · GPU · Coût
Une carte graphique allouée à un seul conteneur reste à moitié vide la plupart du temps. Kubernetes sait partager un processeur, rarement une carte graphique sans mettre en danger les voisins : le processus qui déborde réserve la mémoire des autres, et la panne d'un locataire devient celle du nœud. CUDA 13.4 ajoute la pièce qui manquait, une frontière mémoire appliquée par le pilote et transparente pour l'application, et NVIDIA publie l'opérateur qui la rend utilisable depuis un cluster.
Trois façons de partager une carte, et une limite qui manquait
Un GPU se partage déjà de trois manières. Le multi-instance GPU, MIG, découpe la carte en instances isolées au niveau matériel et invisibles pour l'application. Le temps partagé laisse plusieurs processus se relayer, sans aucune limite de mémoire. Le Multi-Process Service, MPS, les fait tourner en parallèle dans des espaces d'adressage séparés, et CUDA 13.4 y ajoute l'application d'une frontière mémoire en mode temps partagé comme en mode partage de calcul. Avant cette version, un processus pouvait réclamer toute la mémoire libre de la carte quel que soit le lot qui l'avait précédé.
Un montant exact, ou un minimum avec un plafond
La limite prend trois formes. Une quantité exacte : l'allocation au-delà échoue, comme sur une carte plus petite. Une plage : le conteneur obtient un minimum garanti et peut monter jusqu'à un maximum quand la mémoire est libre, puis redescendre quand un voisin la réclame. Un mode de calcul, temps partagé ou partage des multiprocesseurs, que le conteneur choisit explicitement au lieu de subir le défaut. La carte reste découpée en fractions visibles depuis l'intérieur : nvidia-smi lancé dans le conteneur affiche la part allouée, pas la carte entière.
Quatre annotations suffisent à décrire une fraction
L'opérateur, gpu-fractioning, tourne à côté du GPU Operator de NVIDIA, qui fournit le pilote et l'environnement d'exécution. Il installe et supervise MPS sur chaque nœud, applique les limites et le mode de calcul de chaque conteneur avant le démarrage du processus, et mesure la consommation par fraction plutôt que par carte. Il lit quatre annotations posées par le planificateur : la mémoire garantie, le plafond éventuel, le mode de calcul et les cartes attribuées. Le nom du conteneur fait partie de la clé, ce qui évite qu'une annotation s'applique au mauvais conteneur d'un pod à plusieurs conteneurs.
Rien n'impose d'écrire ces annotations soi-même. KAI Scheduler, projet bac à sable de la CNCF maintenu par des ingénieurs venus de Run:ai, ouvre en version 0.18.0 un mode de partage appelé NvFractions : le planificateur choisit la part de quelle carte revient à quel lot, écrit les annotations, et l'opérateur les applique sur le nœud. Le mode s'active à l'installation avec l'option Helm global.nvFractions.set=true, qui installe l'opérateur comme dépendance. La demande peut aussi se faire en portion de carte avec l'annotation gpu-fraction à 0,5, avec un plafond qui doit rester au-dessus de la portion et en dessous de 1.
Deux modes de calcul, jamais mélangés sur une carte
Le partage du temps et le partage des multiprocesseurs ne se valent pas. En temps partagé, les lots se relaient sur la carte entière : chacun obtient environ 1/n du temps quand tous sont actifs, et le temps qu'un lot laisse libre profite aux autres. Chaque lot garde son propre domaine d'erreur, donc un plantage ne touche pas les voisins. En partage des multiprocesseurs, les unités de calcul sont distribuées en continu entre les lots et un seul lot actif peut toutes les prendre, mais tous partagent un domaine d'erreur commun. KAI Scheduler ne place jamais les deux modes sur la même carte, et il suit cette règle par carte et non par nœud, ce qui laisse un nœud héberger les deux modes sur des cartes différentes.
Ce que l'opérateur mesure, et ce qu'il ne protège pas
L'article de NVIDIA décrit le mécanisme et ne donne aucune mesure d'occupation avant et après : une limite appliquée par le pilote, un opérateur qui la configure par conteneur, un planificateur qui répartit. Le partage des multiprocesseurs met les locataires dans un même domaine d'erreur, ce que l'article réserve explicitement aux charges qui peuvent tourner ensemble, et MIG reste la seule voie vers une isolation matérielle.
La conséquence pratique est connue des équipes qui administrent des nœuds GPU : une carte peut porter plusieurs services d'inférenceExécution d'un modèle : une entrée, une sortie. Le calcul se sépare en un pré-remplissage de la question, puis une génération token par token.Fiche du lexique ou plusieurs travaux de réglage sans que l'un réserve la mémoire des autres, et sans qu'un dépassement se traduise par un processus tué au hasard. L'opérateur et le planificateur sont tous deux sur GitHub, sous l'organisation KAI Scheduler, avec un guide administrateur et un guide utilisateur pour les trois mécanismes de partage.
Source primaire NVIDIA Technical Blog, « Memory-Enforced GPU Sharing in Kubernetes with NVIDIA CUDA 13.4 », 27 octobre 2026