Anomalieerkennung in Machine-Learning-Infrastruktur mittels Hardware-Telemetrie

Grundinformationen

• Paper-ID: 2510.26008
• Titel: Detecting Anomalies in Systems for AI Using Hardware Telemetry
• Autoren: Ziji Chen, Steven W. D. Chien, Peng Qian, Noa Zilberman (University of Oxford)
• Klassifizierung: cs.PF (Performance), cs.AR (Computer Architecture), cs.DC (Distributed Computing), cs.LG (Machine Learning)
• Veröffentlichungsdatum: 31. Oktober 2025 (arXiv v2)
• Paper-Link: https://arxiv.org/abs/2510.26008v2

Zusammenfassung

Modernes Machine Learning hat sich zu einem eng gekoppelten Full-Stack-Ökosystem entwickelt, das Hardware, Software, Netzwerk und Anwendungen kombiniert. Viele Benutzer verlassen sich auf Cloud-Anbieter für elastische, isolierte und kosteneffiziente Ressourcen. Diese Platform-as-a-Service-Lösungen nutzen jedoch Virtualisierung, was dazu führt, dass Betreiber keinen Einblick in Benutzer-Workloads haben. Dies behindert die Ressourcenoptimierung durch Betreiber, was jedoch entscheidend für die Gewährleistung von Kosteneffizienz und Minimierung der Ausführungszeit ist. In diesem Paper wird argumentiert, dass Systemoptimierung ohne Workload-Wissen möglich ist. Wir präsentieren Reveal, einen hardwaregestützten Ansatz, der sich ausschließlich auf Hardware-Signale stützt, auf die Betreiber vollständig zugreifen können. Durch die Analyse von über 30 beliebten ML-Modellen auf verschiedenen Hardware-Plattformen wurde eine unüberwachte Lernpipeline zur Anomalieerkennung entwickelt. Mit Reveal gelang es uns, Netzwerk- und Systemkonfigurationsprobleme zu identifizieren und das DeepSeek-Modell um 5,97% zu beschleunigen.

Forschungshintergrund und Motivation

Kernprobleme

1. Fehlende Observabilität: Die Virtualisierung von Cloud-Plattformen verbirgt die zugrunde liegende Hardware, Betreiber können keine hochrangigen Workload-Informationen erhalten und können daher keine Systemoptimierung durchführen
2. Schwierige Erkennung von Leistungsengpässen: ML-Workloads weisen eine enge Hardware-Software-Kopplung auf; kleine Ineffizienzen können kaskadierend zu Systemleistungsabfällen führen
3. Einschränkungen bestehender Tools: Erfordern Anwendungsintegration, hohe Laufzeit-Overhead (bis zu 90,2%), begrenzte Abdeckung

Bedeutung des Problems

• Spezialisierte Beschleuniger wie GPUs sind kostspielig (einzelne GPUs kosten Zehntausende Dollar)
• Die Nachfrage nach Cloud-AI-Ressourcen wird bis 2030 voraussichtlich um 30% pro Jahr wachsen
• Selbst geringfügige Konfigurationsfehler können zu 1,5-facher Leistungsabnahme führen
• Verteiltes Training ist stark von kollektiver Kommunikation abhängig und anfällig für Netzwerkprobleme

Einschränkungen bestehender Methoden

1. Abhängigkeit von hochrangiger Observabilität: Die meisten Tools benötigen Anwendungsinformationen, die in virtualisierten Umgebungen nicht verfügbar sind
2. Hoher Overhead: Plumber erhöht den Overhead um 21%, RL-Scope um 90,2% GPU-Kernel-Startzeit
3. Regelgesteuerte Erkennung: Erfordert workload-spezifische Schwellenwertabstimmung, schlechte Portabilität
4. Begrenzte Abdeckung: Framework-Analyzer decken normalerweise nur Anwendung und Framework-Laufzeit ab

Kernbeiträge

1. Präsentation des Reveal-Frameworks: Ein hardwaregestütztes Analyse- und Anomalieerkennung-Framework mit hoher Portabilität, Bereitstellbarkeit und Analysefähigkeit
2. Identifikation kritischer Leistungsindikatoren: Bestimmung einer Reihe von Low-Level-Leistungsindikatoren, die das Verhalten von ML-Workloads auf Hardware darstellen, und Open-Source-Bereitstellung aller erfassten Datensätze
3. Entwicklung einer unüberwachten Erkennungspipeline: Erfolgreiche Erkennung von Leistungsproblemen in containerisierten ML-Workloads, Identifikation von Systemengpässen und 5,97% Beschleunigung von DeepSeek

