5 tipp a több GPU-s edzéshez Kerasszal

• Január 21, 2018
• Vasilis Vryniotis
• . 1 megjegyzés

A Deep Learning (a 2010-es évek végének kedvenc hívószava a blockchain/bitcoin és a Data Science/Machine Learning mellett) lehetővé tette számunkra, hogy igazán klassz dolgokat csináljunk az elmúlt néhány évben. Sikerének fő okai az algoritmusok fejlődésén kívül (amelyek bizonyára az 1990-es évek óta ismert elképzeléseken alapulnak, más néven „adatbányászati ​​korszak”) a nagyméretű ingyenes adatkészletek elérhetőségével, a nyílt forráskódú könyvtárak bevezetésével és a GPU-k használata. Ebben a blogbejegyzésben az utolsó kettőre fogok összpontosítani, és megosztok veletek néhány tippet, amelyeket kemény úton tanultam meg.

Miért TensorFlow és Keras?

TensorFlow egy nagyon népszerű, a Google által kifejlesztett Deep Learning könyvtár, amely lehetővé teszi az összetett hálózatok gyors prototípusát. Rengeteg érdekes funkcióval rendelkezik, mint például az automatikus differenciálás (amely megkíméli Önt a költségfüggvények gradienseinek becslésétől/kódolásától) és a GPU-támogatás (amely lehetővé teszi, hogy könnyen 200-szoros sebességnövekedést érjen el megfelelő hardver használatával). Ezenkívül Python interfészt kínál, ami azt jelenti, hogy gyorsan prototípust készíthet anélkül, hogy C vagy CUDA kódot kellene írnia. Kétségtelenül sok más keretrendszer is használható a TensorFlow helyett, mint például a Torch, MXNet, Theano, Caffe, Deeplearning4j, CNTK stb., de mindez az Ön használati esetén és személyes preferenciáin múlik.

De miért Keras? Számomra a TF közvetlen használata olyan, mintha gépi tanulást végeznék a Numpyval. Igen, ez megvalósítható, és időnként meg kell tennie (főleg, ha egyedi rétegeket/vesztésfüggvényeket ír), de tényleg olyan kódot akar írni, amely a komplex hálózatokat vektoros műveletek sorozataként írja le (igen, tudom vannak magasabb szintű módszerek a TF-ben, de nem olyan menők, mint a Keras)? És mi van akkor, ha másik könyvtárba szeretne költözni? Nos, akkor valószínűleg át kell írnia a kódot, ami szívás. Ta ta taaa, Keras a megmentésre! A Keras lehetővé teszi a hálózatok leírását magas szintű fogalmak segítségével, és olyan kódot írhat, amely háttér-agnosztikus, ami azt jelenti, hogy a hálózatokat különböző mély tanulási könyvtárakon keresztül futtathatja. A Kerasban csak azt szeretem, hogy jól van megírva, objektum-orientált architektúrájú, könnyű hozzászólni, és barátságos közösséggel rendelkezik. Ha tetszik, mondj köszönetet Francois Chollet fejlesztéséért és nyílt forráskódú beszerzéséért.

Tippek és ötletek a több GPU-s képzéshez

Minden további nélkül ugorjunk néhány tippre, hogyan hozhatja ki a legtöbbet a Keras GPU-képzéséből, valamint néhány apróságra, amelyeket szem előtt kell tartania:

1. A több GPU-s betanítás nem automatikus

A Keras és Tensorflow használatával GPU-n végzett képzési modellek zökkenőmentesek. Ha rendelkezik NVIDIA kártyával, és telepítette a CUDA-t, a könyvtárak automatikusan felismerik, és edzésre használják. Annyira cool! De mi van akkor, ha elkényeztetett kölyök vagy, és több GPU-ja van? Nos, sajnos egy kicsit dolgoznia kell a több GPU-s képzés eléréséhez.

