GridPilot: Real-Time Grid-Responsive Control for AI Supercomputers

Riepilogo Tecnico: GridPilot – Controllo in Tempo Reale Rispondente alla Rete per Supercomputer AI

Enunciato del Problema
I grandi data center, in particolare quelli che ospitano carichi di lavoro di Intelligenza Artificiale (AI) e Calcolo ad Alte Prestazioni (HPC), stanno crescendo più velocemente delle reti elettriche che li alimentano. Gli Operatori di Sistema di Trasmissione (TSO) in Europa, Nord America e Asia stanno sempre più acquistando servizi di risposta alla frequenza (FR) sub-secondo (ad esempio, la Riserva di Frequenza Rapida Nordica, che richiede una risposta entro 700 ms) per mantenere la stabilità della rete. Sebbene i siti di calcolo multi-megawatt siano identificati come potenziali carichi flessibili, esiste un divario critico: nessun lavoro precedente ha misurato la latenza end-to-end di un controller composito a più livelli su hardware GPU reale rispetto a un budget di attivazione TSO pubblicato. Inoltre, i controller esistenti spesso ignorano l'Efficacia dell'Uso dell'Energia (PUE) istantanea, portando a una discrepanza tra la potenza impegnata a livello di scheda GPU e la potenza effettivamente erogata al contatore dell'impianto, dove avvengono i regolamenti di rete.

Metodologia
Gli autori presentano GridPilot, un controller predittivo a tre livelli potenziato da un bypass "isola di sicurezza", progettato per regolare il consumo energetico delle GPU su tre scale temporali: millisecondi, secondi e ore.

1. Architettura:

   • Livello 1 (Per-GPU, 200 Hz): Un ciclo Proporzionale-Integrale-Derivativo (PID) che traccia gli obiettivi di potenza per GPU tramite la NVIDIA Management Library (NVML). Opera con un tick di 5 ms per corrispondere alle latenze di aggiornamento NVML.
   • Livello 2 (Per-Host, 1 Hz): Un modello Autoregressivo di ordine 4 (AR(4)) che coordina i limiti per GPU all'interno del profilo energetico dell'host, prevedendo l'utilizzo dell'host basandosi sui quattro campioni precedenti.
   • Livello 3 (Per-Cluster, Orario): Un selettore che determina il punto di funzionamento del cluster (utilizzo medio e banda di riserva FR) per ottimizzare un obiettivo composito di qualità della Risposta alla Frequenza e allineamento all'Energia Senza Carbonio (CFE).
   • Isola di Sicurezza: Un programma C in tempo reale (ancorato a un core CPU isolato) che bypassa lo stack software più lento (supervisori Python) quando arriva un trigger di rete. Legge il trigger e scrive direttamente nuovi limiti di potenza sulle GPU tramite NVML.

2. Contabilità Consapevole del PUE:
   Il sistema incorpora un modello PUE a quattro componenti (raffreddamento, pompe, lato aria e vario) nell'obiettivo del Livello 3. Ciò garantisce che il punto di impostazione della potenza lato IT corrisponda all'impegno al contatore dell'impianto, correggendo il "drag del sovraccarico di raffreddamento" che si verifica quando la potenza IT viene ridotta (il che può temporaneamente aumentare il PUE a causa dei minimi del sistema di raffreddamento).

3. Configurazione Sperimentale:
   Gli esperimenti sono stati condotti su un banco di prova EPFL dotato di tre GPU NVIDIA Tesla V100 SXM2 (300 W TDP ciascuna). Lo studio ha utilizzato tre archetipi di carico di lavoro: moltiplicazione di matrici (matmul), inferenza (ResNet-50) e carichi di lavoro impulsivi. Il controller è stato testato contro trigger TSO sintetici e validato su sei reti europee (Svezia, Svizzera, Francia, Italia, Germania, Polonia) utilizzando tracce Marconi100 e dati di intensità carbonica ENTSO-E.

Contributi Chiave

