Распределенное обучение с Amazon EKS и Torch Distributed Elastic

Распределенное обучение модели глубокого обучения становится все более важным, поскольку объемы данных растут во многих отраслях. Многие приложения в области компьютерного зрения и обработки естественного языка в настоящее время требуют обучения моделей глубокого обучения, сложность которых растет в геометрической прогрессии и которые часто обучаются на сотнях терабайт данных. Затем становится важным использовать обширную облачную инфраструктуру для масштабирования обучения таких больших моделей.

Разработчики могут использовать платформы с открытым исходным кодом, такие как PyTorch, для простого проектирования интуитивно понятных архитектур моделей. Однако масштабирование обучения этих моделей на нескольких узлах может быть затруднено из-за повышенной сложности оркестровки.

Обучение распределенной модели в основном состоит из двух парадигм:

• Параллельная модель – При параллельном обучении модели сама модель настолько велика, что не может поместиться в памяти одного графического процессора, а для обучения модели необходимо несколько графических процессоров. Хорошим примером этого является модель Open AI GPT-3 со 175 миллиардами обучаемых параметров (размером примерно 350 ГБ).
• Параллельные данные – При параллельном обучении данных модель может располагаться на одном графическом процессоре, но из-за большого объема данных на обучение модели могут уйти дни или недели. Распределение данных по нескольким узлам GPU может значительно сократить время обучения.

В этом посте мы предоставляем пример архитектуры для обучения моделей PyTorch с использованием Распределенная эластичная горелка фреймворк в распределенном параллельном режиме данных с использованием Амазон Эластик Кубернетес Сервис (Амазон ЭКС).

Предпосылки

Чтобы воспроизвести результаты, описанные в этом посте, единственным предварительным условием является учетная запись AWS. В этой учетной записи мы создаем кластер EKS и Amazon FSx для блеска файловая система. Мы также помещаем образы контейнеров в Реестр Amazon Elastic Container (Amazon ECR) репозиторий в учетной записи. Инструкции по настройке этих компонентов предоставляются по мере необходимости на протяжении всей публикации.

Кластеры EKS

Amazon EKS — это управляемый контейнерный сервис для запуска и масштабирования приложений Kubernetes на AWS. С помощью Amazon EKS вы можете эффективно выполнять распределенные задания по обучению, используя новейшие Эластичное вычислительное облако Amazon (Amazon EC2) без необходимости устанавливать, эксплуатировать и поддерживать собственную плоскость управления или узлы. это популярный оркестратором для машинного обучения (ML) и рабочих процессов ИИ. Типичный кластер EKS в AWS выглядит следующим образом.

Мы выпустили проект с открытым исходным кодом, AWS DevOps для EKS (aws-do-eks), который предоставляет большой набор простых в использовании и настраиваемых сценариев и инструментов для подготовки кластеров EKS и выполнения распределенных учебных заданий. Этот проект построен по принципам Сделать фреймворк: Простота, гибкость и универсальность. Вы можете настроить желаемый кластер с помощью экс.конф файл, а затем запустите его, запустив экс-create.sh сценарий. Подробные инструкции приведены в Репо GitHub.

Обучайте модели PyTorch с помощью Torch Distributed Elastic

Torch Distributed Elastic (TDE) — это собственная библиотека PyTorch для обучения крупномасштабных моделей глубокого обучения, где критически важно динамически масштабировать вычислительные ресурсы в зависимости от доступности. Контроллер TorchElastic для Kubernetes — это нативная реализация Kubernetes для TDE, которая автоматически управляет жизненным циклом модулей и сервисов, необходимых для обучения TDE. Это позволяет динамически масштабировать вычислительные ресурсы во время обучения по мере необходимости. Он также обеспечивает отказоустойчивое обучение, восстанавливая задания после сбоя узла.

В этом посте мы обсуждаем шаги по обучению PyTorch. Эффективная сеть-B7 и Реснет50 модели с использованием IMAGEnet данные в распределенном виде с TDE. Мы используем PyTorch РаспределенныеДанныеПараллельный API и контроллер Kubernetes TorchElastic, а также запускать наши обучающие задания в кластере EKS, содержащем несколько узлов GPU. На следующей диаграмме показана схема архитектуры для обучения этой модели.

