Cómo se observa una GPU de verdad: DCGM, OpenTelemetry y el auge de las AI factories

Durante años, en el NOC, la pregunta era siempre la misma: “¿el nodo está sano?”. CPU, memoria, disco, red. Cuatro señales, un semáforo, y a dormir. Hoy esa pregunta cambió de sujeto. El “nodo” ahora es una GPU —o un clúster entero de ellas— entrenando o sirviendo un modelo, y las métricas que importan ya no son las de siempre. 🤖 La buena noticia: la lógica de operaciones que aprendiste vigilando servidores se traduce casi directo a este mundo nuevo. Solo cambian los sensores.

Con NVIDIA empujando su hardware a cada data center de IA de la región, saber cómo se observa una GPU de verdad pasó de curiosidad a habilidad de producto. Y casi nadie lo explica en español. Si vienes llegando a este tema, quizá te ayude leer primero qué es observabilidad y en qué se diferencia del monitoreo, porque aquí voy a asumir esa base y a saltar directo a lo que cambia con las GPUs.

¿Por qué una GPU no se observa como un servidor normal?

Porque el recurso caro y escaso es distinto. En un servidor tradicional peleas por CPU y memoria; en una GPU, lo que se desperdicia —o se rompe— vive en otras métricas. Una tarjeta puede estar al 100 % de “uso” según el sistema operativo y, aun así, tener sus tensor cores casi ociosos porque el job está mal balanceado. Ahí se está quemando presupuesto sin que ninguna alerta clásica suene.

Lo viví de otra forma en la era del NOC: un enlace podía reportar “up” y latencia baja, pero si mirabas solo eso te perdías el jitter que estaba tumbando las llamadas de voz. La lección es la misma. La métrica cómoda —la que trae el sistema operativo de fábrica— rara vez es la métrica que te avisa del problema real. Con GPUs pasa idéntico: nvidia-smi te da un número de utilización que tranquiliza, mientras el hardware que pagas a precio de oro trabaja a media máquina.

¿Y de dónde salen las métricas buenas? De DCGM, la capa oficial de NVIDIA que expone contadores a nivel de streaming multiprocessor, tensor cores, enlaces NVLink y memoria con corrección de errores. No es un agente exótico: es la fuente de la verdad que la propia NVIDIA usa en sus herramientas. Estas son las señales que de verdad importan, y su paralelo con el mundo NOC:

De esas cuatro, la temperatura es la que más se subestima —y la que a mí me enseñó la lección más cara—. Hace años, en un centro de datos, un corte de luz dejó sin aire acondicionado a la sala. Nadie se enteró: no había un solo sensor de temperatura mirando ese cuarto. Lo supimos hasta que los servidores empezaron a apagarse solos, sofocados. Cuando bajamos y abrimos la puerta de cristal del site, salió un golpe de aire de más de 40 °C. El calor no disparó ni una alarma; solo mató el servicio en silencio. 🔥

Con las GPUs el patrón es el mismo, pero más traicionero: el calor rara vez te apaga la tarjeta de golpe. Primero te roba rendimiento con el thermal throttling —la GPU baja su propio reloj para no quemarse— y tú sigues pagando el 100 % por una tarjeta que rinde al 70 %, sin que nada “falle”. Por eso DCGM_FI_DEV_GPU_TEMP no es una métrica de adorno: es la diferencia entre ver el problema o pagarlo a ciegas.

El día que el calor apagó el centro de datos

Mucho antes de que alguien dijera “AI factory” me tocó una lección sobre temperatura que no se me ha ido.

Un corte de luz apagó el aire acondicionado de un centro de datos. Nadie se dio cuenta: no había un solo sensor de temperatura en ese cuarto. El calor fue subiendo en silencio hasta que los servidores empezaron a apagarse solos por protección térmica.

Nosotros estábamos en el piso nueve y los equipos en el quinto. Tuvimos que bajar físicamente a ver qué pasaba, y al abrir la puerta de cristal del site salió un golpe de aire caliente que se sentía como un horno. La alarma fue mi piel, no una consola.

Entramos a decidir qué apagar a mano, de forma controlada, en vez de esperar a que cada equipo se cortara solo: un apagón térmico brusco corrompe datos y alarga muchísimo el levantón.

Cuento esto en un artículo sobre GPUs porque aquí el problema no desapareció, se multiplicó. Un servidor tradicional que se calienta se apaga y te deja un hueco evidente. Un bastidor de GPUs entrenando un modelo consume y disipa en otro orden de magnitud, y su rendimiento se degrada mucho antes de apagarse: baja su frecuencia para protegerse, y tu entrenamiento se vuelve más lento y más caro sin que nada aparezca como caído.

Por eso las métricas térmicas y de consumo no son un adorno en la observabilidad de GPU. Son la señal principal, y son las que te avisan cuando todavía puedes hacer algo.

