Uruchamiaj i optymalizuj wielomodelowe wnioskowanie za pomocą wielomodelowych punktów końcowych Amazon SageMaker

Amazon Sage Maker wielomodelowy punkt końcowy (MME) umożliwia ekonomiczne wdrażanie i hostowanie wielu modeli w jednym punkcie końcowym, a następnie poziome skalowanie punktu końcowego w celu osiągnięcia skali. Jak pokazano na poniższym rysunku, jest to skuteczna technika implementowania modeli z wieloma dzierżawcami w ramach infrastruktury uczenia maszynowego (ML). Widzieliśmy, jak firmy zajmujące się oprogramowaniem jako usługą (SaaS) wykorzystują tę funkcję do stosowania hiperpersonalizacji w swoich modelach ML, przy jednoczesnym osiąganiu niższych kosztów.

Aby uzyskać ogólny przegląd tego, jak działa MME, obejrzyj wideo AWS Summit Skalowanie ML na wyższy poziom: Hosting tysięcy modeli w SageMaker. Aby dowiedzieć się więcej o hiperspersonalizowanych, wielodostępnych przypadkach użycia, które umożliwia MME, zobacz Jak skalować wnioskowanie uczenia maszynowego dla przypadków użycia SaaS dla wielu dzierżawców.

W dalszej części tego wpisu zagłębimy się w architekturę techniczną SageMaker MME i podzielimy się najlepszymi praktykami optymalizacji wielomodelowych punktów końcowych.

Przypadki użycia najlepiej dopasowane do MME

Wielomodelowe punkty końcowe programu SageMaker dobrze nadają się do hostowania dużej liczby modeli, które można obsługiwać za pośrednictwem współdzielonego kontenera udostępniania i nie trzeba uzyskiwać dostępu do wszystkich modeli jednocześnie. W zależności od rozmiaru pamięci wystąpienia punktu końcowego model może czasami zostać zwolniony z pamięci na rzecz załadowania nowego modelu, aby zmaksymalizować efektywne wykorzystanie pamięci, dlatego aplikacja musi być odporna na sporadyczne skoki opóźnień w nieobciążonych modelach.

MME jest również przeznaczony do współhostowania modeli korzystających z tej samej struktury ML, ponieważ używają one udostępnionego kontenera do ładowania wielu modeli. Dlatego też, jeśli w swojej flocie modeli masz mieszankę platform ML (takich jak PyTorch i TensorFlow), dedykowane punkty końcowe SageMaker lub hosting wielokontenerowy są lepszym wyborem.

Wreszcie, MME nadaje się do aplikacji, które mogą tolerować sporadyczne kary za opóźnienie zimnego startu, ponieważ modele są ładowane przy pierwszym wywołaniu, a rzadko używane modele mogą zostać usunięte z pamięci na rzecz ładowania nowych modeli. W związku z tym, jeśli masz kombinację często i rzadko używanych modeli, wielomodelowy punkt końcowy może wydajnie obsługiwać ten ruch przy użyciu mniejszej liczby zasobów i większych oszczędności kosztów.

Widzieliśmy również kilka scenariuszy, w których klienci wdrażają klaster MME z wystarczającą pojemnością pamięci zagregowanej, aby zmieścić wszystkie ich modele, w ten sposób całkowicie unikając odciążania modeli, a jednocześnie osiągając oszczędności kosztów dzięki współdzielonej infrastrukturze wnioskowania.

Modelowe pojemniki do serwowania

W przypadku korzystania z zestawu narzędzi SageMaker Inference Toolkit lub gotowego kontenera obsługującego model SageMaker zgodnego z MME, kontener ma Serwer wielu modeli (proces JVM) uruchomiony. Najłatwiejszym sposobem włączenia serwera Multi Model Server (MMS) do kontenera obsługującego model jest użycie Model SageMaker obsługujący kontenery kompatybilny z MME (poszukaj tych z typem zadania=wnioskowanie i CPU/GPU=CPU). MMS to łatwe w użyciu narzędzie typu open source do obsługi modeli uczenia głębokiego. Zapewnia interfejs API REST z serwerem sieciowym do obsługi i zarządzania wieloma modelami na jednym hoście. Jednak korzystanie z MMS nie jest obowiązkowe; możesz zaimplementować własny serwer modelowy, o ile implementuje on Interfejsy API wymagane przez MME.

W przypadku użycia jako część platformy MME wszystkie przewidywania, ładowanie i zwalnianie wywołań interfejsu API do MMS lub własnego serwera modelu są kierowane przez kontroler płaszczyzny danych MME. Wywołania API z kontrolera płaszczyzny danych są wykonywane tylko za pośrednictwem lokalnego hosta, aby zapobiec nieautoryzowanemu dostępowi z zewnątrz instancji. Jedną z kluczowych zalet MMS jest to, że umożliwia korzystanie ze znormalizowanego interfejsu do ładowania, rozładowywania i wywoływania modeli ze zgodnością w szerokim zakresie platform uczenia głębokiego.

Zaawansowana konfiguracja MMS

Jeśli zdecydujesz się używać MMS do udostępniania modelu, rozważ następujące zaawansowane konfiguracje, aby zoptymalizować skalowalność i przepustowość wystąpień MME.

Zwiększ równoległość wnioskowania na model

MMS tworzy jeden lub więcej procesów roboczych Pythona na model na podstawie wartości default_workers_per_model parametr konfiguracyjny. Te procesy robocze Pythona obsługują każde indywidualne żądanie wnioskowania, uruchamiając dowolne funkcje przetwarzania wstępnego, przewidywania i przetwarzania końcowego. Aby uzyskać więcej informacji, zobacz obsługa niestandardowej usługi Repozytorium GitHub.

Posiadanie więcej niż jednego pracownika modelu zwiększa równoległość predykcji, które mogą być obsługiwane przez dany model. Jeśli jednak duża liczba modeli jest hostowana na instancji z dużą liczbą procesorów, należy wykonać test obciążenia MME, aby znaleźć optymalną wartość default_workers_per_model aby zapobiec wyczerpaniu pamięci lub zasobów procesora.

Projekt dla skoków ruchu

Każdy proces MMS w instancji punktu końcowego ma kolejkę żądań, którą można skonfigurować za pomocą rozmiar_kolejki_zadań parametr (domyślnie 100). Określa to liczbę żądań, które MMS będzie czekał w kolejce, gdy wszystkie procesy robocze są zajęte. Użyj tego parametru, aby dostroić czas reakcji wystąpień punktów końcowych po podjęciu decyzji o optymalnej liczbie procesów roboczych na model.

W optymalnym stosunku pracownika na model w większości przypadków domyślna wartość 100 powinna wystarczyć. Jednak w tych przypadkach, w których ruch żądań do punktu końcowego gwałtownie wzrasta, można zmniejszyć rozmiar kolejki, jeśli chcesz, aby punkt końcowy szybko przekazywał kontrolę do aplikacji lub zwiększyć rozmiar kolejki, jeśli chcesz, aby punkt końcowy pochłonął skok .

Maksymalizuj zasoby pamięci na instancję

W przypadku korzystania z wielu procesów roboczych na model domyślnie każdy proces roboczy ładuje własną kopię modelu. Może to zmniejszyć dostępną pamięć instancji dla innych modeli. Możesz zoptymalizować wykorzystanie pamięci, udostępniając jeden model między procesami roboczymi, ustawiając parametr konfiguracyjny preload_model=prawda. W tym miejscu handlujesz zmniejszoną równoległością wnioskowania (z powodu pojedynczego wystąpienia modelu) z większą wydajnością pamięci. To ustawienie wraz z wieloma procesami roboczymi może być dobrym wyborem w przypadkach użycia, w których opóźnienie modelu jest niskie, ale masz intensywniejsze przetwarzanie wstępne i przetwarzanie końcowe (wykonywane przez procesy robocze) na żądanie wnioskowania.

Ustaw wartości dla zaawansowanych konfiguracji MMS

MMS używa pliku config.properties do przechowywania konfiguracji. MMS używa następującej kolejności do zlokalizowania tego pliku config.properties:

1. Jeśli MMS_CONFIG_FILE zmienna środowiskowa jest ustawiona, MMS ładuje konfigurację ze zmiennej środowiskowej.
2. Jeśli --mms-config parametr jest przekazywany do MMS-a, ładuje konfigurację z parametru.
3. Jeśli tam jest config.properties w bieżącym folderze, w którym użytkownik uruchamia MMS, ładuje config.properties plik z bieżącego katalogu roboczego.

Jeśli nie określono żadnego z powyższych, MMS ładuje wbudowaną konfigurację z wartościami domyślnymi.

Poniżej znajduje się przykład uruchamiania MMS z wiersza poleceń z jawnym plikiem konfiguracyjnym:

multi-model-server --start --mms-config /home/mms/config.properties

Kluczowe metryki do monitorowania wydajności punktów końcowych

Kluczowe metryki, które mogą pomóc zoptymalizować MME, są zazwyczaj związane z wykorzystaniem procesora i pamięci oraz opóźnieniem wnioskowania. Metryki na poziomie wystąpienia są emitowane przez program MMS, podczas gdy metryki opóźnień pochodzą z programu MME. W tej sekcji omówimy typowe metryki, których można użyć do zrozumienia i optymalizacji MME.

Wskaźniki na poziomie wystąpienia punktu końcowego (wskaźniki MMS)

Z lista wskaźników MMS, CPUUtilization i MemoryUtilization mogą pomóc w ocenie, czy instancja lub klaster MME ma odpowiedni rozmiar. Jeśli obie metryki mają wartości procentowe między 50–80%, oznacza to, że MME ma odpowiednią wielkość.

Zazwyczaj niski współczynnik CPUUtilization i wysoki MemoryUtilization wskazują na nadmiernie alokowany klaster MME, ponieważ wskazuje, że rzadko wywoływane modele nie są zwalniane. Może to być spowodowane większą niż optymalna liczbą wystąpień punktów końcowych udostępnionych dla MME, a zatem wyższa niż optymalna pamięć zagregowana jest dostępna dla rzadko używanych modeli, aby pozostać w pamięci. Z drugiej strony, blisko 100% wykorzystanie tych metryk oznacza, że ​​klaster jest niedostatecznie aprowizowany, więc musisz dostosować zasady automatycznego skalowania klastra.

Wskaźniki na poziomie platformy (wskaźniki MME)

Z pełna lista wskaźników MME, kluczową metryką, która może pomóc w zrozumieniu opóźnienia żądania wnioskowania, jest ModelCacheHit. Ta metryka pokazuje średni stosunek żądań wywołania, dla których model został już załadowany do pamięci. Jeśli ten współczynnik jest niski, oznacza to, że klaster MME jest niedostatecznie alokowany, ponieważ prawdopodobnie nie ma wystarczającej pojemności pamięci zagregowanej w klastrze MME dla liczby unikalnych wywołań modeli, co powoduje częste usuwanie modeli z pamięci.

Lekcje praktyczne i strategie optymalizacji MME

Widzieliśmy następujące zalecenia dotyczące niektórych zastosowań MME na dużą skalę wśród wielu klientów.

Skalowanie w poziomie z mniejszymi instancjami jest lepsze niż skalowanie w pionie z większymi instancjami

Podczas uruchamiania wysokich żądań na sekundę (RPS) w mniejszej liczbie wystąpień punktów końcowych może wystąpić ograniczanie wywołań modelu. Istnieją wewnętrzne ograniczenia liczby wywołań na sekundę (ładowania i rozładowywania, które mogą mieć miejsce jednocześnie w instancji), dlatego zawsze lepiej jest mieć większą liczbę mniejszych instancji. Uruchomienie większej liczby mniejszych wystąpień oznacza większą łączną pojemność zagregowaną tych limitów dla punktu końcowego.

Inną zaletą skalowania w poziomie z mniejszymi wystąpieniami jest zmniejszenie ryzyka wyczerpania zasobów procesora i pamięci wystąpienia podczas uruchamiania programu MMS z wyższymi poziomami równoległości, a także większą liczbą modeli w pamięci (jak opisano wcześniej w tym poście).

Unikanie thrashingu to wspólna odpowiedzialność

Lanie w MME ma miejsce, gdy modele są często wyładowywane z pamięci i ponownie ładowane z powodu niewystarczającej ilości pamięci, w pojedynczej instancji lub zagregowanej w klastrze.

Z punktu widzenia użytkowania należy odpowiednio dobrać rozmiar poszczególnych wystąpień punktów końcowych i odpowiednio dobrać ogólny rozmiar klastra MME, aby zapewnić wystarczającą ilość pamięci na wystąpienie, a także w agregacji dla klastra dla danego przypadku użycia. Flota routerów platformy MME również zmaksymalizuje wykorzystanie pamięci podręcznej.

Nie bądź agresywny, pakując zbyt wiele modeli do kosza w mniejszej liczbie, większych instancji pamięci

Pamięć nie jest jedynym zasobem instancji, o którym należy pamiętać. Inne zasoby, takie jak procesor, mogą być czynnikiem ograniczającym, co widać w poniższych wynikach testów obciążenia. W niektórych innych przypadkach zaobserwowaliśmy również wyczerpanie innych zasobów jądra, takich jak identyfikatory procesów w instancji, z powodu kombinacji zbyt wielu załadowanych modeli i podstawowej struktury ML (takiej jak TensorFlow) tworzących wątki na model, które były wielokrotnościami dostępnych procesory wirtualne.

Poniższy test wydajności przedstawia przykład ograniczenia procesora wpływające na opóźnienie modelu. W tym teście punkt końcowy pojedynczego wystąpienia z dużym wystąpieniem, mający więcej niż wystarczającą ilość pamięci, aby zachować wszystkie cztery modele w pamięci, generował stosunkowo gorsze opóźnienia modeli pod obciążeniem w porównaniu z punktem końcowym z czterema mniejszymi wystąpieniami.

opóźnienie modelu punktu końcowego pojedynczego wystąpienia

Jednoinstancyjne wykorzystanie procesora i pamięci w punkcie końcowym

Opóźnienie modelu punktu końcowego z czterema instancjami

wykorzystanie procesora i pamięci w czterech instancjach

Aby osiągnąć zarówno wydajność, jak i opłacalność, należy odpowiednio dobrać rozmiar klastra MME, korzystając z większej liczby mniejszych instancji, które łącznie zapewniają optymalną pojemność pamięci i procesora, a jednocześnie są stosunkowo porównywalne pod względem kosztów z mniejszą liczbą, ale większymi instancjami pamięci.

Mentalny model optymalizacji MME

Istnieją cztery kluczowe wskaźniki, które należy zawsze brać pod uwagę podczas dobierania odpowiedniego rozmiaru MME:

• Liczba i wielkość modeli
• Liczba unikalnych modeli wywołanych w danym momencie
• Typ i rozmiar instancji
• Liczba instancji za punktem końcowym

Zacznij od dwóch pierwszych punktów, ponieważ informują one trzeci i czwarty. Na przykład, jeśli za punktem końcowym nie ma wystarczającej liczby instancji dla liczby lub rozmiaru unikalnych modeli, które posiadasz, zagregowana pamięć dla punktu końcowego będzie niska i zobaczysz niższy współczynnik trafień w pamięci podręcznej i zaśmiecanie na poziomie punktu końcowego, ponieważ MME będzie często ładować i rozładowywać modele do iz pamięci.

Podobnie, jeśli wywołania dla unikalnych modeli są wyższe niż zagregowana pamięć wszystkich wystąpień za punktem końcowym, zobaczysz mniejsze trafienie w pamięci podręcznej. Może się to również zdarzyć, jeśli rozmiar instancji (zwłaszcza pojemność pamięci) jest zbyt mały.

Skalowanie w pionie z naprawdę dużymi instancjami pamięci może również prowadzić do problemów, ponieważ chociaż modele mogą pasować do pamięci, inne zasoby, takie jak procesy procesora i jądra oraz limity wątków, mogą zostać wyczerpane. Przetestuj obciążenie testowe skalowania poziomego w fazie przedprodukcyjnej, aby uzyskać optymalną liczbę i rozmiar instancji dla Twojego MME.

Podsumowanie

W tym poście masz głębsze zrozumienie platformy MME. Dowiedziałeś się, do jakich technicznych przypadków użycia MME jest odpowiedni, i zapoznałeś się z architekturą platformy MME. Uzyskałeś głębsze zrozumienie roli każdego komponentu w architekturze MME i tego, które komponenty możesz bezpośrednio wpłynąć na wydajność. Na koniec przyjrzeliśmy się dokładniej parametrom konfiguracyjnym, które można dostosować, aby zoptymalizować MME dla danego przypadku użycia, oraz metrykom, które należy monitorować w celu utrzymania optymalnej wydajności.

Aby rozpocząć korzystanie z MME, przejrzyj Wielomodelowe punkty końcowe Amazon SageMaker korzystające z XGBoost i Hostuj wiele modeli w jednym kontenerze za jednym punktem końcowym.

O autorze

Syeda Jaffry'ego jest głównym architektem rozwiązań w AWS. Współpracuje z wieloma firmami ze średniej wielkości organizacji, dużych przedsiębiorstw, usług finansowych i niezależnych dostawców oprogramowania, aby pomóc im w tworzeniu i obsłudze opłacalnych i skalowalnych aplikacji AI/ML w chmurze.

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ą.