Detección de Anomalías en Infraestructura de Aprendizaje Automático mediante Telemetría de Hardware

Información Básica

• ID del Artículo: 2510.26008
• Título: Detecting Anomalies in Systems for AI Using Hardware Telemetry
• Autores: Ziji Chen, Steven W. D. Chien, Peng Qian, Noa Zilberman (Universidad de Oxford)
• Clasificación: cs.PF (Rendimiento), cs.AR (Arquitectura de Computadoras), cs.DC (Computación Distribuida), cs.LG (Aprendizaje Automático)
• Fecha de Publicación: 31 de octubre de 2025 (arXiv v2)
• Enlace del Artículo: https://arxiv.org/abs/2510.26008v2

Resumen

El aprendizaje automático moderno se ha desarrollado como un ecosistema de pila completa fuertemente acoplado, que combina hardware, software, redes y aplicaciones. Muchos usuarios dependen de proveedores de nube para obtener recursos elásticos, aislados y rentables. Sin embargo, estas plataformas como servicio utilizan virtualización, lo que resulta en una falta de visibilidad de los operadores sobre las cargas de trabajo de los usuarios. Esto obstaculiza la optimización de recursos por parte de los operadores, lo cual es crítico para garantizar la eficiencia de costos y minimizar el tiempo de ejecución. Este artículo propone que la optimización a nivel de sistema es posible sin conocimiento de la carga de trabajo. Presentamos Reveal, que adopta un enfoque centrado en hardware, dependiendo únicamente de señales de hardware completamente accesibles para los operadores. Mediante el análisis del rendimiento de más de 30 modelos de ML populares en diversas plataformas de hardware, desarrollamos un pipeline de aprendizaje no supervisado para detectar anomalías. Utilizando Reveal, identificamos exitosamente problemas de configuración de red y sistema, acelerando el modelo DeepSeek en un 5.97%.

Contexto de Investigación y Motivación

Problemas Fundamentales

1. Falta de Observabilidad: La virtualización de plataformas en nube oculta el hardware subyacente, impidiendo que los operadores obtengan información de cargas de trabajo de alto nivel, lo que dificulta la optimización a nivel de sistema
2. Dificultad en la Detección de Cuellos de Botella de Rendimiento: Las cargas de trabajo de ML presentan un acoplamiento estrecho entre hardware y software, donde pequeñas ineficiencias pueden causar degradación en cascada del rendimiento del sistema
3. Limitaciones de Herramientas Existentes: Requieren integración a nivel de aplicación, alto costo de tiempo de ejecución (hasta 90.2%), cobertura limitada

Importancia del Problema

• Los aceleradores especializados como GPU tienen costos elevados (decenas de miles de dólares por GPU)
• Se espera que la demanda de recursos de IA en la nube crezca un 30% anual hasta 2030
• Incluso errores de configuración menores pueden resultar en degradación de rendimiento de 1.5 veces
• El entrenamiento distribuido depende altamente de comunicación colectiva, siendo vulnerable a problemas de red

Limitaciones de Métodos Existentes

1. Dependencia de Observabilidad de Alto Nivel: La mayoría de herramientas requieren información a nivel de aplicación, no disponible en entornos virtualizados
2. Alto Costo: Plumber añade 21% de sobrecarga, RL-Scope añade 90.2% de tiempo de lanzamiento de kernels GPU
3. Detección Basada en Reglas: Requiere ajuste de umbrales específicos de carga de trabajo, portabilidad deficiente
4. Cobertura Limitada: Los analizadores de framework típicamente solo cubren la aplicación y el tiempo de ejecución del framework

Contribuciones Principales

1. Propuesta del Framework Reveal: Marco de análisis centrado en hardware y detección de anomalías con alta portabilidad, capacidad de despliegue y precisión analítica
2. Identificación de Indicadores Clave de Rendimiento: Determinación de un conjunto de indicadores de rendimiento de bajo nivel que representan el comportamiento de cargas de trabajo de ML en hardware, con liberación de código abierto de todos los conjuntos de datos recopilados
3. Desarrollo de Pipeline de Detección No Supervisada: Detección exitosa de problemas de rendimiento en cargas de trabajo de ML en contenedores, identificación de cuellos de botella del sistema y aceleración de DeepSeek en 5.97%

