Skip to main content
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Enjoy members-only rewards and discounts
  • Create and access a list of your products
  • Manage your Dell EMC sites, products, and product-level contacts using Company Administration.

CheXNet-koulutuksen optimointitekniikat Dell C4140:ssä Nvidia V100 -grafiikkasuorittimilla

Summary: Parhaat käytännöt, joilla saavutetaan enimmäissuorituskyky jaetussa skaalatussa CheXNetin koulutuksessa käyttäen Nvidia V100 SXM2 -grafiikkasuorittimia Dell EMC:n C4140-palvelimissa.

This article may have been automatically translated. If you have any feedback regarding its quality, please let us know using the form at the bottom of this page.

Article Content


Symptoms

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

Cause

  -

Resolution

Kuten aiemmin on kerrottu, CheXNet on röntgenkuvauksen apuvälineenä käytettävä malli, joka voi tunnistaa DenseNet-arkkitehtuurin avulla jopa 14 patologista muutosta keuhkokuvasta. Useita vaihtoehtoja tutkittiin, jotta saatiin skaalatuksi sellaisen mallin koulutus, joka toimisi vähintään yhtä hyvin kuin alkuperäinen CheXNet-121. ResNet-50 vaikutti lupaavalta sekä skaalautuvuuden että koulutuksen tarkkuuden suhteen (positiivinen AUROC). Tekijät esittelivät skaalautuvuutta suoritinjärjestelmissä, mutta meitä kiinnostaa grafiikkasuoritinten rinnakkaisuus koulutuksen nopeuttamiseksi. Tässä artikkelissa kuvataan parhaita käytäntöjä, joilla saavutetaan enimmäissuorituskyky jaetussa skaalatussa CheXNetin koulutuksessa käyttäen Nvidia V100 SXM2 -grafiikkasuorittimia Dell EMC:n C4140-palvelimissa. Dell EMC:n PowerEdge C4140 takaa sekä tiheyden että suorituskyvyn neljällä Nvidia V100 -grafiikkasuorittimella SXM2-kokoonpanossa.


 

Laitteistokokoonpano: Ohjelmiston määritys:
  • 4 PowerEdge C4140
  • 4 Nvidia V100 32 Gt:n SXM2
  • 2 20-ytimistä Intel(R) Xeon(R) Gold 6148 -suoritinta (2,40 GHz)
  • 384 Gt RAM-muistia, DDR4 2666 MHz
  • 1 Mellanox EDR HCA
  • Lustre-tiedostojärjestelmä
  • Syväoppimiskehys: tensorflow-gpu
  • Kehysversio: 1.12.0
  • Horovod-versio: 0.16.4
  • MPI-versio: 4.0.0 (cuda- ja ucx-tuki)
  • CUDA-versio: 10.1.105
  • CUDNN-versio: 7.6.0
  • NCCL-versio: 2.4.7
  • Python-versio: 3.6.8
  • Käyttöjärjestelmä versio: RHEL 7.4


 


Tietojen työjono on keskeisen tärkeä, jotta kiihdyttimet toimivat mahdollisimman tehokkaasti:



 

Mitä tf-tiedot ovat, miksi niitä kannattaa pyrkiä käyttämään?

 

Uusien laskentalaitteiden (kuten grafiikka- ja tensorisuoritinten) avulla neuraaliverkkoja pystytään kouluttamaan yhä nopeammin, joten suorittimen tekemästä laskennasta saattaa muodostua pullonkaula. Tf.data-ohjelmointirajapinta sisältää tarvittavat osat, joilla voi suunnitella syöttötyöjonoja, jotka käyttävät suoritinta tehokkaasti ja optimoivat kaikki ETL-prosessin vaiheet.

 

