Cómo monitorear la salud de GPUs: ECC, temperatura, potencia y tarjetas degradadas

Las empresas deben monitorear la salud de las GPUs a nivel de tarjeta individual y luego combinar los errores de hardware, temperatura, potencia, frecuencias de reloj, uso, historial de reinicios y comportamiento de las cargas de trabajo en un estado de salud comprensible. El objetivo consiste en detectar un acelerador degradado antes de que ralentice un trabajo de entrenamiento distribuido, genere caídas repetidas o se asigne a otra carga de trabajo.

Que un servidor se muestre en verde no demuestra que cada acelerador en su interior esté en perfecto estado. Un nodo con ocho GPUs puede seguir encendido mientras una de las tarjetas sufre errores ECC recurrentes o problemas térmicos. Para la infraestructura de IA, la unidad operativa debe descender, por tanto, por debajo del servidor hasta el propio acelerador.

¿Qué métricas de salud de GPU deben monitorear las empresas?

Las empresas deben vigilar las señales que responden a tres cuestiones fundamentales: ¿está la tarjeta físicamente sana?, ¿opera dentro de los límites esperados? y ¿entrega un rendimiento estable?

Para la salud física, comienza con los eventos ECC, los fallos de enlace o PCIe cuando estén disponibles, los eventos de reinicio, los códigos de fallo de hardware y el estado del controlador o firmware. Para las condiciones de funcionamiento, recopila la temperatura, el consumo de energía, las frecuencias de reloj, el uso de memoria y los indicadores de throttling. Para el rendimiento, haz seguimiento de la utilización de GPU, el uso de memoria, la tasa de transferencia de la carga de trabajo y las variaciones anómalas de rendimiento a lo largo del tiempo.

NVIDIA Data Center GPU Manager aporta monitoreo de salud, diagnósticos, grupos de campos y telemetría para GPUs corporativas de NVIDIA. Sus campos documentados incluyen potencia del dispositivo, valores de temperatura, frecuencias de reloj, utilización, contadores de ECC y datos adicionales del equipo según la generación de la GPU y el soporte de software.

Las métricas exactas varían según el fabricante del acelerador, de modo que una flota de múltiples proveedores necesita un modelo de salud normalizado que conserve por debajo los campos nativos de cada fabricante. Para explorar el modelo de recursos general, cómo gestionar GPUs y NPUs de múltiples fabricantes detalla cómo estandarizar la salud sin asumir que todos los aceleradores proporcionan una telemetría idéntica.

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

Los errores ECC son eventos de error en la memoria detectados por los mecanismos de código de corrección de errores en el hardware compatible. En el plano operativo, la diferencia crítica se sitúa entre los fallos que el hardware puede corregir por sí mismo y aquellos en los que los datos no pudieron restaurarse de forma fiable.

Un evento corregido no implica necesariamente retirar la tarjeta. Un evento aislado y corregido puede significar algo muy diferente a un incremento acelerado de errores en el mismo componente, por lo que conviene analizar el patrón temporal. Rastrea el tipo de error, el recuento, la tasa de cambio, la tarjeta afectada, la carga de trabajo en ejecución en ese instante y si el evento se reproduce tras un reinicio o una prueba de validación.

Los errores no corregibles exigen una intervención mucho más estricta porque, según el comportamiento del hardware y del software, pueden traducirse en la caída de la carga de trabajo, cálculos corrompidos o el reinicio inesperado del dispositivo.

El sistema de monitoreo nunca debería reducir la salud ECC a un simple indicador rojo o verde sin conservar los contadores subyacentes y el historial de eventos. Un operador que investiga el fallo de un entrenamiento necesita saber si la tarjeta registró un evento aislado hace varios meses o una oleada de incidencias frescas durante el trabajo afectado.

¿Cómo se debe monitorear la temperatura de la GPU?

Monitorea la temperatura de la GPU como una serie temporal y evalúala frente a los límites de operación específicos de cada dispositivo, en lugar de utilizar un único umbral genérico. Cada modelo de acelerador presenta características térmicas particulares, por lo que la plataforma debe almacenar el contexto del modelo y del fabricante junto con la métrica.

Supervisa tanto la temperatura absoluta como la evolución de la curva en torno a los cambios de carga. Si la temperatura aumenta al subir la carga y regresa a valores normales después, ese comportamiento entra dentro de lo esperado. Si permanece alta tras finalizar la tarea, escala más rápido que en tarjetas vecinas o alcanza de forma reiterada el umbral de limitación térmica, investiga la refrigeración, el flujo de aire, el circuito de refrigeración líquida, el contacto del disipador, los ventiladores o el estado físico de la tarjeta.

