Vinkkejä työnkulun optimointiin grafiikkasuorittimissa TF:n ja Horovodin avulla

Artikkelin ovat kirjoittaneet HPC AI Innovation Labin Rakshith Vasudev ja John Lockman lokakuussa 2019.


Johdanto

Horovod on hajautetun syväoppimisen (Distributed Deep Learning) kehys, jonka tarkoituksena on nopeuttaa oppimista erilaisissa syväoppimiskehyksissä, joita ovat esimerkiksi Tensorflow, Keras, Pytorch ja MXNet. Se kehitettiin helpottamaan hajautettujen syväoppimisprojektien perustamista ja nopeuttamaan niiden edistymistä TensorFlow’n avulla. Horovod tukee oppimisprosessin rinnakkaisuutta. Se tukee sekä tietojen että mallin rinnakkaisuutta. Seuraavilla yleisluontoisilla vinkeillä voi korjata virheitä ja parantaa suorituskykyä, kun Horovodia käyttävä neuroverkon oppimistehtävä on käynnissä.

Kuvaus

Artikkelin esimerkkinä käytetään CheXNet-mallia. CheXNet on röntgenkuvauksen apuvälineenä käytettävä malli, joka voi tunnistaa DenseNet-arkkitehtuurin avulla jopa 14 patologista muutosta keuhkokuvasta.

1. Oikein määritetty ympäristö voi säästää huomattavasti aikaa korjatessa suorituskykyongelmia. Varmista, että syväoppimiskehyksen grafiikkasuoritinversio on käytössä. Tässä esimerkissä käytetään anaconda-pakattua tensorflow-gpu:ta.
   
    

2. Suorituskykyä voi parantaa käyttämällä horovodrun- tai mpirun-komentoa ja sitovia parametreja. Grafiikkasuoritinta ohjaava prosessi on mielellään sidottava lähimpään suorittimen kantaan. Optimaalinen asetus Dell EMC PowerEdge C4140 -järjestelmässä on --map-by socket. Sidonta-asetuksia ei tarvitse määrittää.

   Komento näyttää seuraavanlaiselta: 

   mpirun --map-by socket -np x python pyfile.py - -pyoptions
   
    

3. Tehtävä on määritettävä niin, että yhdessä grafiikkasuorittimessa on käynnissä yksi MPI-prosessi. Jos prosesseja on enemmän kuin grafiikkasuorittimia, ne joutuvat kilpailemaan laskentaresursseista, eikä niiden suorituskyky pysy hyvänä. Edellisessä esimerkissä x:n arvon on vastattava käytössä olevien grafiikkasuorittimien lukumäärää.
   
    

4. Määritä yksi prosessi grafiikkasuoritinta kohden käyttämällä Tensorflow’n ConfigProto()-komentoa seuraavasti:

   config.gpu_options.visible_device_list=str(hvd.local_size())
   
    

5. Grafiikkasuoritinta käyttävien prosessien lukumäärän ja grafiikkasuorittimen muistinkulutuksen voi tarkistaa ‘watch nvidia-smi’ -komennolla. Sen avulla voi tarkastella myös virrankulutusta.

   
   Kuva 1: Näyttökuva nvidia-smi-komennon tuloksista, joissa näkyy muistin- ja virrankulutus sekä grafiikkasuorittimen käyttöaste
   
   
    
6. Jos data pipeline -siirto on määritetty oikein ja mpirun-parametrit ovat oikeat, grafiikkasuorittimen käyttöasteen pitäisi olla oppimisen aikana jatkuvasti vähintään 90 %. Satunnaiset notkahdukset käyttöasteeseen 10–25 % ovat hyväksyttäviä, jos niitä ei tapahdu usein.
   
   
    
