GPU monitoring: monitorización de GPUs para IA y entornos híbridos

En los buenos tiempos que dirían algunos, cuando no era necesaria una hipoteca para adquirirla, la GPU (Graphics Processing Unit) era ese componente que solo importaba a los que querían jugar Crysis a toda resolución. Hoy es el reactor de antimateria que mueve media industria: el entrenamiento de modelos IA, inferencia, machine learning, simulación, rendering, análisis de datos y HPC (High-Performance Computing). Sin GPUs no hay IA, y sin IA, según dicen los visionarios (que la venden), no hay futuro. Uno que, según esos mismos, quizá quede destruido de todos modos por esa misma inteligencia artificial.
Pero en muchos casos, el corazón de diamante de la infraestructura permanece sin supervisión.
Se monitorizan con ojo de halcón servidores, CPU, red, servicios… pero las GPUs siguen siendo el punto ciego más caro, que si dejas desatendido puede convertirse en un agujero en el bolsillo.
De ahí que el verdadero reto no sea medir la GPU solamente, sino integrarla en la monitorización de infraestructuras on-premise, híbridas y cloud.
Aquí veremos cómo.

Qué es GPU monitoring o monitorización de Unidades de Procesamiento Gráfico

El GPU monitoring es la supervisión continua del estado, uso, memoria, temperatura, consumo, disponibilidad y errores de las GPUs. Que dicho así, suena a panel de control de nave estelar… y no andamos lejos.
Es obvio dada la introducción, pero para que quede claro, aquí no hablamos de overclocking ni exprimir frames, sino de monitorización de recursos críticos usados por cargas de IA, HPC o procesamiento intensivo, dentro de una estrategia profesional de monitorización de infraestructura.

Por qué el GPU monitoring importa en infraestructuras de IA

Las GPUs sirven para acelerar las operaciones críticas de una organización, pero como nada sale gratis en la vida, a cambio introducen riesgos operativos nuevos. Eso las convierte a la vez en el motor de cualquier proyecto IA y su talón de Aquiles.
¿Por qué?

• Porque son recursos (cada vez más) caros y limitados. Cada tarjeta inactiva o saturada, igual que cada minuto de downtime, es dinero yéndose por el desagüe.
• La saturación afecta a la inferencia y el entrenamiento. Una GPU que resopla al límite ralentiza respuestas y alarga trabajos que, ya de por sí, tardan.
• La falta de memoria provoca errores o degradación. Un out of memory en mitad de un entrenamiento es la pantalla azul de la muerte de nuestros días, solo que mucho más cara.
• La temperatura impacta en el rendimiento y la disponibilidad, ya que, como pasa también con los humanos, el calor degrada y mucho calor apaga.
• La infrautilización dificulta justificar la inversión y obliga a dar explicaciones cuando dirección mira la columna de gastos que ocupa tres hojas de papel continuo.
• El histórico permite decidir sobre capacidad, pero la falta de visibilidad complica nuestra operación con entornos híbridos, on-premise y cloud.

La conclusión es que dejar a la GPU fuera de la foto de familia de la monitorización es una locura en estos tiempos que nos han tocado.

El hueco real: GPU monitoring para entornos on-premise, híbridos y enterprise

Existe la creencia extendida de que la IA vive en la nube, en un centro de datos gestionado por otros y que devasta un ecosistema lejano al nuestro. Sin embargo, muchísimas organizaciones operan GPUs en sus propios datacenters, en entornos híbridos, centros de investigación, industria, instancias cloud con GPU…
Y muchas de esas organizaciones operan bajo requisitos de confidencialidad, soberanía de datos o legislaciones sobre los mismos donde una solución 100% nube no es viable, bajo pena de multa o riesgo de filtraciones peligrosas.
En esos casos, no basta con instalar Ollama o similares y olvidarnos, ni la documentación de turno de un proveedor cloud es suficiente para operar con garantía y eficiencia.
Necesitamos una plataforma capaz de vigilar todo, las GPUs y el resto de la infraestructura en conjunto, ya sea en servidores propios o entornos virtuales.
El debate que nunca termina entre on-premise y SaaS, o los requerimientos de las infraestructuras hiperconvergentes refuerzan nuestra necesidad de control. Porque una GPU puede vivir on-premise, en un ecosistema híbrido o una instancia de nube, pero su impacto afecta a servicios, red, procesos, APIs, aplicaciones….
De ahí la necesidad de juntarse un poco para que la GPU quepa en esa foto de familia e incluirla en la monitorización global, no como una métrica de verso suelto en una pestaña que nadie abre.
Y hablando de ellas…

