5 tips voor multi-GPU-training met Keras

• 21 januari 2018
• Vasilis Vryniotis
• . 1 reactie

Deep Learning (het favoriete modewoord van eind 2010 samen met blockchain / bitcoin en Data Science / Machine Learning) heeft ons de afgelopen jaren in staat gesteld om echt coole dingen te doen. Afgezien van de vooruitgang in algoritmen (die weliswaar zijn gebaseerd op ideeën die al bekend zijn sinds de jaren negentig, ook bekend als "Data Mining-tijdperk"), kunnen de belangrijkste redenen voor het succes ervan worden toegeschreven aan de beschikbaarheid van grote gratis datasets, de introductie van open-sourcebibliotheken en het gebruik van GPU's. In deze blogpost zal ik me concentreren op de laatste twee en ik zal enkele tips met je delen die ik op de harde manier heb geleerd.

Waarom TensorFlow & Keras?

TensorFlow is een zeer populaire Deep Learning-bibliotheek ontwikkeld door Google waarmee u snel complexe netwerken kunt prototypen. Het wordt geleverd met veel interessante functies, zoals automatische differentiatie (die u bespaart bij het schatten / coderen van de gradiënten van de kostenfuncties) en GPU-ondersteuning (waarmee u gemakkelijk 200x snelheidsverbetering kunt krijgen met fatsoenlijke hardware). Bovendien biedt het een Python-interface, wat betekent dat u snel een prototype kunt maken zonder dat u C- of CUDA-code hoeft te schrijven. Toegegeven, er zijn veel andere frameworks die je kunt gebruiken in plaats van TensorFlow, zoals Torch, MXNet, Theano, Caffe, Deeplearning4j, CNTK, enz. Maar het komt allemaal neer op je use-case en je persoonlijke voorkeur.

Maar waarom Keras? Voor mij is het direct gebruiken van TF alsof je Machine Learning doet met Numpy. Ja, het is haalbaar en van tijd tot tijd moet je het doen (vooral als je aangepaste lagen / verliesfuncties schrijft) maar wil je echt code schrijven die de complexe netwerken beschrijft als een reeks vectorbewerkingen (ja, ik weet het er zijn hogere methoden in TF maar ze zijn niet zo cool als Keras)? En wat als u naar een andere bibliotheek wilt verhuizen? Nou, dan zou je waarschijnlijk de code moeten herschrijven, wat rot is. Ta ta taaa, Keras schiet te hulp! Met Keras kunt u uw netwerken beschrijven met behulp van concepten op hoog niveau en code schrijven die back-end agnostisch is, wat betekent dat u de netwerken over verschillende deep learning-bibliotheken kunt laten lopen. Weinig dingen die ik leuk vind aan Keras is dat het goed is geschreven, dat het een objectgeoriënteerde architectuur heeft, dat het gemakkelijk is om bij te dragen en dat het een vriendelijke gemeenschap heeft. Als je het leuk vindt, zeg dan bedankt François Chollet voor het ontwikkelen en open-sourcen ervan.

Tips en Gotchas voor training met meerdere GPU's

Laten we zonder verder oponthoud naar een paar tips gaan om het meeste uit GPU-training op Keras te halen en een paar valkuilen die u in gedachten moet houden:

1. Multi-GPU-training is niet automatisch

Trainingsmodellen op GPU met Keras & Tensorflow zijn naadloos. Als je een NVIDIA-kaart hebt en je hebt CUDA geïnstalleerd, zullen de bibliotheken deze automatisch detecteren en gebruiken voor training. Zo cool! Maar wat als je een verwend nest bent en je hebt meerdere GPU's? Nou, helaas zul je een beetje moeten werken om multi-GPU-training te behalen.

Er zijn meerdere manieren om een ​​netwerk te paralleliseren, afhankelijk van wat u wilt bereiken, maar de twee belangrijkste benaderingen zijn model- en gegevensparallellisatie. De eerste kan u helpen als uw model te complex is om in een enkele GPU te passen, terwijl de laatste helpt wanneer u de uitvoering wilt versnellen. Wanneer mensen het hebben over multi-GPU-training, bedoelen ze meestal de laatste. Vroeger was het moeilijker te bereiken, maar gelukkig heeft Keras onlangs een hulpprogramma-methode genoemd mutli_gpu_model wat de parallelle training / voorspellingen gemakkelijker maakt (momenteel alleen beschikbaar met TF-backend). Het belangrijkste idee is dat u uw model via de methode doorgeeft en dat het wordt gekopieerd over verschillende GPU's. De oorspronkelijke invoer wordt opgesplitst in brokken die naar de verschillende GPU's worden gevoerd en vervolgens als één uitvoer worden samengevoegd. Deze methode kan worden gebruikt voor het bereiken van parallelle training en voorspellingen, maar houd er rekening mee dat het voor training niet lineair schaalt met het aantal GPU's vanwege de vereiste synchronisatie.

2. Let op de batchgrootte

Wanneer u multi-GPU-trainingen doet, let dan op de batchgrootte, omdat dit meerdere effecten heeft op snelheid / geheugen, convergentie van uw model en als u niet oppast, kan uw modelgewichten beschadigd raken!

Snelheid / geheugen: Het is duidelijk dat hoe groter de batch, hoe sneller de training / voorspelling. Dit komt omdat er een overhead is voor het plaatsen en verwijderen van gegevens van de GPU's, dus kleine batches hebben meer overhead. Aan de andere kant: hoe groter de batch, hoe meer geheugen je nodig hebt in de GPU. Vooral tijdens de training worden de ingangen van elke laag in het geheugen bewaard omdat ze nodig zijn tijdens de back-propagation-stap, dus het te veel vergroten van uw batchgrootte kan leiden tot fouten in het geheugen.

Convergentie: Als u Stochastic Gradient Decent (SGD) of een aantal van zijn varianten gebruikt om uw model te trainen, moet u er rekening mee houden dat de batchgrootte het vermogen van uw netwerk om te convergeren en te generaliseren, kan beïnvloeden. Typische batchgroottes bij veel computerzichtproblemen liggen tussen 32-512 voorbeelden. Net zo Keskar et al "Het is in de praktijk geconstateerd dat bij gebruik van een grotere batch (dan 512) de kwaliteit van het model verslechtert, gemeten naar zijn vermogen om te generaliseren." Merk op dat andere verschillende optimizers verschillende eigenschappen hebben en gespecialiseerde gedistribueerde optimalisatietechnieken kunnen helpen bij het probleem. Als je geïnteresseerd bent in de wiskundige details, raad ik je aan het proefschrift van Joeri Hermans te lezen “Over schaalbaar diep leren en parallel verlopende afdaling'.

De gewichten beschadigen: Dit is een akelig technisch detail dat desastreuze gevolgen kan hebben. Wanneer je een multi-GPU training doet, is het belangrijk om alle GPU's van data te voorzien. Het kan voorkomen dat de allerlaatste batch van uw tijdperk minder gegevens heeft dan gedefinieerd (omdat de grootte van uw dataset niet exact kan worden gedeeld door de grootte van uw batch). Dit kan ertoe leiden dat sommige GPU's tijdens de laatste stap geen gegevens ontvangen. Helaas kunnen sommige Keras-lagen, met name de batchnormalisatielaag, dat niet aan, wat leidt tot nan-waarden die in de gewichten verschijnen (het lopende gemiddelde en de variantie in de BN-laag). Om de dingen nog erger te maken, zal men het probleem tijdens de training niet opmerken (terwijl leerfase 1 is) omdat de specifieke laag het gemiddelde / de variantie van de batch gebruikt in de schattingen. Niettemin wordt tijdens voorspellingen (leerfase ingesteld op 0) het lopende gemiddelde / variantie gebruikt, wat in ons geval nan kan worden, wat leidt tot slechte resultaten. Dus doe jezelf een plezier en zorg er altijd voor dat je batchgrootte vast is wanneer je een multi-GPU-training doet. Twee eenvoudige manieren om dit te bereiken zijn door batches te weigeren die niet overeenkomen met de vooraf gedefinieerde grootte of door de records binnen de batch te herhalen totdat u de vooraf gedefinieerde grootte bereikt. Houd er ten slotte rekening mee dat in een opstelling met meerdere GPU's de batchgrootte een veelvoud moet zijn van het aantal beschikbare GPU's op uw systeem.

3. GPU-gegevens Starvation oftewel de CPU's kunnen de GPU's niet bijhouden