Számos módja van a hálózat párhuzamosításának attól függően, hogy mit szeretne elérni, de a két fő megközelítés a modell és az adatok párhuzamosítása. Az első segíthet, ha a modell túl bonyolult ahhoz, hogy egyetlen GPU-ba illeszkedjen, míg az utóbbi akkor segít, ha fel akarja gyorsítani a végrehajtást. Amikor az emberek több GPU-s képzésről beszélnek, általában az utóbbira gondolnak. Korábban nehezebb volt elérni, de szerencsére a Keras nemrégiben beépített egy segédprogramot, az úgynevezett mutli_gpu_model ami megkönnyíti a párhuzamos képzést/jóslatokat (jelenleg csak TF háttérrendszerrel érhető el). A fő ötlet az, hogy átadja a modellt a módszeren, és a rendszer átmásolja a különböző GPU-k között. Az eredeti bemenetet darabokra osztják, amelyeket a különböző GPU-khoz táplálnak, majd egyetlen kimenetként összesítik őket. Ezzel a módszerrel párhuzamos betanítás és előrejelzés is megvalósítható, de ne feledjük, hogy a betanításnál a szükséges szinkronizálás miatt nem skálázódik lineárisan a GPU-k mennyiségével.

2. Ügyeljen a tétel méretére

Amikor több GPU-t oktat, ügyeljen a köteg méretére, mivel annak többféle hatása van a sebességre/memóriára, a modell konvergenciájára, és ha nem vigyáz, megronthatja a modell súlyát!

Sebesség/memória: Nyilvánvalóan minél nagyobb a köteg, annál gyorsabb a képzés/jóslat. Ennek az az oka, hogy a GPU-k adatbevitele és -kivétele többletköltséggel jár, így a kis kötegeknél több az általános költség. A másik oldalon, minél nagyobb a köteg, annál több memóriára van szüksége a GPU-ban. Különösen a betanítás során az egyes rétegek bemenetei a memóriában maradnak, mivel szükség van rájuk a visszafelé terjedési lépésben, így a köteg méretének túlzott növelése memóriakiesési hibákhoz vezethet.

Konvergencia: Ha Stochastic Gradient Decent-et (SGD) vagy annak néhány változatát használja a modell betanításához, akkor szem előtt kell tartania, hogy a kötegméret befolyásolhatja a hálózat konvergáló és általánosító képességét. A tipikus kötegméretek sok számítógépes látásproblémában 32-512 példa között vannak. Mint Keskar et al úgy fogalmazott: „A gyakorlatban megfigyelték, hogy nagyobb tétel (512-nél) használatakor romlik a modell minősége, amit az általánosító képességével mérünk. Vegye figyelembe, hogy más különböző optimalizálók eltérő tulajdonságokkal rendelkeznek, és a speciális elosztott optimalizálási technikák segíthetnek a problémán. Ha érdekelnek a matematikai részletek, ajánlom elolvasni Joeri Hermans tézisét.A méretezhető mély tanulásról és a párhuzamos gradiens süllyedésről".

A súlyok megsértése: Ez egy csúnya technikai részlet, amelynek pusztító következményei lehetnek. Ha több GPU-t oktat, fontos, hogy az összes GPU-t táplálja adatokkal. Előfordulhat, hogy az epocha legutolsó kötegében kevesebb adat van a meghatározottnál (mivel az adatkészlet mérete nem osztható pontosan a köteg méretével). Ez azt eredményezheti, hogy egyes GPU-k nem kapnak adatokat az utolsó lépés során. Sajnos néhány Keras-réteg, különösen a Batch Normalization Layer, nem tud megbirkózni ezzel, ami a nanértékek megjelenéséhez vezet a súlyokban (a BN-réteg futó átlaga és eltérése). Hogy a dolgokat még csúnyábbá tegyük, a képzés során nem figyeljük meg a problémát (miközben a tanulási fázis 1), mert az adott réteg a köteg átlagát/varianciáját használja a becslésekben. Mindazonáltal az előrejelzések során (a tanulási fázis 0-ra van állítva) a futó átlag/szórás használatára kerül sor, ami esetünkben nan lehet, ami rossz eredményekhez vezethet. Tehát tegyen magának egy szívességet, és mindig győződjön meg arról, hogy a köteg mérete rögzített, amikor több GPU-t használ. Ennek két egyszerű módja az előre meghatározott méretnek nem megfelelő kötegek elutasítása, vagy a köteg rekordjainak megismétlése, amíg el nem éri az előre meghatározott méretet. Végül, de nem utolsósorban ne feledje, hogy több GPU-s beállítás esetén a kötegméretnek a rendszeren elérhető GPU-k számának többszörösének kell lennie.

3. GPU adatok Az éhezés más néven a CPU-k nem tudnak lépést tartani a GPU-kkal

A mélyhálózatok betanítása/jóslása során jellemzően a legdrágább a GPU-kon végzett becslés. Az adatokat a háttérben lévő CPU-k előfeldolgozzák, és időszakonként betáplálják a GPU-kba. Ennek ellenére nem szabad alábecsülni a GPU-k gyorsaságát; Előfordulhat, hogy ha a hálózat túl sekély, vagy az előfeldolgozási lépés túl bonyolult, akkor a CPU-k nem tudnak lépést tartani a GPU-kkal, vagy más szóval nem táplálják őket elég gyorsan adatokkal. Ez alacsony GPU-kihasználtsághoz vezethet, ami pénz/erőforrás-pazarlást jelent.

A Keras jellemzően párhuzamosan végzi el a kötegek becslését, de a Python GIL (Global Interpreter Lock) miatt nem igazán lehet valódi többszálas működést elérni Pythonban. Erre két megoldás létezik: vagy használjon több folyamatot (vegye figyelembe, hogy ebben sok hiba van, amelyekre itt nem térek ki), vagy tartsa egyszerű az előfeldolgozási lépést. Korábban küldtem egy Pull-Request-et a Keras-ra, hogy enyhítsem a CPU-kra nehezedő szükségtelen terhelést a kép előfeldolgozása során, így a legtöbb felhasználót nem érinti, ha a szabványos generátorokat használják. Ha egyéni generátorai vannak, próbálja meg a lehető legtöbb logikát a C-könyvtárakba, például a Numpy-ba tolni, mert ezeknek a módszereknek némelyike ​​valójában engedje el a GIL-t ami azt jelenti, hogy növelheti a párhuzamosítás mértékét. A GPU-kihasználtság figyelése egy jó módja annak megállapítására, hogy a GPU-kihasználtság figyelhető-e meg, de nem ez az egyetlen oka ennek megfigyelésére (a több GPU-n történő edzés során előforduló szinkronizálás is felelős az alacsony kihasználtságért ). A GPU adatvesztése általában úgy észlelhető, hogy megfigyeljük a GPU burst, majd hosszú szüneteket, kihasználatlanság nélkül. Korábban nyílt forráskódú bővítményt készítettem a Dstat számára, amely segíthet mérni a GPU kihasználtságát, ezért tekintse meg a eredeti blogbejegyzés.

4. Párhuzamos modellek mentése

Tegyük fel, hogy a mutli_gpu_model metódust használta a modell párhuzamosításához, az edzés befejeződött, és most meg akarja őrizni a súlyait. A rossz hír az, hogy nem hívhatod meg rajta a save()-t. Jelenleg a Kerasnak van egy korlátozása, amely ezt nem teszi lehetővé mentse el a párhuzamos modellt. Kétféleképpen kerülheti el ezt: vagy hívja meg a save()-t az eredeti modell hivatkozásán (a súlyok automatikusan frissülnek), vagy a modellt szerializálni kell a párhuzamosított verzió levágásával és az összes szükségtelen kapcsolat megtisztításával. Az első lehetőség sokkal egyszerűbb, de a jövőben egy nyílt forráskódú serialize() metódust tervezek, amely az utóbbit hajtja végre.

5. Az elérhető GPU-k számbavételének csúnya mellékhatása van

Sajnos jelenleg van egy csúnya mellékhatása a tensorflow.python.client.device_lib.list_local_devices() metódusnak, amely új TensorFlow munkamenet létrehozását és a rendszer összes elérhető GPU-jának inicializálását okozza. Ez nem várt eredményekhez vezethet, mint például a megadottnál több GPU megtekintése vagy új munkamenetek idő előtti inicializálása (erről az összes részletet elolvashatja húzó-kérés). A hasonló meglepetések elkerülése érdekében javasoljuk a Keras K.get_session().list_devices() metódusának használatát, amely visszaadja a munkamenetben jelenleg regisztrált összes GPU-t. Végül, de nem utolsósorban, ne feledje, hogy a list_devices() metódus meghívása valahogy költséges, tehát ha csak az elérhető GPU-k száma érdekli, hívja egyszer a metódust, és tárolja a számát egy helyi változóban.

Ez az! Remélem hasznosnak találta ezt a listát. Ha találtál más érdekességeket/tippeket a Keras GPU-képzéséhez, oszd meg őket lent a megjegyzésekben. 🙂