5 wskazówek dotyczących treningu z wieloma GPU z Kerasem

• 21 stycznia 2018 r.
• Wasilis Wryniotis
• . 1 komentarz

Deep Learning (ulubione hasło końca 2010 roku wraz z blockchain / bitcoin i Data Science / Machine Learning) umożliwiło nam robienie naprawdę fajnych rzeczy w ciągu ostatnich kilku lat. Poza postępem w algorytmach (które wprawdzie opierają się na pomysłach znanych już od lat 1990. ubiegłego wieku, zwanych „erą Data Mining”), główne przyczyny ich sukcesu można przypisać dostępności dużych, bezpłatnych zbiorów danych, wprowadzeniu bibliotek open source i wykorzystanie procesorów graficznych. W tym wpisie na blogu skupię się na dwóch ostatnich i podzielę się z wami kilkoma wskazówkami, których nauczyłem się na własnej skórze.

Dlaczego TensorFlow i Keras?

TensorFlow to bardzo popularna biblioteka Deep Learning opracowana przez Google, która umożliwia szybkie prototypowanie złożonych sieci. Zawiera wiele interesujących funkcji, takich jak automatyczne różnicowanie (co oszczędza szacowanie / kodowanie gradientów funkcji kosztów) i obsługę GPU (co pozwala łatwo uzyskać 200-krotną poprawę szybkości przy użyciu przyzwoitego sprzętu). Ponadto oferuje interfejs Python, co oznacza, że ​​można szybko prototypować bez konieczności pisania kodu w C lub CUDA. Wprawdzie istnieje wiele innych frameworków, których można użyć zamiast TensorFlow, takich jak Torch, MXNet, Theano, Caffe, Deeplearning4j, CNTK itp., Ale wszystko sprowadza się do twojego przypadku użycia i osobistych preferencji.

Ale dlaczego Keras? Dla mnie używanie bezpośrednio TF jest jak uczenie maszynowe z Numpy. Tak, jest to wykonalne i od czasu do czasu musisz to zrobić (szczególnie jeśli piszesz własne warstwy / funkcje strat), ale czy naprawdę chcesz napisać kod, który opisuje złożone sieci jako serię operacji wektorowych (tak, wiem w TF są metody wyższego poziomu, ale nie są one tak fajne jak Keras)? A co jeśli chcesz przenieść się do innej biblioteki? Cóż, wtedy prawdopodobnie musiałbyś przepisać kod, co jest do bani. Ta ta taaa, Keras na ratunek! Keras umożliwia opisywanie sieci przy użyciu koncepcji wysokiego poziomu i pisanie kodu niezależnego od zaplecza, co oznacza, że ​​można uruchamiać sieci w różnych bibliotekach głębokiego uczenia. Niewiele rzeczy, które kocham w Keras, to to, że jest dobrze napisany, ma architekturę zorientowaną obiektowo, jest łatwy do wniesienia i ma przyjazną społeczność. Jeśli Ci się spodoba, podziękuj François Cholleta za jej rozwijanie i udostępnianie.

Wskazówki i problemy dotyczące szkolenia z użyciem wielu procesorów graficznych

Bez zbędnych ceregieli przejdźmy do kilku wskazówek, jak najlepiej wykorzystać trening GPU w Keras i kilka problemów, o których należy pamiętać:

1. Szkolenie z użyciem wielu GPU nie jest automatyczne

Trening modeli na GPU przy użyciu Keras i Tensorflow przebiega bezproblemowo. Jeśli masz kartę NVIDIA i zainstalowałeś CUDA, biblioteki automatycznie wykryją ją i wykorzystają do szkolenia. Ale fajnie! Ale co, jeśli jesteś zepsutym bachorem i masz wiele GPU? Cóż, niestety będziesz musiał trochę popracować, aby osiągnąć szkolenie z obsługą wielu GPU.

Istnieje wiele sposobów zrównoleglenia sieci w zależności od tego, co chcesz osiągnąć, ale główne dwa podejścia to modelowanie i równoległość danych. Pierwsza może ci pomóc, jeśli twój model jest zbyt skomplikowana, aby zmieścić się w jednym GPU, a druga pomaga, gdy chcesz przyspieszyć wykonanie. Zazwyczaj, gdy ludzie mówią o szkoleniu z użyciem wielu procesorów graficznych, mają na myśli to drugie. Kiedyś było to trudniejsze do osiągnięcia, ale na szczęście Keras niedawno dodał metodę użytkową o nazwie mutli_gpu_model co ułatwia równoległe szkolenie / przewidywanie (obecnie dostępne tylko z zapleczem TF). Główną ideą jest to, że przekazujesz model przez tę metodę i jest on kopiowany na różne GPU. Oryginalne dane wejściowe są dzielone na porcje, które są przekazywane do różnych GPU, a następnie są agregowane jako pojedyncze wyjście. Metodę tę można wykorzystać do uzyskania równoległego treningu i prognozowania, niemniej jednak należy pamiętać, że w przypadku treningu nie jest ona skalowana liniowo wraz z ilością GPU ze względu na wymaganą synchronizację.

