Artikkelen er skrevet av Rakshith Vasudev og John Lockman – HPC AI Innovation Lab i oktober 2019
Som tidligereintrodusert er CheXNet en assistentmodell for AI-radiolog som benytter DenseNet til å identifisere opptil 14 patologier fra et gitt x ray-bilde i kabinettet. Flere tilnærminger ble utforsket for å skalere ut opplæringen av en modell som kunne yte like godt som eller bedre enn den opprinnelige CheXNet-121, med ResNet-50 som demonstrerer løfte om både skalerbarhet og økt opplæringsnøyaktighet (positiv AGUNC). Forfatterene demonstrerte skalerbarhet på CPU-systemer, men vi er interessert i å utnytte gpU-enes parallellitet for å akselerere opplæringsprosessen. I denne artikkelen beskriver vi beste praksis for å oppnå maksimal ytelse på distribuert skalerbar opplæring av CheXNet ved hjelp av Nvidia V100 SXM2 GPU-er i Dell EMC C4140-servere. Dell EMC PowerEdge C4140 gir både tetthet og ytelse med fire Nvidia V100 GPU-er i SXM2-konfigurasjon.
Maskinvarekonfigurasjon: | Programvarekonfigurasjon: |
---|---|
|
|
Siden nye dataenheter (for eksempel GPU-er og TPU-er) gjør det mulig å lære opp nevrale nettverk i stadig økende hastighet, er CPU-behandlingen utsatt for å bli flaskehalsen. tf.data-API-en gir brukerne byggeblokker for å utforme inndataforløp som effektivt bruker CPU-en, noe som optimerer hvert trinn i ETL-prosessen.
For å utføre et opplæringstrinn må du først pakke ut og omforme opplæringsdataene og deretter mate dem til en modell som kjører på en akselerator. Men i en napiv synkron implementering, mens CPU-en klargjør dataene, er akseleratoren inaktiv. Derimot, mens akseleratoren lærer modellen, sitter CPU-en inaktiv. Opplæringstrinntiden er dermed summen av både CPU-ens forhåndsbehandlingstid og akseleratoropplæringstiden
Pipelining overlapper preprosesseringen og modellutføringen av et opplæringstrinn. Mens akseleratoren utfører opplæringstrinn N, klargjør CPU-en dataene for trinn N+1. Dette reduserer trinntiden til det maksimale (i motsetning til summen) av opplæringen, og tiden det tar å pakke ut og transformere dataene.
Uten pipelining er CPU-en og GPU/TPU-en inaktiv mye av tiden:
Fig. 1: Sekvensiell utførelse etterlater ofte GPU-en inaktiv
Med pipelining reduseres inaktiv tid betraktelig:
Fig. 2: Pipelining overlapper CPU- og GPU-bruken, noe som maksimerer GPU-bruken
tf.data-API-en gir en pipeliningmekanisme for programvare gjennom tf.data.Dataset.prefetch-transformasjonen, som kan brukes til å koble fra tiden de bruker. Spesielt bruker transformasjonen en bakgrunnstråd og en intern buffer for å forhåndshenting av elementer fra inndatasettet før de blir bedt om det.
Mer informasjon her: https://www.tensorflow.org/guide/performance/datasets
Når man følger retningslinjene som leveres av tensorflow, er det mulig å få en dataforløp som ser slik ut (gammel tilnærming):
https://github.com/dellemc-hpc-ai/code-examples/blob/master/cheXNet-snippets/old_approach.py
I denne tilnærmingen, også kalt den gamle tilnærmingen, gjør tf data pipeline følgende (forutsatt at datasettet for kasse-x-ray er en sekvens av TFRecords):
Dette er imidlertid ikke den mest effektive koden. Det fører til stans og hyppige 0 % gpu-bruk. I utgangspunktet bruker den ikke akseleratorene effektivt.
For å konfigurere tf-data pipeline på riktig måte følger vi tilnærmingen som er tatt spesielt av tensorflow-offisielle modeller, den for ResNet. Forskjellen mellom den gamle tilnærmingen og den nye tilnærmingen er hvordan dataforløp konfigureres før den mates til modellen.
Slik ser den nye tilnærmingen ut:
https://github.com/dellemc-hpc-ai/code-examples/blob/master/cheXNet-snippets/new_approach.py
De offisielle TensorFlow-modellene kalles også en ny tilnærming:
Her er en sammenligning av ytelsen til både gamle og nye tilnærminger ved bruk av de offisielle TF-modellene.
Fig. 3: Med den nye tilnærmingen kan du forvente nær lineær skalering.
Som det kan ses, er det en betydelig ytelsestap, og det er ingen skalering i det hele tatt med den gamle tilnærmingen. GPU-er vil ofte oppleve lite eller ingen bruk, noe som fører til flat linje for ytelsen. Hvis kommunikasjonen håndteres på en måte, kan du gjøre databehandlingen mer effektiv på flere GPU-er på flere noder, hvis kommunikasjonen håndteres på en god måte.
Hvis CPU-ene gjør det parallelt med forhåndsbehandlingen, er det et annet aspekt å forhåndsbevege de behandlede dataene i minnet og GPU-ene som utfører tunge løft av matrisemultiplikasjon med rask kommunikasjon, noe som gjør denne nye tilnærmingen mer attraktive å skalere for flernoder.
Miljøet som kjører jobbene dine, er like viktig som jobbene dine, ettersom det å ha de riktige bibliotekene/modulene er viktig ettersom de vil påvirke opplæringsytelsen. De nyeste CUDA-relaterte bibliotekene kan også bidra til å forbedre ytelsen.
Følg denne opplæringen for å installere hvis du ikke har et arbeidsmiljøoppsett.
MPI er et kommunikasjonsbibliotek som bidrar til horovod for å distribuere jobber. Ulike parameteralternativer for binding og tilordning ble utforsket, og de beste parameterne for C4140 var tilordning etter sokkel. Den anbefalte innstillingen er som følger:mpirun --map-by socket -np x python pyfile.py --pyoptions
Hvis det er mer enn én prosess som fungerer på én gpu, kan de godt velge gpU-ressurser, forbruke GPU-minne og effektivt ikke tilpasse flere bilder per gruppe, og dermed ansvarlig for å få GPU-ytelsen til å bli rammet. Tensorflow 1.13.1 ble utforsket, men det var som om det hadde en feil på det tidspunktet. Den startet mer enn én prosess per GPU.
Oppsummert: