Architektura chmurowa świadoma energii w erze AI

Architektura świadoma energii nie jest osobnym programem ESG ani wyborem regionu oznaczonego zielonym symbolem. To dyscyplina projektowa, w której zespół mierzy, ile energii i emisji wymaga wykonanie określonej pracy, a następnie zmienia kod, model, harmonogram i infrastrukturę bez naruszania SLO, bezpieczeństwa oraz rezydencji danych.

Decyzja powinna zaczynać się od jednostki użytecznego wyniku: obsłużonego zamówienia, przetworzonego dokumentu, ukończonej inferencji albo przebudowanego artefaktu. Bez takiej jednostki spadek zużycia może wynikać po prostu z mniejszego ruchu, a poprawa PUE centrum danych może nie zmienić nieefektywności aplikacji.

Energia jest ograniczeniem pojemności, nie tylko kosztem

Raport IEA Energy and AI opisuje rosnące powiązanie infrastruktury cyfrowej z dostępnością wytwarzania i sieci. Dla architekta oznacza to, że plan pojemności obliczeniowej nie może zakładać nieograniczonego przydziału mocy. Lokalizacja, czas uruchomienia, chłodzenie i wykorzystanie akceleratorów wpływają zarówno na koszt, jak i możliwość dostarczenia usługi.

W praktyce potrzebny jest wspólny model dla produktu, platformy, FinOps i zespołu odpowiedzialnego za energię. Powinien on łączyć prognozę zapytań lub zadań, profil używanego sprzętu, czas pracy, wymagany zapas, źródła energii i ograniczenia regionu. Zakup lub rezerwacja większej liczby GPU przed zrozumieniem profilu obciążenia może utrwalić niskie wykorzystanie na lata.

Warto rozdzielić obciążenia online o twardym SLO od batchy i zadań eksperymentalnych. Te pierwsze potrzebują dostępnego zapasu i stabilnego opóźnienia. Te drugie często można kolejkować, łączyć, przesuwać w czasie albo zatrzymywać, gdy energia jest droższa lub bardziej emisyjna.

Ustal granicę pomiaru i jednostkę funkcjonalną

ISO/IEC 21031:2024 opisuje Software Carbon Intensity jako metodę obliczania emisji przypadającej na jednostkę funkcjonalną systemu. Podejście obejmuje energię zużytą przez oprogramowanie, intensywność emisyjną energii oraz przypisaną część emisji wbudowanych sprzętu. Nie wystarczy więc odczytać rachunku chmurowego albo deklaracji dostawcy.

Granica powinna odpowiadać decyzji. Dla usługi inferencyjnej może obejmować gateway, preprocessing, model serving, cache, storage i transfer danych. Dla pipeline analitycznego — orkiestrację, wykonanie, przechowywanie wyników i powtórzenia po błędach. Trzeba jawnie wskazać, czego pomiar nie obejmuje, oraz zachować wersję modelu, sprzętu i konfiguracji.

Pomiary należy normalizować względem użytecznej pracy. Energia na godzinę klastra pomaga w eksploatacji, ale nie pozwala porównać dwóch rozwiązań obsługujących różną liczbę poprawnych rezultatów. Dla AI warto zestawić energię z jakością odpowiedzi, przepustowością i latencją; agresywna optymalizacja, która zwiększa liczbę ponowień lub błędów, może pogorszyć całkowity wynik.

Najpierw ogranicz pracę, której system nie musi wykonywać

Najtańsza energetycznie operacja to ta, której nie uruchomiono. Architekt powinien sprawdzić retencję danych, częstotliwość recompute, duplikujące się pipeline, niepotrzebne środowiska i stale działające zasoby eksperymentalne. Cache może zastąpić powtarzalną inferencję, a zdarzenie zmianowe — cykliczny pełny skan.

W usługach AI kolejność decyzji ma znaczenie. Najpierw należy dobrać najmniejszy model spełniający wymagania jakościowe, potem ocenić kwantyzację, batching, długość kontekstu, cache i routing do kilku klas modeli. Dopiero po zrozumieniu tych parametrów można wiarygodnie dobrać akcelerator i strategię autoskalowania.

