Tipy a triky pro optimalizaci pracovního postupu s platformou TF a Horovod na GPU

Článek napsali Rakshith Vasudev a John Lockman – HPC AI Innovation Lab v říjnu 2019


Úvod

Horovod je distribuovaný rámec hlubokého učení, který urychluje učení v různých rámcích hlubokého učení, jako je Tensorflow, Keras, Pytorch a MXNet. Byl vyvinut tak, aby usnadnil vytváření distribuovaných projektů hlubokého učení a urychlil je pomocí softwaru TensorFlow. Horovod podporuje paralelizaci procesu učení. Podporuje paralelizaci dat i modelu. Pokud je spuštěna síťová úloha neurálního učení, která využívá Horovod, lze tyto běžné tipy použít k ladění a zlepšení výkonu.

Popis

Tento článek používá CheXNet jako příklad pro referenci. CheXNet je model AI asistenta rentgenu, který využívá síť DenseNet k identifikaci až 14 patologií z daného rentgenového snímku hrudníku.

1. Správné nastavení prostředí může při ladění problémů s výkonem ušetřit spoustu času. Ujistěte se, že používáte verzi platformy hlubokého učení pro grafickou kartu. V tomto příkladu se používá balíček tensorflow-gpu od společnosti anaconda.
   
    

2. Použitím horovodrun nebo mpirun s parametry vazby lze dosáhnout vyššího výkonu. V ideálním případě by měl být proces ovládající GPU navázán na nejbližší patici CPU. Na serveru Dell EMC PowerEdge C4140 je optimální možností „--map-by socket“. Není nutné zadávat žádné volby vazby.

   Bude vypadat přibližně takto: 

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

3. Úloha by měla být nastavená tak, aby na jedné grafické kartě běžel jeden proces MPI. Pokud máte více procesů než grafických karet, budou se procesy přetahovat o výpočetní výkon a nebudou moci provést úlohu s dobrým výkonem. Ve výše uvedeném příkladu by x mělo být stejné číslo jako počet použitých grafických karet.
   
    

4. K nastavení jednoho procesu na jednu grafickou kartu použijte příkaz ConfigProto():

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

5. Ke kontrole počtu procesů využívajících grafickou kartu a její paměť lze použít příkaz watch nvidia-smi. To také umožňuje sledovat spotřebu energie.

   
   Obrázek 1: Snímek obrazovky s výstupem příkazu nvidia-smi zobrazující využití paměti, výkonu a využití grafické karty.
   
   
    
6. Pokud je datový kanál správně nastaven a parametry mpirun jsou správné, využití grafické karty by po zahájení modelového učení nemělo klesnout pod 90 %. Občasné poklesy na využití 10–25 % jsou přijatelné, ale neměly by být pravidelné.
   
   
    
7. Nastavte velikost dávky tak, aby paměť GPU byla téměř zaplněna, ale omezena tak, aby nebyly překročeny požadavky na paměť. Berte v úvahu způsob, jakým se provádí škálování rychlosti učení. Škálování rychlosti učení je koncept, podle kterého se s rostoucím počtem GPU musí vynásobit také rychlost učení koeficientem odpovídajícím počtu grafických karet. To umožňuje efektivní konvergenci modelu. Tímto způsobem se sníží počet operací I/O přizpůsobením maximálního počtu možných obrazů na GPU, aniž by došlo ke snížení konvergence modelu. Je třeba poznamenat, že škálování rychlosti učení není vždy nejlepším řešením pro zlepšení konvergence modelu v distribuovaném pracovním zatížení.
   Chcete-li zkontrolovat, zda je škálování rychlosti učení potřebné:
   
   
   a)    Učte model se škálováním rychlosti učení a bez něj v distribuovaném režimu.
   b)    Pokud model bez škálování rychlosti učení podává lepší výkon než model se škálováním, škálování rychlosti učení není potřebné. 
   
   
   Zejména při učení na konvergenci není vždy povinné umístit co nejvyšší možný počet snímků na dávku. Obvykle existuje kompromis mezi velikostí dávky a konvergencí (ať už se škálování rychlosti učení používá nebo ne), kdy se datový vědec musí rozhodnout na základě svého způsobu použití.
   Znovu se můžete podívat na využití paměti grafické karty pomocí příkazu watch nvidia-smi.  V této případové studii nebylo použito škálování rychlosti učení, protože bylo dosaženo lepšího modelu s hodnotami AUC a velikost místní dávky minibatch byla 64. Při použití škálování rychlosti učení se obvykle používá doba zahřívání, jak je popsáno v tomto dokumentu.
   
    

8. Profilujte své úlohy pomocí příkazu horovod timeline a nvprof, které použijte pro zobrazení případných kritických bodů.  Kritický bod je nejpravděpodobněji způsoben jedním z následujících důvodů:

   a)    Datový kanál tf není správně nastaven, a proto strávíte spoustu času přípravou dat, zatímco akcelerátor zůstane nečinný. Tento problém vyřešíte opravou příkazu kanálu tf. 
   Přečtěte si tento článek, kde jsou uvedeny informace o nastavení datového kanálu tf. 
   
   b)    Komunikace nemusí používat správnou topologii Fabric – ujistěte se, že používáte InfiniBand, abyste viděli využití topologie, použijte příkaz –x NCCL_DEBUG=INFO při spuštění parametru mpirun:
           mpirun -np 8 --map-by socket -x NCCL_DEBUG=INFO python $HOME/models/chexnet/chexnet.py  --batch_size=128   --epochs=15
           nebo použijte příkaz horovodrun s vazbou –x.
   
   
    
9. Aby bylo možné správně implementovat distribuci, grafické karty musí navzájem efektivně komunikovat. Pokud nekomunikují efektivně, dochází k překážce v komunikaci. Pro kontrolu optimální komunikace použijte následující postup:
   
   Nejprve se podívejte, jak grafické karty komunikují pomocí vazby -x, jak je uvedeno výše v bodu 8b.
   
   Pokud grafické karty komunikují:
   1) V rámci uzlu bude optimálně vypadat přibližně takto:  
   gpu002:1299562:1299573 [0] NCCL INFO Ring 00 : 0[0] -> 1[1] via P2P/IPC
    
   2) Mimo uzel bude optimálně vypadat přibližně takto:
   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

• jsou implementovány správné možnosti vazby,
• vyhodnocení více procesů, které neplýtvají pamětí GPU,
• využití moderního postupu pipeliningu,
• vytváření profilů pro zobrazení, že GPU jsou při spuštění úlohy využity alespoň 80 % doby,
• použití nejnovějších knihoven souvisejících s architekturou CUDA.