5 sfaturi pentru antrenament multi-GPU cu Keras

• Ianuarie 21, 2018
• Vasilis Vryniotis
• . 1 Comentariu

Învățarea profundă (cuvântul la modă preferat de la sfârșitul anilor 2010, împreună cu blockchain/bitcoin și Data Science/Machine Learning) ne-a permis să facem niște lucruri foarte interesante în ultimii ani. În afară de progresele în algoritmi (care se recunoaște că se bazează pe idei deja cunoscute încă din anii 1990, numite „Era Data Mining”), principalele motive ale succesului acestuia pot fi atribuite disponibilității unor seturi mari de date gratuite, introducerii bibliotecilor open-source și utilizarea GPU-urilor. În această postare pe blog mă voi concentra pe ultimele două și voi împărtăși cu voi câteva sfaturi pe care le-am învățat la greu.

De ce TensorFlow & Keras?

TensorFlow este o bibliotecă Deep Learning foarte populară dezvoltată de Google, care vă permite să prototipați rapid rețele complexe. Vine cu o mulțime de caracteristici interesante, cum ar fi diferențierea automată (care vă scutește de estimarea/codificarea gradienților funcțiilor de cost) și suport pentru GPU (care vă permite să obțineți cu ușurință o îmbunătățire a vitezei de 200x folosind hardware decent). În plus, oferă o interfață Python, ceea ce înseamnă că puteți prototipa rapid fără a fi nevoie să scrieți cod C sau CUDA. Desigur, există o mulțime de alte cadre pe care le puteți folosi în loc de TensorFlow, cum ar fi Torch, MXNet, Theano, Caffe, Deeplearning4j, CNTK etc., dar totul se rezumă la cazul dvs. de utilizare și la preferințele dvs. personale.

Dar de ce Keras? Pentru mine, folosirea directă a TF este ca și cum aș face Machine Learning cu Numpy. Da, este fezabil și din când în când trebuie să o faci (mai ales dacă scrii straturi personalizate/funcții de pierdere) dar chiar vrei să scrii cod care să descrie rețelele complexe ca o serie de operații vectoriale (da, știu există metode de nivel superior în TF, dar nu sunt la fel de cool ca Keras)? De asemenea, ce se întâmplă dacă doriți să vă mutați într-o altă bibliotecă? Ei bine, atunci probabil că ar trebui să rescrieți codul, ceea ce este nasol. Ta ta taaa, Keras la salvare! Keras vă permite să vă descrieți rețelele folosind concepte de nivel înalt și să scrieți cod care este agnostic de backend, ceea ce înseamnă că puteți rula rețelele în diferite biblioteci de deep learning. Puține lucruri care îmi plac la Keras sunt că este bine scrisă, are o arhitectură orientată pe obiecte, este ușor de contribuit și are o comunitate prietenoasă. Dacă vă place, spuneți mulțumesc Francois Chollet pentru dezvoltarea acestuia și pentru deschiderea acestuia.

Sfaturi și probleme pentru antrenamentul Multi-GPU

Fără alte prelungiri, să trecem la câteva sfaturi despre cum să profitați la maximum de antrenamentul GPU pe Keras și la câteva probleme pe care ar trebui să le aveți în vedere:

1. Antrenamentul multi-GPU nu este automat

Modelele de antrenament pe GPU folosind Keras & Tensorflow sunt perfecte. Dacă aveți un card NVIDIA și ați instalat CUDA, bibliotecile îl vor detecta automat și îl vor folosi pentru antrenament. Atât de tare! Dar ce se întâmplă dacă ești un prost răsfățat și ai mai multe GPU-uri? Ei bine, din păcate, va trebui să munciți puțin pentru a obține antrenament multi-GPU.

