NVIDIA Workload Map unifie l'analyse des charges de travail IA sur Kubernetes

NVIDIA a publié Workload Map, un composant open source conçu pour standardiser la manière dont les outils Kubernetes interprètent les charges de travail IA distribuées. Publié en novembre 2026 dans le cadre de la plateforme NVIDIA DSX AI Factory, ce projet vise à éliminer la fragmentation causée par la diversité des définitions de ressources personnalisées (CRD) entre différents frameworks IA.

Ce qui s'est passé

L'exploitation d'une infrastructure IA sur Kubernetes implique souvent la gestion de tâches distribuées complexes, telles que des jobs d'entraînement multi-nœuds ou des serveurs d'inférence. Ces charges de travail sont rarement constituées d'un seul pod ; il s'agit d'arbres de ressources avec des rôles spécifiques, des nombres de répliques et des indicateurs d'état. Cependant, chaque framework IA encode ces informations différemment. Par exemple, JobSet, LeaderWorkerSet et RayCluster utilisent tous des définitions de ressources personnalisées (CRD) distinctes pour décrire leur structure.

Cette diversité crée une charge importante pour les équipes développant des ordonnanceurs, des contrôleurs, des tableaux de bord ou des outils de gestion des coûts. Les développeurs doivent écrire du code d'adaptateur séparé pour chaque nouveau framework qu'ils souhaitent prendre en charge. Le développement de ces adaptateurs devient un élément récurrent de la feuille de route plutôt qu'un coût d'ingénierie unique, retardant souvent la prise en charge de nouveaux types de charges de travail jusqu'à ce qu'une version logicielle spécifique soit prête.

Pour remédier à cela, NVIDIA a introduit Workload Map, qui fournit une description commune de la structure des charges de travail Kubernetes. Le projet est livré avec un catalogue de définitions préconstruites pour les frameworks populaires, notamment JobSet, PyTorchJob, RayCluster, RayJob, RayService, KServe, Knative, MPIJob, NVIDIA NIM, LeaderWorkerSet, Milvus, Grove PodCliqueSet et NVIDIA Dynamo. En déplaçant la connaissance des charges de travail hors des adaptateurs compilés vers des données déclaratives, l'outil permet aux plateformes d'interpréter les types de charges de travail pris en charge sans maintenir une logique d'analyse distincte pour chacun d'eux.

Comment cela fonctionne

Workload Map fonctionne comme une CRD Kubernetes, anciennement connue sous le nom de Karta, accompagnée d'une bibliothèque Go qui interprète ces définitions de charges de travail. Chaque définition spécifie exactement où trouver les modèles de pods, les nombres de répliques et les champs d'état pour un type de charge de travail donné. La bibliothèque Go résout un objet actif en une vue structurelle uniforme, permettant aux consommateurs d'extraire les métadonnées, de mettre à jour les spécifications des pods et de comprendre la hiérarchie des charges de travail de manière cohérente.

Une fonctionnalité clé est la couche de traduction pour les mappages d'état. Étant donné que différents frameworks rapportent l'état différemment, les définitions de Workload Map associent les conditions natives à un vocabulaire partagé. Par exemple, JobSet ne rapporte pas une simple condition "Running". Au lieu de cela, la définition utilise une expression jq pour dériver cet état en vérifiant si un job est prêt et actif tandis qu'aucun n'a échoué. Cela garantit qu'un RayJob ou un LeaderWorkerSet peut mapper ses indicateurs d'état uniques aux mêmes catégories standard utilisées par les outils de surveillance.

Le système prend en charge plusieurs modes de consommation. L'interface en ligne de commande (CLI) Workload Map peut inspecter les charges de travail directement depuis un cluster sans installer la CRD, affichant une vue arborescente des rôles et des demandes de ressources. Pour l'ordonnancement, le KAI Scheduler utilise ces définitions pour appliquer l'ordonnancement gang, garantissant que tous les pods d'un groupe soient planifiés ensemble. Des plateformes comme NVIDIA Run:ai utilisent les mêmes définitions pour gérer la visibilité, présentant un job distribué comme une seule entité unifiée plutôt que comme une collection de pods disparates.

Détails clés

• Workload Map fournit des définitions préconstruites pour plus de dix principaux frameworks IA, y compris JobSet, RayCluster et PyTorchJob.
• Le projet est disponible sous licence Apache 2.0 et fait partie de la plateforme NVIDIA DSX AI Factory.
• Une bibliothèque Go et un CLI permettent aux outils de résoudre des objets actifs en une vue structurelle uniforme sans analyseurs personnalisés.
• Les mappages d'état utilisent des expressions jq pour traduire les conditions spécifiques aux frameworks en états standard tels que Running, Completed ou Failed.
• L'ordonnanceur Nova d'Elotl utilise Workload Map pour interpréter la structure des charges de travail lors des décisions d'ordonnancement multi-clusters.
• Le CLI peut inspecter les charges de travail en utilisant uniquement un fichier kubeconfig, sans nécessiter l'installation de la CRD Workload Map dans le cluster.

Pourquoi c'est important

Pour les ingénieurs logiciels construisant des infrastructures IA, Workload Map réduit la charge de maintenance liée à la prise en charge de nouveaux frameworks. Au lieu d'écrire et de tester du nouveau code d'adaptateur pour chaque CRD, les développeurs peuvent compter sur une interface standardisée. Cela accélère l'intégration de nouveaux outils IA dans les plateformes existantes et garantit que les ordonnanceurs et les moniteurs peuvent interpréter correctement les exigences des charges de travail dès le premier jour.

La standardisation améliore également la visibilité opérationnelle. Sans description partagée, les opérateurs doivent reconstruire manuellement les structures des charges de travail pour comprendre l'utilisation totale des ressources, comme l'agrégation des demandes GPU à travers plusieurs pods. Workload Map automatise cette agrégation, offrant des insights clairs sur la hiérarchie et la consommation de ressources des jobs distribués. Cette clarté est essentielle pour une gestion efficace des coûts et une planification de la capacité dans les grandes usines IA.

De plus, le découplage de l'interprétation des charges de travail du code spécifique à la plateforme favorise un écosystème plus modulaire. Des outils comme KAI Scheduler et NVIDIA Run:ai peuvent partager les mêmes définitions, réduisant la duplication des efforts. À mesure que le catalogue de frameworks pris en charge s'élargit, la barrière à l'entrée pour les nouvelles charges de travail IA sur Kubernetes diminue, permettant une adoption plus rapide des technologies émergentes sans compromettre la facilité de gestion.

Ce que vous pouvez faire

• Explorez le catalogue de charges de travail dans le dépôt GitHub de la plateforme NVIDIA DSX AI Factory pour trouver des définitions pour les frameworks que vous utilisez actuellement.
• Installez le CLI Workload Map via Homebrew pour inspecter vos charges de travail Kubernetes existantes et visualiser leur structure.
• Examinez l'exemple de définition JobSet pour comprendre comment les mappages d'état et les modèles de pods sont déclarés en YAML.
• Si vous utilisez KAI Scheduler, configurez-le pour utiliser Workload Map comme solution de repli pour le regroupement de pods sur les types de charges de travail non pris en charge.
• Rejoignez l'espace de travail Slack de la plateforme NVIDIA DSX AI Factory pour discuter des intégrations et partager vos retours sur les définitions de charges de travail.
• Envisagez d'écrire une définition YAML personnalisée si vous exploitez un framework de niche non encore inclus dans le catalogue préconstruit.