Wyjaśnij oczekiwania, zanim poszukasz mocniejszego GPU.

Opisz problem za pomocą wyniku i okna czasowego

Zastąp „GPU nie pracuje” obserwacją, którą można zweryfikować: pierwszy wynik pojawia się późno, etapy mają przerwy albo liczba akceptowanych wyników spada. Podaj zbiór wejściowy, wersję aplikacji, ustawienia i obserwowany okres. Pierwsze uruchomienie może obejmować inne fazy niż już przygotowane wykonanie; nie mieszaj ich bez wyraźnego wskazania.

Podziel przebieg na otwieranie plików, przygotowanie CPU, transfer, obliczenia GPU, zapis, a następnie walidację. Te fazy mogą się nakładać: wykres stanowi hipotezę, którą trzeba skonfrontować ze śladami. Zapisz granice w tej samej strefie czasowej i z wystarczającą dokładnością. Wykres sprzętowy pobrany po przerwie nie pozwala wyjaśnić przerwy, nawet jeśli jego wartość wydaje się nietypowa.

Poprawne odczytywanie procentów i pamięci

W NVIDIA SMI wykorzystanie GPU wskazuje część przedziału próbkowania, w której wykonywało się co najmniej jedno jądro. To nie jest ocena wydajności wszystkich komponentów. Wykorzystanie pamięci opisuje jej aktywność odczytu lub zapisu; nie należy go mylić z ilością zajętej pamięci. Dokumentacja precyzuje również, że niektóre pola mogą być niedostępne w zależności od środowiska.

Zachowaj więc dokładną nazwę metryki i jej jednostkę. Duża ilość pamięci może odpowiadać danym przechowywanym w oczekiwaniu; niska aktywność może wystąpić w normalnej fazie przygotowania. Z kolei wysoka aktywność nie dowodzi, że program wykonuje użyteczną pracę. Trzeba patrzeć na wyniki i postęp aplikacji jednocześnie ze sprzętem.

Zbierz skorelowany i wystarczająco krótki odczyt

Wybierz reprezentatywną sekwencję i ogranicz zbieranie danych do tej sekwencji. Zanotuj godziny, identyfikator GPU, aktywność, zajętą pamięć i fazy aplikacji. Równolegle użyj narzędzi dostępnych w Twoim systemie, aby obserwować proces CPU, jego oczekiwania, odczyty i zapisy. Średnia ze wszystkich rdzeni może zamaskować pojedynczy przeciążony wątek; przyjrzyj się także zaangażowanym procesom.

Poniższe polecenie odczytu jest proponowane dla autoryzowanego celu NVIDIA, który ma już NVIDIA SMI. Nie zostało ono wykonane na potrzeby tego przewodnika. Zachowuje jednostki w CSV i wyświetla obserwację co sekundę aż do przerwania. Sprawdź pola obsługiwane przez Twoją wersję i zatrzymaj zbieranie danych na końcu scenariusza. Pole N/A pozostaje nieznane: nie zamieniaj go na zero.

Minimalny dziennik łączy identyfikator zadania, godzinę ze strefą czasową, bieżącą fazę, identyfikowalne wejście lub partię, postęp oraz ewentualny błąd. Nie może zawierać ani sekretów, ani treści biznesowych niepotrzebnych do diagnozy. Jeśli brakuje telemetrii, najpierw sprawdź jej mechanizm zbierania i postęp aplikacji: pusty wykres nie dowodzi zatrzymania procesu. Oznacz okres bez obserwacji, zamiast odtwarzać go z pamięci.

nvidia-smi --version
nvidia-smi --query-gpu=timestamp,uuid,utilization.gpu,memory.used,memory.total --format=csv --loop=1

Odróżnić trop od wniosku

Jeśli aktywność GPU spada, gdy aplikacja czeka na swoje dane wejściowe, przeanalizuj ścieżkę plików. Jeśli spada podczas długiego przygotowania CPU, przeanalizuj tę fazę i jej rzeczywisty paralelizm. Jeśli urządzenia czekają na pozostałych uczestników zadania rozproszonego, sprawdź równowagę obciążeń i komunikację. Kilka objawów może występować jednocześnie; ich korelacja nie jest jeszcze dowodem związku przyczynowego.

Zapisz krótką hipotezę i modyfikację, która pozwoli ją rozstrzygnąć. Na przykład porównanie tych samych, już przygotowanych danych wejściowych z ich zwykłym przygotowaniem może wyizolować jeden etap, pod warunkiem że wyniki pozostaną identyczne. Nie zmieniaj jednocześnie rozmiaru partii, precyzji, liczby procesów i lokalizacji plików: poprawa stałaby się trudna do przypisania.