TorchElastic для Kubernetes состоит в основном из двух компонентов: TorchElastic Kubernetes Controller (TEC) и сервера параметров (etcd). Контроллер отвечает за мониторинг и управление обучающими заданиями, а сервер параметров отслеживает рабочие узлы для распределенной синхронизации и обнаружения одноранговых узлов.

Чтобы учебные модули могли получить доступ к данным, нам нужен общий том данных, который может быть подключен каждым модулем. Некоторые варианты общих томов через Интерфейс хранения контейнеров (CSI) драйверы, включенные в AWS DevOps для EKS Он Эластичная файловая система Amazon (Amazon EFS) и FSx для блеска.

Настройка кластера

В нашей конфигурации кластера мы используем один экземпляр c5.2xlarge для системных модулей. Мы используем три экземпляра p4d.24xlarge в качестве рабочих модулей для обучения модели EfficientNet. Для обучения ResNet50 мы используем экземпляры p3.8xlarge в качестве рабочих модулей. Кроме того, мы используем общую файловую систему FSx для хранения наших обучающих данных и артефактов модели.

Инстансы AWS p4d.24xlarge оснащены Эластичный тканевый адаптер (EFA) для обеспечения сетевого взаимодействия между узлами. Мы обсудим EFA позже в посте. Чтобы включить связь через EFA, нам нужно настроить настройку кластера с помощью файла .yaml. Ан пример файла предоставляется в репозитории GitHub.

После правильной настройки этого файла .yaml мы можем запустить кластер с помощью сценария, предоставленного в репозитории GitHub:

./eks-create.sh

См. Репо GitHub для получения подробных инструкций.

Разницы между запуском заданий на p4d.24xlarge и p3.8xlarge практически нет. Шаги, описанные в этом посте, работают для обоих. Единственное отличие заключается в наличии EFA на инстансах p4d.24xlarge. Для небольших моделей, таких как ResNet50, стандартная сеть по сравнению с сетью EFA оказывает минимальное влияние на скорость обучения.

FSx для файловой системы Lustre

FSx предназначен для высокопроизводительных вычислительных рабочих нагрузок и обеспечивает задержку менее миллисекунды при использовании томов хранения на твердотельных накопителях. Мы выбрали FSx, потому что он обеспечивает лучшую производительность при масштабировании до большого количества узлов. Важно отметить, что FSx может существовать только в одной зоне доступности. Поэтому все узлы, имеющие доступ к файловой системе FSx, должны находиться в той же зоне доступности, что и файловая система FSx. Один из способов добиться этого — указать соответствующую зону доступности в файле .yaml кластера для определенных групп узлов перед созданием кластера. Кроме того, мы можем изменить сетевую часть группы автоматического масштабирования для этих узлов после настройки кластера и ограничить ее использованием одной подсети. Это легко сделать на консоли Amazon EC2.

Предполагая, что кластер EKS запущен и работает, а идентификатор подсети для зоны доступности известен, мы можем настроить файловую систему FSx, предоставив необходимую информацию в fsx.conf файл, как описано в ридми и запуск развернуть.sh сценарий в FSX папка. Это устанавливает правильную политику и группу безопасности для доступа к файловой системе. Скрипт также устанавливает водитель CSI для FSx в качестве набора демонов. Наконец, мы можем создать утверждение постоянного тома FSx в Kubernetes, применив один файл .yaml:

kubectl apply -f fsx-pvc-dynamic.yaml

Это создает файловую систему FSx в зоне доступности, указанной в fsx.conf файл, а также создает постоянную претензию тома fsx-pvc, который может быть смонтирован любым модулем в кластере в режиме чтения-записи-многих (RWX).