Jotta koulutusvaiheen voi tehdä, koulutustiedot on ensin purettava ja muunnettava, minkä jälkeen ne on syötettävä kiihdyttimessä toimivaan malliin. Kiihdytin on kuitenkin vapaana yksinkertaisessa synkronisessa käyttöönotossa, kun suoritin valmistelee tietoja. Vastaavasti suoritin on vapaana, kun kiihdytin kouluttaa mallia. Siten koulutusvaihe koostuu sekä suorittimen esikäsittelyajasta että kiihdyttimen koulutusajasta

 

Työjonotus limittää koulutusvaiheen esikäsittelyn ja mallin suorittamisen. Kun kiihdytin tekee koulutusvaihetta, suoritin valmistelee tietoja vaiheeseen N+1. Se nopeuttaa koulutusta sekä tietojen purkamista ja muuntamista.

 

Ilman työjonotusta suoritin ja grafiikka-/tensorisuoritin on enimmäkseen vapaana:

SLN318898_en_US__1Sequantial execution
Kuva 1: Peräkkäisessä suorituksessa grafiikkasuoritin on usein vapaana

 

Työjonotuksella aika vapaana vähenee merkittävästi:

SLN318898_en_US__2Pipelining overlaps
Kuva 2: Työjonotus limittää suorittimen ja grafiikkasuorittimen käytön ja maksimoi grafiikkasuorittimen käyttöasteen

 

Tf.data-ohjelmointirajapinta tarjoaa ohjelmiston työjonomekanismin muunnoksessa tf.data.Dataset.prefetch transformation, jolla voi irrottaa tietojen tuotantoajan tietojen käyttöajasta. Muunnos käyttää nimenomaisesti taustasäiettä ja sisäistä puskuria elementtien esihakuun syöttötietojoukosta ennen kuin niitä pyydetään.

 

Lisätietoja: https://www.tensorflow.org/guide/performance/datasets

 

Noudattamalla TensorFlow'n ohjeita saadaan tämänkaltainen tietojen työjono (vanha tapa):
https://github.com/dellemc-hpc-ai/code-examples/blob/master/cheXNet-snippets/old_approach.py

 

Tällä tavalla, jota kutsutaan myös vanhaksi tavaksi, tf-tietojen työjono toimii seuraavasti (olettaen, että keuhkokuvan tietojoukko sisältää TFRecords-tietueita):

 

  1. hakee tiedostonimien absoluuttisen luettelon
  2. luo tiedostonimien luettelosta tietojoukon TFRecordDataset()-toiminnolla
  3. luo uuden tietojoukon, joka lataa ja alustaa kuvia esikäsittelemällä
  4. sirpaloi tietojoukon
  5. sekoittaa tietojoukon koulutuksen aikana
  6. toistaa tietojoukon
  7. annostelee tietojoukon
  8. esihakee tietojoukon kohteelle batch_size.


 

Tämä ei ole kuitenkaan tehokkain koodi. Se aiheuttaa pysähdyksiä, ja grafiikkasuorittimen käyttöaste on usein 0 %. Se ei siis käytä kiihdyttimiä tehokkaasti.

Jotta tf-tietojen työjono voidaan määrittää oikein, toimitaan TensorFlow'n virallisten mallien (tarkemmin ResNet-mallin) mukaisesti.  Vanhan ja uuden tavan ero on siinä, miten tietojen työjono määritetään ennen sen syöttämistä malliin.

 

Uusi tapa näyttää tältä:
https://github.com/dellemc-hpc-ai/code-examples/blob/master/cheXNet-snippets/new_approach.py

 

