Wzorce projektowe do szeregowego wnioskowania w Amazon SageMaker

W miarę jak uczenie maszynowe (ML) staje się powszechne i zyskuje szersze zastosowanie, aplikacje oparte na ML stają się coraz powszechniejsze w rozwiązywaniu szeregu złożonych problemów biznesowych. Rozwiązanie tych złożonych problemów biznesowych często wymaga użycia wielu modeli ML. Modele te można łączyć sekwencyjnie w celu wykonywania różnych zadań, takich jak przetwarzanie wstępne, transformacja danych, wybór modelu, generowanie wnioskowania, konsolidacja wnioskowania i przetwarzanie końcowe. Organizacje potrzebują elastycznych opcji do organizowania tych złożonych przepływów pracy ML. Szeregowe potoki wnioskowania są jednym z takich wzorców projektowych, które rozmieszczają te przepływy pracy w serii kroków, przy czym każdy krok wzbogaca lub dalej przetwarza dane wyjściowe wygenerowane przez poprzednie kroki i przekazuje dane wyjściowe do następnego kroku w potoku.

Ponadto te szeregowe potoki wnioskowania powinny zapewniać następujące elementy:

• Elastyczna i dostosowana do potrzeb implementacja (zależności, algorytmy, logika biznesowa itd.)
• Powtarzalne i spójne do wdrożenia produkcyjnego
• Niezróżnicowane podnoszenie ciężarów poprzez minimalizację zarządzania infrastrukturą

W tym poście przyjrzymy się niektórym typowym przypadkom użycia dla szeregowych potoków wnioskowania i omówimy niektóre opcje implementacji dla każdego z tych przypadków użycia przy użyciu Amazon Sage Maker. Omówimy również zagadnienia dotyczące każdej z tych opcji implementacji.

W poniższej tabeli podsumowano różne przypadki użycia wnioskowania szeregowego, zagadnienia dotyczące implementacji i opcje. Zostały one omówione w tym poście.

W kolejnych sekcjach szczegółowo omówimy każdy przypadek użycia.

Szeregowy potok wnioskowania przy użyciu kontenerów wnioskowania

Przypadki użycia potoku wnioskowania szeregowego mają wymagania dotyczące wstępnego przetwarzania danych przychodzących przed wywołaniem wstępnie wytrenowanego modelu ML do generowania wniosków. Ponadto w niektórych przypadkach wygenerowane wnioski mogą wymagać dalszego przetwarzania, aby można je było łatwo wykorzystać w dalszych aplikacjach. Jest to typowy scenariusz w przypadkach użycia, w których źródło danych przesyłania strumieniowego musi być przetwarzane w czasie rzeczywistym, zanim będzie można do niego dopasować model. Jednak ten przypadek użycia może również zamanifestować się w przypadku wnioskowania wsadowego.

SageMaker udostępnia opcję dostosowywania kontenerów wnioskowania i używania ich do tworzenia szeregowego potoku wnioskowania. Kontenery wnioskowania używają Zestaw narzędzi do wnioskowania SageMaker i są zbudowane na Serwer wielu modeli SageMaker (MMS), który zapewnia elastyczny mechanizm obsługi modeli ML. Poniższy diagram ilustruje wzorzec referencyjny implementacji potoku wnioskowania szeregowego przy użyciu kontenerów wnioskowania.

SageMaker MMS oczekuje skryptu Python, który implementuje następujące funkcje do ładowania modelu, wstępnego przetwarzania danych wejściowych, uzyskiwania prognoz z modelu i przetwarzania końcowego danych wyjściowych:

• input_fn () – Odpowiedzialny za deserializację i wstępne przetwarzanie danych wejściowych
• model_fn () – Odpowiedzialny za ładowanie wytrenowanego modelu z artefaktów w Usługa Amazon Simple Storage (Amazonka S3)
• przewidywać_fn () – Odpowiedzialny za generowanie wnioskowań z modelu
• wyjście_fn() – Odpowiedzialny za serializację i postprocessing danych wyjściowych (wnioskowania)

Aby uzyskać szczegółowe instrukcje dostosowywania kontenera wnioskowania, zobacz Dostosowywanie własnego kontenera wnioskowania.

Kontenery wnioskowania są idealnym wzorcem projektowym dla przypadków użycia potoku wnioskowania szeregowego z następującymi podstawowymi względami:

• Wysoka spójność – Logika przetwarzania i odpowiadający jej model napędzają pojedynczą funkcjonalność biznesową i muszą być zlokalizowane w jednej lokalizacji
• Niskie całkowite opóźnienie – Czas, jaki upłynął między wysłaniem żądania wnioskowania a otrzymaniem odpowiedzi

W potoku wnioskowania szeregowego logika przetwarzania i model są hermetyzowane w tym samym kontenerze, więc większość wywołań wywołań pozostaje w kontenerze. Pomaga to zmniejszyć ogólną liczbę przeskoków, co skutkuje lepszym ogólnym opóźnieniem i reakcją potoku.

Ponadto w przypadkach użycia, w których łatwość implementacji jest ważnym kryterium, pomocne mogą być kontenery wnioskowania, ponieważ różne etapy przetwarzania potoku mogą znajdować się w tym samym kontenerze.

Szeregowy potok wnioskowania przy użyciu potoku wnioskowania SageMaker

Inna odmiana przypadku użycia potoku wnioskowania szeregowego wymaga wyraźniejszego oddzielenia między różnymi etapami potoku (takimi jak wstępne przetwarzanie danych, generowanie wnioskowania, przetwarzanie końcowe danych oraz formatowanie i serializacja). Może to wynikać z różnych przyczyn:

• Oddzielenie – Różne etapy potoku mają jasno określony cel i muszą być uruchamiane na osobnych kontenerach ze względu na powiązane zależności. Pomaga to również utrzymać dobrą strukturę rurociągu.
• Konstrukcje – Różne etapy potoku wykorzystują określone struktury dopasowane do celu (takie jak scikit lub Spark ML) i dlatego muszą być uruchamiane w osobnych kontenerach.
• Izolacja zasobów – Różne etapy rurociągu mają różne wymagania dotyczące zużycia zasobów i dlatego muszą być uruchamiane w osobnych kontenerach, aby uzyskać większą elastyczność i kontrolę.

Ponadto w przypadku nieco bardziej złożonych potoków wnioskowania szeregowego może być zaangażowanych wiele kroków w celu przetworzenia żądania i wygenerowania wnioskowania. Dlatego z operacyjnego punktu widzenia korzystne może być hostowanie tych kroków w oddzielnych kontenerach w celu lepszej izolacji funkcjonalnej i ułatwienia uaktualnień i ulepszeń (zmiana jednego kroku bez wpływu na inne modele lub etapy przetwarzania).

Jeśli Twój przypadek użycia jest zgodny z niektórymi z tych rozważań, a Potok wnioskowania SageMaker zapewnia łatwą i elastyczną opcję budowania szeregowego potoku wnioskowania. Poniższy diagram ilustruje wzorzec referencyjny implementujący szeregowy potok wnioskowania przy użyciu wielu kroków hostowanych w dedykowanych kontenerach przy użyciu potoku wnioskowania SageMaker.

Potok wnioskowania SageMaker składa się z liniowej sekwencji 2–15 kontenerów, które przetwarzają żądania dotyczące wnioskowania na danych. Potok wnioskowania zapewnia opcję użycia wstępnie wytrenowanych wbudowanych algorytmów programu SageMaker lub niestandardowych algorytmów spakowanych w kontenerach platformy Docker. Kontenery są hostowane w tym samym wystąpieniu bazowym, co pomaga zmniejszyć ogólne opóźnienie i zminimalizować koszty.

Poniższy fragment kodu pokazuje, jak można połączyć wiele kroków przetwarzania i modeli w celu utworzenia potoku wnioskowania szeregowego.

Zaczynamy od zbudowania i określenia modeli opartych na Spark ML i XGBoost, które zamierzamy wykorzystać jako część potoku:

from sagemaker.model import Model
from sagemaker.pipeline_model import PipelineModel
from sagemaker.sparkml.model import SparkMLModel
sparkml_data = 's3://{}/{}/{}'.format(s3_model_bucket, s3_model_key_prefix, 'model.tar.gz')
sparkml_model = SparkMLModel(model_data=sparkml_data)
xgb_model = Model(model_data=xgb_model.model_data, image=training_image)

Modele są następnie ułożone sekwencyjnie w definicji modelu potoku:

model_name = 'serial-inference-' + timestamp_prefix
endpoint_name = 'serial-inference-ep-' + timestamp_prefix
sm_model = PipelineModel(name=model_name, role=role, models=[sparkml_model, xgb_model])

Potok wnioskowania jest następnie wdrażany za punktem końcowym w celu wnioskowania w czasie rzeczywistym przez określenie typu i liczby wystąpień ML hosta:

sm_model.deploy(initial_instance_count=1, instance_type='ml.c4.xlarge', endpoint_name=endpoint_name)

Cały złożony potok wnioskowania można uznać za model SageMaker, którego można użyć do tworzenia prognoz w czasie rzeczywistym lub bezpośredniego przetwarzania transformacji wsadowych, bez żadnego zewnętrznego przetwarzania wstępnego. W modelu potoku wnioskowania program SageMaker obsługuje wywołania jako sekwencję żądań HTTP pochodzących z aplikacji zewnętrznej. Pierwszy kontener w potoku obsługuje początkowe żądanie, wykonuje pewne przetwarzanie, a następnie wysyła odpowiedź pośrednią jako żądanie do drugiego kontenera w potoku. Dzieje się tak dla każdego kontenera w potoku i ostatecznie zwraca ostateczną odpowiedź do wywołującej aplikacji klienckiej.

Potoki wnioskowania programu SageMaker są w pełni zarządzane. Po wdrożeniu potoku SageMaker instaluje i uruchamia wszystkie zdefiniowane kontenery na każdym z Elastyczna chmura obliczeniowa Amazon (Amazon EC2) instancje udostępniane jako część zadania transformacji punktu końcowego lub wsadowego. Ponadto, ponieważ kontenery są zlokalizowane i hostowane w tym samym wystąpieniu EC2, całkowite opóźnienie potoku jest skrócone.

Szeregowy zestaw modeli przy użyciu potoku wnioskowania SageMaker

Model zespołowy to podejście w ML, w którym wiele modeli ML jest łączonych i używanych jako część procesu wnioskowania do generowania wniosków końcowych. Motywacje dla modeli zespołowych mogą obejmować między innymi poprawę dokładności, zmniejszenie wrażliwości modelu na określone cechy wejściowe oraz zmniejszenie błędu systematycznego pojedynczego modelu. W tym poście skupimy się na przypadkach użycia związanych z szeregowym zestawem modeli, w których wiele modeli ML jest sekwencyjnie łączonych w ramach szeregowego potoku wnioskowania.

Rozważmy konkretny przykład związany z zestawem modeli seryjnych, w którym musimy pogrupować przesłane przez użytkownika obrazy na podstawie określonych motywów lub tematów. Ten potok może składać się z trzech modeli ML:

• Model 1 – Akceptuje obraz jako dane wejściowe i ocenia jakość obrazu na podstawie rozdzielczości obrazu, orientacji i nie tylko. Model ten następnie próbuje przeskalować jakość obrazu i przesyła przetworzone obrazy, które spełniają określony próg jakości, do następnego modelu (Model 2).
• Model 2 – Akceptuje obrazy zweryfikowane za pomocą Modelu 1 i wykonuje rozpoznawanie obrazu do identyfikowania obiektów, miejsc, osób, tekstu i innych niestandardowych działań i koncepcji na obrazach. Dane wyjściowe z Modelu 2, które zawierają zidentyfikowane obiekty, są wysyłane do Modelu 3.
• Model 3 – Akceptuje dane wyjściowe z Modelu 2 i wykonuje zadania przetwarzania języka naturalnego (NLP), takie jak modelowanie tematów w celu grupowania obrazów w oparciu o motywy. Na przykład obrazy można pogrupować na podstawie lokalizacji lub zidentyfikowanych osób. Dane wyjściowe (grupy) są odsyłane z powrotem do aplikacji klienckiej.

Poniższy diagram ilustruje wzorzec referencyjny implementacji wielu modeli ML hostowanych w zestawie modeli szeregowych przy użyciu potoku wnioskowania SageMaker.

Jak wspomniano wcześniej, zarządzany jest potok wnioskowania programu SageMaker, co umożliwia skupienie się na wyborze i rozwoju modelu ML, przy jednoczesnym zmniejszeniu niezróżnicowanego podnoszenia ciężarów związanego z budowaniem potoku zespołu szeregowego.

Ponadto niektóre z omówionych wcześniej rozważań dotyczących odsprzęgania, wyboru algorytmu i struktury na potrzeby opracowywania modeli i wdrażania są również istotne w tym przypadku. Na przykład, ponieważ każdy model jest hostowany w osobnym kontenerze, masz elastyczność w wyborze struktury ML, która najlepiej pasuje do każdego modelu i ogólnego przypadku użycia. Ponadto, z punktu widzenia odsprzęgania i operacyjnego, można znacznie łatwiej kontynuować modernizację lub modyfikację poszczególnych kroków, bez wpływu na inne modele.

Potok wnioskowania SageMaker jest również zintegrowany z Rejestr modeli SageMaker do katalogowania modeli, wersjonowania, zarządzania metadanymi i nadzorowanego wdrażania w środowiskach produkcyjnych w celu wspierania spójnych najlepszych praktyk operacyjnych. Potok wnioskowania SageMaker jest również zintegrowany z Amazon Cloud Watch aby umożliwić monitorowanie modeli wielokontenerowych w potokach wnioskowania. Możesz także uzyskać wgląd w metryki w czasie rzeczywistym aby lepiej zrozumieć wywołania i opóźnienia dla każdego kontenera w potoku, co pomaga w rozwiązywaniu problemów i optymalizacji zasobów.

Szeregowy potok wnioskowania (z wywołaniem modelu docelowego z grupy) przy użyciu potoku wnioskowania SageMaker

Wielomodelowe punkty końcowe SageMaker (MME) zapewniają ekonomiczne rozwiązanie do wdrażania dużej liczby modeli ML za jednym punktem końcowym. Motywacje do korzystania z wielomodelowych punktów końcowych mogą obejmować powoływanie się na konkretny dostosowany model oparty na cechach żądania (takich jak pochodzenie, lokalizacja geograficzna, personalizacja użytkownika itd.) lub po prostu hostowanie wielu modeli za tym samym punktem końcowym w celu osiągnięcia optymalizacji kosztów.

W przypadku wdrażania wielu modeli w jednym punkcie końcowym z obsługą wielu modeli wszystkie modele współużytkują zasoby obliczeniowe i kontener obsługujący model. Potok wnioskowania SageMaker można wdrożyć w MME, gdzie jeden z kontenerów w potoku może dynamicznie obsługiwać żądania na podstawie wywoływanego określonego modelu. Z perspektywy potoku modele mają identyczne wymagania dotyczące przetwarzania wstępnego i oczekują tego samego zestawu funkcji, ale są przeszkolone w celu dostosowania do określonego zachowania. Poniższy diagram ilustruje wzorzec referencyjny działania tego zintegrowanego potoku.

W przypadku MME żądanie wnioskowania pochodzące z aplikacji klienckiej powinno określać model docelowy, który należy wywołać. Pierwszy kontener w potoku obsługuje początkowe żądanie, wykonuje pewne przetwarzanie, a następnie wysyła odpowiedź pośrednią jako żądanie do drugiego kontenera w potoku, który obsługuje wiele modeli. Na podstawie modelu docelowego określonego w żądaniu wnioskowania model jest wywoływany w celu wygenerowania wnioskowania. Wygenerowane wnioskowanie jest wysyłane do następnego kontenera w potoku w celu dalszego przetwarzania. Dzieje się tak dla każdego kolejnego kontenera w potoku, a na koniec SageMaker zwraca ostateczną odpowiedź do wywołującej aplikacji klienckiej.

Wiele artefaktów modelu jest utrwalanych w zasobniku S3. Po wywołaniu określonego modelu SageMaker dynamicznie ładuje go do kontenera obsługującego punkt końcowy. Jeśli model jest już załadowany do pamięci kontenera, wywołanie jest szybsze, ponieważ SageMaker nie musi pobierać modelu z Amazon S3. Jeśli wykorzystanie pamięci instancji jest wysokie i wywoływany jest nowy model i dlatego musi zostać załadowany, nieużywane modele są usuwane z pamięci. Wyładowane modele pozostają jednak w objętości pamięci instancji i można je później ponownie załadować do pamięci kontenera, bez ponownego pobierania z zasobnika S3.

Jednym z kluczowych zagadnień podczas korzystania z MME jest zrozumienie zachowania opóźnienia wywołania modelu. Jak wspomniano wcześniej, modele są dynamicznie ładowane do pamięci kontenera instancji hostującej punkt końcowy po wywołaniu. W związku z tym wywołanie modelu może potrwać dłużej, gdy jest wywoływane po raz pierwszy. Gdy model znajduje się już w pamięci kontenera instancji, kolejne wywołania są szybsze. Jeśli wykorzystanie pamięci instancji jest wysokie i trzeba załadować nowy model, nieużywane modele zostaną zwolnione. Jeśli wolumen pamięci instancji jest pełny, nieużywane modele są usuwane z wolumenu pamięci. SageMaker w pełni zarządza ładowaniem i rozładowywaniem modeli, bez konieczności podejmowania konkretnych działań. Jednak ważne jest, aby zrozumieć to zachowanie, ponieważ ma ono wpływ na opóźnienie wywołania modelu, a zatem ogólne opóźnienie.

Opcje hostingu potokowego

SageMaker zapewnia wiele typ wystąpienia opcje do wyboru w celu wdrażania modeli ML i tworzenia potoków wnioskowania na podstawie przypadku użycia, przepustowości i wymagań dotyczących kosztów. Na przykład można wybrać wystąpienia zoptymalizowane pod kątem procesora CPU lub GPU, aby utworzyć szeregowe potoki wnioskowania w jednym kontenerze lub w wielu kontenerach. Jednak czasami istnieją wymagania, w których wymagana jest elastyczność i obsługa uruchamiania modeli na wystąpieniach opartych na procesorze CPU lub GPU w tym samym potoku w celu uzyskania dodatkowej elastyczności.

Możesz teraz używać serwera NVIDIA Triton Inference Server do obsługi modeli do wnioskowania w programie SageMaker dla heterogenicznych wymagań obliczeniowych. Kasy Wdrażaj szybką i skalowalną sztuczną inteligencję z NVIDIA Triton Inference Server w Amazon SageMaker aby uzyskać dodatkowe informacje.

Wnioski

Gdy organizacje odkrywają i budują nowe rozwiązania oparte na ML, narzędzia wymagane do orkiestracji tych potoków powinny być wystarczająco elastyczne, aby wspierać w oparciu o dany przypadek użycia, przy jednoczesnym uproszczeniu i zmniejszeniu bieżących kosztów operacyjnych. SageMaker zapewnia wiele opcji projektowania i budowania takich przepływów pracy wnioskowania szeregowego w oparciu o Twoje wymagania.

Z niecierpliwością czekamy na wiadomość od Ciebie o tym, jakie przypadki użycia tworzysz przy użyciu potoków wnioskowania szeregowego. Jeśli masz pytania lub uwagi, podziel się nimi w komentarzach.

O autorach

Rahul Sharma jest starszym architektem rozwiązań w AWS Data Lab, pomagającym klientom AWS projektować i budować rozwiązania AI/ML. Przed dołączeniem do AWS Rahul spędził kilka lat w sektorze finansowym i ubezpieczeniowym, pomagając klientom budować platformy danych i analityczne.

Anand Prakasz jest starszym architektem rozwiązań w AWS Data Lab. Anand koncentruje się na pomaganiu klientom w projektowaniu i tworzeniu rozwiązań AI/ML, analizy danych i baz danych w celu przyspieszenia ich drogi do produkcji.

Dawal Patel jest głównym architektem uczenia maszynowego w AWS. Pracował z organizacjami od dużych przedsiębiorstw po średniej wielkości start-upy w zakresie problemów związanych z przetwarzaniem rozproszonym i sztuczną inteligencją. Koncentruje się na uczeniu głębokim, w tym w domenach NLP i Computer Vision. Pomaga klientom uzyskać wnioskowanie o wysokiej wydajności modelu w SageMaker.

Saurabha Trikande jest starszym menedżerem produktu w firmie Amazon SageMaker Inference. Pasjonuje go praca z klientami i zwiększanie dostępności uczenia maszynowego. W wolnym czasie Saurabh lubi wędrować, poznawać innowacyjne technologie, śledzić TechCrunch i spędzać czas z rodziną.