NVIDIA dona OpenShell a CNCF y añade herramientas de código abierto para fábricas de IA

NVIDIA anunció el 10 de noviembre de 2026, durante KubeCon + CloudNativeCon, que contribuirá su entorno de ejecución de seguridad para agentes OpenShell al Sandbox de Cloud Native Computing Foundation (CNCF) y publicará tres componentes de código abierto para su plataforma DSX AI Factory.

Los anuncios vinculan la gobernanza de agentes con la infraestructura necesaria para ejecutarlos de manera eficiente. NVIDIA también contribuye al proyecto Agent Substrate, originado en Google, y añade Kubernetes Engine, Kubernetes Recipes y Snapshot a DSX, que abarcan la ejecución de sesiones, la gestión de clústeres y la recuperación de inferencias.

OpenShell avanza hacia la gobernanza comunitaria

OpenShell aplica controles deterministas mientras los agentes autónomos utilizan herramientas, acceden a servicios de inferencia y ejecutan cargas de trabajo. Ejecuta agentes en entornos aislados a nivel del núcleo, con políticas declarativas de YAML que abarcan el acceso al sistema de archivos, la red, los procesos y las credenciales del proveedor. Las credenciales se incorporan únicamente a solicitudes dirigidas a puntos de conexión aprobados, y la verificación formal comprueba si un cambio de política propuesto otorgaría nuevos permisos de acceso de riesgo antes de aprobarlo.

El entorno de ejecución se distribuye bajo la licencia Apache 2.0. NVIDIA informa que cientos de organizaciones lo han utilizado, que se han recibido decenas de miles de contribuciones en menos de un año y que en la gobernanza del Sandbox participarán organizaciones que lo integren en sus productos. La transición sigue en curso: un aviso del proyecto indica que el desarrollo se está trasladando a la organización ai-openshell, mientras que, durante el traslado, el código, los problemas y las solicitudes de incorporación de cambios permanecen en NVIDIA/OpenShell.

Agent Substrate apunta al cómputo inactivo

Agent Substrate aborda el costo de mantener activas las sesiones de los agentes. A menudo, los agentes esperan instrucciones, resultados de herramientas o respuestas de modelos; un Pod de Kubernetes dedicado y precalentado mantiene los recursos durante esas pausas, mientras que volver a crear el Pod hace perder el estado y supone otro arranque en frío. NVIDIA y Google también colaboran en una integración de OpenShell para agentes que operan en distintas nubes y en sistemas locales.

El diseño de Agent Substrate asigna muchas sesiones con estado a un conjunto más reducido de trabajadores precalentados. Guarda puntos de control de las sesiones inactivas, incluidos el estado de la memoria y del sistema de archivos, libera los trabajadores que ocupaban y las restaura en otros disponibles, sin repetir el proceso habitual de creación de Pods de Kubernetes. Los trabajadores siguen siendo Pods de Kubernetes ordinarios, por lo que continúan aplicándose las políticas de programación, cuotas y ubicación del clúster. Entre las cargas de trabajo previstas se incluyen asistentes de programación, entornos de aprendizaje por refuerzo y entornos aislados de investigación con GPU de corta duración.

NVIDIA está desarrollando la interoperabilidad con Dynamo para la inferencia y con KAI Scheduler para los recursos compartidos del clúster. Dynamo puede proporcionar el tiempo previsto hasta el primer token y el nivel de saturación del conjunto de GPU, para que Agent Substrate decida si debe mantener un agente activo, suspenderlo o reanudarlo. Sus API siguen cambiando, la compatibilidad con GPU se está reconstruyendo en torno a Kubernetes Dynamic Resource Allocation y algunas partes de la integración con Dynamo son experimentales.

DSX incorpora gestión de clústeres y restauraciones más rápidas

NVIDIA Kubernetes Engine y NVIDIA Kubernetes Recipes (NVKE y NVKR) están disponibles en versión preliminar pública bajo la licencia Apache 2.0. NVIDIA señala que sus API, configuración y comportamiento pueden cambiar, y todavía no recomienda usarlos en cargas de trabajo de producción. NVKR crea imágenes reproducibles de nodos y contenedores, archivos binarios y gráficos de Helm a partir de fuentes con versiones fijadas, y registra las entradas utilizadas. NVKE emplea esos artefactos para aprovisionar y operar clústeres mediante una API REST y controladores, aunque los proyectos pueden adoptarse de forma independiente.

NVKE crea clústeres para las cargas de trabajo de los clientes con planos de control de Kubernetes, instancias de etcd y grupos de nodos separados. Obtiene capacidad de infraestructura física mediante NVIDIA Infra Controller y su proveedor de Cluster API, CAPNICo; antes de recibir las credenciales de incorporación, un nodo debe presentar una identidad SPIFFE atestada. Firmus y SK Telecom están integrando los proyectos en sus fábricas de IA, mientras que Mirantis, Netris, OpenNebula Systems, Rafay, Spectro Cloud y vCluster tienen planes de integración relacionados con sus plataformas de infraestructura, ofertas de Kubernetes gestionado o automatización de redes.

NVIDIA Snapshot aborda los arranques en frío de la inferencia al guardar puntos de control de la memoria de CPU y GPU de una carga de trabajo completamente inicializada. Para restaurarla, se necesitan el mismo modelo de GPU y el mismo controlador; además, se evita repetir la carga de pesos, la compilación y la captura del grafo CUDA.

En GPU B200 con almacenamiento VAST NFS, NVIDIA informa de restauraciones de 3,6 a 42,7 segundos en distintas configuraciones de vLLM, SGLang y TensorRT LLM, con aceleraciones de 8x a 36x frente a los arranques en frío. Las pruebas abarcaron desde un modelo de 600 millones de parámetros hasta configuraciones de ocho GPU con puntos de control de casi 1 TB. La creación de los puntos de control tomó entre 15 segundos y 5,5 minutos, y el tiempo combinado de creación del punto de control y restauración fue inferior al de un solo arranque en frío en todas las configuraciones probadas.

Estas cifras no miden el arranque completo de una máquina: el aprovisionamiento de la infraestructura y la carga de imágenes de contenedor quedan fuera del tiempo medido para la restauración. Además, la caché de clave-valor se libera antes de cada punto de control, en lugar de conservarse en el artefacto, por lo que los resultados corresponden a la restauración de una carga de trabajo inicializada en una infraestructura compatible.

La prueba propia de GLM-5.3 de Crusoe en NVIDIA HGX B300 utilizó un punto de control que contenía 594 GB de estado de GPU. Crusoe midió la restauración del estado de GPU: tardó 15,0 segundos desde NVMe local, frente a 33,3 segundos desde NFS. Con el artefacto en NVMe, la creación del pod hasta que estuvo listo tardó 31 segundos, frente a unos ocho minutos con un arranque en frío, lo que señala el almacenamiento como un factor importante en el rendimiento de la restauración. Crusoe también ha aportado mejoras de rendimiento y diagnóstico a los proyectos originales.

En conjunto, estos proyectos incorporan una mayor parte del plano de control y la ruta de recuperación de la fábrica de IA a repositorios abiertos, aunque se encuentran en distintas etapas de madurez: el cambio de gobernanza de OpenShell está incompleto, Agent Substrate sigue evolucionando y NVKE y NVKR continúan en fase de vista previa. Las pruebas comparativas de Snapshot ofrecen la evidencia más clara de una mejora operativa cuantificada, mientras que sus requisitos de compatibilidad y los resultados de Crusoe sobre el almacenamiento muestran que una recuperación más rápida depende tanto de un estado de carga de trabajo reutilizable como de la infraestructura que lo rodea.