Cómo elegir observabilidad full-stack para fábricas de IA NVIDIA
- Un framework de observabilidad full-stack para la infraestructura de IA de NVIDIA integra telemetría en las capas de cómputo, redes, almacenamiento, orquestación y aplicaciones, permitiendo un análisis preciso de la causa raíz y minimizando fallas en cascada, como las fallas grises en clústeres InfiniBand.
- El framework mapea los componentes de infraestructura de NVIDIA a herramientas de telemetría especializadas —DCGM, NVSM, UFM, NetQ, NMX, BCM, Run:ai y NIM— priorizando una superposición mínima de herramientas y manteniendo conjuntos de alertas concisos y accionables vinculados directamente a métricas SLO/SLI, con tableros de triaje unificados en Prometheus/Grafana.
- Las mejores prácticas operativas requieren que cada dominio monitoreado tenga al menos una herramienta dedicada, que todas las alertas críticas sean accionables y estén vinculadas a responsables, y que la madurez de la observabilidad se mida por la capacidad de identificar componentes fallidos y sus rutas de remediación antes de que se pierdan recursos de cómputo sustanciales.
La infraestructura de IA abarca múltiples capas, desde el cómputo y la red hasta el almacenamiento, la orquestación y las aplicaciones. Cuando el rendimiento disminuye, identificar la fuente puede ser difícil porque un síntoma observado en una capa puede originarse en otra parte del stack.
Una estrategia de observabilidad full-stack conecta la telemetría a través de estas capas, ayudando a los equipos de infraestructura y operaciones a detectar problemas, aislar sus causas y mantener cargas de trabajo de IA confiables. Esta publicación presenta un framework de observabilidad práctico para la infraestructura de IA de NVIDIA y muestra cómo aplicarlo a escenarios comunes de monitoreo y resolución de problemas.
Considere un trabajo de entrenamiento distribuido que lleva tres días en ejecución. La utilización de la GPU y los tiempos de espera en la cola permanecen normales. Después de seis horas de rendimiento reducido, el equipo rastrea la causa hasta un enlace InfiniBand que presenta una tasa de error de bits elevada.
Esta es una clásica falla gris. El hardware está degradado, pero el sistema no lo reporta como "caído". El entrenamiento de IA sigue el modelo de sincronización masiva paralela (BSP). Estos sistemas estrechamente acoplados son sensibles a los rezagados: un rango lento detiene todo el trabajo. Las retransmisiones a nivel de enlace bloquean un solo rango durante operaciones colectivas síncronas como NVIDIA Collective Communications Library (NCCL) all-reduce. El rendimiento cae entonces al nivel del rango más lento y los demás rangos se bloquean. Eso es una falla en cascada.
Este modo de falla se observa a menudo en las fábricas de IA. La telemetría requerida generalmente ya existe; el desafío es seleccionar las señales correctas de las herramientas adecuadas lo suficientemente temprano como para actuar. Los operadores no necesitan cada métrica de cada producto. Necesitan una ruta de decisión que mapee componentes a herramientas, herramientas a un conjunto de alertas conciso, y ese conjunto de alertas en un tablero de triaje único.
Esta publicación muestra ese camino. Usted aprenderá a:
- Enumerar los dominios de falla que deben ser observables antes de seleccionar software.
- Mapear componentes de infraestructura de IA a fuentes de herramientas de telemetría utilizando un framework de decisión derivado de despliegues NVIDIA DGX.
- Aplicar el framework de observabilidad a un clúster InfiniBand.
- Reducir la telemetría a un conjunto de alertas top-k y correlacionar señales en un tablero de triaje único.
Mantenga catálogos detallados, matrices de protocolos y guías de habilitación por herramienta en la documentación del producto. Aquí, nos enfocaremos en cómo elegir un stack de observabilidad. Los despliegues NVIDIA DGX y NVIDIA HGX comparten la misma superficie de observabilidad, incluso cuando las configuraciones de hardware difieren (Figura 1):
Identifique los dominios de falla de la fábrica de IA
Antes de seleccionar software de monitoreo, enumere los dominios en los cuales la falla silenciosa consume horas de GPU:
- Salud de la plataforma: Ventiladores, fuentes de poder (PSU), BMC, chasis, CPU, memoria, almacenamiento local.
- Salud y rendimiento de la GPU: Utilización, temperatura, energía, XID/ECC y rendimiento de NVIDIA NVLink.
- Fabric: Integridad de enlace InfiniBand o Ethernet, congestión y salud de switches/cables; NVLink a nivel de rack cuando esté presente.
- Clúster y trabajos: Programación, reservas, GPUs asignadas inactivas, espera en cola.
- Servicios de inferencia: Latencia, tasa de éxito y comportamiento de caché cuando los microservicios NVIDIA NIM o similares están en producción.
En sistemas complejos, las brechas de cobertura rara vez se cierran en una sola pasada. Aparecen más tarde, cuando los modos de falla latentes se manifiestan bajo carga. Analizar esos modos temprano acorta el descubrimiento. Este análisis puede ayudar a evitar que las fallas recurran bajo carga.
Mapee los componentes de infraestructura de IA a herramientas de telemetría
Los equipos de operaciones necesitan un mapeo claro del componente a la fuente de telemetría. La Tabla 1 mapea NVIDIA Data Center GPU Manager (DCGM), NVIDIA System Management (NVSM), NVIDIA Unified Fabric Manager (UFM), NVIDIA NetQ, NVIDIA NMX, NVIDIA Base Command Manager (BCM) y NVIDIA Run:ai a esos componentes. El color verde indica soporte completo para el dominio; el amarillo indica cobertura parcial o indirecta. Utilice el framework para seleccionar el conjunto mínimo de herramientas que elimine las brechas de cobertura.
Las compensaciones clave incluyen:
- DCGM comparado con NVSM para GPUs: Prefiera DCGM para utilización, energía, temperatura, NVLink y exportación de XID/ECC a Prometheus. Mantenga NVSM para la salud del sistema en nodos de clase DGX (unidades, energía, salud general). Las herramientas se superponen en métricas de GPU; ninguna sustituye los datos de BMC de la plataforma.
- UFM comparado con NetQ: Seleccione según el tipo de fabric. InfiniBand utiliza UFM. Spectrum Ethernet/RoCE utiliza NetQ. Despliegue ambos solo cuando ambos fabrics estén presentes.
- NMX: Requerido para NVLink a nivel de rack. Omita en topologías NVLink multi-nodo clásicas donde DCGM ya cubre las interconexiones de nodo.
- BCM: Trate a BCM como el agregador y plano de clúster/trabajo, no como la fuente de contadores de bajo nivel. Las herramientas especializadas siguen siendo responsables de la telemetría profunda.
- Run:ai y NIM: Introduzca cuando la equidad en la programación de cargas de trabajo o los SLOs de inferencia sean requisitos operativos de primer nivel. Ninguno reemplaza a DCGM o al monitoreo de fabric.
Una regla útil: cubra cada celda verde requerida con la menor cantidad de herramientas. Los exportadores adicionales sin una ruta de triaje clara añaden ruido, no observabilidad. Ese ruido conduce a la fatiga por alertas.
Los equipos siguen añadiendo métricas y tableros, pero aún no pueden responder qué está roto y por qué. El resultado son "métricas de sandía": tableros que parecen verdes por fuera mientras los servicios fallan por dentro. El principio correctivo es el establecido en "As Simple as Possible, No Simpler": mantenga el monitoreo simple y elimine las señales no utilizadas en lugar de acumularlas.
Aplique el framework de observabilidad a un clúster InfiniBand
Considere un clúster DGX con InfiniBand, BCM y Slurm. La mayoría de los trabajos son de entrenamiento; la inferencia aún no está en producción. El requisito operativo es un único tablero de triaje y alertas que detecten regresiones en la salud de la fabric y la GPU antes de que se acumule el desperdicio de trabajos de varias horas.
Aquí está el proceso de decisión:
- Dominios en alcance: plataforma, GPU, fabric InfiniBand, clúster/trabajos. Fuera de alcance para el despliegue inicial: NetQ, NMX, Run:ai, NIM.
- Selección de herramientas desde el framework
- Redfish/IPMI en cada nodo para ventiladores, PSU, chasis y estado de BMC.
- DCGM en cada nodo GPU para utilización, energía, temperatura, XID/ECC y NVLink.
- NVSM en nodos DGX para agregación de salud del sistema.
- UFM para salud de puerto InfiniBand, BER, congestión y enrutamiento.
- BCM como el agregador de clúster para trabajos, reservas y estados de nodos.
Vía NVIDIA Developer.
