Osiągnij hiperskalową wydajność udostępniania modeli przy użyciu serwera NVIDIA Triton Inference Server na platformie Amazon SageMaker

Aplikacje uczenia maszynowego (ML) są skomplikowane we wdrażaniu i często wymagają wielu modeli ML do obsługi pojedynczego żądania wnioskowania. Typowe żądanie może przepływać przez wiele modeli z etapami, takimi jak przetwarzanie wstępne, transformacje danych, logika wyboru modelu, agregacja modeli i przetwarzanie końcowe. Doprowadziło to do ewolucji typowych wzorców projektowych, takich jak szeregowe potoki wnioskowania, zespoły (zbieranie rozproszone) i przepływy pracy logiki biznesowej, co skutkuje realizacją całego przepływu pracy żądania jako ukierunkowanego wykresu acyklicznego (DAG). Jednak ponieważ przepływy pracy stają się coraz bardziej złożone, prowadzi to do wydłużenia ogólnego czasu odpowiedzi lub opóźnień tych aplikacji, co z kolei wpływa na ogólne wrażenia użytkownika. Ponadto, jeśli te składniki są hostowane w różnych wystąpieniach, dodatkowe opóźnienie sieci między tymi wystąpieniami zwiększa ogólne opóźnienie. Rozważ przykład popularnego przypadku użycia ML dla wirtualnego asystenta w obsłudze klienta. Typowe żądanie może wymagać przejścia przez kilka etapów obejmujących rozpoznawanie mowy, przetwarzanie języka naturalnego (NLP), śledzenie stanu dialogu, politykę dialogową, generowanie tekstu i wreszcie zamianę tekstu na mowę. Ponadto, aby interakcja z użytkownikiem była bardziej spersonalizowana, możesz również użyć najnowocześniejszych modeli NLP opartych na transformatorach, takich jak różne wersje BERTI, BART, GPT. Efektem końcowym są długie czasy odpowiedzi dla tych zestawów modeli i słabe wrażenia klientów.

Typowym wzorcem skracania czasów odpowiedzi bez obniżania ogólnej przepustowości jest hostowanie tych modeli w tej samej instancji wraz z wbudowaną w nią lekką logiką biznesową. Modele te można dodatkowo hermetyzować w jednym lub wielu kontenerach w tym samym wystąpieniu, aby zapewnić izolację uruchomionych procesów i utrzymać niskie opóźnienia. Ponadto ogólne opóźnienie zależy również od wnioskowania logiki aplikacji, optymalizacji modelu, podstawowej infrastruktury (w tym zasobów obliczeniowych, pamięci masowej i sieci) oraz bazowego serwera sieci Web przyjmującego żądania wnioskowania. Serwer wnioskowania NVIDIA Triton to oprogramowanie typu open source obsługujące wnioskowanie z funkcjami maksymalizującymi przepustowość i wykorzystanie sprzętu przy bardzo niskich (jednocyfrowych milisekundach) opóźnieniach wnioskowania. Oferuje szeroką obsługę platform ML (w tym TensorFlow, PyTorch, ONNX, XGBoost i NVIDIA TensorRT) oraz zaplecza infrastruktury, w tym procesorów graficznych, procesorów i Inferencja AWS. Dodatkowo Triton Inference Server jest zintegrowany z Amazon Sage Maker, w pełni zarządzana, kompleksowa usługa ML, zapewniająca opcje wnioskowania w czasie rzeczywistym, w tym pojedynczy i wielomodelowy hosting. Te opcje wnioskowania obejmują hostowanie wielu modeli w tym samym kontenerze za pojedynczy punkt końcowyi hosting wiele modeli z wieloma pojemnikami za jednym punktem końcowym.

W listopadzie 2021 ogłosiliśmy integracja Triton Inference Server z SageMaker. AWS ściśle współpracowało z firmą NVIDIA, aby umożliwić Ci uzyskanie tego, co najlepsze z obu światów, i ułatwienie wdrażania modeli za pomocą Triton na AWS.

