Κατανεμημένη εκπαίδευση με το Amazon EKS και το Torch Distributed Elastic

Η εκπαίδευση του κατανεμημένου μοντέλου βαθιάς μάθησης γίνεται όλο και πιο σημαντική καθώς τα μεγέθη δεδομένων αυξάνονται σε πολλούς κλάδους. Πολλές εφαρμογές στην όραση υπολογιστών και την επεξεργασία φυσικής γλώσσας απαιτούν πλέον εκπαίδευση μοντέλων βαθιάς μάθησης, τα οποία αυξάνονται εκθετικά σε πολυπλοκότητα και συχνά εκπαιδεύονται με εκατοντάδες terabyte δεδομένων. Στη συνέχεια, καθίσταται σημαντικό να χρησιμοποιηθεί μια τεράστια υποδομή cloud για την κλιμάκωση της εκπαίδευσης τέτοιων μεγάλων μοντέλων.

Οι προγραμματιστές μπορούν να χρησιμοποιήσουν πλαίσια ανοιχτού κώδικα όπως το PyTorch για να σχεδιάσουν εύκολα έξυπνες αρχιτεκτονικές μοντέλων. Ωστόσο, η κλιμάκωση της εκπαίδευσης αυτών των μοντέλων σε πολλούς κόμβους μπορεί να είναι δύσκολη λόγω της αυξημένης πολυπλοκότητας της ενορχήστρωσης.

Η εκπαίδευση κατανεμημένων μοντέλων αποτελείται κυρίως από δύο παραδείγματα:

• Μοντέλο παράλληλο – Στην παράλληλη εκπαίδευση μοντέλου, το ίδιο το μοντέλο είναι τόσο μεγάλο που δεν μπορεί να χωρέσει στη μνήμη μιας μεμονωμένης GPU και απαιτούνται πολλές GPU για την εκπαίδευση του μοντέλου. Το μοντέλο GPT-3 του Open AI με 175 δισεκατομμύρια εκπαιδεύσιμες παραμέτρους (μέγεθος περίπου 350 GB) είναι ένα καλό παράδειγμα αυτού.
• Δεδομένα παράλληλα – Στην παράλληλη εκπαίδευση δεδομένων, το μοντέλο μπορεί να βρίσκεται σε μια ενιαία GPU, αλλά επειδή τα δεδομένα είναι τόσο μεγάλα, μπορεί να χρειαστούν μέρες ή εβδομάδες για να εκπαιδευτεί ένα μοντέλο. Η διανομή των δεδομένων σε πολλούς κόμβους GPU μπορεί να μειώσει σημαντικά τον χρόνο εκπαίδευσης.

Σε αυτήν την ανάρτηση, παρέχουμε ένα παράδειγμα αρχιτεκτονικής για την εκπαίδευση μοντέλων PyTorch χρησιμοποιώντας το Φακός Κατανεμημένο Ελαστικό πλαίσιο με παράλληλο τρόπο κατανεμημένων δεδομένων χρησιμοποιώντας Υπηρεσία Amazon Elastic Kubernetes (Amazon EKS).

Προϋποθέσεις

Για την αναπαραγωγή των αποτελεσμάτων που αναφέρονται σε αυτήν την ανάρτηση, η μόνη προϋπόθεση είναι ένας λογαριασμός AWS. Σε αυτόν τον λογαριασμό, δημιουργούμε ένα σύμπλεγμα EKS και ένα Amazon FSx για λάμψη σύστημα αρχείων. Σπρώχνουμε επίσης εικόνες κοντέινερ σε ένα Μητρώο εμπορευματοκιβωτίων Amazon Elastic (Amazon ECR) αποθετήριο στο λογαριασμό. Οδηγίες για τη ρύθμιση αυτών των στοιχείων παρέχονται όπως απαιτείται σε όλη τη δημοσίευση.

Συστάδες EKS

Το Amazon EKS είναι μια διαχειριζόμενη υπηρεσία κοντέινερ για την εκτέλεση και την κλιμάκωση εφαρμογών Kubernetes στο AWS. Με το Amazon EKS, μπορείτε να εκτελέσετε αποτελεσματικά κατανεμημένες εργασίες κατάρτισης χρησιμοποιώντας την πιο πρόσφατη έκδοση Amazon Elastic Compute Cloud (Amazon EC2) παρουσίες χωρίς να χρειάζεται να εγκαταστήσετε, να χειριστείτε και να διατηρήσετε το δικό σας επίπεδο ελέγχου ή κόμβους. Είναι ένα δημοφιλές ενορχηστρωτής για μηχανική εκμάθηση (ML) και ροές εργασίας AI. Ένα τυπικό σύμπλεγμα EKS στο AWS μοιάζει με το παρακάτω σχήμα.

Έχουμε κυκλοφορήσει ένα έργο ανοιχτού κώδικα, AWS DevOps για EKS (aws-do-eks), το οποίο παρέχει μια μεγάλη συλλογή από εύχρηστα και διαμορφώσιμα σενάρια και εργαλεία για την παροχή συμπλεγμάτων EKS και την εκτέλεση κατανεμημένων εργασιών εκπαίδευσης. Αυτό το έργο είναι κατασκευασμένο σύμφωνα με τις αρχές του Κάντε το πλαίσιο: Απλότητα, ευελιξία και καθολικότητα. Μπορείτε να διαμορφώσετε το σύμπλεγμα που θέλετε χρησιμοποιώντας το eks.conf αρχείο και στη συνέχεια εκκινήστε το εκτελώντας το εκ-δημιουργώ.σ γραφή. Αναλυτικές οδηγίες παρέχονται στο GitHub repo.

Εκπαιδεύστε τα μοντέλα PyTorch χρησιμοποιώντας το Torch Distributed Elastic

Το Torch Distributed Elastic (TDE) είναι μια εγγενής βιβλιοθήκη PyTorch για την εκπαίδευση μοντέλων βαθιάς εκμάθησης μεγάλης κλίμακας, όπου είναι κρίσιμο να κλιμακωθεί ο υπολογισμός των πόρων δυναμικά με βάση τη διαθεσιμότητα. ο TorchElastic Controller για Kubernetes είναι μια εγγενής υλοποίηση Kubernetes για TDE που διαχειρίζεται αυτόματα τον κύκλο ζωής των pods και των υπηρεσιών που απαιτούνται για την εκπαίδευση TDE. Επιτρέπει τη δυναμική κλιμάκωση των υπολογιστικών πόρων κατά τη διάρκεια της εκπαίδευσης, όπως απαιτείται. Παρέχει επίσης εκπαίδευση ανεκτική σε σφάλματα με την ανάκτηση εργασιών από την αστοχία κόμβου.

Σε αυτήν την ανάρτηση, συζητάμε τα βήματα για την εκπαίδευση του PyTorch EfficientNet-B7 και ResNet50 μοντέλα που χρησιμοποιούν IMAGEnet δεδομένα με κατανεμημένο τρόπο με TDE. Χρησιμοποιούμε το PyTorch Κατανεμημένα δεδομένα παράλληλα API και τον ελεγκτή Kubernetes TorchElastic και εκτελέστε τις εκπαιδευτικές μας εργασίες σε ένα σύμπλεγμα EKS που περιέχει πολλούς κόμβους GPU. Το παρακάτω διάγραμμα δείχνει το διάγραμμα αρχιτεκτονικής για αυτό το μοντέλο εκπαίδευσης.

Το TorchElastic για Kubernetes αποτελείται κυρίως από δύο στοιχεία: τον ελεγκτή TorchElastic Kubernetes (TEC) και τον διακομιστή παραμέτρων (κ.λπ.). Ο ελεγκτής είναι υπεύθυνος για την παρακολούθηση και τη διαχείριση των εργασιών εκπαίδευσης και ο διακομιστής παραμέτρων παρακολουθεί τους κόμβους εργαζομένων για κατανεμημένο συγχρονισμό και ανακάλυψη ομοτίμων.

Προκειμένου οι ομάδες εκπαίδευσης να έχουν πρόσβαση στα δεδομένα, χρειαζόμαστε έναν κοινόχρηστο όγκο δεδομένων που μπορεί να προσαρτηθεί από κάθε ομάδα. Ορισμένες επιλογές για κοινόχρηστους τόμους μέσω Διεπαφή αποθήκευσης κοντέινερ (CSI) προγράμματα οδήγησης που περιλαμβάνονται σε AWS DevOps για EKS are Σύστημα αρχείων ελαστικού Amazon (Amazon EFS) και FSx για Luster.

Ρύθμιση συμπλέγματος

Στη διαμόρφωση συμπλέγματός μας, χρησιμοποιούμε μία παρουσία c5.2xlarge για ομάδες ομάδων συστήματος. Χρησιμοποιούμε τρεις περιπτώσεις p4d.24xlarge ως ομάδες εργασίας για να εκπαιδεύσουμε ένα μοντέλο EfficientNet. Για εκπαίδευση ResNet50, χρησιμοποιούμε παρουσίες p3.8xlarge ως ομάδες εργασίας. Επιπλέον, χρησιμοποιούμε ένα κοινόχρηστο σύστημα αρχείων FSx για την αποθήκευση των δεδομένων εκπαίδευσης και των τεχνουργημάτων μοντέλων.

Οι μεγάλες παρουσίες AWS p4d.24x είναι εξοπλισμένες με Ελαστικός προσαρμογέας υφάσματος (EFA) για την παροχή δικτύωσης μεταξύ κόμβων. Θα συζητήσουμε περισσότερα για την EFA αργότερα στην ανάρτηση. Για να ενεργοποιήσουμε την επικοινωνία μέσω EFA, πρέπει να διαμορφώσουμε τη ρύθμιση του συμπλέγματος μέσω ενός αρχείου .yaml. Ενα παράδειγμα αρχείου παρέχεται στο αποθετήριο GitHub.

Αφού ρυθμιστεί σωστά αυτό το αρχείο .yaml, μπορούμε να εκκινήσουμε το σύμπλεγμα χρησιμοποιώντας το σενάριο που παρέχεται στο αποθετήριο GitHub:

./eks-create.sh

Αναφέρομαι στο GitHub repo για λεπτομερείς οδηγίες.

Πρακτικά δεν υπάρχει διαφορά μεταξύ εκτέλεσης εργασιών σε p4d.24xlarge και p3.8xlarge. Τα βήματα που περιγράφονται σε αυτήν την ανάρτηση λειτουργούν και για τα δύο. Η μόνη διαφορά είναι η διαθεσιμότητα EFA σε p4d.24xlarge περιπτώσεις. Για μικρότερα μοντέλα όπως το ResNet50, η τυπική δικτύωση σε σύγκριση με τη δικτύωση EFA έχει ελάχιστο αντίκτυπο στην ταχύτητα της προπόνησης.

Σύστημα αρχείων FSx for Luster

Το FSx έχει σχεδιαστεί για υπολογιστικούς φόρτους εργασίας υψηλής απόδοσης και παρέχει καθυστέρηση κάτω του χιλιοστού του δευτερολέπτου χρησιμοποιώντας όγκους αποθήκευσης μονάδας δίσκου στερεάς κατάστασης. Επιλέξαμε το FSx επειδή παρείχε καλύτερη απόδοση καθώς κλιμακωθήκαμε σε μεγάλο αριθμό κόμβων. Μια σημαντική λεπτομέρεια που πρέπει να σημειωθεί είναι ότι το FSx μπορεί να υπάρχει μόνο σε μία μόνο Ζώνη Διαθεσιμότητας. Επομένως, όλοι οι κόμβοι που έχουν πρόσβαση στο σύστημα αρχείων FSx θα πρέπει να υπάρχουν στην ίδια Ζώνη Διαθεσιμότητας με το σύστημα αρχείων FSx. Ένας τρόπος για να επιτευχθεί αυτό είναι να καθορίσετε τη σχετική Ζώνη Διαθεσιμότητας στο αρχείο συμπλέγματος .yaml για τις συγκεκριμένες ομάδες κόμβων πριν από τη δημιουργία του συμπλέγματος. Εναλλακτικά, μπορούμε να τροποποιήσουμε το τμήμα δικτύου της ομάδας αυτόματης κλίμακας για αυτούς τους κόμβους μετά τη ρύθμιση του συμπλέγματος και να το περιορίσουμε στη χρήση ενός μόνο υποδικτύου. Αυτό μπορεί να γίνει εύκολα στην κονσόλα Amazon EC2.