В нашем эксперименте мы использовали полные данные ImageNet, которые содержат более 12 миллионов обучающих изображений, разделенных на 1,000 классов. Данные можно скачать с Веб-сайт ImageNet. Оригинальный шар TAR имеет несколько каталогов, но для обучения нашей модели нас интересуют только ILSVRC/Data/CLS-LOC/, который включает в себя train и val подкаталоги. Перед тренировкой нам нужно переставить изображения в val подкаталог, чтобы соответствовать структуре каталогов, требуемой PyTorch Папка изображения учебный класс. Это можно сделать с помощью простого Скрипт Python после того, как данные будут скопированы на постоянный том на следующем шаге.

Чтобы скопировать данные из Простой сервис хранения Amazon (Amazon S3) в файловую систему FSx мы создаем образ Docker, который включает в себя скрипты для этой задачи. Пример Dockerfile и сценарий оболочки включены в CSI папка в репозитории GitHub. Мы можем построить образ, используя build.sh сценарий, а затем отправить его в Amazon ECR с помощью push.sh сценарий. Прежде чем использовать эти сценарии, нам необходимо указать правильный URI для репозитория ECR в .env файл в корневой папке репозитория GitHub. После отправки образа Docker в Amazon ECR мы можем запустить модуль для копирования данных, применив соответствующий файл .yaml:

kubectl apply -f fsx-data-prep-pod.yaml

Модуль автоматически запускает скрипт данные-prep.sh для копирования данных из Amazon S3 на общий том. Поскольку данные ImageNet содержат более 12 миллионов файлов, процесс копирования занимает пару часов. Скрипт Python imagenet_data_prep.py также запускается для перестановки val набор данных, как и ожидалось PyTorch.

Сетевое ускорение

Мы можем использовать адаптер эластичной ткани (EFA) в сочетании с поддерживаемые типы инстансов EC2 для ускорения сетевого трафика между узлами GPU в вашем кластере. Это может быть полезно при выполнении больших распределенных учебных заданий, когда стандартная сетевая связь может быть узким местом. Сценарии для развертывания и тестирования подключаемого модуля устройства EFA в кластере EKS, которые мы здесь используем, включены в efa-устройство-плагин папка в репозитории GitHub. Чтобы включить задание с EFA в вашем кластере EKS, в дополнение к узлам кластера, имеющим необходимое аппаратное и программное обеспечение, в кластере необходимо развернуть подключаемый модуль устройства EFA, а ваш контейнер заданий должен иметь совместимые CUDA и NCCL. версии установлен.

Чтобы продемонстрировать выполнение тестов NCCL и оценить производительность EFA на экземплярах p4d.24xlarge, мы сначала должны развернуть оператор Kubeflow MPI, запустив соответствующий развернуть.sh сценарий в mpi-оператор папка. Затем мы запускаем развернуть.sh скрипт и обновить тест-эфа-nccl.yaml манифест, поэтому ограничения и запросы на ресурс vpc.amazonaws.com установлено значение 4. Четыре доступных адаптера EFA в узлах p4d.24xlarge объединяются для обеспечения максимальной пропускной способности.

Run kubectl apply -f ./test-efa-nccl.yaml чтобы применить тест, а затем отобразить журналы тестового модуля. Следующая строка в выходных данных журнала подтверждает, что EFA используется:

NCCL INFO NET/OFI Selected Provider is efa

Результаты теста должны выглядеть примерно так:

[1,0]<stdout>:#                                                       out-of-place                       in-place
[1,0]<stdout>:#       size         count      type   redop     time   algbw   busbw  error     time   algbw   busbw  error
[1,0]<stdout>:#        (B)    (elements)                       (us)  (GB/s)  (GB/s)            (us)  (GB/s)  (GB/s)
[1,0]<stdout>:           8             2     float     sum    629.7    0.00    0.00  2e-07    631.4    0.00    0.00  1e-07
[1,0]<stdout>:          16             4     float     sum    630.5    0.00    0.00  1e-07    628.1    0.00    0.00  1e-07
[1,0]<stdout>:          32             8     float     sum    627.6    0.00    0.00  1e-07    628.2    0.00    0.00  1e-07
[1,0]<stdout>:          64            16     float     sum    633.6    0.00    0.00  1e-07    628.4    0.00    0.00  6e-08
[1,0]<stdout>:         128            32     float     sum    627.5    0.00    0.00  6e-08    632.0    0.00    0.00  6e-08
[1,0]<stdout>:         256            64     float     sum    634.5    0.00    0.00  6e-08    636.5    0.00    0.00  6e-08
[1,0]<stdout>:         512           128     float     sum    634.8    0.00    0.00  6e-08    635.2    0.00    0.00  6e-08
[1,0]<stdout>:        1024           256     float     sum    646.6    0.00    0.00  2e-07    643.6    0.00    0.00  2e-07
[1,0]<stdout>:        2048           512     float     sum    745.0    0.00    0.01  5e-07    746.0    0.00    0.01  5e-07
[1,0]<stdout>:        4096          1024     float     sum    958.2    0.00    0.01  5e-07    955.8    0.00    0.01  5e-07
[1,0]<stdout>:        8192          2048     float     sum    963.0    0.01    0.02  5e-07    954.5    0.01    0.02  5e-07
[1,0]<stdout>:       16384          4096     float     sum    955.0    0.02    0.03  5e-07    955.5    0.02    0.03  5e-07
[1,0]<stdout>:       32768          8192     float     sum    975.5    0.03    0.06  5e-07   1009.0    0.03    0.06  5e-07
[1,0]<stdout>:       65536         16384     float     sum   1353.4    0.05    0.09  5e-07   1343.5    0.05    0.09  5e-07
[1,0]<stdout>:      131072         32768     float     sum   1395.9    0.09    0.18  5e-07   1392.6    0.09    0.18  5e-07
[1,0]<stdout>:      262144         65536     float     sum   1476.7    0.18    0.33  5e-07   1536.3    0.17    0.32  5e-07
[1,0]<stdout>:      524288        131072     float     sum   1560.3    0.34    0.63  5e-07   1568.3    0.33    0.63  5e-07
[1,0]<stdout>:     1048576        262144     float     sum   1599.2    0.66    1.23  5e-07   1595.3    0.66    1.23  5e-07
[1,0]<stdout>:     2097152        524288     float     sum   1671.1    1.25    2.35  5e-07   1672.5    1.25    2.35  5e-07
[1,0]<stdout>:     4194304       1048576     float     sum   1785.1    2.35    4.41  5e-07   1780.3    2.36    4.42  5e-07
[1,0]<stdout>:     8388608       2097152     float     sum   2133.6    3.93    7.37  5e-07   2135.0    3.93    7.37  5e-07
[1,0]<stdout>:    16777216       4194304     float     sum   2650.9    6.33   11.87  5e-07   2649.9    6.33   11.87  5e-07
[1,0]<stdout>:    33554432       8388608     float     sum   3422.0    9.81   18.39  5e-07   3478.7    9.65   18.09  5e-07
[1,0]<stdout>:    67108864      16777216     float     sum   4783.2   14.03   26.31  5e-07   4782.6   14.03   26.31  5e-07
[1,0]<stdout>:   134217728      33554432     float     sum   7216.9   18.60   34.87  5e-07   7240.9   18.54   34.75  5e-07
[1,0]<stdout>:   268435456      67108864     float     sum    12738   21.07   39.51  5e-07    12802   20.97   39.31  5e-07
[1,0]<stdout>:   536870912     134217728     float     sum    24375   22.03   41.30  5e-07    24403   22.00   41.25  5e-07
[1,0]<stdout>:  1073741824     268435456     float     sum    47904   22.41   42.03  5e-07    47893   22.42   42.04  5e-07
[1,4]<stdout>:test-efa-nccl-worker-0:33:33 [4] NCCL INFO comm 0x7fd4a0000f60 rank 4 nranks 16 cudaDev 4 busId 901c0 - Destroy COMPLETE
[1,0]<stdout>:# Out of bounds values : 0 OK
[1,0]<stdout>:# Avg bus bandwidth    : 8.23785

По результатам тестов видно, что максимальная пропускная способность составляет около 42 ГБ/с, а средняя пропускная способность шины — около 8 ГБ.

Мы также провели эксперименты с одним включенным адаптером EFA, а также без адаптеров EFA. Все результаты сведены в следующую таблицу.

Мы также обнаружили, что для относительно небольших моделей, таких как ImageNet, использование ускоренной сети сокращает время обучения на эпоху только на 5–8% при размере пакета 64. Для более крупных моделей и меньших размеров пакетов, когда требуется повышенная сетевая передача весов. , использование ускоренной сети оказывает большее влияние. Мы наблюдали сокращение времени обучения эпохи на 15–18% для обучения EfficientNet-B7 с размером пакета 1. Фактическое влияние EFA на ваше обучение будет зависеть от размера вашей модели.

Мониторинг GPU

Перед запуском задания обучения мы также можем настроить Amazon CloudWatch метрики для визуализации использования графического процессора во время обучения. Может быть полезно узнать, используются ли ресурсы оптимально, или потенциально определить нехватку ресурсов и узкие места в процессе обучения.

Соответствующие сценарии для настройки CloudWatch находятся в GPU-метрики папка. Сначала мы создаем образ Docker с amazon-cloudwatch-agent и nvidia-smi. Мы можем использовать Dockerfile в gpu-metrics папку для создания этого образа. Предполагая, что реестр ECR уже установлен в .env файл из предыдущего шага, мы можем создать и отправить изображение, используя build.sh и push.sh. После этого запустив deploy.sh скрипт автоматически завершает настройку. Он запускает набор демонов с amazon-cloudwatch-agent и отправляет различные показатели в CloudWatch. Метрики графического процессора отображаются под CWAgent пространство имен в консоли CloudWatch. Остальные метрики кластера отображаются под ContainerInsights пространство имен.

Модельное обучение

Все скрипты, необходимые для обучения PyTorch, находятся в папке эластичная работа папка в репозитории GitHub. Перед запуском обучающего задания нам нужно запустить etcd сервер, который используется TEC для обнаружения рабочих процессов и обмена параметрами. развернуть.sh сценарий в elasticjob папка делает именно это.

Чтобы воспользоваться преимуществами EFA в экземплярах p4d.24xlarge, нам нужно использовать определенный образ Docker, доступный в Публичная галерея Amazon ECR который поддерживает связь NCCL через EFA. Нам просто нужно скопировать наш обучающий код в этот образ Docker. Dockerfile под образцы Папка создает образ, который будет использоваться при выполнении обучающего задания на экземплярах p4d. Как всегда, мы можем использовать build.sh и push.sh scripts в папке для сборки и отправки образа.

Ассоциация imagenet-efa.yaml файл описывает обучающую работу. Этот файл .yaml устанавливает ресурсы, необходимые для выполнения задания обучения, а также монтирует постоянный том с данными обучения, настроенными в предыдущем разделе.

Здесь стоит отметить несколько вещей. Количество реплик должно быть равно количеству узлов, доступных в кластере. В нашем случае мы установили значение 3, потому что у нас было три узла p4d.24xlarge. в imagenet-efa.yaml файл, nvidia.com/gpu параметр по ресурсам и nproc_per_node под args должно быть установлено количество GPU на узел, которое в случае p4d.24xlarge равно 8. Кроме того, аргумент worker для скрипта Python устанавливает количество CPU на процесс. Мы выбрали значение 4, поскольку в наших экспериментах это обеспечивает оптимальную производительность при работе на инстансах p4d.24xlarge. Эти настройки необходимы для того, чтобы максимально использовать все аппаратные ресурсы, доступные в кластере.

Когда задание выполняется, мы можем отслеживать использование графического процессора в CloudWatch для всех графических процессоров в кластере. Ниже приведен пример одного из наших учебных заданий с тремя узлами p4d.24xlarge в кластере. Здесь мы выбрали по одному графическому процессору из каждого узла. С настройками, упомянутыми ранее, использование графического процессора близко к 100% на этапе обучения эпохи для всех узлов в кластере.

Для обучения модели ResNet50 с использованием экземпляров p3.8xlarge нам нужны точно такие же шаги, как описано для обучения EfficientNet с использованием p4d.24xlarge. Мы также можем использовать тот же образ Docker. Как упоминалось ранее, инстансы p3.8xlarge не оснащены EFA. Однако для модели ResNet50 это не является существенным недостатком. imagenet-fsx.yaml сценарий, предоставленный в репозитории GitHub, настраивает задание обучения с соответствующими ресурсами для типа узла p3.8xlarge. В задании используется тот же набор данных из файловой системы FSx.

Масштабирование графического процессора

Мы провели несколько экспериментов, чтобы посмотреть, как масштабируется время обучения для модели EfficientNet-B7 за счет увеличения количества графических процессоров. Для этого мы изменили количество реплик с 1 на 3 в нашем тренировочном файле .yaml для каждого тренировочного прогона. Мы наблюдали время только для одной эпохи при использовании полного набора данных ImageNet. На следующем рисунке показаны результаты нашего эксперимента по масштабированию графического процессора. Красная пунктирная линия показывает, как должно сократиться время обучения при использовании 8 GPU за счет увеличения количества GPU. Как мы видим, масштабирование довольно близко к ожидаемому.

Точно так же мы получили график масштабирования графического процессора для обучения ResNet50 на инстансах p3.8xlarge. Для этого случая мы изменили реплики в нашем файле .yaml с 1 на 4. Результаты этого эксперимента показаны на следующем рисунке.

Убирать

Важно сократить ресурсы после обучения модели, чтобы избежать затрат, связанных с запуском простаивающих экземпляров. С каждым скриптом, создающим ресурсы, Репо GitHub предоставляет соответствующий скрипт для их удаления. Чтобы очистить нашу настройку, мы должны удалить файловую систему FSx перед удалением кластера, поскольку она связана с подсетью в VPC кластера. Чтобы удалить файловую систему FSx, нам просто нужно запустить следующую команду (изнутри FSX папка):

kubectl delete -f fsx-pvc-dynamic.yaml
./delete.sh

Обратите внимание, что это удалит не только постоянный том, но и файловую систему FSx, и все данные в файловой системе будут потеряны. Когда этот шаг завершен, мы можем удалить кластер, используя следующий скрипт в эКС Папка:

./eks-delete.sh

Это приведет к удалению всех существующих модулей, удалению кластера и удалению VPC, созданного в начале.

Заключение

В этом посте мы подробно описали шаги, необходимые для запуска обучения параллельной модели распределенных данных PyTorch на кластерах EKS. Эта задача может показаться сложной, но AWS DevOps для EKS Проект, созданный командой ML Frameworks в AWS, предоставляет все необходимые сценарии и инструменты для упрощения процесса и облегчения обучения распределенной модели.

Для получения дополнительной информации о технологиях, используемых в этом посте, посетите Амазон ЭКС и Распределенная эластичная горелка. Мы рекомендуем вам применить описанный здесь подход к вашим собственным примерам использования распределенного обучения.

Полезные ресурсы

Об авторах

Имран Юнус является главным архитектором решений для команды ML Frameworks в AWS. Он занимается крупномасштабными рабочими нагрузками машинного обучения и глубокого обучения в таких сервисах AWS, как Amazon EKS и AWS ParallelCluster. Он имеет большой опыт применения глубокого обучения в области компьютерного зрения и промышленного Интернета вещей. Имран получил докторскую степень в области физики частиц высоких энергий, где он участвовал в анализе экспериментальных данных в петабайтных масштабах.

Алекс Янкульский является комплексным архитектором программного обеспечения и инфраструктуры, который любит выполнять глубокую практическую работу. В настоящее время он является главным архитектором решений для самоуправляемого машинного обучения в AWS. В своей роли он фокусируется на помощи клиентам в контейнеризации и оркестрации рабочих нагрузок машинного обучения и искусственного интеллекта в сервисах AWS на базе контейнеров. Он также является автором открытого исходного кода. Сделать фреймворк и капитан Docker, который любит применять контейнерные технологии для ускорения темпов инноваций при решении самых больших мировых проблем. В течение последних 10 лет Алекс работал над борьбой с изменением климата, демократизацией ИИ и машинного обучения, повышением безопасности путешествий, улучшением здравоохранения и повышением энергоэффективности.