NVIDIA Workload Map unifica el análisis de cargas de trabajo de IA en Kubernetes
NVIDIA lanza una herramienta de código abierto que ofrece una descripción estructural común para las cargas de trabajo de IA distribuidas en Kubernetes, eliminando la necesidad de adaptadores específicos de cada framework.
Traducido automáticamente del original en inglés.
NVIDIA ha lanzado Workload Map, un componente de código abierto diseñado para estandarizar cómo las herramientas de Kubernetes interpretan las cargas de trabajo de IA distribuidas. Publicado en noviembre de 2026 como parte de la plataforma NVIDIA DSX AI Factory, este proyecto busca eliminar la fragmentación causada por las diversas definiciones de recursos personalizados (CRD) entre diferentes frameworks de IA.
Qué ha ocurrido
Operar infraestructura de IA en Kubernetes suele implicar la gestión de tareas distribuidas complejas, como trabajos de entrenamiento multi-nodo o servidores de inferencia. Estas cargas de trabajo rara vez son pods individuales; son árboles de recursos con roles específicos, recuentos de réplicas e indicadores de estado. Sin embargo, cada framework de IA codifica esta información de manera distinta. Por ejemplo, JobSet, LeaderWorkerSet y RayCluster utilizan definiciones de recursos personalizados (CRD) distintas para describir su estructura.
Esta diversidad crea una carga significativa para los equipos que desarrollan planificadores (schedulers), controladores, paneles de control o herramientas de gestión de costos. Los desarrolladores deben escribir código de adaptador separado para cada nuevo framework que deseen soportar. El desarrollo de estos adaptadores se convierte en un elemento recurrente del roadmap en lugar de un costo de ingeniería único, lo que a menudo retrasa el soporte para nuevos tipos de cargas de trabajo hasta que está lista una versión específica del software.
Para abordar esto, NVIDIA introdujo Workload Map, que proporciona una descripción común de la estructura de las cargas de trabajo en Kubernetes. El proyecto incluye un catálogo de definiciones preinstaladas para frameworks populares como JobSet, PyTorchJob, RayCluster, RayJob, RayService, KServe, Knative, MPIJob, NVIDIA NIM, LeaderWorkerSet, Milvus, Grove PodCliqueSet y NVIDIA Dynamo. Al trasladar el conocimiento sobre las cargas de trabajo desde adaptadores compilados hacia datos declarativos, la herramienta permite a las plataformas interpretar los tipos de cargas de trabajo soportadas sin mantener lógica de análisis separada para cada una.
Cómo funciona
Workload Map funciona como una CRD de Kubernetes, anteriormente conocida como Karta, acompañada de una biblioteca Go que interpreta estas definiciones de cargas de trabajo. Cada definición especifica exactamente dónde encontrar las plantillas de pods, los recuentos de réplicas y los campos de estado para un tipo de carga de trabajo dado. La biblioteca Go resuelve un objeto activo en una vista estructural uniforme, permitiendo a los consumidores extraer metadatos, actualizar especificaciones de pods y comprender la jerarquía de la carga de trabajo de forma consistente.
Una característica clave es la capa de traducción para las asignaciones de estado. Dado que diferentes frameworks reportan el estado de manera distinta, las definiciones de Workload Map mapean las condiciones nativas a un vocabulario compartido. Por ejemplo, JobSet no reporta una condición simple "Running" (En ejecución). En su lugar, la definición utiliza una expresión jq para derivar este estado comprobando si algún job está listo y activo mientras ninguno ha fallado. Esto asegura que un RayJob o un LeaderWorkerSet pueda mapear sus indicadores de estado únicos a las mismas categorías estándar utilizadas por las herramientas de monitoreo.
El sistema admite múltiples patrones de consumo. La CLI de Workload Map puede inspeccionar cargas de trabajo directamente desde un clúster sin instalar la CRD, mostrando una vista de árbol de roles y solicitudes de recursos. Para la planificación, el KAI Scheduler utiliza estas definiciones para aplicar la programación en grupo (gang scheduling), asegurando que todos los pods de un grupo se programen juntos. Plataformas como NVIDIA Run:ai usan las mismas definiciones para gestionar la visibilidad, presentando un trabajo distribuido como una única entidad unificada en lugar de una colección de pods dispares.
Detalles clave
- Workload Map proporciona definiciones preinstaladas para más de diez frameworks principales de IA, incluyendo JobSet, RayCluster y PyTorchJob.
- El proyecto está disponible bajo la licencia Apache 2.0 y es parte de la plataforma NVIDIA DSX AI Factory.
- Una biblioteca Go y una CLI permiten a las herramientas resolver objetos activos en una vista estructural uniforme sin analizadores personalizados.
- Las asignaciones de estado utilizan expresiones jq para traducir condiciones específicas del framework a estados estándar como Running, Completed o Failed.
- El scheduler Nova de Elotl utiliza Workload Map para interpretar la estructura de las cargas de trabajo en decisiones de planificación multi-clúster.
- La CLI puede inspeccionar cargas de trabajo utilizando solo un kubeconfig, sin requerir la instalación de la CRD de Workload Map en el clúster.
Por qué importa
Para los ingenieros de software que construyen infraestructura de IA, Workload Map reduce la sobrecarga de mantenimiento asociada al soporte de nuevos frameworks. En lugar de escribir y probar nuevo código de adaptador para cada CRD, los desarrolladores pueden confiar en una interfaz estandarizada. Esto acelera la integración de nuevas herramientas de IA en plataformas existentes y garantiza que los planificadores y monitores puedan interpretar los requisitos de las cargas de trabajo con precisión desde el primer día.
La estandarización también mejora la visibilidad operativa. Sin una descripción compartida, los operadores deben reconstruir manualmente las estructuras de las cargas de trabajo para entender el uso total de recursos, como agregar solicitudes de GPU a través de múltiples pods. Workload Map automatiza esta agregación, proporcionando información clara sobre la jerarquía y el consumo de recursos de los trabajos distribuidos. Esta claridad es esencial para una gestión efectiva de costos y la planificación de capacidad en fábricas de IA a gran escala.
Además, el desacoplamiento de la interpretación de cargas de trabajo del código específico de la plataforma fomenta un ecosistema más modular. Herramientas como KAI Scheduler y NVIDIA Run:ai pueden compartir las mismas definiciones, reduciendo la duplicación de esfuerzo. A medida que crece el catálogo de frameworks soportados, la barrera de entrada para nuevas cargas de trabajo de IA en Kubernetes disminuye, permitiendo una adopción más rápida de tecnologías emergentes sin comprometer la gestionabilidad.
Qué puedes hacer
- Explora el catálogo de cargas de trabajo en el repositorio GitHub de NVIDIA DSX AI Factory para encontrar definiciones para los frameworks que utilizas actualmente.
- Instala la CLI de Workload Map usando Homebrew para inspeccionar tus cargas de trabajo existentes en Kubernetes y visualizar su estructura.
- Revisa el ejemplo de definición de JobSet para entender cómo se declaran las asignaciones de estado y las plantillas de pods en YAML.
- Si usas KAI Scheduler, configúralo para utilizar Workload Map como alternativa para la agrupación de pods en tipos de cargas de trabajo no soportados.
- Únete al espacio de trabajo Slack de NVIDIA DSX AI Factory para discutir integraciones y compartir comentarios sobre las definiciones de cargas de trabajo.
- Considera escribir una definición YAML personalizada si operas un framework de nicho que aún no está incluido en el catálogo preinstalado.



