NVIDIA présente le projet open source Workload Map, une description commune des charges Kubernetes pour l'inspection, l'ordonnancement en groupe et les vues de plateforme

Le 2 novembre 2026, le blog développeur de NVIDIA a présenté NVIDIA Workload Map, une couche de description open source pour les charges de travail Kubernetes. Le problème visé est bien connu de ceux qui construisent des ordonnanceurs, des contrôleurs, des tableaux de bord ou des outils de coûts pour des clusters d'IA. Une tâche réelle est rarement un seul pod. Un entraînement distribué ou un serveur d'inférence multinœud forme un petit arbre de ressources, et chaque cadre, comme JobSet ou LeaderWorkerSet, range les rôles, le nombre de réplicas, les modèles de pod et l'état dans une ressource personnalisée différente. Les outils ont donc besoin d'un adaptateur par cadre.

Workload Map remplace une grande partie de ce code par framework par des données. Il est livré comme une définition de ressource personnalisée Kubernetes accompagnée d'une bibliothèque Go, et chaque définition indique où trouver les modèles de pod, le nombre de réplicas et les champs d'état d'un type de charge. L'article note que le type de ressource s'appelle toujours Karta, l'ancien nom du projet. Avec une définition, un consommateur peut extraire les modèles de pod, le nombre de réplicas, l'état et les métadonnées, mettre à jour les spécifications de pod, les étiquettes et les annotations sur toutes les instances, et comprendre la hiérarchie, par exemple les Jobs répliqués d'un JobSet et leurs pods. Un mappage d'état traduit les conditions natives en un vocabulaire commun. JobSet n'a pas de condition Running simple : la définition la déduit d'une expression sur l'état des Jobs répliqués, tandis que les conditions natives Completed et Failed sont reprises directement.

L'exemple traité est un JobSet avec un Job meneur et deux Jobs travailleurs, chaque pod demandant quatre GPU. Listé avec kubectl, cela donne un JobSet, trois Jobs et trois pods, sans total. Dans NVIDIA Run:ai avant l'enregistrement de la définition, les trois Jobs apparaissent comme trois charges distinctes de quatre GPU. Après l'enregistrement de la même définition du catalogue par un seul appel d'API, Run:ai affiche une seule charge utilisant 12 GPU, avec une vue de structure du meneur et des travailleurs. L'outil en ligne de commande de Workload Map résout l'objet en cours d'exécution en la même arborescence, lit un kubeconfig, inclut des définitions intégrées et, selon l'article, n'exige pas d'installer Workload Map dans le cluster. Sa sortie montre les rôles de meneur et de travailleur et le total de 12 GPU.

L'ordonnancement est le deuxième usage. Une définition peut porter des instructions facultatives d'ordonnancement en groupe. L'article est précis sur la répartition des rôles : la définition fournit les informations de regroupement, tandis que KAI Scheduler applique l'admission en groupe et prend les décisions de placement. KAI Scheduler utilise Workload Map comme solution de repli dans son regroupeur de pods pour les types de charge sans plugin natif, et les plugins natifs gardent la priorité. Ce détail compte, car il signifie que Workload Map comble des lacunes sans écraser les intégrations existantes.

Le projet fournit un catalogue de définitions prêtes et testées pour JobSet, PyTorchJob, RayCluster, RayJob, RayService, KServe, Knative, MPIJob, NVIDIA NIM, LeaderWorkerSet, Milvus, Grove PodCliqueSet et NVIDIA Dynamo. D'autres types de charge peuvent être ajoutés en écrivant une définition YAML. NVIDIA indique que le logiciel est sous licence Apache 2.0 et utilisé en production dans NVIDIA Run:ai, et que Nova d'Elotl s'en sert pour interpréter la structure et les besoins en ressources lors du choix d'un cluster pour des charges distribuées. Le dépôt se décrit comme une couche de traduction qui fait correspondre les ressources personnalisées de n'importe quel cadre Kubernetes à une structure générique standardisée.

Ce que l'article ne montre pas, ce sont des gains mesurés. Il ne donne aucun chiffre sur le temps gagné, la surcharge de l'ordonnanceur, le taux d'erreur ou la justesse des expressions d'état, et les déclarations d'adoption viennent de NVIDIA et d'un partenaire. Une définition est aussi du code déguisé : une expression d'état erronée ou un mauvais chemin vers un modèle de pod peut faire mal rapporter l'état d'une tâche ou la placer à tort, de sorte que les définitions doivent être relues et testées comme n'importe quel manifeste. Pour une équipe, un essai raisonnable consiste à prendre un cadre déjà utilisé, à appliquer sa définition du catalogue, à comparer l'arborescence et le total de GPU de l'outil en ligne de commande avec ce que montre kubectl, puis seulement à l'enregistrer auprès d'un ordonnanceur ou d'une plateforme. Il faut aussi vérifier la version de la CRD et de la bibliothèque installées, car le projet renomme des composants.