Υποθέτοντας ότι το σύμπλεγμα EKS είναι σε λειτουργία και είναι γνωστό το αναγνωριστικό υποδικτύου για τη ζώνη διαθεσιμότητας, μπορούμε να ρυθμίσουμε ένα σύστημα αρχείων FSx παρέχοντας τις απαραίτητες πληροφορίες στο fsx.conf αρχείο όπως περιγράφεται στο readme και τρέχοντας το αναπτύξτε.sh σενάριο στο FSX ντοσιέ. Αυτό ρυθμίζει τη σωστή ομάδα πολιτικής και ασφάλειας για την πρόσβαση στο σύστημα αρχείων. Το σενάριο εγκαθιστά επίσης το Πρόγραμμα οδήγησης CSI για το FSx ως σύνολο δαίμονα. Τέλος, μπορούμε να δημιουργήσουμε την αξίωση μόνιμου όγκου FSx στο Kubernetes εφαρμόζοντας ένα μόνο αρχείο .yaml:

kubectl apply -f fsx-pvc-dynamic.yaml

Αυτό δημιουργεί ένα σύστημα αρχείων FSx στη Ζώνη Διαθεσιμότητας που καθορίζεται στο fsx.conf αρχείο, και δημιουργεί επίσης μια μόνιμη αξίωση τόμου fsx-pvc, το οποίο μπορεί να τοποθετηθεί από οποιοδήποτε από τα pod στο σύμπλεγμα με τρόπο ανάγνωσης-εγγραφής-πολλά (RWX).

Στο πείραμά μας, χρησιμοποιήσαμε πλήρη δεδομένα ImageNet, τα οποία περιέχουν περισσότερες από 12 εκατομμύρια εικόνες εκπαίδευσης χωρισμένες σε 1,000 τάξεις. Τα δεδομένα μπορούν να ληφθούν από το Ιστοσελίδα ImageNet. Η αρχική μπάλα TAR έχει πολλούς καταλόγους, αλλά για την εκπαίδευση μοντέλων μας, μας ενδιαφέρει μόνο ILSVRC/Data/CLS-LOC/, που περιλαμβάνει το train και val υποκαταλόγους. Πριν από την προπόνηση, πρέπει να αναδιατάξουμε τις εικόνες στο val υποκατάλογο για να ταιριάζει με τη δομή καταλόγου που απαιτείται από το PyTorch ImageFolder τάξη. Αυτό μπορεί να γίνει χρησιμοποιώντας ένα απλό Σενάριο Python αφού τα δεδομένα αντιγραφούν στον μόνιμο τόμο στο επόμενο βήμα.

Για να αντιγράψετε τα δεδομένα από ένα Απλή υπηρεσία αποθήκευσης Amazon (Amazon S3) στο σύστημα αρχείων FSx, δημιουργούμε μια εικόνα Docker που περιλαμβάνει σενάρια για αυτήν την εργασία. Ένα παράδειγμα Dockerfile και ένα σενάριο φλοιού περιλαμβάνονται στο csi φάκελο μέσα στο αποθετήριο GitHub. Μπορούμε να δημιουργήσουμε την εικόνα χρησιμοποιώντας το build.sh script και, στη συνέχεια, σπρώξτε το στο Amazon ECR χρησιμοποιώντας το push.sh γραφή. Πριν χρησιμοποιήσουμε αυτά τα σενάρια, πρέπει να παρέχουμε το σωστό URI για το αποθετήριο ECR στο .env αρχείο στον ριζικό φάκελο του αποθετηρίου GitHub. Αφού ωθήσουμε την εικόνα Docker στο Amazon ECR, μπορούμε να ξεκινήσουμε ένα pod για να αντιγράψουμε τα δεδομένα εφαρμόζοντας το σχετικό αρχείο .yaml:

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

Το pod εκτελεί αυτόματα το σενάριο data-prep.sh για να αντιγράψετε τα δεδομένα από το Amazon S3 στον κοινόχρηστο τόμο. Επειδή τα δεδομένα ImageNet έχουν περισσότερα από 12 εκατομμύρια αρχεία, η διαδικασία αντιγραφής διαρκεί μερικές ώρες. Το σενάριο Python imagenet_data_prep.py τρέχει επίσης για να αναδιατάξει το val σύνολο δεδομένων όπως αναμενόταν από το PyTorch.

Επιτάχυνση δικτύου

Μπορούμε να χρησιμοποιήσουμε Elastic Fabric Adapter (EFA) σε συνδυασμό με υποστηριζόμενοι τύποι παρουσιών EC2 για να επιταχύνετε την κυκλοφορία δικτύου μεταξύ των κόμβων GPU στο σύμπλεγμα σας. Αυτό μπορεί να είναι χρήσιμο κατά την εκτέλεση μεγάλων κατανεμημένων εργασιών εκπαίδευσης όπου η τυπική επικοινωνία δικτύου μπορεί να αποτελεί εμπόδιο. Σενάρια για την ανάπτυξη και τη δοκιμή της προσθήκης συσκευής EFA στο σύμπλεγμα EKS που χρησιμοποιούμε εδώ περιλαμβάνονται στο efa-συσκευή-πρόσθετο φάκελο στο αποθετήριο GitHub. Για να ενεργοποιήσετε μια εργασία με EFA στο σύμπλεγμα EKS σας, εκτός από τους κόμβους συμπλέγματος που διαθέτουν το απαραίτητο υλικό και λογισμικό, η προσθήκη συσκευής EFA πρέπει να αναπτυχθεί στο σύμπλεγμα και το κοντέινερ εργασίας σας πρέπει να έχει συμβατά CUDA και NCCL εκδόσεις εγκατασταθεί.

Για να δείξουμε την εκτέλεση δοκιμών NCCL και την αξιολόγηση της απόδοσης του EFA σε περιπτώσεις p4d.24xlarge, πρέπει πρώτα να αναπτύξουμε τον τελεστή Kubeflow MPI εκτελώντας το αντίστοιχο αναπτύξτε.sh σενάριο στο mpi-operator ντοσιέ. Στη συνέχεια τρέχουμε το αναπτύξτε.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 GB/sec και το μέσο εύρος ζώνης διαύλου είναι περίπου 8 GB.

Πραγματοποιήσαμε επίσης πειράματα με έναν μόνο προσαρμογέα EFA ενεργοποιημένο καθώς και χωρίς προσαρμογείς EFA. Όλα τα αποτελέσματα συνοψίζονται στον παρακάτω πίνακα.

Βρήκαμε επίσης ότι για σχετικά μικρά μοντέλα όπως το ImageNet, η χρήση επιταχυνόμενης δικτύωσης μειώνει τον χρόνο εκπαίδευσης ανά εποχή μόνο κατά 5–8% σε μέγεθος παρτίδας 64. Για μεγαλύτερα μοντέλα και μικρότερα μεγέθη παρτίδας, όταν απαιτείται αυξημένη δικτυακή επικοινωνία βαρών , η χρήση επιταχυνόμενης δικτύωσης έχει μεγαλύτερο αντίκτυπο. Παρατηρήσαμε μείωση του χρόνου προπόνησης της εποχής κατά 15–18% για την εκπαίδευση του EfficientNet-B7 με μέγεθος παρτίδας 1. Ο πραγματικός αντίκτυπος της EFA στην προπόνησή σας θα εξαρτηθεί από το μέγεθος του μοντέλου σας.

Παρακολούθηση GPU

Πριν εκτελέσουμε την εργασία εκπαίδευσης, μπορούμε επίσης να ρυθμίσουμε amazoncloudwatch μετρήσεις για την οπτικοποίηση της χρήσης GPU κατά τη διάρκεια της εκπαίδευσης. Μπορεί να είναι χρήσιμο να γνωρίζουμε εάν οι πόροι χρησιμοποιούνται με τον βέλτιστο τρόπο ή δυνητικά αναγνωρίζεται η έλλειψη πόρων και τα σημεία συμφόρησης στη διαδικασία εκπαίδευσης.

Τα σχετικά σενάρια για τη ρύθμιση του CloudWatch βρίσκονται στο gpu-metrics ντοσιέ. Αρχικά, δημιουργούμε μια εικόνα 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 για την ανακάλυψη εργαζομένων και την ανταλλαγή παραμέτρων. ο αναπτύξτε.sh σενάριο στο elasticjob φάκελος κάνει ακριβώς αυτό.

Για να εκμεταλλευτούμε το EFA σε περιπτώσεις p4d.24xlarge, πρέπει να χρησιμοποιήσουμε μια συγκεκριμένη εικόνα Docker που είναι διαθέσιμη στο Amazon ECR Public Gallery που υποστηρίζει επικοινωνία NCCL μέσω EFA. Απλώς πρέπει να αντιγράψουμε τον εκπαιδευτικό μας κώδικα σε αυτήν την εικόνα Docker. ο Dockerfile σύμφωνα με το δείγματα Ο φάκελος δημιουργεί μια εικόνα που θα χρησιμοποιηθεί κατά την εκτέλεση εργασιών εκπαίδευσης σε περιπτώσεις p4d. Όπως πάντα, μπορούμε να χρησιμοποιήσουμε το χτίζω.χ και σπρώξτε.σ σενάρια στον φάκελο για να δημιουργήσετε και να προωθήσετε την εικόνα.