W tym poście przyjrzymy się najlepszym praktykom wdrażania modeli transformatorów na dużą skalę na procesorach graficznych przy użyciu serwera Triton Inference Server w programie SageMaker. Najpierw zaczniemy od podsumowania kluczowych pojęć dotyczących opóźnień w programie SageMaker oraz przeglądu wytycznych dotyczących dostrajania wydajności. Następnie przedstawiamy przegląd Triton i jego funkcji, a także przykładowy kod do wdrożenia w SageMaker. Na koniec wykonujemy testy obciążeniowe za pomocą Polecający wnioskowanie SageMaker i podsumować spostrzeżenia i wnioski z testów obciążenia popularnego modelu transformatora dostarczonego przez Hugging Face.

Możesz przejrzeć notatnik używaliśmy do samodzielnego wdrażania modeli i wykonywania testów obciążeniowych za pomocą kodu on GitHub.

Dostrajanie wydajności i optymalizacja pod kątem udostępniania modeli w SageMaker

Dostrajanie i optymalizacja wydajności to proces empiryczny, często obejmujący wiele iteracji. Liczba parametrów do strojenia jest kombinatoryczna, a zestawy wartości parametrów konfiguracyjnych nie są od siebie niezależne. Różne czynniki wpływają na optymalne dostrajanie parametrów, w tym rozmiar ładunku, typ i liczba modeli ML na wykresie przepływu żądań wnioskowania, typ magazynu, typ wystąpienia obliczeniowego, infrastruktura sieciowa, kod aplikacji, środowisko uruchomieniowe i konfiguracja oprogramowania do wnioskowania i inne.

Jeśli używasz programu SageMaker do wdrażania modeli ML, musisz wybrać instancję obliczeniową o najlepszym stosunku ceny do wydajności, co jest skomplikowanym i powtarzalnym procesem, który może zająć tygodnie eksperymentowania. Najpierw musisz wybrać odpowiedni typ wystąpienia ML spośród ponad 70 opcji w oparciu o wymagania dotyczące zasobów modeli i rozmiar danych wejściowych. Następnie musisz zoptymalizować model dla wybranego typu instancji. Na koniec musisz zapewnić infrastrukturę i zarządzać nią, aby przeprowadzać testy obciążenia i dostrajać konfigurację chmury pod kątem optymalnej wydajności i kosztów. Wszystko to może opóźnić wdrożenie modelu i czas wprowadzenia go na rynek. Ponadto należy ocenić kompromisy między opóźnieniem, przepustowością i kosztem, aby wybrać optymalną konfigurację wdrożenia. Polecający wnioskowanie SageMaker automatycznie wybiera odpowiedni typ wystąpienia obliczeniowego, liczbę wystąpień, parametry kontenera i optymalizacje modelu w celu wnioskowania w celu maksymalizacji przepustowości, zmniejszenia opóźnień i zminimalizowania kosztów.

Wnioskowanie w czasie rzeczywistym i opóźnienia w programie SageMaker

SageMaker wnioskowanie w czasie rzeczywistym jest idealny do wnioskowania w przypadku obciążeń roboczych, w których występują wymagania w czasie rzeczywistym, interaktywne i z małymi opóźnieniami. Istnieją cztery najczęściej używane metryki do monitorowania opóźnienia żądania wnioskowania dla punktów końcowych wnioskowania SageMaker

• Opóźnienie kontenera – Czas potrzebny na wysłanie żądania, pobranie odpowiedzi z kontenera modelu i zakończenie wnioskowania w kontenerze. Ta metryka jest dostępna w Amazon CloudWatch jako część Metryki wywołania opublikowane przez SageMaker.
• Opóźnienie modelu – Całkowity czas, jaki zajmują wszystkie kontenery SageMaker w ciągu potok wnioskowania. Ta metryka jest dostępna w Amazon CloudWatch jako część Metryki wywołania opublikowane przez SageMaker.
• Opóźnienie narzutu – Mierzony od momentu odebrania żądania przez SageMaker do momentu zwrócenia odpowiedzi do klienta, pomniejszony o opóźnienie modelu. Ta metryka jest dostępna w Amazon CloudWatch jako część Metryki wywołania opublikowane przez SageMaker.
• Opóźnienie od końca do końca – Mierzony od momentu wysłania przez klienta żądania wnioskowania do momentu otrzymania odpowiedzi zwrotnej. Klienci mogą opublikować to jako niestandardowe dane w Amazon CloudWatch.

Poniższy diagram ilustruje te komponenty.

Opóźnienie kontenera zależy od kilku czynników; do najważniejszych należą:

• Podstawowy protokół (HTTP/gRPC) używany do komunikacji z serwerem wnioskowania
• Narzut związany z tworzeniem nowych połączeń TLS
• Czas deserializacji ładunku żądania/odpowiedzi
• Żądaj funkcji kolejkowania i grupowania dostarczanych przez bazowy serwer wnioskowania
• Możliwości planowania żądań zapewniane przez podstawowy serwer wnioskowania
• Podstawowa wydajność środowiska uruchomieniowego serwera wnioskowania
• Wydajność bibliotek preprocessingu i postprocessingu przed wywołaniem funkcji przewidywania modelu
• Podstawowa wydajność backendu frameworka ML
• Optymalizacje specyficzne dla modelu i sprzętu

W tym poście skupiamy się przede wszystkim na optymalizacji opóźnień kontenerów wraz z ogólną przepustowością i kosztami. W szczególności badamy dostrajanie wydajności Triton Inference Server działający w kontenerze SageMaker.

Omówienie przypadków użycia

Wdrażanie i skalowanie modeli NLP w konfiguracji produkcyjnej może być dość trudne. Modele NLP są często bardzo duże i zawierają miliony parametrów modelu. Wymagane są optymalne konfiguracje modeli, aby spełnić rygorystyczne wymagania dotyczące wydajności i skalowalności aplikacji NLP klasy produkcyjnej.

W tym poście porównujemy przypadek użycia NLP przy użyciu punktu końcowego czasu rzeczywistego SageMaker w oparciu o kontener Triton Inference Server i zalecamy optymalizacje dostrajania wydajności dla naszego przypadku użycia ML. Używamy dużej, przeszkolonej, opartej na transformatorach Hugging Face BERT duży bez obudowy model, który ma około 336 milionów parametrów modelu. Zdanie wejściowe używane w modelu klasyfikacji binarnej jest dopełniane i skracane do maksymalnej długości sekwencji wejściowej wynoszącej 512 tokenów. Test obciążenia wnioskowania symuluje 500 wywołań na sekundę (maksymalnie 30,000 XNUMX wywołań na minutę) i ModelLatency mniej niż 0.5 sekundy (500 milisekund).

Poniższa tabela podsumowuje naszą konfigurację testu porównawczego.

Serwer wnioskowania NVIDIA Triton

Triton Inference Server został specjalnie zaprojektowany, aby umożliwić skalowalne, szybkie i łatwe wdrażanie modeli w produkcji. Triton obsługuje wiele głównych struktur sztucznej inteligencji, w tym TensorFlow, TensorRT, PyTorch, XGBoost i ONNX. Dzięki niestandardowemu zapleczu Python i C++ możesz również zaimplementować obciążenie wnioskowania w celu uzyskania bardziej niestandardowych przypadków użycia.

Co najważniejsze, Triton zapewnia prostą konfigurację opartą na konfiguracji do hostowania modeli, która udostępnia bogaty zestaw funkcji optymalizacji wydajności, których można użyć przy niewielkim wysiłku kodowania.

Triton zwiększa wydajność wnioskowania, maksymalizując wykorzystanie sprzętu za pomocą różnych technik optymalizacji (najczęściej stosowane są współbieżne przebiegi modeli i dynamiczne grupowanie). Znalezienie optymalnych konfiguracji modeli z różnych kombinacji dynamicznych rozmiarów partii i liczby jednoczesnych wystąpień modelu jest kluczem do uzyskania wnioskowania w czasie rzeczywistym w ramach taniego udostępniania za pomocą Triton.

Dynamiczne dozowanie

Wielu praktyków ma tendencję do sekwencyjnego uruchamiania wnioskowania, gdy serwer jest wywoływany z wieloma niezależnymi żądaniami. Chociaż jest to łatwiejsze w konfiguracji, wykorzystanie mocy obliczeniowej procesora graficznego zwykle nie jest najlepszą praktyką. Aby rozwiązać ten problem, Triton oferuje wbudowaną optymalizację dynamiczne grupowanie połączyć te niezależne żądania wnioskowania po stronie serwera w celu dynamicznego utworzenia większej partii w celu zwiększenia przepustowości. Poniższy diagram ilustruje architekturę środowiska uruchomieniowego Triton.

W poprzedniej architekturze wszystkie żądania docierają do dynamicznego programu wsadowego przed wejściem do rzeczywistych kolejek programu planującego model w celu oczekiwania na wnioskowanie. Możesz ustawić preferowane rozmiary partii dla grupowania dynamicznego za pomocą preferowany_rozmiar_partii ustawienia w konfiguracji modelu. (Zauważ, że uformowana wielkość partii musi być mniejsza niż maksymalna_wielkość_wsadu model obsługuje.) Możesz także skonfigurować max_queue_delay_mikrosekundy aby określić maksymalny czas opóźnienia w programie wsadowym, aby poczekać na inne żądania dołączenia do wiązki na podstawie wymagań dotyczących opóźnień.

Poniższy fragment kodu pokazuje, jak dodać tę funkcję z plikami konfiguracji modelu, aby ustawić dynamiczne przetwarzanie wsadowe z preferowanym rozmiarem partii 16 dla rzeczywistego wnioskowania. Przy bieżących ustawieniach instancja modelu jest wywoływana natychmiast, gdy zostanie spełniony preferowany rozmiar partii 16 lub upłynął czas opóźnienia 100 mikrosekund od momentu, gdy pierwsze żądanie dotarło do dynamicznego wsadu.

dynamic_batching { preferred_batch_size: 16 max_queue_delay_microseconds: 100 }

Uruchomione modele jednocześnie

Inną istotną optymalizacją oferowaną w Triton w celu maksymalizacji wykorzystania sprzętu bez dodatkowego narzutu związanego z opóźnieniami jest jednoczesne wykonanie modelu, który umożliwia równoległe działanie wielu modeli lub wielu kopii tego samego modelu. Ta funkcja umożliwia firmie Triton obsługę wielu żądań wnioskowania jednocześnie, co zwiększa przepustowość wnioskowania dzięki wykorzystaniu bezczynnej mocy obliczeniowej sprzętu.

Poniższy rysunek pokazuje, jak łatwo skonfigurować różne zasady wdrażania modelu, zmieniając tylko kilka wierszy kodu. Na przykład konfiguracja A (po lewej) pokazuje, że można rozgłaszać tę samą konfigurację dwóch instancji modelu bert-large-uncased do wszystkich dostępnych procesorów graficznych. Natomiast konfiguracja B (środkowa) pokazuje inną konfigurację tylko dla GPU 0, bez zmiany zasad na innych GPU. Możesz także wdrożyć instancje różnych modeli na jednym GPU, jak pokazano w konfiguracji C (po prawej).

W konfiguracji C instancja obliczeniowa może obsłużyć dwa współbieżne żądania dla modelu DistilGPT-2 i siedem jednoczesnych żądań dla modelu bert-large-uncased model równolegle. Dzięki tym optymalizacjom zasoby sprzętowe mogą być lepiej wykorzystywane do procesu udostępniania, zwiększając w ten sposób przepustowość i zapewniając lepszą efektywność kosztową obciążenia.

TensorRT

