Przedstawiamy zestaw narzędzi do analizy porównawczej wnioskowania bezserwerowego Amazon SageMaker

Wnioskowanie bezserwerowe Amazon SageMaker to specjalnie opracowana opcja wnioskowania, która ułatwia wdrażanie i skalowanie modeli uczenia maszynowego (ML). Zapewnia model płatności za użycie, który jest idealny dla usług, w których wywołania punktów końcowych są rzadkie i nieprzewidywalne. W przeciwieństwie do punktu końcowego hostingu w czasie rzeczywistym, który jest wspierany przez długotrwałe wystąpienie, zasoby obliczeniowe dla bezserwerowych punktów końcowych są udostępniane na żądanie, eliminując w ten sposób potrzebę wybierania typów wystąpień lub zarządzania zasadami skalowania.

Poniższa architektura wysokiego poziomu ilustruje sposób działania bezserwerowego punktu końcowego. Klient wywołuje punkt końcowy, który jest obsługiwany przez infrastrukturę zarządzaną AWS.

Jednak bezserwerowe punkty końcowe są podatne na zimny start w ciągu kilku sekund i dlatego są bardziej odpowiednie dla sporadycznych lub nieprzewidywalnych obciążeń.

Aby pomóc w ustaleniu, czy bezserwerowy punkt końcowy jest właściwą opcją wdrożenia z punktu widzenia kosztów i wydajności, opracowaliśmy: SageMaker Bezserwerowy zestaw narzędzi do analizy porównawczej wnioskowania, który testuje różne konfiguracje punktów końcowych i porównuje najbardziej optymalną z porównywalnym wystąpieniem hostingu w czasie rzeczywistym.

W tym poście przedstawiamy zestaw narzędzi i przedstawiamy przegląd jego konfiguracji i wyników.

Omówienie rozwiązania

Możesz pobrać zestaw narzędzi i zainstalować go z GitHub repo. Rozpoczęcie pracy jest łatwe: po prostu zainstaluj bibliotekę, utwórz Model SageMakerai podaj nazwę modelu wraz z plikiem w formacie JSON zawierającym przykładowy zestaw parametrów wywołania, w tym treść ładunku i typ zawartości. Dostępna jest funkcja ułatwiająca konwersję listy przykładowych argumentów wywołania na plik wierszy JSON lub plik marynowany dla ładunków binarnych, takich jak obrazy, wideo lub audio.

Zainstaluj zestaw narzędzi

Najpierw zainstaluj bibliotekę benchmarkingową w swoim środowisku Pythona za pomocą pip:

pip install sm-serverless-benchmarking

Możesz uruchomić następujący kod z Studio Amazon SageMaker instancja, Instancja notebooka SageMaker, lub dowolna instancja z dostęp programowy do AWS i odpowiednich AWS Zarządzanie tożsamością i dostępem (IAM) uprawnienia. Wymagane uprawnienia IAM są udokumentowane w GitHub repo. Aby uzyskać dodatkowe wskazówki i przykładowe zasady dotyczące uprawnień, zobacz Jak Amazon SageMaker współpracuje z IAM. Ten kod uruchamia test porównawczy z domyślnym zestawem parametrów w modelu, który oczekuje danych wejściowych w formacie CSV z dwoma przykładowymi rekordami. Dobrą praktyką jest dostarczenie reprezentatywnego zestawu przykładów do analizy, jak punkt końcowy działa z różnymi ładunkami wejściowymi.

from sm_serverless_benchmarking import benchmark
from sm_serverless_benchmarking.utils import convert_invoke_args_to_jsonl
model_name = ""
example_invoke_args = [
        {'Body': '1,2,3,4,5', "ContentType": "text/csv"},
        {'Body': '6,7,8,9,10', "ContentType": "text/csv"}
        ]
example_args_file = convert_invoke_args_to_jsonl(example_invoke_args,
output_path=".")
r = benchmark.run_serverless_benchmarks(model_name, example_args_file)

Ponadto test porównawczy można uruchomić jako zadanie przetwarzania SageMaker, co może być bardziej niezawodną opcją w przypadku dłuższych testów porównawczych z dużą liczbą wywołań. Zobacz następujący kod:

from sm_serverless_benchmarking.sagemaker_runner import run_as_sagemaker_job
run_as_sagemaker_job(
                    role="",
                    model_name="",
                    invoke_args_examples_file="",
                    )

Należy pamiętać, że spowoduje to nałożenie dodatkowych kosztów uruchamiania instancji przetwarzania ml.m5.large SageMaker w czasie trwania testu porównawczego.

Obie metody akceptują szereg parametrów do skonfigurowania, takich jak lista konfiguracji pamięci do testu porównawczego oraz liczba wywołań każdej konfiguracji. W większości przypadków opcje domyślne powinny wystarczyć jako punkt wyjścia, ale należy zapoznać się z GitHub repo aby uzyskać pełną listę i opisy każdego parametru.

Konfiguracja benchmarkingu

Przed zagłębieniem się w to, co robi test porównawczy i jakie dane wyjściowe generuje, ważne jest, aby zrozumieć kilka kluczowych pojęć, jeśli chodzi o konfigurowanie bezserwerowych punktów końcowych.

Tam są dwie kluczowe opcje konfiguracji: MemorySizeInMB i MaxConcurrency. MemorySizeInMB konfiguruje ilość pamięci przydzielonej do wystąpienia i może wynosić 1024 MB, 2048 MB, 3072 MB, 4096 MB, 5120 MB lub 6144 MB. Liczba procesorów wirtualnych również skaluje się proporcjonalnie do ilości przydzielonej pamięci. The MaxConcurrency parametr dostosowuje liczbę jednoczesnych żądań, które punkt końcowy może obsłużyć. Z MaxConcurrency 1, bezserwerowy punkt końcowy może przetwarzać tylko jedno żądanie na raz.

Podsumowując, plik MemorySizeInMB zapewnia mechanizm skalowalności pionowej, co pozwala dostosować pamięć i zasoby obliczeniowe do obsługi większych modeli, podczas gdy MaxConcurrency zapewnia mechanizm skalowalności poziomej, umożliwiając punktowi końcowemu przetwarzanie większej liczby jednoczesnych żądań.

Koszt obsługi punktu końcowego w dużej mierze zależy od rozmiaru pamięci i nie ma żadnych kosztów związanych ze zwiększaniem maksymalnej współbieżności. Istnieje jednak limit kont na region dla maksymalnej współbieżności we wszystkich punktach końcowych. Odnosić się do Punkty końcowe i limity SageMaker dla najnowszych limitów.

Wyniki benchmarkingu

Biorąc to pod uwagę, celem testu porównawczego bezserwerowego punktu końcowego jest określenie najbardziej opłacalnego i niezawodnego ustawienia rozmiaru pamięci oraz minimalnej maksymalnej współbieżności, która może obsłużyć oczekiwane wzorce ruchu.

Domyślnie narzędzie uruchamia dwa testy porównawcze. Pierwszy to test porównawczy stabilności, który wdraża punkt końcowy dla każdej z określonych konfiguracji pamięci i wywołuje każdy punkt końcowy z dostarczonymi przykładowymi ładunkami. Celem tego testu porównawczego jest określenie najbardziej efektywnego i stabilnego ustawienia MemorySizeInMB. Test porównawczy przechwytuje opóźnienia wywołań i oblicza oczekiwany koszt wywołania dla każdego punktu końcowego. Następnie porównuje koszt z podobną instancją hostingu w czasie rzeczywistym.

Po zakończeniu benchmarkingu narzędzie generuje kilka wyników w określonych result_save_path katalog o następującej strukturze katalogów:

├── benchmarking_report
├── concurrency_benchmark_raw_results
├── concurrency_benchmark_summary_results
├── cost_analysis_summary_results
├── stability_benchmark_raw_results
├── stability_benchmark_summary_results

Połączenia benchmarking_report katalog zawiera skonsolidowany raport ze wszystkimi wynikami podsumowania, które przedstawiamy w tym poście. Dodatkowe katalogi zawierają surowe i pośrednie dane wyjściowe, które można wykorzystać do dodatkowych analiz. Zapoznaj się z GitHub repo aby uzyskać bardziej szczegółowy opis każdego artefaktu wyjściowego.

Przyjrzyjmy się kilku rzeczywistym wynikom testów porównawczych dla punktu końcowego obsługującego model wizji komputerowej MobileNetV2 TensorFlow. Jeśli chcesz odtworzyć ten przykład, zapoznaj się z przykładowe zeszyty katalog w repozytorium GitHub.

Pierwszym wynikiem raportu skonsolidowanego jest tabela podsumowująca, która zawiera dane o minimalnym, średnim, średnim i maksymalnym czasie oczekiwania dla każdego MemorySizeInMB pomyślna konfiguracja rozmiaru pamięci. Jak pokazano w poniższej tabeli, średnie opóźnienie wywołania (invocation_latency_mean) nadal ulegała poprawie, ponieważ konfiguracja pamięci została zwiększona do 3072 MB, ale od tego czasu przestała się poprawiać.

Oprócz statystyk opisowych wysokiego poziomu dostępny jest wykres przedstawiający rozkład opóźnień obserwowany przez klienta dla każdej konfiguracji pamięci. Ponownie możemy zauważyć, że konfiguracja 1024 MB nie jest tak wydajna jak inne opcje, ale nie ma znaczącej różnicy w wydajności w konfiguracjach 2048 i wyższych.

Amazon Cloud Watch Dostępne są również metryki skojarzone z każdą konfiguracją punktu końcowego. Jednym z kluczowych wskaźników jest tutaj ModelSetupTime, który mierzy czas ładowania modelu, gdy punkt końcowy został wywołany w stanie zimnym. Metryka może nie zawsze pojawiać się w raporcie, ponieważ punkt końcowy jest uruchamiany w stanie ciepłym. A cold_start_delay parametr jest dostępny do określenia liczby sekund do uśpienia przed uruchomieniem testu porównawczego we wdrożonym punkcie końcowym. Ustawienie tego parametru na wyższą liczbę, na przykład 600 sekund, powinno zwiększyć prawdopodobieństwo wywołania zimnego stanu i zwiększyć szanse na przechwycenie tej metryki. Ponadto jest znacznie bardziej prawdopodobne, że ta metryka zostanie przechwycona za pomocą testu porównawczego współbieżnego wywołania, który omówimy w dalszej części tej sekcji.

W poniższej tabeli przedstawiono metryki przechwycone przez CloudWatch dla każdej konfiguracji pamięci.

Następny wykres przedstawia kompromisy wydajności i kosztów różnych konfiguracji pamięci. Jeden wiersz pokazuje szacowany koszt wywołania punktu końcowego 1 milion razy, a drugi pokazuje średnie opóźnienie odpowiedzi. Te metryki mogą pomóc w podjęciu decyzji o tym, która konfiguracja punktu końcowego jest najbardziej opłacalna. W tym przykładzie widzimy, że średnie opóźnienie spłaszcza się po 2048 MB, podczas gdy koszt nadal rośnie, co wskazuje, że dla tego modelu najbardziej optymalna byłaby konfiguracja rozmiaru pamięci 2048.

Ostatecznym wynikiem testu porównawczego kosztów i stabilności jest zalecana konfiguracja pamięci wraz z tabelą porównującą koszt działania bezserwerowego punktu końcowego z porównywalnym wystąpieniem hostingu SageMaker. Na podstawie zebranych danych narzędzie ustaliło, że konfiguracja 2048 MB jest najbardziej optymalna dla tego modelu. Chociaż konfiguracja 3072 zapewnia około 10 milisekund lepsze opóźnienie, oznacza to wzrost kosztów o 30%, z 4.55 USD do 5.95 USD za 1 milion żądań. Ponadto dane wyjściowe pokazują, że bezserwerowy punkt końcowy zapewniłby oszczędności do 88.72% w porównaniu z porównywalnym wystąpieniem hostingu w czasie rzeczywistym, gdy istnieje mniej niż 1 milion żądań wywołań miesięcznie, i działa nawet z punktem końcowym w czasie rzeczywistym po 8.5 milionach żądań.

Drugi rodzaj benchmarku jest opcjonalny i testuje różne MaxConcurency ustawienia w różnych wzorcach ruchu. Ten test jest zwykle uruchamiany przy użyciu optymalnego MemorySizeInMB konfiguracja ze wzorca stabilności. Dwa kluczowe parametry tego testu porównawczego to lista MaxConcurency ustawienia do testowania wraz z listą mnożników klientów, które określają liczbę symulowanych jednoczesnych klientów, z którymi testowany jest punkt końcowy.

Na przykład, ustawiając concurrency_benchmark_max_conc parameter do [4, 8] i concurrency_num_clients_multiplier do [1, 1.5, 2], uruchamiane są dwa punkty końcowe: jeden z MaxConcurency z 4 i pozostałe 8. Każdy punkt końcowy jest następnie porównywany z (MaxConcurency x mnożnik) liczba symulowanych jednoczesnych klientów, co dla punktu końcowego ze współbieżnością 4 przekłada się na testy porównawcze obciążenia z 4, 6 i 8 jednoczesnymi klientami.

Pierwszym wynikiem tego testu porównawczego jest tabela przedstawiająca metryki opóźnień, wyjątki ograniczania przepustowości i metryki transakcji na sekundę (TPS) powiązane z każdym MaxConcurrency konfiguracja z różną liczbą jednoczesnych klientów. Te metryki pomagają określić odpowiednie MaxConcurrency ustawienie do obsługi oczekiwanego obciążenia ruchem. W poniższej tabeli widzimy, że punkt końcowy skonfigurowany z maksymalną współbieżnością 8 był w stanie obsłużyć do 16 jednoczesnych klientów z tylko dwoma wyjątkami ograniczania przepustowości na 2,500 wywołań wykonanych średnio 24 transakcje na sekundę.

Następny zestaw danych wyjściowych zawiera wykres dla każdego MaxConcurrency ustawienie pokazujące rozkład opóźnienia przy różnych obciążeniach. W tym przykładzie widzimy, że punkt końcowy z a MaxConcurrency ustawienie 4 umożliwiło pomyślne przetworzenie wszystkich żądań z maksymalnie 8 równoczesnymi klientami przy minimalnym wzroście opóźnienia wywołania.

Ostateczne dane wyjściowe zawierają tabelę z metrykami CloudWatch dla każdego MaxConcurrency konfiguracja. W przeciwieństwie do poprzedniej tabeli przedstawiającej rozkład opóźnień dla każdej konfiguracji pamięci, która nie zawsze może wyświetlać zimny start ModelSetupTime metryki, prawdopodobieństwo pojawienia się tej metryki w tej tabeli jest znacznie większe ze względu na większą liczbę żądań wywołań i większą MaxConcurrency.

Wnioski

W tym poście przedstawiliśmy zestaw narzędzi SageMaker Serverless Inference Benchmarking Toolkit i przedstawiliśmy przegląd jego konfiguracji i wyników. Narzędzie może pomóc w podjęciu bardziej świadomej decyzji w odniesieniu do wnioskowania bezserwerowego poprzez testowanie obciążenia różnych konfiguracji z realistycznymi wzorcami ruchu. Wypróbuj zestaw narzędzi do testów porównawczych z własnymi modelami, aby przekonać się, jakiej wydajności i oszczędności można oczekiwać po wdrożeniu bezserwerowego punktu końcowego. Proszę odnieść się do GitHub repo w celu uzyskania dodatkowej dokumentacji i przykładowych notatników.

Dodatkowe zasoby

O autorach

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.

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

Rishabh Ray Chaudhury jest starszym menedżerem produktu w Amazon SageMaker, koncentrując się na wnioskowaniu na uczeniu maszynowym. Jest pasjonatem innowacji i budowania nowych doświadczeń dla klientów korzystających z uczenia maszynowego w AWS, aby pomóc skalować ich obciążenia. W wolnym czasie lubi podróżować i gotować. Możesz go znaleźć na LinkedIn.