Czy LLMy mogą oszczędzać prąd?

Czy LLMy mogą oszczędzać prąd? To pytanie wydaje się na pierwszy rzut oka dziwne, bo przecież powszechnie wiadomo, że AI zużywa dużo energii, jest winne ociepleniu klimatu itd. Zanim jednak zaczniemy powtarzać oczywiste prawdy, warto sięgnąć do źródeł. Bo – podobnie jak było to przy chińskich autobusach – powtarzana prawda może nieco odbiegać od twardych danych źródłowych.

Na początek warto przyjrzeć się pierwszemu popularnemu mitowi, który mówi użycie LLM zużywa wielokrotnie więcej energii, niż zwykłe wyszukiwanie. Twarde dane nie do końca to potwierdzają. Typowe zapytanie do ChatGPT to około 0,3 Wh. Nie kWh, tylko Wh. Na tyle samo Google oceniało pojedyncze zapytanie do wyszukiwarki. Czyli w przypadku prostych zapytań zużywane ilości energii zużywane przy zwykłym wyszukaniu w wyszukiwarce i wykorzystaniu LLM są zbliżone.

Nie żebym zachęcał do używania LLMów w ten sposób, bo jednak nie jest to specjalnie efektywne, ani energetycznie, ani czasowo. Jednak dramatu nie ma[1]. Pewnie efektywniej wykorzystać LLM do przygotowania zestawienia danych. Takiego, do którego potrzeba byłoby kilku wyszukiwań. Owszem, zapytanie będzie „cięższe”, ale unikniemy kilku tradycyjnych zapytań.

No dobrze, ale od to wcale nie jest takie kosztowne energetycznie do LLMy oszczędzają energię długa droga, prawda? Prawda. Wyobraźmy sobie jednak, że chcemy coś zrobić. Powiedzmy, napisać prosty program albo skrypt. Żeby to zrobić, musimy poszukać materiałów, zapoznać się z nimi, wykonać właściwą czynność. Jeśli będzie to pisanie programu wykorzystującego jakieś API, to musimy znaleźć dokumentację tego API, napisać sam program. To wszystko trwa. A że pracujemy na komputerze, który zużywa prąd. Laptop to przynajmniej 10-20W, monitor (24″) kolejne 15-25W. Raczej dolny szacunek, YMMV, można sprawdzić watomierzem.

Jako ludzie działamy raczej wolno, szczególnie w nieznanych obszarach. Wolno czytamy, wolno piszemy. A w tym czasie nasze urządzenia pracują i zużywają prąd. Więc pytanie do LLMa raczej przyspieszy wykonanie. Godzina pracy naszego skromnego laptopa i monitora to równowartość energetyczna od kilkudziesięciu do kilkuset zapytań do LLM.

Przykład z mojego podwórka, to skrypt do backupu obserwowanych na Mastodon. Małe kilka[3] promptów do Gemini, który znalazł i że jest API, i z których endpointów API korzystać, i jakie parametry podawać (a nieco nieoczywiste), i paginację dorobił od kopa. Pół godziny zeszło mi na zabawie, doczytaniu interesujących fragmentów dokumentacji, doszlifowaniu ręcznym. Ręcznie robiłbym z dwie godziny minimum.

Ale przecież są badania na to, że programistom się wydaje, że ich produktywność przy użyciu AI rośnie, a tak naprawdę to ona spada, na przykład to! Rzadko czytam badania, ale jeśli już, to lubię czytać nie tylko tytuł badania i wnioski, ale zerknąć na warunki badań. Bo autorzy często – świadomie lub nie – idą na łatwiznę i mają mocno niereprezentatywną próbkę. W tym konkretnym przypadku jest kilka red flags.

Po pierwsze, mowa o doświadczonych programistach, pracujących na własnym kodzie. Nie uważam się za doświadczonego programistę, ale do głowy by mi nie przyszło korzystanie z LLMa w typowej pracy z własnym kodem. A już na pewno nie jako pierwszy wybór. Czemu? Bo wiem, gdzie co jest, wiem, co chcę dodać, wiem jak to dodać, nie będę musiał czekać na wynik i poprawiać go. Po drugie, sami autorzy tego badania mają tego świadomość i sami piszą, że wyników nie należy uogólniać, a w przypadku mniej doświadczonych programistów LLM prawdopodobnie zwiększy wydajność. Zresztą, o tym, że AI pozwoliło zyskać czas na realizację pomysłów pisze wiele osób w mojej bańce.

Czy twierdzę zatem, że LLMy powodują spadek zużycia energii, globalnie? Nie. Jestem praktycznie pewien, że globalnie powodują wzrost zużycia. Sprzeczność? Nie. Po prostu opłacalność zależy od przypadku, a obecny trend jest taki, żeby do LLMów pchać wszystko, czy jest sens, czy go nie ma. I jest to zarówno trend ze strony producentów, jak i użytkowników.

