En este artículo
NVIDIA Run:ai open source: GPU y fábrica de software
Revisado el con documentación de NVIDIA y repositorios públicos. Es un análisis de fuentes, no un despliegue de Run:ai, una prueba de integración con ESF ni un benchmark de GPU.
Las GPU están ocupadas. El software todavía no está listo para publicarse.
Esa es la diferencia que importa en el anuncio de Run:ai de NVIDIA. Asignar capacidad de cómputo y aceptar un cambio de software son trabajos distintos. La orquestación de GPU de código abierto puede mejorar el primero. No elimina el segundo.
La pregunta útil no es si Run:ai sustituye a cualquier plataforma de IA. Es qué parte de la infraestructura ya no necesita desarrollar y qué decisiones deben seguir bajo su control.
¿Qué ha publicado NVIDIA como código abierto?
El 13 de octubre de 2026, NVIDIA anunció la plataforma Run:ai completa como código abierto, no solo su motor de planificación KAI. El anuncio sitúa Run:ai dentro de NVIDIA DSX AI Factory Platform. Ofrece tanto la plataforma integrada como componentes que pueden adoptarse por separado. Lea el anuncio oficial de NVIDIA.
El repositorio incluye el plano de control, servicios de clúster, instalador, CLI, servidor MCP y entorno de desarrollo. Identifica Apache-2.0 como licencia del código propio, con avisos específicos para materiales de terceros y elementos de marca. Por tanto, “el código de la plataforma usa Apache-2.0; revise las licencias complementarias” es más preciso que “todo es Apache-2.0”. Revise el alcance del repositorio y sus licencias.
Esto cambia la decisión entre desarrollar y comprar. Los equipos pueden inspeccionar y adaptar capacidades de infraestructura que antes exigían evaluar una plataforma comercial. No convierte en gratuitos todas las dependencias, los pesos de los modelos, el soporte ni las GPU.
¿Se puede utilizar Run:ai de código abierto gratis?
Según el anuncio, el Community Product de NGC no requiere una suscripción de pago a Run:ai ni derechos de soporte de NVIDIA. No incluye soporte empresarial de NVIDIA. Descargar esa distribución sigue exigiendo aceptar los términos de software y de productos de IA aplicables. Separe la licencia del código, las condiciones de la distribución y el contrato de soporte.
Existe una salvedad práctica de acceso. Durante esta revisión, la colección de NGC enlazada en el anuncio todavía mostraba mensajes de suscripción y una fecha de actualización del . Esa página anterior no invalida el anuncio más reciente. Sin embargo, no iniciamos sesión ni completamos la descarga del Community Product. Confirme el chart, las versiones de las imágenes y la vía de acceso antes de planificar el despliegue. Compruebe la colección de NGC y las condiciones que muestra.
Una licencia a coste cero no elimina hardware o alquiler en la nube, electricidad, almacenamiento, red, actualizaciones, incidentes ni horas de ingeniería. Una mayor utilización se convierte en ahorro cuando reduce una factura o evita capacidad adicional. Aprovechar una GPU ya pagada recupera capacidad, pero no devuelve dinero automáticamente.
Run:ai frente a KAI Scheduler: ¿qué capa necesita?
Elija la capa más pequeña que resuelva un problema medido. Una plataforma Kubernetes existente puede necesitar un planificador o un mecanismo para compartir GPU, no otro sistema completo de gestión.
| Componente | Función principal | No sustituye a |
|---|---|---|
| Plataforma Run:ai | Coordinar cargas, políticas organizativas, acceso y visibilidad entre clústeres conectados. | Los criterios de aceptación y la aprobación de versiones. |
| KAI Scheduler | Asignar cargas mediante colas, cuotas, reparto justo, prioridades y planificación en grupo. | Un motor de inferencia o el ciclo de razonamiento del agente. |
| GPU Fractioning Operator | Aplicar asignaciones compatibles de memoria GPU fraccionada y exponer métricas. | Más memoria física o aislamiento universal por hardware. |
| KAI Resource Management | Representar proyectos, departamentos, grupos de nodos y derechos de uso. | Las prioridades del producto o el permiso para fusionar código. |
| Workload Map | Describir de forma consistente la estructura de distintos tipos de cargas Kubernetes. | Un flujo de verificación desde la tarea hasta el parche. |
KAI documenta cuotas jerárquicas, pesos para uso por encima de cuota, recuperación de recursos, reparto justo basado en el tiempo y asignación conjunta de cargas agrupadas. Son funciones distintas: la cuota define un derecho, la equidad resuelve la competencia y el gang scheduling ayuda a un trabajo distribuido a obtener su grupo de recursos. Ninguna demuestra que el resultado del trabajo sea correcto. Consulte las capacidades de planificación de KAI.
KAI Resource Management añade la estructura organizativa sobre esas colas. Resulta útil cuando varios equipos comparten capacidad GPU heterogénea. Aporta menos cuando un único equipo ya ejecuta trabajos previsibles sobre hardware dedicado. Examine la capa de gestión de recursos.
Run:ai sí tiene semántica propia. Workload Map comprende estructura, roles y estados, y permite que otras herramientas gestionen diferentes recursos de forma consistente. Lo que no expresa es si un parche generado satisface una necesidad del cliente. Esa es la distinción concreta que importa. Lea el alcance de Workload Map.
¿MIG, time-slicing y GPU fractioning son lo mismo?
No. Comparten hardware de formas diferentes y ofrecen límites diferentes. Comparar una GPU con una pizza es fácil de recordar. Pero oculta detalles importantes para la separación de usuarios y la latencia.
MIG crea instancias particionadas por hardware en GPU compatibles. NVIDIA describe recursos de cálculo y memoria dedicados, con aislamiento entre instancias. Los perfiles disponibles y su compatibilidad dependen de la GPU. Lea la introducción de NVIDIA a MIG.
El time-slicing permite que varias cargas utilicen la GPU por turnos. NVIDIA lo diferencia explícitamente de MIG: el time-slicing ordinario no ofrece aislamiento de memoria ni de fallos entre réplicas. Anunciar más unidades de recurso no crea más capacidad física. Compare las garantías de time-slicing de GPU Operator.
El nuevo GPU Fractioning Operator integra límites de memoria nativos de CUDA. Su documentación describe límites inyectados antes de arrancar el contenedor, aplicados por el controlador y acompañados de métricas por pod. Requiere, entre otros elementos, CUDA 13.4/r615 o posterior, un runtime de contenedores compatible con NRI y versiones adecuadas de GPU Operator, toolkit y device plugin. Son requisitos de ese mecanismo de fraccionamiento, no mínimos universales para cualquier instalación de Run:ai. Revise el comportamiento y todos los requisitos de compatibilidad.
| Mecanismo | Límite útil | Qué comprobar |
|---|---|---|
| MIG | Instancias particionadas por hardware en GPU compatibles. | Si un perfil admitido cubre la memoria del modelo, la caché y la latencia. |
| Time-slicing | Acceso compartido por turnos, sin aislamiento equivalente a MIG. | Contención, impacto de fallos y compatibilidad del nivel de confianza entre usuarios. |
| Fraccionamiento nativo de CUDA | Límites de memoria GPU aplicados por el controlador con software compatible. | Aplicación real del límite, falta de memoria e interferencias bajo carga. |
Un límite estricto de memoria no garantiza tokens por segundo constantes, igual tiempo de cálculo ni una frontera completa entre usuarios hostiles. Dimensione pesos, memoria de ejecución, caché de contexto y concurrencia. Dar menos memoria a un modelo demasiado grande no hace que quepa. La compresión y la inferencia distribuida son decisiones distintas.
Para la capa que sirve el modelo, consulte nuestro análisis de vLLM y Triton en producción. Run:ai puede gobernar la capacidad del servidor de inferencia. Ese servidor sigue siendo responsable de ejecutar y servir el modelo correctamente.
¿RBAC, SSO y OPA hacen seguros a los agentes de programación?
Controlan permisos y políticas concretos. No demuestran que el software sea correcto. La referencia de servicios de Run:ai documenta integración con proveedores de identidad, permisos por roles, políticas de cargas, auditoría y límites de ejecución. Son capacidades reales, aunque estén por debajo del agente. Revise los servicios de identidad, políticas y auditoría.
La mención de OPA necesita precisión. La guía de identidad revisada presenta Gatekeeper como una opción para aplicar controles de clúster en Kubernetes sin OpenShift. No demuestra que todas las instalaciones de Run:ai incluyan un conjunto completo y correctamente configurado de políticas OPA. Consulte los límites documentados de OpenShift y Gatekeeper.
El permiso para enviar una carga no debe convertirse en permiso para reescribir sus propias comprobaciones. Separe administración de infraestructura, credenciales del modelo, escritura en repositorios y aprobación de versiones. Pruebe las identidades de API y automatización, además del acceso por navegador. Una buena pantalla SSO no demuestra que las demás rutas estén restringidas.
| Decisión | Capa responsable | Evidencia necesaria |
|---|---|---|
| ¿Quién obtiene capacidad GPU? | Run:ai y el planificador configurado. | Registros de colas, cuotas, asignación y recuperación de recursos. |
| ¿Qué modelo recibe la petición? | Endpoint de inferencia y enrutamiento controlado por el operador. | Revisión del modelo, destino e identidad de la petición. |
| ¿Qué puede cambiar el agente? | Política de la tarea, sandbox y permisos del repositorio. | Commit base autorizado, alcance de escritura y pruebas de denegación. |
| ¿El parche cumple los requisitos? | Verificación y revisión independientes. | Hash del parche, definición de controles, resultados y observaciones. |
| ¿Puede publicarse esta versión? | Autoridad de publicación externa al agente. | Aprobación vinculada a la revisión exacta que se verificó. |
Este es nuestro modelo operativo propuesto. No afirmamos que Run:ai conecte automáticamente las cinco capas.
¿Dónde encaja ESF y existe una integración preparada?
En el proyecto citado, ESF significa Engineering Software Factory. Es un proyecto independiente con licencia MIT, derivado de Machinist. Su README describe Temporal coordinando agentes de programación en microVM de CubeSandbox, controles deterministas y conservación de parches y evidencias de ejecución. También aclara que ESF produce cambios para revisión, no decisiones de publicación. En el momento de la revisión, la versión 0.6.2 se describe como candidata a lanzamiento, no como una versión incondicionalmente validada para producción. Lea la arquitectura y las advertencias de madurez de ESF.
Eso permite que Run:ai y ESF sean complementarios. No demuestra que constituyan una solución integrada lista para usar. No verificamos un adaptador soportado entre ambos ni realizamos un despliegue conjunto. El entorno CubeSandbox de ESF no es intercambiable con una carga de Run:ai solo porque ambos aíslen trabajo.
Un experimento acotado mantendría el flujo y el sandbox de ESF. Sus agentes llamarían a un endpoint de modelo cuya capacidad GPU estuviera gestionada por Run:ai. Un identificador de correlación conectaría la ejecución de la fábrica, la petición de inferencia y los registros de infraestructura. No asigne una GPU dedicada a cada agente solo porque la inferencia necesite GPU en otra parte.
En este diseño propuesto, las cuotas GPU corresponden a los servicios de inferencia. Los límites de solicitudes y los presupuestos por agente deben aplicarse en el gateway o la aplicación y vincularse a las ejecuciones de la fábrica. Una asignación GPU compartida no es automáticamente un presupuesto para cada agente que llama al endpoint.
El contrato de aceptación debería vincular tarea, commit base, versión del harness, revisión del modelo, hash del parche, controles protegidos, resultados, decisión del revisor y limpieza del entorno. Los controles deben quedar fuera de los permisos de escritura del agente o someterse a una comprobación independiente de integridad. Un nuevo parche invalida la aprobación anterior.
Nuestra guía de ingeniería del harness cubre la capa general del flujo. El análisis de Google AX trata ejecución y recuperación de agentes. Aquí nos centramos en la frontera de capacidad GPU de Run:ai, no en otra comparación general de orquestadores.
¿Qué debe demostrar un piloto de Run:ai para una fábrica de software?
Empiece con dos proyectos de prueba, un repositorio desechable y un conjunto fijo de cargas. Registre la referencia antes de cambiar el planificador. Mantenga la calidad del modelo y los criterios de verificación mientras evalúa la infraestructura. Las siguientes son pruebas de aceptación propuestas, no resultados de un benchmark realizado por Wavect.
| Prueba | Condición de aceptación |
|---|---|
| Cuota y recuperación | Un equipo solo toma capacidad libre según la política; la demanda que regresa recupera su derecho sin bucles ilimitados de reinicio. |
| Límite de la fracción | Una asignación deliberadamente excesiva falla en la carga prevista y la carga vecina mantiene su objetivo de servicio. |
| Asignación agrupada | Un trabajo distribuido no ocupa capacidad parcial indefinidamente mientras espera componentes obligatorios sin asignar. |
| Identidad y evasión | UI, API, CLI y rutas MCP activas deniegan la misma acción no autorizada entre proyectos. |
| Desalojo y recuperación | Una ejecución interrumpida continúa o se reintenta desde un estado registrado sin duplicar escrituras externas ni aceptar resultados obsoletos. |
| Integridad de controles | Un parche no puede convertir un cambio fallido en aceptado debilitando las verificaciones. |
| Evidencia y aprobación | Cada cambio aceptado tiene evidencia exportable vinculada al parche exacto; el agente no puede aprobar su propia publicación. |
| Reversión y coste | El equipo puede restaurar el planificador o la política anterior y explicar la capacidad ganada junto con el esfuerzo operativo adicional. |
Mida espera en cola, latencia en los percentiles altos, trabajos completados, cambios rechazados, trabajo repetido y esfuerzo del operador. Una GPU más ocupada no representa éxito si las peticiones incumplen sus objetivos o los revisores reciben más parches defectuosos. Para el denominador económico general, consulte nuestra metodología de coste por acción de un agente de IA.
¿Debe adoptar Run:ai para controlar su propia IA?
Adóptelo cuando la capacidad GPU compartida sea una limitación importante y alguien pueda responsabilizarse de su operación. Un entorno Kubernetes con varios equipos y cargas de entrenamiento, inferencia y desarrollo que compiten es un candidato razonable. Un equipo que solo utiliza API, una estación local o un flujo bloqueado por pruebas poco fiables puede necesitar otra primera inversión.
Nuestra interpretación del cambio de mercado: la infraestructura abierta eleva el listón para productos que apenas reempaquetan planificación. No elimina el valor de operaciones fiables, flujos especializados, integraciones ni verificación. El propio anuncio de NVIDIA presenta un ecosistema de socios, no la desaparición de todas las empresas de software relacionadas.
“Ser dueño de su IA” resulta más útil como prueba operativa: ¿puede cambiar el modelo, controlar los destinos de datos, revocar credenciales, exportar evidencias y mover la carga? Un despliegue en la nube puede conservar esas opciones. Uno autoalojado puede seguir dependiendo mucho de un proveedor. Ninguna ubicación garantiza que el modelo actúe según sus intereses.
Antes de comprar más GPU, identifique si el cuello de botella es capacidad, inferencia, permisos o verificación. La ingeniería de IA de Wavect ayuda a separar esas decisiones. El caso Twinsoft AI ilustra entrega de aplicaciones, no un despliegue de Run:ai. Utilice nuestra lista de QA antes de publicar software para definir criterios, o comente con nosotros su flujo de GPU y agentes.
Preguntas sobre Run:ai open source y fábricas de software
¿Qué publicó NVIDIA como open source en octubre de 2026?
¿Run:ai open source exige una licencia de pago?
¿Qué diferencia hay entre Run:ai y KAI Scheduler?
¿GPU fractioning es lo mismo que MIG?
¿El fractioning permite alojar un modelo mayor en una GPU pequeña?
¿Run:ai sustituye CI/CD o la verificación de software?
¿Qué es ESF y está lista su integración con Run:ai para producción?
¿Todas las instalaciones de Run:ai incluyen políticas OPA?
¿Debería un equipo pequeño que solo usa API instalar Run:ai?
¿El autoalojamiento garantiza el control de la IA?
Reflexiones finales
Use Run:ai para repartir la capacidad GPU limitada. Use verificaciones independientes para decidir qué cambios generados se aceptan. El código abierto permite inspeccionar la primera capa, pero no hace opcional la segunda.