Omkostningseffektiv ML-slutning med multi-framework-modeller på Amazon SageMaker 

Machine learning (ML) har vist sig at være en af ​​de mest succesrige og udbredte anvendelser af teknologi, der påvirker en lang række industrier og påvirker milliarder af brugere hver dag. Med denne hurtige indførelse af ML i alle brancher står virksomheder over for udfordringer med at understøtte forudsigelser med lav latens og høj tilgængelighed, mens de maksimerer ressourceudnyttelsen og reducerer de tilknyttede omkostninger. Fordi hver ML-framework har sine egne afhængigheder, og implementeringstrinene for hver framework er forskellige, bliver implementering af modeller bygget i forskellige frameworks i produktionen og styring af hvert af slutpunkterne mere og mere kompleks.

Amazon SageMaker multi-container endpoints (MCE'er) gør det muligt for os at gruppere modeller på forskellige rammer og implementere dem til den samme vært, hvilket skaber et enkelt slutpunkt. Du kan levere containere til de forskellige frameworks, som du bruger til at bygge modellerne, og SageMaker tager alle disse containere og sætter dem bag ét endepunkt. For eksempel kan du have en PyTorch- og en TensorFlow-model indlæst på to dedikerede endepunkter, der betjener de samme eller helt forskellige brugssager, og begge disse modeller har intermitterende indgående trafik, der ikke udnytter ressourcerne til dets grænser. I et sådant scenarie kan du samle dem ved hjælp af containere til ét endepunkt ved hjælp af en MCE, hvilket forbedrer ressourceudnyttelsen, mens du reducerer omkostningerne ved at have begge modeller til at betjene fra forskellige endepunkter.

Multi-container-endepunkter giver en skalerbar og omkostningseffektiv løsning til at implementere op til 15 modeller bygget på forskellige ML-frameworks, modelservere og algoritmer, der tjener samme eller forskellige use case, hvilket betyder, at du kan få modeller bygget på forskellige ML-frameworks eller mellemled. trin på tværs af alle disse beholdere og modeller. Alle disse modeller kan tilgås individuelt via direkte kald eller syet ind i en pipeline ved hjælp af seriel kald, hvor output fra én model er input til den næste.

I dette indlæg diskuterer vi, hvordan man udfører omkostningseffektiv ML-slutning med multi-framework-modeller på SageMaker.

MCE-invokationsmønstre

SageMaker MCE direkte påkaldelse er nyttig i tilfælde, hvor du har lagt urelaterede modeller ind i et MCE-slutpunkt, eller du kører en A/B-test mellem modellerne bag et MCE-endepunkt for at måle deres ydeevne. Du kan kalde den specifikke container direkte i API-kaldet og få forudsigelsen fra den model.

Med seriel invokation kan du sy 2-15 containere sammen, og outputtet fra den ene bliver input til den næste container i rækkefølge. Dette er en ideel use case, hvis du for eksempel har en flertrins forudsigelsespipeline, hvor en Scikit-learn-model bruges til en mellemforudsigelse, og resultatet føres til en TensorFlow-model for endelig inferens. I stedet for at få dem implementeret som forskellige endepunkter og en anden applikation eller job til at orkestrere dem og foretage flere API-kald, kan du implementere dem som en SageMaker MCE, abstrahere logikken og indstille dem til seriel invokation, hvor SageMaker styrer dataoverførslen mellem én container til en anden automatisk og udsender output fra den endelige container til klienten, der foretager API-anmodningen.

SageMaker MCE seriel invokation er fundamentalt forskellig fra en SageMaker seriel inferens pipeline (flere detaljer i afsnittene nedenfor). En seriel inferenspipeline er mere målrettet til at orkestrere komplekse ML-arbejdsgange, såsom dataforbehandling, opbygning af et modelensemble, implementering af betingede kontroller for at bestemme, hvilken model der skal påberåbes, eller efterbehandling af forudsigelsen, der involverer forretningslogik, før forudsigelsen sendes ud til downstream-applikationerne . I modsætning hertil er MCE seriel invokation designet til at sy 2-14 modeller ind i en pipeline til slutning, hvor hver model tager forudsigelsen af ​​den tidligere model som input.

Alle beholderne i en MCE er altid i drift og i hukommelsen, så der er ingen koldstart, mens du kalder slutpunktet. MCE'er forbedrer også slutpunktsudnyttelsen og forbedrer omkostningerne, fordi modeller er implementeret bag ét slutpunkt og deler den underliggende beregningsinstans, i stedet for at hver model optager individuelle computerressourcer.

Lad os se på nogle få use cases og se, hvordan du kan bruge SageMaker MCE'er til at optimere ML-inferens.

Use cases for SageMaker MCE'er

Antag, at du har to modeller for sentimentklassificering, en for engelsk sprog og en anden for tysk, og disse modeller betjener forskellige geografier med trafik, der kommer ind på forskellige tidspunkter på en dag. I stedet for at have to endepunkter, der kører 24/7, kan du implementere dem begge i ét endepunkt ved hjælp af en MCE og få adgang til dem ved hjælp af direkte påkald, og derved optimere din ressourceudnyttelse og omkostninger. Se følgende kode:

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 dette eksempel har vi to modeller (englishModel , germanModel), og vi definerer beholderne i SageMaker create_model konstruere og definere InferenceExecutionConfig som 'Direkte'. Nu kan vi kalde slutpunktet for inferens og definere TargetContainerHostname som enten englishModel or germanModel afhængigt af klienten, der foretager API-kaldet:

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

Du kan også bruge direkte påkald i MCE'en til at køre A/B-tests for at sammenligne ydeevnen mellem modellerne.

Følgende diagram illustrerer vores arkitektur.

Tilsvarende, i andre ML-brugstilfælde, når den trænede model bruges til at behandle en anmodning, modtager modellen data i et format, der skal forbehandles (f.eks. fremhæves), før det kan videregives til algoritmen til slutning. Når ML-algoritmer er kædet sammen, tjener outputtet fra en model som input til den næste, før det når det endelige resultat. I dette tilfælde kan du bygge en SageMaker MCE seriel pipeline, hvor containerne taler med hinanden i den rækkefølge, der er defineret i create_model konstruer i stedet for at du implementerer hver af modellerne i forskellige endepunkter og skriver en uafhængig logik for at lette strømmen af ​​data mellem alle disse modeller og API-kald. Følgende diagram illustrerer denne arkitektur.

Til dette use case bruger vi følgende kode:

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 dette eksempel har vi to behandlingsbeholdere (Processing-1 , Processing-2) til funktionsbehandling og datatransformationer og to inferensbeholdere (Inference-1 , Inference-2) for at køre ML-modelforudsigelser på de forbehandlede data. Det PipelineModel instans giver dig mulighed for at definere inferenspipelinen sammensat af en lineær sekvens af fire containere, der behandler anmodninger om inferens på data. Containerne er placeret på samme instans, hvilket gør det muligt for dig at køre inferens med lav latenstid.

Skaler multi-model slutpunkter for et stort antal modeller

Fordelene ved SageMaker multi-model endpoints øges baseret på skalaen af ​​modelkonsolidering. Du kan se omkostningsbesparelser, når du hoster to modeller med ét slutpunkt, og for brugssager med hundreder eller tusinder af modeller er besparelserne meget større.

At skalere MCE-endepunkterne er også ligetil ved at bruge SageMakerVariantInvocationsPerInstance foruddefineret metrik, som angiver det gennemsnitlige antal gange pr. minut, som hver instans for et modelendepunkt kaldes for at definere en TargetScaling politik. SageMaker justerer dynamisk antallet af forekomster, der er klargjort for en model, som svar på ændringer i din arbejdsbyrde. Når arbejdsbyrden stiger, bringer autoskalering flere forekomster online og indlæses med målmodellerne og containerne for at blive ved med at betjene anmodningerne. Når arbejdsbyrden falder, fjerner autoskalering unødvendige forekomster og aflaster modelcontainerne, så containerne ikke spiser ressourcerne, og du betaler ikke for forekomster, som du ikke bruger. Tiden til at fuldføre den første anmodning mod en given model oplever yderligere latenstid (kaldet en kold start) til at downloade modellen fra Amazon Simple Storage Service (Amazon S3) og indlæs den i hukommelsen. Efterfølgende opkald afsluttes uden yderligere omkostninger, fordi modellen allerede er indlæst. Se følgende kode:

# 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 det foregående eksempel på politikkonfigurationen bruger vi SageMakerVariantInvocationsPerInstance foruddefineret metric for at justere antallet af variantforekomster, så hver forekomst har en InvocationsPerInstance metrisk på 70.

Vi kan også skalere SageMaker MCE'er baseret på vores egen tilpassede metrik, som f.eks CPUUtilization, MemoryUtilization, GPUUtilization, GPUMemoryUtilization eller DiskUtilization, for at skalere op eller ned for antallet af forekomster baseret på udnyttelse af en specifik ressource. For mere information, se Skaler automatisk Amazon SageMaker-modeller.

Det anbefales, at modellen i hver container udviser lignende beregnings- og latenskrav på hver inferensanmodning, fordi hvis trafikken til MCE'en skifter fra en model med høj CPU-udnyttelse til en model med lav CPU-udnyttelse, men den samlede opkaldsvolumen forbliver den samme, vil slutpunktet skalerer ikke ud, og der er muligvis ikke nok instanser til at håndtere alle anmodninger til modellen med høj CPU-udnyttelse.

Sikre MCE'er

For MCE'er med direkte opkald hostes flere containere i en enkelt instans ved at dele hukommelse og en lagervolumen. Det er vigtigt at sikre containerne, vedligeholde den korrekte kortlægning af anmodninger til målcontainere og give brugerne den korrekte adgang til målcontainere. Du kan begrænse invoke_endpoint adgang til et begrænset sæt beholdere inde i en MCE ved hjælp af sagemaker:TargetContainerHostname AWS identitets- og adgangsstyring (IAM) tilstandsnøgle. SageMaker bruger IAM roller at levere IAM-identitetsbaserede politikker, som du bruger til at specificere tilladte eller nægtede handlinger og ressourcer og de betingelser, hvorunder handlinger er tilladt eller afvist. Følgende politikker viser, hvordan man begrænser opkald til bestemte containere inden for et 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*"]
                }
            }
        }
    ]
}

Overvåg multi-model slutpunkter ved hjælp af Amazon CloudWatch-metrics

For at afveje pris og ydeevne, vil du gerne teste multi-model slutpunkter med modeller og repræsentativ trafik fra din egen applikation. SageMaker giver yderligere metrics i amazoncloudwatch for multi-model-endepunkter, så du kan bestemme slutpunktforbruget og cache-hitraten og optimere dit slutpunkt. Metrics er som følger:

• ModelLoadingWaitTime – Det tidsinterval, som en invokationsanmodning venter på, at målmodellen skal downloades eller indlæses for at udføre slutningen.
• ModelUdlæsningstid – Det tidsinterval, det tager at losse modellen gennem containerens UnloadModel API-kald.
• Modeldownloadtid – Det tidsinterval, det tager at downloade modellen fra Amazon S3.
• ModelLoadingTime – Det tidsinterval, det tager at læsse modellen gennem containerens LoadModel API-kald.
• ModelCacheHit - Antallet af InvokeEndpoint anmodninger sendt til slutpunktet, hvor modellen allerede var indlæst. At tage Average statistik viser forholdet mellem anmodninger, hvor modellen allerede var indlæst.
• LoadedModelCount – Antallet af modeller, der er læsset i containerne i endepunktet. Denne metrik udsendes pr. instans. Det Average statistik med en periode på 1 minut fortæller dig det gennemsnitlige antal indlæste modeller pr. instans, og Sum statistik fortæller dig det samlede antal modeller, der er indlæst på tværs af alle forekomster i slutpunktet. De modeller, som denne metric sporer, er ikke nødvendigvis unikke, fordi du kan indlæse en model i flere containere i slutpunktet.

Der er også flere andre metrics, der bruges af hver container, der kører på en instans, som f.eks Invocations med angivelse af antallet af InvokeEndpoint anmodninger sendt til en container inde i et slutpunkt, ContainerLatency give den tid, et slutpunkt tog for målbeholderen eller alle beholderne i en seriel invokation til at reagere som set fra SageMaker, og CPUUtilization , MemoryUtilizaton angiver CPU-enhederne og procentdelen af ​​hukommelsen.

Konklusion

I indlægget diskuterede vi, hvordan SageMaker multi-container-endepunkter kan være nyttige til at optimere omkostninger og ressourceudnyttelse. Eksempler på, hvornår man skal bruge MCE'er omfatter, men er ikke begrænset til, følgende:

• Hosting af modeller på tværs af forskellige rammer (såsom TensorFlow, PyTorch og Scikit-learn), der ikke har tilstrækkelig trafik til at mætte den fulde kapacitet af en instans
• Hosting af modeller fra den samme ramme med forskellige ML-algoritmer (såsom anbefalinger, prognoser eller klassificering) og handlerfunktioner
• Sammenligninger af lignende arkitekturer, der kører på forskellige rammeversioner (såsom TensorFlow 1.x vs. TensorFlow 2.x) til scenarier som A/B-testning

SageMaker MCE'er understøtter implementering af op til 15 containere på real-time endpoints og påberåber dem uafhængigt for lav latens slutning og omkostningsbesparelser. Modellerne kan være fuldstændig heterogene med deres egen uafhængige serveringsstak. Du kan enten kalde disse beholdere sekventielt eller uafhængigt for hver anmodning. Sikker hosting af flere modeller fra forskellige rammer på en enkelt instans kan spare dig op til 90 % i omkostninger sammenlignet med hosting af modeller i dedikerede single-instans endpoints.

Om forfatterne

Dhawal Patel er Principal Machine Learning Architect hos AWS. Han har arbejdet med organisationer lige fra store virksomheder til mellemstore startups om problemer relateret til distribueret databehandling og kunstig intelligens. Han fokuserer på dyb læring, herunder NLP og computer vision domæner. Han hjælper kunder med at opnå højtydende modelslutning på Amazon SageMaker.

Vikram Elango er Senior AI/ML Specialist Solutions Architect hos Amazon Web Services, baseret i Virginia, USA. Vikram hjælper globale finans- og forsikringsindustrikunder med design og tankelederskab med at bygge og implementere maskinlæringsapplikationer i stor skala. Han er i øjeblikket fokuseret på naturlig sprogbehandling, ansvarlig AI, inferensoptimering og skalering af ML på tværs af virksomheden. I sin fritid nyder han at rejse, vandre, lave mad og campere med sin familie.

Saurabh Trikande er Senior Product Manager for Amazon SageMaker Inference. Han brænder for at arbejde med kunder og er motiveret af målet om at demokratisere machine learning. Han fokuserer på kerneudfordringer relateret til implementering af komplekse ML-applikationer, multi-tenant ML-modeller, omkostningsoptimeringer og at gøre implementering af deep learning-modeller mere tilgængelig. I sin fritid nyder Saurabh at vandre, lære om innovative teknologier, følge TechCrunch og tilbringe tid med sin familie.