Odbiegając nieco od tematu, zabawna jest obserwacja, jak używając coraz bardziej energooszczędnych technologii, zużywamy coraz więcej energii[3]. Wynika to z paru czynników. Mamy coraz więcej rzeczy na prąd, które kiedyś były ręczne. Lub ich nie było. Powszechna klimatyzacja. Drzwi otwierane elektrycznie w sklepach. Smart żarówki, rolety okienne, zawory grzewcze, sterowanie elektroniczne praktycznie wszystkim. Szczoteczki elektryczne, czytniki ebooków. Streaming zamiast radia. Wszytko zużywa trochę energii. I może wymagać jakiegoś serwera. Kolejny czynnik to po prostu wzrost ilości ludzi na planecie. Jeszcze pół wieku temu było nas o połowę mniej. A na początku XX w. – zaledwie 20% tego, co teraz.

Jeśli komuś naprawdę zależy na oszczędzaniu energii, zamiast martwić się o LLMy, powinien dbać o fizyczne odłączanie urządzeń z prądu, gdy są nieużywane. Przynajmniej na noc. Na przykład przyciskiem na listwie. Czemu? Bo pojedynczy zasilacz od laptopa przez sam fakt bycia podłączonym do prądu potrafi pobierać 1W. Wyłączony/uśpiony monitor – podobnie. Skąd wiem? Bo mierzyłem.

Inne ciekawe linki w temacie:

https://marmelab.com/blog/2025/03/19/ai-carbon-footprint.html

https://www.nature.com/articles/s41598-024-54271-x

UPDATE I jeszcze jeden link, na który trafiłem dziś, dotyczący tego, jak LLMy (w połączeniu z agentami AI) zabijają CTFy. Niedawno grałem, potwierdzam sytuację – kilkadziesiąt zespołów zrobiło wszystkie zadania. W temacie tego posta, potwierdza to szybkość i skuteczność (także energetyczną) AI.

[1] Tak, mam świadomość, że przytoczone tu dane dla tradycyjnych wyszukiwań są z 2009. W tzw. międzyczasie zużycie prądu przez pojedynczy serwer spadło. Z drugiej strony, ilość danych do przeszukania wzrosła, więc pewnie niewiele się zmieniło. Chętnie poznam współczesne dane.
[2] Pewnie 2-3 były, nie więcej niż 5.
[3] Jak to kiedyś ładnie ujął pewien człowiek, jeszcze nigdy w historii ludzkość jako ogół nie zmniejszała zużycia energii, niezależnie od coraz mniej energochłonnych technologii.

Jasność nocą

Nie wszyscy wiedzą, że istnieje coś takiego jak MÖRKRÄDD, czyli oświetlenie nocne, władane do gniazdka. Nocne z nazwy, bo ma czujnik, który powoduje, że świeci tylko wtedy, kiedy jest ciemno.

Ja nie wiedziałem. A są takie miejsca, gdzie w nocy jest nieco za ciemno. Na przykład korytarz. Oczywiście, można zapalać światło, ale to dość inwazyjne. Poza tym, włącznik nie zawsze jest w dobrym miejscu. A gdyby było choć trochę światła, to może wystarczyć, by przejść, nie wpadając na nic i nie wdeptując w nic. I do tego sprawdzają się świetnie.

W każdym razie kupiłem te lampki ponad rok temu i jestem dość zadowolony. Prądu pobiera niewiele, bo jakieś 0,5W[1]. Czyli dwie sztuki, gdyby działały przez cały miesiąc non-stop, zużyją prądu za jakiś 1 zł. Wygląda estetycznie, świeci ładnie. Nie nagrzewa się. Jest jedna, niewielka wada – brak regulacji, przy jakim natężeniu światła ma się załączać. Gdyby była regulacja, nawet trzypozycyjna, byłoby perfekcyjnie. Ustawiłbym większą czułość, czyli wyłączanie przy niewielkiej ilości światła.

Oczywiście rozwiązań tego typu jest znacznie więcej. Tu wersja lampki z zimniejszym światłem, za to zużywająca tylko 0,2W. Z kolei tu wersja z regulowanym kątem świecenia. Tu chyba jedna z tańszych. Z kolei ta jest i energooszczędna 0,25W, i chyba najładniejsza. Choć ta z Ikei też jest estetyczna.

Okazje do wpisu były dwie, po pierwsze, akurat jest promocja. Po drugie, przypomniałem sobie, że miałem napisać o tym oświetleniu nocnym – sprawdza się. Dla jasności: wpis nie jest sponsorowany, choć do Allegro są linki afiliacyjne.

[1] Według danych producenta, watomierzem nie potraktowałem, zresztą chyba na granicy czułości będzie…

Gosund SP-111 cz. 2

