1. Zachowaj komunikat i kontekst, zanim uruchomisz ponownie
Przestań dodawać zadania do kolejki. Zapisz dokładną treść błędu, plik lub pytanie, których dotyczy, liczbę elementów przetwarzanych razem oraz osiągnięty etap. Czy model się ładował, czy obliczenia postępowały, czy wynik był właśnie zapisywany? Trzymaj ustawienia w notatce, a już ukończone wyniki w ich folderze.
Zamrożony ekran lub zamknięta bez wyjaśnienia aplikacja nie wystarczą, by ustalić przyczynę. Odnajdź jej dziennik, jeśli istnieje. Awaria połączenia, nieprawidłowe dane wejściowe i zapełniona pamięć mogą dawać podobne objawy w interfejsie. Jeśli oprogramowanie nic nie precyzuje, napisz „przyczyna nieustalona” i przygotuj minimalny test, zamiast wymyślać diagnozę.
2. Rozróżnij pamięć GPU, pamięć systemową i miejsce na dysku
Pamięć GPU służy elementom obliczeń na karcie. RAM serwera i dysk odpowiadają na inne potrzeby. Pojemności widoczne na kartach GPU BriefGPU nie opisują faktycznie dostępnego RAM-u ani dysku. Sprawdź zasób wskazany w komunikacie oraz informacje o swoim środowisku.
W Pythonie MemoryError oznacza niepowodzenie alokacji pamięci; sama ta nazwa nie oznacza braku VRAM. Kod ENOSPC odpowiada brakowi miejsca na docelowym urządzeniu. Te wskazówki ukierunkowują poszukiwania, ale do zlokalizowania operacji nadal potrzebny jest dziennik aplikacji.
| Obserwacja | Pierwsza kontrola | Czego większy GPU sam nie rozwiąże |
|---|---|---|
| Komunikat CUDA out of memory podczas obliczeń | Wykorzystana pamięć karty, inne zadania i rozmiar grupy | Niekompatybilność oprogramowania lub uszkodzony plik |
| MemoryError podczas wczytywania plików | Pamięć procesu, ilość danych wczytanych do RAM | Wczytanie całego folderu do pamięci systemowej |
| No space left on device podczas eksportu | Przestrzeń i ewentualny limit folderu wyjściowego lub tymczasowego | Pełny dysk lub limit miejsca do przechowywania |
| Aplikacja zamknięta bez czytelnego komunikatu | Log, osiągnięty etap i próba na jednym wejściu | Przyczyna wciąż nieznana |
3. Wróć do jednego wejścia i tylko jednego aktywnego zadania
Najpierw sprawdź zadania, które sam uruchomiłeś. Podgląd, stara sesja lub drugie narzędzie mogą wciąż pracować. Zamknij porządnie zadania, które stały się zbędne, po zachowaniu ich stanu. Nie kończ procesu, którego nie rozpoznajesz, i nie restartuj całego środowiska, żeby zaoszczędzić kilka minut diagnostyki.
Uruchom ponownie sam element, który zawiódł, nie obniżając jego jakości. Jeśli przechodzi osobno, ale zawodzi w grupie, liczba jednoczesnych elementów staje się tropem. Zmniejsz na przykład grupę z czterech do dwóch, a potem do jednej, jeśli to konieczne. Liczba plików w folderze pozostaje taka sama; zmienia się tylko ilość przetwarzana jednocześnie.
Niektóre narzędzia oferują przetwarzanie sekwencyjne, aby ograniczyć szczyty zużycia pamięci. Diffusers dokumentuje między innymi dzielenie dekodowania grupy obrazów. Ta możliwość zależy od używanego pipeline'u: sprawdź jego opcje, zanim włączysz ustawienie znalezione dla innego modelu.
4. Zmniejsz obciążenie, nie tracąc oczekiwanego rezultatu
Jeśli pojedynczy element zawodzi, przyjrzyj się jego wymiarom lub długości. W przypadku obrazu przejście z 2048 × 2048 na 1024 × 1024 dzieli liczbę pikseli przez cztery. Nie gwarantuje to podzielenia całkowitej pamięci przez cztery: model i pozostałe elementy zachowują własne potrzeby. Zmniejszenie jest dopuszczalne tylko wtedy, gdy wynik zachowuje niezbędne szczegóły.
W przypadku asystenta rozróżnij dostarczone dokumenty, pytanie i wygenerowaną odpowiedź. Cache generowania może zużywać więcej pamięci przy długim kontekście; dokładne mechanizmy zależą od modelu. Przetestuj krótsze zapytanie lub pojedyncze żądanie naraz. Nie usuwaj fragmentu zawierającego odpowiedź, a następnie nie uznawaj, że problem został rozwiązany.
Zawsze zachowuj oryginalne dane wejściowe. Nazwij testowany wariant i opisz, co zmienia. Jeśli narzędzie oferuje podział na kafelki lub przenoszenie niektórych elementów do RAM, sprawdź jego dokumentację i skontroluj łączenia, jakość oraz zaobserwowany czas. Opcja oszczędzająca VRAM może przenieść ograniczenie gdzie indziej.
5. Nie myl pamięci zarezerwowanej z pamięcią użyteczną
W PyTorch pamięć zarezerwowana przez alokator i pamięć zajęta przez tensory to dwie różne miary. Wyczyszczenie nieużywanego cache nie zwalnia wciąż aktywnych tensorów. Polecenie czyszczenia nie zamieni więc zbyt dużego obciążenia w obciążenie obsługiwalne.
Jeśli czysty restart aplikacji pomaga, powtórz następnie ten sam mały przypadek i zapisz wynik. Sukces po restarcie sam w sobie nie dowodzi naprawionego wycieku pamięci. Jeśli użycie rośnie przy każdym identycznym przebiegu, zachowaj tę obserwację i skonsultuj się z dokumentacją lub pomocą techniczną oprogramowania, zanim zaczniesz mnożyć restarty.
Przykład: wyizoluj problem w folderze z dwunastoma obrazami
Oto scenariusz ilustracyjny, bez pomiarów sprzętu. Freelancerka przygotowuje dwanaście obrazów, z których dwa mają duże wymiary i drobny tekst. Przetwarzanie w grupach po cztery kończy się niepowodzeniem. Zachowuje komunikat, a następnie próbuje jeden z dużych obrazów osobno, w pierwotnej jakości. Tabela pokazuje, jak interpretować możliwe obserwacje.
W tym scenariuszu wybiera grupy po dwa dopiero po sprawdzeniu dwóch dużych obrazów razem i kilku zwykłych obrazów. Sprawdza tekst i kontury w wyeksportowanych plikach. Nie uogólnia tego wyniku na wszystkie rozmiary obrazów, wszystkie modele ani inne oprogramowanie.
| Przebieg scenariusza | Hipotetyczna obserwacja | Decyzja lokalna |
|---|---|---|
| Cztery obrazy jednocześnie | Błąd pamięci | Zachować błąd i zmniejszyć grupę |
| Jeden duży obraz, te same ustawienia | Pełny i akceptowalny wynik | Docelowa jakość może przejść w tym odosobnionym przypadku |
| Dwa duże obrazy razem | Pełne i akceptowalne wyniki | Przetestować tę grupę na krótkim wycinku |
| Obraz znacznie zmniejszony | Obliczenia zakończone, tekst nieczytelny | Odrzucić to zmniejszenie mimo technicznego sukcesu |
Kiedy inna karta staje się uzasadnionym tropem
Porównaj inną kartę, gdy brak pamięci GPU został zidentyfikowany, niezbędny przypadek sam się nie udaje, a zmniejszenia zgodne z twoją jakością nie wystarczają. Zachowaj oprogramowanie, wersję, parametry i dane wejściowe: taki zapis czyni następną próbę porównywalną. Nie pozwala jednak dokładnie wywnioskować, ile dodatkowych GB wystarczy.
Błąd przy wczytywaniu modelu może też ograniczać sens zmniejszania grupy: znaczna część obciążenia istnieje przed pierwszym wejściem. Opcje precyzji lub kwantyzacji zmieniają warunki wykonania, a czasem wyniki; wymagają osobnej próby. Dodawanie partii nie łączy automatycznie pamięci kilku kart.
Zakończ użyteczną diagnozą
Twoja notatka wyjściowa składa się z pięciu elementów: komunikat i krok, podejrzewany zasób, zachowane dane wejściowe, ustawienie, które działa lub zawodzi, wykonana kontrola jakości. Dopisz to, co pozostaje nieznane. Jeśli żaden mały przypadek nie działa, przerwij powtarzanie pełnej partii i poproś o pomoc, podając te informacje.
Nie usuwaj swoich jedynych oryginałów, aby zwolnić dysk, nie obniżaj kilku parametrów naraz i nie uznawaj częściowego wyniku za sukces. Zarezerwuj czas na zapisanie poprawnych wyników. Diagnoza ma zmniejszyć niepewność; nie musi zamieniać się w niekończącą się sesję regulacji.