Las métricas clave en GPU monitoring

Debemos vigilar, vale, pero ¿qué exactamente?
Las métricas de una estrategia de GPU monitoring que se precie de llamarse así son (además de su número y nombres):

• Estatus de la GPU (su estado operativo).
• Utilización de GPU (en porcentaje de uso).
• Memoria de la GPU usada / libre / total (estado general de la memoria, tanto en bruto como en porcentaje).
• Temperatura de la GPU para saber si el reactor de curvatura de la IA va a explotar o no.
• Energía que consume y límite para evitar facturas como la capa de Superman.
• Velocidad del ventilador cuando esto aplica, claro, como veremos enseguida.
• Errores críticos.
• Versiones de driver NVIDIA y CUDA.

Un par de matices porque en ellos se esconde lo que nos evitará disgustos.
Los errores críticos no son una métrica universal. En un centro de datos con soporte ECC, como las A100, H100, Tesla o RTX PRO, son relevantes, pero en las de nivel consumidor (como una GeForce RTX o similares), la utilidad de línea de comandos de NVIDIA nvidia-smi puede devolver N/A para los errores ECC.
Así, nuestro plugin de Pandora FMS, por ejemplo, emitirá 0 por diseño. Ese eterno cero no significa que la tarjeta sea inmortal, simplemente, no hay nada que contar.
Por otro lado, la velocidad de ventilador solo tiene sentido en tarjetas con ventilación activa (D’oh, que diría Homer Simpson). En GPUs de servidor o entornos fanless no aplicaría, claro.
Es por eso que un plugin de monitorización como el nuestro permite omitir ese módulo con –include-fan=false, ya que la telemetría avanzada consiste también en saber qué no medir para no saturar con ruido.

nvidia-smi, DCGM y plataformas de monitorización: qué aporta cada una

Ya hemos visto el qué, ahora toca ver el cómo monitorizamos y también diferenciar entre herramientas, porque se confunden con facilidad.
Analicemos qué aporta cada una.
Por un lado tenemos nvidia-smi, que ya ha asomado la patita y es la utilidad de línea de comandos que permite consultar información de las GPUs NVIDIA. Hablamos de su utilización, memoria, temperatura, consumo, procesos, driver, CUDA…
Este es el tricorder de la GPU, lo apuntas, lees una cifra y sigues tu camino. Perfecto para diagnóstico puntual o algún script de madrugada.
NVIDIA DCGM se orienta a la gestión de GPUs en centros de datos, clusters y despliegues avanzados. Aquí ya tenemos sensores más amplios para nuestra nave espacial porque es útil cuando hay muchas GPUs o una integración con stacks de observabilidad.
Ambas son buenas herramientas, pero la verdad es que ni nvidia-smi ni DCGM nos van a resolver toda la operación IT.
No centralizan la infraestructura, no sustituyen dashboards corporativos, no aportan reporting histórico orientado a negocio y no correlacionan por su cuenta GPU con CPU, RAM, disco, red, logs, servicios o SLA, por ejemplo.
Por esos motivos, propuestas como la de Datadog insisten en conectar la GPU con el resto del AI workload.
O voy a expresarlo de otro modo para que se entienda. nvidia-smi y DCGM pueden ser excelentes fuentes de datos, pero flotando solos en un vacío.
Es una plataforma, como Pandora FMS, la que los convierte en conocimiento accionable operacional con histórico, alertas, dashboards, informes, correlación y decisiones de capacidad.
El tricorder da una lectura, un puente de mando del Enterprise como Pandora FMS te dice qué significa en el contexto de todo lo demás cuando integra dicha lectura.
Y en una crisis, quieres estar en el puente, no descifrando datos sueltos a oscuras.

Los riesgos de no monitorizar GPUs

Dejar el motor desatendido tiene consecuencias desastrosas como:

• Saturación invisible, de esa que solo se descubre cuando ya escuece.
• Degradación en servicios, de inferencia, entrenamientos más lentos o fallidos.
• Errores CUDA, que pasan inadvertidos.
• Sobrecalentamiento y facturas, de electricidad kilométricas.
• Compra innecesaria, de hardware o ,infrautilización, del ya pagado.
• Dificultades para relacionar incidencias, de aplicación con la presión real de la infraestructura.

Es la trama de tantas películas de catástrofes, las señales estaban ahí, parpadeando en algún panel, pero nadie las miraba.

De las métricas aisladas a la correlación operativa