Typisch het duurste onderdeel tijdens het trainen / voorspellen van diepe netwerken is de schatting die op de GPU's gebeurt. De gegevens worden voorverwerkt in de CPU's op de achtergrond en worden periodiek naar de GPU's gevoerd. Desalniettemin moet men niet onderschatten hoe snel de GPU's zijn; het kan gebeuren dat als uw netwerk te oppervlakkig is of de voorbewerkingsstap te complex is, uw CPU's uw GPU's niet kunnen bijhouden of met andere woorden ze niet snel genoeg van gegevens voorzien. Dit kan leiden tot een laag GPU-gebruik, wat zich vertaalt in verspild geld / middelen.

Keras voert de schattingen van de batches meestal parallel uit, maar dankzij Python's GIL (Global Interpreter Lock) kunt u niet echt echte multi-threading in Python bereiken. Daar zijn twee oplossingen voor: gebruik meerdere processen (merk op dat hier veel valkuilen zijn die ik hier niet ga behandelen) of houd je voorbewerkingsstap eenvoudig. In het verleden heb ik een Pull-Request op Keras gestuurd om een ​​deel van de onnodige belasting te verminderen die we op de CPU's hebben uitgeoefend tijdens het voorbewerken van afbeeldingen, dus de meeste gebruikers zouden niet moeten worden beïnvloed als ze de standaardgeneratoren gebruiken. Als u aangepaste generatoren heeft, probeer dan zoveel mogelijk logica naar C-bibliotheken zoals Numpy te pushen, omdat sommige van deze methoden eigenlijk laat de GIL vrij wat betekent dat u de mate van parallellisatie kunt verhogen. Een goede manier om te detecteren of u met GPU-gegevensgebrek wordt geconfronteerd, is door het GPU-gebruik te bewaken, maar wees gewaarschuwd dat dit niet de enige reden is om dat te observeren (de synchronisatie die plaatsvindt tijdens training over de meerdere GPU's is ook de schuld van een laag gebruik) ). Meestal kunnen GPU-gegevensgebrek worden gedetecteerd door GPU-bursts te observeren, gevolgd door lange pauzes zonder gebruik. In het verleden heb ik een open source-extensie voor Dstat geopend die u kan helpen uw GPU-gebruik te meten, dus kijk eens naar de origineel blogbericht.

4. Opslaan van uw parallelle modellen

Stel dat u de mutli_gpu_model-methode hebt gebruikt om uw model te paralleliseren, de training is voltooid en nu wilt u de gewichten behouden. Het slechte nieuws is dat je niet zomaar save () erop kunt aanroepen. Momenteel heeft Keras een beperking die u niet toestaat bewaar een parallel model. Er zijn 2 manieren om dit te omzeilen: bel de save () op de referentie van het originele model (de gewichten worden automatisch bijgewerkt) of je moet het model serialiseren door de parallelle versie te hakken en alle onnodige verbindingen op te ruimen. De eerste optie is veel gemakkelijker, maar in de toekomst ben ik van plan om een ​​serialize () -methode te openen die de laatste uitvoert.

5. Het tellen van de beschikbare GPU's heeft een nare bijwerking

Helaas is er op dit moment een vervelende bijwerking op de tensorflow.python.client.device_lib.list_local_devices () methode die ervoor zorgt dat er een nieuwe TensorFlow-sessie wordt aangemaakt en de initialisatie van alle beschikbare GPU's op het systeem. Dit kan leiden tot onverwachte resultaten, zoals het bekijken van meer GPU's dan gespecificeerd of het voortijdig initialiseren van nieuwe sessies (u kunt alle details hierover lezen pull-verzoek). Om soortgelijke verrassingen te voorkomen, wordt u aangeraden om in plaats daarvan de methode K.get_session (). List_devices () van Keras te gebruiken, waarmee u alle momenteel geregistreerde GPU's voor de sessie terugkrijgt. Last but not least, houd er rekening mee dat het aanroepen van de methode list_devices () op de een of andere manier duur is, dus als je alleen geïnteresseerd bent in het aantal beschikbare GPU's, bel de methode dan één keer en bewaar hun nummer op een lokale variabele.

Dat is het! Ik hoop dat je deze lijst nuttig vond. Als je andere valkuilen / tips voor GPU-training op Keras hebt gevonden, deel ze dan hieronder bij de opmerkingen. 🙂