Explicación Detallada del Método

Definición de Tareas

Entrada: Datos de telemetría de hardware a nivel de host (métricas de CPU, GPU, memoria, red, almacenamiento) Salida: Detección de ventanas anómalas, atribución de subsistemas, informe de análisis de causa raíz Restricciones: Uso exclusivo de señales de hardware accesibles para operadores, sin necesidad de conocimiento de carga de trabajo de alto nivel

Arquitectura del Modelo

1. Recopilador de Telemetría (Telemetry Collector)

• Utiliza perf, procfs, nvidia-smi, herramientas estándar de Linux para recopilar aproximadamente 150 tipos de métricas únicas
• Se expande a más de 700 canales de series temporales cuando se replica entre núcleos de CPU y GPU
• La sobrecarga de CPU se mantiene por debajo del 1.5%

2. Reanálisis de Métricas y Extracción de Características (Metric Reanalysis and Feature Extraction)

• Filtrado de Métricas: Poda impulsada por correlación, retención de aproximadamente 60% de métricas en umbral |r|=0.5
• Métricas Derivadas: Cálculo de IPC (rendimiento de ejecución), tasa de predicción incorrecta de rama, tasa de fallos de caché, etc.
• Ventana Deslizante: Ventana de 3 segundos, paso de 1 segundo, extracción de características estadísticas y temporales

3. Motor de Detección de Anomalías (Anomaly Detection Engine)

Adopta tres métodos no supervisados complementarios:

• Puntuación Z: Detección de desviación normalizada, marcado de ventanas que exceden el percentil 99%
• Distancia de Mahalanobis en Subespacio PCA: Considera correlación entre métricas y diferencias de escala
• Bosque de Aislamiento (Isolation Forest): Método de conjunto basado en árboles, tasa de contaminación 1%

Puntos de Innovación Técnica

1. Enfoque Centrado en Hardware: Completamente basado en señales de hardware, evitando dependencia de observabilidad de alto nivel
2. Fusión de Múltiples Detectores: Reducción de falsos positivos mediante consistencia entre detectores, mejora de precisión de detección
3. Atribución de Subsistemas: Mapeo de anomalías a subsistemas de hardware específicos (CPU, GPU, memoria, red, almacenamiento)
4. Análisis Multicapa: Una única ventana anómala puede involucrar múltiples señales relacionadas, proporcionando evidencia más fuerte de anomalía

Configuración Experimental

Conjunto de Datos

• Aplicaciones de ML: Más de 30 modelos populares, incluyendo BERT, BART, ResNet, ViT, VGG, DeepSeek, LLaMA, Mistral
• Tipos de Tareas: Clasificación de texto, preguntas sobre tablas, clasificación de imágenes, segmentación semántica
• Conjuntos de Datos: GLUE/SST2, WikiSQL, PASCAL VOC, CIFAR, MNIST
• Ejecuciones: 10 ejecuciones por tipo de carga de trabajo para garantizar confiabilidad estadística

Entorno Experimental

1. Clúster HPC:
   • Nodo dual, GPU NVIDIA Tesla V100 (32GB), CPU Intel Xeon Platinum 8628
   • Nodo único, cuatro GPU NVIDIA H100 (96GB HBM3), CPU Intel Sapphire Rapids
2. Clúster Local:
   • 9 servidores, CPU AMD EPYC 7443P (24 núcleos), 256GB de memoria
   • Configuración de entrenamiento distribuido con 99 contenedores

Métricas de Evaluación

• Precisión de Detección: Tasa de precisión en identificación de ventanas anómalas
• Atribución de Subsistemas: Capacidad de mapeo correcto a subsistemas de hardware
• Mejora de Rendimiento: Mejora del tiempo de ejecución de extremo a extremo
• Evaluación de Sobrecarga: Utilización de CPU, requisitos de almacenamiento, tiempo de ejecución del detector

Resultados Experimentales

Resultados Principales

Sobrecarga de Rendimiento

