Розподілене навчання за допомогою Amazon EKS і Torch Distributed Elastic

Навчання моделі розподіленого глибокого навчання стає все більш важливим, оскільки розмір даних зростає в багатьох галузях. Зараз багато програм комп’ютерного зору та обробки природної мови вимагають навчання моделей глибокого навчання, складність яких зростає в геометричній прогресії та часто навчається із сотнями терабайтів даних. Тоді стає важливим використовувати величезну хмарну інфраструктуру для масштабування навчання таких великих моделей.

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

Розподілена модель навчання в основному складається з двох парадигм:

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

У цій публікації ми надаємо приклад архітектури для навчання моделей PyTorch за допомогою Факел розподілений еластичний фреймворку в режимі паралельного використання розподілених даних Послуга Amazon Elastic Kubernetes (Amazon EKS).

Передумови

Щоб відтворити результати, наведені в цій публікації, єдиною необхідною умовою є обліковий запис AWS. У цьому обліковому записі ми створюємо кластер EKS і an Amazon FSx для Luster файлова система. Ми також надсилаємо зображення контейнерів до Реєстр контейнерів Amazon Elastic (Amazon ECR) репозиторій в обліковому записі. Інструкції з налаштування цих компонентів надаються за потреби в цій публікації.

Кластери EKS

Amazon EKS — це керований контейнерний сервіс для запуску та масштабування програм Kubernetes на AWS. За допомогою Amazon EKS ви можете ефективно виконувати розподілені навчальні завдання, використовуючи останні Обчислювальна хмара Amazon Elastic (Amazon EC2) без необхідності встановлювати, керувати та підтримувати власну площину керування чи вузли. Це популярний оркестратор для машинного навчання (ML) і робочих процесів ШІ. Типовий кластер EKS в AWS виглядає так, як показано нижче.

Ми випустили проект з відкритим кодом, AWS DevOps для EKS (aws-do-eks), який надає велику колекцію простих у використанні та настроюваних сценаріїв і інструментів для підготовки кластерів EKS і виконання розподілених навчальних завдань. Цей проект побудовано за принципами Виконайте фреймворк: простота, гнучкість і універсальність. Ви можете налаштувати бажаний кластер за допомогою екс.конф файл, а потім запустіть його, запустивши екс-create.sh сценарій. Детальні інструкції наведено в GitHub репо.

Навчання моделей PyTorch за допомогою Torch Distributed Elastic

Torch Distributed Elastic (TDE) — це власна бібліотека PyTorch для навчання великомасштабних моделей глибокого навчання, де важливо динамічно масштабувати обчислювальні ресурси залежно від доступності. The Контролер TorchElastic для Kubernetes — це рідна реалізація Kubernetes для TDE, яка автоматично керує життєвим циклом модулів і служб, необхідних для навчання TDE. Це дозволяє за потреби динамічно масштабувати обчислювальні ресурси під час навчання. Він також забезпечує відмовостійке навчання шляхом відновлення завдань після збою вузла.

У цій публікації ми обговорюємо етапи навчання PyTorch EfficientNet-B7 та ResNet50 використання моделей IMAGEnet дані в розподіленому вигляді за допомогою TDE. Ми використовуємо PyTorch DistributedDataParallel API та контролер Kubernetes TorchElastic, а також виконувати наші навчальні завдання на кластері EKS, що містить кілька вузлів GPU. На наступній діаграмі показано діаграму архітектури для цієї моделі навчання.

TorchElastic для Kubernetes складається в основному з двох компонентів: контролера TorchElastic Kubernetes (TEC) і сервера параметрів (etcd). Контролер відповідає за моніторинг та керування навчальними завданнями, а сервер параметрів відстежує робочі вузли для розподіленої синхронізації та виявлення однорангових вузлів.

Щоб навчальні модулі мали доступ до даних, нам потрібен спільний том даних, який може бути змонтований кожним модулем. Деякі параметри для спільних томів через Інтерфейс зберігання контейнерів (CSI) включені драйвери AWS DevOps для EKS він має Еластична файлова система Amazon (Amazon EFS) і FSx для Luster.

Налаштування кластера

У нашій конфігурації кластера ми використовуємо один екземпляр 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 файл, як описано в ридми і запустити deploy.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 ImageFolder клас. Це можна зробити за допомогою простого Скрипт Python після того, як дані буде скопійовано на постійний том на наступному кроці.

Щоб скопіювати дані з an Служба простого зберігання 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

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

Прискорення мережі

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