Există mai multe moduri de a paraleliza o rețea în funcție de ceea ce doriți să realizați, dar principalele două abordări sunt paralelizarea modelului și a datelor. Primul vă poate ajuta dacă modelul dvs. este prea complex pentru a se potrivi într-un singur GPU, în timp ce cel din urmă vă ajută atunci când doriți să grăbiți execuția. De obicei, atunci când oamenii vorbesc despre antrenament multi-GPU, se referă la acesta din urmă. Odinioară era mai greu de realizat, dar, din fericire, Keras a inclus recent o metodă de utilitate numită mutli_gpu_model ceea ce facilitează antrenamentul/predicțiile paralele (disponibil în prezent numai cu backend TF). Ideea principală este că vă treceți modelul prin metodă și acesta este copiat pe diferite GPU-uri. Intrarea inițială este împărțită în bucăți care sunt alimentate diferitelor GPU-uri și apoi sunt agregate ca o singură ieșire. Această metodă poate fi utilizată pentru realizarea de antrenament și predicții paralele, totuși rețineți că pentru antrenament nu se scalează liniar cu cantitatea de GPU-uri datorită sincronizării necesare.

2. Acordați atenție dimensiunii lotului

Când faceți antrenament multi-GPU, acordați atenție dimensiunii lotului, deoarece are efecte multiple asupra vitezei/memoriei, convergenței modelului dvs. și, dacă nu sunteți atent, s-ar putea să vă deteriorați greutățile modelului!

Viteza/memorie: Evident, cu cât lotul este mai mare, cu atât antrenamentul/predicția este mai rapidă. Acest lucru se datorează faptului că există o suprasarcină la introducerea și scoaterea datelor din GPU-uri, astfel încât loturile mici au mai multă suprasarcină. Pe de altă parte, cu cât lotul este mai mare, cu atât aveți nevoie de mai multă memorie în GPU. În special în timpul antrenamentului, intrările fiecărui strat sunt păstrate în memorie, deoarece sunt necesare în pasul de back-propagation, astfel încât mărirea prea multă a dimensiunii lotului poate duce la erori de lipsă de memorie.

Convergenţă: Dacă utilizați Stochastic Gradient Decent (SGD) sau unele dintre variantele sale pentru a vă antrena modelul, ar trebui să aveți în vedere că dimensiunea lotului poate afecta capacitatea rețelei dvs. de a converge și de a generaliza. Dimensiunile tipice ale loturilor în multe probleme de vedere computerizată sunt între 32-512 exemple. La fel de Keskar şi colab „S-a observat în practică că atunci când se folosește un lot mai mare (decat 512) există o degradare a calității modelului, măsurată prin capacitatea sa de a generaliza.” Rețineți că alți optimizatori diferiți au proprietăți diferite, iar tehnicile specializate de optimizare distribuită pot ajuta la rezolvarea problemei. Dacă sunteți interesat de detaliile matematice, vă recomand să citiți teza lui Joeri Hermans „Despre învățare profundă scalabilă și coborâre paralelă a gradientului".

Coruperea greutăților: Acesta este un detaliu tehnic urât care poate avea rezultate devastatoare. Când faceți antrenament multi-GPU, este important să alimentați toate GPU-urile cu date. Se poate întâmpla ca ultimul lot al epocii tale să aibă mai puține date decât cele definite (deoarece dimensiunea setului de date nu poate fi împărțită exact la dimensiunea lotului). Acest lucru ar putea face ca unele GPU să nu primească date în timpul ultimului pas. Din păcate, unele straturi Keras, în special Stratul de normalizare a lotului, nu pot face față faptului că apar valori nan în ponderi (media curentă și varianța în stratul BN). Pentru a face lucrurile și mai urâte, nu se va observa problema în timpul antrenamentului (în timp ce faza de învățare este 1), deoarece stratul specific folosește media/varianța lotului în estimări. Cu toate acestea, în timpul predicțiilor (faza de învățare setată la 0), este utilizată media/varianța curentă care în cazul nostru poate deveni nan conducând la rezultate slabe. Așa că fă-ți o favoare și asigură-te întotdeauna că dimensiunea lotului este fixă ​​atunci când faci antrenament multi-GPU. Două moduri simple de a realiza acest lucru sunt fie prin respingerea loturilor care nu se potrivesc cu dimensiunea predefinită, fie prin repetarea înregistrărilor în cadrul lotului până când ajungeți la dimensiunea predefinită. Nu în ultimul rând, rețineți că într-o configurare cu mai multe GPU, dimensiunea lotului ar trebui să fie un multiplu al numărului de GPU-uri disponibile pe sistemul dvs.

3. Datele GPU Starvation alias CPU-urile nu pot ține pasul cu GPU-urile