La comparación entre componentes equivalentes suele ser la herramienta más eficaz. Compara tarjetas del mismo modelo en el mismo chasis bajo cargas idénticas: que una tarjeta opere de forma constante más caliente que las otras siete aporta mucha más información que un promedio abstracto de toda la flota.

La temperatura también debe correlacionarse con las frecuencias de reloj y el rendimiento. Una tarjeta puede permanecer conectada mientras el control térmico reduce drásticamente sus frecuencias. El usuario percibe una tarea lenta y el monitor de hardware detecta un estrangulamiento térmico; conectar ambas observaciones es precisamente lo que hace que el monitoreo sea útil en el día a día.

¿Cómo se debe monitorear el consumo de potencia de la GPU?

Supervisa la potencia de la GPU a nivel de tarjeta individual y compárala con la asignación de recursos, el nivel de utilización, la frecuencia de reloj y el estado de la carga de trabajo.

La potencia instantánea te indica lo que la tarjeta consume en este momento. La energía es la potencia acumulada en el tiempo, de modo que si necesitas calcular el coste por proyecto o el consumo por hora de tarjeta, debes integrar las lecturas de potencia a lo largo del intervalo de ejecución de la tarea.

Una tarjeta que demanda una potencia notable sin realizar trabajo útil representa un problema de eficiencia energética. Una tarjeta que consume una potencia anormalmente baja durante una tarea pesada puede estar bloqueada a la espera de almacenamiento, transferencias de red, carga de datos desde la CPU o un fallo del programador de tareas. Una tarjeta que roza continuamente su límite de potencia puede comportarse de forma muy dispar a otra que ejecuta la misma tarea.

Por tanto, la potencia ayuda tanto a evaluar la salud como la economía del clúster. La perspectiva de salud determina si el consumo es anómalo, mientras que la perspectiva operativa evalúa cuánta energía gastó la carga y si hubo hardware costoso desaprovechado en reposo.

Para el diagnóstico de cuellos de botella, por qué el uso de la GPU puede ser bajo explica cómo relacionar la potencia y el uso del acelerador con el almacenamiento, la red y la carga de datos.

¿Qué es una tarjeta aceleradora degradada?

Una tarjeta aceleradora degradada es un dispositivo que sigue respondiendo pero muestra suficientes indicios anómalos como para que asignarle nuevas cargas de trabajo en producción represente un riesgo inasumible. Constituye una categoría operativa, más que un estándar estricto de los fabricantes de hardware.

Un único incidente grave o una concatenación de señales menores pueden justificar el paso a estado degradado. Entre los ejemplos comunes figuran errores ECC repetidos, reinicios continuos, limitación térmica recurrente, oscilaciones erráticas de frecuencias de reloj, inestabilidad en los enlaces PCIe, recuperaciones sucesivas del controlador o caídas medibles de rendimiento frente a tarjetas idénticas.

Establece los umbrales según el modelo de hardware, la criticidad de la tarea y la experiencia previa del equipo. No catalogues una tarjeta como degradada solo porque una métrica aislada rebasó un umbral puntual una vez, pero tampoco esperes al fallo irreversible cuando los indicios no dejan de acumularse.

El estado degradado existe para definir un término medio controlado entre lo saludable y lo averiado. Permite al programador detener la asignación de nuevas tareas mientras el equipo de operaciones revisa el componente.

¿Cómo deben construir las empresas una puntuación de salud de GPU?

Una puntuación de salud de GPU debe integrar múltiples señales manteniendo a la vista los datos en bruto. Un esquema funcional muy extendido emplea tres niveles. Saludable indica la ausencia de advertencias significativas de hardware, condiciones ambientales dentro de los márgenes previstos y un rendimiento parejo al de sus pares. Degradado significa que el componente está en línea pero arrastra advertencias reiteradas o de calado que justifican no asignarle nuevas cargas. Fallido implica que el dispositivo no ofrece garantías para producción y debe aislarse hasta su reparación o reemplazo.

Puedes calcular internamente un índice numérico detrás de estas categorías, pero evita presentar a los usuarios una cifra sin contexto como «72 sobre 100» sin desglosar su motivo. Cada estado degradado debe justificar su causa: los errores ECC corregidos crecieron rápidamente en los últimos 30 minutos, la tarjeta se reinició tres veces durante dos entrenamientos o la temperatura alcanzó reiteradamente el límite de limitación térmica mientras las demás tarjetas funcionaban con normalidad. La explicación operativa importa mucho más que la nota numérica.

¿Cómo deben colaborar el monitoreo in-band y out-of-band?

