Efektywne kosztowo wnioskowanie ML z modelami wieloplatformowymi w Amazon SageMaker 

Uczenie maszynowe (ML) okazało się jednym z najskuteczniejszych i najbardziej rozpowszechnionych zastosowań technologii, które ma wpływ na wiele branż i każdego dnia wpływa na miliardy użytkowników. W związku z szybkim przyjęciem ML w każdej branży firmy stoją przed wyzwaniami w zakresie obsługi prognoz o niskich opóźnieniach i wysokiej dostępności przy maksymalizacji wykorzystania zasobów i redukcji powiązanych kosztów. Ponieważ każda struktura ML ma własne zależności, a kroki wdrażania dla każdej struktury są różne, wdrażanie modeli zbudowanych w różnych strukturach w środowisku produkcyjnym i zarządzanie każdym z punktów końcowych staje się coraz bardziej złożone.

Amazon Sage Maker Wielokontenerowe punkty końcowe (MCE) umożliwiają nam grupowanie modeli na różnych platformach i wdrażanie ich na tym samym hoście, tworząc jeden punkt końcowy. Możesz udostępnić kontenery dla różnych struktur, których używasz do budowania modeli, a SageMaker pobiera wszystkie te kontenery i umieszcza je za jednym punktem końcowym. Na przykład możesz mieć modele PyTorch i TensorFlow załadowane na dwóch dedykowanych punktach końcowych obsługujących te same lub zupełnie różne przypadki użycia, a oba te modele mają przerywany ruch przychodzący, który nie wykorzystuje zasobów do swoich limitów. W takim scenariuszu można połączyć je za pomocą kontenerów w jeden punkt końcowy za pomocą MCE, poprawiając wykorzystanie zasobów przy jednoczesnym obniżeniu kosztów ponoszonych w związku z posiadaniem obu modeli obsługujących z różnych punktów końcowych.

Wielokontenerowe punkty końcowe zapewniają skalowalne i ekonomiczne rozwiązanie do wdrażania do 15 modeli zbudowanych na różnych platformach ML, serwerach modelowych i algorytmach obsługujących ten sam lub inny przypadek użycia, co oznacza, że ​​możesz mieć modele zbudowane na różnych platformach ML lub pośrednikach kroki we wszystkich tych kontenerach i modelach. Dostęp do wszystkich tych modeli można uzyskać indywidualnie poprzez bezpośrednie wywołanie lub połączone w potok za pomocą wywołania szeregowego, gdzie dane wyjściowe jednego modelu są danymi wejściowymi dla następnego.

W tym poście omówimy, jak przeprowadzić efektywne kosztowo wnioskowanie ML za pomocą modeli wielostrukturalnych w programie SageMaker.

Wzorce wywołań MCE

Bezpośrednie wywoływanie programu SageMaker MCE jest przydatne w przypadkach, gdy kijowałeś niezwiązane modele z punktem końcowym MCE lub przeprowadzasz test A/B między modelami za punktem końcowym MCE, aby ocenić ich wydajność. Możesz wywołać konkretny kontener bezpośrednio w wywołaniu interfejsu API i uzyskać prognozę z tego modelu.

Dzięki wywołaniu szeregowemu można połączyć ze sobą 2–15 kontenerów, a dane wyjściowe jednego stają się danymi wejściowymi następnego kontenera w kolejności. Jest to idealny przypadek użycia, jeśli na przykład masz potok przewidywania wieloetapowego, w którym model uczenia się Scikit jest używany do przewidywania pośredniego, a wynik jest przekazywany do modelu TensorFlow w celu ostatecznego wnioskowania. Zamiast wdrażać je jako różne punkty końcowe i inną aplikację lub zadanie, które je aranżuje i wykonuje wiele wywołań API, można je wdrożyć jako MCE SageMaker, abstrahując logikę i konfigurując je do wywoływania szeregowego, gdzie SageMaker zarządza transferem danych między jednym kontenerem do innego automatycznie i emituje dane wyjściowe końcowego kontenera do klienta wysyłającego żądanie API.

Wywołanie szeregowe SageMaker MCE zasadniczo różni się od szeregowego potoku wnioskowania SageMaker (więcej szczegółów w poniższych sekcjach). Szeregowy potok wnioskowania jest przeznaczony bardziej do organizowania złożonych przepływów pracy ML, takich jak wstępne przetwarzanie danych, budowanie zestawu modeli, wdrażanie kontroli warunkowych w celu określenia, który model należy wywołać lub przetwarzanie końcowe prognozy, obejmujące logikę biznesową przed wysłaniem prognozy do dalszych aplikacji . Natomiast wywołanie szeregowe MCE jest przeznaczone do łączenia 2–14 modeli w potok w celu wnioskowania, przy czym każdy model przyjmuje jako dane wejściowe prognozę poprzedniego modelu.

Wszystkie kontenery w MCE są zawsze w usłudze i pamięci, więc nie ma zimnego startu podczas wywoływania punktu końcowego. Moduły MCE poprawiają również wykorzystanie punktów końcowych i obniżają koszty, ponieważ modele są wdrażane za jednym punktem końcowym i współużytkują bazowe wystąpienie obliczeniowe, a nie każdy model zajmujący poszczególne zasoby obliczeniowe.

Przyjrzyjmy się kilku przypadkom użycia i zobaczmy, jak można wykorzystać MCE SageMaker do optymalizacji wnioskowania ML.

Przypadki użycia modułów MCE SageMaker

Załóżmy, że masz dwa modele klasyfikacji nastrojów, jeden dla języka angielskiego, a drugi dla języka niemieckiego, które obsługują różne regiony geograficzne z ruchem napływającym o różnych porach dnia. Zamiast dwóch punktów końcowych działających 24 godziny na dobę, 7 dni w tygodniu, możesz wdrożyć oba w jednym punkcie końcowym za pomocą MCE i uzyskiwać do nich dostęp za pomocą bezpośredniego wywołania, optymalizując w ten sposób wykorzystanie zasobów i koszty. Zobacz następujący kod:

englishModel = {
   'Image': container1,
   'ContainerHostname': englishModel }; ...
 
germanModel = {
   'Image': container2,
   'ContainerHostname': germanModel }; ...
 
sm.create_model(
   InferenceExecutionConfig = {'Mode': 'Direct'},
   Containers = [englishModel, germanModel], ...)
sm.create_endpoint_config(EndpointConfigName = ‘my-mce-epc’,
    ProductionVariants=[{
        'InstanceType':        ‘ml.m4.xlarge’,
        'InitialInstanceCount': 2,
        'InitialVariantWeight': 1,
        'ModelName':            ‘my-multi-model-name’,
        'VariantName':          'AllTraffic'}])
sm.create_endpoint(EndpointName = ‘my-mce-endpoint’, 
                  EndpointConfigName = ‘my-mce-epc’)

W tym przykładzie mamy dwa modele (englishModel i germanModel) i definiujemy kontenery w SageMaker create_model skonstruować i zdefiniować InferenceExecutionConfig jako „Bezpośredni”. Teraz możemy wywołać punkt końcowy do wnioskowania i zdefiniować TargetContainerHostname albo jako englishModel or germanModel w zależności od klienta wykonującego wywołanie API:

sm.invoke_endpoint(        
   EndpointName = endpoint_name,
   TargetContainerHostname = englishModel,
   Body = body, ...)

Możesz również użyć bezpośredniego wywołania w MCE, aby uruchomić testy A/B w celu porównania wydajności między modelami.

Poniższy diagram ilustruje naszą architekturę.

Podobnie w innych przypadkach użycia ML, gdy wyszkolony model jest używany do przetwarzania żądania, model odbiera dane w formacie, który musi być wstępnie przetworzony (na przykład wyróżniony), zanim będzie można go przekazać do algorytmu w celu wnioskowania. Gdy algorytmy ML są połączone w łańcuch, dane wyjściowe jednego modelu służą jako dane wejściowe dla następnego przed osiągnięciem końcowego wyniku. W takim przypadku można zbudować potok szeregowy SageMaker MCE, w którym kontenery komunikują się ze sobą w kolejności określonej w create_model konstruuj zamiast wdrażać każdy z modeli w różnych punktach końcowych i pisać niezależną logikę, aby ułatwić przepływ danych między wszystkimi tymi modelami i wywołaniami interfejsu API. Poniższy diagram ilustruje tę architekturę.

W tym przypadku użycia używamy następującego kodu:

sm_model = PipelineModel(name=model_name, role=aws_role, models=[Processing-1, Processing-2, Inference-1, Inference-2]) 

predictor = sm_model.deploy(initial_instance_count=1, instance_type="ml.c4.xlarge")                  
response = runtime.invoke_endpoint( 
EndpointName=predictor.endpoint,                                
    Body=body,...)

W tym przykładzie mamy dwa pojemniki do przetwarzania (Processing-1 i Processing-2) do przetwarzania cech i przekształceń danych oraz dwa kontenery wnioskowania (Inference-1 i Inference-2), aby uruchomić prognozy modelu ML na wstępnie przetworzonych danych. The PipelineModel wystąpienie umożliwia zdefiniowanie potoku wnioskowania składającego się z liniowej sekwencji czterech kontenerów, które przetwarzają żądania dotyczące wnioskowania na danych. Kontenery znajdują się w tym samym wystąpieniu, co umożliwia wnioskowanie z małym opóźnieniem.

Skaluj wielomodelowe punkty końcowe dla dużej liczby modeli

Korzyści z wielomodelowych punktów końcowych SageMaker rosną w zależności od skali konsolidacji modeli. Możesz zauważyć oszczędności kosztów, gdy hostujesz dwa modele z jednym punktem końcowym, a w przypadku użycia z setkami lub tysiącami modeli oszczędności są znacznie większe.

Skalowanie punktów końcowych MCE jest również proste za pomocą SageMakerVariantInvocationsPerInstance wstępnie zdefiniowana metryka, która podaje średnią liczbę razy na minutę, przez które każde wystąpienie punktu końcowego modelu jest wywoływane w celu zdefiniowania TargetScaling polityka. SageMaker dynamicznie dostosowuje liczbę instancji udostępnianych dla modelu w odpowiedzi na zmiany w obciążeniu. Gdy obciążenie wzrasta, autoskalowanie powoduje przełączenie większej liczby wystąpień w tryb online i ładowanie z modelami docelowymi i kontenerami, aby na bieżąco obsługiwać żądania. Gdy obciążenie spada, skalowanie automatyczne usuwa niepotrzebne wystąpienia i odciąża kontenery modelu, dzięki czemu kontenery nie zużywają zasobów i nie płacisz za wystąpienia, których nie używasz. Czas na ukończenie pierwszego żądania przeciwko danemu modelowi ma dodatkowe opóźnienie (tzw. zimny start) na pobranie modelu z Usługa Amazon Simple Storage (Amazon S3) i załaduj go do pamięci. Kolejne wywołania kończą się bez dodatkowych kosztów, ponieważ model jest już załadowany. Zobacz następujący kod:

# AutoScaling client
asg = boto3.client('application-autoscaling')

# Resource type is variant and the unique identifier is the resource ID.
resource_id=f"endpoint/{endpoint_name}/variant/AllTraffic"

# scaling configuration
response = asg.register_scalable_target(
    ServiceNamespace='sagemaker', #
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount', 
    MinCapacity=1,
    MaxCapacity=4
)
#Target Scaling
response = asg.put_scaling_policy(
    PolicyName=f'Request-ScalingPolicy-{endpoint_name}',
    ServiceNamespace='sagemaker',
    ResourceId=resource_id,
    ScalableDimension='sagemaker:variant:DesiredInstanceCount',
    PolicyType='TargetTrackingScaling',
    TargetTrackingScalingPolicyConfiguration={
        'TargetValue': 70.0, # Threshold
        'PredefinedMetricSpecification': {
            'PredefinedMetricType': 'SageMakerVariantInvocationsPerInstance',
        },
        'ScaleInCooldown': 300, # duration until scale in
        'ScaleOutCooldown': 60 # duration between scale out
    }
)

Zgodnie z poprzednią przykładową konfiguracją zasad używamy SageMakerVariantInvocationsPerInstance wstępnie zdefiniowana metryka, aby dostosować liczbę instancji wariantów, tak aby każda instancja miała InvocationsPerInstance metryka 70.

Możemy również skalować MCE SageMaker w oparciu o nasze własne niestandardowe metryki, takie jak CPUUtilization, MemoryUtilization, GPUUtilization, GPUMemoryUtilizationlub DiskUtilization, aby skalować w górę lub w dół liczbę instancji na podstawie wykorzystania określonego zasobu. Aby uzyskać więcej informacji, zobacz Automatyczne skalowanie modeli Amazon SageMaker.

Zaleca się, aby model w każdym kontenerze wykazywał podobne wymagania dotyczące mocy obliczeniowej i opóźnień dla każdego żądania wnioskowania, ponieważ jeśli ruch do MCE zmieni się z modelu wysokiego wykorzystania procesora na model niskiego wykorzystania procesora, ale ogólna liczba wywołań pozostaje taka sama, punkt końcowy nie skaluje się w poziomie i może nie być wystarczającej liczby wystąpień do obsługi wszystkich żądań do modelu wysokiego wykorzystania procesora.

Bezpieczne MCE

W przypadku MCE z bezpośrednim wywoływaniem wiele kontenerów jest hostowanych w jednej instancji dzięki współdzieleniu pamięci i woluminu pamięci masowej. Ważne jest, aby zabezpieczyć kontenery, utrzymywać prawidłowe mapowanie żądań do kontenerów docelowych i zapewnić użytkownikom prawidłowy dostęp do kontenerów docelowych. Możesz ograniczyć invoke_endpoint dostęp do ograniczonego zestawu kontenerów wewnątrz MCE za pomocą sagemaker:TargetContainerHostname AWS Zarządzanie tożsamością i dostępem (IAM) klucz warunku. SageMaker używa Role IAM aby zapewnić zasady IAM oparte na tożsamości używane do określania dozwolonych lub odrzucanych akcji i zasobów oraz warunków, na których akcje są dozwolone lub odrzucane. Poniższe zasady pokazują, jak ograniczyć wywołania do określonych kontenerów w punkcie końcowym:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "sagemaker:InvokeEndpoint"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:sagemaker:region:account-id:endpoint/endpoint_name",
            "Condition": {
                "StringLike": {
                    "sagemaker:TargetContainerHostname": ["customIps*", "common*"]
                }
            }
        }
    ]
}

Monitoruj wielomodelowe punkty końcowe za pomocą metryk Amazon CloudWatch

Aby dokonać kompromisu w zakresie ceny i wydajności, warto przetestować wielomodelowe punkty końcowe z modelami i reprezentatywnym ruchem z własnej aplikacji. SageMaker zapewnia dodatkowe metryki w Amazon Cloud Watch dla wielomodelowych punktów końcowych, dzięki czemu można określić użycie punktu końcowego i współczynnik trafień w pamięci podręcznej oraz zoptymalizować punkt końcowy. Metryki są następujące:

• ModelŁadowanieCzas oczekiwania – Interwał czasu oczekiwania żądania wywołania na pobranie lub załadowanie modelu docelowego w celu przeprowadzenia wnioskowania.
• Czas Rozładunku Modelu – Interwał czasu potrzebny na rozładowanie modelu przez kontener UnloadModel Wywołanie API.
• ModelCzas Pobierania – Interwał czasu potrzebny na pobranie modelu z Amazon S3.
• Czas ładowania modelu – Interwał czasu potrzebny na załadowanie modelu przez kontener LoadModel Wywołanie API.
• ModelCacheHit - Liczba InvokeEndpoint żądania wysyłane do punktu końcowego, w którym model został już załadowany. Biorąc Average statystyka pokazuje stosunek żądań, w których model został już załadowany.
• Liczba załadowanych modeli – Liczba modeli załadowanych do kontenerów w punkcie końcowym. Ta metryka jest emitowana na instancję. The Average statystyka z okresem 1 minuty pokazuje średnią liczbę modeli załadowanych na instancję, a Sum statystyka informuje o całkowitej liczbie modeli załadowanych we wszystkich instancjach w punkcie końcowym. Modele, które śledzi ta metryka, niekoniecznie są unikatowe, ponieważ w punkcie końcowym można załadować model do wielu kontenerów.

Istnieje również kilka innych metryk używanych przez każdy kontener uruchomiony w instancji, takich jak Invocations wskazując liczbę InvokeEndpoint żądania wysyłane do kontenera wewnątrz punktu końcowego, ContainerLatency podając czas, jaki zajęło punktowi końcowemu, zanim kontener docelowy lub wszystkie kontenery w wywołaniu seryjnym zareagowały, jak widać z programu SageMaker, oraz CPUUtilization i MemoryUtilizaton wskazując jednostki procesora i procent pamięci.

Wnioski

W poście omówiliśmy, w jaki sposób wielokontenerowe punkty końcowe SageMaker mogą być pomocne w optymalizacji kosztów i wykorzystania zasobów. Przykłady wykorzystania MCE obejmują między innymi:

• Hosting modeli w różnych platformach (takich jak TensorFlow, PyTorch i Scikit-learn), które nie mają wystarczającego ruchu, aby nasycić pełną pojemność instancji
• Hosting modeli z tej samej platformy z różnymi algorytmami ML (takimi jak rekomendacje, prognozowanie lub klasyfikacja) i funkcjami obsługi
• Porównanie podobnych architektur działających na różnych wersjach frameworka (takich jak TensorFlow 1.x vs. TensorFlow 2.x) dla scenariuszy takich jak testy A/B

Moduły MCE SageMaker obsługują wdrażanie do 15 kontenerów na punktach końcowych w czasie rzeczywistym i wywoływanie ich niezależnie w celu uzyskania niewielkich opóźnień i oszczędności kosztów. Modele mogą być całkowicie heterogeniczne, z własnym niezależnym stosem obsługi. Możesz wywoływać te kontenery sekwencyjnie lub niezależnie dla każdego żądania. Bezpieczne hostowanie wielu modeli z różnych platform w jednym wystąpieniu może zaoszczędzić do 90% kosztów w porównaniu z hostowaniem modeli w dedykowanych punktach końcowych z jednym wystąpieniem.

O autorach

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 Amazon SageMaker.

Vikrama Elango jest starszym architektem rozwiązań AI/ML w Amazon Web Services z siedzibą w Wirginii w USA. Vikram pomaga globalnym klientom z branży finansowej i ubezpieczeniowej, zapewniając przywództwo projektowe i myślowe 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ą.

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