Советы и рекомендации по оптимизации рабочих процессов с помощью TF и Horovod на графических процессорах

Авторы статьи: Ракшитх Васудев (Rakshith Vasudev) и Джон Локмен (John Lockman), HPC AI Innovation Lab, октябрь 2019 г.


Введение

Horovod — это распределенная платформа глубинного обучения для ускорения обучения на различных платформах глубинного обучения, таких как Tensorflow, Keras, Pytorch и MXNet. Платформа Horovod была разработана для упрощения разработки распределенных проектов глубинного обучения и ускорения их работы с помощью TensorFlow. Horovod поддерживает параллелизацию процесса обучения. Он поддерживает параллельность данных и параллельность моделей. При выполнении задания по обучению нейронной сети, которое использует horovod, можно использовать следующие общие рекомендации для отладки и повышения производительности.

Описание

В этой статье в качестве примера используется модель CheXNet. CheXNet — это модель ассистента рентгенолога на основе ИИ, которая использует DenseNet для идентификации до 14 патологий на изображении рентгена грудной клетки.

1. Правильная настройка среды может сэкономить много времени при устранении проблем производительности. Убедитесь, что используется версия графического процессора для платформы глубокого обучения. В этом примере используется графический процессор Tensorflow с пакетом Anaconda.
   
    

2. Использование horovodrun или mpirun параметрами привязки может повысить производительность. В идеальном случае процесс, управляющий графическим процессором, должен быть привязан к ближайшему гнезду ЦП. На сервере Dell EMC PowerEdge C4140 оптимальным вариантом будет процессор --map-by. Параметры привязки указывать не нужно.

   Команда будет выглядеть следующим образом: 

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

3. Задание должно быть настроено таким образом, чтобы на каждом графическом процессоре выполнялся один процесс MPI. Если количество процессов превышает количество графических процессоров, процессы будут конкурировать за вычислительные ресурсы и не смогут выполнять задания с хорошей производительностью. В приведенном выше примере число x должно быть равно количеству используемых графических процессоров.
   
    

4. Чтобы настроить выполнение одного процесса на каждом графическом процессоре, используйте параметры Tensorflow ConfigProto(), например:

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

5. Для проверки количества процессов, использующих графический процессор, и объема потребления памяти, используемой графическим процессором, можно использовать команду ‘watch nvidia-smi’. С помощью этой команды также можно получить сведения о потребляемой мощности.

   
   Рис. 1. Снимок экрана с выходными данными команды «nvidia-smi», включающими объем оперативной памяти, потребляемую мощность и использование графического процессора.
   
   
    
6. Если конвейер данных настроен правильно и параметры команды «mpirun» заданы верно, то после начала обучения модели использование графического процессора должно постоянно превышать величину в 90%. Допускается периодическое снижение использования до 10–25 %, но оно должно быть нечастым.
   
   
    
7. Задайте размер пакета таким образом, чтобы память графического процессора была почти заполнена, но ограничьте размер пакета, чтобы не превысить требования к памяти. Важно учитывать, каким образом выполняется масштабирование скорости обучения. Масштабирование скорости обучения — это концепция, согласно которой по мере увеличения количества графических процессоров скорость обучения также должна быть умножена на коэффициент, пропорциональный количеству графических процессоров. Это позволяет обеспечить сходимость модели. Таким образом, количество операций ввода-вывода сокращается за счет установки максимального числа изображений на каждый графический процессор без нарушения сходимости модели. Следует отметить, что масштабирование скорости обучения не всегда является наилучшим решением для улучшения сходимости моделей в распределенных рабочих нагрузках.
   Чтобы проверить, требуется ли масштабирование скорости обучения, выполните следующие действия:
   
   
   а)    обучите модель в распределенном режиме с масштабированием скорости обучения и без него.
   б)    если модель без масштабирования скорости обучения работает лучше, чем модель с масштабированием скорости обучения, то масштабирование скорости обучения не требуется. 
   
   
   В частности, при обучении сходимости достижение максимально возможного числа изображений в пакете не всегда является обязательным правилом. Обычно существует компромисс между размером пакета и сходимостью (независимо от того, используется ли масштабирование скорости обучения), к которому может прийти специалист по анализу данных в зависимости от сценария использования.
   Объем оперативной памяти, используемой графическим процессором, также можно просмотреть с помощью команды ‘watch nvidia-smi’.  В этом примере масштабирование скорости обучения не использовалось, так как это позволило получить улучшенную модель со значениями AUC и локальным размером minibatch, равным 64. Как правило, если используется масштабирование скорости обучения, рекомендуется включить «эпохи разогрева», как описано в этом документе.
   
    

8. Составьте профиль заданий с помощью команд horovod timeline и nvprof для определения возможных узких мест.  Узкие места скорее всего связаны с одним из следующих факторов:

   а)    настройка конвейера данных tf выполнена недостаточно хорошо, поэтому на подготовку данных затрачивается много времени, пока ускоритель находится в режиме ожидания. Чтобы устранить эту проблему, необходимо внести исправления в конвейер tf. 
   Чтобы узнать, как настроить конвейер данных tf, ознакомьтесь с этой статьей. 
   
   б)    возможно, для обмена данными используется неправильная фабрика — убедитесь, что используется фабрика InfiniBand, указав параметр –x NCCL_DEBUG=INFO при запуске «mpirun».
           mpirun -np 8 --map-by socket -x NCCL_DEBUG=INFO python $HOME/models/chexnet/chexnet.py  --batch_size=128   --epochs=15
           or use horovodrun which includes the –x binding.
   
   
    
9. Для правильной реализации распределения графические процессоры должны эффективно взаимодействовать друг с другом. Если они не взаимодействуют эффективно, это приводит к появлению узких мест. Чтобы проверить, насколько оптимально взаимодействуют графические процессоры, выполните следующие действия:
   
   Во-первых, посмотрите, как взаимодействуют графические процессоры, указав параметр -x binding, как описано выше в пункте 8b
   
   Если графические процессоры взаимодействуют:
   1) в пределах узла, оптимальное взаимодействие будет выглядеть следующим образом:  
   gpu002:1299562:1299573 [0] NCCL INFO Ring 00 : 0[0] -> 1[1] via P2P/IPC
    
   2) за пределами узла, оптимальное взаимодействие будет выглядеть следующим образом:
   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

• используются правильные варианты привязки;
• используется оценка нескольких процессов, которые не приводят к напрасному использованию памяти графического процессора;
• используется современный подход к организации конвейеров;
• используется профилирование, чтобы убедиться, что графические процессоры используются на протяжении не менее 80 % времени выполнения задания;
• используется последняя версия связанных библиотек CUDA.