Karta z limitem 300 W nie pobiera stale 300 W. Inaczej zachowuje się podczas oczekiwania na zapytanie, inaczej przy czytaniu długiego promptu, a jeszcze inaczej podczas generowania odpowiedzi. Dlatego do oceny zużycia energii potrzebny jest pomiar konkretnego zadania, nie tylko specyfikacja GPU.
Drugie ważne rozróżnienie: moc karty nie jest mocą całego serwera. CPU, pamięć, dyski, wentylatory i zasilacze tworzą pozostałą część bilansu.
Nasz pomiar z Qwen3-8B
Podczas dwóch krótkich scenariuszy Qwen3-8B Q4_K_M odczyty mocy karty skupiały się w okolicy 300 W. Przed uruchomieniem modelu zarejestrowaliśmy średnio 14,55 W, a w krótkim oczekiwaniu tuż po jego załadowaniu — 68,55 W.
| Etap | Średnia z odczytów | Zakres odczytów | Liczba próbek |
|---|---|---|---|
| Bez procesu modelu, 10 s | 14,55 W | 14,30–15,15 W | 5 |
| Gotowy model, 10 s bez zapytań tuż po załadowaniu | 68,55 W | 66,60–74,30 W | 5 |
| Wejście 2048 tokenów, 1 zapytanie naraz | 300,04 W | 299,93–300,24 W | 3 |
| Wejście 8192 tokeny, 4 zapytania naraz | 299,97 W | 299,77–300,33 W | 10 |
To odczyty karty w podanych oknach. 68,55 W nie jest ustalonym poborem spoczynkowym — dotyczy dziesięciu sekund zaraz po załadowaniu modelu. Krótkie próbki podczas zapytań pokazują pracę w pobliżu limitu, ale nie wyznaczają energii całego zadania ani miesięcznego zużycia serwera.
Sprzęt i sposób pomiaru
| Element | Konfiguracja pomiaru |
|---|---|
| GPU | RTX PRO 6000 Blackwell Max-Q Workstation Edition, 96 GB VRAM, limit 300 W |
| CPU | AMD EPYC 4565P, 16 rdzeni / 32 wątki |
| RAM systemowy | 96 GB |
| System i sterownik | Rocky Linux 10.2, NVIDIA 595.91.07 |
| Model i silnik | Qwen3-8B Q4_K_M, llama.cpp b11146, KV cache F16, Flash Attention |
Każdy scenariusz miał rozgrzewkę i trzy mierzone rundy; każda odpowiedź zawierała 256 nowych tokenów. Model pracował na GPU, API lokalnie, z czterema slotami po 8704 tokeny i bez cache promptu. Przed scenariuszem czekaliśmy na temperaturę GPU nie wyższą niż 40°C. Limit mocy i sterownik pozostawały bez zmian.
Telemetrię odczytywaliśmy co około dwie sekundy. Do wyników zapytań weszły tylko próbki z ukończonych mierzonych rund, bez rozgrzewki, chłodzenia i przerw. Cache systemu był ciepły po sprawdzeniu sumy pliku modelu. Dokładne ustawienia i granice okien są w JSON, a odczyty podsumowuje CSV. To osobny pomiar zasobów; dodatkowa telemetria ma własny narzut, więc nie zestawiamy jego czasów bezpośrednio z wcześniejszym testem szybkości API.
Co pokazuje nvidia-smi
Odczyt mocy GPU dotyczy całej karty. NVIDIA rozróżnia pomiar chwilowy oraz średnią z określonego okna; dostępność pól zależy od sprzętu. Limit mocy określa granicę sterowania kartą, a nie jej stałe obciążenie. Szczegóły opisuje dokumentacja NVIDIA-SMI.
Przy porównywaniu wyników zapisz nazwę pola, częstotliwość odczytu i granice zadania. Maksimum z próbek co dwie sekundy to najwyższy zarejestrowany odczyt, nie gwarancja uchwycenia każdego krótkiego skoku.
Waty, kilowatogodziny i koszt zadania
Waty opisują moc, a kilowatogodziny — energię zużytą przez pewien czas. Dla średniej mocy z całego badanego okresu:
Energia [kWh] = średnia moc [W] × czas [h] / 1000.
W praktyce przy zmiennym obciążeniu sumuje się energię kolejnych odcinków pomiaru. Dłuższe przerwy między zapytaniami też mają znaczenie, jeśli aplikacja i GPU pozostają uruchomione. Koszt otrzymasz po pomnożeniu energii przez właściwą stawkę.
Aby policzyć zużycie całego serwera, mierz całą maszynę — najlepiej na zasilaniu, ze znanym zakresem odczytu. Z samej telemetrii karty nie wyliczysz poboru CPU ani strat zasilaczy. Również czujnik BMC trzeba najpierw zidentyfikować: może opisywać konkretny zasilacz, wejście lub wyjście, a nie ten sam punkt co licznik energii.
Jak porównywać dwa obciążenia LLM
Zachowaj model, kwantyzację, długość wejścia i odpowiedzi oraz liczbę jednoczesnych zapytań. Następnie sprawdź łącznie:
- ile trwało całe zadanie;
- jaką moc rejestrowała karta;
- ile poprawnych odpowiedzi lub tokenów uzyskano;
- ile czasu serwer czekał między zadaniami.
Niższa moc nie musi oznaczać mniej energii na ukończoną pracę, jeśli zadanie trwa dłużej. Z kolei większa liczba tokenów na sekundę nie przesądza o użyteczności odpowiedzi — jakość modelu pozostaje osobnym kryterium.
Co warto monitorować we własnej aplikacji
Oddziel start modelu, gotowość bez zapytań i obsługę ruchu. Łącz odczyty mocy z czasem pierwszego tokena, czasem całej odpowiedzi i temperaturą. Dzięki temu zobaczysz, czy wzrost obciążenia daje oczekiwaną liczbę odpowiedzi, a nie tylko wyższe zużycie zasobów.
Przy planowaniu stałego API uwzględnij typowy dzień pracy, nie wyłącznie najcięższy prompt. Krótki test nadaje się do rozpoznania zachowania karty; bilans energetyczny usługi wymaga obserwacji jej rzeczywistego ruchu i czasu bezczynności.
Uzupełnieniem są pomiary CPU przy pracy modelu na GPU oraz test czasu odpowiedzi i równoległości.
Sprawdź konfigurację serwera lub opisz planowany model i rytm obciążenia.