Combina el monitoreo in-band para el comportamiento en tiempo de ejecución del acelerador con el monitoreo out-of-band para el servidor físico y la vía de recuperación. Las bibliotecas de ejecución de GPU y las utilidades del fabricante suelen ofrecer la telemetría más rica a nivel de tarjeta. La controladora BMC proporciona la salud del chasis, el estado eléctrico, ventiladores, fuentes de alimentación, versiones de firmware y otras señales físicas de forma independiente al sistema operativo del host.

Juntas ofrecen un diagnóstico mucho más certero. Supongamos que una GPU experimenta altas temperaturas. La telemetría in-band confirma la subida térmica y la caída de frecuencia del acelerador, mientras que la telemetría out-of-band registra una alarma en un ventilador del chasis. Evaluadas en conjunto, las dos lecturas señalan un fallo de refrigeración del servidor físico y descartan un problema de configuración del entrenamiento.

El mismo principio resulta vital si el sistema operativo colapsa: el flujo de telemetría de la GPU se interrumpirá, pero el canal de la BMC seguirá respondiendo. Una arquitectura eficaz asocia ambas fuentes de datos a la misma identidad de servidor y tarjeta.

¿Cómo deben influir los datos de salud en la asignación de GPUs?

La salud de cada tarjeta debe intervenir de forma directa en las decisiones de programación y asignación. En cuanto una tarjeta entra en estado degradado y se activa la política aprobada, el programador debe dejar de asignarle trabajo nuevo. Ante una anomalía leve, la plataforma puede optar por rebajar su prioridad de asignación. Ante incidencias más severas, puede marcar el dispositivo o el nodo completo como no asignable. Ante un fallo definitivo, el mecanismo de recuperación de cargas puede tomar el último checkpoint, reubicar la tarea en hardware sano y generar una incidencia de soporte técnico.

Esto cierra el ciclo entre el monitoreo y las operaciones de infraestructura. Sin ese vínculo, el equipo de soporte puede saber que una tarjeta falla mientras el orquestador sigue enviándole tareas críticas, lo que conforma una de las desconexiones operativas más caras en un clúster de IA.

¿Cómo evitar los falsos positivos?

Evita los falsos positivos conjugando umbrales, persistencia en el tiempo, contraste entre pares y contexto de la carga. Un pico térmico de dos segundos rara vez amerita aislar una máquina, pero picos continuos en cada tarea pesada sí justifican la alerta. Un error ECC corregido y puntual no exige retirar la tarjeta, pero un contador que escala sin freno sí. Una caída brusca de uso de GPU puede originarse en el almacenamiento y no en un defecto del silicio.

Por esta razón, las reglas de evaluación de salud no deben depender de una única métrica en solitario. Define ventanas de observación y tasas de variación temporal, compara con tarjetas hermanas bajo el mismo esfuerzo, comprueba si el acelerador estaba trabajando al máximo y revisa si coincidió con algún otro evento de la infraestructura. Ajusta después estas políticas a partir de incidentes reales. El modelo operativo de referencia trata explícitamente los umbrales de degradación como parámetros sujetos a calibración continua según la casuística de los entrenamientos.

¿Qué debe ocurrir después de marcar una tarjeta como degradada?

Una tarjeta degradada debe entrar en un protocolo controlado: proteger las cargas de trabajo, detener nuevas asignaciones, recopilar evidencias, validar el dispositivo y determinar si puede volver a la producción activa.

Primero, identifica la tarea que se encuentra en ejecución y, si admite guardar un checkpoint de forma segura, protege el progreso del entrenamiento antes de reubicarla. Segundo, bloquea cualquier nueva asignación de cómputo. Tercero, reúne el paquete de diagnóstico, que comprende el historial de anomalías, temperaturas, potencias, frecuencias, versiones de firmware y controlador, además de las alertas del servidor. Cuarto, ejecuta las pruebas de diagnóstico del fabricante o un test de esfuerzo validado. Quinto, contrasta el resultado con los requisitos de la política de reincorporación al servicio.

No levantes el estado degradado simplemente porque la tarjeta parezca operar con normalidad cinco minutos más tarde, ya que un fallo intermitente de silicio puede enmascararse de forma temporal tras un reinicio. La tarjeta solo debe reintegrarse al grupo de trabajo cuando las pruebas aporten la certeza necesaria.

Una plataforma que integra la salud de las tarjetas, la programación de tareas y los flujos operativos en una misma solución es Sensaka.

La regla práctica es muy clara: cada acelerador debe contar con una identidad unívoca, un estado de salud en tiempo real, un historial de eventos anómalos y una directiva de asignación supeditada a esa salud. Si no puedes apartar una tarjeta sospechosa antes de que falle del todo, estás monitoreando GPUs pero todavía no las estás gestionando como un recurso operativo real.