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

Maskinlæring (ML) har vist seg å være en av de mest vellykkede og utbredte anvendelsene av teknologi, som påvirker et bredt spekter av bransjer og påvirker milliarder av brukere hver dag. Med denne raske innføringen av ML i alle bransjer, står bedrifter overfor utfordringer med å støtte spådommer med lav latens og høy tilgjengelighet samtidig som de maksimerer ressursutnyttelsen og reduserer tilknyttede kostnader. Fordi hvert ML-rammeverk har sine egne avhengigheter, og distribusjonstrinn for hvert rammeverk er forskjellige, blir det mer og mer komplekst å distribuere modeller bygget i forskjellige rammeverk i produksjon og administrere hvert av endepunktene.

Amazon SageMaker multi-container endpoints (MCEer) gjør det mulig for oss å gruppere modeller på forskjellige rammeverk og distribuere dem til samme vert, og skape ett enkelt endepunkt. Du kan gi beholdere for de forskjellige rammeverkene du bruker for å bygge modellene, og SageMaker tar alle disse beholderne og plasserer dem bak ett endepunkt. For eksempel kan du ha en PyTorch- og en TensorFlow-modell lastet opp på to dedikerte endepunkter som betjener samme eller helt forskjellige brukstilfeller, og begge disse modellene har intermitterende innkommende trafikk som ikke utnytter ressursene til det ytterste. I et slikt scenario kan du slå dem sammen ved å bruke containere til ett endepunkt ved å bruke en MCE, og forbedre ressursutnyttelsen samtidig som du reduserer kostnadene som påløper ved å ha begge modellene til å betjene fra forskjellige endepunkter.

Endepunkter for flere beholdere gir en skalerbar og kostnadseffektiv løsning for å distribuere opptil 15 modeller bygget på forskjellige ML-rammeverk, modellservere og algoritmer som betjener samme eller forskjellige brukstilfeller, noe som betyr at du kan ha modeller bygget på forskjellige ML-rammeverk eller mellomledd trinn på tvers av alle disse beholderne og modellene. Alle disse modellene kan nås individuelt via direkte påkalling eller sys sammen i en rørledning ved hjelp av seriell påkalling, der utgangen fra én modell er inngangen til den neste.

I dette innlegget diskuterer vi hvordan du kan utføre kostnadseffektiv ML-slutning med multi-framework-modeller på SageMaker.

MCE-anropsmønstre

SageMaker MCE direkte påkalling er nyttig i tilfeller der du har lagt urelaterte modeller inn i et MCE-endepunkt eller du kjører en A/B-test mellom modellene bak et MCE-endepunkt for å måle ytelsen deres. Du kan kalle den spesifikke beholderen direkte i API-kallet og få prediksjonen fra den modellen.

Med serieanrop kan du sy sammen 2–15 beholdere, og utgangen fra en blir inngangen til neste beholder i rekkefølge. Dette er en ideell brukssituasjon hvis du for eksempel har en flertrinns prediksjonspipeline der en Scikit-learn-modell brukes for en mellomprediksjon og resultatet mates til en TensorFlow-modell for endelig slutning. I stedet for å ha dem utplassert som forskjellige endepunkter og en annen applikasjon eller jobb som orkestrerer dem og foretar flere API-kall, kan du distribuere dem som en SageMaker MCE, abstrahere logikken og sette dem opp for seriell påkalling, der SageMaker administrerer dataoverføringen mellom én beholder automatisk til en annen og sender utdata fra den endelige beholderen til klienten som sender API-forespørselen.

SageMaker MCE-serieanrop er fundamentalt forskjellig fra en SageMaker serie-inferens-pipeline (mer detaljer i avsnittene nedenfor). En serieslutningspipeline er mer målrettet for å orkestrere komplekse ML-arbeidsflyter som dataforbehandling, bygge et modellensemble, implementere betingede kontroller for å bestemme hvilken modell som skal påkalles, eller etterbehandle prediksjonen, som involverer forretningslogikk før prediksjonen sendes ut til nedstrømsapplikasjonene . Derimot er MCE seriell invokasjon designet for å sy 2–14 modeller inn i en pipeline for slutning, hver modell tar prediksjonen til den forrige modellen som input.