W tej części cyklu wpisów o Gosund SP-111 opiszę moje perypetie związane z wymianą firmware. Zaczęło się od tego, że chciałem uzyskać możliwość sterowania urządzeniem bez dostępu do internetu. O tym, czemu miałem takie wymaganie może następnym razem. W każdym razie urządzenie posiada wsparcie w otwartych firmware, np. obsługiwane jest przez Tasmota.

Wgrywanie Tasmota bez kabli

Istnieją opisy jak flashować Gosund SP-111 rozkręcając gniazdko i podłączając przewody. Choć posiadam sprzęt, wolałem tego uniknać, dlatego ucieszyłem się, znajdując ten opis bezprzewodowej wymiany firmware przy pomocy tuya-convert. Doczytałem gdzieś, że najlepiej nie pozwolić urządzeniu łączyć się z internetem, tylko od razu przystąpić do flashowania. Chodzi o uniknięcie aktualizacji oprogramowania – podobno nowe wersje mają jakieś zabezpieczenia przed aktualizacją przez tuya-convert.

Po krótkiej zabawie najpierw z Orange Pi, następnie Banana Pi doszedłem do tego, że trzeba trochę powalczyć z konfiguracją, zmieniając nazwę urządzenia sieciowego. Karta wbudowana w Orange Pi nie działała, z kolei sam system nie widział mojej karty na USB, stąd ostatecznie przełączenie na Banana Pi. Niestety, mimo trzymania się i opisu, i instrukcji ze strony projektu, nie udało się wgrać oprogramowania przy pomocy tuya-convert. Ani korzystając z głównej gałęzi oprogramowania, ani z wersji developerskiej.

Oryginalne oprogramowanie i API

Stwierdziłem, że pora wypróbować oryginalne oprogramowanie i zobaczyć, czy urządzenie w ogóle jest sprawne. Zainstalowałem aplikację, zarejestrowałem konto, podłączyłem – wszystko działa. Chyba zaktualizowałem oprogramowanie producenta. Albo zrobiło się to samo? Nie pamiętam. Okazało się również, że powinno dać się uzyskać klucz API umożliwiający sterowanie z użyciem oryginalnego oprogramowania. Po szczegóły odsyłam do projektu tuyapi. Jednak gdy zobaczyłem, że mam zakładać kolejne konto, w kolejnym serwisie, zwątpiłem.

Podszedłem jeszcze raz do flashowania przy pomocy tuya-convert i… tym razem udało się od kopa. Nie wiem czy znaczenie miała aktywacja z oryginalnym oprogramowaniem, czy ew. aktualizacja firmware producenta. Po prostu się firmware się sflashował i… cegła. Krótki błysk po włączeniu zasilanie i tyle. Logi też nie nastrajały optymistycznie, ostatnie co było widać to:

smarthack-web.log:[I 211220 22:07:17 web:2239] 200 GET /files/upgrade.bin (10.42.42.12) 4003.81ms

Wgranie oprogramowania przy pomocy konwertera FTDI

Czyli przyszła pora przeprosić się z kabelkami. Skorzystałem z tego opisu i wgrania firmware przy pomocy esptool. W zasadzie uznałbym go za bardzo dobry, jednak przestrzegam przed poleganiem na kolorach kabli ze zdjęć. Zawsze należy czytać opisy pinów i łączyć zgodnie z opisem. Wpis ten jest dobrym przykładem, bo zdjęcie konwertera FTDI pochodzi bowiem prawdopodobnie z innego podłączenia, niż zdjęcie samego Gosund SP-111 z podłączonymi kabelkami. Tak czy inaczej, opis jest dobry, uwagi dotyczące zaostrzenia pinów czy użycia taśmy klejącej jak najbardziej na miejscu. Oczywiście całą operację flashowania i podłączania kabelków wykonujemy na urządzeniu wypiętym z gniazdka 230V.

Flashowanie „po kablu” przebiegło poprawnie i bez niespodzianek, włożyłem Gosund SP-111 do gniazdka, włączyłem zasilanie i… znowu krótki błysk i zupełna ciemność, całkiem jak po flashowaniu bezprzewodowym.

Tym razem jednak coś mnie tknęło, albo przeczytałem w którymś opisie i przeskanowałem dostępne sieci WiFi. I oczywiście, znalazł się tam nowy AP, po podłączeniu którego mogłem skonfigurować urządzenie. Czyli prawdopodobnie podmiana oprogramowania przy pomocy tuya-convert także była skuteczna. To, czego nie wiedziałem, to fakt, że zachowaniem LED steruje się przy pomocy template’u, który wgrywa się samodzielnie, później.

Jednym słowem, nie ma to jak utrudnić sobie życie i wypróbować wiele sposobów. Grunt jednak, że udało się dotrzeć do szczęśliwego finału, czyli mój Gosund SP-111 działa pod kontrolą otwartego firmware w postaci Tasmota.