Βελτιώστε την απόδοση των μοντέλων Falcon με το Amazon SageMaker | Υπηρεσίες Ιστού της Amazon

Ποιο είναι το βέλτιστο πλαίσιο και η διαμόρφωση παραμέτρων για τη φιλοξενία μοντέλων μεγάλων γλωσσών (LLM) για εφαρμογές τεχνητής νοημοσύνης που δημιουργούν κείμενο; Παρά την πληθώρα επιλογών για την εξυπηρέτηση των LLMs, αυτό είναι ένα δύσκολο ερώτημα για να απαντηθεί λόγω του μεγέθους των μοντέλων, των ποικίλων αρχιτεκτονικών μοντέλων, των απαιτήσεων απόδοσης των εφαρμογών και άλλων. ο Amazon Sage Maker Εμπορευματοκιβώτιο Large Model Inference (LMI). καθιστά εύκολη την εξυπηρέτηση των LLM συγκεντρώνοντας μια σειρά από διαφορετικά πλαίσια και τεχνικές που βελτιστοποιούν την ανάπτυξη των LLM. Το κοντέινερ LMI έχει μια ισχυρή στοίβα σερβιρίσματος που ονομάζεται Σερβίρισμα DJL που είναι αγνωστικιστικό για το υποκείμενο LLM. Παρέχει παραμέτρους διαμόρφωσης σε επίπεδο συστήματος που μπορούν να ρυθμιστούν για την εξαγωγή της καλύτερης απόδοσης της υποδομής φιλοξενίας για ένα δεδομένο LLM. Διαθέτει επίσης υποστήριξη για πρόσφατες βελτιστοποιήσεις, όπως η συνεχής παρτίδα, γνωστή και ως επαναληπτική παρτίδα ή κυλιόμενη παρτίδα, η οποία παρέχει σημαντικές βελτιώσεις στην απόδοση.

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

Βασικές αρχές συμπεράσματος δημιουργίας κειμένου για LLMs

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

Προώθηση πάσο, ενεργοποιήσεις και κρυφή μνήμη KV

Δεδομένης μιας ακολουθίας εισόδου από διακριτικά, εκτελούνται σε α forward pass σε όλα τα επίπεδα του LLM (όπως το Falcon) για να δημιουργήσετε το επόμενο διακριτικό. ΕΝΑ forward pass αναφέρεται στη διαδικασία των δεδομένων εισόδου που διέρχονται μέσω ενός νευρωνικού δικτύου για την παραγωγή μιας εξόδου. Στην περίπτωση δημιουργίας κειμένου, το μπροστινό πέρασμα περιλαμβάνει την τροφοδοσία μιας αρχικής αρχής ή περιβάλλοντος στο γλωσσικό μοντέλο και τη δημιουργία του επόμενου χαρακτήρα ή διακριτικού στην ακολουθία. Για να δημιουργηθεί μια ακολουθία κειμένου, η διαδικασία συχνά γίνεται επαναληπτικά, που σημαίνει ότι επαναλαμβάνεται για κάθε βήμα ή θέση στην ακολουθία εξόδου. Σε κάθε επανάληψη, το μοντέλο δημιουργεί τον επόμενο χαρακτήρα ή διακριτικό, το οποίο γίνεται μέρος του παραγόμενου κειμένου και αυτή η διαδικασία συνεχίζεται μέχρι να δημιουργηθεί το επιθυμητό μήκος κειμένου.

Η δημιουργία κειμένου με γλωσσικά μοντέλα όπως το Falcon ή το GPT είναι autoregressive. Αυτό σημαίνει ότι το μοντέλο δημιουργεί ένα διακριτικό τη φορά, ενώ ρυθμίζει τα κουπόνια που δημιουργήθηκαν προηγουμένως. Με άλλα λόγια, σε κάθε επανάληψη, το μοντέλο παίρνει το κείμενο που δημιουργήθηκε προηγουμένως ως είσοδο και προβλέπει το επόμενο διακριτικό με βάση αυτό το πλαίσιο. Όπως αναφέρεται στο vLLM: Εύκολη, γρήγορη και φθηνή υπηρεσία LLM με PagedAttention, σε αυτήν την αυτοπαλινδρομική διαδικασία αποκωδικοποίησης, όλα τα διακριτικά εισόδου στο LLM παράγουν τους τανυστές κλειδιού προσοχής και τιμής και αυτοί οι τανυστές διατηρούνται στη μνήμη της GPU για να δημιουργήσουν τα επόμενα διακριτικά. Αυτοί οι τανυστές κλειδιού και τιμών που έχουν αποθηκευτεί στην κρυφή μνήμη αναφέρονται συχνά ως το KV cache.

Φάσεις προπλήρωσης και αποκωδικοποίησης

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

Η φάση προπλήρωσης περιλαμβάνει τα ακόλουθα:

• Αρχικό πλαίσιο – Η φάση προπλήρωσης ξεκινά με ένα αρχικό κείμενο περιβάλλοντος ή αρχικού κειμένου που παρέχεται από τον χρήστη. Αυτό το αρχικό πλαίσιο μπορεί να είναι μια πρόταση, μια φράση ή ακόμα και μόνο μια λέξη. Θέτει το σημείο εκκίνησης για τη δημιουργία κειμένου και παρέχει το πλαίσιο για το τι θα ακολουθήσει.
• Κλιματισμός μοντέλου – Το παρεχόμενο πλαίσιο χρησιμοποιείται για τη ρύθμιση του γλωσσικού μοντέλου. Το μοντέλο παίρνει αυτό το πλαίσιο ως είσοδο και δημιουργεί το επόμενο διακριτικό (λέξη ή χαρακτήρα) στην ακολουθία με βάση την κατανόηση του περιβάλλοντος.
• Δημιουργία διακριτικών – Το μοντέλο δημιουργεί ένα διακριτικό κάθε φορά, προβλέποντας τι θα ακολουθήσει στο κείμενο. Αυτό το διακριτικό προσαρτάται στο πλαίσιο, επεκτείνοντάς το ουσιαστικά.
• Επαναληπτική διαδικασία – Η διαδικασία δημιουργίας διακριτικών επαναλαμβάνεται επαναληπτικά. Σε κάθε βήμα, το μοντέλο δημιουργεί ένα διακριτικό λαμβάνοντας υπόψη το ενημερωμένο πλαίσιο, το οποίο περιλαμβάνει πλέον τα διακριτικά που δημιουργήθηκαν σε προηγούμενα βήματα.

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

Η φάση αποκωδικοποίησης περιλαμβάνει τα εξής:

• Ολοκλήρωση – Μετά τη φάση προπλήρωσης, έχετε ένα μερικώς δημιουργημένο κείμενο που μπορεί να είναι ημιτελές ή να αποκοπεί κάποια στιγμή. Η φάση της αποκωδικοποίησης είναι υπεύθυνη για τη συμπλήρωση του κειμένου για να γίνει συνεκτικό και γραμματικά σωστό.
• Συνέχεια από το τελευταίο διακριτικό – Στη φάση της αποκωδικοποίησης, το μοντέλο ξεκινά από το τελευταίο διακριτικό που δημιουργήθηκε κατά τη φάση προπλήρωσης. Χρησιμοποιεί αυτό το διακριτικό ως αρχικό πλαίσιο και δημιουργεί το επόμενο διακριτικό για να συνεχίσει το κείμενο.
• Επαναληπτική ολοκλήρωση – Όπως και στη φάση προπλήρωσης, η διαδικασία δημιουργίας διακριτικών είναι και πάλι επαναληπτική. Το μοντέλο δημιουργεί ένα διακριτικό τη φορά, εξαρτώντας από τα προηγούμενα διακριτικά της ακολουθίας.
• Κατάσταση στάσης – Η φάση αποκωδικοποίησης έχει επίσης μια κατάσταση διακοπής, η οποία μπορεί να είναι η ίδια με τη φάση προπλήρωσης, όπως η επίτευξη ενός μέγιστου μήκους ή η αντιμετώπιση ενός διακριτικού τέλους κειμένου. Όταν πληρούται αυτή η προϋπόθεση, η διαδικασία παραγωγής σταματά.

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

Αναφέρομαι σε Ένα κατανεμημένο σύστημα εξυπηρέτησης για μοντέλα παραγωγής που βασίζονται σε μετασχηματιστές για λεπτομερή επεξήγηση της διαδικασίας.

Βελτιστοποίηση της απόδοσης με χρήση δυναμικής παρτίδας

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

• max_batch_delay = 100 – Η μέγιστη καθυστέρηση για τη συγκέντρωση παρτίδων σε χιλιοστά του δευτερολέπτου. Η προεπιλεγμένη τιμή είναι 100 χιλιοστά του δευτερολέπτου.
• μέγεθος παρτίδας = 32 – Το δυναμικό μέγεθος παρτίδας. Η προεπιλογή είναι 1.

Αυτό ουσιαστικά δείχνει ότι το DJLServing θα βάλει σε ουρά αιτήματα για 100 χιλιοστά του δευτερολέπτου κάθε φορά ή εάν ο αριθμός των αιτημάτων που βρίσκονται στην ουρά είναι μέχρι το καθορισμένο μέγεθος_παρτίδας, η παρτίδα θα προγραμματιστεί να εκτελεστεί στο backend για συμπέρασμα. Αυτό είναι γνωστό ως dynamic batching. Είναι δυναμικό επειδή το μέγεθος της παρτίδας μπορεί να αλλάξει μεταξύ των παρτίδων ανάλογα με τον αριθμό των αιτημάτων που προστέθηκαν σε αυτήν τη χρονική διάρκεια. Ωστόσο, επειδή τα αιτήματα μπορεί να έχουν διαφορετικά χαρακτηριστικά, (για παράδειγμα, ορισμένα αιτήματα μπορεί να έχουν σχήμα 20 tokens εισόδου και 500 tokens εξόδου, ενώ άλλα μπορεί να αντιστραφούν, με 500 tokens εισόδου αλλά μόνο 20 για έξοδο), ορισμένα αιτήματα μπορεί να ολοκληρώνουν την επεξεργασία ταχύτερα από άλλες στην ίδια παρτίδα. Αυτό θα μπορούσε να έχει ως αποτέλεσμα την υποχρησιμοποίηση της GPU ενώ περιμένουν όλα τα αιτήματα κατά τη διάρκεια της πτήσης στη δέσμη για να ολοκληρωθεί το στάδιο αποκωδικοποίησης, ακόμα κι αν υπάρχουν πρόσθετα αιτήματα που περιμένουν να επεξεργαστούν στην ουρά. Το παρακάτω διάγραμμα απεικονίζει αυτή τη διαδικασία.

Βελτιστοποίηση της απόδοσης χρησιμοποιώντας συνεχή παρτίδα

Με continuous batching, γνωστός και ως iterative or rolling κατά παρτίδες, εκμεταλλευόμαστε τις διαφορές μεταξύ των σταδίων προπλήρωσης και αποκωδικοποίησης. Για να ενεργοποιήσετε τη συνεχή παρτίδα, το DJServing παρέχει τις ακόλουθες πρόσθετες διαμορφώσεις σύμφωνα με το serving.properties:

• κινητήρας=MPI – Σας ενθαρρύνουμε να χρησιμοποιήσετε τον κινητήρα MPI για συνεχή παρτίδα.
• option.rolling_batch=auto ή lmi-dist – Συνιστούμε τη χρήση του auto, επειδή θα επιλέξει αυτόματα τον πιο κατάλληλο αλγόριθμο κυλιόμενης παρτίδας μαζί με άλλες βελτιστοποιήσεις στο μέλλον.
• επιλογή.max_rolling_batch_size=32 – Αυτό περιορίζει τον αριθμό των ταυτόχρονων αιτημάτων. Η προεπιλογή είναι 32.

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

Το μέγεθος αυτής της κρυφής μνήμης μπορεί να ρυθμιστεί με την ακόλουθη επιλογή:

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

Ίσως έχετε ήδη συνειδητοποιήσει ότι η συνεχής παρτίδα είναι μια σχεδόν παρόμοια προσέγγιση με την οποία φυσικά παραλληλίζουμε τις εργασίες στην καθημερινή μας ζωή. Έχουμε μηνύματα, email, ειδοποιήσεις τηλεφώνου (ενδεχομένως νέα αιτήματα) που έρχονται σε τυχαία χρονικά διαστήματα (ανάλογα με πολλαπλά αιτήματα που έρχονται με τυχαίο κλιμακωτό τρόπο για τις GPU). Όλα αυτά συμβαίνουν ενώ προχωράμε στην ολοκλήρωση των εργασιών μας κατά την πτήση — σύνταξη email, κωδικοποίηση, συμμετοχή σε συσκέψεις (ανάλογα με τις τρέχουσες εργασίες επεξεργασίας στις GPU). Σε λογικά διαλείμματα, διακόπτουμε παύση τις εργασίες μας κατά την πτήση και ελέγχουμε τις ειδοποιήσεις μας για να αποφασίσουμε εάν απαιτείται κάποια ενέργεια από μέρους μας και, εάν υπάρχει, την προσθέτουμε στις εργασίες μας κατά την πτήση (πραγματική κυλιόμενη παρτίδα) ή βάλτε το σε μια λίστα υποχρεώσεων (την ουρά).

Συνδυάζοντας τα όλα μαζί: Πώς να σκεφτείτε τη χρήση μνήμης των GPU

Συνιστάται να φορτώσετε τη δοκιμή του μοντέλου σας για να δείτε ποια διαμόρφωση είναι η πιο οικονομική για την περίπτωση επαγγελματικής χρήσης σας. Για να κατανοήσουμε, ας απεικονίσουμε το αποτύπωμα μνήμης των GPU καθώς φορτώνεται το μοντέλο και καθώς επεξεργάζονται διαδοχικά αιτήματα σε μια κυλιόμενη παρτίδα. Για αυτήν την ανάρτηση, ας υποθέσουμε ότι φορτώνουμε το μοντέλο Falcon-40B σε ένα από τα στιγμιότυπα τύπων παρουσίας G5 που είναι εγκατεστημένα με GPU NVIDIA A10G, η καθεμία με μνήμη 24 GB. Λάβετε υπόψη ότι παρόμοια κατανόηση ισχύει για τους τύπους παρουσίας p3, p4 και p5, οι οποίοι συνοδεύονται από τις σειρές GPU V100, A100 και H100.

Ακολουθεί η επισκόπηση της λήψης μιας κατά προσέγγιση τιμής της συνολικής μνήμης που απαιτείται για την εξυπηρέτηση του Falcon-40B:

• Μέγεθος μοντέλου = Αριθμός παραμέτρων μοντέλου (40 δισεκατομμύρια για Falcon-40B) x 4 byte ανά παράμετρο (για FP32) = 160 GB
• Κατά προσέγγιση συνολική μνήμη που απαιτείται για τη φόρτωση του Falcon-40B για συμπεράσματα = Μέγεθος μοντέλου (=160 GB) + Προσωρινή μνήμη KV (Κρυφή μνήμη Προσοχής) (=*20 GB) + Πρόσθετη επιβάρυνση μνήμης από ML Frameworks (περίπου 2 GB)

Για το Falcon-40B, εάν συμπιέσουμε το μοντέλο κβαντίζοντας το μοντέλο στον τύπο δεδομένων bfloat16 (2 bytes), το μέγεθος του μοντέλου γίνεται περίπου 80 GB. Όπως μπορείτε να δείτε, αυτή εξακολουθεί να είναι μεγαλύτερη από τη μνήμη που υποστηρίζεται από μία συσκευή επιτάχυνσης, επομένως πρέπει να υιοθετήσουμε μια τεχνική κατάτμησης μοντέλων (sharding) με μια ειδική παραλληλισμός τανυστών (TP) προσεγγίζει και μοιράζει το μοντέλο σε πολλαπλές συσκευές επιταχυντή. Ας υποθέσουμε ότι επιλέξαμε το g5.24xlarge, το οποίο διαθέτει 4 συσκευές GPU A10G. Εάν διαμορφώσουμε το DJLServing (serving.properties) με τα ακόλουθα, μπορούμε να αναμένουμε ότι τα 80 GB βάρη μοντέλου θα κατανεμηθούν εξίσου και στις 4 GPU:

Με tensor_parallel_degree ρυθμισμένο στο 4, περίπου 20 GB της μνήμης GPU των 24 GB (περίπου 84%) χρησιμοποιούνται ήδη ακόμη και πριν από την επεξεργασία ενός μεμονωμένου αιτήματος. Το υπόλοιπο 16% της GPU θα χρησιμοποιηθεί για την κρυφή μνήμη KV για τα εισερχόμενα αιτήματα. Είναι πιθανό για το σενάριο της επιχείρησής σας και τις απαιτήσεις καθυστέρησης και απόδοσης, τα 2–3 GB της εναπομείνασας μνήμης να είναι υπεραρκετά. Εάν όχι, μπορείτε να αυξήσετε το μέγεθος του στιγμιότυπου σε g5.48xlarge, το οποίο έχει 8 GPU και χρησιμοποιεί tensor_parallel_degree που έχει οριστεί σε 8. Σε αυτήν την περίπτωση, μόνο περίπου 10 GB από τη διαθέσιμη μνήμη 24 GB κάθε GPU χρησιμοποιούνται για βάρη μοντέλων και εμείς έχουν περίπου το 60% της υπολειπόμενης GPU για τις ενεργοποιήσεις και την κρυφή μνήμη KV. Διαισθητικά, μπορούμε να δούμε ότι αυτή η διαμόρφωση μπορεί να μας επιτρέψει να έχουμε υψηλότερη απόδοση. Επιπλέον, επειδή έχουμε μεγαλύτερο buffer τώρα, μπορούμε να αυξήσουμε το max_rolling_batch_prefill_tokens και max_rolling_battch_size παραμέτρους για περαιτέρω βελτιστοποίηση της απόδοσης. Μαζί, αυτές οι δύο παράμετροι θα ελέγχουν τις προκατανομές των προγεμίσεων ενεργοποίησης και της κρυφής μνήμης KV για το μοντέλο. Ένας μεγαλύτερος αριθμός για αυτές τις δύο παραμέτρους θα συσχετιστεί με μια μεγαλύτερη απόδοση, με την προϋπόθεση ότι έχετε αρκετό buffer για την κρυφή μνήμη KV στη μνήμη GPU.

Συνεχής ομαδοποίηση με το PagedAttention

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

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

Σύγκριση απόδοσης

Για να διασφαλίσετε την αποτελεσματική δοκιμή φορτίου της διαμόρφωσης ανάπτυξης, συνιστάται να ξεκινήσετε εξετάζοντας το επιχειρηματικό σενάριο και προσδιορίζοντας με σαφήνεια τα χαρακτηριστικά της εισόδου και της εξόδου για την εφαρμογή που βασίζεται στο LLM. Για παράδειγμα, εάν εργάζεστε σε μια περίπτωση χρήσης περίληψης τηλεφωνικού κέντρου, η είσοδος θα μπορούσε να αποτελείται από μεγαλύτερο κείμενο, όπως μια μεταγραφή συνομιλίας 500 τόνων μεταξύ ενός αντιπροσώπου εξυπηρέτησης πελατών και ενός πελάτη, αλλά η έξοδος μπορεί να είναι σχετικά μικρότερη, περίπου 100 μάρκες, που αντιπροσωπεύουν μια περίληψη της μεταγραφής. Από την άλλη πλευρά, εάν εργάζεστε σε ένα σενάριο δημιουργίας κώδικα, η είσοδος θα μπορούσε να είναι τόσο σύντομη όσο 15 διακριτικά, όπως "γράψτε μια αποτελεσματική υλοποίηση στην Python για την περιγραφή όλων των πόρων EC2, συμπεριλαμβανομένης της σελιδοποίησης", αλλά η έξοδος θα μπορούσε να είναι πολύ μεγαλύτερο, φτάνοντας τα 500 μάρκες. Είναι επίσης σημαντικό να εξετάσετε εάν η επίτευξη χαμηλότερου λανθάνοντος χρόνου ή η μεγιστοποίηση της απόδοσης είναι η κορυφαία προτεραιότητα για το συγκεκριμένο σας σενάριο.

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

Στην ανάλυσή μας, κάναμε συγκριτική αξιολόγηση της απόδοσης για να δείξουμε τα οφέλη της συνεχούς παρτίδας έναντι της παραδοσιακής δυναμικής παρτίδας. Χρησιμοποιήσαμε τις διαμορφώσεις που περιγράφονται λεπτομερώς στον παρακάτω πίνακα στο serving.properties για δυναμική παρτίδα και επαναληπτική παρτίδα, χρησιμοποιώντας ένα κοντέινερ LMI στο SageMaker.

Δυναμική παρτίδα	Συνεχής παρτίδα	Συνεχής ομαδοποίηση με PagedAttention
κινητήρας=Python επιλογή.model_id=tiiuae/falcon-40b επιλογή.tensor_parallel_degree=8 option.dtype=fp16 batch_size=4 max_batch_delay=100 option.trust_remote_code = true	κινητήρας = MPI option.model_id = {{s3_url}} option.trust_remote_code = true επιλογή.tensor_parallel_degree = 8 option.max_rolling_batch_size = 32 option.rolling_batch = αυτόματο option.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = Λάθος	κινητήρας = MPI option.model_id = {{s3_url}} option.trust_remote_code = true επιλογή.tensor_parallel_degree = 8 option.max_rolling_batch_size = 32 option.rolling_batch = αυτόματο option.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = Σωστό

Οι δύο διαμορφώσεις συγκρίθηκαν για το Falcon-40B με τον τύπο δεδομένων FP16 που αναπτύχθηκε σε ml.g5.48xlarge σε μερικά διαφορετικά σενάρια που αντιπροσωπεύουν εφαρμογές πραγματικού κόσμου:

• Ένας μικρός αριθμός διακριτικών εισόδου με μεγάλο αριθμό διακριτικών που δημιουργείται – Σε αυτό το σενάριο, ο αριθμός των διακριτικών εισόδου καθορίστηκε σε 32 και δημιουργήθηκαν 128 νέα διακριτικά

Στρατηγική παρτίδων	Διακίνηση (tokens/sec)	Λανθάνουσα περίοδος p90 (δευτ.)
Δυναμική παρτίδα	5.53	58.34
Συνεχής παρτίδα	56.04	4.74
Συνεχής ομαδοποίηση με PagedAttention	59.18	4.76

• Μια μεγάλη είσοδος με μικρό αριθμό διακριτικών που δημιουργείται – Εδώ, διορθώνουμε τον αριθμό των διακριτικών εισόδου σε 256 και ζητάμε από το LLM να συνοψίσει την είσοδο σε 32 διακριτικά

Στρατηγική παρτίδων	Διακίνηση (tokens/sec)	Λανθάνουσα περίοδος p90 (δευτ.)
Δυναμική παρτίδα	19.96	59.31
Συνεχής παρτίδα	46.69	3.88
Συνεχής ομαδοποίηση με PagedAttention	44.75	2.67

Μπορούμε να δούμε ότι η συνεχής παρτίδα με το PagedAttention παρέχει βελτίωση απόδοσης 10 φορές μεγαλύτερη στο σενάριο 1 και 2.3 φορές στο σενάριο 2 σε σύγκριση με τη χρήση δυναμικής παρτίδας στο SageMaker κατά τη χρήση του κοντέινερ LMI.

Συμπέρασμα

Σε αυτήν την ανάρτηση, εξετάσαμε πώς τα LLM χρησιμοποιούν τη μνήμη και εξηγήσαμε πώς η συνεχής παρτίδα βελτιώνει την απόδοση χρησιμοποιώντας ένα κοντέινερ LMI στο SageMaker. Επιδείξαμε τα πλεονεκτήματα της συνεχούς παρτίδας για το Falcon-40B χρησιμοποιώντας ένα δοχείο LMI στο SageMaker, δείχνοντας αποτελέσματα συγκριτικής αξιολόγησης. Μπορείτε να βρείτε τον κωδικό στο GitHub repo.

---

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

Abhi Shivaditya είναι Ανώτερος Αρχιτέκτονας Λύσεων στην AWS, συνεργαζόμενος με στρατηγικούς παγκόσμιους επιχειρηματικούς οργανισμούς για να διευκολύνει την υιοθέτηση υπηρεσιών AWS σε τομείς όπως η Τεχνητή Νοημοσύνη, η κατανεμημένη πληροφορική, η δικτύωση και η αποθήκευση. Η εξειδίκευσή του έγκειται στη Deep Learning στους τομείς της Επεξεργασίας Φυσικής Γλώσσας (NLP) και του Computer Vision. Η Abhi βοηθά τους πελάτες να αναπτύξουν αποτελεσματικά μοντέλα μηχανικής εκμάθησης υψηλής απόδοσης εντός του οικοσυστήματος AWS.

Dhawal Patel είναι Κύριος Αρχιτέκτονας Μηχανικής Μάθησης στο AWS. Έχει συνεργαστεί με οργανισμούς που κυμαίνονται από μεγάλες επιχειρήσεις έως νεοφυείς επιχειρήσεις μεσαίου μεγέθους για προβλήματα που σχετίζονται με τους κατανεμημένους υπολογιστές και την Τεχνητή Νοημοσύνη. Εστιάζεται στη Deep Learning, συμπεριλαμβανομένων των τομέων NLP και Computer Vision. Βοηθά τους πελάτες να επιτύχουν συμπεράσματα μοντέλων υψηλής απόδοσης στο SageMaker.

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

Abhi Sodhani κατέχει τη θέση του Senior AI/ML Solutions Architect στην AWS, όπου ειδικεύεται στην προσφορά τεχνικής εμπειρογνωμοσύνης και καθοδήγησης για Generative AI και ML λύσεις στους πελάτες. Η κύρια εστίασή του είναι να βοηθήσει τις ψηφιακές εγγενείς επιχειρήσεις να αξιοποιήσουν πλήρως τις δυνατότητες των τεχνολογιών Generative AI και ML, δίνοντάς τους τη δυνατότητα να επιτύχουν αποτελεσματικά τους επιχειρηματικούς τους στόχους. Πέρα από τις επαγγελματικές του προσπάθειες, ο Abhi επιδεικνύει έντονο πάθος για πνευματικές αναζητήσεις όπως το διάβασμα, καθώς και η ενασχόληση με δραστηριότητες που προάγουν τη σωματική και ψυχική ευεξία, όπως η γιόγκα, ο διαλογισμός.

Τσινγκ Λαν είναι Μηχανικός Ανάπτυξης Λογισμικού στην AWS. Έχει εργαστεί σε πολλά προκλητικά προϊόντα στο Amazon, συμπεριλαμβανομένων λύσεων συμπερασμάτων ML υψηλής απόδοσης και συστήματος καταγραφής υψηλής απόδοσης. Η ομάδα του Qing κυκλοφόρησε με επιτυχία το πρώτο μοντέλο δισεκατομμυρίων παραμέτρων στο Amazon Advertising με πολύ χαμηλό λανθάνοντα χρόνο που απαιτείται. Ο Qing έχει εις βάθος γνώση σχετικά με τη βελτιστοποίηση της υποδομής και την επιτάχυνση Deep Learning.

• SEO Powered Content & PR Distribution. Ενισχύστε σήμερα.
• PlatoData.Network Vertical Generative Ai. Ενδυναμώστε τον εαυτό σας. Πρόσβαση εδώ.
• PlatoAiStream. Web3 Intelligence. Ενισχύθηκε η γνώση. Πρόσβαση εδώ.
• PlatoESG. Ανθρακας, Cleantech, Ενέργεια, Περιβάλλον, Ηλιακός, Διαχείριση των αποβλήτων. Πρόσβαση εδώ.
• PlatoHealth. Ευφυΐα βιοτεχνολογίας και κλινικών δοκιμών. Πρόσβαση εδώ.
• πηγή: https://aws.amazon.com/blogs/machine-learning/improve-performance-of-falcon-models-with-amazon-sagemaker/