Índice de contenidos
Claves de la noticia
- Nvidia anuncia nuevas contribuciones abiertas para la infraestructura Vera Rubin y cuatro componentes de software DSX en OCP.
- Los cuatro repositorios enlazados muestran Apache 2.0; Config Manager se declara en Developer Preview y el proveedor de Cluster API, experimental.
- Detectar un nodo defectuoso, aislarlo e instalar Kubernetes siguen siendo tareas distintas: los repositorios delimitan quién realiza cada una.
Nvidia ha presentado este 12 de octubre una nueva apertura de su infraestructura para fábricas de IA. El anuncio de OCP combina diseños de racks y software operativo. La revisión de sus cuatro repositorios permite precisar qué puede reutilizarse y qué trabajo sigue en manos del operador.
La apertura llega a los racks y a su operación
El anuncio oficial de Nvidia recoge contribuciones de diseños Vera Rubin mediante MGX y nuevos componentes abiertos de DSX. El objetivo declarado es facilitar infraestructura compatible para centros de datos. Abrir esas interfaces no equivale a publicar el diseño completo de los chips ni a convertir todas las piezas del sistema en intercambiables.
MGX 1.2 incorpora refrigeración líquida con conexión ciega y soporte para equipos de 19 pulgadas. Nvidia describe racks de hasta 250 kW. Esa cifra expresa una capacidad de despliegue del diseño, no el consumo medido de cualquier instalación ni una mejora automática de eficiencia. El suministro eléctrico y la refrigeración deben dimensionarse para la configuración concreta.
La página de MGX presenta una arquitectura modular para que los fabricantes desarrollen servidores. El interés de una interfaz común es reducir decisiones particulares de integración. Un operador puede conservar procedimientos compatibles entre equipos, pero todavía necesita comprobar la lista de hardware y el soporte de cada componente antes de comprarlo.
Cuatro repositorios, cuatro responsabilidades
La parte de software del anuncio se puede contrastar directamente con el código publicado. Un recuento de los cuatro repositorios enlazados muestra que los cuatro identifican Apache 2.0. Dos añaden avisos explícitos de madurez: Config Manager está en Developer Preview y el proveedor para NVIDIA Infrastructure Controller tiene soporte experimental.
| Componente | Función documentada | Límite relevante |
|---|---|---|
| Config Manager | Configuración y aprovisionamiento de red | Developer Preview; no recomendado para producción |
| Cluster Readiness Engine | Pruebas y detección de nodos defectuosos | No aísla los nodos |
| Rack Management Service | Inventario, energía y firmware del rack | Compatibilidad por hardware |
| Proveedor Cluster API para NICo | Aprovisionamiento de máquinas físicas | Experimental; no instala Kubernetes |
El método del recuento consiste en leer la licencia y las advertencias de los README de esos cuatro destinos, sin extender el resultado a todo DSX. Código abierto y preparación para producción son condiciones diferentes. La tabla muestra dónde termina una función, además de nombrar lo que automatiza.
Configurar la red exige una fuente de inventario
Config Manager reúne configuración, aprovisionamiento inicial y flujos de trabajo. Su README explica que Nautobot es el proveedor de referencia incluido, no una dependencia obligatoria del núcleo. Eso permite distinguir el servicio de automatización de la fuente que describe los equipos y sus conexiones.
La consecuencia operativa es concreta: automatizar una configuración no garantiza que el inventario del que parte sea correcto. Antes de aplicar cambios a gran escala, el operador debe validar esa fuente y ensayar el resultado. Además, el aviso de Developer Preview desaconseja presentar la herramienta como un sustituto listo para una red de producción.
Certificar un clúster no retira la máquina averiada
Cluster Readiness Engine ejecuta cargas de entrenamiento y comunicación distribuida para evaluar grupos de nodos. Informa de las máquinas que fallan y del motivo. El repositorio aclara que no aplica por sí mismo las operaciones de aislamiento de Kubernetes: no marca ni modifica los nodos para retirarlos del servicio.
Ese detalle acota la promesa comercial de reducir fallos antes del entrenamiento. Detectar un problema es una etapa; impedir que el planificador vuelva a utilizar la máquina es otra. Si el operador conecta solo el informe y deja pendiente la respuesta, el diagnóstico no evita que una carga posterior encuentre el mismo equipo.
El resultado citable del cruce documental es que la validación abierta de Nvidia necesita una política externa de retirada de nodos. No se trata de un fallo descubierto en el programa, sino de una frontera de responsabilidad escrita en su documentación. Integrarla con la operación existente es parte del despliegue, no un efecto automático de instalar el controlador.
Un servicio de rack y un proveedor de máquinas
Rack Management Service ofrece una API gRPC para inventario, control de energía, firmware y configuración de switches. Habla con controladores de gestión y otros dispositivos a través de interfaces específicas. Las tareas largas se ejecutan como trabajos asíncronos que el cliente consulta hasta su finalización.
Por eso una respuesta inicial no basta para acreditar que el firmware ya se ha actualizado. Un panel que solicite el trabajo debe seguir su estado y distinguir finalización de aceptación. El repositorio incluye una lista de compatibilidad: el código abierto no sustituye la verificación del equipo que va a recibir esas órdenes.
El proveedor Cluster API para NICo cumple una función distinta: consigue las máquinas físicas que Cluster API solicita. Su README indica expresamente que no instala Kubernetes ni une los nodos al clúster. Esas tareas corresponden a los proveedores de arranque y del plano de control.
La separación permite reutilizar un flujo de Cluster API con otra infraestructura, pero conserva prerrequisitos: controlador físico, credenciales, imagen del sistema y componentes de arranque. La automatización se vuelve componible; no desaparecen las piezas que deben estar preparadas. El nivel experimental obliga además a evaluar la compatibilidad de versiones.
Estas novedades complementan el nuevo formato óptico USFP y la distribución de agentes de AMD Helion, que abordan problemas diferentes. La aportación inmediata de los repositorios es permitir inspeccionar licencias, funciones y límites. Para un operador español, esa evidencia resulta más útil que interpretar «abierto» como una garantía de intercambiabilidad total.
Imagen: ilustración conceptual generada de mantenimiento de servidores; no representa un rack Vera Rubin real.