El GPU monitoring aislado es un termómetro que, con la correlación operativa derivada de integrarlo en la monitorización global, se convierte en diagnóstico y conocimiento operativo.
Saber que una GPU está al 95% no dice gran cosa, como la fiebre por sí sola no revela su porqué. Lo importante es el contexto.
Siguiendo el ejemplo, una GPU al 95% durante diez minutos puede ser normal, pero la misma GPU al 95% durante cuatro horas, con la memoria por encima del 85%, errores pintando los logs y la latencia de un servicio de inferencia subiendo es un incidente operativo.
Otro ejemplo es la temperatura. Una lectura alta junto a un ventilador corriendo a warp 9 y el rendimiento por los suelos puede anticipar un fallo físico, una brecha en la muralla que derrumbará el castillo si se ignora.
Conectar esas señales es lo que distingue una herramienta que mira de una plataforma que entiende.
Esa es la materia del análisis de causa raíz, del trabajo diario de cualquier Network Operations Center o equipo de SRE que se tome en serio la monitorización de sistemas TI.

Cómo ayuda Pandora FMS al GPU monitoring

En tecnología, o estás en la punta de lanza o en realidad no estás.
Esa es la filosofía en Pandora FMS y por eso la aplicación permite integrar las métricas de GPU en la misma consola donde ya se monitorizan servidores, servicios, red, almacenamiento, logs, eventos y disponibilidad.
Eso hace que la vigilancia de GPUs no sea una nota a pie de página, sino pieza fundamental de una maquinaria optimizada para la monitorización y observabilidad que necesita una infraestructura IT profesional.
Para ello, Pandora FMS usa un plugin especialista en GPU monitoring.
Este se apoya en nvidia-smi y funciona como plugin de agente local en el host con GPU NVIDIA, emitiendo módulos que Pandora FMS incorpora al contexto del agente.
Así, esas métricas pueden:

• Visualizarse, obviamente.
• Componer un histórico para tendencias, análisis o lo que sea necesario.
• Alertar de manera inteligente.
• Incluirse en informes como cualquier otra métrica.

Además, esa información que emite es crítica y la necesaria para la gestión óptima de un activo más caro que el adamantium.
Por cada GPU detectada emite, entre otros: GPU_<i>_Status (1 = sano, 0 = degradado), GPU_<i>_Utilization, GPU_<i>_Memory_Used, GPU_<i>_Memory_Free, GPU_<i>_Memory_Total (en MiB, mebibytes, no en bytes), GPU_<i>_Memory_Used_Percent, GPU_<i>_Temperature (°C), GPU_<i>_Power_Draw y GPU_<i>_Power_Limit (W), GPU_<i>_Fan_Speed (omitible), GPU_<i>_Critical_Errors y GPU_<i>_Name.
A escala de host añade tres globales: GPU_Count, GPU_Driver_Version y GPU_CUDA_Version.
La cuenta total sale de una fórmula sencilla: 12N + 3 módulos con fan speed, o 11N + 3 sin él, donde N es el número de GPUs del host.
Y un detalle que revela mucho del diseño. Si nvidia-smi no está disponible, no te preocupes, el plugin no se rompe ni produce un XML inválido, sino que emite GPU_Count = 0 en estado crítico.
El problema queda visible como una alerta limpia, no como ese silencio sospechoso que puede estar gestando la ruina.
Nuestro objetivo (porque hemos vivido en carne propia el caos costoso de la fragmentación), es que Pandora FMS permite analizar todas esas señales en la misma plataforma, con alertas integradas o nuestra metaconsola, por ejemplo, para tener un punto único de visión y control, en lugar de saltar haciendo malabares entre comandos, logs y dashboards dispersos.

Umbrales, alertas y estados críticos

Pandora FMS está para evitar el desastre. Para ello, levanta hasta la última alfombra y une los puntos para que tengas lo más parecido a la presciencia de los Atreides en Dune. De ahí su sistema de umbrales y alertas.
Y para que podamos empezar enseguida y no lo hagamos de cero (una situación que suele hacer que procrastinemos en lo importante), el plugin incluye umbrales predefinidos, disjuntos (que no se solapan) y acotados (con suelo y techo claro), en las métricas más sensibles:

• GPU_<i>_Memory_Used_Percent — Normal: 0-69 %. Warning: 70-84 %. Critical: 85-100 %.
• GPU_<i>_Temperature — Normal: 0-69 °C. Warning: 70-89 °C. Critical: 90-110 °C.
• GPU_<i>_Critical_Errors — Normal: 0. Critical: cualquier valor mayor que 0.

