Szkolenie AI jest synchroniczne, więc tysiące GPU osiągają szczyty podczas obliczeń i opadają podczas komunikacji. Zsumowane, tworzy to duże, rytmiczne wahania mocy, które mogą wzbudzać 'złe częstotliwości' w sieci. Usługi komunalne zaczynają ograniczać oba aspekty: (1) jak szybko/jak daleko przemieszcza się moc (w dziedzinie czasu), oraz (2) ile rytmu znajduje się w wrażliwym paśmie częstotliwości (w dziedzinie częstotliwości). Dotychczasowe wydarzenia pokazują, że oscylacje o niskiej częstotliwości mogą się propagować i obciążać elektrownie/sieci; w przypadku obciążeń związanych z treningiem AI, funkcja wymuszająca jest większa. Dlatego usługi komunalne ustalają krytyczne częstotliwości i limity wielkości (np. szeroki pas ochronny 0,1–20 Hz w porównaniu do 0,2-3 Hz FFT obciążenia AI), aby wąski rytm jednego miejsca nie dominował w sieci. Potencjalne rozwiązania dla zgodności: Oczekuj kompromisów: zużycie energii (pierwsze dwa) w porównaniu do capex/przestrzeni (ostatnie). -Monitorowanie oprogramowania (dodawanie kontrolowanej pracy "uzupełniającej" w momencie spadku mocy), -Kształtowanie oprogramowania układowego GPU (ograniczenia rampy, utrzymanie minimalnego poziomu mocy) -Magazynowanie na poziomie szafy, aby wchłonąć/dostarczyć wahania. Monitorowanie FFT w czasie rzeczywistym działa jako zabezpieczenie. Dlaczego samo oprogramowanie układowe często nie wystarcza? Na obecnych GPU, MPF osiąga maksymalnie ~90% TDP (maksymalna moc), a minimalne ustawienie krótkiego szczytu (EDP) wynosi nadal ~1,1× TDP = przynajmniej ~20% wahań pozostaje. Ścisłe limity usług komunalnych (np. ~10%) zazwyczaj wymagają magazynowania na poziomie szafy oprócz rozwiązań programowych i układowych (np. oczekuj hybrydowych rozwiązań).