Rilevamento di Anomalie nell'Infrastruttura di Machine Learning tramite Telemetria Hardware

Informazioni Fondamentali

• ID Articolo: 2510.26008
• Titolo: Detecting Anomalies in Systems for AI Using Hardware Telemetry
• Autori: Ziji Chen, Steven W. D. Chien, Peng Qian, Noa Zilberman (University of Oxford)
• Classificazione: cs.PF (Performance), cs.AR (Computer Architecture), cs.DC (Distributed Computing), cs.LG (Machine Learning)
• Data di Pubblicazione: 31 ottobre 2025 (arXiv v2)
• Link Articolo: https://arxiv.org/abs/2510.26008v2

Riassunto

Il machine learning moderno si è evoluto in un ecosistema full-stack strettamente accoppiato, che combina hardware, software, rete e applicazioni. Molti utenti si affidano ai fornitori cloud per ottenere risorse elastiche, isolate ed economicamente efficienti. Tuttavia, queste piattaforme as-a-service utilizzano la virtualizzazione, causando una mancanza di visibilità degli operatori sui carichi di lavoro degli utenti. Ciò ostacola l'ottimizzazione delle risorse da parte degli operatori, fondamentale per garantire l'efficienza dei costi e minimizzare i tempi di esecuzione. Questo articolo propone che l'ottimizzazione a livello di sistema sia possibile senza conoscenza del carico di lavoro. Presentiamo Reveal, che adotta un approccio incentrato sull'hardware, affidandosi esclusivamente ai segnali hardware completamente accessibili agli operatori. Analizzando le prestazioni di oltre 30 modelli ML popolari su varie piattaforme hardware, abbiamo sviluppato una pipeline di apprendimento non supervisionato per rilevare anomalie. Utilizzando Reveal, abbiamo identificato con successo problemi di rete e configurazione del sistema, accelerando il modello DeepSeek del 5,97%.

Contesto di Ricerca e Motivazione

Problemi Fondamentali

1. Mancanza di Osservabilità: La virtualizzazione delle piattaforme cloud nasconde l'hardware sottostante, impedendo agli operatori di ottenere informazioni sui carichi di lavoro di alto livello, rendendo difficile l'ottimizzazione a livello di sistema
2. Difficoltà nel Rilevamento dei Colli di Bottiglia: I carichi di lavoro ML presentano un accoppiamento stretto tra hardware e software, dove piccole inefficienze possono causare degradazione a cascata delle prestazioni del sistema
3. Limitazioni degli Strumenti Esistenti: Richiedono integrazione a livello di applicazione, overhead di runtime elevato (fino al 90,2%), copertura limitata

Importanza del Problema

• Gli acceleratori specializzati come le GPU hanno costi elevati (decine di migliaia di dollari per GPU)
• La domanda di risorse AI nel cloud dovrebbe crescere del 30% annuo fino al 2030
• Anche errori di configurazione minori possono causare un degrado delle prestazioni di 1,5 volte
• L'addestramento distribuito dipende fortemente dalle comunicazioni collettive, vulnerabile ai problemi di rete

Limitazioni dei Metodi Esistenti

1. Dipendenza dall'Osservabilità di Alto Livello: La maggior parte degli strumenti richiede informazioni a livello di applicazione, non disponibili in ambienti virtualizzati
2. Overhead Elevato: Plumber aggiunge il 21% di overhead, RL-Scope aggiunge il 90,2% di tempo di avvio del kernel GPU
3. Rilevamento Basato su Regole: Richiede l'ottimizzazione di soglie specifiche per il carico di lavoro, scarsa portabilità
4. Copertura Limitata: Gli analizzatori del framework di solito coprono solo l'applicazione e il runtime del framework

Contributi Principali

1. Propone il Framework Reveal: Un framework di analisi incentrato sull'hardware e rilevamento di anomalie con elevata portabilità, distribuibilità e capacità di analisi accurata
2. Identifica Indicatori Chiave di Prestazione: Determina un insieme di indicatori di prestazione di basso livello che rappresentano il comportamento dei carichi di lavoro ML sull'hardware, e rende open-source tutti i dataset raccolti
3. Sviluppa una Pipeline di Rilevamento Non Supervisionato: Rileva con successo i problemi di prestazione nei carichi di lavoro ML containerizzati, identifica i colli di bottiglia del sistema e accelera DeepSeek del 5,97%

Dettagli del Metodo

Definizione del Compito

Input: Dati di telemetria hardware a livello di host (metriche CPU, GPU, memoria, rete, archiviazione) Output: Rilevamento di finestre anomale, attribuzione di sottosistemi, rapporto di analisi della causa radice Vincoli: Utilizzo esclusivo di segnali hardware a livello di host accessibili agli operatori, senza conoscenza avanzata del carico di lavoro

Architettura del Modello

1. Collettore di Telemetria (Telemetry Collector)

• Raccoglie circa 150 tipi di metriche univoche utilizzando perf, procfs, nvidia-smi e strumenti Linux standard
• Si estende a oltre 700 canali di serie temporali quando replicato tra core CPU e GPU
• L'overhead della CPU rimane al di sotto dell'1,5%

2. Rianalisi delle Metriche ed Estrazione di Caratteristiche (Metric Reanalysis and Feature Extraction)

• Filtraggio delle Metriche: Potatura guidata dalla correlazione, conservando circa il 60% delle metriche con soglia |r|=0,5
• Metriche Derivate: Calcola IPC (throughput di esecuzione), tasso di errore di previsione dei branch, tasso di cache miss, ecc.
• Finestra Scorrevole: Finestra di 3 secondi, passo di 1 secondo, estrae caratteristiche statistiche e temporali

3. Motore di Rilevamento di Anomalie (Anomaly Detection Engine)

Impiega tre metodi non supervisionati complementari:

• Z-score: Rilevamento della deviazione normalizzata, contrassegna le finestre che superano il 99° percentile
• Distanza di Mahalanobis nello Spazio Principale PCA: Considera la correlazione tra metriche e le differenze di scala
• Isolation Forest: Metodo ensemble basato su alberi, tasso di contaminazione 1%

Punti di Innovazione Tecnica

1. Approccio Incentrato sull'Hardware: Completamente basato su segnali hardware, evita la dipendenza dall'osservabilità di alto livello
2. Fusione di Rilevatori Multipli: Riduce i falsi positivi attraverso la coerenza tra rilevatori, migliorando l'accuratezza del rilevamento
3. Attribuzione di Sottosistemi: Mappa le anomalie a sottosistemi hardware specifici (CPU, GPU, memoria, rete, archiviazione)
4. Analisi Tra Livelli: Una singola finestra anomala può coinvolgere più segnali correlati, fornendo prove di anomalia più forti

Configurazione Sperimentale

Dataset

• Applicazioni ML: Oltre 30 modelli popolari, inclusi BERT, BART, ResNet, ViT, VGG, DeepSeek, LLaMA, Mistral
• Tipi di Compiti: Classificazione di testo, question answering su tabelle, classificazione di immagini, segmentazione semantica
• Dataset: GLUE/SST2, WikiSQL, PASCAL VOC, CIFAR, MNIST
• Numero di Esecuzioni: 10 esecuzioni per ogni tipo di carico di lavoro per garantire affidabilità statistica

Ambiente Sperimentale

1. Cluster HPC:
   • Nodo doppio, GPU NVIDIA Tesla V100 (32GB), CPU Intel Xeon Platinum 8628
   • Nodo singolo, quattro GPU NVIDIA H100 (96GB HBM3), CPU Intel Sapphire Rapids
2. Cluster Locale:
   • 9 server, CPU AMD EPYC 7443P (24 core), 256GB di memoria
   • Configurazione di addestramento distribuito con 99 container

Metriche di Valutazione

• Accuratezza del Rilevamento: Accuratezza nell'identificazione delle finestre anomale
• Attribuzione di Sottosistemi: Capacità di mappare correttamente ai sottosistemi hardware
• Miglioramento delle Prestazioni: Miglioramento del tempo di esecuzione end-to-end
• Valutazione dell'Overhead: Utilizzo della CPU, requisiti di archiviazione, tempo di esecuzione del rilevatore

Risultati Sperimentali

Risultati Principali

Overhead di Prestazione