Η 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. Αυτές οι ρυθμίσεις είναι απαραίτητες προκειμένου να μεγιστοποιηθεί η χρήση όλων των πόρων υλικού που είναι διαθέσιμοι στο σύμπλεγμα.

Όταν η εργασία εκτελείται, μπορούμε να παρατηρήσουμε τη χρήση της GPU στο CloudWatch για όλες τις GPU στο σύμπλεγμα. Το παρακάτω είναι ένα παράδειγμα από μια από τις εργασίες εκπαίδευσης μας με τρεις κόμβους p4d.24xlarge στο σύμπλεγμα. Εδώ έχουμε επιλέξει μία GPU από κάθε κόμβο. Με τις ρυθμίσεις που αναφέρθηκαν προηγουμένως, η χρήση της GPU είναι κοντά στο 100% κατά τη φάση εκπαίδευσης της εποχής για όλους τους κόμβους του συμπλέγματος.

Για την εκπαίδευση ενός μοντέλου ResNet50 με χρήση παρουσιών p3.8xlarge, χρειαζόμαστε ακριβώς τα ίδια βήματα που περιγράφηκαν για την εκπαίδευση EfficientNet χρησιμοποιώντας p4d.24xlarge. Μπορούμε επίσης να χρησιμοποιήσουμε την ίδια εικόνα Docker. Όπως αναφέρθηκε προηγουμένως, οι περιπτώσεις p3.8xlarge δεν είναι εξοπλισμένες με EFA. Ωστόσο, για το μοντέλο ResNet50, αυτό δεν αποτελεί σημαντικό μειονέκτημα. ο imagenet-fsx.yaml Το σενάριο που παρέχεται στο αποθετήριο GitHub ρυθμίζει την εργασία εκπαίδευσης με κατάλληλους πόρους για τον τύπο κόμβου p3.8xlarge. Η εργασία χρησιμοποιεί το ίδιο σύνολο δεδομένων από το σύστημα αρχείων FSx.

Κλιμάκωση GPU

Πραγματοποιήσαμε μερικά πειράματα για να παρατηρήσουμε πώς κλιμακώνεται ο χρόνος εκπαίδευσης για το μοντέλο EfficientNet-B7 αυξάνοντας τον αριθμό των GPU. Για να γίνει αυτό, αλλάξαμε τον αριθμό των αντιγράφων από 1 σε 3 στο εκπαιδευτικό μας αρχείο .yaml για κάθε εκτέλεση εκπαίδευσης. Παρατηρήσαμε μόνο τον χρόνο για μία μόνο εποχή ενώ χρησιμοποιούσαμε το πλήρες σύνολο δεδομένων ImageNet. Το παρακάτω σχήμα δείχνει τα αποτελέσματα για το πείραμα κλιμάκωσης της GPU. Η κόκκινη διακεκομμένη γραμμή αντιπροσωπεύει πώς θα πρέπει να μειωθεί ο χρόνος εκπαίδευσης από μια εκτέλεση με χρήση 8 GPU αυξάνοντας τον αριθμό των GPU. Όπως μπορούμε να δούμε, η κλιμάκωση είναι αρκετά κοντά στο αναμενόμενο.

Ομοίως, αποκτήσαμε το διάγραμμα κλιμάκωσης της GPU για την εκπαίδευση ResNet50 σε p3.8x μεγάλες περιπτώσεις. Για αυτήν την περίπτωση, αλλάξαμε τα αντίγραφα στο αρχείο μας .yaml από 1 σε 4. Τα αποτελέσματα αυτού του πειράματος φαίνονται στο παρακάτω σχήμα.

εκκαθάριση

Είναι σημαντικό να περιστρέφονται πόροι μετά την εκπαίδευση του μοντέλου, προκειμένου να αποφευχθούν τα κόστη που σχετίζονται με την εκτέλεση περιπτώσεων αδράνειας. Με κάθε σενάριο που δημιουργεί πόρους, το GitHub repo παρέχει ένα αντίστοιχο σενάριο για τη διαγραφή τους. Για να καθαρίσουμε τις ρυθμίσεις μας, πρέπει να διαγράψουμε το σύστημα αρχείων FSx πριν διαγράψουμε το σύμπλεγμα επειδή σχετίζεται με ένα υποδίκτυο στο VPC του συμπλέγματος. Για να διαγράψουμε το σύστημα αρχείων FSx, πρέπει απλώς να εκτελέσουμε την ακόλουθη εντολή (από το εσωτερικό του FSX ντοσιέ):

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

