Pelatihan Terdistribusi Dengan Amazon EKS Dan Torch Distributed Elastic

Diterbitkan Ulang Oleh Plato

Followers: 0

Pelatihan model pembelajaran mendalam terdistribusi menjadi semakin penting karena ukuran data tumbuh di banyak industri. Banyak aplikasi dalam visi komputer dan pemrosesan bahasa alami sekarang memerlukan pelatihan model pembelajaran mendalam, yang berkembang secara eksponensial dalam kompleksitas dan sering dilatih dengan ratusan terabyte data. Kemudian menjadi penting untuk menggunakan infrastruktur cloud yang luas untuk menskalakan pelatihan model sebesar itu.

Pengembang dapat menggunakan kerangka kerja sumber terbuka seperti PyTorch untuk merancang arsitektur model intuitif dengan mudah. Namun, menskalakan pelatihan model ini di beberapa node dapat menjadi tantangan karena meningkatnya kompleksitas orkestrasi.

Pelatihan model terdistribusi terutama terdiri dari dua paradigma:

Model paralel – Dalam pelatihan paralel model, model itu sendiri sangat besar sehingga tidak dapat masuk ke dalam memori satu GPU, dan beberapa GPU diperlukan untuk melatih model. Model GPT-3 Open AI dengan 175 miliar parameter yang dapat dilatih (berukuran sekitar 350 GB) adalah contoh yang baik untuk ini.
Data paralel – Dalam pelatihan paralel data, model dapat berada dalam satu GPU, tetapi karena datanya sangat besar, diperlukan waktu berhari-hari atau berminggu-minggu untuk melatih model. Mendistribusikan data ke beberapa node GPU dapat mengurangi waktu pelatihan secara signifikan.

Dalam posting ini, kami memberikan contoh arsitektur untuk melatih model PyTorch menggunakan Obor Terdistribusi Elastis kerangka kerja dalam mode paralel data terdistribusi menggunakan Layanan Amazon Elastic Kubernetes (AmazonEKS).

Prasyarat

Untuk mereplikasi hasil yang dilaporkan dalam posting ini, satu-satunya prasyarat adalah akun AWS. Di akun ini, kami membuat cluster EKS dan Amazon FSx untuk Lustre berkas sistem. Kami juga mendorong gambar kontainer ke Registry Kontainer Elastis Amazon (Amazon ECR) repositori di akun. Instruksi untuk mengatur komponen ini disediakan sesuai kebutuhan di seluruh posting.

klaster EKS

Amazon EKS adalah layanan container terkelola untuk menjalankan dan menskalakan aplikasi Kubernetes di AWS. Dengan Amazon EKS, Anda dapat menjalankan tugas pelatihan terdistribusi secara efisien menggunakan yang terbaru Cloud komputasi elastis Amazon (Amazon EC2) instans tanpa perlu menginstal, mengoperasikan, dan memelihara bidang kontrol atau node Anda sendiri. Ini adalah populer pemimpin orkestra untuk pembelajaran mesin (ML) dan alur kerja AI. Sebuah cluster EKS khas di AWS terlihat seperti gambar berikut.

Kami telah merilis proyek sumber terbuka, AWS DevOps untuk EKS (aws-do-eks), yang menyediakan banyak koleksi skrip dan alat yang mudah digunakan dan dapat dikonfigurasi untuk menyediakan klaster EKS dan menjalankan tugas pelatihan terdistribusi. Proyek ini dibangun mengikuti prinsip-prinsip Lakukan Kerangka: Kesederhanaan, Fleksibilitas, dan Universalitas. Anda dapat mengonfigurasi cluster yang Anda inginkan dengan menggunakan eks.conf file dan kemudian luncurkan dengan menjalankan eks-buat.sh naskah. Instruksi terperinci disediakan di GitHub repo.

Latih model PyTorch menggunakan Torch Distributed Elastic

Torch Distributed Elastic (TDE) adalah library PyTorch asli untuk melatih model deep learning skala besar di mana sangat penting untuk menskalakan sumber daya komputasi secara dinamis berdasarkan ketersediaan. Itu Pengontrol TorchElastic untuk Kubernetes adalah implementasi Kubernetes asli untuk TDE yang secara otomatis mengelola siklus hidup pod dan layanan yang diperlukan untuk pelatihan TDE. Ini memungkinkan penskalaan sumber daya komputasi secara dinamis selama pelatihan sesuai kebutuhan. Ini juga menyediakan pelatihan toleransi kesalahan dengan memulihkan pekerjaan dari kegagalan node.

Dalam posting ini, kami membahas langkah-langkah untuk melatih PyTorch EfisienNet-B7 dan ResNet50 model menggunakan IMAGEnet data secara terdistribusi dengan TDE. Kami menggunakan PyTorch Data TerdistribusiParalel API dan pengontrol Kubernetes TorchElastic, dan menjalankan tugas pelatihan kami di klaster EKS yang berisi beberapa node GPU. Diagram berikut menunjukkan diagram arsitektur untuk pelatihan model ini.

TorchElastic untuk Kubernetes terutama terdiri dari dua komponen: TorchElastic Kubernetes Controller (TEC) dan server parameter (etcd). Pengontrol bertanggung jawab untuk memantau dan mengelola pekerjaan pelatihan, dan server parameter melacak node pekerja untuk sinkronisasi terdistribusi dan penemuan rekan.

Agar pod pelatihan dapat mengakses data, kami memerlukan volume data bersama yang dapat dipasang oleh setiap pod. Beberapa opsi untuk volume bersama melalui Antarmuka Penyimpanan Kontainer (CSI) driver termasuk dalam AWS DevOps untuk EKS adalah Sistem File Amazon Elastis (Amazon EFS) dan FSx untuk Lustre.

Pengaturan kluster

Dalam konfigurasi cluster kami, kami menggunakan satu instance c5.2xlarge untuk pod sistem. Kami menggunakan tiga instance p4d.24xlarge sebagai pod pekerja untuk melatih model EfficientNet. Untuk pelatihan ResNet50, kami menggunakan instance p3.8xlarge sebagai pod pekerja. Selain itu, kami menggunakan sistem file bersama FSx untuk menyimpan data pelatihan dan artefak model kami.

Instans AWS p4d.24xlarge dilengkapi dengan Adaptor Kain Elastis (EFA) untuk menyediakan jaringan antar node. Kami membahas EFA lebih lanjut nanti di pos. Untuk mengaktifkan komunikasi melalui EFA, kita perlu mengonfigurasi penyiapan cluster melalui file .yaml. Sebuah contoh file disediakan di repositori GitHub.

Setelah file .yaml ini dikonfigurasi dengan benar, kita dapat meluncurkan cluster menggunakan skrip yang disediakan di repo GitHub:

./eks-create.sh

Mengacu kepada GitHub repo untuk petunjuk rinci.

Praktis tidak ada perbedaan antara menjalankan pekerjaan pada p4d.24xlarge dan p3.8xlarge. Langkah-langkah yang dijelaskan dalam posting ini berfungsi untuk keduanya. Satu-satunya perbedaan adalah ketersediaan EFA pada instans p4d.24xlarge. Untuk model yang lebih kecil seperti ResNet50, jaringan standar dibandingkan dengan jaringan EFA memiliki dampak minimal pada kecepatan pelatihan.

FSx untuk sistem file Lustre

FSx dirancang untuk beban kerja komputasi kinerja tinggi dan menyediakan latensi sub-milidetik menggunakan volume penyimpanan solid-state drive. Kami memilih FSx karena memberikan kinerja yang lebih baik saat kami menskalakan ke sejumlah besar node. Detail penting yang perlu diperhatikan adalah bahwa FSx hanya dapat ada di satu Availability Zone. Oleh karena itu, semua node yang mengakses sistem file FSx harus ada di Availability Zone yang sama dengan sistem file FSx. Salah satu cara untuk mencapainya adalah dengan menentukan Availability Zone yang relevan dalam file .yaml cluster untuk grup node tertentu sebelum membuat cluster. Atau, kita dapat memodifikasi bagian jaringan dari grup penskalaan otomatis untuk node ini setelah cluster disiapkan, dan membatasinya untuk menggunakan satu subnet. Ini dapat dengan mudah dilakukan di konsol Amazon EC2.

Dengan asumsi bahwa klaster EKS aktif dan berjalan, dan ID subnet untuk Availability Zone diketahui, kita dapat menyiapkan sistem file FSx dengan memberikan informasi yang diperlukan di fsx.conf file seperti yang dijelaskan dalam readme dan menjalankan menyebarkan.sh naskah di fsx map. Ini mengatur grup kebijakan dan keamanan yang benar untuk mengakses sistem file. Script juga menginstal pengemudi CSI untuk FSx sebagai daemonset. Terakhir, kita dapat membuat klaim volume persisten FSx di Kubernetes dengan menerapkan satu file .yaml:

kubectl apply -f fsx-pvc-dynamic.yaml

Ini membuat sistem file FSx di Availability Zone yang ditentukan dalam fsx.conf file, dan juga membuat klaim volume yang persisten fsx-pvc, yang dapat di-mount oleh salah satu pod dalam cluster dengan cara read-write-many (RWX).

Dalam percobaan kami, kami menggunakan data ImageNet lengkap, yang berisi lebih dari 12 juta gambar pelatihan yang dibagi menjadi 1,000 kelas. Data dapat diunduh dari Situs web ImageNet. Bola TAR asli memiliki beberapa direktori, tetapi untuk pelatihan model kami, kami hanya tertarik pada ILSVRC/Data/CLS-LOC/, yang meliputi train dan val subdirektori. Sebelum pelatihan, kita perlu mengatur ulang gambar di val subdirektori agar sesuai dengan struktur direktori yang diperlukan oleh PyTorch Folder Gambar kelas. Hal ini dapat dilakukan dengan menggunakan sederhana Skrip python setelah data disalin ke volume persisten di langkah berikutnya.

Untuk menyalin data dari Layanan Penyimpanan Sederhana Amazon (Amazon S3) ke sistem file FSx, kami membuat gambar Docker yang menyertakan skrip untuk tugas ini. Contoh Dockerfile dan skrip shell disertakan dalam csi folder dalam repo GitHub. Kita dapat membangun gambar menggunakan build.sh skrip dan kemudian Dorong ke Amazon ECR menggunakan push.sh naskah. Sebelum menggunakan skrip ini, kita perlu menyediakan URI yang benar untuk repositori ECR di .env file di folder root repo GitHub. Setelah kami mendorong image Docker ke Amazon ECR, kami dapat meluncurkan pod untuk menyalin data dengan menerapkan file .yaml yang relevan:

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

Pod secara otomatis menjalankan skrip data-persiapan.sh untuk menyalin data dari Amazon S3 ke volume bersama. Karena data ImageNet memiliki lebih dari 12 juta file, proses penyalinan memakan waktu beberapa jam. Skrip Python imagenet_data_prep.py juga dijalankan untuk mengatur ulang val kumpulan data seperti yang diharapkan oleh PyTorch.

Akselerasi jaringan

Kita dapat menggunakan Adaptor Kain Elastis (EFA) dalam kombinasi dengan jenis instans EC2 yang didukung untuk mempercepat lalu lintas jaringan antara node GPU di cluster Anda. Ini dapat berguna saat menjalankan pekerjaan pelatihan terdistribusi besar di mana komunikasi jaringan standar mungkin menjadi hambatan. Skrip untuk menerapkan dan menguji plugin perangkat EFA di kluster EKS yang kami gunakan di sini termasuk dalam efa-perangkat-plugin folder di repo GitHub. Untuk mengaktifkan pekerjaan dengan EFA di klaster EKS Anda, selain node klaster yang memiliki perangkat keras dan lunak yang diperlukan, plugin perangkat EFA perlu diterapkan ke klaster, dan wadah pekerjaan Anda harus memiliki CUDA dan NCCL yang kompatibel Versi diinstal.

Untuk mendemonstrasikan menjalankan pengujian NCCL dan mengevaluasi kinerja EFA pada instance p4d.24xlarge, pertama-tama kita harus men-deploy operator Kubeflow MPI dengan menjalankan yang sesuai menyebarkan.sh naskah di mpi-operator map. Kemudian kita jalankan menyebarkan.sh skrip dan perbarui tes-efa-nccl.yaml nyatakan batasan dan permintaan sumber daya vpc.amazonaws.com diatur ke 4. Empat adaptor EFA yang tersedia di node p4d.24xlarge digabungkan bersama untuk memberikan throughput maksimum.

Run kubectl apply -f ./test-efa-nccl.yaml untuk menerapkan tes dan kemudian menampilkan log dari pod tes. Baris berikut dalam output log mengonfirmasi bahwa EFA sedang digunakan:

NCCL INFO NET/OFI Selected Provider is efa

Hasil tes akan terlihat mirip dengan output berikut:

[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

Kita dapat mengamati dalam hasil pengujian bahwa throughput maksimum sekitar 42 GB/dtk dan bandwidth bus rata-rata sekitar 8 GB.

Kami juga melakukan eksperimen dengan adaptor EFA tunggal yang diaktifkan serta tanpa adaptor EFA. Semua hasil dirangkum dalam tabel berikut.

Jumlah Adaptor EFA	Penyedia Terpilih Net/OFI	Rata-rata Bandwidth (GB/dtk)	Maks. Bandwith (GB/dtk)
4	efa	8.24	42.04
1	efa	3.02	5.89
0	stopkontak	0.97	2.38

Kami juga menemukan bahwa untuk model yang relatif kecil seperti ImageNet, penggunaan jaringan yang dipercepat mengurangi waktu pelatihan per epoch hanya dengan 5-8% pada ukuran batch 64. Untuk model yang lebih besar dan ukuran batch yang lebih kecil, ketika diperlukan peningkatan komunikasi jaringan bobot , penggunaan jaringan yang dipercepat memiliki dampak yang lebih besar. Kami mengamati penurunan waktu pelatihan epoch dengan 15–18% untuk pelatihan EfficientNet-B7 dengan ukuran batch 1. Dampak sebenarnya dari EFA pada pelatihan Anda akan bergantung pada ukuran model Anda.

pemantauan GPU

Sebelum menjalankan pekerjaan pelatihan, kami juga dapat mengatur amazoncloudwatch metrik untuk memvisualisasikan penggunaan GPU selama pelatihan. Akan sangat membantu untuk mengetahui apakah sumber daya digunakan secara optimal atau berpotensi mengidentifikasi kekurangan sumber daya dan kemacetan dalam proses pelatihan.

Skrip yang relevan untuk menyiapkan CloudWatch terletak di gpu-metrik map. Pertama, kami membuat gambar Docker dengan amazon-cloudwatch-agent dan nvidia-smi. Kita dapat menggunakan Dockerfile di gpu-metrics folder untuk membuat gambar ini. Dengan asumsi bahwa registri ECR sudah diatur di .env file dari langkah sebelumnya, kita dapat membangun dan mendorong gambar menggunakan build.sh dan push.sh. Setelah ini, jalankan deploy.sh skrip secara otomatis menyelesaikan pengaturan. Ini meluncurkan daemonset dengan amazon-cloudwatch-agent dan mendorong berbagai metrik ke CloudWatch. Metrik GPU muncul di bawah CWAgent namespace di konsol CloudWatch. Metrik kluster lainnya ditampilkan di bawah ContainerInsights ruang nama.

Pelatihan model

Semua skrip yang diperlukan untuk pelatihan PyTorch terletak di pekerjaan elastis folder di repo GitHub. Sebelum meluncurkan pekerjaan pelatihan, kita perlu menjalankan etcd server, yang digunakan oleh TEC untuk penemuan pekerja dan pertukaran parameter. Itu menyebarkan.sh naskah di elasticjob folder melakukan hal itu.

Untuk memanfaatkan EFA dalam instans p4d.24xlarge, kita perlu menggunakan image Docker tertentu yang tersedia di Galeri Publik Amazon ECR yang mendukung komunikasi NCCL melalui EFA. Kita hanya perlu menyalin kode pelatihan kita ke image Docker ini. Itu Dockerfile bawah sampel folder membuat gambar untuk digunakan saat menjalankan tugas pelatihan pada instans p4d. Seperti biasa, kita bisa menggunakan membangun.sh dan dorong.sh skrip di folder untuk membangun dan mendorong gambar.

Grafik imagenet-efa.yaml file menjelaskan pekerjaan pelatihan. File .yaml ini menyiapkan sumber daya yang diperlukan untuk menjalankan tugas pelatihan dan juga memasang volume persisten dengan data pelatihan yang disiapkan di bagian sebelumnya.

Beberapa hal patut ditunjukkan di sini. Jumlah replika harus diatur ke jumlah node yang tersedia di cluster. Dalam kasus kami, kami menetapkan ini ke 3 karena kami memiliki tiga node p4d.24xlarge. Dalam imagenet-efa.yaml file, file nvidia.com/gpu parameter di bawah sumber daya dan nproc_per_node bawah args harus diatur ke jumlah GPU per node, yang dalam kasus p4d.24xlarge adalah 8. Juga, argumen pekerja untuk skrip Python menetapkan jumlah CPU per proses. Kami memilih ini menjadi 4 karena, dalam eksperimen kami, ini memberikan kinerja optimal saat dijalankan pada instans p4d.24xlarge. Pengaturan ini diperlukan untuk memaksimalkan penggunaan semua sumber daya perangkat keras yang tersedia di cluster.

Saat pekerjaan berjalan, kita dapat mengamati penggunaan GPU di CloudWatch untuk semua GPU di cluster. Berikut ini adalah contoh dari salah satu pekerjaan pelatihan kami dengan tiga node p4d.24xlarge di cluster. Di sini kami telah memilih satu GPU dari setiap node. Dengan pengaturan yang disebutkan sebelumnya, penggunaan GPU mendekati 100% selama fase pelatihan epoch untuk semua node dalam cluster.

Untuk melatih model ResNet50 menggunakan instans p3.8xlarge, kita memerlukan langkah yang persis sama seperti yang dijelaskan untuk pelatihan EfficientNet menggunakan p4d.24xlarge. Kami juga dapat menggunakan gambar Docker yang sama. Seperti disebutkan sebelumnya, instans p3.8xlarge tidak dilengkapi dengan EFA. Namun, untuk model ResNet50, ini bukan kelemahan yang signifikan. Itu imagenet-fsx.yaml skrip yang disediakan di repositori GitHub menyiapkan tugas pelatihan dengan sumber daya yang sesuai untuk jenis simpul p3.8xlarge. Pekerjaan menggunakan dataset yang sama dari sistem file FSx.

penskalaan GPU

Kami menjalankan beberapa eksperimen untuk mengamati bagaimana skala waktu pelatihan untuk model EfficientNet-B7 dengan meningkatkan jumlah GPU. Untuk melakukan ini, kami mengubah jumlah replika dari 1 menjadi 3 dalam file .yaml pelatihan kami untuk setiap pelatihan yang dijalankan. Kami hanya mengamati waktu untuk satu zaman saat menggunakan dataset ImageNet lengkap. Gambar berikut menunjukkan hasil percobaan penskalaan GPU kami. Garis putus-putus merah menunjukkan bagaimana waktu pelatihan harus dikurangi dari lari menggunakan 8 GPU dengan meningkatkan jumlah GPU. Seperti yang bisa kita lihat, penskalaannya cukup dekat dengan apa yang diharapkan.

Demikian pula, kami memperoleh plot penskalaan GPU untuk pelatihan ResNet50 pada instans p3.8xlarge. Untuk kasus ini, kami mengubah replika di file .yaml kami dari 1 menjadi 4. Hasil percobaan ini ditunjukkan pada gambar berikut.

Membersihkan

Sangat penting untuk mengurangi sumber daya setelah pelatihan model untuk menghindari biaya yang terkait dengan menjalankan instans yang tidak digunakan. Dengan setiap skrip yang membuat sumber daya, GitHub repo menyediakan skrip yang cocok untuk menghapusnya. Untuk membersihkan setup kita, kita harus menghapus sistem file FSx sebelum menghapus cluster karena terkait dengan subnet di VPC cluster. Untuk menghapus sistem file FSx, kita hanya perlu menjalankan perintah berikut (dari dalam fsx map):

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

Perhatikan bahwa ini tidak hanya akan menghapus volume persisten, tetapi juga akan menghapus sistem file FSx, dan semua data pada sistem file akan hilang. Ketika langkah ini selesai, kita dapat menghapus cluster dengan menggunakan skrip berikut di: mis folder:

./eks-delete.sh

Ini akan menghapus semua pod yang ada, menghapus cluster, dan menghapus VPC yang dibuat di awal.

Kesimpulan

Dalam posting ini, kami merinci langkah-langkah yang diperlukan untuk menjalankan pelatihan model paralel data terdistribusi PyTorch pada cluster EKS. Tugas ini mungkin tampak menakutkan, tetapi AWS DevOps untuk EKS proyek yang dibuat oleh tim Kerangka Kerja ML di AWS menyediakan semua skrip dan alat yang diperlukan untuk menyederhanakan proses dan membuat pelatihan model terdistribusi mudah diakses.

Untuk informasi lebih lanjut tentang teknologi yang digunakan dalam posting ini, kunjungi Amazon EKS dan Obor Terdistribusi Elastis. Kami mendorong Anda untuk menerapkan pendekatan yang dijelaskan di sini untuk kasus penggunaan pelatihan terdistribusi Anda sendiri.

Sumber

Tentang penulis

Imran Younus adalah Arsitek Solusi Utama untuk tim Kerangka Kerja ML di AWS. Dia berfokus pada pembelajaran mesin skala besar dan beban kerja pembelajaran mendalam di seluruh layanan AWS seperti Amazon EKS dan AWS ParallelCluster. Dia memiliki pengalaman luas dalam aplikasi Deep Leaning dalam Computer Vision dan IoT Industri. Imran memperoleh gelar PhD dalam Fisika Partikel Energi Tinggi di mana ia terlibat dalam menganalisis data eksperimen pada skala peta-byte.

Alex Iankoulski adalah arsitek perangkat lunak dan infrastruktur full-stack yang suka melakukan pekerjaan langsung dan mendalam. Saat ini dia adalah Arsitek Solusi Utama untuk Pembelajaran Mesin yang Dikelola Sendiri di AWS. Dalam perannya, dia berfokus untuk membantu pelanggan dengan containerisasi dan orkestrasi beban kerja ML dan AI pada layanan AWS yang didukung container. Dia juga penulis sumber terbuka Lakukan kerangka kerja dan seorang kapten Docker yang suka menerapkan teknologi kontainer untuk mempercepat laju inovasi sambil memecahkan tantangan terbesar dunia. Selama 10 tahun terakhir, Alex telah berupaya memerangi perubahan iklim, mendemokratisasi AI dan ML, menjadikan perjalanan lebih aman, perawatan kesehatan lebih baik, dan energi lebih cerdas.