Alle beholderne i en MCE er alltid i drift og i minnet, så det er ingen kaldstart mens du påkaller endepunktet. MCE-er forbedrer også endepunktutnyttelsen og forbedrer kostnadene fordi modeller er distribuert bak ett endepunkt og deler den underliggende beregningsforekomsten, i stedet for at hver modell opptar individuelle beregningsressurser.

La oss se på noen få brukstilfeller og se hvordan du kan bruke SageMaker MCE-er for å optimalisere ML-slutninger.

Brukssaker for SageMaker MCE-er

Anta at du har to modeller for sentimentklassifisering, en for engelsk og en annen for tysk, og disse modellene betjener forskjellige geografier med trafikk som kommer inn til forskjellige tider på en dag. I stedet for å ha to endepunkter som kjører 24/7, kan du distribuere dem begge til ett endepunkt ved hjelp av en MCE og få tilgang til dem ved å bruke direkte påkalling, og dermed optimalisere ressursutnyttelsen og kostnadene. 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 eksemplet har vi to modeller (englishModel og germanModel), og vi definerer beholderne i SageMaker create_model konstruere og definere InferenceExecutionConfig som 'Direkte'. Nå kan vi kalle endepunktet for slutning og definere TargetContainerHostname som enten englishModel or germanModel avhengig av klienten som foretar API-kallet:

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

Du kan også bruke direkte påkalling i MCE for å kjøre A/B-tester for å sammenligne ytelsen mellom modellene.

Følgende diagram illustrerer arkitekturen vår.

Tilsvarende, i andre ML-brukstilfeller, når den trente modellen brukes til å behandle en forespørsel, mottar modellen data i et format som må forhåndsbehandles (for eksempel funksjoner) før de kan overføres til algoritmen for slutning. Når ML-algoritmer er lenket sammen, fungerer utdataene fra en modell som input for den neste før den når det endelige resultatet. I dette tilfellet kan du bygge en SageMaker MCE seriell rørledning, hvor beholderne snakker med hverandre i rekkefølgen som er definert i create_model konstruer i stedet for at du distribuerer hver av modellene til forskjellige endepunkter og skriver en uavhengig logikk for å lette dataflyten mellom alle disse modellene og API-kall. Følgende diagram illustrerer denne arkitekturen.

For denne brukssaken bruker 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 eksemplet har vi to behandlingsbeholdere (Processing-1 og Processing-2) for funksjonsbehandling og datatransformasjoner, og to slutningsbeholdere (Inference-1 og Inference-2) for å kjøre ML-modellprediksjoner på de forhåndsbehandlede dataene. De PipelineModel instans lar deg definere inferensrørledningen som består av en lineær sekvens av fire beholdere som behandler forespørsler om inferens på data. Beholderne er samlokalisert på samme instans, slik at du kan kjøre inferens med lav latenstid.

Skaler endepunkter for flere modeller for et stort antall modeller

Fordelene med SageMaker multi-modell endepunkter øker basert på omfanget av modellkonsolidering. Du kan se kostnadsbesparelser når du er vert for to modeller med ett endepunkt, og for brukstilfeller med hundrevis eller tusenvis av modeller er besparelsene mye større.

