Szkolenie rozproszone z Amazon EKS i Torch Distributed Elastic

Uczenie rozproszonego modelu uczenia głębokiego staje się coraz ważniejsze, ponieważ rozmiary danych rosną w wielu branżach. Wiele aplikacji w zakresie wizji komputerowej i przetwarzania języka naturalnego wymaga obecnie uczenia modeli głębokiego uczenia, których złożoność rośnie wykładniczo i często jest szkolona przy użyciu setek terabajtów danych. Wtedy ważne staje się wykorzystanie rozległej infrastruktury chmurowej do skalowania szkolenia tak dużych modeli.

Deweloperzy mogą korzystać z platform typu open source, takich jak PyTorch, do łatwego projektowania intuicyjnych architektur modeli. Jednak skalowanie uczenia tych modeli w wielu węzłach może być trudne ze względu na większą złożoność aranżacji.

Uczenie modeli rozproszonych składa się głównie z dwóch paradygmatów:

• Model równoległy – W przypadku uczenia równoległego modelu sam model jest tak duży, że nie mieści się w pamięci pojedynczego procesora GPU, a do uczenia modelu potrzebnych jest wiele procesorów GPU. Model GPT-3 Open AI z 175 miliardami możliwych do trenowania parametrów (około 350 GB) jest tego dobrym przykładem.
• Dane równoległe – W przypadku uczenia równoległego danych model może znajdować się na pojedynczym procesorze GPU, ale ponieważ dane są tak duże, uczenie modelu może zająć dni lub tygodnie. Dystrybucja danych w wielu węzłach GPU może znacznie skrócić czas uczenia.

W tym poście przedstawiamy przykładową architekturę do trenowania modeli PyTorch przy użyciu Latarka rozproszona elastyczna framework w rozproszonych danych równoległy sposób przy użyciu Elastyczna usługa Amazon Kubernetes (Amazon EKS).

Wymagania wstępne

Aby powtórzyć wyniki przedstawione w tym poście, jedynym warunkiem wstępnym jest konto AWS. Na tym koncie tworzymy klaster EKS i Amazon FSx dla Luster system plików. Przesyłamy również obrazy kontenerów do Rejestr elastycznego pojemnika Amazon (Amazon ECR) na koncie. Instrukcje dotyczące konfiguracji tych elementów są dostarczane w miarę potrzeb w całym poście.

Klastry EKS

Amazon EKS to zarządzana usługa kontenerowa do uruchamiania i skalowania aplikacji Kubernetes w AWS. Dzięki Amazon EKS możesz efektywnie prowadzić rozproszone zadania szkoleniowe przy użyciu najnowszych Elastyczna chmura obliczeniowa Amazon (Amazon EC2) instancje bez konieczności instalowania, obsługi i utrzymywania własnej płaszczyzny sterowania lub węzłów. Jest popularnym orkiestrator do uczenia maszynowego (ML) i przepływów pracy AI. Typowy klaster EKS w AWS wygląda jak na poniższym rysunku.

Wydaliśmy projekt open-source, AWS DevOps dla EKS (aws-do-eks), który zapewnia dużą kolekcję łatwych w użyciu i konfigurowalnych skryptów oraz narzędzi do obsługi klastrów EKS i uruchamiania rozproszonych zadań szkoleniowych. Ten projekt jest zbudowany zgodnie z zasadami Czy Framework: Prostota, Elastyczność i Uniwersalność. Możesz skonfigurować żądany klaster za pomocą eks.conf plik, a następnie uruchom go, uruchamiając eks-create.sh scenariusz. Szczegółowe instrukcje znajdują się w GitHub repo.

Trenuj modele PyTorch za pomocą Torch Distributed Elastic

Torch Distributed Elastic (TDE) to natywna biblioteka PyTorch do trenowania modeli uczenia głębokiego na dużą skalę, w których kluczowe jest dynamiczne skalowanie zasobów obliczeniowych w oparciu o dostępność. The Kontroler TorchElastic dla Kubernetes to natywna implementacja Kubernetes dla TDE, która automatycznie zarządza cyklem życia podów i usług wymaganych do szkolenia TDE. Pozwala na dynamiczne skalowanie zasobów obliczeniowych podczas szkolenia zgodnie z potrzebami. Zapewnia również szkolenie w zakresie odporności na awarie poprzez odzyskiwanie zadań po awarii węzła.

W tym poście omawiamy etapy szkolenia PyTorch EfficientNet-B7 i ResNet50 modele używające ImageNet dane w sposób rozproszony dzięki TDE. Używamy PyTorch Dane rozproszoneParallel API i kontrolera Kubernetes TorchElastic oraz uruchamiaj nasze zadania szkoleniowe w klastrze EKS zawierającym wiele węzłów GPU. Poniższy diagram przedstawia diagram architektury dla tego szkolenia modelu.

TorchElastic for Kubernetes składa się głównie z dwóch komponentów: TorchElastic Kubernetes Controller (TEC) i serwera parametrów (itp.). Kontroler jest odpowiedzialny za monitorowanie i zarządzanie zadaniami szkoleniowymi, a serwer parametrów śledzi węzły robocze w celu rozproszonej synchronizacji i wykrywania peerów.

Aby moduły szkoleniowe miały dostęp do danych, potrzebujemy udostępnionej objętości danych, którą można zamontować dla każdego modułu. Niektóre opcje dla udostępnionych woluminów przez Interfejs przechowywania kontenerów (CSI) sterowniki zawarte w AWS DevOps dla EKS jest System plików Amazon Elastic (Amazon EFS) i FSx dla połysku.

Konfiguracja klastra

W naszej konfiguracji klastra używamy jednej instancji c5.2xlarge dla podów systemowych. Używamy trzech instancji p4d.24xlarge jako zasobników roboczych do trenowania modelu EfficientNet. W przypadku szkolenia ResNet50 używamy wystąpień p3.8xlarge jako zasobników roboczych. Ponadto używamy współdzielonego systemu plików FSx do przechowywania naszych danych szkoleniowych i artefaktów modelu.

Instancje AWS p4d.24xlarge są wyposażone w Elastyczny adapter do tkaniny (EFA) w celu zapewnienia sieci między węzłami. Więcej o EFA w dalszej części postu. Aby umożliwić komunikację przez EFA, musimy skonfigurować konfigurację klastra za pomocą pliku .yaml. jakiś przykładowy plik jest dostępny w repozytorium GitHub.

Po prawidłowym skonfigurowaniu tego pliku .yaml możemy uruchomić klaster za pomocą skryptu dostarczonego w repozytorium GitHub:

./eks-create.sh

Patrz: GitHub repo dla szczegółowych instrukcji.

Praktycznie nie ma różnicy między uruchamianiem zadań na p4d.24xlarge i p3.8xlarge. Kroki opisane w tym poście działają dla obu. Jedyną różnicą jest dostępność EFA na instancjach p4d.24xlarge. W przypadku mniejszych modeli, takich jak ResNet50, standardowa sieć w porównaniu do sieci EFA ma minimalny wpływ na szybkość uczenia.

FSx dla systemu plików Lustre

FSx jest przeznaczony do obciążeń obliczeniowych o wysokiej wydajności i zapewnia opóźnienia poniżej milisekundy przy użyciu woluminów pamięci masowej na dyskach półprzewodnikowych. Wybraliśmy FSx, ponieważ zapewniał lepszą wydajność, ponieważ skalowaliśmy do dużej liczby węzłów. Ważnym szczegółem, na który należy zwrócić uwagę, jest to, że FSx może istnieć tylko w jednej Strefie Dostępności. Dlatego wszystkie węzły uzyskujące dostęp do systemu plików FSx powinny znajdować się w tej samej strefie dostępności, co system plików FSx. Jednym ze sposobów osiągnięcia tego jest określenie odpowiedniej strefy dostępności w pliku .yaml klastra dla określonych grup węzłów przed utworzeniem klastra. Alternatywnie możemy zmodyfikować część sieciową grupy autoskalowania dla tych węzłów po skonfigurowaniu klastra i ograniczyć ją do korzystania z jednej podsieci. Można to łatwo zrobić na konsoli Amazon EC2.

Zakładając, że klaster EKS jest już uruchomiony, a identyfikator podsieci dla strefy dostępności jest znany, możemy skonfigurować system plików FSx, podając niezbędne informacje w fsx.conf plik zgodnie z opisem w readme i uruchamiam wdrożyć.sh skrypt w fsx teczka. Ustawia to prawidłową politykę i grupę bezpieczeństwa dostępu do systemu plików. Skrypt instaluje również Sterownik CSI dla FSx jako demona. Na koniec możemy utworzyć żądanie trwałego woluminu FSx w Kubernetes, stosując pojedynczy plik .yaml:

kubectl apply -f fsx-pvc-dynamic.yaml

Spowoduje to utworzenie systemu plików FSx w strefie dostępności określonej w fsx.conf pliku, a także tworzy trwałe żądanie woluminu fsx-pvc, który może być montowany przez dowolny zasobnik w klastrze w trybie odczytu-zapisu-wielu (RWX).

