Zoptymalizuj swoje zadania wnioskowania za pomocą dynamicznego wnioskowania wsadowego za pomocą TorchServe na Amazon SageMaker

W uczeniu głębokim przetwarzanie wsadowe odnosi się do wprowadzania wielu danych wejściowych do modelu. Chociaż jest to niezbędne podczas szkolenia, może być bardzo pomocne w zarządzaniu kosztami i optymalizowaniu przepływności również w czasie wnioskowania. Akceleratory sprzętowe są zoptymalizowane pod kątem równoległości, a przetwarzanie wsadowe pomaga nasycić moc obliczeniową i często prowadzi do wyższej przepustowości.

Przetwarzanie wsadowe może być pomocne w kilku scenariuszach podczas wdrażania modelu w środowisku produkcyjnym. Tutaj ogólnie dzielimy je na dwa przypadki użycia:

• Aplikacje działające w czasie rzeczywistym, w których od różnych klientów odbieranych jest kilka żądań wnioskowania, które są dynamicznie grupowane i przekazywane do modelu obsługującego. Opóźnienie jest zwykle ważne w takich przypadkach użycia.
• Aplikacje offline, w których kilka danych wejściowych lub żądań jest grupowanych po stronie klienta i wysyłanych do modelu obsługującego. Wyższa przepustowość jest często celem tych przypadków użycia, co pomaga zarządzać kosztami. Przykładowe przypadki użycia obejmują analizę wideo i ocenę modelu.

Amazon Sage Maker udostępnia dwie popularne opcje zadań wnioskowania. W przypadku aplikacji działających w czasie rzeczywistym SageMaker Hosting wykorzystuje TorchServe jako bibliotekę obsługi zaplecza, która obsługuje dynamiczne przetwarzanie wsadowe otrzymanych żądań. W przypadku aplikacji offline można użyć zadań transformacji wsadowej SageMaker. W tym poście omówimy przykład każdej opcji, aby pomóc Ci zacząć.

Ponieważ TorchServe jest natywnie zintegrowany z SageMakerem za pośrednictwem Zestaw narzędzi wnioskowania SageMaker PyTorch, możesz łatwo wdrożyć model PyTorch na TorchServe za pomocą SageMaker Hosting. Może się również zdarzyć, że konieczne będzie dalsze dostosowanie środowiska przy użyciu niestandardowych obrazów platformy Docker. W tym poście najpierw pokazujemy, jak wdrożyć punkt końcowy w czasie rzeczywistym za pomocą natywnego zestawu narzędzi do wnioskowania SageMaker PyTorch i skonfigurować rozmiar partii w celu optymalizacji przepustowości. W drugim przykładzie pokazujemy, jak używać niestandardowego obrazu platformy Docker do konfigurowania zaawansowanych konfiguracji TorchServe, które nie są dostępne jako zmienna środowiskowa w celu optymalizacji zadania wnioskowania wsadowego.

Najlepsze praktyki dotyczące wnioskowania wsadowego

Przetwarzanie wsadowe może zwiększyć przepustowość i zoptymalizować zasoby, ponieważ pomaga ukończyć większą liczbę wniosków w określonym czasie kosztem opóźnień. Aby zoptymalizować wdrożenie modelu pod kątem większej przepływności, ogólną wskazówką jest zwiększanie rozmiaru wsadu do momentu zmniejszenia przepływności. To najczęściej pasuje do aplikacji offline, w których kilka danych wejściowych jest grupowanych (takich jak klatki wideo, obrazy lub tekst) w celu uzyskania danych wyjściowych prognozy.

W przypadku aplikacji działających w czasie rzeczywistym opóźnienie jest często głównym problemem. Istnieje kompromis między wyższą przepustowością a zwiększonym rozmiarem partii i opóźnieniem; może być konieczne dostosowanie w razie potrzeby, aby spełnić umowę SLA dotyczącą opóźnień. Jeśli chodzi o najlepsze praktyki w chmurze, koszt określonej liczby wniosków jest pomocną wskazówką przy podejmowaniu świadomej decyzji spełniającej potrzeby biznesowe. Jednym z czynników wpływających na zarządzanie kosztami jest wybór odpowiedniego akceleratora. Aby uzyskać więcej informacji, zobacz Wybierz najlepszy akcelerator AI i kompilację modeli do wnioskowania o obrazie komputerowym za pomocą Amazon SageMaker.

Dynamiczne przetwarzanie wsadowe TorchServe w SageMaker

PochodniaPodaj to natywna biblioteka PyTorch do obsługi modeli w produkcji na dużą skalę. To wspólne opracowanie Facebooka i AWS. TorchServe umożliwia monitorowanie, dodawanie niestandardowych wskaźników, obsługę wielu modeli, zwiększanie i zmniejszanie liczby pracowników za pomocą bezpiecznych interfejsów API do zarządzania oraz zapewnianie punktów końcowych wnioskowania i wyjaśniania.

Aby wspierać przetwarzanie wsadowe, TorchServe udostępnia funkcję dynamicznego przetwarzania wsadowego. Agreguje odebrane żądania w określonym przedziale czasowym, grupuje je razem i wysyła partię do wnioskowania. Otrzymane żądania są przetwarzane przez Wozy w TorchServe. TorchServe ma kilka domyślnych procedur obsługi i możesz stworzyć niestandardową procedurę obsługi, jeśli Twój przypadek użycia nie jest uwzględniony. W przypadku korzystania z niestandardowej procedury obsługi upewnij się, że w procedurze obsługi została zaimplementowana logika wnioskowania wsadowego. Przykład niestandardowej procedury obsługi z obsługą wnioskowania wsadowego jest dostępny na GitHub.

Możesz skonfigurować dynamiczne przetwarzanie wsadowe za pomocą dwóch ustawień, batch_size i max_batch_delay, albo poprzez zmienne środowiskowe w SageMaker, albo przez config.properties plik w TorchServe (jeśli używasz niestandardowego kontenera). TorchServe używa dowolnego ustawienia, które pojawia się jako pierwsze, albo maksymalnego rozmiaru wsadu (batch_size) lub określone okno czasowe oczekiwania na przejście partii żądań max_batch_delay.

Dzięki integracji TorchServe z SageMaker możesz teraz wdrażać modele PyTorch natywnie w SageMaker, gdzie możesz zdefiniować model SageMaker PyTorch. Możesz dodać niestandardowe ładowanie modelu, wnioskowanie oraz logikę wstępnego i końcowego przetwarzania w skrypcie przekazanym jako punkt wejścia do SageMaker PyTorch (zobacz poniższy przykładowy kod). Alternatywnie możesz użyć niestandardowego kontenera do wdrożenia modeli. Aby uzyskać więcej informacji, zobacz Modelowy serwer SageMaker PyTorch.

Możesz ustawić rozmiar partii dla modeli PyTorch w SageMaker za pomocą zmiennych środowiskowych. Jeśli zdecydujesz się użyć kontenera niestandardowego, możesz połączyć go w pakiet w panelu ustawień in config.properties ze swoim modelem podczas pakowania modelu w TorchServe. Poniższy fragment kodu pokazuje przykład, jak ustawić rozmiar partii za pomocą zmiennych środowiskowych i jak wdrożyć model PyTorch w SageMaker:

from SageMaker.pytorch.model import PyTorchModel env_variables_dict = { "SAGEMAKER_TS_BATCH_SIZE": "3", "SAGEMAKER_TS_MAX_BATCH_DELAY": "100000"
} pytorch_model = PyTorchModel( model_data=model_artifact, role=role, source_dir="code", framework_version='1.9', entry_point="inference.py", env=env_variables_dict
) predictor = pytorch_model.deploy(initial_instance_count=1, instance_type="ml.c5.2xlarge", serializer=SageMaker.serializers.JSONSerializer(), deserializer=SageMaker.deserializers.BytesDeserializer())

We fragmencie kodu model_artifact odnosi się do wszystkich plików wymaganych do ponownego załadowania wytrenowanego modelu, który jest archiwizowany w pliku .tar i przekazywany do pliku Usługa Amazon Simple Storage (Amazon S3) wiadro. Plik inference.py jest podobny do niestandardowego modułu obsługi TorchServe; ma kilka funkcji, które można przesłonić, aby uwzględnić inicjalizację modelu, przetwarzanie wstępne i końcowe otrzymanych żądań oraz logikę wnioskowania.

Poniższy notatnik pokazuje pełny przykład wdrożenia modelu BERT przytulania twarzy.

Jeśli potrzebujesz niestandardowego kontenera, możesz utworzyć niestandardowy obraz kontenera i przekazać go do Rejestr elastycznego pojemnika Amazon (Amazon ECR). W tym przypadku artefaktem modelu może być plik TorchServe .mar, który łączy artefakty modelu wraz z procedurą obsługi. Pokażemy to w następnej sekcji, w której użyjemy zadania transformacji wsadowej SageMaker.

Zadanie transformacji wsadowej SageMaker

W przypadkach użycia w trybie offline, w których żądania są grupowane ze źródła danych, takiego jak zestaw danych, zapewnia SageMaker zadania przekształcania wsadowego. Te zadania umożliwiają odczytywanie danych z zasobnika S3 i zapisywanie wyników w docelowym zasobniku S3. Aby uzyskać więcej informacji, zobacz Użyj transformacji wsadowej, aby uzyskać wnioski z dużych zbiorów danych. Pełny przykład wnioskowania wsadowego przy użyciu zadań transformacji wsadowej można znaleźć poniżej notatnik, gdzie wykorzystujemy model tłumaczenia maszynowego z konkursu FLORES. W tym przykładzie pokazujemy, jak użyć niestandardowego kontenera do oceny naszego modelu za pomocą SageMaker. Korzystanie z niestandardowego kontenera wnioskowania umożliwia dalsze dostosowanie konfiguracji TorchServe. W tym przykładzie chcemy zmienić i wyłączyć dekodowanie JSON, co możemy zrobić za pomocą TorchServe config.properties plik.

Używając niestandardowego modułu obsługi dla TorchServe, musimy upewnić się, że moduł obsługi implementuje logikę wnioskowania wsadowego. Każda procedura obsługi może mieć niestandardowe funkcje do wykonywania przetwarzania wstępnego, wnioskowania i przetwarzania końcowego. Przykład niestandardowej procedury obsługi z obsługą wnioskowania wsadowego jest dostępny na GitHub.

Używamy naszego niestandardowego kontenera do łączenia artefaktów modelu z modułem obsługi, tak jak robimy to w TorchServe (tworzenie pliku .mar). Potrzebujemy również punktu wejścia do kontenera Docker, który uruchamia TorchServe z ustawionym rozmiarem wsadu i dekodowaniem JSON config.properties. Pokazujemy to na przykładzie notatnik.

Zadanie transformacji wsadowej SageMaker wymaga dostępu do plików wejściowych z zasobnika S3, gdzie dzieli pliki wejściowe na mini partie i wysyła je do wnioskowania. Podczas konfigurowania zadania transformacji wsadowej należy wziąć pod uwagę następujące kwestie:

• Umieść pliki wejściowe (takie jak zbiór danych) w zasobniku S3 i ustaw je jako źródło danych w ustawieniach zadania.
• Przypisz zasobnik S3, w którym mają zostać zapisane wyniki zadania transformacji wsadowej.
• Zestaw Strategia wsadowa do MultiRecord i SplitType do Line jeśli potrzebujesz zadania transformacji wsadowej, aby utworzyć mini partie z pliku wejściowego. Jeśli nie może automatycznie podzielić zbioru danych na mini partie, możesz podzielić go na mini partie, umieszczając każdą partię w oddzielnym pliku wejściowym, umieszczonym w zasobniku źródła danych S3.
• Upewnij się, że wielkość partii mieści się w pamięci. SageMaker zwykle obsługuje to automatycznie; jednak przy ręcznym dzieleniu partii należy to dostroić w oparciu o pamięć.

Poniższy kod jest przykładem zadania transformacji wsadowej:

s3_bucket_name= 'SageMaker-us-west-2-XXXXXXXX'
batch_input = f"s3://{s3_bucket_name}/folder/jobename_TorchServe_SageMaker/"
batch_output = f"s3://{s3_bucket_name}/folder/jobname_TorchServe_SageMaker_output/" batch_job_name = 'job-batch' + time.strftime("%Y-%m-%d-%H-%M-%S", time.gmtime())
batch_job_name request = { "ModelClientConfig": { "InvocationsTimeoutInSeconds": 3600, "InvocationsMaxRetries": 1, }, "TransformJobName": batch_job_name, "ModelName": model_name, "MaxConcurrentTransforms":1, "BatchStrategy": "MultiRecord", "TransformOutput": {"S3OutputPath": batch_output, "AssembleWith": "Line", "Accept": "application/json"}, "TransformInput": { "DataSource": { "S3DataSource": {"S3DataType": "S3Prefix", "S3Uri": batch_input} }, "SplitType" : "Line", "ContentType": "application/json", }, "TransformResources": {"InstanceType": "ml.p2.xlarge", "InstanceCount": 1},
}

Kiedy użyjemy powyższych ustawień i uruchomimy nasze zadanie transformacji, odczytuje ono pliki wejściowe ze źródłowego zasobnika S3 partiami i wysyła je do wnioskowania. Wyniki są zapisywane z powrotem do zasobnika S3 określonego na wyjściach.

Poniższy fragment kodu pokazuje, jak utworzyć i uruchomić zadanie przy użyciu powyższych ustawień:

sm.create_transform_job(**request) while True: response = sm.describe_transform_job(TransformJobName=batch_job_name) status = response["TransformJobStatus"] if status == "Completed": print("Transform job ended with status: " + status) break if status == "Failed": message = response["FailureReason"] print("Transform failed with the following error: {}".format(message)) raise Exception("Transform job failed") print("Transform job is still in status: " + status) time.sleep(30)

Wnioski

W tym poście przejrzeliśmy dwa tryby oferowane przez SageMaker do wnioskowania online i offline. Ten pierwszy wykorzystuje dynamiczne przetwarzanie wsadowe dostępne w TorchServe do grupowania żądań od wielu klientów. Ten ostatni wykorzystuje zadanie transformacji SageMaker do grupowania żądań z plików wejściowych w zasobniku S3 i uruchamiania wnioskowania.

Pokazaliśmy również, jak obsługiwać modele w SageMaker przy użyciu natywnych obrazów kontenerów zestawu narzędzi wnioskowania SageMaker PyTorch oraz jak używać niestandardowych kontenerów w przypadkach użycia, które wymagają zaawansowanych ustawień konfiguracyjnych TorchServe.

Ponieważ TorchServe wciąż ewoluuje, aby sprostać potrzebom społeczności PyTorch, nowe funkcje są integrowane z SageMaker, aby zapewnić wydajne sposoby obsługi modeli w produkcji. Aby uzyskać więcej informacji, sprawdź Repozytorium TorchServe GitHub oraz Przykłady SageMakera.

O autorach

Phi Nguyena jest architektem rozwiązań w AWS, pomagającym klientom w ich podróży do chmury, ze szczególnym uwzględnieniem jeziora danych, analityki, technologii semantyki i uczenia maszynowego. W wolnym czasie można go spotkać na rowerze do pracy, trenera drużyny piłkarskiej syna lub spacerów na łonie natury z rodziną.

Nihil Kulkarni jest programistą w AWS Machine Learning, koncentrując się na zwiększaniu wydajności obciążeń uczenia maszynowego w chmurze i jest współtwórcą AWS Deep Learning Containers do szkolenia i wnioskowania. Pasjonuje się rozproszonymi systemami głębokiego uczenia. Poza pracą lubi czytać książki, grać na gitarze i robić pizzę.

Hamida Shojanazeriego jest inżynierem-partnerem w firmie Pytorch, pracującym nad optymalizacją i obsługą wysokowydajnych modeli OSS. Hamid ma doktorat z widzenia komputerowego i pracował jako badacz w laboratoriach multimedialnych w Australii, Malezji i kierowniku NLP w Opus.ai. Lubi znajdować prostsze rozwiązania trudnych problemów, aw wolnym czasie pasjonuje się sztuką.

Geeta Chauhan kieruje AI Partner Engineering w Meta AI z doświadczeniem w budowaniu odpornych, odpornych na kruchość, rozproszonych platform na dużą skalę dla startupów i firm z listy Fortune 500. Jej zespół współpracuje z partnerami strategicznymi, liderami uczenia maszynowego w całej branży i wszystkimi głównymi dostawcami usług w chmurze w celu tworzenia i uruchamiania nowych usług i doświadczeń związanych z AI; i przenoszenie modeli PyTorch od badań do produkcji. Jest zwyciężczynią Women in IT – Silicon Valley – CTO roku 2019, wybitnym mówcą ACM i liderem myśli w tematach od etyki w AI, głębokiego uczenia się, Blockchain, IoT. Pasjonuje się promowaniem wykorzystania AI for Good.