Recordemos lo de que este error crítico tiene sentido en tarjetas de datacenter con ECC, donde cualquier error no corregido debe tratarse como prioritario, sin término medio. En las GPUs para consumidores (y pobres) esto no aplica.
Con estos umbrales detectaremos presión de memoria, riesgo térmico y errores críticos sin caer en el exceso de alertas, ese ruido que acaba haciendo que nadie haga caso a ninguna.
Y si una organización necesita otros valores, genial. Creemos que cada organización es un mundo, así que podemos ajustarlos a nuestra realidad concreta desde la propia consola.

Compatibilidad y requisitos del plugin de Pandora FMS

«Promesas que no valen nada…», ya lo dice la canción. En Pandora FMS no nos gustan nada, así que para evitar las que luego no se sostienen, conviene ser claros con lo que el plugin hace y lo que no:

• Este está orientado a GPUs NVIDIA y usa nvidia-smi como fuente de datos.
• Funciona como plugin de agente local y requiere el driver NVIDIA instalado y nvidia-smi disponible.
• Es compatible con Linux y Windows.
• En la nube funciona con instancias GPU de AWS, Azure o Google Cloud siempre que la GPU NVIDIA esté expuesta al sistema operativo y el driver esté correctamente instalado. Los proveedores documentan ese punto, como en las guías de Google Cloud o AWS.
• Por el momento, no soporta AMD ni Intel.
• Tampoco monitoriza modelos de IA, prompts, drift ni métricas MLOps.
• El intervalo recomendado del agente es de al menos 30 segundos, aunque el valor por defecto de 300 segundos resulta adecuado para la mayoría de entornos.

Y un matiz operativo. El plugin está pensado para hosts individuales o entornos medianos.
Si en tu caso hablamos de clusters con muchas GPUs por nodo o arquitecturas Kubernetes a gran escala, puede ser necesario complementarlo con enfoques como DCGM, Prometheus u otras soluciones de agregación.
Ninguna herramienta lo es todo y reconocerlo nos parece lo honesto.

GPU monitoring y planificación de capacidad (capacity planning)

Teniendo en cuenta la cantidad de primogénitos que debemos sacrificar al Dios Máquina para permitirnos una GPU, todo lo anterior está justificado de sobra. O monitorizamos, o el punto más crítico se convierte en punto ciego.
Pero es en el capacity planning donde la monitorización se traduce en euros contantes y sonantes.
Con el histórico de utilización, memoria, temperatura y consumo se pueden detectar GPUs saturadas de forma recurrente, identificar las infrautilizadas, redistribuir cargas y justificar adquisiciones ante el departamento de compras con datos, en lugar de corazonadas y ruegos, ya que podremos medir el crecimiento real de la demanda.
Al final, es ciencia de datos aplicada a IT y convertir el pasado en decisiones.

La monitorización de GPU como parte de una monitorización de infraestructura IA (AI infrastructure monitoring)

Se suele hablar de GPUs porque en estos tiempos se han aupado a la cima de muchas infraestructuras IT, pero no juegan solas el partido.
Una infraestructura IA depende también de CPU, RAM, disco, almacenamiento, red, APIs, servicios, logs, procesos, contenedores, bases de datos y la disponibilidad del conjunto.
Por eso, el GPU monitoring debe formar parte de una estrategia más amplia de AI infrastructure monitoring.
Vigilar solo la GPU es como tripular el Enterprise atendiendo únicamente a lo que ocurre en el motor de antimateria, mientras se ignoran escudos, soporte vital o hasta el rumbo.
Ahí es donde Pandora FMS se convierte en esa legendaria computadora de la nave que lo sabía todo.
Pandora integra esa visibilidad en una operación IT completa, en la que la IA aplicada a la gestión, la IA generativa y el deep learning aportan el análisis que (reconozcámoslo como especie) ningún humano podría sostener a mano (ni ganas de hacerlo, porque tampoco hay necesidad).
Esto es relevante especialmente en los centros de datos, donde la disponibilidad se da por descontada hasta que deja de estarlo, como bien sabe cualquier buena estrategia de uptime monitoring.

Conclusión

Hemos comentado mucho, pero concentrémonos en tres ideas que llevarnos a casa.

• Que las GPUs son recursos críticos en infraestructuras de IA y HPC, no un detalle técnico.
• Que monitorizarlas de forma aislada no es suficiente, ya que una cifra sin contexto es ruido.
• Que el valor está en integrarlas en la monitorización global de la infraestructura, donde una métrica de GPU dialoga con servidores, servicios, red, logs y alertas.

Las herramientas de NVIDIA cantan la lectura, pero hace falta un puente de mando que la interprete.
Pandora FMS aspira a ser ese puente para llevar el GPU monitoring a entornos on-premise, híbridos y enterprise. Porque entre los resquicios de IT viven los gremlins de la máquina, que te dan el disgusto en lo que no vigilas.