Det er også enkelt å skalere MCE-endepunktene ved å bruke SageMakerVariantInvocationsPerInstance forhåndsdefinert beregning, som gir gjennomsnittlig antall ganger per minutt hver forekomst for et modellendepunkt påkalles for å definere en TargetScaling Politikk. SageMaker justerer dynamisk antall forekomster som er klargjort for en modell som svar på endringer i arbeidsmengden din. Når arbeidsmengden øker, bringer autoskalering flere forekomster online og laster med målmodellene og beholderne for å fortsette å betjene forespørslene. Når arbeidsmengden reduseres, fjerner autoskalering unødvendige forekomster og laster av modellbeholderne slik at containerne ikke spiser opp ressursene, og du betaler ikke for forekomster du ikke bruker. Tiden for å fullføre den første forespørselen mot en gitt modell opplever ytterligere latens (kalt en kaldstart) for å laste ned modellen fra Amazon enkel lagringstjeneste (Amazon S3) og last den inn i minnet. Påfølgende samtaler avsluttes uten ekstra kostnader fordi modellen allerede er lastet. 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
    }
)

Etter den foregående policykonfigurasjonen bruker vi SageMakerVariantInvocationsPerInstance forhåndsdefinert beregning for å justere antall variantforekomster slik at hver forekomst har en InvocationsPerInstance metrikk på 70.

Vi kan også skalere SageMaker MCEer basert på vår egen tilpassede metrikk, som f.eks CPUUtilization, MemoryUtilization, GPUUtilization, GPUMemoryUtilizationeller DiskUtilization, for å skalere opp eller ned antall forekomster basert på bruk av en spesifikk ressurs. For mer informasjon, se Skala Amazon SageMaker-modeller automatisk.

Det anbefales at modellen i hver beholder viser lignende beregnings- og latenskrav for hver slutningsforespørsel, fordi hvis trafikk til MCE skifter fra en modell med høy CPU-utnyttelse til en modell med lav CPU-bruk, men det totale samtalevolumet forblir det samme, vil endepunktet skalerer ikke ut, og det kan hende det ikke er nok forekomster til å håndtere alle forespørslene til modellen med høy CPU-utnyttelse.

Sikre MCE-er

For MCE-er med direkte påkalling vert flere beholdere i en enkelt forekomst ved å dele minne og et lagringsvolum. Det er viktig å sikre beholderne, opprettholde riktig tilordning av forespørsler til målbeholdere og gi brukere riktig tilgang til målbeholdere. Du kan begrense invoke_endpoint tilgang til et begrenset sett med beholdere inne i en MCE ved å bruke sagemaker:TargetContainerHostname AWS identitets- og tilgangsadministrasjon (IAM) tilstandsnøkkel. SageMaker bruker IAM-roller å gi IAM-identitetsbaserte retningslinjer som du bruker for å spesifisere tillatte eller nektede handlinger og ressurser og betingelsene for hvilke handlinger er tillatt eller nektet. Følgende retningslinjer viser hvordan du begrenser anrop til bestemte beholdere innenfor et endepunkt:

{
    "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åk endepunkter med flere modeller ved hjelp av Amazon CloudWatch-beregninger

For å avveie pris og ytelse, bør du teste endepunkter for flere modeller med modeller og representativ trafikk fra din egen applikasjon. SageMaker gir ytterligere beregninger i Amazon CloudWatch for endepunkter med flere modeller, slik at du kan bestemme endepunktbruken og hurtigbufferens trefffrekvens og optimalisere endepunktet. Beregningene er som følger:

• ModelLoadingWaitTime – Tidsintervallet som en påkallingsforespørsel venter på at målmodellen skal lastes ned eller lastes for å utføre slutningen.
• ModellUtlastingstid – Tidsintervallet det tar å losse modellen gjennom containerens UnloadModel API-anrop.
• Modellnedlastingstid – Tidsintervallet det tar å laste ned modellen fra Amazon S3.
• ModelLoadingTime – Tidsintervallet det tar å laste modellen gjennom beholderens LoadModel API-anrop.
• ModelCacheHit - Antall InvokeEndpoint forespørsler sendt til endepunktet der modellen allerede var lastet inn. Tar Average statistikk viser forholdet mellom forespørsler der modellen allerede var lastet inn.
• LoadedModelCount – Antall modeller lastet i containerne i endepunktet. Denne beregningen sendes ut per forekomst. De Average statistikk med en periode på 1 minutt forteller deg gjennomsnittlig antall modeller lastet per forekomst, og Sum statistikk forteller deg det totale antallet modeller som er lastet på tvers av alle forekomster i endepunktet. Modellene som denne metrikken sporer, er ikke nødvendigvis unike fordi du kan laste en modell i flere beholdere i endepunktet.

Det er også flere andre beregninger som brukes av hver beholder som kjører på en forekomst, for eksempel Invocations angir antall InvokeEndpoint forespørsler sendt til en beholder inne i et endepunkt, ContainerLatency gi tiden et endepunkt tok for målbeholderen eller alle beholderne i en seriell påkalling til å svare som sett fra SageMaker, og CPUUtilization og MemoryUtilizaton som indikerer CPU-enhetene og prosentandelen av minnet.

konklusjonen

I innlegget diskuterte vi hvordan SageMaker multi-container-endepunkter kan være nyttige for å optimalisere kostnader og ressursutnyttelse. Eksempler på når man skal bruke MCE-er inkluderer, men er ikke begrenset til, følgende:

• Hosting av modeller på tvers av forskjellige rammeverk (som TensorFlow, PyTorch og Scikit-learn) som ikke har tilstrekkelig trafikk til å mette hele kapasiteten til en forekomst
• Hosting av modeller fra samme rammeverk med forskjellige ML-algoritmer (som anbefalinger, prognoser eller klassifisering) og behandlerfunksjoner
• Sammenligninger av lignende arkitekturer som kjører på forskjellige rammeverkversjoner (som TensorFlow 1.x vs. TensorFlow 2.x) for scenarier som A/B-testing

SageMaker MCE-er støtter distribusjon av opptil 15 containere på sanntidsendepunkter og påkaller dem uavhengig for slutning med lav latens og kostnadsbesparelser. Modellene kan være helt heterogene, med sin egen uavhengige serveringsstabel. Du kan enten påkalle disse beholderne sekvensielt eller uavhengig for hver forespørsel. Sikker hosting av flere modeller, fra forskjellige rammeverk, på en enkelt forekomst kan spare deg for opptil 90 % i kostnader sammenlignet med hosting av modeller i dedikerte enkeltforekomstendepunkter.

Om forfatterne

Dhawal Patel er en hovedmaskinlæringsarkitekt ved AWS. Han har jobbet med organisasjoner som spenner fra store bedrifter til mellomstore startups med problemer knyttet til distribuert databehandling og kunstig intelligens. Han fokuserer på dyp læring, inkludert NLP og datasynsdomener. Han hjelper kunder med å oppnå høyytelsesmodellslutning på Amazon SageMaker.

Vikram Elango er senior AI/ML spesialistløsningsarkitekt hos Amazon Web Services, basert i Virginia, USA. Vikram hjelper globale finans- og forsikringsindustrikunder med design og tankeledelse med å bygge og distribuere maskinlæringsapplikasjoner i stor skala. Han er for tiden fokusert på naturlig språkbehandling, ansvarlig AI, inferensoptimalisering og skalering av ML på tvers av bedriften. På fritiden liker han å reise, gå fotturer, lage mat og campe med familien.

Saurabh Trikande er senior produktsjef for Amazon SageMaker Inference. Han brenner for å jobbe med kunder og er motivert av målet om å demokratisere maskinlæring. Han fokuserer på kjerneutfordringer knyttet til distribusjon av komplekse ML-applikasjoner, multi-tenant ML-modeller, kostnadsoptimaliseringer og å gjøre distribusjon av dyplæringsmodeller mer tilgjengelig. På fritiden liker Saurabh å gå tur, lære om innovative teknologier, følge TechCrunch og tilbringe tid med familien.