7. Määritä eräkoko niin, että grafiikkasuorittimen muisti on lähes täynnä, mutta muistivaatimukset eivät ylity. On tärkeää miettiä, miten oppimisnopeuden skaalaus saavutetaan. Oppimisnopeuden skaalaus tarkoittaa, että kun grafiikkasuorittimien lukumäärä lisääntyy, oppimisnopeuden on moninkertaistuttava grafiikkasuorittimien lukumäärää vastaavalla kertoimella. Näin malli voi konvergoitua tehokkaasti. Ominaisuuden ansiosta I/O-toimintojen lukumäärä vähenee, kun grafiikkasuoritin määritetään käsittelemään enimmäismäärä kuvia, mutta mallin konvergenssi ei kärsi. Huomioithan, että oppimisnopeuden skaalaus ei ole aina paras ratkaisu mallin konvergenssin nopeuttamiseen hajautetun kuorman ympäristössä.
   Tarkista seuraavasti, tarvitaanko oppimisnopeuden skaalausta:
   
   
   a)    Opeta malli hajautetusti ensin käyttäen ja sitten käyttämättä oppimisnopeuden skaalausta.
   b)    Jos oppimisnopeuden skaalausta käyttämättömän mallin suorituskyky on parempi kuin skaalausta käyttävän, skaalausta ei tarvita. 
   
   
   Tavoiteltaessa konvergenssia grafiikkasuoritinta ei tarvitse aina määrittää käsittelemään enimmäismäärää kuvia erää kohden. Yleensä on tingittävä joko eräkoosta tai konvergenssista (käytettiinpä oppimisnopeuden skaalausta tai ei), ja tietojenkäsittelijän on päätettävä tinkimisen kohde aina tapauskohtaisesti.
   Muista, että grafiikkasuorittimen muistinkulutusta voi tarkastella ‘watch nvidia-smi’-komennolla.  Tässä esimerkissä ei käytetty oppimisnopeuden skaalausta, sillä AUC-arvoilla saavutettiin parempi malli, ja lisäksi paikallinen minibatch-eräkoko oli 64. Kun oppimisnopeuden skaalaus on käytössä, oppimisessa on tavallista käyttää lämmittelyjaksoja tässä asiakirjassa kuvatulla tavalla.
   
    

8. Profiloi tehtävät horovod timeline- ja nvprof-toiminnoilla, jotta voit tarkastella mahdollisia pullonkauloja.  Pullonkaula johtuu todennäköisesti jostakin seuraavista tekijöistä:

   a)    Tf data pipeline -siirtoa ei ole määritetty oikein, joten tietojen valmisteluun kuluu paljon aikaa samalla, kun kiihdytin on käyttämättömänä. Tf pipeline -siirto on korjattava, jotta ongelma ratkeaa. 
   Tässä artikkelissa on ohjeet tf data pipeline -siirron määrittämiseen. 
   
   b)    Viestinnässä ei käytetä oikeaa verkkoa. Varmista, että InfiniBand-verkko on käytössä. Voit tarkastella käytössä olevaa verkkoa lisäämällä –x NCCL_DEBUG=INFO-tekstin mpirun-komentoon seuraavasti:
           mpirun -np 8 --map-by socket -x NCCL_DEBUG=INFO python $HOME/models/chexnet/chexnet.py  --batch_size=128   --epochs=15
           tai käytä horovodrun-toimintoa, joka sisältää –x bindingin.
   
   
    
9. Grafiikkasuorittimien on voitava viestiä tehokkaasti keskenään, jotta hajautus toimii tarkoituksenmukaisesti. Jos viestintä ei ole tehokasta, seurauksena on viestinnän pullonkaula. Tarkista viestinnän optimaalisuus seuraavan prosessin avulla:
   
   Tarkista ensiksi grafiikkasuorittimien viestintätiedot käyttämällä -x binding -toimintoa edellä kohdassa 8b kuvatulla tavalla.
   
   Jos grafiikkasuorittimet viestivät:
   1) optimaalisesti solmun sisällä, tulos näyttää seuraavanlaiselta:  
   gpu002:1299562:1299573 [0] NCCL INFO Ring 00 : 0[0] -> 1[1] via P2P/IPC
    
   2) optimaalisesti solmun ulkopuolella, tulos näyttää seuraavanlaiselta:
   gpu028:149460:149495 [0] NCCL INFO Ring 01 : 16 -> 0 [send] via NET/IB/0
   gpu009:164181:164216 [0] NCCL INFO Ring 01 : 12 -> 8 [receive] via NET/IB/0
   gpu009:164181:164216 [0] NCCL INFO Ring 01 : 4 -> 8 [receive] via NET/IB/0

• käytä oikeita sidonta-asetuksia
• tarkista, että prosessit eivät tuhlaa grafiikkasuorittimien muistia
• käytä nykyaikaista pipeline-tekniikkaa
• tarkista, että grafiikkasuorittimia käytetään vähintään 80 % tehtävän suorittamisajasta
• käytä uusimpia CUDA-kirjastoja.