Kostnadseffektiv ML-inferens med modeller med flera ramar på Amazon SageMaker 

Maskininlärning (ML) har visat sig vara en av de mest framgångsrika och utbredda tillämpningarna av teknik, som påverkar ett brett spektrum av industrier och påverkar miljarder användare varje dag. Med denna snabba introduktion av ML i alla branscher står företag inför utmaningar när det gäller att stödja förutsägelser med låg latens och med hög tillgänglighet samtidigt som de maximerar resursutnyttjandet och minskar relaterade kostnader. Eftersom varje ML-ramverk har sina egna beroenden och distributionsstegen för varje ramverk är olika, blir det mer och mer komplext att distribuera modeller som är byggda i olika ramverk i produktionen och hantera var och en av slutpunkterna.

Amazon SageMaker multi-container endpoints (MCE) gör det möjligt för oss att gruppera modeller på olika ramverk och distribuera dem till samma värd, vilket skapar en enda slutpunkt. Du kan tillhandahålla behållare för de olika ramverken som du använder för att bygga modellerna, och SageMaker tar alla dessa behållare och placerar dem bakom en slutpunkt. Till exempel kan du ha en PyTorch- och en TensorFlow-modell laddade på två dedikerade slutpunkter som tjänar samma eller helt olika användningsfall, och båda dessa modeller har intermittent inkommande trafik som inte använder resurser till sin gräns. I ett sådant scenario skulle du kunna klubba ihop dem med hjälp av behållare till en slutpunkt med hjälp av en MCE, vilket förbättrar resursutnyttjandet samtidigt som du minskar kostnaderna för att ha båda modellerna att betjäna från olika slutpunkter.

Slutpunkter för flera behållare ger en skalbar och kostnadseffektiv lösning för att distribuera upp till 15 modeller byggda på olika ML-ramverk, modellservrar och algoritmer som tjänar samma eller olika användningsfall, vilket innebär att du kan ha modeller byggda på olika ML-ramverk eller mellanhand steg över alla dessa behållare och modeller. Alla dessa modeller kan nås individuellt via direktanrop eller sammanfogas i en pipeline med seriell anrop, där utdata från en modell är indata för nästa.

I det här inlägget diskuterar vi hur man utför kostnadseffektiv ML-inferens med multi-framework-modeller på SageMaker.

MCE-anropsmönster

SageMaker MCE-direktanrop är användbart i fall där du har klubbat orelaterade modeller till en MCE-slutpunkt eller du kör ett A/B-test mellan modellerna bakom en MCE-slutpunkt för att mäta deras prestanda. Du kan anropa den specifika behållaren direkt i API-anropet och få förutsägelsen från den modellen.

Med serieanrop kan du sy ihop 2–15 behållare, och utgången från en blir ingången till nästa behållare i följd. Detta är ett idealiskt användningsfall om du till exempel har en flerstegsprediktionspipeline där en Scikit-learn-modell används för en mellanförutsägelse och resultatet matas till en TensorFlow-modell för slutlig slutledning. Istället för att ha dem distribuerade som olika slutpunkter och en annan applikation eller jobb som orkestrerar dem och gör flera API-anrop, kan du distribuera dem som en SageMaker MCE, abstrahera logiken och ställa in dem för seriell anrop, där SageMaker hanterar dataöverföringen mellan en behållare till en annan automatiskt och skickar utdata från den slutliga behållaren till klienten som gör API-begäran.

SageMaker MCE seriell anrop skiljer sig fundamentalt från en SageMaker seriell inferenspipeline (mer information i avsnitten nedan). En seriell inferenspipeline är mer inriktad på att orkestrera komplexa ML-arbetsflöden som dataförbearbetning, bygga en modellensemble, implementera villkorskontroller för att avgöra vilken modell som ska anropas, eller efterbearbeta förutsägelsen, som involverar affärslogik innan förutsägelsen skickas ut till nedströmsapplikationerna . Däremot är MCE-serieanrop designad för att sammanfoga 2–14 modeller i en pipeline för slutledning, där varje modell tar förutsägelsen från den föregående modellen som indata.

Alla behållare i en MCE är alltid i drift och i minnet, så det finns ingen kallstart när slutpunkten anropas. MCE:er förbättrar också slutpunktsanvändningen och förbättrar kostnaderna eftersom modellerna är utplacerade bakom en slutpunkt och delar den underliggande beräkningsinstansen, istället för att varje modell upptar individuella beräkningsresurser.

Låt oss titta på några användningsfall och se hur du kan använda SageMaker MCE:er för att optimera ML-inferens.

Användningsfall för SageMaker MCE:er

Anta att du har två modeller för sentimentklassificering, en för engelska och andra för tyska, och dessa modeller betjänar olika geografier med trafik som kommer in vid olika tidpunkter på en dag. Istället för att ha två slutpunkter som körs 24/7, kan du distribuera båda till en slutpunkt med hjälp av en MCE och komma åt dem med direktanrop, och därigenom optimera ditt resursutnyttjande och dina kostnader. Se följande 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’)

I det här exemplet har vi två modeller (englishModel och germanModel), och vi definierar behållarna i SageMaker create_model konstruera och definiera InferenceExecutionConfig som 'Direkt'. Nu kan vi kalla slutpunkten för slutledning och definiera TargetContainerHostname som antingen englishModel or germanModel beroende på klienten som gör API-anropet:

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

Du kan också använda direktanrop inom MCE för att köra A/B-tester för att jämföra prestanda mellan modellerna.

Följande diagram illustrerar vår arkitektur.

På liknande sätt, i andra ML-användningsfall, när den tränade modellen används för att bearbeta en begäran, tar modellen emot data i ett format som behöver förbehandlas (till exempel presenteras) innan det kan skickas till algoritmen för slutledning. När ML-algoritmer kedjas ihop, fungerar utdata från en modell som indata för nästa innan det slutliga resultatet når. I det här fallet kan du bygga en SageMaker MCE seriell pipeline, där behållarna pratar med varandra i den sekvens som definieras i create_model konstruera istället för att du distribuerar var och en av modellerna till olika slutpunkter och skriver en oberoende logik för att underlätta dataflödet mellan alla dessa modeller och API-anrop. Följande diagram illustrerar denna arkitektur.

För detta användningsfall använder vi följande kod:

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,...)

I det här exemplet har vi två bearbetningsbehållare (Processing-1 och Processing-2) för funktionsbearbetning och datatransformationer, och två slutledningsbehållare (Inference-1 och Inference-2) för att köra ML-modellförutsägelser på förbearbetade data. De PipelineModel instans låter dig definiera inferenspipeline som består av en linjär sekvens av fyra behållare som behandlar förfrågningar om inferens på data. Behållarna är samlokaliserade på samma instans, vilket gör att du kan köra inferens med låg latens.

Skala flermodellslutpunkter för ett stort antal modeller

Fördelarna med SageMaker multi-model endpoints ökar baserat på omfattningen av modellkonsolidering. Du kan se kostnadsbesparingar när du är värd för två modeller med en slutpunkt, och för användningsfall med hundratals eller tusentals modeller är besparingarna mycket större.

Det är också enkelt att skala MCE-ändpunkterna med hjälp av SageMakerVariantInvocationsPerInstance fördefinierat mått, som ger det genomsnittliga antalet gånger per minut som varje instans för en modelländpunkt anropas för att definiera en TargetScaling politik. SageMaker justerar dynamiskt antalet instanser som tillhandahålls för en modell som svar på förändringar i din arbetsbelastning. När arbetsbelastningen ökar, tar autoskalning fler instanser online och laddas med målmodellerna och behållarna för att fortsätta betjäna förfrågningarna. När arbetsbelastningen minskar tar autoskalning bort onödiga instanser och lastar av modellbehållarna så att behållarna inte äter upp resurserna och du betalar inte för instanser som du inte använder. Tiden för att slutföra den första begäran mot en given modell upplever ytterligare latens (kallad kallstart) att ladda ner modellen från Amazon enkel lagringstjänst (Amazon S3) och ladda den i minnet. Efterföljande samtal avslutas utan extra kostnader eftersom modellen redan är laddad. Se följande 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
    }
)

Efter policykonfigurationen i föregående exempel använder vi SageMakerVariantInvocationsPerInstance fördefinierat mått för att justera antalet variantinstanser så att varje instans har en InvocationsPerInstance mått på 70.

Vi kan även skala SageMaker MCE baserat på vår egen anpassade mätning, som t.ex CPUUtilization, MemoryUtilization, GPUUtilization, GPUMemoryUtilization, eller DiskUtilization, för att skala upp eller ned antalet instanser baserat på användningen av en specifik resurs. För mer information, se Skala Amazon SageMaker-modeller automatiskt.

Det rekommenderas att modellen i varje behållare uppvisar liknande beräknings- och latenskrav för varje slutledningsbegäran, eftersom om trafiken till MCE:n skiftar från en modell med hög CPU-användning till en modell med låg CPU-användning, men den totala samtalsvolymen förblir densamma, kommer slutpunkten skalas inte ut och det kanske inte finns tillräckligt med instanser för att hantera alla förfrågningar till modellen med hög CPU-användning.

Säkra MCE:er

För MCE:er med direktanrop, lagras flera behållare i en enda instans genom att dela minne och en lagringsvolym. Det är viktigt att säkra behållarna, underhålla korrekt mappning av förfrågningar till målbehållare och ge användarna rätt åtkomst till målbehållare. Du kan begränsa invoke_endpoint tillgång till en begränsad uppsättning behållare inuti en MCE med hjälp av sagemaker:TargetContainerHostname AWS identitets- och åtkomsthantering (IAM) villkorsnyckel. SageMaker använder IAM-roller att tillhandahålla IAM-identitetsbaserade policyer som du använder för att specificera tillåtna eller nekade åtgärder och resurser och under vilka villkor åtgärder är tillåtna eller nekade. Följande policyer visar hur man begränsar anrop till specifika behållare inom en slutpunkt:

{
    "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*"]
                }
            }
        }
    ]
}

Övervaka flermodellslutpunkter med Amazon CloudWatch-mätvärden

För att göra avvägningar mellan pris och prestanda, vill du testa flermodellslutpunkter med modeller och representativ trafik från din egen applikation. SageMaker tillhandahåller ytterligare mätvärden i amazoncloudwatch för flermodellslutpunkter så att du kan bestämma slutpunktsanvändningen och cacheträfffrekvensen och optimera din slutpunkt. Mätvärdena är följande:

• ModelLoadingWaitTime – Tidsintervallet som en anropsbegäran väntar på att målmodellen ska laddas ner eller laddas för att utföra slutledningen.
• ModelUnloadingTime – Tidsintervallet som det tar att lossa modellen genom containerns UnloadModel API-samtal.
• Modellnedladdningstid – Tidsintervallet som det tar att ladda ner modellen från Amazon S3.
• ModelLoadingTime – Tidsintervallet som det tar att ladda modellen genom containerns LoadModel API-samtal.
• ModelCacheHit - Antalet InvokeEndpoint förfrågningar som skickas till slutpunkten där modellen redan laddades. Att ta Average statistik visar förhållandet mellan förfrågningar där modellen redan laddades.
• LoadedModelCount – Antalet modeller som är lastade i behållarna i ändpunkten. Detta mått sänds ut per instans. De Average statistik med en period på 1 minut talar om för dig det genomsnittliga antalet laddade modeller per instans, och Sum statistik visar det totala antalet modeller som laddats över alla instanser i slutpunkten. Modellerna som detta mätvärde spårar är inte nödvändigtvis unika eftersom du kan ladda en modell i flera behållare i slutpunkten.

Det finns också flera andra mätvärden som används av varje behållare som körs på en instans, som t.ex Invocations anger antalet InvokeEndpoint förfrågningar som skickas till en container i en slutpunkt, ContainerLatency ange den tid en slutpunkt tog för målbehållaren eller alla behållare i en serieanrop att svara enligt SageMaker, och CPUUtilization och MemoryUtilizaton som indikerar CPU-enheterna och minnesprocenten.

Slutsats

I inlägget diskuterade vi hur SageMaker multi-container endpoints kan vara till hjälp för att optimera kostnader och resursutnyttjande. Exempel på när man ska använda MCE inkluderar, men är inte begränsade till, följande:

• Hosta modeller över olika ramverk (som TensorFlow, PyTorch och Scikit-learn) som inte har tillräckligt med trafik för att mätta hela kapaciteten för en instans
• Hosta modeller från samma ramverk med olika ML-algoritmer (som rekommendationer, prognoser eller klassificering) och hanterarfunktioner
• Jämförelser av liknande arkitekturer som körs på olika ramverksversioner (som TensorFlow 1.x vs. TensorFlow 2.x) för scenarier som A/B-testning

SageMaker MCE:er stöder att distribuera upp till 15 behållare på realtidsslutpunkter och anropa dem oberoende för slutledning med låg latens och kostnadsbesparingar. Modellerna kan vara helt heterogena, med en egen oberoende serveringsstack. Du kan antingen anropa dessa behållare sekventiellt eller oberoende för varje begäran. Säker värd för flera modeller, från olika ramverk, på en enda instans kan spara upp till 90 % i kostnad jämfört med värdmodeller i dedikerade slutpunkter för en instans.

Om författarna

Dhawal Patel är en huvudarkitekt för maskininlärning på AWS. Han har arbetat med organisationer som sträcker sig från stora företag till medelstora startups med problem relaterade till distribuerad datoranvändning och artificiell intelligens. Han fokuserar på djupinlärning, inklusive NLP och datorseende domäner. Han hjälper kunder att uppnå högpresterande modellslutledning på Amazon SageMaker.

Vikram Elango är Senior AI/ML Specialist Solutions Architect på Amazon Web Services, baserad i Virginia, USA. Vikram hjälper globala finans- och försäkringskunder med design- och tankeledarskap att bygga och distribuera maskininlärningsapplikationer i stor skala. Han är för närvarande fokuserad på naturlig språkbehandling, ansvarsfull AI, slutledningsoptimering och skalning av ML över hela företaget. På fritiden tycker han om att resa, vandra, laga mat och campa med sin familj.

Saurabh Trikande är senior produktchef för Amazon SageMaker Inference. Han brinner för att arbeta med kunder och motiveras av målet att demokratisera maskininlärning. Han fokuserar på kärnutmaningar relaterade till att distribuera komplexa ML-applikationer, multi-tenant ML-modeller, kostnadsoptimeringar och att göra implementeringen av djupinlärningsmodeller mer tillgänglig. På sin fritid gillar Saurabh att vandra, lära sig om innovativ teknik, följa TechCrunch och umgås med sin familj.