1. Misurazione della Latenza nel Mondo Reale: Il documento fornisce il primo tempo di risposta end-to-end misurato per un controller a più livelli su hardware AI/HPC reale rispetto a un budget TSO pubblicato.
2. Isola di Sicurezza Deterministica: L'implementazione di un bypass C in tempo reale che garantisce tempi di risposta inferiori a 100 ms, superando le latenze non deterministiche (ad esempio, garbage collection, importazioni lazy) dei supervisori standard basati su Python.
3. Correzione PUE lato Impianto: Una strategia di controllo che modella esplicitamente le dinamiche di potenza dell'impianto, garantendo che gli impegni di rete siano soddisfatti al contatore e non solo a livello di scheda GPU.
4. Rilascio Open Source: L'intera pila del controller, la telemetria grezza e gli script di riproducibilità sono stati rilasciati per dimostrare che la domanda di calcolo su scala MW può essere controllabile per progettazione.

Risultati

• Prestazioni di Latenza: Sul banco di prova V100 a tre GPU, il tempo di risposta end-to-end mediano da un trigger di rete al superamento da parte della potenza GPU del 95% del nuovo obiettivo è stato di 97,2 ms (caso peggiore 101,1 ms su 90 prove). Questo è circa 6,9 volte più veloce del prodotto di rete europeo più rigoroso (Nordic FFR, budget di 700 ms).
• Impatto dell'Isola di Sicurezza: Senza il bypass dell'isola di sicurezza, esperimenti identici utilizzando uno stack di supervisori Python hanno mostrato latenze p99 superiori a 250 ms, che avrebbero fallito la pre-qualifica TSO.
• Impatto del PUE: Gli esperimenti su sei reti europee hanno mostrato che la correzione consapevole del PUE ha chiuso il "drag del sovraccarico di raffreddamento" di 2,5–5,8 punti percentuali (pp) al contatore dell'impianto, garantendo che l'impegno del controller corrispondesse alla realtà misurata.
• Accuratezza del Controllo: Il ciclo PID del Livello 1 si è stabilizzato entro ±2% del punto di impostazione in 18–29 ms. Il predittore AR(4) del Livello 2 ha raggiunto un basso Errore Assoluto Medio (MAE) per carichi di lavoro costanti (ad esempio, 4,69 W per l'inferenza), sebbene i carichi di lavoro impulsivi abbiano mostrato una varianza più elevata (19,66 W), assorbita dall'architettura a cascata.

Significato e Affermazioni
Il documento afferma che GridPilot funge da prova di concetto che dimostra come gli impianti AI/HPC su scala MW possano essere progettati come carichi flessibili e rispondenti alla rete. Gli autori affermano che la combinazione di un bypass deterministico dell'isola di sicurezza, livelli di controllo predittivo e correzione PUE lato impianto è sufficiente per soddisfare i budget di attivazione di rete sub-secondo.

Il significato è inquadrato come una validazione ingegneristica:

• Dimostra che lo stack software può garantire un dispacciamento deterministico sotto una reale contesa dei carichi di lavoro.
• Dimostra che ignorare il PUE istantaneo porta a un'erogazione insufficiente al contatore (da 4 a 7 pp), rendendo il controllo consapevole del PUE una necessità per la conformità alla rete.
• Stabilisce che l'architettura "isola di sicurezza" è critica per soddisfare i requisiti di latenza più rigorosi, poiché gli stack software standard sono troppo lenti per la risposta alla frequenza sub-secondo.

Gli autori rimangono modesti riguardo alla scalabilità, notando che le misurazioni attuali sono su un nodo a tre GPU e che la contesa su scala rack e le oscillazioni di potenza H100/H200 (che sono 1,5–2 volte superiori) non sono ancora state pienamente validate a livello di latenza FR. Il lavoro è posizionato come il livello rivolto alla rete dell'emergente HPC PowerStack, destinato a comporsi verticalmente con i gestori di potenza esistenti all'interno del cluster.