L'addestramento dell'AI è sincrono, quindi migliaia di GPU aumentano durante il calcolo e diminuiscono durante la comunicazione. Aggregato, ciò crea grandi oscillazioni di potenza ritmiche che possono eccitare le 'cattive frequenze' della rete. Le utility stanno iniziando a limitare entrambi: (1) quanto velocemente/quanto lontano si muove l'energia (dominio del tempo) e (2) quanto battito si trova in una banda di frequenza sensibile (dominio della frequenza). Eventi passati mostrano che le oscillazioni a bassa frequenza possono propagarsi e stressare impianti/reti; con i carichi di addestramento dell'AI, la funzione di forzamento è più grande. Pertanto, le utility impostano limiti critici di frequenza + magnitudo (ad esempio, una banda di guardia ampia di 0,1–20 Hz rispetto a 0,2-3 Hz FFT del carico di lavoro dell'AI) in modo che il battito stretto di un sito non possa dominare la rete. Possibili soluzioni per la conformità: Aspettati compromessi: consumo energetico (primi due) vs. capex/spazio (ultimi). -Smoothing software (aggiungere lavoro "riempitivo" controllato quando l'energia diminuirebbe), -Formattazione del firmware GPU (limiti di aumento, mantenere un pavimento di potenza minimo) -Storage a livello di rack per assorbire/fornire le oscillazioni. Il monitoraggio FFT in tempo reale funge da supporto. Perché il firmware da solo spesso non è sufficiente? Sulle GPU attuali, il MPF raggiunge circa il 90% del TDP (massima potenza) e l'impostazione minima per picchi brevi (EDP) è ancora circa 1,1× TDP = almeno circa il 20% di oscillazione rimane. Limiti rigidi delle utility (ad esempio, circa il 10%) richiedono tipicamente storage a livello di rack oltre a soluzioni di firmware e software (ad esempio, aspettati soluzioni ibride).