Щоб продемонструвати виконання тестів NCCL та оцінку продуктивності EFA на примірниках p4d.24xlarge, ми спочатку повинні розгорнути оператор Kubeflow MPI, запустивши відповідний deploy.sh сценарій у mpi-оператор папку. Потім запускаємо deploy.sh сценарій і оновити test-efa-nccl.yaml виявити обмеження та запити на ресурси vpc.amazonaws.com встановлено на 4. Чотири доступні адаптери EFA у вузлах p4d.24xlarge об’єднуються разом, щоб забезпечити максимальну пропускну здатність.

прогін 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 метрики для візуалізації використання GPU під час навчання. Може бути корисно дізнатися, чи оптимально використовуються ресурси, або потенційно виявити брак ресурсів і вузькі місця в процесі навчання.

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

Модельний тренінг

Усі сценарії, необхідні для навчання PyTorch, знаходяться в еластична робота у сховищі GitHub. Перш ніж запускати навчальну роботу, нам потрібно запустити etcd сервер, який використовується TEC для виявлення працівників і обміну параметрами. The deploy.sh сценарій у elasticjob папка робить саме це.

Щоб скористатися перевагами EFA в екземплярах p4d.24xlarge, нам потрібно використовувати певний образ Docker, доступний у Громадська галерея Amazon ECR який підтримує зв’язок NCCL через EFA. Нам просто потрібно скопіювати наш навчальний код до цього образу Docker. The Докер-файл під зразки папка створює зображення для використання під час виконання навчального завдання на екземплярах p4d. Як завжди, ми можемо використовувати build.sh та push.sh сценарії в папці для створення та надсилання зображення.

Команда imagenet-efa.yaml файл описує навчальну роботу. Цей файл .yaml налаштовує ресурси, необхідні для запуску навчального завдання, а також монтує постійний том із навчальними даними, налаштованими в попередньому розділі.

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

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

Для навчання моделі ResNet50 з використанням екземплярів p3.8xlarge нам потрібні ті самі кроки, що й для навчання EfficientNet з використанням p4d.24xlarge. Ми також можемо використовувати той самий образ Docker. Як згадувалося раніше, екземпляри p3.8xlarge не оснащені EFA. Однак для моделі ResNet50 це не є істотним недоліком. The imagenet-fsx.yaml сценарій, наданий у сховищі GitHub, налаштовує завдання навчання з відповідними ресурсами для типу вузла p3.8xlarge. Завдання використовує той самий набір даних із файлової системи FSx.

Масштабування GPU

Ми провели кілька експериментів, щоб спостерігати, як масштабується час навчання для моделі EfficientNet-B7 за рахунок збільшення кількості графічних процесорів. Для цього ми змінили кількість реплік з 1 до 3 у нашому навчальному файлі .yaml для кожного навчального запуску. Ми спостерігали лише час для однієї епохи, використовуючи повний набір даних ImageNet. На наступному малюнку показано результати нашого експерименту з масштабування GPU. Червона пунктирна лінія показує, як має зменшитися час тренування після пробіжки з використанням 8 GPU за рахунок збільшення кількості 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, надає всі необхідні сценарії та інструменти для спрощення процесу та робить навчання розподіленої моделі легкодоступним.

Для отримання додаткової інформації про технології, які використовуються в цій публікації, відвідайте Amazon EKS та Факел розподілений еластичний. Ми заохочуємо вас застосувати описаний тут підхід до ваших власних випадків використання розподіленого навчання.

ресурси

Про авторів

Імран Юнус є головним архітектором рішень для команди ML Frameworks в AWS. Він зосереджується на великомасштабному машинному навчанні та глибокому навчанні в таких сервісах AWS, як Amazon EKS і AWS ParallelCluster. Він має великий досвід у застосуванні Deep Leaning у комп’ютерному баченні та промисловому Інтернеті речей. Імран отримав ступінь доктора філософії з фізики частинок високих енергій, де він брав участь в аналізі експериментальних даних у пета-байтних масштабах.

Алекс Янкульський є архітектором повного програмного забезпечення та інфраструктури, який любить виконувати глибоку практичну роботу. Зараз він є головним архітектором рішень для самокерованого машинного навчання в AWS. У своїй ролі він зосереджується на допомозі клієнтам із контейнеризацією та оркестровкою робочих навантажень ML та AI у службах AWS на базі контейнерів. Він також є автором відкритого коду Зробіть каркас і капітан Docker, який любить застосовувати контейнерні технології для прискорення темпів інновацій, вирішуючи найбільші світові проблеми. Протягом останніх 10 років Алекс працював над боротьбою зі зміною клімату, демократизацією штучного інтелекту та машинного навчання, роблячи подорожі безпечнішими, охорону здоров’я кращими та енергію розумнішою.