Methodische Details

Aufgabendefinition

Eingabe: Host-Level-Hardware-Telemetriedaten (CPU-, GPU-, Speicher-, Netzwerk-, Speichermetriken) Ausgabe: Anomaliefenster-Erkennung, Subsystem-Zuordnung, Grundursachen-Analysebericht Einschränkungen: Verwendung nur von Hardware-Level-Signalen, auf die Betreiber zugreifen können, ohne hochrangiges Workload-Wissen

Modellarchitektur

1. Telemetrie-Kollektor (Telemetry Collector)

• Erfassung von etwa 150 eindeutigen Metriktypen mit perf, procfs, nvidia-smi und Standard-Linux-Tools
• Erweiterung auf über 700 Zeitreihen-Kanäle bei Replikation über CPU-Kerne und GPU
• CPU-Overhead bleibt unter 1,5%

2. Metrik-Reanalyse und Merkmalsextraktion (Metric Reanalysis and Feature Extraction)

• Metrik-Filterung: Korrelationsgesteuerte Beschneidung, Beibehaltung von etwa 60% der Metriken bei |r|=0,5-Schwellenwert
• Abgeleitete Metriken: Berechnung von IPC (Ausführungsdurchsatz), Branch-Misprediction-Rate, Cache-Miss-Rate usw.
• Gleitendes Fenster: 3-Sekunden-Fenster, 1-Sekunden-Schritte, Extraktion statistischer und zeitlicher Merkmale

3. Anomalieerkennung-Engine (Anomaly Detection Engine)

Einsatz von drei komplementären unüberwachten Methoden:

• Z-Score: Standardisierte Abweichungserkennung, Markierung von Fenstern über dem 99. Perzentil
• Mahalanobis-Distanz im PCA-Unterraum: Berücksichtigung von Metrik-Korrelationen und Skalierungsunterschieden
• Isolation Forest: Baumbasierte Ensemble-Methode, Kontaminationsrate 1%

Technische Innovationen

1. Hardwaregestützter Ansatz: Vollständig auf Hardware-Signalen basierend, vermeidet Abhängigkeit von hochrangiger Observabilität
2. Multi-Detektor-Fusion: Reduzierung von Falschalarmen durch Konsistenz zwischen Detektoren, Verbesserung der Erkennungsgenauigkeit
3. Subsystem-Zuordnung: Zuordnung von Anomalien zu spezifischen Hardware-Subsystemen (CPU, GPU, Speicher, Netzwerk, Speicher)
4. Schichtübergreifende Analyse: Ein einzelnes Anomaliefenster kann mehrere verwandte Signale betreffen und stärkere Anomalieevidenz liefern

Experimentelle Einrichtung

Datensatz

• ML-Anwendungen: 30+ beliebte Modelle, einschließlich BERT, BART, ResNet, ViT, VGG, DeepSeek, LLaMA, Mistral
• Aufgabentypen: Textklassifizierung, Tabellen-Frage-Beantwortung, Bildklassifizierung, semantische Segmentierung
• Datensätze: GLUE/SST2, WikiSQL, PASCAL VOC, CIFAR, MNIST
• Durchläufe: Jede Workload wurde 10-mal ausgeführt, um statistische Zuverlässigkeit zu gewährleisten

Experimentelle Umgebung

1. HPC-Cluster:
   • Zwei Knoten, NVIDIA Tesla V100 GPU (32GB), Intel Xeon Platinum 8628 CPU
   • Ein Knoten, vier NVIDIA H100 GPUs (96GB HBM3), Intel Sapphire Rapids CPU
2. Lokaler Cluster:
   • 9 Server, AMD EPYC 7443P CPU (24 Kerne), 256GB Speicher
   • 99 Container verteilte Trainingseinrichtung

Bewertungsmetriken

• Erkennungsgenauigkeit: Genauigkeit der Anomaliefenster-Identifikation
• Subsystem-Zuordnung: Fähigkeit zur korrekten Zuordnung zu Hardware-Subsystemen
• Leistungsverbesserung: Verbesserung der End-to-End-Laufzeit
• Overhead-Bewertung: CPU-Nutzung, Speicherbedarf, Detektor-Laufzeit

Experimentelle Ergebnisse

Hauptergebnisse

Leistungs-Overhead

