Artiklen er skrevet af Rakshith Vasudev og John Lockman - HPC AI Innovation Lab i oktober 2019
Som introduceret tidligereer CheXNet en AI-radiologassistentmodel, der bruger DenseNet til at identificere op til 14 patologier ud fra et givent diagnost x ray-billede. Flere metoder blev undersøgt for at udskalere undervisningen af en model, der kunne fungere lige så godt som eller bedre end den oprindelige CheXNet-121 med ResNet-50, som har et løfte om både skalerbarhed og øget indlæringsgengivelse (positiv AUROC). Forfatterene demonstrerede skalerbarhed på CPU-systemer, men vi er interesserede i at udnytte GPU'ens parallelitet til at fremskynde indlæringsprocessen. I denne artikel beskriver vi best practices for at opnå maksimal ydeevne på distribueret skalering af CheXNet, der anvender Nvidia V100 SXM2 GPU'er i Dell EMC C4140-servere. Dell EMC PowerEdge C4140 giver både tæthed og ydeevne med fire Nvidia V100 GPU'er i SXM2-konfigurationen.
Hardwarekonfiguration: | Softwarekonfiguration: |
---|---|
|
|
Da nye databehandlingsenheder (f.eks. GPU'er og TPU'er) gør det muligt at uddanne neurale netværk i stadig hurtigere hastighed, er CPU-behandling udsat for at blive flaskehalsen. tf.data API giver brugerne byggeklodser til at designe inputpipelines, der effektivt udnytter CPU'en og optimerer hvert trin i ETL-processen.
For at udføre et undervisningstrin skal du først udtrække og transformere undervisningsdataene og derefter overføre dem til en model, der kører på en accelerator. I en na ive synkron implementering, mens CPU'en forbereder dataene, er acceleratoren imidlertid inaktiv. Og omvendt, mens acceleratoren uddanner modellen, er CPU'en inaktiv. Indlæringstrinet er således summen af både CPU'ens indledende behandlingstid og acceleratorens træningstid
Pipelining overlapper forbehandling og modeludførelse af et undervisningstrin. Mens acceleratoren udfører undervisningstrin N, forbereder CPU'en dataene til trin N+1. Hvis du gør det, reduceres trintiden til det maksimale (i modsætning til summen) for undervisningen, og den tid det tager at udtrække og transformere data.
Uden rørledning er CPU'en og GPU/TPU'en inaktive det meste af tiden:
Fig. 1: Sekventiel udførelse efterlader ofte GPU'en inaktiv
Med pipelining formindskes den ledige tid betydeligt:
Fig. 2: Pipelining overlapper CPU- og GPU-udnyttelse og maksimerer GPU-udnyttelse
tf.data API giver en software-pipelining-mekanisme gennem tf.data.Dataset.prefetch-transformationen, som kan bruges til at frakoble den tid, som data produceres fra det tidspunkt, de forbruges. Specifikt bruger transformationen en baggrundstråd og en intern buffer til at forhåndsforene elementer fra inputdatasættet, før de bliver anmodet om det.
Flere oplysninger her: https://www.tensorflow.org/guide/performance/datasets
Når man følger retningslinjer fra tensorflow, er det muligt at få en datapipeline, der ser sådan ud (gammel tilgang):
https://github.com/dellemc-hpc-ai/code-examples/blob/master/cheXNet-snippets/old_approach.py
I denne tilgang, også kaldet den gamle tilgang, gør tf-datapipeline følgende (forudsat, at symptom x ray-datasættet er en sekvens af TF-moduler):
Dette er imidlertid ikke den mest performant kode. Det medfører går i stå og hyppige 0 % gpu-udnyttelser. Den udnytter grundlæggende ikke acceleratorerne effektivt.
For at konfigurere tf-datapipeline korrekt følger vi den tilgang, der er udført af tensorflow officielle modeller specifikt, den for ResNet. Forskellen mellem den gamle tilgang og den nye tilgang er, hvordan datapipeline er konfigureret, før den leveres til modellen.
Sådan ser den nye tilgang ud:
https://github.com/dellemc-hpc-ai/code-examples/blob/master/cheXNet-snippets/new_approach.py
De officielle TensorFlow-modeller kaldes også for en ny tilgang og er som følger:
Her er en sammenligning af ydeevnen af både den gamle og den nye tilgang ved hjælp af de officielle TF-modeller.
Fig. 3: Med den nye tilgang kan man forvente tæt på lineær skalering.
Som det kan ses, er der et betydeligt resultat, og der er slet ikke nogen skalering med den gamle tilgang. GPU'er vil ofte opleve kun lidt eller ingen udnyttelse, hvilket medfører en flad ydeevne. Hvis beregning gøres mere effektiv på én GPU, betyder det, at beregning gøres mere effektiv på flere GPU'er på flere noder, hvis kommunikationen håndteres korrekt.
Hvis CPU'er udfører den indledende behandling parallelt, er forudfastgørelse af de behandles data i hukommelsen &GPU'er, der gør det hårde arbejde med matrixmultiplikering med hurtig kommunikation et andet aspekt, der gør denne nye tilgang mere attraktive at skalere for flerenoder.
Det miljø, der kører dine job, er lige så vigtigt som dine job, da det at have de rigtige biblioteker/moduler er vigtigt, da de vil påvirke undervisningens ydeevne. Desuden kan de nyeste CUDA-relaterede biblioteker hjælpe med at forbedre ydeevnen.
Følg dette selvstudium for at installere, hvis du ikke har en opsætning af arbejdsmiljøet.
MPI er et kommunikationsbibliotek, der svarer horovod til at distribuere job. Forskellige bindings- og tilknytningsparameterindstillinger blev undersøgt, og de bedste parametre for C4140 blev kortlagt efter sokkel. Den anbefalede indstilling er som følger:mpirun --map-by socket -np x python pyfile.py --pyoptions
Hvis der er mere end én proces, der fungerer med én GPU, kan de meget godt være på udkig efter GPU-ressourcer, der bruger GPU-hukommelse og effektivt ikke monterer flere billeder pr. batch, således at de er ansvarlige for at få GPU'ens ydeevne til at tage et hit. Tensorflow 1.13.1 blev udforsket, men det føles, som om der var en fejl på det tidspunkt. Den startede mere end én proces pr. GPU.
Opsummeret: