Đào tạo phân tán với Amazon EKS và Torch Distributed Elastic

Đào tạo mô hình deep learning phân tán ngày càng trở nên quan trọng khi kích thước dữ liệu ngày càng tăng trong nhiều ngành. Nhiều ứng dụng trong thị giác máy tính và xử lý ngôn ngữ tự nhiên hiện nay yêu cầu đào tạo các mô hình học sâu, vốn ngày càng phức tạp theo cấp số nhân và thường được đào tạo với hàng trăm terabyte dữ liệu. Khi đó, điều quan trọng là sử dụng cơ sở hạ tầng đám mây rộng lớn để mở rộng quy mô đào tạo các mô hình lớn như vậy.

Các nhà phát triển có thể sử dụng các khung nguồn mở như PyTorch để dễ dàng thiết kế các kiến ​​trúc mô hình trực quan. Tuy nhiên, việc mở rộng quy mô đào tạo các mô hình này trên nhiều nút có thể gặp khó khăn do độ phức tạp của việc điều phối tăng lên.

Đào tạo mô hình phân tán chủ yếu bao gồm hai mô hình:

• Mô hình song song – Trong đào tạo song song mô hình, bản thân mô hình lớn đến mức không thể chứa vừa bộ nhớ của một GPU và cần có nhiều GPU để đào tạo mô hình. Mô hình GPT-3 của Open AI với 175 tỷ tham số có thể huấn luyện (kích thước khoảng 350 GB) là một ví dụ điển hình cho điều này.
• Dữ liệu song song – Trong đào tạo song song dữ liệu, mô hình có thể nằm trong một GPU duy nhất, nhưng do dữ liệu quá lớn nên có thể mất vài ngày hoặc vài tuần để đào tạo một mô hình. Việc phân phối dữ liệu trên nhiều nút GPU có thể giảm đáng kể thời gian đào tạo.

Trong bài đăng này, chúng tôi cung cấp một kiến ​​trúc mẫu để huấn luyện các mô hình PyTorch bằng cách sử dụng Ngọn đuốc phân phối đàn hồi framework theo kiểu song song dữ liệu phân tán bằng cách sử dụng Dịch vụ Kubernetes đàn hồi của Amazon (Amazon EKS).

Điều kiện tiên quyết

Để sao chép kết quả được báo cáo trong bài đăng này, điều kiện tiên quyết duy nhất là tài khoản AWS. Trong tài khoản này, chúng tôi tạo một cụm EKS và một Amazon FSx cho ánh hệ thống tập tin. Chúng tôi cũng đẩy hình ảnh vùng chứa lên một Đăng ký container đàn hồi Amazon (Amazon ECR) trong tài khoản. Hướng dẫn thiết lập các thành phần này được cung cấp khi cần thiết trong suốt bài viết.

Cụm EKS

Amazon EKS là dịch vụ bộ chứa được quản lý để chạy và mở rộng quy mô ứng dụng Kubernetes trên AWS. Với Amazon EKS, bạn có thể chạy các công việc đào tạo phân tán một cách hiệu quả bằng cách sử dụng phiên bản mới nhất Đám mây điện toán đàn hồi Amazon (Amazon EC2) mà không cần cài đặt, vận hành và bảo trì mặt phẳng điều khiển hoặc nút của riêng bạn. Nó là một phổ biến dàn nhạc cho quy trình học máy (ML) và AI. Một cụm EKS điển hình trong AWS trông giống như hình sau.

Chúng tôi đã phát hành một dự án nguồn mở, AWS DevOps cho EKS (aws-do-eks), cung cấp một bộ sưu tập lớn các tập lệnh và công cụ dễ sử dụng và có thể định cấu hình để cung cấp các cụm EKS và chạy các công việc đào tạo phân tán. Dự án này được xây dựng theo nguyên tắc của Làm khung: Đơn giản, linh hoạt và phổ quát. Bạn có thể định cấu hình cụm mong muốn của mình bằng cách sử dụng eks.conf tập tin và sau đó khởi chạy nó bằng cách chạy eks-create.sh kịch bản. Hướng dẫn chi tiết được cung cấp trong Repo GitHub.

Huấn luyện các mô hình PyTorch bằng cách sử dụng đàn hồi phân tán Torch

Torch Distributed Elastic (TDE) là thư viện PyTorch gốc để đào tạo các mô hình deep learning quy mô lớn, trong đó việc mở rộng quy mô tài nguyên điện toán một cách linh hoạt dựa trên tính khả dụng là rất quan trọng. Các Bộ điều khiển TorchElastic cho Kubernetes là một triển khai Kubernetes gốc dành cho TDE, tự động quản lý vòng đời của các nhóm và dịch vụ cần thiết cho hoạt động đào tạo TDE. Nó cho phép mở rộng quy mô tài nguyên điện toán một cách linh hoạt trong quá trình đào tạo khi cần thiết. Nó cũng cung cấp đào tạo về khả năng chịu lỗi bằng cách khôi phục các công việc sau lỗi nút.

Trong bài đăng này, chúng tôi thảo luận về các bước để đào tạo PyTorch Hiệu quảNet-B7 và ResNet50 mô hình sử dụng IMAGEnet dữ liệu theo kiểu phân tán với TDE. Chúng tôi sử dụng PyTorch Dữ liệu phân tán song song API và bộ điều khiển Kubernetes TorchElastic, đồng thời chạy các công việc đào tạo của chúng tôi trên cụm EKS chứa nhiều nút GPU. Sơ đồ sau đây thể hiện sơ đồ kiến ​​trúc cho việc đào tạo mô hình này.

TorchElastic cho Kubernetes bao gồm chủ yếu hai thành phần: Bộ điều khiển Kubernetes TorchElastic (TEC) và máy chủ tham số (etcd). Bộ điều khiển chịu trách nhiệm giám sát và quản lý các công việc đào tạo và máy chủ tham số theo dõi các nút công nhân để đồng bộ hóa phân tán và khám phá ngang hàng.

Để các nhóm đào tạo truy cập dữ liệu, chúng tôi cần một khối dữ liệu dùng chung mà mỗi nhóm có thể gắn kết. Một số tùy chọn cho khối lượng được chia sẻ thông qua Giao diện lưu trữ vùng chứa (CSI) trình điều khiển được bao gồm trong AWS DevOps cho EKS đang Hệ thống tệp đàn hồi Amazon (Amazon EFS) và FSx cho Lustre.

Thiết lập cụm

Trong cấu hình cụm của chúng tôi, chúng tôi sử dụng một phiên bản c5.2xlarge cho nhóm hệ thống. Chúng tôi sử dụng ba phiên bản p4d.24xlarge làm nhóm công nhân để huấn luyện mô hình EfficiencyNet. Để đào tạo ResNet50, chúng tôi sử dụng phiên bản p3.8xlarge làm nhóm công nhân. Ngoài ra, chúng tôi sử dụng hệ thống tệp chia sẻ FSx để lưu trữ dữ liệu đào tạo và các tạo phẩm mô hình của mình.

Phiên bản AWS p4d.24xlarge được trang bị Bộ điều hợp vải đàn hồi (EFA) để cung cấp kết nối mạng giữa các nút. Chúng ta sẽ thảo luận thêm về EFA ở phần sau của bài viết. Để kích hoạt giao tiếp qua EFA, chúng ta cần định cấu hình thiết lập cụm thông qua tệp .yaml. MỘT tập tin ví dụ được cung cấp trong kho GitHub.

Sau khi tệp .yaml này được định cấu hình đúng cách, chúng ta có thể khởi chạy cụm bằng tập lệnh được cung cấp trong kho GitHub:

./eks-create.sh

Tham khảo đến Repo GitHub để có hướng dẫn chi tiết.

Thực tế không có sự khác biệt giữa các công việc đang chạy trên p4d.24xlarge và p3.8xlarge. Các bước được mô tả trong bài đăng này có hiệu quả cho cả hai. Sự khác biệt duy nhất là tính khả dụng của EFA trên các phiên bản p4d.24xlarge. Đối với các mô hình nhỏ hơn như ResNet50, mạng tiêu chuẩn so với mạng EFA có tác động tối thiểu đến tốc độ đào tạo.

FSx cho hệ thống tập tin Lustre

FSx được thiết kế cho khối lượng công việc tính toán hiệu suất cao và cung cấp độ trễ dưới một phần nghìn giây khi sử dụng ổ lưu trữ thể rắn. Chúng tôi chọn FSx vì nó mang lại hiệu suất tốt hơn khi chúng tôi mở rộng quy mô thành một số lượng lớn nút. Một chi tiết quan trọng cần lưu ý là FSx chỉ có thể tồn tại trong một Vùng sẵn sàng duy nhất. Do đó, tất cả các nút truy cập hệ thống tệp FSx phải tồn tại trong cùng Vùng sẵn sàng với hệ thống tệp FSx. Một cách để đạt được điều này là chỉ định Vùng sẵn sàng liên quan trong tệp .yaml cụm cho các nhóm nút cụ thể trước khi tạo cụm. Ngoài ra, chúng tôi có thể sửa đổi phần mạng của nhóm tự động mở rộng quy mô cho các nút này sau khi cụm được thiết lập và giới hạn nó ở mức sử dụng một mạng con duy nhất. Điều này có thể được thực hiện dễ dàng trên bảng điều khiển Amazon EC2.

Giả sử rằng cụm EKS đang hoạt động và ID mạng con cho Vùng sẵn sàng đã được biết, chúng tôi có thể thiết lập hệ thống tệp FSx bằng cách cung cấp thông tin cần thiết trong fsx.conf tệp như được mô tả trong readme và chạy triển khai.sh kịch bản trong fsx thư mục. Điều này thiết lập chính sách chính xác và nhóm bảo mật để truy cập hệ thống tệp. Kịch bản cũng cài đặt Trình điều khiển CSI cho FSx dưới dạng daemonset. Cuối cùng, chúng ta có thể tạo yêu cầu khối lượng liên tục FSx trong Kubernetes bằng cách áp dụng một tệp .yaml duy nhất:

kubectl apply -f fsx-pvc-dynamic.yaml

Điều này tạo ra một hệ thống tệp FSx trong Vùng sẵn sàng được chỉ định trong fsx.conf tập tin và cũng tạo ra một xác nhận quyền sở hữu khối lượng liên tục fsx-pvc, có thể được gắn bởi bất kỳ nhóm nào trong cụm theo kiểu đọc-ghi-nhiều (RWX).

Trong thử nghiệm của mình, chúng tôi đã sử dụng dữ liệu ImageNet hoàn chỉnh, chứa hơn 12 triệu hình ảnh đào tạo được chia thành 1,000 lớp. Dữ liệu có thể được tải xuống từ Trang web ImageNet. Quả bóng TAR ban đầu có một số thư mục, nhưng đối với việc đào tạo mô hình, chúng tôi chỉ quan tâm đến ILSVRC/Data/CLS-LOC/, bao gồm train và val các thư mục con. Trước khi huấn luyện, chúng ta cần sắp xếp lại các hình ảnh trong val thư mục con để phù hợp với cấu trúc thư mục theo yêu cầu của PyTorch Thư mục hình ảnh lớp học. Điều này có thể được thực hiện bằng cách sử dụng một cách đơn giản Tập lệnh Python sau khi dữ liệu được sao chép sang ổ đĩa cố định ở bước tiếp theo.

Để sao chép dữ liệu từ một Dịch vụ lưu trữ đơn giản của Amazon (Amazon S3) vào hệ thống tệp FSx, chúng tôi tạo hình ảnh Docker bao gồm các tập lệnh cho tác vụ này. Một ví dụ Dockerfile và tập lệnh shell được bao gồm trong csi thư mục trong kho GitHub. Chúng ta có thể xây dựng hình ảnh bằng cách sử dụng build.sh tập lệnh rồi đẩy nó lên Amazon ECR bằng cách sử dụng push.sh kịch bản. Trước khi sử dụng các tập lệnh này, chúng tôi cần cung cấp URI chính xác cho kho lưu trữ ECR trong .env tập tin trong thư mục gốc của repo GitHub. Sau khi đẩy hình ảnh Docker lên Amazon ECR, chúng ta có thể khởi chạy một nhóm để sao chép dữ liệu bằng cách áp dụng tệp .yaml có liên quan:

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

Nhóm tự động chạy tập lệnh dữ liệu-prep.sh để sao chép dữ liệu từ Amazon S3 sang ổ đĩa chung. Vì dữ liệu ImageNet có hơn 12 triệu tệp nên quá trình sao chép sẽ mất vài giờ. Tập lệnh Python imagenet_data_prep.py cũng được chạy để sắp xếp lại val tập dữ liệu như mong đợi của PyTorch.

Tăng tốc mạng

Chúng ta có thể sử dụng Elastic Fabric Adaptor (EFA) kết hợp với các loại phiên bản EC2 được hỗ trợ để tăng tốc lưu lượng mạng giữa các nút GPU trong cụm của bạn. Điều này có thể hữu ích khi thực hiện các công việc đào tạo phân tán lớn trong đó giao tiếp mạng tiêu chuẩn có thể bị tắc nghẽn. Các tập lệnh để triển khai và kiểm tra plugin thiết bị EFA trong cụm EKS mà chúng tôi sử dụng ở đây được bao gồm trong plugin thiết bị efa thư mục trong kho GitHub. Để kích hoạt công việc với EFA trong cụm EKS của bạn, ngoài các nút cụm có phần cứng và phần mềm cần thiết, plugin thiết bị EFA cần được triển khai vào cụm và vùng chứa công việc của bạn cần phải có CUDA và NCCL tương thích phiên bản cài đặt.

Để chứng minh việc chạy thử nghiệm NCCL và đánh giá hiệu suất của EFA trên các phiên bản p4d.24xlarge, trước tiên chúng tôi phải triển khai toán tử Kubeflow MPI bằng cách chạy lệnh tương ứng triển khai.sh kịch bản trong toán tử mpi thư mục. Sau đó chúng tôi chạy triển khai.sh tập lệnh và cập nhật test-efa-nccl.yaml biểu hiện các giới hạn và yêu cầu về tài nguyên vpc.amazonaws.com được đặt thành 4. Bốn bộ điều hợp EFA có sẵn trong các nút p4d.24xlarge được nhóm lại với nhau để cung cấp thông lượng tối đa.

chạy kubectl apply -f ./test-efa-nccl.yaml để áp dụng thử nghiệm và sau đó hiển thị nhật ký của nhóm thử nghiệm. Dòng sau trong đầu ra nhật ký xác nhận rằng EFA đang được sử dụng:

NCCL INFO NET/OFI Selected Provider is efa

Kết quả kiểm tra sẽ trông giống như kết quả đầu ra sau:

[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

Chúng ta có thể quan sát trong kết quả thử nghiệm rằng thông lượng tối đa là khoảng 42 GB/giây và băng thông bus trung bình là khoảng 8 GB.

Chúng tôi cũng đã tiến hành thử nghiệm với một bộ chuyển đổi EFA duy nhất được kích hoạt cũng như không có bộ chuyển đổi EFA nào. Tất cả các kết quả được tóm tắt trong bảng sau.

Chúng tôi cũng nhận thấy rằng đối với các mô hình tương đối nhỏ như ImageNet, việc sử dụng mạng tăng tốc chỉ giúp giảm thời gian đào tạo trên mỗi kỷ nguyên với 5–8% ở kích thước lô là 64. Đối với các mô hình lớn hơn và kích thước lô nhỏ hơn, khi cần tăng cường giao tiếp mạng về trọng số , việc sử dụng mạng tăng tốc có tác động lớn hơn. Chúng tôi nhận thấy thời gian đào tạo kỷ nguyên giảm từ 15–18% đối với đào tạo EfficiencyNet-B7 với quy mô lô 1. Tác động thực tế của EFA đối với quá trình đào tạo của bạn sẽ phụ thuộc vào quy mô mô hình của bạn.

Giám sát GPU

Trước khi chạy công việc đào tạo, chúng ta cũng có thể thiết lập amazoncloudwatch số liệu để trực quan hóa việc sử dụng GPU trong quá trình đào tạo. Có thể hữu ích nếu biết liệu các tài nguyên có đang được sử dụng một cách tối ưu hay có khả năng xác định được tình trạng thiếu tài nguyên và tắc nghẽn trong quá trình đào tạo hay không.

Các tập lệnh liên quan để thiết lập CloudWatch nằm trong số liệu gpu thư mục. Đầu tiên, chúng ta tạo một Docker image với amazon-cloudwatch-agent và nvidia-smi. Chúng ta có thể sử dụng Dockerfile trong gpu-metrics thư mục để tạo hình ảnh này. Giả sử rằng sổ đăng ký ECR đã được đặt trong .env tập tin từ bước trước, chúng ta có thể xây dựng và đẩy hình ảnh bằng cách sử dụng build.sh và push.sh. Sau đó, chạy deploy.sh tập lệnh tự động hoàn tất thiết lập. Nó khởi chạy một daemonset với amazon-cloudwatch-agent và đẩy nhiều số liệu khác nhau lên CloudWatch. Số liệu GPU xuất hiện bên dưới CWAgent không gian tên trên bảng điều khiển CloudWatch. Phần còn lại của số liệu cụm hiển thị bên dưới ContainerInsights không gian tên.

Đào tạo người mẫu

Tất cả các tập lệnh cần thiết cho việc đào tạo PyTorch đều nằm trong đàn hồi thư mục trong kho GitHub. Trước khi bắt đầu công việc đào tạo, chúng ta cần chạy etcd máy chủ, được TEC sử dụng để khám phá công nhân và trao đổi tham số. Các triển khai.sh kịch bản trong elasticjob thư mục thực hiện chính xác điều đó.

Để tận dụng EFA trong các phiên bản p4d.24xlarge, chúng ta cần sử dụng hình ảnh Docker cụ thể có sẵn trong Thư viện công cộng Amazon ECR hỗ trợ giao tiếp NCCL thông qua EFA. Chúng ta chỉ cần sao chép mã đào tạo của mình vào hình ảnh Docker này. Các Dockerfile theo mẫu thư mục tạo một hình ảnh để sử dụng khi chạy công việc đào tạo trên phiên bản p4d. Như mọi khi, chúng ta có thể sử dụng xây dựng.sh và đẩy.sh tập lệnh trong thư mục để xây dựng và đẩy hình ảnh.

Sản phẩm imagenet-efa.yaml tập tin mô tả công việc đào tạo. Tệp .yaml này thiết lập các tài nguyên cần thiết để chạy công việc đào tạo và cũng gắn khối lượng liên tục với dữ liệu đào tạo được thiết lập trong phần trước.

Có một vài điều đáng được chỉ ra ở đây. Số lượng bản sao phải được đặt thành số lượng nút có sẵn trong cụm. Trong trường hợp của chúng tôi, chúng tôi đặt giá trị này thành 3 vì chúng tôi có ba nút p4d.24xlarge. bên trong imagenet-efa.yaml tập tin nvidia.com/gpu tham số theo tài nguyên và nproc_per_node Dưới args nên được đặt thành số lượng GPU trên mỗi nút, trong trường hợp p4d.24xlarge là 8. Ngoài ra, đối số worker cho tập lệnh Python sẽ đặt số lượng CPU trên mỗi quy trình. Chúng tôi chọn giá trị này là 4 vì trong các thử nghiệm của chúng tôi, giá trị này mang lại hiệu suất tối ưu khi chạy trên các phiên bản p4d.24xlarge. Những cài đặt này là cần thiết để tối đa hóa việc sử dụng tất cả các tài nguyên phần cứng có sẵn trong cụm.

Khi tác vụ đang chạy, chúng tôi có thể quan sát mức sử dụng GPU trong CloudWatch của tất cả các GPU trong cụm. Sau đây là ví dụ từ một trong các công việc đào tạo của chúng tôi với ba nút p4d.24xlarge trong cụm. Ở đây chúng tôi đã chọn một GPU từ mỗi nút. Với các cài đặt được đề cập trước đó, mức sử dụng GPU gần 100% trong giai đoạn huấn luyện của kỷ nguyên cho tất cả các nút trong cụm.

Để đào tạo mô hình ResNet50 bằng cách sử dụng phiên bản p3.8xlarge, chúng tôi cần các bước tương tự như được mô tả cho quá trình đào tạo EfficiencyNet bằng p4d.24xlarge. Chúng ta cũng có thể sử dụng cùng một Docker image. Như đã đề cập trước đó, phiên bản p3.8xlarge không được trang bị EFA. Tuy nhiên, đối với mẫu ResNet50, đây không phải là nhược điểm đáng kể. Các imagenet-fsx.yaml tập lệnh được cung cấp trong kho lưu trữ GitHub sẽ thiết lập công việc đào tạo với các tài nguyên thích hợp cho loại nút p3.8xlarge. Công việc sử dụng cùng một tập dữ liệu từ hệ thống tệp FSx.

Chia tỷ lệ GPU

Chúng tôi đã chạy một số thử nghiệm để quan sát quy mô thời gian đào tạo cho mô hình EfficiencyNet-B7 bằng cách tăng số lượng GPU. Để làm điều này, chúng tôi đã thay đổi số lượng bản sao từ 1 thành 3 trong tệp .yaml huấn luyện của mình cho mỗi lần huấn luyện. Chúng tôi chỉ quan sát thời gian trong một kỷ nguyên duy nhất trong khi sử dụng bộ dữ liệu ImageNet hoàn chỉnh. Hình dưới đây hiển thị kết quả cho thử nghiệm mở rộng quy mô GPU của chúng tôi. Đường chấm màu đỏ biểu thị mức độ giảm thời gian đào tạo sau khi chạy sử dụng 8 GPU bằng cách tăng số lượng GPU. Như chúng ta có thể thấy, tỷ lệ này khá gần với những gì được mong đợi.

Tương tự, chúng tôi thu được sơ đồ chia tỷ lệ GPU để đào tạo ResNet50 trên các phiên bản p3.8xlarge. Trong trường hợp này, chúng tôi đã thay đổi các bản sao trong tệp .yaml của mình từ 1 thành 4. Kết quả của thử nghiệm này được hiển thị trong hình sau.

Làm sạch

Điều quan trọng là phải rút bớt tài nguyên sau khi đào tạo mô hình để tránh chi phí liên quan đến việc chạy các phiên bản không hoạt động. Với mỗi tập lệnh tạo tài nguyên, Repo GitHub cung cấp một tập lệnh phù hợp để xóa chúng. Để dọn dẹp thiết lập của chúng tôi, chúng tôi phải xóa hệ thống tệp FSx trước khi xóa cụm vì nó được liên kết với mạng con trong VPC của cụm. Để xóa hệ thống tệp FSx, chúng ta chỉ cần chạy lệnh sau (từ bên trong fsx thư mục):

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

Lưu ý rằng thao tác này sẽ không chỉ xóa ổ đĩa liên tục mà còn xóa hệ thống tệp FSx và tất cả dữ liệu trên hệ thống tệp sẽ bị mất. Khi bước này hoàn tất, chúng ta có thể xóa cụm bằng cách sử dụng tập lệnh sau trong Ví dụ thư mục:

./eks-delete.sh

Thao tác này sẽ xóa tất cả các nhóm hiện có, xóa cụm và xóa VPC đã tạo từ đầu.

Kết luận

Trong bài đăng này, chúng tôi đã trình bày chi tiết các bước cần thiết để chạy đào tạo mô hình song song dữ liệu phân tán PyTorch trên các cụm EKS. Nhiệm vụ này có vẻ khó khăn nhưng AWS DevOps cho EKS dự án do nhóm ML Frameworks tại AWS tạo ra cung cấp tất cả các tập lệnh và công cụ cần thiết để đơn giản hóa quy trình và giúp việc đào tạo mô hình phân tán có thể dễ dàng truy cập.

Để biết thêm thông tin về các công nghệ được sử dụng trong bài đăng này, hãy truy cập Amazon EKS và Ngọn đuốc phân phối đàn hồi. Chúng tôi khuyến khích bạn áp dụng phương pháp được mô tả ở đây cho các trường hợp sử dụng đào tạo phân tán của riêng bạn.

Thông tin

Giới thiệu về tác giả

Imran Younus là Kiến trúc sư giải pháp chính cho nhóm ML Framework tại AWS. Anh tập trung vào khối lượng công việc machine learning và deep learning quy mô lớn trên các dịch vụ AWS như Amazon EKS và AWS ParallelCluster. Anh có nhiều kinh nghiệm về ứng dụng Deep Leaning trong Thị giác máy tính và IoT công nghiệp. Imran lấy bằng Tiến sĩ về Vật lý Hạt Năng lượng Cao, nơi ông đã tham gia phân tích dữ liệu thực nghiệm ở quy mô peta-byte.

Alex Iankoulski là một kiến ​​trúc sư cơ sở hạ tầng và phần mềm full-stack thích làm những công việc chuyên sâu, thực hành. Anh hiện là Kiến trúc sư giải pháp chính cho Học máy tự quản lý tại AWS. Trong vai trò của mình, anh ấy tập trung vào việc giúp khách hàng container hóa và điều phối khối lượng công việc ML và AI trên các dịch vụ AWS hỗ trợ container. Anh ấy cũng là tác giả của mã nguồn mở Làm khuôn khổ và một đội trưởng Docker, người thích áp dụng công nghệ container để đẩy nhanh tốc độ đổi mới đồng thời giải quyết những thách thức lớn nhất trên thế giới. Trong 10 năm qua, Alex đã nỗ lực chống biến đổi khí hậu, dân chủ hóa AI và ML, giúp việc đi lại an toàn hơn, chăm sóc sức khỏe tốt hơn và năng lượng thông minh hơn.