• Sobrecarga de CPU: 1.2-1.4% con intervalo de muestreo de 100ms, disminuye a menos de 0.6% con 600ms
• Requisitos de Almacenamiento: 42-43 KB/s/host antes del filtrado, 14-22 KB/s después del filtrado
• Latencia de Detección: Extracción de características 1.46±0.02s, extremo a extremo 2.26±0.17s

Efectividad de Detección de Anomalías

• Estabilidad de Métricas: 99.75% de pares carga de trabajo-métrica muestran similitud estadística significativa (p<0.05)
• Consistencia Multiconfiguraciones: Mediana IoU de 0.50 entre configuración predeterminada y configuración de grano fino, tasa de aciertos 0.92

Análisis de Casos

Caso 1: Anomalía NUMA (Subsistema de Memoria)

• Detección: Ventanas 118-123 muestran disminución de IPC e incremento de ciclos de fallo L3
• Análisis: Memoria entre sockets y tráfico PCIe causan aumento de latencia
• Corrección: Vinculación consciente de NUMA, vinculación de procesos a nodo NUMA único
• Efecto: Ajuste fino de DeepSeek-7B mejorado de 1823.4±46.1s a 1714.6±70.0s (mejora de 5.97%)

Caso 2: Error de Configuración NCCL-QP (Subsistema de Red)

• Detección: Aumento de CPU Busy%, ráfagas de tráfico TX/RX de ib0, disminución de potencia de GPU
• Análisis: Configuración de QP único causa cuello de botella en procesamiento de finalización
• Corrección: Aumento de configuración de 1QP a 2QP
• Efecto: Tiempo de ejecución mejorado de 1825.4±46.1s a 1769.3±16.7s (mejora de 3.1%)

Caso 3: Desbalance de IRQ (Subsistema de CPU)

• Detección: Varianza de CPU Busy% y anomalía en contadores de IRQ
• Corrección: Habilitación del servicio irqbalance para distribución automática de carga de interrupciones
• Efecto: Anomalía de retransmisión TCP disminuida de 6.07% a 3.51%

Caso 4: Error de Configuración de HugePages (Subsistema de Memoria)

• Detección: Anomalía en uso de memoria entre nodos
• Análisis: HugePages de 1GiB preasignadas reportadas como memoria "utilizada"
• Corrección: Configuración de asignación predeterminada de HugePages de 2MiB

Caso 5: Prueba de Inyección de Pérdida de Paquetes (Subsistema de Red)

• Capacidad de Detección: Diferenciación entre retransmisiones intrínsecas de carga de trabajo y retransmisiones causadas por fallos
• Profundidad de Análisis: Proporciona contexto multicapa, desde contadores de capa de transporte hasta picos de IRQ de CPU y pausas de GPU

Análisis de Patrones Anómalos

• Clúster HPC: Señales del lado de CPU (Bzy_MHz, IRQ) dominan, contribuyendo más del 50% de características anómalas
• Clúster Local: Anomalías concentradas en subsistemas de memoria e I/O, con picos de writeback y acumulación de páginas sucias
• Entornos Cruzados: Retransmisión TCP aparece en ambos entornos, típicamente asociada con desbalance de NCCL

Trabajo Relacionado

Comparación de Métodos de Monitoreo Existentes

Según la Tabla 1 del artículo, los métodos existentes se dividen en tres categorías:

1. Analizadores a Nivel de Aplicación: TensorFlow Profiler, PyTorch Profiler - requieren instrumentación de código
2. Herramientas de Sistema: AWS SageMaker, Prometheus - detección basada en reglas
3. Rastreo de Bajo Nivel: Herramientas BCC/eBPF, RL-Scope - alto costo o cobertura limitada

Ventajas de Reveal

• Sin Instrumentación: Completamente basado en telemetría a nivel de host
• Cobertura de Todos los Subsistemas: CPU, GPU, memoria, red, almacenamiento
• Detección Automática de Anomalías: Método de aprendizaje automático no supervisado
• Atribución de Hardware: Mapeo de anomalías a componentes de hardware específicos

Conclusiones y Discusión