• CPU-Overhead: 1,2-1,4% bei 100ms Abtastintervall, unter 0,6% bei 600ms
• Speicherbedarf: 42-43 KB/s/Host vor Filterung, 14-22 KB/s nach Filterung
• Erkennungsverzögerung: Merkmalsextraktion 1,46±0,02s, End-to-End 2,26±0,17s

Anomalieerkennung-Effektivität

• Metrik-Stabilität: 99,75% der Workload-Metrik-Paare zeigen statistisch signifikante Ähnlichkeit (p<0,05)
• Konfigurationsübergreifende Konsistenz: Median-IoU 0,50 für Standard- vs. Feinkörnige Einstellungen, Hit-Rate 0,92

Fallstudien

Fallstudie 1: NUMA-Anomalie (Speicher-Subsystem)

• Erkennung: Fenster 118-123 zeigen IPC-Abfall und erhöhte L3-Miss-Zyklen
• Analyse: Speicher über Sockets und PCIe-Verkehr führen zu erhöhter Latenz
• Behebung: NUMA-bewusste Bindung, Prozesse an einzelnen NUMA-Knoten gebunden
• Effekt: DeepSeek-7B Fine-Tuning von 1823,4±46,1s auf 1714,6±70,0s verbessert (5,97% Verbesserung)

Fallstudie 2: NCCL-QP-Konfigurationsfehler (Netzwerk-Subsystem)

• Erkennung: CPU Busy% erhöht, ib0 TX/RX-Verkehr sprunghaft, GPU-Leistung sinkt
• Analyse: Single-QP-Konfiguration führt zu Fertigstellungsverarbeitungsengpass
• Behebung: Erhöhung von 1QP auf 2QP-Konfiguration
• Effekt: Laufzeit von 1825,4±46,1s auf 1769,3±16,7s verbessert (3,1% Verbesserung)

Fallstudie 3: IRQ-Unausgeglichenheit (CPU-Subsystem)

• Erkennung: CPU Busy% Varianz und IRQ-Zähler-Anomalien
• Behebung: irqbalance-Service aktiviert, um Interrupt-Last automatisch zu verteilen
• Effekt: TCP-Retransmission-Anomalien von 6,07% auf 3,51% reduziert

Fallstudie 4: HugePages-Konfigurationsfehler (Speicher-Subsystem)

• Erkennung: Speichernutzungs-Anomalien über Knoten hinweg
• Analyse: Vorallokierte 1GiB HugePages werden als "verwendeter" Speicher gemeldet
• Behebung: Konfiguration auf Standard-2MiB HugePages-Zuweisung

Fallstudie 5: Injizierter Paketverluststest (Netzwerk-Subsystem)

• Erkennungsfähigkeit: Unterscheidung zwischen inhärenten Workload-Retransmissionen und fehlerverursachten Retransmissionen
• Analysentiefe: Bereitstellung von schichtübergreifendem Kontext, von Transportschicht-Zählern bis zu CPU-IRQ-Spitzen und GPU-Stalls

Anomaliemuster-Analyse

• HPC-Cluster: CPU-seitige Signale (Bzy_MHz, IRQ) dominieren, tragen über 50% zu Anomalieeigenschaften bei
• Lokaler Cluster: Anomalien konzentrieren sich auf Speicher- und I/O-Subsysteme, Writeback-Spitzen und Dirty-Page-Ansammlung
• Umgebungsübergreifend: TCP-Retransmissionen treten in beiden Umgebungen auf, normalerweise mit NCCL-Unausgeglichenheit verbunden

Verwandte Arbeiten

Vergleich bestehender Überwachungsmethoden

Gemäß Tabelle 1 des Papers werden bestehende Methoden in drei Kategorien eingeteilt:

1. Anwendungsebenen-Analyzer: TensorFlow Profiler, PyTorch Profiler - erfordern Code-Instrumentation
2. Systemtools: AWS SageMaker, Prometheus - regelgesteuerte Erkennung
3. Low-Level-Tracing: BCC/eBPF-Tools, RL-Scope - hoher Overhead oder begrenzte Abdeckung

Vorteile von Reveal

• Keine Instrumentation erforderlich: Vollständig auf Host-Level-Telemetrie basierend
• Vollständige Subsystem-Abdeckung: CPU, GPU, Speicher, Netzwerk, Speicher
• Automatische Anomalieerkennung: Unüberwachte ML-Methode
• Hardware-Zuordnung: Zuordnung von Anomalien zu spezifischen Hardware-Komponenten

Schlussfolgerungen und Diskussion

Hauptschlussfolgerungen

