Jak uczciwie rozliczać energię GPU, gdy wiele zapytań do LLM idzie jednocześnie?
Serwowanie dużych modeli językowych w trybie wsadowym komplikuje rozliczanie zużycia energii - nie wiadomo, ile prądu pochłonęło konkretne zapytanie. Autorzy pracy proponują framework JouleShare, który mierzy to znacznie dokładniej niż stosowana dziś metoda proporcjonalna do liczby tokenów.

👁 150 przeczytań
Kiedy model językowy obsługuje wiele zapytań naraz (tzw. batching), GPU pobiera pewną łączną ilość energii. Problem polega na tym, że telemetria karty graficznej zwraca tylko wartość zagregowaną - jeden pomiar dla całej partii, bez rozbicia na poszczególne zapytania. Tymczasem raportowanie zrównoważonego rozwoju, obciążanie kosztami konkretnych klientów czy analiza obciążeń wymagają, żeby wiedzieć, ile energii zużyło każde zapytanie z osobna.
Jak to się liczy dziś i dlaczego to błąd
Dotychczasowe benchmarki energetyczne dla modeli raportują zużycie na poziomie modelu, fazy lub tokenu. W praktyce najczęściej stosuje się atrybucję proporcjonalną do liczby tokenów - im dłuższe zapytanie, tym większy udział w energii. Autorzy pracy pokazują, że to podejście jest poważnie niedokładne. Różnica między atrybucją proporcjonalną do tokenów a wartością wyznaczoną metodą Shapleya wynosi średnio 0,440 znormalizowanego L1 przy statycznym batchingu i 0,458 przy ciągłym batchingu. Ten błąd utrzymuje się na trzech różnych kartach graficznych klasy data-center, więc nie jest kwestią specyfiki konkretnego sprzętu.
Metoda Shapleya to pojęcie z teorii gier, które pozwala sprawiedliwie podzielić wspólny efekt między uczestników - w tym przypadku podzielić energię zużytą przez GPU między zapytania, które były przetwarzane razem. Autorzy piszą, że wcześniejsze prace z obszaru rozliczania emisji CO2 motywowały użycie tej metody konceptualnie, ale nikt nie dostarczył zmierzonej podstawy prawdy dla poszczególnych zapytań.
Co proponują autorzy: JouleShare i JCalib
Zaproponowany framework JouleShare składa się z dwóch elementów. Pierwszym jest harness offline - narzędzie, które ustala wspomnianą podstawę prawdy. Działa to tak: podzbiory zapytań są odtwarzane pod vLLM zgodnie z odtwarzalnym protokołem, integrując telemetrię mocy GPU i obliczając dokładne wartości energii Shapleya dla każdego zapytania. To jest kosztowne obliczeniowo i nie nadaje się do użytku w czasie rzeczywistym.
Dlatego drugi element to lekki model kalibracyjny JCalib, który uczy się przewidywać udziały Shapleya na podstawie tanich cech zapytania - takich, które są dostępne podczas serwowania. JCalib sprowadza błąd atrybucji do 0,116 przy statycznym batchingu i do 0,177 przy ciągłym batchingu. Co ważne, jest to wynik lepszy nawet od linii bazowej opartej na samodzielnym pomiarze każdego zapytania z osobna - a ta linia bazowa i tak nie jest dostępna w warunkach produkcyjnych, bo wymagałaby izolowanego uruchamiania każdego zapytania. JCalib jednocześnie zachowuje dokładność pomiaru energii dla całej partii.
Weryfikacja i zakres eksperymentów
Nie przepłacaj za te subskrypcje
Prowadzę sklep z rocznymi dostępami do narzędzi AI - te same konta, o których piszę wyżej, tylko taniej niż w cenniku producenta.
Eksperymenty objęły 16 kombinacji modeli i obciążeń. Autorzy sprawdzili też wariant z próbkowanym Shapleym, który rozszerza zmierzony punkt odniesienia na większe grupy zapytań - tam błąd proporcjonalny do tokenów utrzymuje się, a pojedyncza kalibracja offline pozostaje najdokładniejszą regułą dającą się wdrożyć w praktyce. Praca liczy 12 stron i zawiera 4 rysunki. Nie ma w niej informacji o udostępnieniu kodu ani zbiorów danych.
Google · Twoje źródłaPromptowy wyżej w Twoim Google - jednym kliknięciemDodaj do preferowanych źródeł →Co z tego wynika
To, co mnie tu interesuje, to nie tyle samo narzędzie, co fakt, że autorzy zmierzyli, jak duży jest błąd powszechnie stosowanej metody tokenowej - i jest on naprawdę duży. Jeśli firmy raportują ślad węglowy swoich usług AI albo obciążają klientów kosztami energii proporcjonalnie do tokenów, to robią to ze średnim błędem rzędu 0,44-0,46 w znormalizowanej mierze L1. JouleShare redukuje ten błąd czterokrotnie. Z praktycznego punktu widzenia praca jest interesująca dla operatorów dużych klastrów GPU, ale też dla każdego, kto bierze poważnie kwestię raportowania emisji w kontekście AI - bo pokazuje, że dotychczasowe dane mogły być istotnie przekłamane.
Źródło: arXiv cs.AI: Request-Level Energy Attribution for Batched LLM Serving (dokument z 2026-08-04). To omówienie powstało na podstawie pełnego tekstu dokumentu, nie relacji innych mediów.
Cały tydzień w AI, w jednym mailu
Wybrane premiery, narzędzia i analizy. Raz w tygodniu, prosto do skrzynki.
Zapisz się za darmo →


