Wujek Google ratuje wewnętrznego Sknerusa przed wykrętami nauki uczenia głębokiego

wpis w: chmura, IaaS, Machine Learning, Python | 4

Nieustanny rozwój mocy obliczeniowej komputerów osobistych, fizycznych serwerów i wszelkiej maści maszyn wirtualnych umieszczanych w chmurach prywatnych czy publicznych umożliwił  testowanie i uruchamianie modeli uczenia maszynowego, które do niedawna były poza zasięgiem przeciętnego fascynata sztucznej inteligencji. Myślę o osobach, które nie tylko chciały z niej korzystać, ale również wnieść wkład w praktyczne wykorzystanie lat doświadczeń środowiska naukowego. Dotyczy to w szczególności uczenia głębokiego, które jest podzbiorem algorytmów uczenia maszynowego i jedną z jego cech jest  pazerność na moc obliczeniową. Głębokie sieci neuronowe składające się z wielu warstw ukrytych i setek tysięcy parametrów (wag), które podczas procesu uczenia są wyznaczane iteracyjne wymagają mocy obliczeniowych. Standardowa jednostka CPU nie radzi sobie odpowiednio skutecznie. Ratunkiem jest wykorzystanie  procesorów graficznych GPU, które pozwalają na sprawne przeprowadzanie operacji macierzowych i znacznie przyśpieszają  czas obliczeń. Przypomina mi się moje pierwsze uruchomienie takiego modelu z wykorzystaniem laptopa biznesowego i jego 8-rdzeniowego procesora I7 drugiej generacji. Do tego momentu nie miałem świadomości, jakie wydaje dźwięki to obciążone urządzenie. Skończyło się twardym restartem.

W poprzednim wpisie  mówiłem o sposobie pracy z płytką Jetson Nano, która jest takim odpowiednikiem Raspberry PI, ale ze sprzętowym procesorem GPU, który może być użyty np. przy wykorzystaniu silnika Tensorflow.  Tak opisana konfiguracja  jest niejako rozwiązaniem chmury prywatnej   serwującym usługę GPU as a Service. WYmaga to oczywiście zakupu urządzenia i jego konfigurację. Powstało pytanie, czy da się zbudować podobne rozwiązanie ale w chmurze publicznej? Takie ,które pozwoli na uruchamianie skryptów języka Python z wykorzystaniem GPU i bez zużycia portfela naszego wewnętrznego Sknerusa.

Okazałą się że jest taka usługa. Usługa Colab firmy Google, pozwala ona między innymi wykorzystać na góra 12h w jednej sesji kartę GPU Nvidia Tesla K-80 .  Dla zainteresowanych proponuję poszukać ile jest ona obecnie warta.

Po uruchomieniu mamy do dyspozycji  możliwość utworzenia notatnika

Utwórzmy prosty notatnik w języku Python 3, druga wersja tego języka jest nadal obsługiwana, ale pamiętajmy, że  jest praktycznie na wymarciu i od 2020 roku nie będzie rozwijana.

Z menu Runtime wybieramy opcję Change Runtime Type

 

Jest do dyspozycji też procesor TPU, ale o tym opowiem w innym wpisie. Na tę chwilę wybierzmy GPU. Po naciśnięciu przycisku Save w tle zostanie podłączona maszyna wirtualna z gotowym oprogramowaniem. Spójrzmy na chwilę co tu mamy.

W podkatalogu sample_data mamy kilka małych plików z klasycznymi przykładami znanych zbiorów danych.

Zwracam uwagę na liczbę na dole. Mamy do dyspozycji  ponad 300 GB wolnego miejsca, ale pamiętajmy ze wszelkie dane jaki tam umieścimy są ulotne i po wygaśnięciu sesji 12 godzin nie będziemy mieć do nich dostępu. Na szczęście istnieje możliwość podłączenie Google drive, pobrania danych z  zewnętrznych źródeł. Pamiętajmy to tym, oszczędzi nam to na przyszłość wiele rozczarowań. Dla osób, które rozpoczynają przygodę z usługami w chmurach publicznych może się to wydawać na początku ich wadą, ale wbrew pozorom ma to swoje uzasadnienie.

