5 tips for multi-GPU-trening med Keras

• Januar 21, 2018
• Vasilis Vryniotis
• . 1 kommentar

Deep Learning (favorittordet på slutten av 2010-tallet sammen med blockchain / bitcoin og Data Science / Machine Learning) har gjort det mulig for oss å gjøre noen veldig kule ting de siste årene. Annet enn fremskrittene innen algoritmer (som riktignok er basert på ideer som allerede er kjent siden 1990-tallet, alias "Data Mining era"), kan hovedårsakene til suksessen tilskrives tilgjengeligheten av store gratis datasett, innføringen av open source-biblioteker og bruk av GPUer. I dette blogginnlegget vil jeg fokusere på de to siste, og jeg vil dele med deg noen tips som jeg lærte på den harde måten.

Hvorfor TensorFlow & Keras?

tensorflow er et veldig populært Deep Learning-bibliotek utviklet av Google som lar deg prototype raskt komplekse nettverk. Den kommer med mange interessante funksjoner som automatisk differensiering (som sparer deg for å estimere / kode gradientene til kostnadsfunksjonene) og GPU-støtte (som lar deg enkelt få en 200 ganger hastighetsforbedring ved å bruke anstendig maskinvare). Videre har det et Python-grensesnitt som betyr at du kan prototype raskt uten å måtte skrive C- eller CUDA-kode. Riktignok er det mange andre rammer man kan bruke i stedet for TensorFlow, for eksempel Torch, MXNet, Theano, Caffe, Deeplearning4j, CNTK, etc, men alt koker ned til brukssaken og din personlige preferanse.

Men hvorfor Keras? For meg å bruke direkte er TF som å gjøre Machine Learning with Numpy. Ja, det er mulig og fra tid til annen må du gjøre det (spesielt hvis du skriver tilpassede lag / tap-funksjoner), men vil du virkelig skrive kode som beskriver de komplekse nettverkene som en serie vektoroperasjoner (ja, jeg vet det er metoder på høyere nivå i TF, men de er ikke så kule som Keras)? Hva også om du vil flytte til et annet bibliotek? Vel, du vil sannsynligvis trenge å skrive om koden, som suger. Ta ta taaa, Keras til unnsetning! Keras lar deg beskrive nettverkene dine ved hjelp av begreper på høyt nivå og skrive kode som er agendistisk backend, noe som betyr at du kan kjøre nettverkene på tvers av forskjellige dype læringsbiblioteker. Få ting jeg liker med Keras er at den er velskrevet, den har en objektorientert arkitektur, den er lett å bidra og den har et vennlig samfunn. Hvis du liker det, si takk til Francois Chollet for å utvikle den og åpne sourcing.

Tips og Gotchas for Multi-GPU-trening

Uten videre, la oss gå til noen tips om hvordan du får mest mulig ut av GPU-trening på Keras og et par gotchas som du bør ha i bakhodet:

1. Multi-GPU-opplæring er ikke automatisk

Treningsmodeller på GPU ved bruk av Keras & Tensorflow er sømløse. Hvis du har et NVIDIA-kort og har installert CUDA, vil bibliotekene automatisk oppdage det og bruke det til trening. Så kult! Men hva om du er en bortskjemt brat og har flere GPUer? Vel, dessverre må du jobbe litt for å oppnå multi-GPU-trening.

Det er flere måter å parallellisere et nettverk avhengig av hva du vil oppnå, men de to viktigste tilnærmingene er modell- og dataparallellisering. Den første kan hjelpe deg hvis modellen din er for kompleks til å passe i en enkelt GPU, mens sistnevnte hjelper når du vil øke hastigheten på utførelsen. Vanligvis når folk snakker om multi-GPU-trening, mener de sistnevnte. Det pleide å være vanskeligere å oppnå, men heldigvis har Keras nylig tatt med en verktøymetode kalt mutli_gpu_model som gjør parallell trening / spådommer lettere (foreløpig bare tilgjengelig med TF-backend). Hovedideen er at du sender modellen din gjennom metoden, og den kopieres over forskjellige GPUer. Den originale inngangen er delt inn i biter som mates til de forskjellige GPUene, og deretter blir de samlet som en enkelt utgang. Denne metoden kan brukes for å oppnå parallell trening og spådommer, men husk at den for trening ikke skaleres lineært med mengden GPUer på grunn av den nødvendige synkroniseringen.

2. Vær oppmerksom på batchstørrelsen

Når du gjør trening med flere GPUer, vær oppmerksom på batchstørrelsen, siden den har flere effekter på hastighet / minne, konvergens av modellen din, og hvis du ikke er forsiktig, kan du ødelegge modellvektene!

Hastighet / minne: Åpenbart jo større batch jo raskere trening / spådom. Dette er fordi det er en overhead på å sette inn og ta ut data fra GPU-ene, så små grupper har mer overhead. På baksiden, jo større batch jo mer minne trenger du i GPUen. Spesielt under trening holdes inngangene til hvert lag i minnet ettersom det kreves på tilbakespredningstrinnet, så å øke batchstørrelsen for mye kan føre til feil utenfor minnet.

Konvergens: Hvis du bruker Stochastic Gradient Decent (SGD) eller noen av dens varianter for å trene modellen din, bør du huske på at batchstørrelsen kan påvirke nettverkets evne til å konvergere og generalisere. Typiske batchstørrelser i mange problemer med datasyn er mellom 32 og 512 eksempler. Som Keskar et al si det, "Det er blitt observert i praksis at når man bruker et større parti (enn 512), er det en forringelse av kvaliteten på modellen, målt ved dens evne til å generalisere.". Vær oppmerksom på at andre forskjellige optimaliserere har forskjellige egenskaper, og spesialiserte distribuerte optimaliseringsteknikker kan hjelpe deg med problemet. Hvis du er interessert i de matematiske detaljene, anbefaler jeg å lese Joeri Hermans avhandling “På skalerbar dyp læring og parallellisering av gradientnedstigning".