Σημειώστε ότι αυτό όχι μόνο θα διαγράψει τον μόνιμο τόμο, αλλά θα διαγράψει επίσης το σύστημα αρχείων FSx και όλα τα δεδομένα στο σύστημα αρχείων θα χαθούν. Όταν ολοκληρωθεί αυτό το βήμα, μπορούμε να διαγράψουμε το σύμπλεγμα χρησιμοποιώντας το ακόλουθο σενάριο στο εξ φάκελο:

./eks-delete.sh

Αυτό θα διαγράψει όλα τα υπάρχοντα pod, θα καταργήσει το σύμπλεγμα και θα διαγράψει το VPC που δημιουργήθηκε στην αρχή.

Συμπέρασμα

Σε αυτήν την ανάρτηση, αναλύσαμε τα βήματα που απαιτούνται για την εκτέλεση της εκπαίδευσης παράλληλων μοντέλων κατανεμημένων δεδομένων PyTorch σε συμπλέγματα EKS. Αυτό το έργο μπορεί να φαίνεται τρομακτικό, αλλά το AWS DevOps για EKS Το έργο που δημιουργήθηκε από την ομάδα ML Frameworks στο AWS παρέχει όλα τα απαραίτητα σενάρια και εργαλεία για να απλοποιήσει τη διαδικασία και να κάνει την εκπαίδευση κατανεμημένων μοντέλων εύκολα προσβάσιμη.

Για περισσότερες πληροφορίες σχετικά με τις τεχνολογίες που χρησιμοποιούνται σε αυτήν την ανάρτηση, επισκεφθείτε Amazon EX και Φακός Κατανεμημένο Ελαστικό. Σας ενθαρρύνουμε να εφαρμόσετε την προσέγγιση που περιγράφεται εδώ στις δικές σας περιπτώσεις χρήσης κατανεμημένης εκπαίδευσης.

Υποστηρικτικό υλικό

Σχετικά με τους συγγραφείς

Imran Younus είναι μια ομάδα Principal Solutions Architect για ML Frameworks στην AWS. Εστιάζει σε μεγάλης κλίμακας μηχανική μάθηση και φόρτους εργασίας βαθιάς μάθησης σε υπηρεσίες AWS όπως το Amazon EKS και το AWS ParallelCluster. Διαθέτει μεγάλη εμπειρία σε εφαρμογές Deep Leaning σε Computer Vision και Industrial IoT. Ο Imran απέκτησε το διδακτορικό του στη Φυσική των Σωματιδίων Υψηλής Ενέργειας όπου ασχολήθηκε με την ανάλυση πειραματικών δεδομένων σε κλίμακες peta-byte.

Άλεξ Ιανκούλσκι είναι ένας πλήρης αρχιτέκτονας λογισμικού και υποδομής που του αρέσει να κάνει βαθιά, πρακτική δουλειά. Αυτή τη στιγμή είναι Κύριος Αρχιτέκτονας Λύσεων για Αυτοδιαχειριζόμενη Μηχανική Μάθηση στο AWS. Στο ρόλο του εστιάζει στο να βοηθά τους πελάτες με τη δημιουργία εμπορευματοκιβωτίων και την ενορχήστρωση φόρτου εργασίας ML και AI σε υπηρεσίες AWS που λειτουργούν με κοντέινερ. Είναι επίσης ο συγγραφέας του ανοιχτού κώδικα Κάντε πλαίσιο και ένας καπετάνιος Docker που λατρεύει να εφαρμόζει τεχνολογίες εμπορευματοκιβωτίων για να επιταχύνει τον ρυθμό της καινοτομίας επιλύοντας παράλληλα τις μεγαλύτερες προκλήσεις του κόσμου. Τα τελευταία 10 χρόνια, ο Alex έχει εργαστεί για την καταπολέμηση της κλιματικής αλλαγής, τον εκδημοκρατισμό της τεχνητής νοημοσύνης και του ML, κάνοντας τα ταξίδια ασφαλέστερα, την υγειονομική περίθαλψη καλύτερη και την ενέργεια πιο έξυπνη.