Conclusiones Principales

1. Viabilidad del Enfoque Centrado en Hardware: Es posible detectar efectivamente anomalías en cargas de trabajo de ML utilizando únicamente señales de hardware
2. Efectividad de Detección No Supervisada: La combinación de tres detectores puede identificar con precisión múltiples tipos de anomalías
3. Mejora de Rendimiento Práctica: Identificación y corrección exitosa de problemas de configuración, logrando mejoras significativas de rendimiento
4. Alta Portabilidad: 91% del código es reutilizable entre plataformas

Limitaciones

1. Configuración Estática: Actualmente utiliza tasas de muestreo y tamaños de ventana fijos, incapaz de adaptarse a dinámicas de carga de trabajo
2. Detección Pasiva: Solo puede detectar anomalías, incapaz de resolver problemas automáticamente
3. Corrección Manual: Requiere intervención manual del operador para reparación de problemas

Direcciones Futuras

1. Muestreo Adaptativo: Ajuste de frecuencia de muestreo basado en métodos heurísticos
2. Corrección Automática: Investigación de intervenciones ligeras en tiempo de ejecución, como activación automática de rebalanceo de IRQ
3. Extensión de Detectores: Exploración de métodos adicionales de detección de anomalías no supervisada

Evaluación Profunda

Fortalezas

1. Innovación Fuerte: Primer método propuesto de detección de anomalías de ML basado en señales de hardware puro, resolviendo el problema de observabilidad en entornos en nube
2. Experimentación Completa: Pruebas en múltiples plataformas de hardware con más de 30 modelos, conjunto de datos rico
3. Alto Valor Práctico: Baja sobrecarga (<2% CPU), alta portabilidad (91% reutilización de código)
4. Resultados Convincentes: Mejora de rendimiento real del 5.97% demuestra efectividad del método
5. Contribución de Código Abierto: Proporciona conjunto de datos completo y kit de herramientas

Deficiencias

1. Latencia de Detección: Latencia extremo a extremo de 2.26 segundos puede no ser adecuada para aplicaciones en tiempo real
2. Ingeniería de Características: Proceso de selección de métricas y extracción de características relativamente complejo, requiere conocimiento especializado
3. Alcance de Evaluación: Principalmente probado en entornos académicos, la complejidad del entorno de producción puede presentar nuevos desafíos
4. Profundidad de Análisis de Causa Raíz: Aunque puede atribuir a subsistemas, el análisis específico de causa raíz aún requiere intervención manual

Impacto

1. Contribución Académica: Proporciona nueva dirección de investigación para monitoreo de rendimiento de sistemas de ML
2. Valor Práctico: Ofrece a proveedores de servicios en nube solución de monitoreo sin necesidad de acceso invasivo a entornos de usuario
3. Reproducibilidad: Código abierto y conjuntos de datos apoyan reproducción de investigación y extensión

Escenarios Aplicables

1. Proveedores de Servicios en Nube: Necesidad de optimización de rendimiento sin acceso a cargas de trabajo de usuario
2. Centros HPC: Monitoreo y diagnóstico de problemas de rendimiento de cargas de trabajo de ML
3. Computación Perimetral: Monitoreo ligero en entornos con recursos limitados
4. Instituciones de Investigación: Análisis de rendimiento de sistemas de ML e investigación de optimización

Referencias

El artículo cita 77 referencias relacionadas, abarcando:

• Herramientas de análisis de rendimiento de ML: Hotline, RL-Scope, Plumber, etc.
• Métodos de detección de anomalías: Bosque de Aislamiento, PCA, Distancia de Mahalanobis, etc.
• Monitoreo de sistemas: Prometheus, AWS CloudWatch, etc.
• Frameworks de ML: PyTorch, TensorFlow, etc.

Evaluación General: Este es un artículo de investigación de sistemas de alta calidad que propone un método innovador de detección de anomalías centrado en hardware, resolviendo problemas prácticos de monitoreo de cargas de trabajo de ML en entornos en nube. El diseño experimental es completo, los resultados son convincentes y tiene valor significativo tanto para la comunidad académica como para la industria.