Å ødelegge vektene: Dette er en ekkel teknisk detalj som kan ha ødeleggende resultater. Når du trener med flere GPUer, er det viktig å mate alle GPUene med data. Det kan skje at den siste batchen av epoken din har mindre data enn definert (fordi størrelsen på datasettet ditt ikke kan deles nøyaktig etter størrelsen på batchen din). Dette kan føre til at noen GPUer ikke mottar data i løpet av det siste trinnet. Dessverre kan noen Keras-lag, spesielt batch-normaliseringslaget, ikke takle det som fører til nanverdier som vises i vektene (det løpende gjennomsnittet og variansen i BN-laget). For å gjøre tingene enda styre, vil man ikke observere problemet under trening (mens læringsfasen er 1) fordi det spesifikke laget bruker batchens gjennomsnitt / varians i estimatene. Likevel under spådommer (læringsfase satt til 0) brukes løpende gjennomsnitt / varians som i vårt tilfelle kan bli nan som fører til dårlige resultater. Så gjør deg selv en tjeneste og sørg alltid for at batchstørrelsen din er løst når du trener med flere GPUer. To enkle måter å oppnå dette på er enten ved å avvise grupper som ikke samsvarer med den forhåndsdefinerte størrelsen, eller gjenta postene i batchen til du når den forhåndsdefinerte størrelsen. Sist men ikke minst husk at i et multi-GPU-oppsett, bør batchstørrelsen være et multiplum av antall tilgjengelige GPUer på systemet ditt.

3. GPU-data Starvation, altså CPU-ene, kan ikke følge med GPU-ene

Vanligvis er den dyreste delen under trening / forutsigelse av dype nettverk estimeringen som skjer på GPU-ene. Dataene er forhåndsbehandlet i CPU-ene i bakgrunnen, og de mates til GPU-ene med jevne mellomrom. Likevel skal man ikke undervurdere hvor raske GPU-ene er; det kan skje at hvis nettverket ditt er for grunt eller forhåndsbehandlingstrinnet er for komplisert at prosessorer ikke kan følge med GPU-ene, eller med andre ord, gir de dem ikke data raskt nok. Dette kan føre til lav GPU-utnyttelse som oversettes til bortkastede penger / ressurser.

Keras utfører vanligvis estimeringene av batchene parallelt, men på grunn av Pythons GIL (Global Interpreter Lock) kan du ikke virkelig oppnå ekte multitråding i Python. Det er to løsninger for det: enten bruk flere prosesser (merk at det er mange gotchas i denne som jeg ikke kommer til å dekke her) eller hold forhåndsbehandlingstrinnet enkelt. Tidligere har jeg sendt en Pull-Request på Keras for å lindre noe av den unødvendige belastningen vi satte på CPU-ene under forbehandling av Image, så de fleste brukere bør ikke bli berørt hvis de bruker standardgeneratorene. Hvis du har tilpassede generatorer, kan du prøve å skyve så mye logikk som mulig til C-biblioteker som Numpy fordi noen av disse metodene faktisk slipp GIL noe som betyr at du kan øke graden av parallellisering. En god måte å oppdage om du står overfor GPU-sult, er å overvåke GPU-bruken. Ikke desto mindre blir du advart om at dette ikke er den eneste grunnen til å observere at (synkroniseringen som skjer under trening på tvers av flere GPUer, er også skyld i lav utnyttelse ). Vanligvis kan GPU-sult oppdages ved å observere GPU-utbrudd etterfulgt av lange pauser uten bruk. Tidligere har jeg åpent en utvidelse for Dstat som kan hjelpe deg med å måle GPU-bruken din, så ta en titt på opprinnelig blogginnlegg.

4. Lagre dine parallelle modeller

Si at du brukte mutli_gpu_model-metoden for å parallellisere modellen din, opplæringen var ferdig, og nå vil du fortsette vektene. Den dårlige nyheten er at du ikke bare kan ringe lagre () på den. For øyeblikket har Keras en begrensning som ikke tillater deg lagre en parallell modell. Det er to måter å gjøre dette på: enten ring lagringen () på referansen til den opprinnelige modellen (vektene oppdateres automatisk), eller du må serialisere modellen ved å hugge ned den parallelle versjonen og rydde opp i alle unødvendige tilkoblinger. Det første alternativet er enklere, men i fremtiden planlegger jeg å åpne en kildekode () -metode som utfører sistnevnte.

5. Å telle tilgjengelige GPUer har en ekkel bivirkning

Dessverre er det for øyeblikket en stygg bivirkning på metoden tensorflow.python.client.device_lib.list_local_devices () som fører til at en ny TensorFlow-økt opprettes og initialiseringen av alle tilgjengelige GPUer på systemet. Dette kan føre til uventede resultater som å se på flere GPUer enn spesifisert eller initialisere nye økter for tidlig (du kan lese alle detaljene om dette pull-forespørsel). For å unngå lignende overraskelser, anbefales det at du bruker Keras 'K.get_session (). List_devices () -metode i stedet, som gir deg alle de nåværende registrerte GPU-ene på økten. Sist men ikke minst, husk at det å ringe til list_devices () -metoden er på en eller annen måte dyrt, så hvis du bare er interessert i antall tilgjengelige GPUer, ring metoden en gang og lagre nummeret på en lokal variabel.

Det er det! Håper du fant denne listen nyttig. Hvis du fant andre gotchas / tips for GPU-trening på Keras, kan du dele dem nedenfor på kommentarene. 🙂