De obicei, cea mai scumpă parte în timpul antrenamentului/predicției rețelelor profunde este estimarea care se întâmplă pe GPU-uri. Datele sunt preprocesate în procesoarele de pe fundal și sunt transmise periodic la GPU-uri. Cu toate acestea, nu ar trebui să subestimați cât de rapide sunt GPU-urile; se poate întâmpla ca dacă rețeaua dvs. este prea superficială sau pasul de preprocesare este prea complex încât CPU-urile dvs. să nu poată ține pasul cu GPU-urile dvs. sau, cu alte cuvinte, să nu le alimenteze suficient de repede cu date. Acest lucru poate duce la o utilizare scăzută a GPU-ului, ceea ce se traduce prin risipa de bani/resurse.

Keras efectuează de obicei estimările loturilor în paralel, cu toate acestea, datorită GIL (Global Interpreter Lock) de la Python, nu puteți realiza cu adevărat multi-threading în Python. Există două soluții pentru asta: fie folosiți mai multe procese (rețineți că există o mulțime de probleme în acesta pe care nu le voi acoperi aici) sau păstrați pasul de preprocesare simplu. În trecut, am trimis un Pull-Request pe Keras pentru a atenua o parte din efortul inutil pe care îl puneam pe procesoarele în timpul preprocesării imaginii, așa că majoritatea utilizatorilor nu ar trebui să fie afectați dacă folosesc generatoarele standard. Dacă aveți generatoare personalizate, încercați să împingeți cât mai multă logică în bibliotecile C, cum ar fi Numpy, deoarece unele dintre aceste metode de fapt eliberează GIL ceea ce înseamnă că poți crește gradul de paralelizare. O modalitate bună de a detecta dacă vă confruntați cu înfometarea datelor GPU este să monitorizați utilizarea GPU-ului, totuși fiți avertizat că acesta nu este singurul motiv pentru care observați că (sincronizarea care are loc în timpul antrenamentului pe mai multe GPU-uri este, de asemenea, de vină pentru utilizarea scăzută). ). De obicei, lipsa datelor GPU poate fi detectată prin observarea exploziilor GPU urmate de pauze lungi fără utilizare. În trecut, am creat în sursă deschisă o extensie pentru Dstat care vă poate ajuta să vă măsurați utilizarea GPU-ului, așa că aruncați o privire la postare originală pe blog.

4. Salvarea modelelor dvs. paralele

Să presupunem că ați folosit metoda mutli_gpu_model pentru a vă paraleliza modelul, antrenamentul s-a terminat și acum doriți să-i păstrați greutățile. Vestea proastă este că nu poți să apelezi la save() pe el. În prezent, Keras are o limitare care nu vă permite salvați un model paralel. Există 2 moduri de a evita acest lucru: fie apelați salvarea () pe referința modelului original (greutățile vor fi actualizate automat) fie trebuie să serializați modelul prin tăierea versiunii paralelizate și curățarea tuturor conexiunilor inutile. Prima opțiune este mult mai ușoară, dar pe viitor plănuiesc să deschid o metodă serialize() care o efectuează pe cea din urmă.

5. Numărarea GPU-urilor disponibile are un efect secundar urât

Din păcate, în acest moment, există un efect secundar urât asupra metodei tensorflow.python.client.device_lib.list_local_devices() care determină crearea unei noi sesiuni TensorFlow și inițializarea tuturor GPU-urilor disponibile pe sistem. Acest lucru poate duce la rezultate neașteptate, cum ar fi vizualizarea mai multor GPU-uri decât cele specificate sau inițializarea prematură a noilor sesiuni (puteți citi toate detaliile despre aceasta cerere de tragere). Pentru a evita surprize similare, sunteți sfătuit să utilizați metoda K.get_session().list_devices() de la Keras, care vă va returna toate GPU-urile înregistrate în prezent în sesiune. Nu în ultimul rând, rețineți că apelarea metodei list_devices() este oarecum costisitoare, așa că dacă sunteți interesat doar de numărul de GPU-uri disponibile, apelați metoda o dată și stocați numărul lor pe o variabilă locală.

Asta este! Sper că ați găsit această listă utilă. Dacă ați găsit alte probleme/sfaturi pentru antrenamentul GPU pe Keras, împărtășiți-le mai jos în comentarii. 🙂