Preguntas frecuentes

Recopilemos las dudas más importantes sobre monitorización de GPU y sus respuestas.

¿Qué es GPU monitoring?

El GPU monitoring es la supervisión continua del estado, utilización, memoria, temperatura, consumo y errores de las Unidades de Procesamiento Gráfico en entornos profesionales.
Se usa para controlar GPUs empleadas en IA, HPC, inferencia, entrenamiento de modelos o procesamiento intensivo.
Como he comentado al principio, no debe confundirse con herramientas de gaming, overclocking o tuning gráfico.

¿Por qué es importante monitorizar GPUs en infraestructuras de IA?

Porque las GPUs son lo que hace latir el corazón y, además, recursos muy caros y críticos para cargas de inferencia, entrenamiento y machine learning.
Sin monitorización, estamos ciegos en nuestro activo más crítico, dejándolo indefenso ante la saturación, el sobrecalentamiento, los errores o la infrautilización, que tienen la manía de atacar escondidos en las sombras y huecos que dejamos sin vigilar.
Esto aumenta el riesgo operativo y dificulta que nos aprueben nuevas inversiones en hardware desde el departamento financiero.

¿Qué métricas deben monitorizarse en una GPU?

Las principales son utilización, memoria usada, libre y total, porcentaje de memoria utilizada, temperatura, consumo instantáneo, límite de consumo, velocidad de ventilador, estado, errores críticos ECC, modelo de GPU, versión de driver y versión CUDA.
Casi nada, pero eso sí, aisladas tendremos un puzzle sin montar, así que en entornos profesionales, estas métricas deben analizarse junto al resto de la infraestructura.

¿Qué diferencia hay entre nvidia-smi, DCGM y una plataforma de monitorización?

nvidia-smi es una utilidad de línea de comandos para consultar métricas puntuales de GPUs NVIDIA.
DCGM se orienta a la gestión y monitorización de GPUs en datacenters y clusters.
Una plataforma como Pandora FMS centraliza esas métricas junto al resto de la infraestructura, con histórico, alertas, dashboards e informes.

¿A qué temperatura se considera crítica una GPU de servidor?

Por nuestra experiencia volcada en el plugin de GPU monitoring de Pandora FMS, una temperatura a partir de 70 °C se considera advertencia y a partir de 90 °C, crítica.
Estos umbrales sirven como referencia operativa, aunque pueden variar según el modelo de GPU, el fabricante y las condiciones térmicas del entorno.

¿Qué son los errores ECC en una GPU y por qué importan?

Los errores ECC (Error-Correcting Code) son errores de memoria detectados en GPUs con soporte ECC.
Los no corregidos pueden indicar fallos de hardware y deben tratarse como incidentes críticos.
Son especialmente relevantes en GPUs de datacenter como A100, H100, Tesla o RTX PRO. En GPUs de nivel consumidor el módulo se emite igual, pero con valor 0 en el plugin de Pandora FMS, porque no hay errores ECC que contar.

¿Se pueden monitorizar GPUs en entornos on-premise con Pandora FMS?

Sí. Pandora FMS dispone de un plugin de agente local basado en nvidia-smi que permite monitorizar GPUs NVIDIA en servidores on-premise.
También puede usarse en entornos híbridos o instancias de nube si la GPU NVIDIA está expuesta al sistema operativo y el driver está correctamente instalado.

¿Cómo ayuda el GPU monitoring al capacity planning?

El histórico de utilización, memoria, temperatura y consumo permite identificar GPUs saturadas de forma recurrente, detectar infrautilización y redistribuir cargas.
También ayuda a justificar compras de hardware o posponer ampliaciones innecesarias con datos objetivos de uso y capacidad en la mano.

¿Qué ocurre si nvidia-smi no está instalado en el servidor?

Si nvidia-smi no está disponible, el plugin de Pandora FMS emite el módulo GPU_Count con valor 0 en estado crítico.
Esto permite generar una alerta sin romper la ejecución del agente ni producir XML inválido.
El problema queda visible como ausencia de GPU o fallo en la disponibilidad de la fuente de datos.

¿El GPU monitoring es suficiente para gestionar una infraestructura de IA?

No. Es una parte de un todo más amplio.
La GPU es componente crítico, pero una infraestructura de IA también depende de CPU, RAM, almacenamiento, red, servicios…
Por eso el GPU monitoring debe integrarse en una estrategia más amplia de AI infrastructure monitoring. Sin eso, será imposible que tengamos una visión operativa completa.