NVIDIA TensorRT to zestaw SDK do wysokowydajnego wnioskowania o głębokim uczeniu, który bezproblemowo współpracuje z Tritonem. TensorRT, który obsługuje każdą główną platformę uczenia głębokiego, zawiera optymalizator wnioskowania i środowisko wykonawcze, które zapewnia niskie opóźnienia i wysoką przepustowość do uruchamiania wnioskowania z ogromnymi ilościami danych dzięki potężnym optymalizacjom.

TensorRT optymalizuje wykres, aby zminimalizować zużycie pamięci, zwalniając niepotrzebną pamięć i efektywnie ją ponownie wykorzystując. Dodatkowo kompilacja TensorRT łączy rzadkie operacje wewnątrz wykresu modelu, tworząc większe jądro, aby uniknąć obciążenia związanego z wielokrotnymi uruchomieniami małego jądra. Automatyczne dostrajanie jądra pomaga w pełni wykorzystać sprzęt, wybierając najlepszy algorytm na docelowym GPU. Strumienie CUDA umożliwiają równoległe działanie modeli, aby zmaksymalizować wykorzystanie GPU w celu uzyskania najlepszej wydajności. Wreszcie, technika kwantyzacji może w pełni wykorzystać akcelerację rdzeni Tensor o mieszanej precyzji, aby uruchomić model w FP32, TF32, FP16 i INT8, aby osiągnąć najlepszą wydajność wnioskowania.

Triton na hostingu SageMaker

Hosting SageMaker usługi to zestaw funkcji programu SageMaker, których celem jest ułatwienie wdrażania i obsługi modeli. Zapewnia różnorodne opcje łatwego wdrażania, automatycznego skalowania, monitorowania i optymalizacji modeli ML dostosowanych do różnych przypadków użycia. Oznacza to, że można zoptymalizować wdrożenia pod kątem wszystkich typów wzorców użycia, od trwałych i zawsze dostępnych z opcjami bezserwerowymi po przejściowe, długotrwałe lub wsadowe potrzeby wnioskowania.

W ramach hostingu SageMaker znajduje się również zestaw wnioskowań SageMaker Deep Learning Containers (DLC), które są dostarczane z odpowiednim oprogramowaniem serwera modelowego dla odpowiedniej obsługiwanej struktury ML. Umożliwia to uzyskanie wysokiej wydajności wnioskowania bez konfiguracji serwera modelu, co często jest najbardziej złożonym aspektem technicznym wdrażania modelu i ogólnie nie jest częścią zestawu umiejętności analityka danych. Serwer wnioskowania Triton jest teraz dostępny na temat kontenerów głębokiego uczenia SageMaker (DLC).

Ten szeroki zakres opcji, modułowość i łatwość użycia różnych frameworków obsługujących sprawia, że ​​SageMaker i Triton to potężne połączenie.

SageMaker Inference Recommender dla wyników testów porównawczych

Do przeprowadzania eksperymentów używamy narzędzia SageMaker Inference Recommender. SageMaker Inference Recommender oferuje dwa typy zadań: domyślne i zaawansowane, jak pokazano na poniższym diagramie.

Domyślne zadanie zawiera rekomendacje dotyczące typów instancji z samym modelem i próbką ładunku do porównania. Oprócz rekomendacji instancji usługa oferuje również parametry runtime poprawiające wydajność. Domyślne rekomendacje zadań mają na celu zawężenie wyszukiwania instancji. W niektórych przypadkach może to być rodzina wystąpień, a w innych mogą to być określone typy wystąpień. Wyniki zadania domyślnego są następnie wprowadzane do zadania zaawansowanego.

Zaawansowane zadanie oferuje więcej elementów sterujących w celu dalszego dostrojenia wydajności. Te elementy sterujące symulują rzeczywiste środowisko i wymagania produkcyjne. Wśród tych kontroli znajduje się wzorzec ruchu, który ma na celu ustawienie wzorca żądania dla testów porównawczych. Możesz ustawić rampy lub stały ruch, używając wielu faz wzorca ruchu. Na przykład an Początkowa Liczba Użytkowników 1, Współczynnik odradzania z 1 i Czas trwania w sekundach 600 może skutkować ruchem rampowym wynoszącym 10 minut z 1 równoczesnym użytkownikiem na początku i 10 na końcu. Dodatkowo na sterach MaxInwokacje i Progi opóźnienia modelu ustawić próg produkcji, więc po przekroczeniu jednego z progów benchmarking się zatrzymuje.

Wreszcie, wskaźniki rekomendacji obejmują przepływność, opóźnienie przy maksymalnej przepływności i koszt na wnioskowanie, dzięki czemu można je łatwo porównać.

Używamy zaawansowanego typu zadania SageMaker Inference Recommender, aby przeprowadzać nasze eksperymenty w celu uzyskania dodatkowej kontroli nad wzorcami ruchu i dostrojenia konfiguracji kontenera udostępniania.

Konfiguracja eksperymentu

Używamy niestandardowej funkcji testu obciążenia programu SageMaker Inference Recommender do testowania profilu NLP opisanego w naszym przypadku użycia. Najpierw definiujemy następujące wymagania wstępne związane z modelem NLP i zadaniem ML. SageMaker Inference Recommender wykorzystuje te informacje, aby pobrać wnioskowanie z obrazu Dockera Rejestr elastycznego pojemnika Amazon (Amazon ECR) i zarejestruj model w rejestrze modeli SageMaker.

Konfiguracje wzorców ruchu w programie SageMaker Inference Recommender pozwalają nam zdefiniować różne fazy dla niestandardowego testu obciążenia. Test obciążenia rozpoczyna się od dwóch początkowych użytkowników i co minutę odradza dwóch nowych użytkowników przez łączny czas trwania 25 minut (1500 sekund), jak pokazano w poniższym kodzie:

"TrafficPattern": { "TrafficType": "PHASES", "Phases": [ { "InitialNumberOfUsers": 2, "SpawnRate": 2, "DurationInSeconds": 1500 }, ],
}

Eksperymentujemy z testowaniem obciążenia tego samego modelu w dwóch różnych stanach. Eksperymenty oparte na PyTorch wykorzystują standardowy, niezmieniony model PyTorch. W przypadku eksperymentów opartych na TensorRT, wcześniej konwertujemy model PyTorch na silnik TensorRT.

W tych dwóch modelach stosujemy różne kombinacje funkcji optymalizacji wydajności, podsumowane w poniższej tabeli.

Wyniki badań i obserwacje

Przeprowadziliśmy testy obciążeniowe dla trzech typów instancji z tej samej rodziny g4dn: ml.g4dn.xlarge, ml.g4dn.2xlarge i ml.g4dn.12xlarge. Wszystkie typy wystąpień g4dn mają dostęp do procesorów graficznych NVIDIA T4 Tensor Core i procesorów Intel Cascade Lake drugiej generacji. Logika wyboru typów instancji polegała na tym, aby mieć zarówno instancję z dostępnym tylko jednym GPU, jak i instancję z dostępem do wielu GPU — czterech w przypadku ml.g2dn.4xlarge. Ponadto chcieliśmy przetestować, czy zwiększenie pojemności vCPU w instancji przy użyciu tylko jednego dostępnego GPU przyniosłoby poprawę stosunku kosztów do wydajności.

Przyjrzyjmy się najpierw przyspieszeniu indywidualnej optymalizacji. Poniższy wykres pokazuje, że optymalizacja TensorRT zapewnia 50% zmniejszenie opóźnienia modelu w porównaniu z natywnym w PyTorch w wystąpieniu ml.g4dn.xlarge. Ta redukcja opóźnień wzrasta do ponad trzech razy w wystąpieniach z wieloma procesorami graficznymi ml.g4dn.12xlarge. Tymczasem poprawa przepustowości o 30% jest spójna w obu przypadkach, co skutkuje lepszą opłacalnością po zastosowaniu optymalizacji TensorRT.