1. Hardwaregestützter Ansatz ist machbar: Nur mit Hardware-Signalen können ML-Workload-Anomalien effektiv erkannt werden
2. Unüberwachte Erkennung ist effektiv: Die Kombination von drei Detektoren kann verschiedene Anomalietypen genau identifizieren
3. Tatsächliche Leistungsverbesserung: Erfolgreiche Identifikation und Behebung von Konfigurationsproblemen mit signifikanten Leistungsverbesserungen
4. Hohe Portabilität: 91% des Codes können plattformübergreifend wiederverwendet werden

Einschränkungen

1. Statische Konfiguration: Derzeit werden feste Abtastraten und Fenstergröße verwendet, kann sich nicht an dynamische Workloads anpassen
2. Passive Erkennung: Kann nur Anomalien erkennen, kann Probleme nicht automatisch lösen
3. Manuelle Behebung: Erfordert manuelle Intervention durch Betreiber zur Problembehebung

Zukünftige Richtungen

1. Adaptive Abtastung: Anpassung der Abtastfrequenz basierend auf heuristischen Methoden
2. Automatische Behebung: Erforschung leichtgewichtiger Laufzeit-Interventionen, wie automatisch ausgelöste IRQ-Neuausgleichung
3. Erweiterte Detektoren: Erforschung weiterer unüberwachter Anomalieerkennung-Methoden

Tiefgreifende Bewertung

Stärken

1. Starke Innovation: Erste Methode zur reinen Hardware-Signal-basierten ML-Anomalieerkennung, löst Observabilitätsprobleme in Cloud-Umgebungen
2. Umfangreiche Experimente: Tests auf mehreren Hardware-Plattformen mit 30+ Modellen, reichhaltiger Datensatz
3. Hoher praktischer Wert: Niedriger Overhead (<2% CPU), hohe Portabilität (91% Code-Wiederverwendung)
4. Überzeugende Ergebnisse: 5,97% tatsächliche Leistungsverbesserung beweist Methodeneffektivität
5. Open-Source-Beitrag: Bereitstellung vollständiger Datensätze und Toolkits

Schwächen

1. Erkennungsverzögerung: 2,26 Sekunden End-to-End-Verzögerung möglicherweise nicht geeignet für Echtzeit-Anwendungen
2. Merkmalsengineering: Metrik-Auswahl und Merkmalsextraktionsprozess relativ komplex, erfordert Fachkenntnisse
3. Bewertungsbereich: Hauptsächlich in akademischen Umgebungen getestet, Komplexität von Produktionsumgebungen könnte neue Herausforderungen mit sich bringen
4. Tiefe der Grundursachen-Analyse: Obwohl Zuordnung zu Subsystemen möglich ist, erfordert spezifische Grundursachen-Analyse immer noch manuelle Intervention

Auswirkungen

1. Akademischer Beitrag: Bietet neue Forschungsrichtung für ML-Systemleistungsüberwachung
2. Praktischer Wert: Bietet Cloud-Service-Providern Überwachungslösung ohne Benutzer-Workload-Zugriff
3. Reproduzierbarkeit: Open-Source-Code und Datensätze unterstützen Forschungsreproduzierung und Erweiterung

Anwendungsszenarien

1. Cloud-Service-Provider: Benötigen Leistungsoptimierung ohne Zugriff auf Benutzer-Workloads
2. HPC-Zentren: Benötigen Überwachung und Diagnose von ML-Workload-Leistungsproblemen
3. Edge Computing: Leichtgewichtige Überwachung in ressourcenbeschränkten Umgebungen
4. Forschungsinstitutionen: ML-Systemleistungsanalyse und Optimierungsforschung

Literaturverzeichnis

Das Paper zitiert 77 relevante Referenzen, die folgende Bereiche abdecken:

• ML-Leistungsanalyse-Tools: Hotline, RL-Scope, Plumber usw.
• Anomalieerkennung-Methoden: Isolation Forest, PCA, Mahalanobis-Distanz usw.
• Systemüberwachung: Prometheus, AWS CloudWatch usw.
• ML-Frameworks: PyTorch, TensorFlow usw.

Gesamtbewertung: Dies ist ein hochqualitatives Systemforschungspapier, das eine innovative hardwaregestützte Anomalieerkennung-Methode präsentiert und praktische Probleme der ML-Workload-Überwachung in Cloud-Umgebungen löst. Das experimentelle Design ist umfassend, die Ergebnisse sind überzeugend und das Paper hat wichtigen Wert für Wissenschaft und Industrie.