TensorFlow'n virallinen eli uusi tapa:

 

  1. hakee tiedostonimien absoluuttisen luettelon
  2. luo tiedostonimien luettelosta tietojoukon from_tensor_slices()-toiminnolla
  3. sirpalointi tehdään etukäteen
  4. tietojoukko sekoitetaan koulutuksen aikana
  5. tietojoukosta luodaan TFRecord-tietojoukko rinnakkaisella lomituksella, mikä tarkoittaa usean tiedoston lomitusta (määrityksenä cycle_length)
  6. tietojoukko esihaetaan buffer_size määrittää, miten paljon tietueita esihaetaan, mikä on tavallisesti työn mini batch_size
  7. tietojoukko sekoitetaan uudelleen sekoituksen tietoja hallinnoi buffer_size
  8. tietojoukko toistetaan  tietojoukkoa toistetaan koulutuksessa num_epochs saakka
  9. tietojoukolle tehdään samanaikaisesti map_and_batch(), joka jäsentää tf-tietuetiedostot, minkä jälkeen kuvat esikäsitellään ja annostellaan
  10. esikäsitelty kuva on valmis tietojoukko, ja se esihaetaan uudelleen.


 

Tässä vertaillaan vanhan ja uuden tavan suorituskykyä käyttäen TF Official -malleja.

SLN318898_en_US__3image(12053)
Kuva 3: Uudella tavalla skaanaus on lähes lineaarinen.

 

Kuten huomataan, vanhalla tavalla suorituskyky on merkittävästi heikompi eikä skaalausta ole. Grafiikkasuorittimet ovat usein vähäisellä käytöllä tai vapaina, mikä laskee suorituskyvyn erittäin alas. Jos tiedonsiirtoa käsitellään hyvin, laskennan tehostaminen yhdessä grafiikkasuorittimessa tehostaa sitä usean solmun useassa grafiikkasuorittimessa.
Kun suorittimet tekevät esikäsittelyn rinnakkain, käsitellyt tiedot esihaetaan muistiin ja grafiikkasuorittimet hoitavat raskaimman kuorman eli matriisin kertauksen nopein yhteyksin, tämä uusi tapa vaikuttaa selvästi houkuttelevammalta usean solmun järjestelmissä.


 


Muita tekniikoita suorituskyvyn optimoimiseen:



 

Oikeanlainen ympäristö on tärkeä:

 

Ympäristö, jossa töitä suoritetaan, on yhtä tärkeä kuin itse työt, koska oikeat kirjastot/moduulit vaikuttavat koulutuksen suorituskykyyn. Myös uusimmat CUDAan liittyvät kirjastot voivat parantaa suorituskykyä.

Asenna tämän ohjeen mukaan, jos toimivaa ympäristöä ei ole määritetty.



 

Oikeiden MPI-sidontaparametrien käyttäminen:

 

MPI on viestintäkirjasto, joka auttaa Horovodia jakamaan töitä. Erilaisia sidonta- ja yhdistämisparametrien vaihtoehtoja tutkittiin, ja paras parametri C4140:lle oli yhdistäminen kannan mukaan. Suositeltu asetus:
mpirun --map-by socket -np x python pyfile.py --pyoptions



 

Varmista, että yksi prosessi toimii yhdessä grafiikkasuorittimessa:

 

Jos samassa grafiikkasuorittimessa on käynnissä useita prosesseja, ne todennäköisesti kilpailevat grafiikkasuorittimen resursseista, käyttävät grafiikkasuorittimen muistia eivätkä saa mahdutetuksi kuhunkin erään enempää kuvia, ja tämä kaikki heikentää grafiikkasuorittimen suorituskykyä. Tensorflow 1.13.1 -versiota tutkittiin, mutta siinä näytti olevan vikaa. Se käynnisti useita prosesseja kussakin grafiikkasuorittimessa.


 

Yhteenveto:

  • tietojen työjonon oikea määritys on keskeisen tärkeää suorituskyvyn parantamisen kannalta
  • oikean ympäristön määrittäminen voi parantaa suorituskykyä huomattavasti
  • oikeiden MPI-sidontaparametrien käyttäminen parantaa suorituskykyä
  • selvitä ja korjaa pullonkaulat, jos grafiikkasuorittimet eivät ole täysin käytössä.


 


Article Properties


Affected Product

High Performance Computing Solution Resources, Poweredge C4140

Last Published Date

17 Sep 2021

Version

5

Article Type

Solution