Dzięki dynamicznemu grupowaniu możemy uzyskać prawie dwukrotną poprawę przepustowości przy użyciu tej samej architektury sprzętowej we wszystkich wystąpieniach eksperymentów ml.g2dn.xlarge, ml.g4dn.4xlarge i ml.g2dn.4xlarge bez zauważalnego wzrostu opóźnień.

Podobnie współbieżne wykonywanie modelu umożliwia nam uzyskanie około 3-4-krotnej poprawy przepustowości przez maksymalizację wykorzystania procesora GPU w wystąpieniu ml.g4dn.xlarge i około dwukrotną poprawę zarówno w przypadku ml.g2dn.4xlarge, jak i wystąpienia ml.g2dn.4xlarge z wieloma procesorami graficznymi. g12dn.XNUMXxlarge.. Ten wzrost przepustowości przychodzi bez żadnych kosztów związanych z opóźnieniem.

Co więcej, możemy zintegrować wszystkie te optymalizacje, aby zapewnić najlepszą wydajność, wykorzystując w pełni zasoby sprzętowe. Poniższa tabela i wykresy podsumowują wyniki, które uzyskaliśmy w naszych eksperymentach.

[1] Początkowa liczba wystąpień w powyższej tabeli to zalecana liczba wystąpień do użycia z zasadami autoskalowania w celu zachowania wymagań dotyczących przepustowości i opóźnień dla obciążenia.

[2] Koszt godziny w powyższej tabeli jest obliczany na podstawie liczby wystąpień początkowych i ceny dla typu wystąpienia.

Wyniki w większości potwierdzają oczekiwany wpływ różnych funkcji optymalizacji wydajności:

• Kompilacja TensorRT ma najbardziej niezawodny wpływ na wszystkie typy instancji. Transakcje na minutę na instancję wzrosły o 30–35%, przy stałej redukcji kosztów o około 25% w porównaniu z wydajnością silnika TensorRT do domyślnego BERT PyTorch (pt-base). Zwiększona wydajność silnika TensorRT jest połączona i wykorzystywana przez inne przetestowane funkcje dostrajania wydajności.
• Załadowanie dwóch modeli na każdy procesor graficzny (grupa instancji) prawie podwoiło wszystkie zmierzone metryki. Liczba wywołań na minutę na instancję wzrosła o około 80–90%, co dało redukcję kosztów w zakresie 50%, prawie tak, jakbyśmy używali dwóch procesorów graficznych. W rzeczywistości, Amazon Cloud Watch metryki dla naszych eksperymentów na g4dn.2xlarge (jako przykład) potwierdzają, że użycie procesora CPU i GPU podwaja się, gdy konfigurujemy grupę instancji składającą się z dwóch modeli.

Dalsze wskazówki dotyczące wydajności i optymalizacji kosztów

Test porównawczy przedstawiony w tym poście tylko zarysował powierzchnię możliwych funkcji i technik, których można użyć z Tritonem, aby poprawić wydajność wnioskowania. Obejmują one techniki wstępnego przetwarzania danych, takie jak wysyłanie ładunków binarnych do serwera modelowego lub ładunków z większymi partiami, po natywne funkcje Triton, takie jak:

• Rozgrzewka modelu, co zapobiega początkowym powolnym żądaniom wnioskowania przez całkowite zainicjowanie modelu przed odebraniem pierwszego żądania wnioskowania.
• Pamięć podręczna odpowiedzi, który buforuje powtarzające się żądania.
• Składanie modeli, co umożliwia utworzenie potoku jednego lub większej liczby modeli oraz połączenie tensorów wejściowych i wyjściowych między tymi modelami. Otwiera to możliwość dodawania kroków przetwarzania wstępnego i końcowego, a nawet wnioskowania z innymi modelami, do przepływu przetwarzania dla każdego żądania.

Spodziewamy się przetestować i porównać te techniki i funkcje w przyszłym poście, więc bądźcie czujni!

Wnioski

W tym poście zbadaliśmy kilka parametrów, których można użyć, aby zmaksymalizować wydajność punktu końcowego czasu rzeczywistego SageMaker do obsługi modeli PyTorch BERT za pomocą serwera Triton Inference Server. Wykorzystaliśmy SageMaker Inference Recommender do przeprowadzenia testów porównawczych w celu dostrojenia tych parametrów. Parametry te są w istocie związane z optymalizacją modelu opartą na TensorRT, co prowadzi do prawie 50% poprawy czasu odpowiedzi w porównaniu z wersją niezoptymalizowaną. Dodatkowo, jednoczesne uruchamianie modeli i dynamiczne dozowanie Tritona doprowadziło do prawie 70% wzrostu przepustowości. Dostrojenie tych parametrów doprowadziło również do ogólnego zmniejszenia kosztów wnioskowania.

Najlepszym sposobem uzyskania prawidłowych wartości jest eksperymentowanie. Aby jednak rozpocząć budowanie wiedzy empirycznej na temat dostrajania i optymalizacji wydajności, można zaobserwować kombinacje różnych parametrów związanych z Tritonem i ich wpływ na wydajność w modelach ML i instancjach SageMaker ML.

SageMaker zapewnia narzędzia do usuwania niezróżnicowanego podnoszenia ciężarów na każdym etapie cyklu życia ML, ułatwiając w ten sposób szybkie eksperymentowanie i eksplorację potrzebne do pełnej optymalizacji wdrożeń modeli.

Notebook używany do testowania obciążenia i wdrażania można znaleźć na GitHub. Możesz zaktualizować konfiguracje Triton i ustawienia rekomendacji wnioskowania SageMaker, aby jak najlepiej dopasować je do przypadku użycia, aby uzyskać opłacalne i najlepiej działające obciążenia wnioskowania.

O autorach

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

Joao Moura jest specjalistą ds. rozwiązań AI/ML w Amazon Web Services. Koncentruje się głównie na przypadkach użycia NLP i pomaga klientom zoptymalizować szkolenie i wdrażanie modelu Deep Learning. Jest również aktywnym zwolennikiem rozwiązań ML typu low-code oraz sprzętu wyspecjalizowanego w ML.

Mohana Gandhiego jest starszym inżynierem oprogramowania w AWS. Jest związany z AWS od 9 lat i pracował nad różnymi usługami AWS, takimi jak EMR, EFA i RDS w Outposts. Obecnie koncentruje się na doskonaleniu doświadczenia wnioskowania SageMaker. W wolnym czasie lubi wędrować i biegać w maratonach.

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.

Santosha Bhavaniego jest starszym kierownikiem technicznym produktu w zespole Amazon SageMaker Elastic Inference. Koncentruje się na pomaganiu klientom SageMaker w przyspieszaniu wnioskowania o modelach i ich wdrażania. W wolnym czasie lubi podróżować, grać w tenisa i pić dużo herbaty Pu'er.

Jiahong Liu jest architektem rozwiązań w zespole Cloud Service Provider firmy NVIDIA. Pomaga klientom we wdrażaniu rozwiązań uczenia maszynowego i sztucznej inteligencji, które wykorzystują akcelerowane obliczenia NVIDIA, aby sprostać wyzwaniom związanym ze szkoleniem i wnioskowaniem. W wolnym czasie lubi origami, projekty DIY i grę w koszykówkę.

• Coinsmart. Najlepsza w Europie giełda bitcoinów i kryptowalut.
• Platoblockchain. Web3 Inteligencja Metaverse. Wzmocniona wiedza. DARMOWY DOSTĘP.
• CryptoJastrząb. Radar Altcoin. Bezpłatna wersja próbna.
• Źródło: https://aws.amazon.com/blogs/machine-learning/achieve-hyperscale-performance-for-model-serving-using-nvidia-triton-inference-server-on-amazon-sagemaker/