W naszym eksperymencie wykorzystaliśmy pełne dane ImageNet, które zawierają ponad 12 milionów obrazów treningowych podzielonych na 1,000 klas. Dane można pobrać z Strona internetowa ImageNet. Oryginalna piłka TAR ma kilka katalogów, ale w przypadku naszego treningu modelowego jesteśmy zainteresowani tylko ILSVRC/Data/CLS-LOC/, który zawiera train i val podkatalogi. Przed treningiem musimy przearanżować obrazy w val podkatalog zgodny ze strukturą katalogów wymaganą przez PyTorch Folder obrazów klasa. Można to zrobić za pomocą prostego Skrypt Pythona po skopiowaniu danych do woluminu trwałego w następnym kroku.

Aby skopiować dane z Usługa Amazon Simple Storage (Amazon S3) do systemu plików FSx, tworzymy obraz Dockera, który zawiera skrypty do tego zadania. Przykładowy plik Dockerfile i skrypt powłoki są zawarte w csi folder w repozytorium GitHub. Wizerunek możemy zbudować za pomocą build.sh skryptu, a następnie prześlij go do Amazon ECR za pomocą push.sh scenariusz. Przed użyciem tych skryptów musimy podać poprawny identyfikator URI dla repozytorium ECR w .env plik w folderze głównym repozytorium GitHub. Po wypchnięciu obrazu Dockera do Amazon ECR, możemy uruchomić pod, aby skopiować dane, stosując odpowiedni plik .yaml:

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

Pod automatycznie uruchamia skrypt przygotowanie danych.sh skopiować dane z Amazon S3 do udostępnionego woluminu. Ponieważ dane ImageNet zawierają ponad 12 milionów plików, proces kopiowania zajmuje kilka godzin. Skrypt Pythona imagenet_data_prep.py jest również uruchamiany, aby zmienić val zestaw danych zgodnie z oczekiwaniami PyTorch.

Akceleracja sieci

Możemy użyć elastycznego adaptera do tkaniny (EFA) w połączeniu z obsługiwane typy instancji EC2 w celu przyspieszenia ruchu sieciowego między węzłami GPU w klastrze. Może to być przydatne podczas uruchamiania dużych rozproszonych zadań szkoleniowych, w których standardowa komunikacja sieciowa może stanowić wąskie gardło. Skrypty do wdrażania i testowania wtyczki urządzenia EFA w klastrze EKS, którego tutaj używamy, są zawarte w efa-device-wtyczka folder w repozytorium GitHub. Aby umożliwić zadanie z EFA w klastrze EKS, oprócz węzłów klastra z niezbędnym sprzętem i oprogramowaniem, wtyczka urządzenia EFA musi zostać wdrożona w klastrze, a kontener zadań musi mieć zgodny CUDA i NCCL Wersje zainstalowany.

Aby zademonstrować uruchamianie testów NCCL i ocenianie wydajności EFA na instancjach p4d.24xlarge, najpierw musimy wdrożyć operator Kubeflow MPI, uruchamiając odpowiedni wdrożyć.sh skrypt w operator mpi teczka. Następnie uruchamiamy wdrożyć.sh skrypt i zaktualizuj test-efa-nccl.yaml manifest więc limity i prośby o zasoby vpc.amazonaws.com są ustawione na 4. Cztery dostępne adaptery EFA w węzłach p4d.24xlarge są łączone w pakiet, aby zapewnić maksymalną przepustowość.

run kubectl apply -f ./test-efa-nccl.yaml aby zastosować test, a następnie wyświetlić dzienniki testera. Poniższy wiersz w danych wyjściowych dziennika potwierdza, że ​​jest używany EFA:

NCCL INFO NET/OFI Selected Provider is efa

Wyniki testu powinny wyglądać podobnie do następującego wyniku:

[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

W wynikach testów widać, że maksymalna przepustowość wynosi około 42 GB/s, a średnia przepustowość magistrali to około 8 GB.

Przeprowadziliśmy również eksperymenty z jednym włączonym adapterem EFA, a także bez adapterów EFA. Wszystkie wyniki podsumowano w poniższej tabeli.

Odkryliśmy również, że w przypadku stosunkowo małych modeli, takich jak ImageNet, użycie przyspieszonej sieci skraca czas uczenia w każdej epoce tylko o 5-8% przy wielkości partii 64. W przypadku większych modeli i mniejszych wielkości partii, gdy potrzebna jest zwiększona komunikacja sieciowa wag , użycie przyspieszonej sieci ma większy wpływ. Zaobserwowaliśmy skrócenie czasu uczenia w epoce o 15–18% w przypadku uczenia EfficientNet-B7 z rozmiarem partii 1. Rzeczywisty wpływ EFA na szkolenie będzie zależał od rozmiaru modelu.

Monitorowanie GPU

Przed uruchomieniem pracy szkoleniowej możemy również skonfigurować Amazon Cloud Watch metryki do wizualizacji wykorzystania procesora GPU podczas szkolenia. Pomocna może być wiedza, czy zasoby są wykorzystywane optymalnie, czy też potencjalna identyfikacja głodu zasobów i wąskich gardeł w procesie szkolenia.

Odpowiednie skrypty do konfiguracji CloudWatch znajdują się w GPU-metryki teczka. Najpierw tworzymy obraz Dockera za pomocą amazon-cloudwatch-agent i nvidia-smi. Możemy użyć Dockerfile w gpu-metrics folder, aby utworzyć ten obraz. Zakładając, że rejestr ECR jest już ustawiony w .env plik z poprzedniego kroku, możemy zbudować i wepchnąć obraz za pomocą build.sh i push.sh. Następnie uruchamiam deploy.sh skrypt automatycznie zakończy instalację. Uruchamia demona z amazon-cloudwatch-agent i przesyła różne metryki do CloudWatch. Wskaźniki GPU pojawiają się pod CWAgent przestrzeń nazw w konsoli CloudWatch. Pozostałe metryki klastra są wyświetlane pod ContainerInsights przestrzeń nazw.

Szkolenie modelowe

Wszystkie skrypty potrzebne do szkolenia PyTorch znajdują się w elastyczna praca folder w repozytorium GitHub. Przed rozpoczęciem pracy szkoleniowej musimy uruchomić etcd serwer, który jest używany przez komputer TEC do wykrywania pracowników i wymiany parametrów. The wdrożyć.sh skrypt w elasticjob folder robi dokładnie to.

Aby skorzystać z EFA w instancjach p4d.24xlarge, musimy użyć określonego obrazu Docker dostępnego w Publiczna galeria Amazon ECR który obsługuje komunikację NCCL poprzez EFA. Musimy tylko skopiować nasz kod szkoleniowy do tego obrazu Dockera. The Dockerfile pod próbki folder tworzy obraz, który ma być używany podczas uruchamiania zadania szkoleniowego na instancjach p4d. Jak zawsze możemy skorzystać z build.sh i push.sh skrypty w folderze, aby zbudować i wypchnąć obraz.

Połączenia imagenet-efa.yaml plik opisuje pracę szkoleniową. Ten plik .yaml konfiguruje zasoby potrzebne do uruchomienia zadania szkoleniowego, a także montuje stały wolumin z danymi treningowymi skonfigurowanymi w poprzedniej sekcji.

Warto tutaj zwrócić uwagę na kilka rzeczy. Liczbę replik należy ustawić na liczbę węzłów dostępnych w klastrze. W naszym przypadku ustawiliśmy to na 3, ponieważ mieliśmy trzy węzły p4d.24xlarge. w imagenet-efa.yaml plik, plik nvidia.com/gpu parametr w ramach zasobów i nproc_per_node dla args powinna być ustawiona na liczbę procesorów graficznych na węzeł, która w przypadku p4d.24xlarge wynosi 8. Ponadto argument worker dla skryptu Pythona określa liczbę procesorów CPU na proces. Wybraliśmy wartość 4, ponieważ w naszych eksperymentach zapewnia to optymalną wydajność podczas uruchamiania na instancjach p4d.24xlarge. Te ustawienia są niezbędne, aby zmaksymalizować wykorzystanie wszystkich zasobów sprzętowych dostępnych w klastrze.

Gdy zadanie jest uruchomione, możemy obserwować użycie GPU w CloudWatch dla wszystkich GPU w klastrze. Poniżej znajduje się przykład z jednego z naszych zadań szkoleniowych z trzema węzłami p4d.24xlarge w klastrze. Tutaj wybraliśmy po jednym GPU z każdego węzła. Przy ustawieniach wspomnianych wcześniej użycie procesora graficznego jest bliskie 100% podczas fazy uczenia epoki dla wszystkich węzłów w klastrze.

Aby nauczyć model ResNet50 przy użyciu wystąpień p3.8xlarge, potrzebujemy dokładnie takich samych kroków, jak opisano w przypadku szkolenia EfficientNet przy użyciu p4d.24xlarge. Możemy również użyć tego samego obrazu Dockera. Jak wspomniano wcześniej, instancje p3.8xlarge nie są wyposażone w EFA. Jednak dla modelu ResNet50 nie jest to znacząca wada. The imagenet-fsx.yaml skrypt udostępniony w repozytorium GitHub konfiguruje zadanie szkoleniowe z odpowiednimi zasobami dla typu węzła p3.8xlarge. Zadanie używa tego samego zestawu danych z systemu plików FSx.

Skalowanie GPU

Przeprowadziliśmy kilka eksperymentów, aby zaobserwować, jak skaluje się czas uczenia modelu EfficientNet-B7 poprzez zwiększenie liczby procesorów graficznych. W tym celu zmieniliśmy liczbę replik z 1 na 3 w naszym szkoleniowym pliku .yaml dla każdego przebiegu szkolenia. Zaobserwowaliśmy tylko czas jednej epoki podczas korzystania z pełnego zestawu danych ImageNet. Poniższy rysunek przedstawia wyniki naszego eksperymentu skalowania GPU. Czerwona kropkowana linia przedstawia, jak powinien zmniejszyć się czas treningu w przypadku biegu z 8 procesorami graficznymi poprzez zwiększenie liczby procesorów graficznych. Jak widać, skalowanie jest dość zbliżone do oczekiwanego.

Podobnie uzyskaliśmy wykres skalowania GPU dla szkolenia ResNet50 na instancjach p3.8xlarge. W tym przypadku zmieniliśmy repliki w naszym pliku .yaml z 1 na 4. Wyniki tego eksperymentu pokazano na poniższym rysunku.

Sprzątać

Ważne jest, aby zmniejszyć zasoby po uczeniu modelu, aby uniknąć kosztów związanych z uruchamianiem bezczynnych wystąpień. Z każdym skryptem, który tworzy zasoby, GitHub repo udostępnia pasujący skrypt do ich usunięcia. Aby wyczyścić naszą konfigurację, musimy usunąć system plików FSx przed usunięciem klastra, ponieważ jest on powiązany z podsiecią w VPC klastra. Aby usunąć system plików FSx, wystarczy uruchomić następujące polecenie (z wnętrza fsx teczka):

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

Zauważ, że spowoduje to nie tylko usunięcie stałego woluminu, ale także usunie system plików FSx, a wszystkie dane w systemie plików zostaną utracone. Po zakończeniu tego kroku możemy usunąć klaster za pomocą następującego skryptu w EKS folder:

./eks-delete.sh

Spowoduje to usunięcie wszystkich istniejących podów, usunięcie klastra i usunięcie utworzonej na początku sieci VPC.

Wnioski

W tym poście szczegółowo opisaliśmy kroki potrzebne do uruchomienia uczenia modelu równoległego danych rozproszonych PyTorch w klastrach EKS. To zadanie może wydawać się trudne, ale AWS DevOps dla EKS projekt stworzony przez zespół ML Frameworks w AWS zapewnia wszystkie niezbędne skrypty i narzędzia do uproszczenia procesu i ułatwienia dostępu do szkolenia modeli rozproszonych.

Aby uzyskać więcej informacji na temat technologii użytych w tym poście, odwiedź Amazon EX i Latarka rozproszona elastyczna. Zachęcamy do zastosowania opisanego tutaj podejścia do własnych przypadków użycia szkolenia rozproszonego.

Zasoby

O autorach

Imrana Younusa jest głównym architektem rozwiązań dla zespołu ML Frameworks w AWS. Koncentruje się na uczeniu maszynowym na dużą skalę i obciążeniach uczenia głębokiego w usługach AWS, takich jak Amazon EKS i AWS ParallelCluster. Posiada bogate doświadczenie w zastosowaniach Deep Leaning w Computer Vision i Industrial IoT. Imran uzyskał doktorat z fizyki cząstek wysokich energii, gdzie brał udział w analizie danych eksperymentalnych w skali petabajtowej.

Aleks Iankoulski jest pełnowymiarowym architektem oprogramowania i infrastruktury, który lubi wykonywać głęboką, praktyczną pracę. Obecnie jest głównym architektem rozwiązań dla samozarządzającego się uczenia maszynowego w AWS. W swojej roli koncentruje się na pomaganiu klientom w konteneryzacji i orkiestracji obciążeń ML i AI w usługach AWS opartych na kontenerach. Jest także autorem open source Czy ramy oraz kapitana Dockera, który uwielbia stosować technologie kontenerowe, aby przyspieszyć tempo innowacji, jednocześnie rozwiązując największe wyzwania świata. W ciągu ostatnich 10 lat Alex pracował nad przeciwdziałaniem zmianom klimatycznym, demokratyzacją sztucznej inteligencji i ML, bezpieczniejszymi podróżami, lepszą opieką zdrowotną i inteligentniejszą energią.