Zespół powinien mierzyć wykorzystanie przy rzeczywistym profilu ruchu, nie tylko średnią dobową. GPU może wyglądać na zajęte, ale znaczną część czasu spędzać na oczekiwaniu na dane albo komunikację. Przydatne są rozkłady wykorzystania, długość kolejki, czas inicjalizacji, liczba pustych okresów i energia na poprawnie zakończoną jednostkę pracy.

Przesuwaj workload tylko w granicach kontraktu usługi

Carbon-aware scheduling ma sens dla obciążeń tolerujących opóźnienie i zmianę lokalizacji. Każdy workload powinien otrzymać klasę elastyczności: dopuszczalne okno wykonania, możliwe regiony, minimalna pojemność, ograniczenia danych i maksymalny czas oczekiwania. Scheduler może wtedy wybierać moment lub miejsce wykonania na podstawie uzgodnionych danych, zamiast podejmować arbitralną decyzję.

Nie wolno poświęcać niezawodności ani rezydencji danych dla lepszego wskaźnika. Prognoza intensywności emisyjnej jest estymacją, a przeniesienie dużego datasetu także zużywa zasoby. Potrzebna jest reguła anulowania: jeśli zadanie zbliża się do terminu albo brak regionu zgodnego z polityką, system uruchamia je w podstawowej lokalizacji.

Rozliczenie powinno pokazać także rebound effect. Tańsze i bardziej efektywne wykonanie może zwiększyć liczbę uruchomień. Dlatego zespół mierzy nie tylko poprawę pojedynczego zadania, lecz również całkowite zużycie i zmianę wolumenu w okresie.

Nie myl PUE z efektywnością aplikacji

Rozporządzenie delegowane UE 2024/1364 definiuje dla raportujących centrów danych między innymi PUE, WUE, Energy Reuse Factor i Renewable Energy Factor. Wskaźniki te opisują ważne cechy obiektu, ale odpowiadają na inne pytania niż efektywność workloadu.

PUE pokazuje relację całkowitego zużycia energii centrum danych do energii urządzeń IT. Nie rozstrzyga, czy serwery wykonują użyteczną pracę. WUE mierzy wykorzystanie wody, ERF ponowne użycie energii, a REF udział energii odnawialnej. Dobra decyzja architektoniczna powinna widzieć kilka wymiarów jednocześnie i nie redukować ich do jednego syntetycznego wyniku.

Dashboard zespołu aplikacyjnego może łączyć jednostkę funkcjonalną, koszt, energię, szacowane emisje, jakość i SLO. Dane obiektu lub regionu pozostają kontekstem. Gdy dostawca nie udostępnia wystarczającej granularności, trzeba oznaczyć estymację i zakres niepewności, a nie przedstawiać jej jako pomiar bezpośredni.

Podejmuj decyzje przez kontrolowane porównania

Program warto zacząć od jednego kosztownego workloadu, dla którego istnieje właściciel i powtarzalny test. Należy zamrozić zestaw danych lub profil ruchu, zapisać baseline jakości, latencji, kosztu i energii, a następnie zmieniać jeden parametr naraz. Wynik bez regresji SLO można utrwalić jako domyślną konfigurację platformy.

Do stałego przeglądu nadają się: energia i koszt na jednostkę funkcjonalną, wykorzystanie akceleratorów, udział pracy wykonanej w elastycznych oknach, liczba odroczonych zadań niespełniających terminu, całkowite zużycie w okresie oraz jakość danych pomiarowych. Każdy wskaźnik powinien mieć właściciela i opisaną reakcję na odchylenie.

Architektura świadoma energii staje się użyteczna wtedy, gdy prowadzi do decyzji możliwej do odtworzenia: zmiany modelu, harmonogramu, kodu, retencji albo klasy sprzętu. Sama etykieta „sustainable cloud” nie dostarcza takiego mechanizmu.

Źródła

• Energy and AI — International Energy Agency, 10 kwietnia 2025.
• ISO/IEC 21031:2024 — Information technology — Software Carbon Intensity specification — ISO/IEC, 22 marca 2024.
• Rozporządzenie delegowane Komisji (UE) 2024/1364 dotyczące systemu oceny centrów danych — Komisja Europejska, 14 marca 2024, publikacja 17 maja 2024.