Détection des Anomalies dans l'Infrastructure d'Apprentissage Automatique via la Télémétrie Matérielle

Informations Fondamentales

• ID de l'article : 2510.26008
• Titre : Detecting Anomalies in Systems for AI Using Hardware Telemetry
• Auteurs : Ziji Chen, Steven W. D. Chien, Peng Qian, Noa Zilberman (Université d'Oxford)
• Classification : cs.PF (Performance), cs.AR (Architecture Informatique), cs.DC (Informatique Distribuée), cs.LG (Apprentissage Automatique)
• Date de publication : 31 octobre 2025 (arXiv v2)
• Lien de l'article : https://arxiv.org/abs/2510.26008v2

Résumé

L'apprentissage automatique moderne s'est développé en un écosystème entièrement intégré combinant matériel, logiciel, réseau et applications. De nombreux utilisateurs dépendent des fournisseurs de services cloud pour obtenir des ressources élastiques, isolées et rentables. Cependant, ces plateformes en tant que service utilisent la virtualisation, ce qui empêche les opérateurs d'avoir une visibilité sur les charges de travail des utilisateurs. Cela entrave l'optimisation des ressources par les opérateurs, ce qui est essentiel pour assurer l'efficacité des coûts et minimiser le temps d'exécution. Cet article propose que l'optimisation au niveau du système soit possible sans connaissance de la charge de travail. Nous présentons Reveal, une approche centrée sur le matériel qui s'appuie uniquement sur les signaux matériels entièrement accessibles aux opérateurs. En analysant les performances de plus de 30 modèles ML populaires sur diverses plates-formes matérielles, nous avons développé un pipeline d'apprentissage non supervisé pour détecter les anomalies. Avec Reveal, nous avons identifié avec succès des problèmes de configuration réseau et système, accélérant le modèle DeepSeek de 5,97 %.

Contexte et Motivation de la Recherche

Problèmes Fondamentaux

1. Manque d'observabilité : La virtualisation des plates-formes cloud masque le matériel sous-jacent, empêchant les opérateurs d'accéder aux informations de charge de travail de haut niveau, rendant difficile l'optimisation au niveau du système
2. Difficulté de détection des goulots d'étranglement : Les charges de travail ML présentent un couplage étroit entre matériel et logiciel, où les petites inefficacités peuvent entraîner des dégradations de performance en cascade au niveau du système
3. Limitations des outils existants : Nécessitent une intégration au niveau de l'application, une surcharge d'exécution élevée (jusqu'à 90,2 %), couverture limitée

Importance du Problème

• Les accélérateurs spécialisés comme les GPU sont coûteux (dizaines de milliers de dollars par GPU)
• La demande de ressources IA en cloud devrait augmenter de 30 % par an jusqu'en 2030
• Même les erreurs de configuration mineures peuvent entraîner une dégradation de performance de 1,5 fois
• L'entraînement distribué dépend fortement de la communication collective, vulnérable aux problèmes réseau

Limitations des Approches Existantes

1. Dépendance à l'observabilité de haut niveau : La plupart des outils nécessitent des informations au niveau de l'application, indisponibles dans les environnements virtualisés
2. Surcharge élevée : Plumber ajoute 21 % de surcharge, RL-Scope ajoute 90,2 % au temps de lancement des noyaux GPU
3. Détection basée sur des règles : Nécessite un ajustement des seuils spécifiques à la charge de travail, faible portabilité
4. Couverture limitée : Les analyseurs de framework couvrent généralement uniquement l'application et l'exécution du framework

Contributions Principales

1. Proposition du framework Reveal : Un framework d'analyse centrée sur le matériel et de détection d'anomalies avec haute portabilité, déployabilité et capacité d'analyse
2. Identification des indicateurs de performance clés : Détermination d'un ensemble d'indicateurs de performance de bas niveau représentant le comportement des charges de travail ML sur le matériel, avec publication en open source de tous les ensembles de données collectés
3. Développement d'un pipeline de détection non supervisée : Détection réussie des problèmes de performance dans les charges de travail ML conteneurisées, identification des goulots d'étranglement système et accélération de DeepSeek de 5,97 %

Détails de la Méthode

Définition de la Tâche

Entrée : Données de télémétrie matérielle au niveau de l'hôte (métriques CPU, GPU, mémoire, réseau, stockage) Sortie : Détection de fenêtres d'anomalies, attribution aux sous-systèmes, rapport d'analyse des causes profondes Contraintes : Utilisation exclusive de signaux matériels accessibles aux opérateurs, sans connaissance de charge de travail de haut niveau

Architecture du Modèle

1. Collecteur de Télémétrie (Telemetry Collector)

• Collecte d'environ 150 types de métriques uniques utilisant perf, procfs, nvidia-smi et outils Linux standard
• Extension à plus de 700 canaux de séries temporelles lors de la réplication entre cœurs CPU et GPU
• Surcharge CPU maintenue en dessous de 1,5 %

2. Réanalyse des Métriques et Extraction de Caractéristiques (Metric Reanalysis and Feature Extraction)

• Filtrage des métriques : Élagage basé sur la corrélation, conservation d'environ 60 % des métriques au seuil |r|=0,5
• Métriques dérivées : Calcul de l'IPC (débit d'exécution), taux de mauvaise prédiction de branche, taux de défauts de cache, etc.
• Fenêtres glissantes : Fenêtres de 3 secondes, pas de 1 seconde, extraction de caractéristiques statistiques et temporelles

3. Moteur de Détection d'Anomalies (Anomaly Detection Engine)

Emploi de trois méthodes non supervisées complémentaires :

• Z-score : Détection d'écart normalisé, marquage des fenêtres dépassant le 99e percentile
• Distance de Mahalanobis dans l'espace PCA : Prise en compte de la corrélation entre métriques et des différences d'échelle
• Forêt d'Isolation (Isolation Forest) : Méthode d'ensemble basée sur les arbres, taux de contamination de 1 %

Points d'Innovation Technique

1. Approche centrée sur le matériel : Entièrement basée sur les signaux matériels, évitant la dépendance à l'observabilité de haut niveau
2. Fusion de plusieurs détecteurs : Réduction des faux positifs par cohérence entre détecteurs, amélioration de la précision de détection
3. Attribution aux sous-systèmes : Mappage des anomalies aux sous-systèmes matériels spécifiques (CPU, GPU, mémoire, réseau, stockage)
4. Analyse multi-couches : Une seule fenêtre d'anomalie peut impliquer plusieurs signaux connexes, fournissant des preuves d'anomalie plus fortes

Configuration Expérimentale

Ensemble de Données

• Applications ML : Plus de 30 modèles populaires, incluant BERT, BART, ResNet, ViT, VGG, DeepSeek, LLaMA, Mistral
• Types de tâches : Classification de texte, questions sur tableaux, classification d'images, segmentation sémantique
• Ensembles de données : GLUE/SST2, WikiSQL, PASCAL VOC, CIFAR, MNIST
• Nombre d'exécutions : 10 exécutions par type de charge de travail pour assurer la fiabilité statistique

Environnement Expérimental

1. Cluster HPC :
   • Deux nœuds, GPU NVIDIA Tesla V100 (32 Go), CPU Intel Xeon Platinum 8628
   • Un nœud, quatre GPU NVIDIA H100 (96 Go HBM3), CPU Intel Sapphire Rapids
2. Cluster Local :
   • 9 serveurs, CPU AMD EPYC 7443P (24 cœurs), 256 Go de mémoire
   • Configuration d'entraînement distribué avec 99 conteneurs

Métriques d'Évaluation

• Précision de détection : Taux de précision de l'identification des fenêtres d'anomalies
• Attribution aux sous-systèmes : Capacité de mappage correct aux sous-systèmes matériels
• Amélioration de performance : Amélioration du temps d'exécution de bout en bout
• Évaluation de la surcharge : Utilisation CPU, besoins de stockage, temps d'exécution des détecteurs

Résultats Expérimentaux

Résultats Principaux

Surcharge de Performance

• Surcharge CPU : 1,2-1,4 % avec intervalle d'échantillonnage de 100 ms, descend en dessous de 0,6 % à 600 ms
• Besoins de stockage : 42-43 Ko/s/hôte avant filtrage, 14-22 Ko/s après filtrage
• Latence de détection : Extraction de caractéristiques 1,46±0,02 s, bout en bout 2,26±0,17 s

Efficacité de Détection d'Anomalies

• Stabilité des métriques : 99,75 % des paires charge de travail-métrique montrent une similarité statistiquement significative (p<0,05)
• Cohérence inter-configurations : IoU médian 0,50 pour configuration par défaut vs fine-grained, taux de succès 0,92

Études de Cas

Cas 1 : Anomalie NUMA (Sous-système Mémoire)

• Détection : Fenêtres 118-123 montrant baisse d'IPC et augmentation des cycles de défaut L3
• Analyse : Mémoire inter-socket et trafic PCIe causant augmentation de latence
• Correction : Liaison consciente de NUMA, attachement des processus à un seul nœud NUMA
• Résultat : Amélioration du fine-tuning DeepSeek-7B de 1823,4±46,1 s à 1714,6±70,0 s (amélioration de 5,97 %)

Cas 2 : Erreur de Configuration NCCL-QP (Sous-système Réseau)

• Détection : Augmentation CPU Busy %, rafales de trafic TX/RX ib0, baisse de puissance GPU
• Analyse : Configuration à QP unique causant goulot d'étranglement de traitement d'achèvement
• Correction : Augmentation de 1QP à configuration 2QP
• Résultat : Amélioration du temps d'exécution de 1825,4±46,1 s à 1769,3±16,7 s (amélioration de 3,1 %)

Cas 3 : Déséquilibre IRQ (Sous-système CPU)

• Détection : Variance CPU Busy % et anomalies des compteurs IRQ
• Correction : Activation du service irqbalance pour distribution automatique de la charge d'interruption
• Résultat : Anomalie de retransmission TCP réduite de 6,07 % à 3,51 %

Cas 4 : Erreur de Configuration HugePages (Sous-système Mémoire)

• Détection : Anomalie d'utilisation mémoire inter-nœuds
• Analyse : Préallocation de HugePages 1 Gio signalée comme mémoire "utilisée"
• Correction : Configuration pour allocation HugePages 2 Mio par défaut

Cas 5 : Test d'Injection de Perte de Paquets (Sous-système Réseau)

• Capacité de détection : Distinction entre retransmissions inhérentes à la charge de travail et retransmissions dues aux défaillances
• Profondeur d'analyse : Fourniture de contexte multi-couches, des compteurs de couche transport aux pics d'IRQ CPU et aux arrêts GPU

Analyse des Modèles d'Anomalies

• Cluster HPC : Signaux côté CPU (Bzy_MHz, IRQ) dominants, contribuant à plus de 50 % des caractéristiques d'anomalies
• Cluster Local : Anomalies concentrées sur sous-systèmes mémoire et E/S, avec pics de writeback et accumulation de pages sales
• Inter-environnements : Retransmissions TCP apparaissant dans les deux environnements, généralement associées à déséquilibre NCCL

Travaux Connexes

Comparaison des Méthodes de Surveillance Existantes

Selon le Tableau 1 de l'article, les méthodes existantes se divisent en trois catégories :

1. Analyseurs au niveau de l'application : TensorFlow Profiler, PyTorch Profiler - nécessitent instrumentation du code
2. Outils système : AWS SageMaker, Prometheus - détection basée sur des règles
3. Traçage de bas niveau : Outils BCC/eBPF, RL-Scope - surcharge élevée ou couverture limitée

Avantages de Reveal

• Sans instrumentation : Entièrement basé sur la télémétrie au niveau de l'hôte
• Couverture complète des sous-systèmes : CPU, GPU, mémoire, réseau, stockage
• Détection d'anomalies automatique : Méthodes ML non supervisées
• Attribution matérielle : Mappage des anomalies aux composants matériels spécifiques

Conclusions et Discussion

Conclusions Principales

1. Faisabilité de l'approche centrée sur le matériel : Les signaux matériels seuls suffisent pour détecter efficacement les anomalies dans les charges de travail ML
2. Efficacité de la détection non supervisée : La combinaison de trois détecteurs peut identifier avec précision plusieurs types d'anomalies
3. Amélioration de performance réelle : Identification et correction réussies des problèmes de configuration, obtenant des améliorations de performance significatives
4. Haute portabilité : 91 % du code réutilisable entre plates-formes

Limitations

1. Configuration statique : Utilisation actuelle de taux d'échantillonnage et taille de fenêtre fixes, incapacité à s'adapter à la dynamique de la charge de travail
2. Détection passive : Peut uniquement détecter les anomalies, incapable de résoudre automatiquement les problèmes
3. Correction manuelle : Nécessite intervention manuelle de l'opérateur pour corriger les problèmes

Directions Futures

1. Échantillonnage adaptatif : Ajustement de la fréquence d'échantillonnage basé sur des heuristiques
2. Correction automatique : Recherche d'interventions légères au niveau de l'exécution, comme déclenchement automatique du rééquilibrage IRQ
3. Extension des détecteurs : Exploration de méthodes supplémentaires de détection d'anomalies non supervisées

Évaluation Approfondie

Points Forts

1. Innovation forte : Première proposition d'une méthode de détection d'anomalies ML basée sur des signaux matériels purs, résolvant le problème d'observabilité en environnement cloud
2. Expérimentation complète : Test sur plus de 30 modèles sur diverses plates-formes matérielles, ensemble de données riche
3. Valeur pratique élevée : Surcharge faible (<2 % CPU), haute portabilité (91 % de réutilisation de code)
4. Résultats convaincants : Amélioration de performance réelle de 5,97 % prouvant l'efficacité de la méthode
5. Contribution open source : Fourniture d'ensemble de données complet et de kit d'outils

Insuffisances

1. Latence de détection : La latence bout en bout de 2,26 secondes peut ne pas convenir aux applications en temps réel
2. Ingénierie des caractéristiques : Le processus de sélection des métriques et d'extraction de caractéristiques est relativement complexe, nécessitant expertise
3. Portée d'évaluation : Principalement testé en environnement académique, la complexité de l'environnement de production peut présenter de nouveaux défis
4. Profondeur d'analyse des causes profondes : Bien que capable d'attribution aux sous-systèmes, l'analyse spécifique des causes profondes nécessite toujours intervention humaine

Impact

1. Contribution académique : Fournit une nouvelle direction de recherche pour la surveillance de performance des systèmes ML
2. Valeur pratique : Fournit aux fournisseurs de services cloud une solution de surveillance sans intrusion dans l'environnement utilisateur
3. Reproductibilité : Code open source et ensemble de données supportant la reproduction et l'extension de la recherche

Scénarios d'Application

1. Fournisseurs de services cloud : Nécessitant optimisation de performance sans accès aux charges de travail utilisateur
2. Centres HPC : Nécessitant surveillance et diagnostic des problèmes de performance des charges de travail ML
3. Informatique en périphérie : Surveillance légère dans les environnements aux ressources limitées
4. Institutions de recherche : Analyse et optimisation de performance des systèmes ML

Références Bibliographiques

L'article cite 77 références pertinentes, couvrant :

• Outils d'analyse de performance ML : Hotline, RL-Scope, Plumber, etc.
• Méthodes de détection d'anomalies : Forêt d'Isolation, PCA, Distance de Mahalanobis, etc.
• Surveillance système : Prometheus, AWS CloudWatch, etc.
• Frameworks ML : PyTorch, TensorFlow, etc.

Évaluation Globale : Ceci est un article de recherche système de haute qualité proposant une méthode innovante de détection d'anomalies centrée sur le matériel, résolvant des problèmes pratiques de surveillance des charges de travail ML en environnement cloud. La conception expérimentale est complète, les résultats convaincants, avec valeur importante pour le monde académique et industriel.