NVIDIA ha abierto el código de Run:ai: lo difícil es decidir qué significa eso
# NVIDIA ha abierto el código de Run:ai. Lo difícil es decidir qué significa eso
El 13 de octubre de 2026, NVIDIA anunció que la plataforma Run:ai completa, la capa de orquestación de GPU que había comprado y venía vendiendo en comercial, pasa a ser código abierto bajo la Apache License 2.0. La publicación llega como base de la NVIDIA DSX AI Factory Platform, y es un movimiento de peso: el scheduler que decide qué equipo se lleva qué GPU, y cuánta, pasa a ser código que puedes leer.
Tampoco es lo que sugiere la mayoría de la cobertura, y la distancia entre el anuncio y la realidad operativa es justo donde vive tu planificación de los próximos dos trimestres.
Hay tres cosas ciertas a la vez, y necesitas las tres para decidir bien. El código está abierto. La gobernanza no. Y las partes que sí están realmente gobernadas por la comunidad no son las partes que llevan el bloqueo de proveedor.
Qué se publicó exactamente
La plataforma completa vive en un único monorepositorio, dsx-ai-factory/run-ai, bajo Apache 2.0. Se creó el 25 de agosto de 2026 y, al consultarlo el 27 de octubre, tenía 663 estrellas, 97 forks y 149 issues abiertos, con la documentación en docs.nvidia.com/run-ai. La última etiqueta publicada era 3.0.21, del 26 de octubre, dentro de una línea de parches 3.0 que también contiene 3.0.20 y 3.0.17. Solo hay una rama de release soportada: SUPPORT.md lista release-3.0 como Supported.
El repositorio es bastante más que un scheduler. Contiene los servicios del plano de control, el operador y los controladores dentro del clúster, las librerías compartidas y los clientes, el instalador, la CLI, un servidor MCP y el entorno de desarrollo local.
Junto a la plataforma completa, NVIDIA publicó cuatro componentes que se pueden adoptar por separado: KAI Scheduler, el GPU Fractioning Operator, KAI Resource Management y Workload Map. Esa última parte es donde está el valor práctico, así que merece precisión, porque los cuatro no están igual de listos.
Los CRD de la plataforma son específicos del proveedor, no APIs de Kubernetes upstream: projects.run.ai, nodepools.run.ai, departments.scheduling.run.ai, clusters, datavolumes, accessrules, workloadrunners, runaiconfigs y remoteconfigs. Si instalas la plataforma completa, tus manifiestos arrastrarán grupos de API run.ai y scheduling.run.ai, y salir de ahí después significa reescribirlos.
KAI Scheduler, en cambio, es un repositorio comunitario aparte, kai-scheduler/KAI-Scheduler, también Apache 2.0, creado el 26 de febrero de 2025, con 1.614 estrellas, 314 forks y 265 issues abiertos. NVIDIA afirma que todo el desarrollo del scheduler ocurre en ese repositorio comunitario, así que cada mejora pasa por el mismo código. Y es la única parte de esta historia que tiene una fundación detrás: la aplicación al Sandbox de la CNCF, el issue 372 de cncf/sandbox, se abrió el 8 de mayo de 2025 y se cerró el 8 de febrero de 2026 con el milestone de sandbox registrado como 16 de diciembre de 2025.
Esa aplicación no fue un trámite. El equipo del proyecto Volcano planteó dudas sobre la procedencia del código y la higiene de licencias el 10 de junio de 2025, y el Technical Oversight Committee de la CNCF revisó el proyecto el 23 de septiembre de 2025. Sandbox es el nivel más bajo de la incubación de la CNCF, y sigue siendo un peldaño por encima de donde está el resto de Run:ai.
La línea de gobernanza que nadie pone en la nota de prensa
GOVERNANCE.md es explícito: la hoja de ruta y la planificación de releases las fija NVIDIA. La toma de decisiones usa consenso lazy con una ventana de objeción de cinco días hábiles, y las decisiones no resueltas escalan a la dirección de ingeniería de NVIDIA responsable del proyecto.
Las propias palabras del proyecto son el resumen más justo: "This is an NVIDIA open-source project. The source is public and contributions are welcome under the terms in Contributing, including the Developer Certificate of Origin sign-off requirement. Roadmap and release scheduling [are set by NVIDIA]".
Es un proyecto de código abierto de un solo proveedor, bien gestionado. No es un proyecto gobernado por una fundación, y la diferencia importa el día que quieras una funcionalidad que NVIDIA no quiere.
El reporte de problemas de seguridad va al PSIRT de NVIDIA en lugar de a issues públicas de GitHub, con compromiso de acuse en tres días hábiles, evaluación inicial en diez y actualizaciones de estado al menos cada catorce días. No hay recompensa económica por reportar fallos en el repositorio, aunque los problemas reportados externamente se reconocen públicamente según la política de divulgación coordinada si el reportador lo acepta.
Y la historia de la licencia no es una sola palabra. El monorepositorio es Apache 2.0, algunos subdirectorios vendorizados se distribuyen bajo MIT, y el directorio skills bajo Apache 2.0 y CC-BY-4.0. Descargar el Community Product desde NGC sigue exigiendo aceptar el Software License Agreement de NVIDIA y sus términos específicos de producto. Y la línea comercial de Run:ai continúa por separado, con un producto independiente, NVIDIA Mission Control, NVIDIA AI Enterprise y marketplaces de nube seleccionados.
La parte que decidirá si puedes ejecutarlo
Las GPU fraccionadas son la funcionalidad que todo el mundo quiere, y vienen con una cadena de prerrequisitos que los resúmenes de prensa omiten.
El GPU Fractioning Operator exige Kubernetes 1.28 o posterior, containerd 2.0 o posterior con NRI activado, o CRI-O con NRI, el NVIDIA GPU Operator en v26.7.0 o posterior con container toolkit v1.20.1 y device plugin v0.20.1 o posteriores, y un driver NVIDIA r615 o posterior con CUDA 13.4 en los nodos con GPU. El operador tiene cuatro partes: un controlador que reconcilia el recurso GpuFractioningConfig, mpsd para el control de MPS y la contabilidad de memoria, fractiond, un plugin de NRI que inyecta la petición y el límite de memoria antes de arrancar el proceso del contenedor, y metricsd como exportador sidecar.
El modelo de aplicación es la parte buena. El README lo dice sin rodeos: "The NVIDIA driver enforces NVIDIA_GPU_MEMORY_LIMIT as a hard cap, so a container cannot allocate beyond its share and impact its neighbors on the same GPU. A container that exceeds its limit is terminated (out-of-memory)."
Y NVIDIA ha retirado su anterior implementación propietaria de fraccionamiento en favor de esa capacidad nativa de CUDA 13.4, que es la dirección correcta: el límite lo impone el driver, no un demonio que se pueda esquivar.
Dos matices vienen con el paquete. La matriz de soporte fija el GPU Operator entre 25.10 y 26.7.1, y las fracciones de GPU exigen específicamente 26.7.1 junto con un driver r615, que 26.7.1 no instala por defecto. Así que la última milla de esa actualización es tuya. Y el soporte de GPU fraccionada es solo passthrough: vGPU no está soportado en v3.0, y DGX Spark, Jetson y las estaciones de trabajo quedan fuera del soporte.
El resto de la matriz es exhaustiva. Run:ai v3.0 soporta Kubernetes upstream 1.35 a 1.37 y Red Hat OpenShift 4.20 a 4.22, sobre containerd o CRI-O, para x86 y ARM, con EKS, GKE, AKS, OKE y RKE2 listados. Las versiones de servicios de terceros validadas para v3.0 incluyen Keycloak 26.6, PostgreSQL 16, Traefik 3.7, NATS 2.11.8, Thanos 0.38.0, Valkey 9.0.4, oauth2-proxy 7.15.4 y git-sync 4.7.0.
Un componente todavía no está publicado
KAI Resource Management es la pieza que añade la capa organizativa: proyectos y departamentos, una jerarquía de recursos con semántica de reparto justo y cuotas, y node pools para apuntar a hardware heterogéneo. Es también la pieza que hoy no puedes instalar desde un chart.
Su README lo dice claro: "There is not yet a published release, so cluster administrators must currently package the chart from source and supply compatible controller images."
Eso importa para cualquiera cuya pelea interna sea el reparto de costes de GPU, porque eso es justo lo que hace este componente, y es justo el que no está listo. Planifícalo, no contra él.
Workload Map, antes Karta, es una librería Go más un CRD que describe tipos de workload de Kubernetes arbitrarios, incluidos PyTorchJob, RayCluster, JobSet y CRDs corporativos. Trabaja offline sobre objetos sin esquema y deliberadamente no planifica, no encola, no autoescala ni propaga entre clústeres. Su CRD se distribuye como run.ai/kartas.
Cómo se ve esto en operación
El camino de desarrollo local es más pesado que la típica demo de portátil. La guía describe alrededor de 50 servicios Go y un clúster Kind de cinco nodos, un control plane más cuatro workers, llamado runai-local y fijado en Kubernetes v1.37.0 con kind v0.33.0. Las GPU se simulan con un fake GPU operator configurado para ocho Tesla-A10. Los requisitos son macOS o Linux en amd64 o arm64, Windows queda descartado, al menos 4 CPUs, 16 GB de RAM y 100 GB de disco libre en Linux, o al menos 12 GB de RAM para la VM de Podman en macOS. Una compilación completa deja alrededor de 44 GB de cachés, unos 11 GB de caché de build de Docker y 33 GB de cachés de módulos y compilación de Go. El entorno sirve la plataforma en https://runai.local tras una CA autofirmada y un certificado de servidor con SAN comodín, y añade la entrada de hosts por ti.
Ese último número, 44 GB, es el que va a tu plan de capacidad. El entorno local es una forma legítima de evaluar la plataforma, y no es una demo de portátil.
La instalación es Helm de toda la vida, y eso juega a favor. Añade el repositorio open source de NVIDIA y actualiza los índices:
helm repo add runai https://helm.ngc.nvidia.com/nvidia/runai-oss --force-update helm repo update
El chart del plano de control declara kubeVersion >=1.29.0-0 y arrastra runai-common-chart, Bitnami PostgreSQL, codecentric keycloakx, Bitnami Thanos, Bitnami NATS, Unleash Edge y el chart runai-telemetry de NVIDIA, así que estás instalando una pila con estado completa, no un scheduler. El componente de clúster se registra contra el plano de control, y el motor del scheduler se instala como chart OCI en su propio namespace:
helm upgrade -i kai-scheduler oci://ghcr.io/kai-scheduler/kai-scheduler/kai-scheduler -n kai-scheduler --create-namespace --version <VERSION>
KAI Scheduler asigna trabajo mediante la etiqueta de pod kai.scheduler/queue y el schedulerName kai-scheduler, y una instalación nueva crea las colas por defecto default-parent-queue y default-queue. Sus modos de compartición de GPU son NonMemoryEnforced, HamiCore, NvFractions y Disabled, donde NvFractions usa gpu-fractioning con la aplicación del límite de memoria por CUDA descrita arriba. Aporta sus propios CRD, scheduling.run.ai para podgroups, queues y bindrequests, y kai.scheduler para configs, schedulingshards y topologies.
El fraccionamiento necesita un parche en la cluster policy de NVIDIA para que el container toolkit entregue el dispositivo de gestión al namespace gpu-fractioning, y el driver hay que instalarlo explícitamente en r615 porque el operador no lo hace por ti:
kubectl patch clusterpolicies.nvidia.com/cluster-policy --type=json -p='[{"op":"add","path":"/spec/toolkit/env/-","value":{"name":"NRI_MANAGEMENT_CDI_DEVICE_NAMESPACES","value":"gpu-fractioning"}}]' helm install gpu-operator nvidia/gpu-operator --version v26.7.1 --namespace gpu-operator --create-namespace --set driver.version=615.<patch>
Después, verifica en lugar de suponer:
kubectl -n gpu-fractioning get pods kubectl get gpufractioningconfig default -o yaml kubectl get nodes -L nvidia.com/gpu.deploy.client,nvidia.com/gpu-driver-upgrade-state
Y si quieres que cualquier CRD de workload se pueda describir sin escribir un plugin de scheduler, aplica el CRD de Workload Map:
kubectl apply -f https://raw.githubusercontent.com/dsx-ai-factory/workload-map/main/charts/karta/crds/run.ai_kartas.yaml
El ecosistema, sin adornos
Ocho socios del ecosistema DSX anunciaron integraciones el 13 de octubre: Crusoe, Mirantis, Nebius, OpenNebula Systems, Rafay, Saturn Cloud, Spectro Cloud y vCluster. Crusoe validó el despliegue y cargas representativas, entre ellas registro de clúster, entrenamiento distribuido PyTorch multi-nodo, compartición fraccionada de GPU e inferencia. Mirantis integra Run:ai en k0rdent AI como una entrada del catálogo. Nebius, socio de lanzamiento, ofrece la plataforma open source en sus AI Cloud Applications sobre Kubernetes gestionado.
Lee la matriz de soporte antes de planear sobre nada de eso. La tabla de distribuciones compatibles con socios sigue listando las versiones 2.22 a 2.25 de Run:ai, con Crusoe CMK sobre Kubernetes 1.33, Mirantis k0rdent en 2.22 y 2.23, OpenNebula OneKS en 2.25 con Kubernetes 1.34, Rafay en 2.23 y 2.24 y Spectro Cloud en 2.24 con Kubernetes 1.34. La línea 3.0 todavía no está en esa tabla. Los anuncios del ecosistema son prospectivos, no una certificación de 3.0, y la diferencia importa si estás planificando la compra este trimestre.
Un número más que hay que tratar con cuidado. La mejora de 3x a 6x que circula en la cobertura pertenece a Model Streamer, un SDK de Python que vuelca ficheros SafeTensors en memoria de GPU, integrado upstream en vLLM y SGLang y habilitado con la opción --load-format runai_streamer. Microsoft lo midió en Azure. Es una mejora en la carga de modelos, no en la planificación o la gestión de cuotas, y NVIDIA no publicó ningún benchmark de plataforma para la versión open source. Si te han citado la cifra de 6x como resultado de Run:ai, es un error de categoría que conviene pillar antes de que llegue a una diapositiva.
La decisión que esto te obliga a tomar
Esta es la versión de la noticia que le sirve a quien dirige una plataforma.
El scheduler es la parte que merece adoptarse, y es la parte que está realmente abierta. KAI Scheduler es Apache 2.0, se desarrolla en comunidad, pasó la revisión de Sandbox de la CNCF, tiene sus propios CRD y una instalación limpia por Helm y OCI. Adoptarlo por su cuenta te da planificación en grupo, semántica de cuotas y reparto justo, y compartición de GPU sin adopting un solo grupo de API del proveedor. Es una apuesta con poco bloqueo y con historial upstream.
La plataforma es la parte que merece evaluarse, y es la parte que lleva el bloqueo. Instalar el plano de control de Run:ai significa CRD del proveedor, una pila con estado de PostgreSQL, Keycloak, Thanos y NATS, y un modelo de gobernanza en el que NVIDIA fija la hoja de ruta. Puede ser la decisión correcta para una organización que se está estandarizando en DSX, y es una decisión distinta de la que tomas sobre el scheduler.
Y el centro de la plataforma, la jerarquía de cuotas y proyectos que te va a pedir finanzas, todavía no tiene release publicada.
La secuencia práctica es ejecutar el entorno local si tienes disco, adoptar el scheduler por su cuenta si tu contención de GPU es real, y tratar la plataforma como una decisión de proveedor y no de código abierto. No cuentes con GPU fraccionadas hasta que el driver r615 y el runtime con NRI estén en su sitio, porque esa cadena es la que te va a costar el mes. Y no presupuestes pilas certificadas por socios hasta que la matriz de soporte alcance la 3.0.
Abrir el código es la mitad fácil del movimiento. Decidir quién manda, y cuánta de tu plataforma quieres atar a un proveedor, es la mitad que aparece en tu próxima revisión de arquitectura.