Durante una época, mi trabajo empezaba a las ocho de la mañana marcando por teléfono a unos diez conmutadores, uno por uno, para comprobar que el servicio de voz funcionaba.
No había tablero. No había alerta. Había una lista, un teléfono y yo. Si alguno no contestaba bien, ese era el problema del día y arrancaba antes de que el primer usuario se enterara.
Años después aprendí que eso tenía nombre —monitoreo sintético— y que se podía automatizar. Pero en su momento el sistema de detección temprana era una persona con una lista. Funcionaba porque eran diez.
Traigo esto porque este artículo es sobre qué pasa cuando ya no son diez, sino miles de piezas que se degradan sin avisar, y alguien te ofrece un software que promete vigilarlas por ti. Se llama NVIDIA Mission Control, y merece una lectura de Producto, no de folleto.
🔑 Lo esencial en 20 segundos
- Mission Control no es un producto nuevo: es un paraguas sobre piezas que ya existían por separado.
- Adentro vienen Base Command Manager, Run:ai, Slurm, NetQ, UFM y un conjunto de observabilidad.
- Lo verdaderamente distinto son las dos recuperaciones autónomas: la de trabajos y la de hardware.
- El folleto y el manual no dicen lo mismo sobre el control de energía y enfriamiento. Lo comprobé.
- Y un detalle con consecuencias: dentro viene Prometheus. Puede que ya estés comprando el stack abierto sin saberlo.
Qué es en realidad
Empiezo por lo que más ordena la conversación: Mission Control es una capa de gestión que agrupa herramientas que NVIDIA ya tenía, más el pegamento entre ellas y el soporte de todo el conjunto como una sola cosa.
Según la guía de administración de sistemas, esto es lo que trae dentro:
| La pieza | Para qué es |
|---|---|
| Base Command Manager | La gestión del clúster: aprovisionar el sistema operativo, actualizar firmware, configurar red, llevar inventario |
| Run:ai | Reparte las GPUs entre los trabajos y la gente que las pide. Es el planificador con criterio de IA |
| Slurm | El planificador clásico de cómputo de alto rendimiento, para quien ya trabaja así |
| Servicios de Kubernetes | Orquestan los servicios del sistema, con Prometheus para métricas y Loki para registros |
| NetQ y gestión de NVLink | Vigilar y diagnosticar el fabric de red y el interconector entre GPUs |
| Conjunto de observabilidad | Recolección de métricas, manejo de registros, tableros de salud y alertas |
Con la cocina de siempre: Mission Control es el jefe de cocina que no cocina. Reparte las estaciones, sabe quién está saturado, se entera antes que nadie de que una plancha dejó de calentar, y decide qué platillo se hace primero. No mejora las recetas. Hace que la cocina no se detenga.
Y esto es lo primero que yo aclararía en una propuesta, porque cambia la conversación de compra: si te lo presentan como una capacidad nueva, es una lectura de folleto. Lo que estás comprando es integración y soporte único de piezas que existían. Eso puede valer muchísimo —lo digo en serio— pero se negocia distinto que una tecnología nueva.
Lo que sí es diferente: las dos recuperaciones autónomas
Aquí está la parte que a mí me parece la más interesante del conjunto, y la que no existía antes bajo un mismo techo.
Son dos mecanismos con nombre propio en la documentación:
- Recuperación autónoma de trabajos. Cuando un entrenamiento falla por algo recuperable, se reinicia solo, retomando desde un punto de control en lugar de desde cero. Se integra con los dos planificadores.
- Recuperación autónoma de hardware. Vigila la salud del equipo de forma continua, detecta la falla, aísla la pieza mala y sigue.
Nombres, alcance y versiones por arquitectura de las dos recuperaciones: guía de administración de NVIDIA Mission Control.
Y por qué importa tanto en este contexto: en un entrenamiento largo con miles de GPUs, una pieza que falla no arruina su parte, arruina el trabajo entero. Todas las GPUs se esperan unas a otras, así que una que se cae deja al resto sin poder avanzar. Sin reinicio desde punto de control, eso son horas o días de cómputo carísimo tirados.
La disciplina detrás es exactamente la de operaciones de siempre: detectar, aislar, seguir operando degradado, arreglar después. Lo que cambia es que a esta escala ya no hay una persona con una lista. Lo que yo hacía a las ocho de la mañana con diez conmutadores, aquí lo tiene que hacer el software, todo el tiempo, sobre miles de piezas.
Fíjate en una cosa: eso es una decisión de arquitectura, no una función que se prende. Para que un trabajo se reanude desde un punto de control, alguien tuvo que diseñar cada cuánto se guardan esos puntos, dónde, y cuánto cuesta guardarlos. Es una conversación de almacenamiento y de tiempo perdido aceptable, y se tiene antes de comprar.
Lo que dice el folleto y lo que dice el manual
Aquí va la parte que me hizo levantar la ceja, y la cuento porque es el trabajo que uno hace en Producto.
Leí las dos fuentes. La página comercial promete visibilidad en tiempo real del rendimiento, la energía y el enfriamiento, políticas de energía a nivel de clúster conscientes del trabajo en curso, detección rápida de fugas con integración al sistema del edificio, y dos cifras llamativas: operar al 85% de potencia conservando el 93% del rendimiento, y recuperarse diez veces más rápido sin intervención manual.
Después leí la guía de administración, que es el documento que usa quien opera aquello. Enumera con detalle los componentes, las dos recuperaciones autónomas, el conjunto de observabilidad y la gestión de red. Y sobre control de energía y enfriamiento, no hace ninguna afirmación explícita.
💡 Lo que eso significa, y lo que no
No estoy diciendo que la página comercial mienta. Estoy diciendo que la capacidad que más me interesaría de todo el conjunto es la que menos respaldo tiene en la documentación operativa, y que eso es precisamente lo que hay que preguntar en una demostración, con el manual abierto.
Una vez en mi empresa contrataron a un experto en un marco de desarrollo de producto. Juntó a veinte personas en una sala y se dedicó a leernos sus diapositivas. Salí de ahí con una convicción que no se me ha ido: el conocimiento aplicado vale más que la presentación, y una lámina nunca es una demostración.
Aplicado a esto: las dos cifras del folleto son buenas noticias si se pueden reproducir en tu instalación, con tu carga y tu planta eléctrica. Son marketing si solo viven en la lámina. La diferencia entre las dos cosas es una prueba, y la prueba se pide antes de firmar, no después.
El detalle que casi nadie nota: adentro viene Prometheus
Vuelvo a la tabla de componentes, a la fila de los servicios de Kubernetes: ahí están Prometheus para métricas y Loki para registros.
O sea que el stack abierto de observabilidad no es una alternativa a esto. Ya viene adentro.
Y eso cambia dos conversaciones a la vez. La primera, de arquitectura: si tu equipo ya sabe operar esas herramientas, ese conocimiento no se tira. La segunda, de contrato: hay que saber qué parte de lo que estás comprando es software abierto empaquetado y qué parte es propiedad del fabricante, porque no se negocian igual y no se sustituyen igual.
De eso hablo la semana que viene y en el artículo del stack abierto, así que aquí solo dejo la pregunta plantada: ¿qué de esto podría yo operar sin la licencia, y qué no?
Y la capa de abajo ya la conoces
Una aclaración para que no se repita nada: la telemetría fina de cada GPU no vive aquí. Vive una capa más abajo, en DCGM, que es de lo que ya escribí en cómo se observa una GPU de verdad.
La relación es esta: DCGM te dice qué le pasa a una GPU. Mission Control decide qué hacer cuando eso le pasa a una de miles, mientras hay trabajos corriendo. Son capas distintas y ninguna sustituye a la otra.
Qué preguntar antes de firmar
| La pregunta | Por qué |
|---|---|
| ¿Qué de esto no tendría si compro solo Base Command Manager? | Separa lo que es integración y soporte de lo que es capacidad nueva. Cambia la negociación |
| Enséñame la recuperación autónoma en vivo, tirando una pieza | Es la función que justifica el conjunto. Verla es distinto a que te la cuenten |
| ¿Cada cuánto se guardan los puntos de control y cuánto almacenamiento piden? | Sin eso, reanudar un trabajo no existe. Es una decisión de arquitectura con costo |
| Las cifras de energía y rendimiento, ¿en qué condiciones se midieron? | Están en la página comercial y no en la guía de administración. Que las reproduzcan con tu carga |
| ¿Qué componentes son software abierto empaquetado? | Prometheus y Loki vienen dentro. Saberlo cambia qué puedes sustituir y qué no |
| ¿Esto reemplaza a mi plataforma de observabilidad actual? | Casi nunca. Vigila la fábrica, no tu negocio. Y las dos van a coexistir |
| ¿Qué pasa cuando el clúster crece o cambia de generación? | Varias funciones están disponibles solo en ciertas arquitecturas y versiones. Conviene leer la letra chica |
Preguntas frecuentes
¿Qué es NVIDIA Mission Control?
Es la capa de software con la que NVIDIA propone operar un centro de datos de IA completo. Agrupa piezas que ya existían por separado —Base Command Manager, Run:ai, Slurm, NetQ, gestión de NVLink y un conjunto de observabilidad con Prometheus y Loki— y añade recuperación autónoma de trabajos y de hardware, todo con soporte como un solo producto.
¿Qué es la recuperación autónoma y por qué importa?
Son dos mecanismos: uno reinicia un trabajo fallido desde un punto de control en lugar de desde cero, y el otro vigila la salud del hardware, detecta la falla y aísla la pieza mala. Importa porque en un entrenamiento con miles de GPUs que se esperan unas a otras, una pieza que falla detiene el trabajo completo, y eso son horas o días de cómputo perdidos.
¿Mission Control reemplaza mi plataforma de observabilidad?
Casi nunca. Vigila la infraestructura de la fábrica de IA: salud del clúster, trabajos, red y hardware. Tu plataforma de observabilidad vigila el servicio que el negocio consume. En la práctica coexisten, y conviene decidir desde el principio qué se mira en cada una para no pagar dos veces por lo mismo.
¿Mission Control controla la energía y el enfriamiento?
La página comercial de NVIDIA promete visibilidad en tiempo real de energía y enfriamiento, políticas de energía conscientes del trabajo y detección de fugas integrada al edificio, además de operar al 85% de potencia conservando el 93% del rendimiento. La guía de administración de sistemas, en cambio, no hace afirmaciones explícitas sobre control de energía o enfriamiento. Es exactamente lo que conviene pedir demostrado antes de firmar.
¿Qué diferencia hay entre Mission Control y DCGM?
DCGM es la capa de telemetría de cada GPU: dice qué le está pasando a una tarjeta en concreto. Mission Control está una capa arriba y decide qué hacer cuando eso ocurre en una de miles, con trabajos corriendo. Son complementarias y ninguna sustituye a la otra.
Lo que me llevo de esto
Después de tres artículos hablando de cosas que se degradan sin avisar —un puerto mal afinado, una hoja de red que aísla GPUs, una biblioteca que te amarra— era obligatorio preguntarse con qué se miran. Y la respuesta que ofrece el fabricante es razonable: un paraguas sobre lo que ya tenía, con dos automatismos que a esta escala dejaron de ser un lujo.
Lo que no cambia es el oficio. Alguien tiene que decidir qué se vigila, cada cuánto, y qué se hace cuando salta. Yo eso lo hacía con un teléfono y una lista de diez conmutadores. La herramienta creció una barbaridad; la pregunta es la misma.
La próxima semana bajamos al piso, literalmente: energía y enfriamiento. Porque de todos los proyectos de este tipo que he visto tropezar, los que se caen no se caen por software. 🔌
Que los sistemas estén con ustedes. ✦
Imagen destacada generada con inteligencia artificial.
Ethel Méndez
Senior Product Manager en observabilidad y redes B2B, con 20 años de campo, NOC y servicios administrados en LATAM. Escribo lo que aprendí operando sistemas de verdad, no en un curso.