Przykład fikcyjny: analiza pętli stu sekund

Fikcyjny zespół „Przegląd makiet” opisuje pętlę bez nakładania się: sześćdziesiąt sekund przygotowania CPU, dwadzieścia obliczeń GPU, a następnie dwadzieścia eksportu. Suma wynosi 100 sekund, a udział czasowy przypisany do obliczeń GPU to 20/100, czyli 20%. To obliczenie dydaktyczne nie przewiduje procentu żadnego narzędzia próbkowania i nie odpowiada żadnemu pomiarowi GPU z katalogu.

Załóżmy, że przygotowanie można skrócić do trzydziestu sekund, nie zmieniając obliczeń ani wyników. Pętla wynosiłaby wtedy 30 + 20 + 20 = 70 sekund: trzydzieści sekund mniej, przy udziale GPU wynoszącym 20/70, czyli około 28,6%. Odwrotnie, hipotetyczne podzielenie samych obliczeń GPU przez dwa dałoby 60 + 10 + 20 = 90 sekund. Scenariusz wyjaśnia, dlaczego zajęcie się najdłuższym oczekiwaniem może ważyć więcej niż zmiana karty.

Pogłębić analizę fazy za pomocą profilera

Jeśli ogólna obserwacja wskazuje wolny obszar, ale go nie wyjaśnia, użyj profilera dostosowanego do aplikacji w krótkim oknie. PyTorch Profiler może zbierać zdarzenia CPU i CUDA oraz organizować okna zbierania. Dokumentacja sygnalizuje narzut, gdy włączone jest rejestrowanie kształtów lub stosów. Szczegółowy ślad jest więc narzędziem diagnostycznym; jego całkowitego czasu nie należy bez zastrzeżeń przedstawiać jako normalnego czasu programu.

Nadawaj fazom nazwy wystarczająco opisowe, aby powiązać operację techniczną z Twoją pracą: przygotowanie grupy plików, transfer, krok aplikacji lub publikacja wyniku. Zacznij od poziomu szczegółowości potrzebnego do weryfikacji hipotezy. Po zmianie przeprowadź ponownie porównywalną obserwację, a następnie uruchomienie bez ciężkiej instrumentacji. Ta druga kontrola pozwala sprawdzić, czy korzyść występuje również w zwykłych warunkach.

Unikać poprawek, które maskują problem

Zwiększenie współbieżności może wypełnić GPU, jednocześnie przeciążając dysk, pamięć hosta lub wyjścia. Zwiększenie rozmiaru partii może zmienić opóźnienie i wymaganą pamięć. Zmniejszenie precyzji może zmienić wynik. Te decyzje nie są zabronione, ale należy je oceniać według tego samego celu biznesowego, wraz z ich efektami ubocznymi, a nie wybierać tylko dlatego, że wyświetlany procent rośnie.

Nie resetuj urządzenia ani nie zmieniaj jego parametrów sprzętowych, aby diagnozować zwykły spadek aktywności. Zacznij od odczytu, a następnie zleć przeanalizowanie jawnych błędów upoważnionej osobie. Unikaj także publikowania surowych śladów zawierających prywatne ścieżki, poufne parametry lub dane wejściowe. Przygotuj fragment przydatny do diagnostyki, a pełny dowód zachowaj w autoryzowanym zakresie zespołu.

Zamknąć diagnostykę dowodem przydatnym do decyzji

Końcowy dokument powinien wskazywać objaw, przyjętą hipotezę, wypróbowaną zmianę, jej warunki i zaobserwowany wynik. Zachowaj co najmniej jedno porównanie przed/po na tym samym zbiorze danych wejściowych, tej samej jakości i tej samej definicji zakończenia. Jeśli wynik nie jest rozstrzygający, opisz, co zostało wykluczone i jaka obserwacja jest potrzebna w następnej kolejności. Udokumentowany odrzucony trop pozwala uniknąć losowego zaczynania od nowa przez inną osobę.

Niska, normalna aktywność nie zawsze wymaga poprawki. Jeśli zadanie mieści się w terminie, jakości i budżecie, zmniejszenie złożoności może być lepsze niż krucha optymalizacja. Jeśli rozważana jest nowa konfiguracja, przekaż wykazane ograniczenia do protokołu odbioru. Żaden pojedynczy pomiar nie klasyfikuje katalogu i żadna wartość z tego przykładu nie stanowi obiecanej wydajności.