El camino práctico: DCGM → OpenTelemetry → tu backend

La parte buena es que no tienes que inventar nada. NVIDIA expone las métricas con DCGM, el DCGM Exporter las publica en formato Prometheus, y desde ahí OpenTelemetry las recoge y las manda a donde ya tengas tu observabilidad. Si vienes de mi artículo sobre OpenTelemetry y trazas en microservicios, esto te va a sonar familiar: es el mismo Collector, otra fuente de datos.

El DCGM Exporter corre como un servicio junto a tus nodos y publica las métricas en un endpoint HTTP, por defecto el puerto 9400. Guías prácticas como la de OpenObserve lo describen igual: levantas el exporter, lo raspas con un scrape de Prometheus y las métricas quedan listas para tu backend. La de OneUptime, centrada en cargas de machine learning, insiste en el mismo punto que yo defiendo desde el NOC: mide la utilización real, no la nominal, o tomarás decisiones de capacidad con datos falsos.

Y no se queda en las métricas del hardware. NVIDIA NIM —el runtime de inferencia— ya expone logging estructurado, métricas Prometheus y trazas OpenTelemetry, según la documentación de NVIDIA. Eso significa que la inferencia de tu modelo puede aparecer dentro de tus trazas distribuidas, junto al resto de la aplicación. El “GPS” de la petición ahora llega hasta la GPU. 🛰️

Caso trabajado: observar un clúster de entrenamiento

Bajemos a tierra. Supón un clúster de ocho nodos con GPUs entrenando un modelo interno, y un equipo que ya tiene Datadog para el resto de su plataforma. La pregunta operativa es la de siempre: ¿estos nodos están sanos y estamos aprovechando lo que cuestan? Vamos a armar la observación desde cero, con la misma disciplina con la que instrumentabas un rack en el NOC.

1. Conectar el DCGM Exporter al OpenTelemetry Collector

El corazón del montaje es un receiver de Prometheus dentro del Collector que raspa el DCGM Exporter —vive en el puerto 9400— cada quince segundos, y reenvía esas métricas por OTLP al backend que uses: Datadog, Splunk, Grafana o el que sea.

Entre lo que entra y lo que sale hay un paso que es el que de verdad importa, y es el que casi nadie pone: la detección de recursos, que etiqueta cada métrica con su host y su nodo antes de enviarla.

Sin esas etiquetas tendrás un mar de métricas anónimas y no podrás decir qué GPU está fallando. En el NOC eso equivalía a tener alarmas sin saber de qué sitio venían: ruido puro. La instrumentación sin contexto no sirve.

2. El ejemplo numérico que revela dinero tirado

Aquí está el momento que justifica todo el ejercicio. Imagina que abres el dashboard y una GPU marca 100 % de utilización según DCGM_FI_DEV_GPU_UTIL, la métrica cómoda, la que también te muestra nvidia-smi. Todo verde, aparentemente. Pero al lado, DCGM_FI_PROF_PIPE_TENSOR_ACTIVE —la actividad real de los tensor cores— marca 0,25, es decir, un 25 %.

Traducción: la GPU está encendida y ocupada el 100 % del tiempo, pero sus unidades de cálculo de matrices, las que de verdad entrenan el modelo, trabajan una cuarta parte del tiempo. Las otras tres cuartas partes las pasa esperando datos, moviendo memoria o mal alimentada por un pipeline de entrada lento. Estás pagando una GPU completa y usando el equivalente a un cuarto de ella. 💸

Ese es el hallazgo que ninguna alerta clásica te da. Y no requiere magia: basta graficar DCGM_FI_PROF_PIPE_TENSOR_ACTIVE junto a la utilización nominal y observar la brecha. Cuando la de arriba está pegada al techo y la de abajo languidece, tienes una conversación de negocio, no solo técnica: o mejoras el data loader, o consolidas cargas, o reduces la flota. Cualquiera de las tres se paga sola.

3. Las 3-4 métricas DCGM que alertaría primero

Si tuviera que empezar mañana con presupuesto de alertas limitado, priorizaría estas, en este orden, por la misma lógica de “salud de nodo” del NOC:

• Utilización de tensor cores (DCGM_FI_PROF_PIPE_TENSOR_ACTIVE). No predice una caída, predice desperdicio. Es la métrica de dinero. Alerta cuando queda baja de forma sostenida mientras el job dice estar corriendo.
• Throughput de NVLink (DCGM_FI_PROF_NVLINK_TX_BYTES / RX). En entrenamiento distribuido, la comunicación entre GPUs suele ser el cuello de botella real. Si el NVLink se satura, sumar GPUs no acelera nada, solo encarece.
• Errores ECC de doble bit (DCGM_FI_DEV_ECC_DBE_VOL_TOTAL). Los de un bit se corrigen solos; los de doble bit no, y suelen anteceder a la muerte del job o de la tarjeta. Es tu alarma de “esto se va a caer”, el equivalente al disco que empieza a devolver sectores malos.
• Temperatura (DCGM_FI_DEV_GPU_TEMP). Cuando sube demasiado, la GPU baja su reloj sola —thermal throttling— y pierdes rendimiento sin que nada “falle”. Es el enemigo silencioso: no dispara errores, solo te hace lento y caro.