2. Zwróć uwagę na wielkość partii

Kiedy wykonujesz trening z wieloma GPU, zwróć uwagę na rozmiar wsadu, ponieważ ma on wieloraki wpływ na szybkość / pamięć, konwergencję modelu, a jeśli nie będziesz ostrożny, możesz uszkodzić wagę modelu!

Prędkość / pamięć: Oczywiście im większa partia, tym szybsze szkolenie / przewidywanie. Dzieje się tak, ponieważ wprowadzanie i pobieranie danych z GPU wiąże się z dodatkowymi kosztami, więc małe partie mają większy narzut. Z drugiej strony, im większa partia, tym więcej pamięci potrzebujesz w GPU. Szczególnie podczas uczenia dane wejściowe każdej warstwy są przechowywane w pamięci, ponieważ są wymagane na etapie propagacji wstecznej, więc zbyt duże zwiększenie rozmiaru wsadu może prowadzić do błędów braku pamięci.

Konwergencja: Jeśli używasz stochastycznego gradientu przyzwoitego (SGD) lub niektórych jego wariantów do trenowania modelu, powinieneś pamiętać, że rozmiar wsadu może wpływać na zdolność sieci do zbieżności i generalizacji. Typowe wielkości partii w wielu problemach z widzeniem komputerowym mieszczą się w zakresie od 32 do 512 przykładów. Tak jak Keskar i in ujął to następująco: „W praktyce zaobserwowano, że przy stosowaniu większej partii (niż 512) następuje degradacja jakości modelu, mierzona jego zdolnością do generalizacji”. Należy zauważyć, że inne różne optymalizatory mają różne właściwości, a wyspecjalizowane techniki optymalizacji rozproszonej mogą pomóc w rozwiązaniu problemu. Jeśli interesują Cię szczegóły matematyczne, polecam przeczytanie pracy Joeri Hermansa „Skalowalne uczenie głębokie i równoległe zejście gradientowe".

Uszkodzenie wagi: To paskudny szczegół techniczny, który może mieć katastrofalne skutki. Podczas uczenia wielu GPU ważne jest, aby wszystkie GPU były zasilane danymi. Może się zdarzyć, że ostatnia porcja twojej epoki zawiera mniej danych niż zdefiniowano (ponieważ rozmiaru twojego zbioru danych nie można dokładnie podzielić przez rozmiar twojej partii). Może to spowodować, że niektóre procesory graficzne nie będą otrzymywać żadnych danych podczas ostatniego kroku. Niestety niektóre warstwy Keras, w szczególności warstwa normalizacji wsadowej, nie radzą sobie z tym, co prowadzi do pojawiania się wartości nan w wagach (średnia bieżąca i wariancja w warstwie BN). Aby było jeszcze bardziej nieprzyjemnie, nie będzie się obserwować problemu podczas uczenia (podczas gdy faza uczenia to 1), ponieważ określona warstwa używa średniej / wariancji wsadu w oszacowaniach. Niemniej jednak podczas prognozowania (faza uczenia się ustawiona na 0) używana jest bieżąca średnia / wariancja, która w naszym przypadku może stać się nan, prowadząc do słabych wyników. Zrób sobie więc przysługę i zawsze upewnij się, że rozmiar partii jest stały, gdy wykonujesz szkolenie z użyciem wielu GPU. Dwa proste sposoby na osiągnięcie tego to odrzucenie partii, które nie pasują do wstępnie zdefiniowanego rozmiaru, lub powtórzenie rekordów w partii, aż osiągniesz wstępnie zdefiniowany rozmiar. Na koniec pamiętaj, że w konfiguracji z wieloma GPU rozmiar partii powinien być wielokrotnością liczby dostępnych procesorów graficznych w systemie.

3. Brak danych GPU, czyli procesory nie nadążają za GPU

