Osiągnij wysoką wydajność na dużą skalę do obsługi modeli przy użyciu wielomodelowych punktów końcowych Amazon SageMaker z procesorem graficznym

Amazon Sage Maker wielomodelowe punkty końcowe (MME) zapewniają skalowalny i ekonomiczny sposób wdrażania dużej liczby modeli uczenia maszynowego (ML). Daje możliwość wdrażania wielu modeli ML w jednym kontenerze obsługującym za jednym punktem końcowym. Stamtąd SageMaker zarządza ładowaniem i rozładowywaniem modeli oraz skalowaniem zasobów w Twoim imieniu na podstawie wzorców ruchu. Skorzystasz na udostępnianiu i ponownym wykorzystywaniu zasobów hostingowych oraz zmniejszonym obciążeniu operacyjnym związanym z zarządzaniem dużą liczbą modeli.

W listopadzie 2022, MME dodały obsługę GPUs, która umożliwia uruchamianie wielu modeli na jednym urządzeniu GPU i skalowanie instancji GPU za jednym punktem końcowym. To zaspokaja silne zapotrzebowanie MME na modele głębokich sieci neuronowych (DNN), które korzystają z przyspieszonych obliczeń z procesorami graficznymi. Należą do nich wizja komputerowa (CV), przetwarzanie języka naturalnego (NLP) i generatywne modele sztucznej inteligencji. Powody żądania są następujące:

• Modele DNN mają zwykle duże rozmiary i złożoność oraz stale rosną w szybkim tempie. Biorąc za przykład modele NLP, wiele z nich przekracza miliardy parametrów, co wymaga od procesorów graficznych spełnienia wymagań dotyczących niskich opóźnień i wysokiej przepustowości.
• Zaobserwowaliśmy zwiększoną potrzebę dostosowywania tych modeli w celu dostarczania hiperspersonalizowanych doświadczeń poszczególnym użytkownikom. Wraz ze wzrostem liczby tych modeli istnieje zapotrzebowanie na łatwiejsze rozwiązanie do wdrażania i operacjonalizacji wielu modeli na dużą skalę.
• Instancje GPU są drogie i chcesz je ponownie wykorzystywać w jak największym stopniu, aby zmaksymalizować wykorzystanie GPU i obniżyć koszty operacyjne.

Chociaż wszystkie te powody wskazują, że MME z procesorem graficznym są idealną opcją dla modeli DNN, zaleca się przeprowadzenie testów obciążenia, aby znaleźć odpowiednią konfigurację punktu końcowego, która spełnia wymagania danego przypadku użycia. Na wyniki testów obciążenia może wpływać wiele czynników, takich jak typ wystąpienia, liczba wystąpień, rozmiar modelu i architektura modelu. Ponadto testy obciążenia mogą pomóc w kierowaniu strategiami automatycznego skalowania przy użyciu właściwych metryk zamiast iteracyjnych metod prób i błędów.

Z tych powodów przygotowaliśmy ten post, aby pomóc Ci przeprowadzić odpowiednie testy obciążenia na MME z GPU i znaleźć najlepszą konfigurację dla twojego przypadku użycia ML. Udostępniamy wyniki naszych testów obciążenia dla niektórych najpopularniejszych modeli DNN w NLP i CV hostowanych przy użyciu MME na różnych typach instancji. Podsumowujemy spostrzeżenia i wnioski z wyników naszych testów, aby pomóc Ci podjąć świadomą decyzję dotyczącą konfiguracji własnych wdrożeń. Przy okazji dzielimy się również naszym zalecanym podejściem do przeprowadzania testów obciążenia dla MME na GPU. Zalecane narzędzia i techniki określają optymalną liczbę modeli, które można załadować na typ instancji, i pomagają osiągnąć najlepszy stosunek ceny do wydajności.

Omówienie rozwiązania

Aby zapoznać się z wprowadzeniem do MME i MME z procesorem graficznym, patrz Utwórz wielomodelowy punkt końcowy i Uruchamiaj wiele modeli głębokiego uczenia na GPU z wielomodelowymi punktami końcowymi Amazon SageMaker. W kontekście testowania obciążenia w tym poście możesz pobrać nasz przykładowy kod ze strony GitHub repo aby odtworzyć wyniki lub użyć go jako szablonu do porównania własnych modeli. W repozytorium dostępne są dwa notebooki: jeden do testowania modeli CV, a drugi do NLP. Kilka modeli o różnych rozmiarach i architekturach zostało porównanych z różnymi typami instancji GPU: ml.g4dn.2xlarge, ml.g5.2xlarge i ml.p3.2xlarge. Powinno to zapewnić rozsądny przekrój wydajności w ramach następujących wskaźników dla każdej instancji i typu modelu:

• Maksymalna liczba modeli, które można załadować do pamięci GPU
• Całkowite opóźnienie odpowiedzi obserwowane po stronie klienta dla każdego zapytania wnioskowania
• Maksymalna przepustowość zapytań na sekundę, którą punkt końcowy może przetworzyć bez błędów
• Maksymalna liczba bieżących użytkowników na instancje przed zaobserwowaniem nieudanego żądania

W poniższej tabeli wymieniono przetestowane modele.

W poniższej tabeli wymieniono przetestowane wystąpienia GPU.

Jak wcześniej wspomniano, przykład kodu można dostosować do innych modeli i typów instancji.

Należy pamiętać, że MME obsługują obecnie tylko pojedyncze instancje GPU. Aby uzyskać listę obsługiwanych typów instancji, zobacz Obsługiwane algorytmy, struktury i instancje.

Procedura benchmarkingu składa się z następujących kroków:

1. Pobierz wstępnie przeszkolony model z centrum modelu.
2. Przygotuj artefakt modelu do udostępnienia w MME SageMaker (patrz Uruchamiaj wiele modeli głębokiego uczenia na GPU z wielomodelowymi punktami końcowymi Amazon SageMaker po więcej szczegółów).
3. Wdróż MME SageMaker na instancji GPU.
4. Określ maksymalną liczbę modeli, które można załadować do pamięci GPU w ramach określonego progu.
5. Użyj Locust Load Testing Framework do symulacji ruchu, który losowo wywołuje modele ładowane w instancji.
6. Zbieraj dane i analizuj wyniki.
7. Opcjonalnie powtórz kroki 2–6 po skompilowaniu modelu do TensorRT.

Kroki 4 i 5 gwarantują głębsze spojrzenie. Modele w SageMaker GPU MME są ładowane do pamięci w sposób dynamiczny. Dlatego w kroku 4 przesyłamy początkowy artefakt modelu do Usługa Amazon Simple Storage (Amazon S3) i wywołaj model, aby załadować go do pamięci. Po początkowym wywołaniu mierzymy ilość zużytej pamięci GPU, wykonujemy kopię początkowego modelu, wywołujemy kopię modelu w celu załadowania go do pamięci i ponownie mierzymy całkowitą ilość zużytej pamięci GPU. Ten proces jest powtarzany do momentu osiągnięcia określonego procentowego progu wykorzystania pamięci GPU. W przypadku testu porównawczego ustawiliśmy próg na 90%, aby zapewnić rozsądny bufor pamięci do wnioskowania na większych partiach lub pozostawienia miejsca na załadowanie innych, rzadziej używanych modeli.

Symuluj ruch użytkowników

Po określeniu liczby modeli możemy przeprowadzić test obciążenia za pomocą Struktura testowania obciążenia szarańczy. Test obciążenia symuluje żądania użytkowników kierowane do losowych modeli i automatycznie mierzy metryki, takie jak opóźnienie odpowiedzi i przepustowość.

Locust obsługuje niestandardowe kształty testów obciążenia, które umożliwiają definiowanie niestandardowych wzorców ruchu. Kształt, który został użyty w tym teście porównawczym, pokazano na poniższym wykresie. W ciągu pierwszych 30 sekund punkt końcowy jest rozgrzewany z 10 jednoczesnymi użytkownikami. Po 30 sekundach nowi użytkownicy pojawiają się w tempie dwóch na sekundę, osiągając 20 jednoczesnych użytkowników w 40 sekundzie. Punkt końcowy jest następnie stale porównywany z 20 jednoczesnymi użytkownikami aż do 60-sekundowego znaku, w którym to momencie Locust ponownie zaczyna zwiększać liczbę użytkowników z szybkością dwóch na sekundę, aż do 40 jednoczesnych użytkowników. Ten wzorzec zwiększania i stałego testowania jest powtarzany, dopóki punkt końcowy nie zostanie powiększony do 200 jednoczesnych użytkowników. W zależności od przypadku użycia możesz dostosować kształt testu obciążenia w pliku locust_benchmark_sm.py, aby dokładniej odzwierciedlał oczekiwane wzorce ruchu. Na przykład, jeśli zamierzasz hostować większe modele językowe, test obciążenia z 200 jednoczesnymi użytkownikami może nie być wykonalny dla modelu hostowanego w jednym wystąpieniu, dlatego możesz chcieć zmniejszyć liczbę użytkowników lub zwiększyć liczbę wystąpień. Możesz także wydłużyć czas trwania testu obciążenia, aby dokładniej ocenić stabilność punktu końcowego w dłuższym okresie czasu.

stages = [
{"duration": 30, "users": 10, "spawn_rate": 5},
{"duration": 60, "users": 20, "spawn_rate": 1},
{"duration": 90, "users": 40, "spawn_rate": 2},
…
]

Zwróć uwagę, że porównaliśmy tylko punkt końcowy z jednorodnymi modelami działającymi na spójnych podstawach udostępniania przy użyciu PyTorch lub TensorRT. Wynika to z faktu, że MME najlepiej nadają się do hostowania wielu modeli o podobnych cechach, takich jak zużycie pamięci i czas odpowiedzi. Szablony testów porównawczych zawarte w GitHub repo nadal można wykorzystać do określenia, czy obsługa heterogenicznych modeli w MME przyniosłaby pożądaną wydajność i stabilność.

Wyniki testów porównawczych dla modeli CV

Użyj notatnika cv-benchmark.ipynb, aby uruchomić testy obciążenia dla modeli wizyjnych. Wstępnie przeszkoloną nazwę modelu i parametry typu wystąpienia można dostosować do testowania obciążenia wydajnościowego na różnych kombinacjach modelu i typu wystąpienia. Celowo przetestowaliśmy trzy modele CV w różnych zakresach rozmiarów, od najmniejszego do największego: resnet50 (25 mln), convnext_base (88M) i vit_large_patch16_224 (304M). Może być konieczne dostosowanie się do kodu, jeśli wybierzesz model spoza tej listy. dodatkowo notebook domyślnie ustawia kształt obrazu wejściowego na tensor obrazu 224x224x3. Pamiętaj, aby odpowiednio dostosować kształt wejściowy, jeśli chcesz porównać modele, które pobierają obraz o różnych rozmiarach.

Po przejrzeniu całego notatnika otrzymasz kilka wizualizacji analizy wydajności. Pierwsze dwa szczegółowo opisują wydajność modelu w odniesieniu do rosnącej liczby jednoczesnych użytkowników. Poniższe rysunki to przykładowe wizualizacje wygenerowane dla programu ResNet50 model działający na ml.g4dn.2xlarge, porównujący PyTorch (po lewej) z TensorRT (po prawej). Górne wykresy liniowe przedstawiają opóźnienie modelu i przepływność na osi y wraz ze wzrostem liczby współbieżnych procesów roboczych klienta odzwierciedlonych na osi x. Dolne wykresy słupkowe pokazują liczbę pomyślnych i nieudanych żądań.

Przyglądając się wszystkim testowanym modelom widzenia komputerowego, zauważyliśmy, co następuje:

• Opóźnienie (w milisekundach) jest większe, a przepustowość (żądania na sekundę) jest niższa w przypadku większych modeli (resnet50 > convnext_base > vit_large_patch16_224).
• Wzrost opóźnienia jest proporcjonalny do liczby użytkowników, ponieważ więcej żądań jest ustawianych w kolejce na serwerze wnioskowania.
• Duże modele zużywają więcej zasobów obliczeniowych i mogą osiągnąć swoje maksymalne limity przepływności przy mniejszej liczbie użytkowników niż mniejszy model. Obserwuje się to z vit_large_patch16_224 modelu, który zarejestrował pierwsze nieudane żądanie przy 140 jednoczesnych użytkownikach. Ponieważ był znacznie większy niż pozostałe dwa testowane modele, miał również najwięcej nieudanych żądań przy wyższej współbieżności. Jest to wyraźny sygnał, że punkt końcowy musiałby skalować poza pojedynczą instancję, jeśli celem jest obsługa ponad 140 jednoczesnych użytkowników.

Pod koniec pracy notebooka otrzymujesz również podsumowanie porównania modeli PyTorch i TensorRT dla każdej z czterech kluczowych metryk. Z naszych testów porównawczych wynika, że ​​wszystkie modele CV odnotowały wzrost wydajności modelu po kompilacji TensorRT. Biorąc nasze ResNet50 modelu jako przykładu, opóźnienie zmniejszyło się o 32%, a przepustowość wzrosła o 18%. Chociaż maksymalna liczba jednoczesnych użytkowników pozostała taka sama dla ResNet50, pozostałe dwa modele odnotowały 14% wzrost liczby jednoczesnych użytkowników, których mogą obsługiwać. Poprawa wydajności TensorRT nastąpiła jednak kosztem większego wykorzystania pamięci, co skutkowało mniejszą liczbą modeli ładowanych przez MME. Wpływ dotyczy bardziej modeli wykorzystujących konwolucyjną sieć neuronową (CNN). W rzeczywistości nasz model ResNet50 zużywał około dwa razy więcej pamięci GPU, przechodząc z PyTorch do TensorRT, co skutkowało załadowaniem o 50% mniej modeli (46 vs. 23). Diagnozujemy to zachowanie dalej w następnej sekcji.

Wyniki testów porównawczych dla modeli NLP

W przypadku modeli NLP użyj notebooka nlp-benchmark.ipynb, aby uruchomić test obciążenia. Konfiguracja notebooka powinna wyglądać bardzo podobnie. Przetestowaliśmy dwa modele NLP: bert-base-uncased (109M) i roberta-large (335M). Wstępnie przeszkolony model i tokenizator są pobierane z centrum Hugging Face, a ładunek testowy jest generowany z tokenizatora przy użyciu przykładowego ciągu. Maksymalna długość sekwencji jest domyślnie ustawiona na 128. Jeśli chcesz przetestować dłuższe łańcuchy, pamiętaj o dostosowaniu tego parametru. Przeglądanie notatnika NLP generuje ten sam zestaw wizualizacji: Pytorch (po lewej) vs TensorRT (po prawej).

Na ich podstawie zaobserwowaliśmy jeszcze większe korzyści w zakresie wydajności TensorRT dla modeli NLP. Biorąc roberta-large na przykładzie instancji ml.g4dn.2xlarge, opóźnienie wnioskowania spadło dramatycznie ze 180 milisekund do 56 milisekund (poprawa o 70%), podczas gdy przepustowość wzrosła o 406% z 33 żądań na sekundę do 167. Ponadto maksymalna liczba jednoczesnych żądań liczba użytkowników wzrosła o 50%; nieudane żądania nie zostały zaobserwowane, dopóki nie osiągnęliśmy 180 jednoczesnych użytkowników, w porównaniu do 120 w przypadku oryginalnego modelu PyTorch. Jeśli chodzi o wykorzystanie pamięci, widzieliśmy o jeden model mniej załadowany dla TensorRT (z dziewięciu modeli do ośmiu). Jednak negatywny wpływ jest znacznie mniejszy w porównaniu z tym, co zaobserwowaliśmy w modelach opartych na CNN.

Analiza wykorzystania pamięci

W poniższej tabeli przedstawiono pełną analizę wpływu wykorzystania pamięci przechodzącą z PyTorch do TensorRT. Wspomnieliśmy wcześniej, że modele oparte na CNN mają bardziej negatywny wpływ. The ResNet50 model miał ponad 50% redukcję liczby modeli ładowanych we wszystkich trzech typach instancji GPU. Convnext_base miał jeszcze większy spadek, wynoszący około 70%. Z drugiej strony wpływ na modele transformatorów jest niewielki lub mieszany. vit_large_patch16_224 i roberta-large odnotowała średnią redukcję odpowiednio o około 20% i 3%. bert-base-uncased miał około 40% poprawę.

Patrząc na wszystkie punkty danych jako całość w odniesieniu do najwyższej wydajności w zakresie opóźnień, przepustowości i niezawodności oraz niewielkiego wpływu na maksymalną liczbę załadowanych modeli, zalecamy model TensorRT dla architektur opartych na transformatorach. W przypadku CNN uważamy, że potrzebna jest dalsza analiza wydajności kosztowej, aby upewnić się, że korzyści z wydajności przewyższają koszt dodatkowej infrastruktury hostingowej.

Poniższe tabele przedstawiają nasze pełne wyniki testów porównawczych dla wszystkich metryk we wszystkich trzech typach instancji GPU.

Poniższa tabela podsumowuje wyniki dla wszystkich typów instancji. Instancja ml.g5.2xlarge zapewnia najlepszą wydajność, podczas gdy instancja ml.p3.2xlarge generalnie osiąga gorsze wyniki, mimo że jest najdroższa z tych trzech. Instancje g5 i g4dn wykazują najlepszą wartość dla obciążeń wnioskowania.

Sprzątać

Po zakończeniu testu obciążenia wyczyść wygenerowane zasoby, aby uniknąć naliczania dodatkowych opłat. Główne zasoby to punkty końcowe SageMaker i pliki artefaktów modeli w Amazon S3. Aby Ci to ułatwić, pliki notesu mają następujący kod czyszczący, który pomoże Ci je usunąć:

delete_endpoint(sm_client, sm_model_name, endpoint_config_name, endpoint_name) ! aws s3 rm --recursive {trt_mme_path}

Wnioski

W tym poście udostępniliśmy nasze wyniki testów i analizy dla różnych modeli głębokich sieci neuronowych działających na wielomodelowych punktach końcowych SageMaker z GPU. Wyniki i spostrzeżenia, które udostępniliśmy, powinny zapewnić rozsądny przekrój wydajności w różnych metrykach i typach instancji. W trakcie tego procesu wprowadziliśmy również nasze zalecane podejście do przeprowadzania testów porównawczych dla SageMaker MME z GPU. Udostępnione przez nas narzędzia i przykładowy kod mogą pomóc w szybkim rozpoczęciu testów porównawczych i podjęciu bardziej świadomej decyzji dotyczącej opłacalnego hostowania setek modeli DNN na przyspieszonym sprzęcie obliczeniowym. Aby rozpocząć testowanie własnych modeli z obsługą MME dla GPU, zobacz Obsługiwane algorytmy, struktury i instancje oraz GitHub repo w celu uzyskania dodatkowych przykładów i dokumentacji.

O autorach

Jamesa Wu jest starszym architektem rozwiązań AI/ML w AWS. pomaganie klientom w projektowaniu i budowaniu rozwiązań AI/ML. Praca Jamesa obejmuje szeroki zakres przypadków użycia ML, ze szczególnym uwzględnieniem wizji komputerowej, głębokiego uczenia i skalowania ML w całym przedsiębiorstwie. Przed dołączeniem do AWS James był architektem, programistą i liderem technologicznym przez ponad 10 lat, w tym 6 lat w inżynierii i 4 lata w branży marketingowej i reklamowej.

Vikrama Elango jest specjalistą ds. rozwiązań AI/ML w Amazon Web Services z siedzibą w Wirginii w USA. Vikram pomaga klientom z branży finansowej i ubezpieczeniowej w projektowaniu, przemyślanym przywództwie w tworzeniu i wdrażaniu aplikacji uczenia maszynowego na dużą skalę. Obecnie koncentruje się na przetwarzaniu języka naturalnego, odpowiedzialnej sztucznej inteligencji, optymalizacji wnioskowania i skalowaniu ML w całym przedsiębiorstwie. W wolnym czasie lubi podróżować, wędrować, gotować i biwakować z rodziną.

Szymon Zamarin jest architektem rozwiązań AI / ML, którego głównym celem jest pomoc klientom w wydobyciu wartości z ich zasobów danych. W wolnym czasie Simon lubi spędzać czas z rodziną, czytając sci-fi i pracując nad różnymi projektami domowymi.

Saurabha Trikande jest starszym menedżerem produktu w firmie Amazon SageMaker Inference. Pasjonuje go praca z klientami i motywuje go cel, jakim jest demokratyzacja uczenia maszynowego. Koncentruje się na podstawowych wyzwaniach związanych z wdrażaniem złożonych aplikacji ML, wielodostępnych modeli ML, optymalizacji kosztów oraz zwiększaniem dostępności wdrażania modeli uczenia głębokiego. W wolnym czasie Saurabh lubi wędrować, poznawać innowacyjne technologie, śledzić TechCrunch i spędzać czas z rodziną.

• Dystrybucja treści i PR oparta na SEO. Uzyskaj wzmocnienie już dziś.
• Platoblockchain. Web3 Inteligencja Metaverse. Wzmocniona wiedza. Dostęp tutaj.
• Źródło: https://aws.amazon.com/blogs/machine-learning/achieve-high-performance-at-scale-for-model-serving-using-amazon-sagemaker-multi-model-endpoints-with-gpu/