La formation de l'IA est synchrone, donc des milliers de GPU connaissent des pics pendant le calcul et des baisses pendant la communication. Agrégés, cela crée de grandes variations de puissance rythmiques qui peuvent exciter des 'mauvaises fréquences' du réseau. Les services publics commencent à limiter les deux : (1) la vitesse et la distance de déplacement de l'énergie (domaine temporel), et (2) la quantité de battement dans une bande de fréquence sensible (domaine de fréquence). Des événements passés montrent que les oscillations à basse fréquence peuvent se propager et stresser les centrales/réseaux ; avec les charges d'entraînement de l'IA, la fonction de forçage est plus importante. Les services publics établissent donc des limites critiques de fréquence et de magnitude (par exemple, une large bande de protection de 0,1 à 20 Hz contre un FFT de charge de travail de l'IA de 0,2 à 3 Hz) afin qu'un battement étroit d'un site ne puisse pas dominer le réseau. Solutions potentielles pour la conformité : Attendez-vous à des compromis : consommation d'énergie (les deux premiers) contre capex/espace (les derniers). -Lissage logiciel (ajouter un travail de "remplissage" contrôlé lorsque la puissance diminuerait), -Formage du firmware GPU (limites de montée, maintenir un plancher de puissance minimum) -Stockage au niveau des racks pour absorber/fournir les fluctuations. La surveillance FFT en temps réel agit comme un filet de sécurité. Pourquoi le firmware seul n'est souvent pas suffisant ? Sur les GPU actuels, le MPF atteint environ 90 % du TDP (puissance maximale) et le réglage de court pic minimum (EDP) est encore d'environ 1,1× TDP = au moins environ 20 % de fluctuation reste. Des limites strictes des services publics (par exemple, environ 10 %) nécessitent généralement un stockage au niveau des racks en plus des solutions de firmware et de logiciel (par exemple, attendez-vous à des solutions hybrides).