Con esas cuatro señales cubres las dos preguntas que de verdad importan: ¿estoy aprovechando lo que pago? (tensor cores, NVLink) y ¿esto se va a romper? (ECC, temperatura). Todo lo demás es refinamiento.

Lo nuevo de NVIDIA en 2026: monitoreo de flota y “AI factories”

Dos movimientos recientes cambian el panorama y conviene entenderlos como decisiones de producto, no solo como notas técnicas:

• Servicio de monitoreo de flota de GPUs. Según el anuncio de NVIDIA (junio 2026), NVIDIA planteó un servicio de telemetría opt-in y de solo lectura: cada sistema envía métricas operativas a un dashboard centralizado que la compañía planea liberar como open source. NVIDIA aclaró explícitamente que no incluye kill-switches ni backdoors, un punto sensible para operadores de infraestructura crítica.
• NVIDIA Mission Control. Presentado en GTC 2026, es un plano de control de “AI factory” que reúne salud del clúster, cuotas, despliegues de modelos y chargeback, apoyado en telemetría DCGM. Es NVIDIA diciendo, en la práctica, que la observabilidad del clúster es parte del producto, no un extra.

Lo que me llama la atención de ambos es la dirección: NVIDIA está construyendo la capa de operaciones por encima del hardware, y lo hace apoyándose en DCGM, exactamente el mismo estándar que tú puedes usar hoy sin esperar a nadie. Si aprendiste a leer DCGM ahora, hablas el idioma que estas plataformas van a hablar mañana. Eso es ventaja de tiempo.

¿Cómo empezar sin comprar nada nuevo?

Si ya tienes Datadog, Splunk o Grafana, tienes el 80 % del camino andado. La observabilidad de GPU no exige un stack aparte; exige apuntar el que ya tienes a una fuente nueva. Y la decisión de dónde vive ese stack —nube o on-premise— tiene los mismos matices que cualquier otra plataforma, algo que desarrollé en nube vs. on-premise en observabilidad. El plan mínimo es corto:

1. Despliega el DCGM Exporter en tus nodos con GPU (puerto 9400).
2. Conéctalo a tu OpenTelemetry Collector vía el receiver de Prometheus, como en el YAML de arriba.
3. Crea alertas sobre utilización de tensor cores baja (dinero desperdiciado) y errores ECC de doble bit en aumento (falla inminente).
4. Suma NVLink y temperatura como segunda capa, para entrenamiento distribuido y throttling.
5. Si sirves modelos con NIM, activa la exportación de trazas OTel para verlos en tu APM.

Un consejo de campo: no arranques con veinte métricas. Arranca con la brecha tensor-core-vs-utilización en una GPU y deja que ese número incómodo haga el trabajo de convencer a tu equipo. La primera vez que alguien vea que paga cuatro y usa uno, el resto del proyecto se aprueba solo.

Preguntas frecuentes

¿Necesito una herramienta especial para monitorear GPUs de NVIDIA?

No necesariamente. DCGM y el DCGM Exporter (gratuitos, de NVIDIA) exponen las métricas en formato Prometheus, y desde ahí las integras con OpenTelemetry y tu backend actual. La herramienta especial es opcional; el estándar abierto, no.

¿Qué métrica de GPU debería vigilar primero?

La utilización de tensor cores (DCGM_FI_PROF_PIPE_TENSOR_ACTIVE). Una GPU puede reportar 100 % de uso y aun así tener sus tensor cores ociosos: ahí se esconde el mayor desperdicio de presupuesto en cargas de IA. Compara esa señal contra la utilización nominal y verás la brecha.

¿El monitoreo de flota de NVIDIA envía mis datos a NVIDIA?

Según el anuncio de NVIDIA, el servicio anunciado es opt-in y de solo lectura, sin kill-switches ni backdoors, y NVIDIA planea liberar el componente como open source. Como con cualquier telemetría hacia un tercero, conviene revisar qué se envía antes de activarlo.

¿Puedo ver la inferencia de mi modelo dentro de mis trazas distribuidas?

Sí. NVIDIA NIM expone trazas OpenTelemetry, además de logging estructurado y métricas Prometheus. Al activarlas, la llamada al modelo aparece dentro de la misma traza que el resto de tu aplicación, junto a las métricas de hardware que da DCGM.

✍️ Creado por Ethel Méndez — Senior Product Manager en observabilidad, con certificación Cisco AI Infrastructure y Master de IA en curso.

Imagen destacada generada con inteligencia artificial.