• Overhead della CPU: 1,2-1,4% con intervallo di campionamento di 100ms, scende al di sotto dello 0,6% con 600ms
• Requisiti di Archiviazione: 42-43 KB/s/host prima del filtraggio, 14-22 KB/s dopo il filtraggio
• Latenza di Rilevamento: Estrazione di caratteristiche 1,46±0,02s, end-to-end 2,26±0,17s

Effetto del Rilevamento di Anomalie

• Stabilità delle Metriche: Il 99,75% delle coppie carico di lavoro-metrica mostra somiglianza statistica significativa (p<0,05)
• Coerenza Tra Configurazioni: IoU mediano 0,50 tra configurazione predefinita e fine-grained, tasso di hit 0,92

Analisi di Casi

Caso 1: Anomalia NUMA (Sottosistema di Memoria)

• Rilevamento: Finestre 118-123 mostrano calo dell'IPC e aumento dei cicli di fallimento L3
• Analisi: Memoria tra socket e traffico PCIe causano aumento della latenza
• Correzione: Binding consapevole di NUMA, binding dei processi a un singolo nodo NUMA
• Effetto: Messa a punto DeepSeek-7B da 1823,4±46,1s a 1714,6±70,0s (miglioramento del 5,97%)

Caso 2: Errore di Configurazione NCCL-QP (Sottosistema di Rete)

• Rilevamento: Aumento della CPU Busy%, burst del traffico TX/RX ib0, calo della potenza GPU
• Analisi: Configurazione a QP singolo causa collo di bottiglia nell'elaborazione dei completamenti
• Correzione: Aumento da configurazione 1QP a 2QP
• Effetto: Tempo di esecuzione da 1825,4±46,1s a 1769,3±16,7s (miglioramento del 3,1%)

Caso 3: Squilibrio IRQ (Sottosistema CPU)

• Rilevamento: Varianza della CPU Busy% e anomalia dei contatori IRQ
• Correzione: Abilitazione del servizio irqbalance per la distribuzione automatica del carico di interruzione
• Effetto: Anomalia di ritrasmissione TCP da 6,07% a 3,51%

Caso 4: Errore di Configurazione HugePages (Sottosistema di Memoria)

• Rilevamento: Anomalia nell'utilizzo della memoria tra nodi
• Analisi: HugePages preallocate da 1GiB segnalate come memoria "utilizzata"
• Correzione: Configurazione per allocazione predefinita di HugePages da 2MiB

Caso 5: Test di Iniezione di Perdita di Pacchetti (Sottosistema di Rete)

• Capacità di Rilevamento: Distingue tra ritrasmissioni intrinseche del carico di lavoro e quelle causate da guasti
• Profondità di Analisi: Fornisce contesto tra livelli, dai contatori del livello di trasporto all'impennata dell'IRQ della CPU e ai blocchi della GPU

Analisi dei Modelli di Anomalia

• Cluster HPC: I segnali lato CPU (Bzy_MHz, IRQ) dominano, contribuendo a oltre il 50% delle caratteristiche anomale
• Cluster Locale: Le anomalie si concentrano nei sottosistemi di memoria e I/O, con impennate di writeback e accumulo di pagine sporche
• Tra Ambienti: Le ritrasmissioni TCP appaiono in entrambi gli ambienti, di solito correlate a squilibrio NCCL

Lavori Correlati

Confronto dei Metodi di Monitoraggio Esistenti

Secondo la Tabella 1 dell'articolo, i metodi esistenti si dividono in tre categorie:

1. Analizzatori a Livello di Applicazione: TensorFlow Profiler, PyTorch Profiler - richiedono instrumentazione del codice
2. Strumenti di Sistema: AWS SageMaker, Prometheus - rilevamento basato su regole
3. Tracciamento di Basso Livello: Strumenti BCC/eBPF, RL-Scope - overhead elevato o copertura limitata

Vantaggi di Reveal

• Senza Instrumentazione: Completamente basato su telemetria a livello di host
• Copertura Completa di Sottosistemi: CPU, GPU, memoria, rete, archiviazione
• Rilevamento Automatico di Anomalie: Metodo ML non supervisionato
• Attribuzione Hardware: Mappa le anomalie a componenti hardware specifici

Conclusioni e Discussione

Conclusioni Principali

