Νέα

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Επιλέχτηκε από το imbue.com

Συγγραφέας: Imbue Team

Συλλογή Machine Heart

Επιμέλεια: panda

Γνωρίζουμε ότι το LLM εκπαιδεύεται σε συμπλέγματα υπολογιστών μεγάλης κλίμακας χρησιμοποιώντας τεράστια δεδομένα Η Machine Heart έχει εισαγάγει πολλές μεθόδους και τεχνολογίες για την υποβοήθηση και τη βελτίωση της εκπαιδευτικής διαδικασίας LLM. Σήμερα, αυτό που θέλουμε να μοιραστούμε είναι ένα άρθρο που εμβαθύνει στην υποκείμενη τεχνολογία και εισάγει πώς να μετατρέψετε ένα σωρό "γυμνά μέταλλα" που δεν διαθέτουν καν λειτουργικό σύστημα σε ένα σύμπλεγμα υπολογιστών για την εκπαίδευση LLM.

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

Φυσικά, το να μετατρέψεις ένα μάτσο "γυμνό μέταλλο" χωρίς λειτουργικό σύστημα σε ένα σύμπλεγμα υπολογιστή για εκπαίδευση LLM δεν είναι μια εύκολη διαδικασία, γεμάτη εξερεύνηση και δοκιμή και λάθη, αλλά η Imbue εκπαίδευσε με επιτυχία ένα LLM με 70 δισεκατομμύρια παραμέτρους πολλές χρήσιμες εμπειρίες στη διαδικασία.

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

Εάν ενδιαφέρεστε να δημιουργήσετε τη δική σας υποδομή εκπαίδευσης LLM ή είστε περίεργοι για το πώς φτιάχνεται το LLM, τότε αυτό το άρθρο αξίζει να διαβάσετε και να συλλέξετε.

Ακολουθεί το αρχικό κείμενο του άρθρου της ομάδας Imbue.

εισαγωγή

Η μικρή ομάδα ερευνητών και μηχανικών μας ξόδεψε αρκετούς μήνες εκπαιδεύοντας ένα μοντέλο 70 δισεκατομμυρίων παραμέτρων από την αρχή στη δική μας υποδομή και το μοντέλο ξεπέρασε τα μοντέλα μηδενικής λήψης σε εργασίες που σχετίζονται με συμπεράσματα.

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

Καθ' όλη τη διάρκεια της διαδικασίας, η ομάδα μηχανικών μας συνεργάστηκε με το Voltage Park για να προετοιμάσει συμπλέγματα υπολογιστών και να δημιουργήσει τα θεμέλια για εφαρμογές παραγωγής. Όλη αυτή η διαδικασία περιλαμβάνει:

1. Διαμορφώστε κάθε μηχανή

2. Διαμορφώστε το InfiniBand

3. Βεβαιωθείτε ότι το μηχάνημα είναι απολύτως υγιές

4. Διαγνώστε κοινά προβλήματα προπόνησης

5. Βελτίωση εργαλείων υποδομής

Κάθε βήμα περιγράφεται αναλυτικά παρακάτω.

Ιστορικό: Πώς φτιάχτηκε

Ο στόχος μας για την εκτέλεση υπολογισμών είναι να εξασφαλίσουμε γρήγορο πειραματισμό με μεγάλα γλωσσικά μοντέλα. Για να γίνει αυτό, χρειαζόμαστε μεγάλο αριθμό GPU υψηλής ταχύτητας και επικοινωνία υψηλής ταχύτητας μεταξύ αυτών των GPU.

Αυτό το άρθρο θα επικεντρωθεί σε ένα σύμπλεγμα που περιέχει 4088 GPU H100 κατανεμημένες σε 511 υπολογιστές ή 8 GPU ανά υπολογιστή. Ο λόγος για τον οποίο υπάρχουν 511 υπολογιστές με GPU είναι επειδή ορισμένες συνδέσεις πρέπει να δεσμευτούν για τον κόμβο Unified Fabric Manager, ο ρόλος του οποίου είναι να διαχειρίζεται το δίκτυο InfiniBand. Στους κεντρικούς υπολογιστές που διαθέτουν 511 GPU, κάθε GPU συνδέεται απευθείας με μια κάρτα δικτύου ConnectX-7, η οποία μπορεί να μεταδώσει δεδομένα στα 400 Gbps σε οποιαδήποτε GPU στο δίκτυο InfiniBand.

Η τοπολογία δικτύου μας InfiniBand θεωρητικά είναι "πλήρης μη αποκλεισμός", αυτό επιτρέπει στις GPU να επικοινωνούν μεταξύ τους με τη μέγιστη ταχύτητα. Για να γίνει αυτό, χρησιμοποιούμε μια αρχιτεκτονική δικτύου InfiniBand τριών επιπέδων: διακόπτες InfiniBand τριών επιπέδων. Με τις σωστές συνδέσεις, αυτό το υψηλό επίπεδο απόδοσης μπορεί να επιτευχθεί σε ολόκληρο το δίκτυο. Το παρακάτω σχήμα δείχνει μια επισκόπηση αυτού του δικτύου InfiniBand:

Σημειώστε ότι η επικοινωνία κατά την εκπαίδευση του δικτύου πραγματοποιείται μέσω InfiniBand και όχι μέσω Ethernet. Αν και αυτά τα μηχανήματα είναι επίσης συνδεδεμένα με Ethernet, ο ρόλος αυτού του δικτύου είναι να μεταφέρει δεδομένα όπως σύνολα δεδομένων και σημεία ελέγχου. Εάν χρησιμοποιείτε Ethernet για την αποστολή δεδομένων, η ταχύτητα θα είναι πολύ πιο αργή, επειδή τα δεδομένα θα ταξιδεύουν πρώτα από την GPU στην CPU και στη συνέχεια θα βγαίνουν μέσω της κάρτας Ethernet ταχύτητας 100 Gbps. Αν και είναι επίσης δυνατή η εκπαίδευση μέσω Ethernet χρησιμοποιώντας μια τεχνολογία που ονομάζεται RDMA μέσω Converged Ethernet (RoCE), η οποία απαιτεί πολλή επιπλέον δουλειά τόσο από την πλευρά του υλικού όσο και του λογισμικού και είναι γενικά λιγότερο αξιόπιστη από το InfiniBand. Για λεπτομέρειες, ανατρέξτε σε αυτό το έγγραφο: https://arxiv.org/pdf/2402.15627

Υπάρχει επίσης ένα δευτερεύον Ethernet που χρησιμοποιείται μόνο για διαμόρφωση και διαχείριση, παρέχοντας πρόσβαση στο BIOS (Basic Input Output System), στο τροφοδοτικό και σε άλλες διεπαφές ελέγχου για διεπαφές μηχανημάτων χαμηλού επιπέδου. Χωρίς αυτό το δίκτυο διαχείρισης, θα έπρεπε να ρυθμίσουμε χειροκίνητα κάθε κόμβο μέσω ενός προγράμματος οδήγησης USB, πληκτρολογίου και οθόνης. Για καταστάσεις με εκατοντάδες μηχανές, αυτή δεν είναι μια βιώσιμη προσέγγιση.

Η επίτευξη εκπαίδευσης υψηλής απόδοσης σε αυτό το σύμπλεγμα απαιτεί κάθε στοιχείο (InfiniBand, Ethernet, GPU και οι ίδιοι οι κόμβοι) να λειτουργούν σχεδόν τέλεια. Εάν κάποια από αυτές τις 12.000+ συνδέσεις είναι λίγο ασταθής, μπορεί να επιβραδύνει τη συνολική προπόνηση.

Το υπόλοιπο αυτού του άρθρου αφορά το πώς να τα κάνετε όλα να λειτουργούν τέλεια και σταθερά.

Διαδικασία: Πώς να μετατρέψετε το γυμνό μέταλλο σε ένα πλήρως λειτουργικό σύμπλεγμα

Διαμόρφωση κάθε μηχανής

Μετά τη δημιουργία της αρχικής σύνδεσης Ethernet με το σύμπλεγμα μέσω του δικτύου διαχείρισης, λαμβάνονται διαπιστευτήρια πρόσβασης στον ελεγκτή διαχείρισης βάσης (BMC). Το BMC είναι ένας αποκλειστικός επεξεργαστής υπηρεσιών που παρακολουθεί εξ αποστάσεως συστήματα κεντρικού υπολογιστή και συνήθως συνδέεται σε ξεχωριστό δίκτυο. Μας επιτρέπει να χειριζόμαστε το μηχάνημα σαν να ήμασταν προσωπικά εκεί και επιπλέον παρέχει API για την υγεία του υλικού, τις ρυθμίσεις του BIOS και τη διαχείριση ενέργειας.

Με αυτά τα εξαρτήματα στη θέση τους, μπορούμε να σηκώσουμε τα μανίκια μας και να αρχίσουμε να στήνουμε το σύμπλεγμα.

Βήμα 0: Διαμορφώστε πρώτα ένα μηχάνημα

Ξεκινήσαμε εγκαθιστώντας το Ubuntu 22.04 σε έναν διακομιστή χρησιμοποιώντας το iDRAC (Dell's Baseboard Management Controller) και στη συνέχεια ρυθμίσαμε οτιδήποτε άλλο με βάση αυτό το λειτουργικό σύστημα. Μία από τις δυνατότητες του iDRAC είναι να επιτρέπει την εγκατάσταση και την εκκίνηση εικόνων ISO από τον τοπικό υπολογιστή και να παρέχει μια εικονική κονσόλα μέσω του προγράμματος περιήγησης. Στην ιδανική περίπτωση, αυτό είναι το μόνο βήμα χειροκίνητης εγκατάστασης στη διαδικασία.

Βήμα 1: Εγκαταστήστε το λειτουργικό σύστημα σε κάθε μηχάνημα

Αφού ρυθμίσετε τις παραμέτρους του πρώτου μηχανήματος, προχωρήστε στην εγκατάσταση του λογισμικού Metal-as-a-Service (MAAS) του Ubuntu για να βοηθήσετε στη διαμόρφωση των υπόλοιπων διακομιστών. Το εργαλείο εκκίνησης και αυτοματισμού iDRAC χρησιμοποιεί το πρωτόκολλο Preboot Execution Environment Protocol (PXE) για να δώσει εντολή σε κάθε μηχάνημα να εκκινήσει από το δίκτυο και να ρυθμίσει το MAAS ώστε να ανταποκρίνεται σε αιτήματα εκκίνησης PXE. Κατά την εκτέλεση μιας αρχικής εκκίνησης δικτύου, ο διακομιστής λαμβάνει μια IP και έναν αρχικό πυρήνα από το MAAS μέσω του Πρωτοκόλλου δυναμικής κατανομής IP DHCP χωρίς να χρειάζεται να εγκαταστήσει τίποτα στην τοπική μονάδα δίσκου. Αυτό είναι το βασικό περιβάλλον για την αυτοματοποίηση επαναλαμβανόμενων εγκαταστάσεων λειτουργικών συστημάτων. Θεωρητικά, δεν έχουμε παρά να περιμένουμε την πρώτη μπότα και όλα θα επιλυθούν. Αλλά στην πράξη, η ενσωμάτωση MAAS με το BMC είναι αναξιόπιστη, επομένως χρησιμοποιούμε το iDRAC API για να συλλέξουμε εκ των προτέρων τη διεύθυνση MAC κάθε μηχανής (ένα μοναδικό φυσικό αναγνωριστικό υλικού).

Σε όλη αυτή τη διαδικασία εκπαίδευσης, το MAAS είναι συχνά το πιο αξιόπιστο συστατικό της σπονδυλικής στοίβας. Ωστόσο, αντιμετωπίσαμε κάποια ζητήματα στην αρχή που ήταν μοναδικά για τις ρυθμίσεις μας. Για παράδειγμα, κατά τη διαμόρφωση των πρώτων μηχανών, δεν μπόρεσα να εγκαταστήσω τίποτα μέσω του apt λόγω προβλημάτων επαλήθευσης πιστοποιητικού HTTPS, επειδή τα ρολόγια ήταν τόσο διαφορετικά. Σχετικά, δεδομένου ότι ο διακομιστής MAAS πρέπει να είναι υπεύθυνος για πολλά πράγματα (διακομιστής DHCP, διακομιστής DNS για την επίλυση ονομάτων κεντρικού υπολογιστή σε IP, διακομιστής μεσολάβησης HTTP μεταξύ του κεντρικού υπολογιστή και του επίσημου διακομιστή πακέτων Ubuntu, διακομιστής NTP, διαχείριση διαμόρφωσης cloud-init , γείωση βάση δεδομένων αλήθειας που χρησιμοποιείται για τη σύνδεση της διεύθυνσης MAC με την IP με το όνομα κεντρικού υπολογιστή με προσαρμοσμένα μεταδεδομένα), επομένως είναι δύσκολο για εμάς να λύσουμε αυτά τα προβλήματα από τη βασική αιτία. Επιπλέον, υπάρχει το ζήτημα της καμπύλης εκμάθησης του κύκλου ζωής της διαμόρφωσης MAAS, καθώς ο στόχος του σχεδιασμού είναι να χειριστεί την πολυπλοκότητα της διαχείρισης των αναπτυξιακών πεδίων και τη σταδιακή μετανάστευση κόμβων και διαφόρων ενδιάμεσων καταστάσεων εντοπισμού σφαλμάτων/ανθυγιεινών.

Βήμα 2: Διαγνώστε το σπασμένο μηχάνημα

Διαπιστώσαμε ότι περίπου το 10% των μηχανών απέτυχε να εκκινήσει, κυρίως λόγω φυσικών προβλημάτων με τον διακομιστή. Αυτό είναι ένα συνηθισμένο σενάριο για τη ρύθμιση μεγάλων συμπλεγμάτων GPU. Οι καταστάσεις που αντιμετωπίσαμε περιλαμβάνουν: ελλείψεις ή λανθασμένα καλώδια δικτύου, προβλήματα υλικού στο iDRAC, κατεστραμμένες μονάδες τροφοδοσίας, κατεστραμμένα προγράμματα οδήγησης NVME (non-volatile memory fast), ελλείψεις εσωτερικών γραμμών, μη εμφάνιση καρτών δικτύου ή GPU. Ελέγξαμε αυτόματα για αυτά τα ζητήματα, επιστρέψαμε ορισμένα μηχανήματα στην Dell για επανέλεγχο και υποβάλαμε κατάλληλες εντολές εργασίας για το προσωπικό του κέντρου δεδομένων. Ένα πλεονέκτημα της διαμόρφωσης του συμπλέγματος μόνοι μας είναι ότι μπορούμε να χρησιμοποιήσουμε αμέσως υγιή μηχανήματα ενώ περιμένουμε τη συντήρηση σε ορισμένα μηχανήματα.

Βήμα 3: Ελάχιστο βιώσιμο παρατηρήσιμο μηχάνημα

Συνεχίζουμε με τις παρακάτω ρυθμίσεις σε κάθε διακομιστή:

1.Docker (για να διευκολυνθεί η εκτέλεση εργασιών υπηρεσιών και εκπαίδευσης)

2. Πρόγραμμα οδήγησης GPU κέντρου δεδομένων

3. Εργαλείο εξαγωγής κόμβου Prometheus (χρησιμοποιείται για την εξαγωγή σταθερής ροής δεδομένων δείκτη υλικού/λειτουργικού συστήματος)

4. Εργαλείο εξαγωγής DCGM (χρησιμοποιείται για την εξαγωγή πρόσθετων δεδομένων δείκτη από την GPU NVIDIA, όπως κατάσταση GPU, ρολόι, χρήση)

5. Δεξαμενή RAIDZ ZFS για όλα τα προγράμματα οδήγησης μη λειτουργικού συστήματος, που επιτρέπει στο μηχάνημα να συνεχίσει να λειτουργεί ακόμα και αν ένα πρόγραμμα οδήγησης αποτύχει, ενώ παρέχει επίσης διαφανή συμπίεση δωρεάν (αυτό είναι ιδιαίτερα χρήσιμο για σύνολα δεδομένων απλού κειμένου και επαναλαμβανόμενα αρχεία καταγραφής - σχετικά Χρησιμοποιώντας αυτό Το εργαλείο συνήθως αυξάνει τον χρησιμοποιήσιμο χώρο έως και 10 φορές σε σύγκριση με τη μη χρήση αυτού του εργαλείου)

Στη συνέχεια, εκτελούμε βασικά διαγνωστικά GPU για να προσδιορίσουμε εάν η GPU γενικά λειτουργεί σωστά - οτιδήποτε δεν λειτουργεί συνήθως οδηγεί σε προβλήματα υλικού μέσα σε λίγες ώρες.

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

Βήμα 4: Εκπαίδευση GPU ενός κόμβου

Το επόμενο βήμα είναι να διασφαλίσετε ότι κάθε μηχάνημα μπορεί να χειριστεί από μόνο του πραγματικούς φόρτους εργασίας GPU. Πολλά μηχανήματα δεν μπορούν να το κάνουν αυτό και τα προβλήματα περιλαμβάνουν:

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

Σύμφωνα με τα αρχεία καταγραφής διακομιστή Ubuntu, πολλά καλώδια μεταξύ της GPU και του διαύλου PCIe ή της κάρτας δικτύου εξέδωσαν αυτό το σφάλμα: "περιορισμένο πλάτος: x4 < x16". Μετά την ενημέρωση του υλικολογισμικού του διαύλου διακόπτη PCIe, διαπιστώσαμε ότι περίπου το ένα τέταρτο των κεντρικών υπολογιστών απαιτούσε επανατοποθέτηση των εσωτερικών καλωδίων PCIe - πιθανώς επειδή τα καλώδια μεταξύ της θήκης και της GPU είναι αρκετά εύθραυστα, πράγμα που σημαίνει ότι κάθε φορά που γίνεται συντήρηση στη GPU, αυτά τα καλώδια θα να σπρωχθεί ή να τραβηχτεί έξω.

Υπήρξαν μερικές διάφορες διακοπές λειτουργίας που επηρέασαν επίσης αρκετούς οικοδεσπότες. Η Dell μας βοήθησε να επιλύσουμε ορισμένα προβλήματα με μια αναβάθμιση υλικολογισμικού:

Η μονάδα NVMe δεν παρουσίασε σφάλματα, αλλά κλείδωσε ολόκληρο το μηχάνημα όταν την άγγιξε.

Οι σκληροί δίσκοι εμφανίζονται με τυχαία σειρά στο Linux, προκαλώντας σύγχυση στο MAAS και προκαλώντας την εγκατάσταση του λειτουργικού συστήματος σε λάθος μονάδα δίσκου.

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

Η δυναμική κλιμάκωση της CPU βγήκε εκτός ελέγχου, περιορίζοντας τους πυρήνες εργασίας στα 2 GHz.

Η απευθείας επικοινωνία GPU-GPU (GDR ή GPUDirect RDMA Peer Memory Client) δεν μπορεί να εφαρμοστεί με επιτυχία.

Διαμόρφωση InfiniBand

Βήμα 0: Εγκαταστήστε το UFM

Ένα πλεονέκτημα του InfiniBand είναι ο κεντρικός σχεδιασμός του, έτσι ώστε ολόκληρο το δίκτυο να έχει έναν εγκέφαλο. Επομένως, χρειάζεται να ασχοληθούμε μόνο με μια παρουσία των 320 μεταγωγέων δικτύου σε ολόκληρη τη δομή του δικτύου. Η πρώτη μας εργασία ήταν να καταλάβουμε ποιος διακόπτης συνέδεσε ποιες μηχανές, στη συνέχεια να το συσχετίσουμε με το διάγραμμα καλωδίωσης και να τις μετονομάσουμε με βάση τη φυσική θέση του διακόπτη.

Βήμα 1: Επανακαλωδίωση

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

Βήμα 2: Δέκα χιλιάδες συναγερμοί θερμοκρασίας (ειδοποίηση)

Μετά την επίλυση των προβλημάτων φυσικής καλωδίωσης, το InfiniBand δημιούργησε επιτυχώς συνδέσεις με όλους τους μεταγωγείς InfiniBand στο ιστό δικτύου. Ωστόσο, σχεδόν κάθε θύρα μεταγωγέα άρχισε να αναφέρει υπερβολικές θερμοκρασίες, που μερικές φορές ξεπερνούσαν τους 70°C, παρόλο που δεν μετέφεραν δεδομένα. Ανακαλύψαμε ότι το πρόβλημα προήλθε από τον ανοιχτό χώρο μεταξύ των διακοπτών στο ίδιο ράφι, ο οποίος προκάλεσε τη ροή ζεστού αέρα πίσω στο μπροστινό μέρος. Ο συνεργάτης μας στο κέντρο δεδομένων μας βοήθησε να διαγνώσουμε γρήγορα το πρόβλημα και να αναπτύξουμε την κατάλληλη λύση.

Βήμα 3: 1800 συναγερμοί

Πολλές θύρες έχουν επίσης υψηλά ποσοστά σφάλματος, ή πηγαίνουν πέρα ​​δώθε μεταξύ κανονικών και κατεστραμμένων καταστάσεων, κάτι που ονομάζεται "flapping". Αυτά τα ζητήματα προκύπτουν μόνο όταν χρησιμοποιούνται πραγματικά οι θύρες, επομένως είναι δύσκολο να εντοπιστούν εκ των προτέρων επειδή ολόκληρη η δομή μας αποτελείται από 10.000 εξαιρετικά περιττούς συνδέσμους. Ο συνεργάτης του κέντρου δεδομένων μας βοήθησε να καθαριστούν και να επανεγκατασταθούν οι θύρες του συναγερμού και απενεργοποιήσαμε τους εναπομείναντες πομποδέκτες συναγερμού ενώ περιμέναμε την αντικατάστασή τους.

Ενώ το InfiniBand είναι ανθεκτικό σε αστοχίες υλικού, μόλις το 10% περίπου του υφάσματος αρχίσει να αποτυγχάνει, λειτουργίες όπως η προσαρμοστική δρομολόγηση δεν λειτουργούν αξιόπιστα για να λάβουν υπόψη την περιστασιακή απώλεια σύνδεσης.

Κατά τη διάρκεια αυτής της περιόδου, εκτελέσαμε επιτυχώς εκπαίδευση πολλαπλών κόμβων χρησιμοποιώντας 100 έως 200 μηχανές. Η διαδικασία μας είναι κάπως αυτοσχέδια: μερικές φορές περιστρέφουμε ένα τυχαίο σύνολο κόμβων, παρατηρούμε την απόδοσή τους και στη συνέχεια προσπαθούμε να κρατήσουμε όσο το δυνατόν περισσότερους από αυτούς σε λειτουργία. Αυτή η μέθοδος μας επιτρέπει να βρούμε ένα αξιόπιστο υποσύνολο της δομής δικτύου InfiniBand, αλλά είναι πολύ δύσκολο γιατί κάθε φορά πρέπει να αλλάζουμε το σύνολο των κόμβων που χρησιμοποιούνται για εκπαίδευση, αλλάζοντας έτσι τον προεπιλεγμένο σύνδεσμο InfiniBand.

Βήμα 4: Το InfiniBand καίγεται σαν τρελό

Για να διαγνώσουμε τα προβλήματα InfiniBand πιο αποτελεσματικά, σχεδιάσαμε έναν φόρτο εργασίας για ολόκληρο το σύμπλεγμα που ώθησε όσο το δυνατόν περισσότερα δεδομένα σε κάθε θύρα του υφάσματος ταυτόχρονα. Αυτό διαφέρει από την εκτέλεση ενός μεγάλου φόρτου εργασίας σε όλο το σύμπλεγμα, που απαιτεί τη χρήση NCCL για τη βελτιστοποίηση της επικοινωνίας μεταξύ μεμονωμένων κόμβων χρησιμοποιώντας το NVLink για επικοινωνία GPU μέσω υποδοχών Server PCIe Module (SXM).

Αντίθετα, επιλέξαμε μια προσέγγιση ωμής βίας και πετύχαμε με ευκολία. Το UFM θα αρχίσει να εκδίδει ειδοποιήσεις όταν ο όγκος μεταφοράς δεδομένων στις περισσότερες θύρες υπερβαίνει το 97% της θεωρητικής χωρητικότητας και ορισμένοι διακόπτες θα μειωθούν προσωρινά. Κάθε λιμάνι πιστεύαμε ότι έφτασε στο τέλος της ημέρας ήταν αρκετά στιβαρό και οι υπόλοιπες απενεργοποιήθηκαν ή αφαιρέθηκαν εν αναμονή επισκευών.

Βήμα 5: GPUDirect RDMA

Για να επιτρέψουμε την επικοινωνία GPU χωρίς επιβάρυνση υπολογιστών CPU, ενεργοποιήσαμε μια δυνατότητα που ονομάζεται GPUDirect RDMA, η οποία επιτρέπει την άμεση επικοινωνία μεταξύ καρτών δικτύου InfiniBand. Αυτό περιλαμβάνει δύο βασικά βήματα:

1. Ξεκινήστε μια πρόσθετη λειτουργική μονάδα πυρήνα

2. Βεβαιωθείτε ότι η Υπηρεσία Ελέγχου Πρόσβασης PCIe (ACS) είναι απενεργοποιημένη για να αποφευχθούν οι άμεσες κολλήσεις (άμεσες κολλήσεις)

Βήμα 6: Αναπτύξτε τον διακομιστή "χρυσό".

Για να δημιουργήσετε ένα σύμπλεγμα GPU χρησιμοποιώντας το πιο πρόσφατο υλικό, ένας εμπειρικός κανόνας είναι να προετοιμαστείτε ώστε περίπου το 3% των μηχανημάτων σας να αποτυγχάνουν κάθε εβδομάδα.

Ωστόσο, θα πρέπει να σημειωθεί: δεν έχει κάθε μηχανή ομοιόμορφη πιθανότητα βλάβης 3%, αλλά ένας μικρός αριθμός μηχανών που δεν έχουν υποστεί επεξεργασία έχουν διάφορα προβλήματα επανειλημμένα μέχρι να επισκευαστούν σωστά. Αυτό τονίζει τα πλεονεκτήματα της ύπαρξης μεγάλου αριθμού μηχανών στην ίδια δομή δικτύου. Έτσι, αντί να βρίσκουμε απλώς τυχαίες μηχανές για να εκτελούμε προπόνηση μεγάλης κλίμακας, όπως το whack-a-mole για να δούμε τι χαλάει, η προσέγγισή μας είναι να επικεντρωθούμε στην κλιμάκωση διακομιστών που είναι γνωστό ότι είναι αξιόπιστοι, στους «χρυσούς» διακομιστές.

Βήμα 7: Συντήρηση

Η συντήρηση του InfiniBand περιλαμβάνει κυρίως την απόκριση σε συναγερμούς UFM, την αντικατάσταση ελαττωματικών καλωδίων και πομποδέκτη και περιστασιακά τη διάγνωση πιο δύσκολων σφαλμάτων (όπως αστοχίες διακόπτη). Υπάρχουν συνήθως δύο παράγοντες που οδηγούν σε μεγάλης κλίμακας συντήρηση:

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

2. Τα κουτιά GPU επανεκκινούνται μαζικά την ίδια στιγμή, γεγονός που μπορεί να εισάγει μεγάλο αριθμό ενημερώσεων στην κατάσταση UFM και επίσης να απαιτεί επανεκκίνηση της υπηρεσίας UFM.

Βεβαιωθείτε ότι το μηχάνημα είναι απολύτως υγιές

Στην πορεία, ανακαλύψαμε πολλούς τρόπους με τους οποίους μεμονωμένες μηχανές θα μπορούσαν να δυσλειτουργήσουν ή να επιβραδύνουν την προπόνηση. Πολλές από αυτές τις λειτουργίες αποτυχίας δεν είναι άμεσα εμφανείς, επομένως γράψαμε μια σειρά από σενάρια ελέγχου υγείας για να ελέγξουμε αν ο κεντρικός υπολογιστής ήταν αρκετά υγιής. Δημοσιεύσαμε τον κώδικα εδώ: https://github.com/imbue-ai/cluster-health

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

Έλεγχος υγείας GPU

Ελέγξαμε ότι ο αριθμός των GPU ήταν σωστός, ότι ο έλεγχος ECC (Error Correction Code) ήταν ενεργοποιημένος και ότι δεν υπήρχαν σφάλματα ECC. Ελέγξαμε επίσης ότι η τοπολογία NVLink (η οποία συνδέει τις GPU μεταξύ τους) λειτουργεί και λειτουργεί χωρίς σφάλματα.

Έλεγχος υγείας χώρου στο δίσκο

Ελέγξαμε αν η χρήση του χώρου στο δίσκο του κεντρικού υπολογιστή υπερβαίνει το 95%.

Έλεγχος υγείας Docker

Ελέγξαμε ότι το Docker μπορεί να εκτελεί κοντέινερ με συνδεδεμένη GPU (δηλαδή, ο χρόνος εκτέλεσης του κοντέινερ NVIDIA λειτουργεί σωστά) και ότι τα κοντέινερ του Docker που σχετίζονται με την παρακολούθηση/ανάλυση είναι ενεργοποιημένα και διαθέτουν τα σωστά δικαιώματα κεντρικού υπολογιστή.

Έλεγχος υγείας Dmesg

Ελέγξαμε το dmesg για σφάλματα υλικού Xid ή SXid (βλάβες που προκαλούνται από GPU της NVIDIA ή διακόπτες NVIDIA μεταξύ GPU). Διαβάζουμε επίσης όλες τις γραμμές καταγραφής dmesg για να επαληθεύσουμε ότι μπορούν όλες να ταξινομηθούν στη λίστα Κοινές/Αναμενόμενες γραμμές καταγραφής.

Έλεγχος υγείας iDRAC

Ελέγξαμε για σφάλματα iDRAC στο μηχάνημα, το οποίο αγνόησε τα μη θανατηφόρα μηνύματα σφάλματος. Αυτός είναι ένας έλεγχος ειδικά για υπολογιστές Dell, επομένως δεν περιλαμβάνεται στον ανοιχτό κώδικα μας.

Έλεγχος υγείας δίσκου

Ελέγξαμε ότι το zpool είναι εγκατεστημένο, ότι το Docker είναι σωστά συνδεδεμένο σε αυτό και ότι μπορεί πραγματικά να το φτάσει χωρίς να κλειδώσει τη CPU.

Έλεγχος υγείας InfiniBand

Ελέγξαμε αν το ποσοστό σφάλματος του InfiniBand αυξήθηκε ή/και αν το υλικολογισμικό του προγράμματος οδήγησης ήταν ξεπερασμένο.

Έλεγχος υγείας Nvlink

Ελέγξαμε για σφάλματα NVLink στο μηχάνημα. Στην πράξη, αυτό δεν φαίνεται να προκαλεί αποτυχίες στην προπόνηση, αλλά μπορεί να επιβραδύνει την προπόνηση.

Έλεγχος υγείας της ΛΔΓ

Ελέγξαμε εάν το GDR είναι ενεργοποιημένο στο μηχάνημα.

Έλεγχος υγείας του VBIOS

Ελέγξαμε ότι η έκδοση VBIOS της GPU και το υλικολογισμικό βάσης H100 ήταν ενημερωμένα.

Έλεγχος υγείας πυριτόλιθου

Χρησιμοποιήσαμε flint και hca_self_test για να ελέγξουμε ότι το πρόγραμμα οδήγησης Mellanox OFED, το υλικολογισμικό της κάρτας δικτύου και το υλικολογισμικό του πομποδέκτη ήταν των σωστών εκδόσεων και ότι είχαν μεταγλωττιστεί σωστά για το πρόγραμμα οδήγησης NVIDIA.

Έλεγχος υγείας PSB

Ζητήσαμε από τις συσκευές PCIe για να ελέγξουμε αν η ταχύτητα και το πλάτος σύνδεσης μεταξύ της GPU, του PSB (PCIe Switch Bus) και της κάρτας δικτύου ήταν αυτό που περιμέναμε. Ελέγξαμε επίσης ότι το υλικολογισμικό του διακόπτη είναι ενημερωμένο. Αυτό το σενάριο αναπτύχθηκε από την Dell, όχι από την Imbue, επομένως δεν μπορούμε να το μοιραστούμε αυτήν τη στιγμή.

Εκτός από αυτούς τους γρήγορους ελέγχους υγείας, πραγματοποιούμε επίσης ορισμένους πιο σύνθετους ελέγχους υγείας, όπως:

Αρχικοποιήστε τους υπολογισμούς matrix μέσω του PyTorch και μετρήστε το εύρος ζώνης NVLink και την ταχύτητα και τη μνήμη υπολογισμού της GPU. Ορίσαμε τις κατάλληλες σημαίες GDR για να δοκιμάσουμε το InfiniBand και το NVLink.

Χρησιμοποιήστε τα ib_write_bw και –use_cuda για να στείλετε δεδομένα μέσω της κάρτας IB και να μετρήσετε το εύρος ζώνης της κάρτας PCIe και InfiniBand. Αυτή η διαδικασία διήρκεσε για μεγάλο χρονικό διάστημα (περίπου 15 λεπτά) για να διασφαλιστεί ότι βρέθηκε ο κυματιστής σύνδεσμος InfiniBand.

Εκτελέστε μια διαγνωστική εκτέλεση πολλών κόμβων για να ελέγξετε την ικανότητα προετοιμασίας NCCL και εάν σταματάει τυχαία. Εάν υπάρχουν παύσεις, ο διχαλωμένος κωδικός NCCL προσθέτει επιπλέον καταγραφή. Αυτό διαρκεί 12 έως 24 ώρες για να εντοπιστεί ένα πρόβλημα, επομένως το εκτελούμε συνήθως μόνο σε νέους κόμβους ή όταν υποπτευόμαστε ότι υπάρχει πρόβλημα.

Ελέγξτε την εξαγωγή DCGM για τυχόν συμβάντα περιορισμού του ρολογιού GPU (εξαιρουμένων των αναμενόμενων gpu_idle και power_cap). Για να ελέγξετε για αυτά τα συμβάντα ισχύος, ο καλύτερος τρόπος είναι να εκτελέσετε μια εκπαίδευση πολλών κόμβων που ελέγχει όλες τις GPU, τις κάρτες InfiniBand και τις CPU και τους δίσκους ταυτόχρονα.

Διαγνώστε κοινά προβλήματα προπόνησης

Μόλις το υλικό λειτουργεί σωστά, μπορεί να ξεκινήσει η εκπαίδευση.

Αυτή η ενότητα θα μοιραστεί ορισμένα συγκεκριμένα βήματα εντοπισμού σφαλμάτων και πληροφορίες που βασίζονται στην εμπειρία μας από την εκτέλεση εκπαίδευσης μεγάλων γλωσσικών μοντέλων στο σύμπλεγμα μας.

Κατάρρευση κατά την εκκίνηση

Κατά κάποιο τρόπο, αυτό είναι το καλύτερο σφάλμα που μπορείτε να συναντήσετε επειδή είναι (θεωρητικά) εύκολο να αναπαραχθεί και να επαναληφθεί.

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

Ένας άλλος βασικός έλεγχος που πραγματοποιούμε είναι να διασφαλίσουμε ότι όλα τα μηχανήματα είναι online και ότι τα ίχνη στοίβας ή τα αρχεία καταγραφής που εκπέμπονται μπορούν εύκολα να συγκεντρωθούν και να επιθεωρηθούν. Χρησιμοποιήσαμε τις στοίβες λογισμικού Loki, Prometheus και Grafana, αλλά κάθε κατάλληλο εργαλείο συλλογής αρχείων καταγραφής ή παρακολούθησης SaaS θα κάνει. Επειδή αυτές οι εκτελέσεις εκπαίδευσης είναι σύγχρονες και κατανεμημένες στη φύση τους, το πρώτο σφάλμα οδηγεί συχνά σε έναν καταρράκτη άσχετων σφαλμάτων. Εδώ, οι έλεγχοι υγείας μπορούν επίσης να βοηθήσουν στην άμεση ανίχνευση σφαλμάτων όπως κατεστραμμένος σκληρός δίσκος ή έλλειψη ή μη έγκυρη GPU.

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

1. Σφάλματα όπως "Προώθηση σειράς διαφέρει μεταξύ των βαθμών: η κατάταξη 0 συγκεντρώνει όλες τις 43 παραμέτρους ενώ η κατάταξη 1228 είναι όλες οι παραμέτρους 1". Βρήκαμε ότι αυτό είναι ένα περίεργο χαρακτηριστικό της εφαρμογής Fully Sharded Data Parallel (FSDP) του PyTorch, το οποίο επιλύθηκε με επανεκκίνηση.

2. Σφάλμα GPU εκτός μνήμης (OOM), το οποίο μοιάζει με αυτό: "CUDA εκτός μνήμης. Προσπάθησα να εκχωρήσω..." Ελέγχοντας τη διαμόρφωση και τον κώδικά μας πολλές φορές και αναιρώντας τις πρόσφατες τροποποιήσεις κώδικα (λόγω εσφαλμένων προδιαγραφών συσκευής PyTorch κατά τη διάρκεια εκκίνησης και με αποτέλεσμα την υπερβολική χρήση της GPU#0), επιλύσαμε αυτά τα ζητήματα.

3. Σφάλματα CPU/RAM Out of Memory (OOM) Αυτά τα σφάλματα δεν είναι εύκολο να εντοπιστούν στο αρχείο καταγραφής σφαλμάτων και συνήθως μπορούν να εντοπιστούν μέσω του αρχείου καταγραφής dmesg του κεντρικού υπολογιστή εκτός του κοντέινερ Docker. Όταν το OOM Killer καλεί για να σταματήσει μια διχαλωμένη διεργασία ή ομότιμο δίκτυο, μπορούμε να δούμε ότι εμφανίζονται κυρίως ως CalledProcessError ή ConnectionError. Όταν ανιχνεύεται μια κλήση OOM Killer από το dmesg, προτιμούμε απλώς να εγκαταλείψουμε τον έλεγχο υγείας και να επανεκκινήσουμε το πλαίσιο. Ελέγξαμε επίσης τις διαδρομές κώδικα για επαρκή χειροκίνητη συλλογή σκουπιδιών (υπάρχει μια ενότητα παρακάτω σχετικά με τον τρόπο απενεργοποίησης αυτής) και επίσης ελέγξαμε για τυχόν απροσδόκητες προσπάθειες να κάνουμε υπολογισμούς ή να μετακινήσουμε τανυστές στη CPU.

Συντριβή κατά τη διάρκεια της προπόνησης

Η πρώτη προτεραιότητα είναι να αυτοματοποιηθεί το σύστημα, ώστε να μπορεί να επαναλάβει αυτόματα όλους τους ελέγχους υγείας και στη συνέχεια να επανεκκινήσει εάν δεν βρεθεί ένας ανθυγιεινός κεντρικός υπολογιστής. Αντιμετωπίσαμε ορισμένα τυχαία σφάλματα υλικού, συμπεριλαμβανομένων των σφαλμάτων Xid και SXid, αυτά τα σφάλματα θα μπορούσαν να προκαλέσουν συντριβή της εκτέλεσης χωρίς να εκπέμπουν ένα σημαντικό ίχνος στοίβας Python. Ορισμένα ζητήματα, όπως η επαναχαρτογράφηση σειρών, μπορούν να ανακτηθούν με επανεκκίνηση. Άλλα προβλήματα, όπως τα μη διορθωμένα σφάλματα ECC, απαιτούν συχνά συντήρηση υλικού ή ανταλλακτικά.

Επιπλέον, παρατηρήσαμε ότι τα λανθασμένα δεδομένα προπόνησης μπορούν επίσης να προκαλέσουν ατυχήματα. Για παράδειγμα, εάν υπάρχει ένα πολύ μεγάλο μεμονωμένο έγγραφο στο σώμα, μπορεί να προκαλέσει σφάλμα εξάντλησης μνήμης στη GPU ή την CPU. Για να αποτρέψουμε αυτό το πρόβλημα, χρησιμοποιούμε ένα πλήρως ντετερμινιστικό πρόγραμμα φόρτωσης δεδομένων - καθιστώντας κάθε σφάλμα αναπαραγώγιμη εύκολα, συνδέοντάς το με έναν αριθμό εποχής ή βήματος. Διαπιστώσαμε ότι η απενεργοποίηση της φόρτωσης δεδομένων ή η αντικατάσταση πλαστών δεδομένων (όπως όλα τα δεδομένα) συμβάλλει στην επιβεβαίωση εάν η βασική αιτία του σφάλματος είναι τα δεδομένα.

Τέλος, μπορεί επίσης να είναι χρήσιμη η καταγραφή στατιστικών στοιχείων υγείας δικτύου και γενικών κόμβων μέσω μεθόδων μετρικής συνάθροισης. Ζητήματα όπως μια σύντομη αποσύνδεση Ethernet ή ο χαμηλός χώρος στο δίσκο ενδέχεται να μην εμφανίζονται ως χρήσιμα μηνύματα σφάλματος, αλλά μπορούν εύκολα να συσχετιστούν με τα δεδομένα που συλλέγονται.

Παραμονή χωρίς ίχνος στοίβας (ενδέχεται να υπάρχουν προβλήματα χρονικού ορίου αργότερα)

Λόγω της έλλειψης χρήσιμων πληροφοριών για αυτά τα ζητήματα και της δυσκολίας αξιόπιστης αναπαραγωγής τους, η αποσφαλμάτωση αυτών των τύπων σφαλμάτων μπορεί να είναι απογοητευτική.

Ένας από τους πιο αξιομνημόνευτους τύπους σφαλμάτων συνοδεύεται από μηνύματα λάθους όπως αυτό:

Λήξη χρονικού ορίου λειτουργίας συλλογικής λειτουργίας Watchdog:WorkNCCL (SeqNum=408951, OpType=_ALLGATHER_BASE, … , Timeout (ms)=600000) έτρεξε για 600351 χιλιοστά του δευτερολέπτου πριν λήξει

Και όλοι οι εργαζόμενοι της GPU στην εκτέλεση εκπαίδευσης εξέδωσαν τέτοια μηνύματα σφάλματος.

Αυτό σημαίνει ότι ένας ή περισσότεροι κεντρικοί υπολογιστές απέτυχαν να ολοκληρώσουν τη λειτουργία NCCL ή οι συνδέσεις NCCL και InfiniBand κατέρρευσαν, με αποτέλεσμα όλοι οι άλλοι κεντρικοί υπολογιστές να κολλήσουν σε μια λειτουργία τανυστήρα ταυτόχρονα μέχρι να συμπληρωθεί το χρονικό όριο NCCL_TIMEOUT. Δυστυχώς, λόγω της φύσης της βιβλιοθήκης λογισμικού NCCL, είναι δύσκολο να βρεθεί ποιος κεντρικός υπολογιστής έχει το πρόβλημα.

Κάναμε ορισμένες τροποποιήσεις στην καταγραφή της βιβλιοθήκης λογισμικού NCCL, ανατρέξτε στη διχαλωμένη έκδοση: https://github.com/boweiliu/nccl. Αυτό μπορεί να αποκαλύψει καλύτερα τα μηνύματα ή τις λειτουργίες που εκτελούνται όταν συμβαίνει ένα σφάλμα και, επομένως, να προσδιορίσει ποιος κεντρικός υπολογιστής ή GPU μπορεί να εμποδίζει την εκτέλεσή του.

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

Άλλες καταστάσεις που δεν ανταποκρίνονται χωρίς διαθέσιμα μηνύματα σφάλματος σχετίζονται συνήθως με ζητήματα που σχετίζονται με το υλικό, όπως τα προαναφερθέντα σφάλματα Xid/SXid/ECC που προκαλούν το κλείδωμα του προγράμματος οδήγησης NVIDIA ή του προγράμματος οδήγησης επικοινωνίας NVIDIA Docker. Για να διακρίνουμε το NCCL hangs από τις κολλήσεις οδηγών και τις συνθήκες αγώνα ή τα αδιέξοδα στον κώδικα Python, χρησιμοποιούμε εργαλεία όπως το Py-Spy και το GNU Project Debugger (GDB) για τον εντοπισμό σφαλμάτων σε πραγματικό χρόνο. Ανακαλύφθηκε ένα συγκεκριμένο ζήτημα χρησιμοποιώντας αυτήν την προσέγγιση: λόγω ενός σφάλματος διαμόρφωσης στις ρυθμίσεις νημάτων Python, δεν μπορέσαμε να εκκινήσουμε σωστά οκτώ διεργασίες GPU NCCL πολλαπλών νημάτων σε ορισμένους κεντρικούς υπολογιστές, οι οποίοι αντιμετώπισαν μια συνθήκη κούρσας στο στάδιο του κώδικα προετοιμασίας πριν από το PyTorch.

Επιβράδυνση προπόνησης (μετρούμενη με MFU)

Η έλλειψη εργαλείων καθιστά αυτό το είδος προβλήματος ακόμη πιο απογοητευτικό από το προηγούμενο. Εκτός από τη χρήση του Py-Spy, της επιθεώρησης ανίχνευσης στοίβας και του GDB, χρησιμοποιήσαμε επίσης εργαλεία NVIDIA Nsight και δημιουργίας προφίλ, μερικά από τα οποία είναι δύσκολο να χρησιμοποιηθούν σε ρυθμίσεις υψηλής κατανομής.

Δυστυχώς, υπάρχουν πολλοί λόγοι για μια γενική επιβράδυνση ή χαμηλότερη ταχύτητα από το μοντέλο χρήσης κινητής υποδιαστολής (MFU) που παρουσιάστηκε προηγουμένως.

Πρώτον, αποδεικνύεται χρήσιμο να ελέγχετε τη διαμόρφωση, τον κώδικα και τις μεταβλητές περιβάλλοντος πολλές φορές. Τα σφάλματα που αντιμετωπίσαμε περιλαμβάνουν την εκτέλεση λανθασμένου μοντέλου, λάθος μέγεθος παρτίδας, λανθασμένες ρυθμίσεις UFM ή NCCL, σφάλματα CUDA_DEVICE_MAX_CONNECTIONS. Αυτό θα έχει ως αποτέλεσμα τη μη βέλτιστη απόδοση.

Θεωρούμε επίσης χρήσιμο να μετράμε τη στιγμιαία (δηλαδή, ανά παρτίδα) MFU (αντί για εξομαλυνμένους ή παραθυρωμένους μέσους όρους), καθώς οι μη εξομαλυνόμενες καμπύλες MFU συχνά βοηθούν στη διάγνωση κατηγοριών προβλημάτων. Τα προβλήματα που προκαλούν επιβράδυνση της προπόνησης περιλαμβάνουν:

Ξεκινήστε αμέσως την προπόνηση από πολύ χαμηλό MFU (λιγότερο από το ένα δέκατο του αναμενόμενου) και μείνετε σταθεροί

Πιθανότατα πρόκειται για πρόβλημα υλικού με τη σύνδεση δικτύου InfiniBand, όπως σφάλμα διακόπτη επιπέδου T2 ή T3. Προβλήματα υλικού μεταξύ της GPU και του NIC ενδέχεται επίσης να προκαλέσουν αυτήν την κατάσταση, για την οποία το dmesg θα αναφέρει ένα σφάλμα όπως αυτό: Οι λωρίδες PCIe x16 περιορίζονται από…

Ξεκινήστε αμέσως την προπόνηση από το 30% της αναμενόμενης MFU και μείνετε σταθεροί

Αυτό μπορεί να οφείλεται σε εσφαλμένες ρυθμίσεις GDR σε έναν κεντρικό υπολογιστή (ομότιμη μνήμη NVIDIA) ή σε λανθασμένες μεταβλητές περιβάλλοντος GDR.

Ξεκινήστε αμέσως την προπόνηση από περίπου 60-80% της αναμενόμενης MFU και μείνετε σταθεροί

Η πιο συνηθισμένη αιτία είναι η κακή ή ελαττωματική ποιότητα σύνδεσης InfiniBand, συγκεκριμένα μια αποτυχία που σχετίζεται με το InfiniBand NIC σε μια μεμονωμένη GPU, με αποτέλεσμα το NCCL να προσπαθεί να δρομολογήσει την κυκλοφορία μέσω εγγενούς NVLink και να χρησιμοποιήσει το NIC σε άλλη GPU στον ίδιο κεντρικό υπολογιστή. Ο στραγγαλισμός της CPU μπορεί επίσης να προκαλέσει αυτό το πρόβλημα, το οποίο απαιτεί προσαρμογή των ρυθμίσεων του BIOS σε ορισμένους κεντρικούς υπολογιστές.

Ξαφνική τεράστια επιβράδυνση (κάτω κατά 10x) κατά την επεξεργασία ορισμένων παρτίδων δεδομένων, και αυτό συμβαίνει αρκετά συχνά

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

Ξαφνική τεράστια επιβράδυνση (10x πτώση) κατά την επεξεργασία ορισμένων παρτίδων δεδομένων

Αυτό συμβαίνει τυχαία και αρκετά σπάνια (περίπου μία φορά κάθε 15 λεπτά) και ακολουθείται αμέσως από πλήρη επιστροφή στην καλή MFU.

Η πιο κοινή αιτία φαίνεται να είναι ότι άλλοι φόρτοι εργασίας με ένταση CPU έχουν προγραμματιστεί σε έναν κεντρικό υπολογιστή που λειτουργεί. Διαπιστώσαμε ότι αντί να δημιουργήσουμε εργαλεία δημιουργίας προφίλ για τον εντοπισμό συγκεκριμένων κεντρικών υπολογιστών, ήταν ευκολότερο να παρακολουθήσουμε χονδρικά την CPU με PID. Η αιτία μπορεί να είναι περιστασιακά ζητήματα συνδεσιμότητας δικτύου, όπως σημεία συμφόρησης στο πρόγραμμα φόρτωσης δεδομένων. Παρακολουθήσαμε φορτώσεις δεδομένων, σημεία ελέγχου και μετρήσεις για οποιονδήποτε κώδικα που δεν είναι NCCL και προσθέσαμε αρχεία καταγραφής χρονισμού κώδικα Python, τα οποία αποδείχθηκαν πολύ αξιόπιστα.

Το MFU σταδιακά επιβραδύνεται κατά τη λειτουργία, αλλά επιστρέφει στο 100% μετά από κάθε επανεκκίνηση

Θεωρητικά, η αιτία θα μπορούσε να είναι η συσσώρευση θερμότητας στον διακόπτη, αλλά δεν το έχουμε δει ποτέ να συμβαίνει αυτό. Ωστόσο, χρησιμοποιήσαμε προγράμματα προφίλ Python και NVIDIA για να προσδιορίσουμε ότι η αιτία της υποβάθμισης της απόδοσης φαίνεται να είναι η αυτόματη συλλογή σκουπιδιών.

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

Χρησιμοποιήσαμε έναν σύγχρονο κατανεμημένο αλγόριθμο εκπαίδευσης FSDP με βάση το ZeRO-3. Κατά τη διάρκεια μιας λειτουργίας αποκλεισμού, μια μεμονωμένη διαδικασία εργαζομένου που εκτελεί τη συλλογή απορριμμάτων μπορεί να επιβραδύνει όλους τους άλλους εργαζόμενους. Εάν έχετε εκατοντάδες διαδικασίες εργασίας, αυτό μπορεί να προκαλέσει σημαντική επιβράδυνση.

Η απόδοση είναι καλή στην αρχή, μετά πέφτει ξαφνικά (στο 70% της αναμενόμενης) και συνεχίζει σε υψηλή συχνότητα (κάθε 15 δευτερόλεπτα)

Παρατηρήσαμε ότι αυτό σχετίζεται με "λόγους περιορισμού του ρολογιού" στις GPU της NVIDIA, οι οποίες μπορούν να επιλυθούν με τις κατάλληλες ρυθμίσεις για το NVIDIA DCGM. Θερμικά ζητήματα (υψηλή θερμοκρασία GPU ή αποτυχία ανεμιστήρα ψύξης κεντρικού υπολογιστή/μειωμένη αποτελεσματικότητα) ή διακοπή τροφοδοσίας μπορεί να προκαλέσει αυτό το ζήτημα. Επίσης, όταν μεγιστοποιούμε τη χρήση 8 GPU και τη χρήση 8x NIC InfiniBand μαζί με CPU/RAM/δίσκο, ορισμένοι από τους κεντρικούς υπολογιστές μας με συγκεκριμένο υλικό τροφοδοσίας έχουν προβλήματα τάσης, αλλά τα χρησιμοποιούν μόνο όλα (συνήθως μόνο σε Αυτό συμβαίνει μόνο κατά τη πραγματική πορεία εκπαίδευσης).

Καλή απόδοση αλλά περισσότερος θόρυβος από το συνηθισμένο (διακύμανση λευκού θορύβου υψηλής συχνότητας μεταξύ 90% και 100% της αναμενόμενης MFU)

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

Δυστυχώς, πολλά από αυτά τα ζητήματα είναι δύσκολο να εντοπιστούν σε συγκεκριμένο κεντρικό υπολογιστή και τα ζητήματα που σχετίζονται με το InfiniBand είναι ιδιαίτερα δύσκολο να εντοπιστούν λόγω της τοπολογίας της τεχνολογίας μεταγωγής InfiniBand. Το InfiniBand φαίνεται να ευνοεί τους παρακείμενους κεντρικούς υπολογιστές στο σχέδιο InfiniBand fat-tree, ενώ το UFM μπορεί να δρομολογήσει πακέτα σε ασύμμετρες ταχύτητες σύνδεσης.

Ακολουθεί μια απλή σύνοψη/διάγραμμα ροής/λίστα ελέγχου πληρότητας για τον εντοπισμό σφαλμάτων σχετικά με τη διεκπεραίωση:

Αυτό το σύστημα λειτουργούσε σωστά πριν;

Ποιες αλλαγές κάνατε πρόσφατα (όπως συγχώνευση κώδικα, ενημέρωση προγραμμάτων οδήγησης);

Είναι υγιής ο οικοδεσπότης που τρέχετε; Όλες οι εξαρτώμενες υπηρεσίες σας εκτελούνται κανονικά, συμπεριλαμβανομένου του SaaS τρίτων, όπως το Docker Hub, το GitHub κ.λπ.;

Μπορείτε να είστε σίγουροι ότι ο κώδικας, το περιβάλλον, η διαμόρφωση, η έκδοση, η λίστα κεντρικών υπολογιστών, η σειρά κατάταξης και ο τυχαίος σπόρος που εκτελείτε τώρα είναι ακριβώς τα ίδια με την προηγούμενη φορά; (Εάν ένας τέτοιος έλεγχος μπορούσε να εφαρμοστεί.)

Είναι το πρόβλημα αναπαραγόμενο;

Πώς σχετίζεται με άλλα πράγματα; Άλλες διαδικασίες; Καθημερινές προγραμματισμένες εργασίες crontab; Κεντρικός υπολογιστής ή ένδειξη DCGM ή UFM;

Το εργαλείο σας μετρά σωστά αυτές τις μετρήσεις;

Επιμένει το πρόβλημα κατά την εκτέλεση μιας απογυμνωμένης έκδοσης του κώδικα (χρησιμοποιώντας μικρότερα μοντέλα, πλαστά δεδομένα, χωρίς αποθήκευση ή φόρτωση σημείων ελέγχου);

Βελτίωση εργαλείων υποδομής

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

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

Σχεδόν όλα τα προβλήματα που αντιμετωπίζουμε κατά τη διάρκεια της εκπαίδευσης μπορούν να αποδοθούν σε αστοχία μηχανήματος ή στοιχείου δικτύου. Αυτοί οι τύποι αστοχιών είναι συνηθισμένοι σε μεγάλα συμπλέγματα, επομένως η προσέγγισή μας είναι να απενεργοποιήσουμε αυτόματα το μηχάνημα και τα στοιχεία δικτύου που απέτυχαν και να στείλουμε ένα αίτημα επισκευής.

δυσλειτουργία του μηχανήματος

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

Αποτυχία στοιχείου δικτύου

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

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

τοπικό σύστημα αρχείων καθρέφτη

Για αυτές τις μεγάλες κατανεμημένες εκπαιδεύσεις, έχει ανακαλυφθεί εδώ και καιρό ότι η ταχύτητα ανταλλαγής δεδομένων μεταξύ του συμπλέγματος και του Ethernet αποτελεί εμπόδιο. Το εύρος ζώνης μιας κοινόχρηστης σύνδεσης Ethernet είναι περίπου 10 Gbit/s, αυτό το εύρος ζώνης μπορεί να κορεστεί γρήγορα εάν εκατοντάδες εργαζόμενοι πραγματοποιήσουν λήψη συνόλων δεδομένων και μοντέλων σημείων ελέγχου ταυτόχρονα.

Για το σκοπό αυτό, αποφασίσαμε να δημιουργήσουμε ένα τοπικό σύστημα αρχείων μέσα στο σύμπλεγμα μας ως καθρέφτη για αποθήκευση στο cloud, το οποίο είναι ουσιαστικά ένας χώρος προσωρινής μνήμης που μπορεί να μειώσει τον όγκο των αρχείων που διαβάζονται από το S3. Για να λάβουμε υπόψη τη διακοπή συμπλέγματος (δηλαδή, όταν ένα μηχάνημα είναι απενεργοποιημένο ή αντικαθίσταται για λόγους συντήρησης), έχουμε τρία αντίγραφα κάθε αρχείου και χρησιμοποιούμε συνεπή κατακερματισμό για ομοιόμορφη κατανομή του φορτίου για μεγιστοποίηση της απόδοσης κατά τη διάρκεια της ανατροπής του συμπλέγματος. Δεδομένου ότι το σύμπλεγμα έχει περιορισμένο χώρο στο δίσκο, έπρεπε να αναπτύξουμε εργαλεία για την παρακολούθηση του κύκλου ζωής των αρχείων και την εκκαθάριση αρχείων που δεν ήταν πλέον χρήσιμα.

Τοπικό κατανεμημένο μητρώο Docker

Χρησιμοποιήσαμε το Kraken, το οποίο είναι ένα εξαιρετικό λογισμικό ανοιχτού κώδικα για τη μεταφορά εικόνων Docker από σημείο σε σημείο. Δεν είχαμε σχεδόν κανένα πρόβλημα με το λογισμικό, κάτι που μας εξέπληξε, λαμβάνοντας υπόψη την πολυπλοκότητα των εργασιών και της εφαρμογής μας. Διεύθυνση εργαλείου: https://github.com/uber/kraken

Διάφορα εργαλεία παρακολούθησης απόδοσης

Ρυθμίσαμε τον προεπιλεγμένο αναλυτή Torch και τα Nsight Systems της NVIDIA. Το τελευταίο μάς βοηθά να κατανοήσουμε τον ακριβή χρόνο που απαιτείται για τα περάσματα προς τα εμπρός/πίσω και την επικοινωνία NCCL, και επιπλέον μας βοηθά να προσδιορίσουμε εάν ένα δεδομένο μέγεθος μοντέλου και αριθμός εργαζομένων θα γίνει εμπόδιο. Ωστόσο, το Nsight Systems είναι λίγο δύσκολο στη χρήση επειδή απαιτεί την εκτέλεση του Docker σε προνομιακή λειτουργία, η οποία απαιτεί την απενεργοποίηση των ελέγχων ασφαλείας που σχετίζονται με συμβάντα παρακολούθησης απόδοσης και η αποθήκευση της διαμόρφωσής του απαιτεί συχνά τη διακοπή ολόκληρης της διαδικασίας εκπαίδευσης.

Επιπλέον, έχουμε γραπτά εργαλεία για τον εντοπισμό αργών παρτίδων προπόνησης και την κατανόηση των πιθανών αιτιών τους. Αυτό το βρήκαμε χρήσιμο. Το πιο χρήσιμο εργαλείο παρακολουθεί πόσο χρόνο χρειάζεται κάθε παρτίδα και απορρίπτει το ίχνος στοίβας του εργαζομένου εάν μια παρτίδα είναι πολύ αργή - διευκολύνοντας την εύρεση κεντρικών υπολογιστών με μικρά προβλήματα υλικού ή λογισμικού.

Διαχωρίστε τα μηχανήματα σε διαφορετικές ομάδες για να εντοπίσετε τους αποτυχημένους κεντρικούς υπολογιστές

Τους πρώτους μήνες χρήσης του συμπλέγματος (όταν οι έλεγχοι υγείας δεν ήταν τόσο διεξοδικοί όσο τώρα), συναντούσαμε συχνά μια κατάσταση όπου παρουσιάστηκε μια αποτυχία κατά την προπόνηση σε μια ομάδα μηχανών, αλλά δεν ήταν σαφές ποια μηχανή είχε το πρόβλημα ερώτηση. Για να βρούμε ελαττωματικούς κεντρικούς υπολογιστές, αναπτύξαμε εργαλεία που διευκολύνουν τον διαχωρισμό ενός συνόλου μηχανών σε διαφορετικές ομάδες και την εκτέλεση μικρότερων εκπαιδεύσεων σε κάθε ομάδα μηχανών.

Για παράδειγμα, εάν μια προπόνηση σε 48 μηχανές αποτύχει, τότε εκτελέστε μια μικρότερη προπόνηση σε 6 ομάδες των 8 μηχανών η καθεμία και, στη συνέχεια, εκτελέστε τη μικρότερη προπόνηση σε 8 ομάδες των 6 μηχανών η καθεμία. Συνήθως, μόνο μία εκτέλεση από τις δύο φάσεις θα αποτύχει, δίνοντάς μας σιγουριά για να συμπεράνουμε ότι ένα μηχάνημα που αποτυγχάνει και στις δύο φάσεις είναι ελαττωματικό.

Προβληματισμός και διδάγματα

Κατά τη διαδικασία εγκατάστασης και συντήρησης της υποδομής, πήραμε μερικά χρήσιμα μαθήματα:

Μια χρήσιμη προσέγγιση είναι η εναλλαγή της θέσης των μηχανών. Κατά το χρόνο εκτέλεσης, μπορεί να είναι χρήσιμο να χρησιμοποιείτε 10-20% περισσότερες μηχανές από τις απαιτούμενες, έτσι ώστε η εκπαίδευση να μπορεί να επανεκκινηθεί εύκολα σε περίπτωση βλάβης του μηχανήματος. Η ρύθμιση της δικτύωσης συμπλέγματος έτσι ώστε κάθε μηχάνημα να είναι στενά συνδεδεμένο με κάθε άλλο μηχάνημα, μας επιτρέπει να χρησιμοποιούμε οποιοδήποτε υποσύνολο εργασίας αυτών των μηχανημάτων.

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

Η αναπαραγωγιμότητα είναι το κλειδί για την καλή επιστημονική έρευνα. Μία από τις μεγάλες αρχές που υιοθετήσαμε αμέσως ήταν: «Αλλάξτε μόνο ένα πράγμα τη φορά», ακόμα και στα πιο απλά πράγματα.

Εμπιστευτείτε, αλλά και επαληθεύστε. Κάθε φορά που εισάγουμε εξωτερικά εργαλεία ή φέρνουμε νέα άτομα (είτε από το εσωτερικό είτε από το εξωτερικό της εταιρείας), ελέγχουμε ξανά αυτό που ισχυρίζονται, ειδικά εάν τα επόμενα βήματα εξαρτώνται από αυτούς τους ισχυρισμούς.

Συνοψίζω

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

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

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