Zwykle najdroższą częścią podczas szkolenia / przewidywania sieci głębokich jest oszacowanie, które ma miejsce na procesorach graficznych. Dane są wstępnie przetwarzane w procesorach w tle i okresowo przesyłane do GPU. Niemniej jednak nie należy lekceważyć szybkości działania procesorów graficznych; może się zdarzyć, że jeśli twoja sieć jest zbyt płytka lub etap wstępnego przetwarzania jest zbyt złożony, twoje procesory nie mogą nadążyć za twoimi GPU lub innymi słowy, nie dostarczają im danych wystarczająco szybko. Może to prowadzić do niskiego wykorzystania GPU, co przekłada się na marnowanie pieniędzy / zasobów.

Keras zazwyczaj przeprowadza estymacje wsadów równolegle, jednak ze względu na GIL (Global Interpreter Lock) Pythona nie można osiągnąć prawdziwej wielowątkowości w Pythonie. Są na to dwa rozwiązania: albo użyj wielu procesów (zwróć uwagę, że w tym jest wiele problemów, których nie zamierzam tutaj omawiać) lub zachowaj prostotę wstępnego przetwarzania. W przeszłości wysłałem żądanie ściągnięcia do Keras, aby złagodzić niepotrzebne obciążenie procesorów podczas wstępnego przetwarzania obrazu, więc większość użytkowników nie powinna mieć wpływu na używanie standardowych generatorów. Jeśli masz własne generatory, spróbuj przekazać jak najwięcej logiki do bibliotek C, takich jak Numpy, ponieważ niektóre z tych metod w rzeczywistości zwolnić GIL co oznacza, że ​​można zwiększyć stopień równoległości. Dobrym sposobem na wykrycie, czy grozi ci utrata danych GPU, jest monitorowanie wykorzystania GPU, niemniej jednak pamiętaj, że nie jest to jedyny powód, dla którego warto to zauważyć (synchronizacja, która ma miejsce podczas uczenia wielu GPU, jest również odpowiedzialna za niskie wykorzystanie ). Zazwyczaj brak danych GPU można wykryć obserwując impulsy GPU, po których następują długie przerwy bez wykorzystania. W przeszłości stworzyłem rozszerzenie dla Dstat typu open source, które może pomóc w mierzeniu wykorzystania procesora graficznego, więc spójrz na oryginalny post na blogu.

4. Zapisywanie modeli równoległych

Załóżmy, że użyłeś metody mutli_gpu_model do zrównoleglenia modelu, szkolenie zostało zakończone i teraz chcesz zachować jego wagi. Zła wiadomość jest taka, że ​​nie możesz po prostu wywołać metody save (). Obecnie Keras ma ograniczenie, które ci na to nie pozwala zapisać model równoległy. Istnieją dwa sposoby obejścia tego: albo wywołaj metodę save () w odniesieniu do oryginalnego modelu (wagi zostaną zaktualizowane automatycznie) lub musisz serializować model, odcinając równoległą wersję i czyszcząc wszystkie niepotrzebne połączenia. Pierwsza opcja jest znacznie łatwiejsza, ale w przyszłości planuję otworzyć kod źródłowy metody serialize (), która będzie wykonywać to drugie.

5. Liczenie dostępnych procesorów graficznych ma nieprzyjemny efekt uboczny

Niestety w tej chwili w metodzie tensorflow.python.client.device_lib.list_local_devices () występuje nieprzyjemny efekt uboczny, który powoduje utworzenie nowej sesji TensorFlow i inicjalizację wszystkich dostępnych procesorów graficznych w systemie. Może to prowadzić do nieoczekiwanych rezultatów, takich jak wyświetlanie większej liczby procesorów graficznych niż określono lub przedwczesne inicjowanie nowych sesji (możesz przeczytać wszystkie szczegóły na ten temat prośba o pociągnięcie). Aby uniknąć podobnych niespodzianek, zamiast tego zaleca się użycie metody K.get_session (). List_devices () Keras, która zwróci wszystkie aktualnie zarejestrowane procesory GPU w sesji. Na koniec pamiętaj, że wywołanie metody list_devices () jest w jakiś sposób drogie, więc jeśli interesuje Cię tylko liczba dostępnych GPU, wywołaj tę metodę raz i zapisz ich numer w zmiennej lokalnej.

Otóż ​​to! Mam nadzieję, że ta lista okazała się przydatna. Jeśli znalazłeś inne problemy / wskazówki dotyczące treningu GPU w Keras, udostępnij je poniżej w komentarzach. 🙂