1. Fattibilità dell'Approccio Incentrato sull'Hardware: L'utilizzo esclusivo di segnali hardware può rilevare efficacemente anomalie nei carichi di lavoro ML
2. Efficacia del Rilevamento Non Supervisionato: La combinazione di tre rilevatori può identificare accuratamente molteplici tipi di anomalie
3. Miglioramento Reale delle Prestazioni: Identificazione e correzione con successo di problemi di configurazione, ottenendo miglioramenti significativi delle prestazioni
4. Elevata Portabilità: Il 91% del codice è riutilizzabile tra piattaforme

Limitazioni

1. Configurazione Statica: Attualmente utilizza frequenza di campionamento e dimensione della finestra fisse, incapace di adattarsi dinamicamente al carico di lavoro
2. Rilevamento Passivo: Può solo rilevare anomalie, non risolvere automaticamente i problemi
3. Correzione Manuale: Richiede intervento manuale dell'operatore per correggere i problemi

Direzioni Future

1. Campionamento Adattivo: Regolazione della frequenza di campionamento basata su metodi euristici
2. Correzione Automatica: Ricerca di interventi runtime leggeri, come l'attivazione automatica del ribilanciamento IRQ
3. Estensione dei Rilevatori: Esplorazione di ulteriori metodi di rilevamento di anomalie non supervisionati

Valutazione Approfondita

Punti di Forza

1. Forte Innovazione: Primo metodo di rilevamento di anomalie ML basato su segnali hardware puri, risolvendo il problema dell'osservabilità negli ambienti cloud
2. Esperimenti Completi: Test su più piattaforme hardware con oltre 30 modelli, dataset ricco
3. Alto Valore Pratico: Basso overhead (<2% CPU), elevata portabilità (91% di riutilizzo del codice)
4. Risultati Convincenti: Il miglioramento reale delle prestazioni del 5,97% dimostra l'efficacia del metodo
5. Contributo Open-Source: Fornisce dataset completo e toolkit

Carenze

1. Latenza di Rilevamento: La latenza end-to-end di 2,26 secondi potrebbe non essere adatta per applicazioni in tempo reale
2. Ingegneria delle Caratteristiche: Il processo di selezione delle metriche e estrazione delle caratteristiche è relativamente complesso, richiede competenze specializzate
3. Ambito di Valutazione: Principalmente testato in ambienti accademici, la complessità dell'ambiente di produzione potrebbe presentare nuove sfide
4. Profondità dell'Analisi della Causa Radice: Sebbene possa attribuire ai sottosistemi, l'analisi della causa radice specifica richiede ancora intervento umano

Impatto

1. Contributo Accademico: Fornisce una nuova direzione di ricerca per il monitoraggio delle prestazioni dei sistemi ML
2. Valore Pratico: Fornisce ai fornitori di servizi cloud una soluzione di monitoraggio che non richiede l'accesso all'ambiente dell'utente
3. Riproducibilità: Il codice open-source e i dataset supportano la riproduzione e l'estensione della ricerca

Scenari Applicabili

1. Fornitori di Servizi Cloud: Necessitano di ottimizzazione delle prestazioni senza accesso ai carichi di lavoro degli utenti
2. Centri HPC: Necessitano di monitoraggio e diagnosi dei problemi di prestazione dei carichi di lavoro ML
3. Informatica Perimetrale: Monitoraggio leggero in ambienti con risorse limitate
4. Istituzioni di Ricerca: Analisi e ottimizzazione delle prestazioni dei sistemi ML

Riferimenti Bibliografici

L'articolo cita 77 riferimenti correlati, coprendo:

• Strumenti di analisi delle prestazioni ML: Hotline, RL-Scope, Plumber, ecc.
• Metodi di rilevamento di anomalie: Isolation Forest, PCA, distanza di Mahalanobis, ecc.
• Monitoraggio del sistema: Prometheus, AWS CloudWatch, ecc.
• Framework ML: PyTorch, TensorFlow, ecc.

Valutazione Complessiva: Questo è un articolo di ricerca di alta qualità che propone un metodo innovativo di rilevamento di anomalie incentrato sull'hardware, risolvendo il problema pratico del monitoraggio dei carichi di lavoro ML negli ambienti cloud. La progettazione sperimentale è completa, i risultati sono convincenti e ha un valore significativo sia per il mondo accademico che per l'industria.