NVIDIA Attribution: Herramienta de código abierto para diagnosticar fallos en IA distribuida

NVIDIA ha lanzado NVIDIA Attribution como proyecto de código abierto para ayudar a los ingenieros a diagnosticar fallos en cargas de trabajo de IA distribuidas. Publicado el 2 de noviembre de 2026, esta herramienta aborda la complejidad de depurar clústeres GPU a gran escala mediante la correlación de fuentes de datos dispares en un diagnóstico único y estructurado. Va más allá del simple reporte de errores para explicar por qué falló una carga de trabajo.

Qué ocurrió

Los trabajos de entrenamiento distribuido suelen fallar debido a errores en cascada donde un único problema de hardware o red desencadena miles de síntomas posteriores. Un fallo en una GPU puede manifestarse como tiempos de espera de comunicación en muchos otros ranks, lo que dificulta distinguir la causa raíz del ruido resultante. Las herramientas de monitoreo tradicionales suelen reportar dónde se detuvo la carga de trabajo, no dónde se originó el fallo, lo que lleva a tiempos de investigación prolongados.

Para resolver esto, NVIDIA publicó bajo licencia open-source su sistema interno de atribución de fallos centrado en la carga de trabajo. La herramienta, que ha sido utilizada en producción durante años en la infraestructura de IA de NVIDIA, analiza millones de cargas de trabajo semanalmente en cientos de miles de GPUs. Al correlacionar registros, métricas, telemetría y estado del planificador específicos de la carga de trabajo, produce un diagnóstico reproducible que incluye el resultado, la causa raíz, los nodos afectados y un rastro de evidencia.

El lanzamiento incluye dos componentes desplegables principales: el Attribution Service y el Attribution Blueprint. El Service expone el motor central de atribución a través de una API REST, mientras que el Blueprint actúa como un orquestador de referencia en Python. El Blueprint conecta los planificadores de clúster y las fuentes de telemetría con el Service, permitiendo a los equipos integrar la herramienta en su infraestructura existente sin reconstruir la lógica central.

Cómo funciona

El proceso de atribución sigue cuatro etapas deterministas para garantizar la reproducibilidad. Primero, el Blueprint define el alcance de la carga de trabajo identificando el intento específico mediante identificadores del planificador o ventanas de ejecución. Segundo, recopila observaciones de varios conectores, incluyendo registros de aplicación, syslogs, mensajes del driver de GPU y métricas de red. Estas entradas se normalizan en registros de observación estructurados.

A continuación, el Service extrae y correlaciona eventos utilizando un motor de reglas. Identifica eventos significativos como XIDs de GPU, fallos de NCCL y transiciones del planificador. Reglas deterministas evalúan el tiempo y la interacción de estos eventos para separar los síntomas posteriores de la causa principal. Por ejemplo, si una GPU reporta un problema de integridad de señal y otros ranks reportan errores de comunicación, el sistema identifica el fallo de hardware como la causa raíz y los errores de comunicación como síntomas de apoyo.

Finalmente, el sistema devuelve un resultado estructurado que contiene el estado terminal, el dominio atribuido y los nodos afectados. La salida distingue entre causas raíz definitivas y situaciones ambiguas donde la evidencia es incompleta. Este formato estructurado permite que sistemas posteriores, como la gestión de incidentes o herramientas de recuperación automatizada, consuman el diagnóstico sin analizar registros brutos específicos del producto.

Detalles clave

• El sistema opera a través de dos componentes: el Attribution Service para el análisis y el Attribution Blueprint para la orquestación y recopilación de datos.
• Admite conectores de contexto de ejecución para Slurm, Kueue y entradas estáticas, junto con conectores de registro y métricas para Loki, archivos locales, registros de pods de Kubernetes y PromQL.
• En producción, el sistema ha identificado patrones de fallo de fabric alrededor de puertos específicos de host y switch al correlacionar errores de puerto y reinicios de conexión.
• El motor de atribución utiliza reglas deterministas para evaluar el tiempo de los eventos, asegurando que los resultados sean reproducibles y personalizables para diferentes entornos.
• La salida incluye un indicador de calidad que refleja la incertidumbre cuando múltiples causas coinciden con la evidencia, evitando una falsa confianza en diagnósticos incompletos.
• Los desarrolladores pueden extender el sistema añadiendo nuevas reglas para modos de fallo o implementando conectores para planificadores personalizados y backends de telemetría.

Por qué importa

Para los ingenieros de software y líderes de infraestructura de ML, reducir el tiempo medio hasta la resolución (MTTR) es crítico para mantener una alta utilización de recursos GPU costosos. La depuración manual de fallos distribuidos consume mucho tiempo y es propensa a errores, requiriendo a menudo que expertos examinen gigabytes de registros. NVIDIA Attribution automatiza esta correlación, permitiendo a los equipos centrarse en arreglar problemas de infraestructura en lugar de buscarlos. Al proporcionar un rastro de evidencia claro, también facilita una mejor comunicación entre los equipos de software y las operaciones de hardware.

La naturaleza de código abierto del proyecto permite a las organizaciones adaptar la herramienta a su stack específico. Dado que la lógica central está separada de la capa de integración, los equipos pueden aplicar las mismas reglas de atribución en diferentes clústeres mientras personalizan cómo se recopilan y almacenan los datos. Esta flexibilidad admite entornos diversos, desde pequeños clústeres de investigación hasta flotas masivas de producción, habilitando prácticas consistentes de análisis de fallos en toda la organización.

Qué puedes hacer

• Clona el repositorio de NVIDIA Attribution desde GitHub para acceder al código fuente y cargas de trabajo de muestra.
• Sigue la guía de inicio rápido para ejecutar el flujo de trabajo de muestra usando Docker y el gestor de paquetes uv.
• Inspecciona los diagnósticos generados en el dashboard local para entender cómo el sistema correlaciona eventos e identifica causas raíz.
• Revisa la referencia de configuración del Blueprint para conectar tus propios backends de planificador y telemetría, como Slurm o Kubernetes.
• Examina las reglas declarativas y en Python incluidas para aprender a codificar nuevos patrones de fallo para tu stack específico de hardware o software.
• Integra el Resultado del Attribution Blueprint en tus sistemas existentes de gestión de incidentes o recuperación de flotas para automatizar respuestas a fallos comunes.