Celem naszego ćwiczenia jest wykorzystanie usługi Colab jako klasycznej maszyny wirtualnej, na której możemy instalować potrzebne nam oprogramowanie, załadować dane do uczenia i załadować skrypty z modelami.

 

Na początku zobaczmy co mamy tam pod spodem z poziomu notatnika:

To co otrzymujemy na wyjściu to potwierdzenie, że mamy zainstlowane oprogramowanie do obłsugi naszej karty GPU.

Znak ! na początku oznacza wykonanie polecenia powłoki (linux) a nie instrukcji Pythona.

 

Zwracam uwagę, że z pudełka  nie mamy  zgodności wersji

NVIDIA-SMI 430.40 Driver Version: 418.67 .

Będzie to poprawione w skrypcie wdrażającym oprogramowanie

Zobaczmy czy silnik Tensorflow zauważa urządzenie GPU

Urządzenie “/device:GPU:0”  jest widoczne jako jedyne tego typu i oznacza to pierwszą kartę GPU (numerujemy od zera). Ogólnie istnieje możliwość korzystania z wielu kart GPU, ale cały czas mówimy tu o darmowym rozwiązaniu, które ma oczywiście swoje ograniczenia, ale nie aż takie, by nie można z niego efektywnie korzystać.

Zainstalowana jest wersja 1.14, ale istnieje możliwość instalacji wersji 2.

Jak widać mamy do czynienia z Ubuntu w wersji 18.04 LTS.

Tu jest najważniejsza informacja, zauważmy ze pracujemy na koncie root tej maszyny. Wyższych uprawnień nie można dodać. Nie wiem do końca jaki był zamysł twórcy usługi.  Dodatkowo mamy potwierdzenie,że  dostępna przestrzeń dyskowa to ponad 300 GB.

Możemy jeszcze dowiedzić się o szczegółach informacji o pamięciu, procesorze

Pozostawiam to do wykonania dla zainteresowanych.

W tym momencie zaczynamy właściwą instalację oprogramowania.
Kod skryptu umieściłem w repozytorium Github.

Po pobraniu danych możemy podejrzeć zawartość skryptu

Instalacja oprogramowania sprowadza się do kilku czynności.
1) Aktualizacja repozytoriów Ubuntu
2) Wymuszenie korzystania z Pythona w wersji 3 (Python 3.6.8). Domyślnie jest to wersja 2.7.
3) Instalowane jest oprogramowanie konsolowe do monitoringu o nazwie nvtop
4) Instalacja sterowników Nvidia, tak by zachować zgodność wersji CUDA z wersją oprogramoania aplikacji.
Wybrałem wersje 418.87

Ta część być może nie wygląda zbyt elegancko, ale została przetestowana wielokrotnie.

5) Instalacja oprogramowania Jupyter notebook

Po instalacji oprogramowania,  potrzebnego do wykorzystania GPU na tej maszynie (trwa ono około 6 minut)  przyszła pora na zmianę konfiguracji sieciowej

Jak widać mamy uruchomioną tylko adresację prywatną 172.16.0.1 – 172.31.255.254

Rozpoczynamy od instalacji usługi SSH

Przykładowe informacje potrzebne do zalogowanie się do maszyny to para (użytkownik/hasło). W skrypcie umieściłem też statyczne hasło, ale nie jest to polecania konfiguracja, stad generate_password=True i za każdym razie mamy jego inną wartość. Dodatkowo, jeśli dobrze przyjrzymy się skryptowi, to zauważymy, że włączyliśmy możliwość logowania się przez SSH kontem root. Bezpieczeństwo rozwiązania nie jest głównym celem tej demonstracji, ale każda zmiana, która spowoduje tak zwany hardening (utwardzenie), jest mile widziana. Piszcie śmiało.

Na wyjściu skryptu mamy:

Tworzymy tunel z maszyny wirtualnej. Wykorzystamy to tego celu darmowe rozwiązanie ngrok.

 

Logujemy się na stronę https://dashboard.ngrok.com/

 

Pobieramy token

Nie martwcie się, nie skorzystacie z niego, został już dawno przegenerowany.

Zamiast zaglądania na stronę www możemy również z poziomu skryptu podejrzeć numer portu

Do pełni szczęścia brakuje  jeszcze podłączenia z  naszego komputera do Colaba.

Wykorzystując popularny klient SSH jakim jest putty logujemy się kontem root na naszą maszynę:

Po zalogowaniu się za pomocą hasła wygenerowanego poprzednio

Potwierdzamy dodanie klucza do naszego lokalnego rejestru i po chwili jesteśmy wewnątrz maszyny Colaba.

Po zalogowaniu się uruchamiamy polecenie

I naszym oczom okazuje się konsola podzielona na trzy części

Mamy tu uruchomiony notatnik Jupytera, monitoring GPU i forwardowanie portu 8888 na nazwę publiczną.

myjupyter-lab.serveo.net

Dzięki temu w  oknie naszej przeglądarki jest możliwość uruchamiania standardowych notatników Jupytera.

Zawartość pliku bash

 

Można oczywiście nie korzystać z maszyny w ten sposób. Notatniki Jupytera są dobre do budowy prototypów. Trenowanie modelu może się odbywać w czystych skryptach języka Python. Co więcej, należy zapewnić cykliczną synchronizację danych z Colaba np. na dysk Google. Dotyczy to w szczególności zapisanych modeli i ich wag. Pamiętajmy o czasie jakiego potrzebuje sieć by się trenować. Proces trenowania powinien być przystosowany do wznawiania w dowolnym momencie, ale tak by tracić dane co najwyżej z ostatniej epoki.

Szkic rozwiązania można  opisać w poniższy sposób:

 

Wnioski

 

Opisana konfiguracja pozwala na wykorzystanie dostępu do darmowego GPU i maszyny wirtualnej z pełną nad nią kontrolą. Dzięki temu nasza podróż w poznawaniu algorytmów uczenia głębokiego przez wykorzystanie np. bibliotek języka Python nie musi być być obarczona dodatkowym kosztem.

Ale nie tylko. W planach mam zamiar zademonstrować, jak wykorzystać Colaba do nauki Apache Sparka.

 

Literatura

https://imadelhanafi.com/posts/google_colal_server/

https://gist.github.com/yashkumaratri/204755a85977586cebbb58dc971496da

 

Kody źródłowe

https://github.com/djkormo/colab-examples

 

Aplikacja do budowy wykresów

https://www.draw.io/

 

4 Responses

  1. mmoskit

    Nie dowiedziałem się co prawda w jaki sposób wykorzystać darmową moc obliczeniową GPU do powiększenia zasobów portfela BTC ale artykuł zainspirował mnie do dalszego drążenia tematu 🙂
    Tak na poważnie… Dzięki. Dobra Robota!

    • djkormo

      No i się nie dowiesz jak kopać cryptowaluty. Związane jest to z oficjalnym stanowiskiem na stronie
      https://research.google.com/colaboratory/faq.html
      “Please note that using Colaboratory for cryptocurrency mining is disallowed entirely, and may result in being banned from using Colab altogether.”
      Ale pozostałe funckjonalności i uczenie głębokie stoją otworem. Nic tylko brać i wybierać.

  2. Damian

    Fajny pomysł i artykuł. Faktycznie czasem ciekawi jak daleko można zajść z publicznymi instancjami maszyn obliczeniowych. A tutaj, dotarłeś w praktyce do samego dna :-D.

    Z chęcią przeczytam też jak jak ugryzłeś temat Apache Spark. Oby tak dalej 🙂

    • djkormo

      Poprzedni post dotyczył płytki Jetson Nano, ten opisuje Colaba. Będą kontynuacje w obu kierunkach. Np. Pytorch zamiast pary Keras-TF.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *