Komme i gang med å distribuere sanntidsmodeller på Amazon SageMaker

Amazon SageMaker er en fullstendig administrert tjeneste som gir alle utviklere og dataforskere muligheten til raskt å bygge, trene og distribuere maskinlæringsmodeller (ML) i stor skala. ML er realisert i slutning. SageMaker tilbyr fire inferensalternativer:

1. Sanntidsslutning
2. Serverløs slutning
3. Asynkron inferens
4. Batch Transform

Disse fire alternativene kan grovt klassifiseres i alternativer for online- og batchslutninger. I Online Inference forventes forespørsler å bli behandlet etter hvert som de ankommer, og den forbrukende applikasjonen forventer et svar etter at hver forespørsel er behandlet. Dette kan enten skje synkront (inferens i sanntid, serverløs) eller asynkront (asynkron inferens). I et synkront mønster er den forbrukende applikasjonen blokkert og kan ikke fortsette før den mottar et svar. Disse arbeidsbelastningene har en tendens til å være sanntidsapplikasjoner, for eksempel oppdagelse av kredittkortsvindel online, der svar forventes i størrelsesorden millisekunder til sekunder og forespørselsnyttelastene er små (noen få MB). I det asynkrone mønsteret er ikke applikasjonsopplevelsen blokkert (for eksempel ved å sende inn et forsikringskrav via en mobilapp), og krever vanligvis større nyttelaststørrelser og/eller lengre behandlingstider. I frakoblet slutning behandles en aggregering (batch) av slutningsforespørsler sammen, og svar gis først etter at hele partiet er behandlet. Vanligvis er disse arbeidsbelastningene ikke latenssensitive, involverer store volumer (flere GB) med data, og er planlagt til en vanlig tråkkfrekvens (for eksempel kjøre objektgjenkjenning på opptak fra sikkerhetskamera på slutten av dagen eller behandle lønnsdata ved slutten av måneden).

Ved bare bein, SageMaker sanntidsslutning består av en(e) modell(er), rammeverket/beholderen du jobber med, og infrastrukturen/instansene som støtter det distribuerte endepunktet ditt. I dette innlegget skal vi utforske hvordan du kan opprette og påkalle et enkelt modellendepunkt.

Valg av modelldistribusjonsalternativ

Det kan være vanskelig å velge riktig slutningstype, og følgende enkle veiledning kan hjelpe deg. Det er ikke et strengt flytskjema, så hvis du finner ut at et annet alternativ fungerer bedre for deg, kan du gjerne bruke dem. Spesielt er Real-Time Inference et flott alternativ for å være vert for modellene dine når du har lav og konsistent ventetid (i størrelsesorden millisekunder eller sekunder) og gjennomstrømningssensitive arbeidsbelastninger. Du kan kontrollere forekomsttypen og telle bak endepunktet ditt mens du også konfigurerer AutoScaling politikk for å håndtere trafikk. Det er to andre SageMaker Inference-alternativer som du også kan bruke til å lage et endepunkt. Asynkron inferens er når du har store nyttelaststørrelser og båndbredde tilnærmet sanntid. Dette er et godt alternativ, spesielt for NLP- og Computer Vision-modeller som har lengre forbehandlingstider. Serverless Inference er et flott alternativ når du har intermitterende trafikk og ikke ønsker å administrere infrastrukturskalering. Oppskriften for å lage et endepunkt forblir den samme uavhengig av slutningstypen du velger. I dette innlegget vil vi fokusere på å lage et instansbasert endepunkt i sanntid, men du kan enkelt tilpasse det til et av de andre slutningsalternativene basert på din brukssituasjon. Til slutt, Batch-inferens foregår offline, slik at du kan gi et sett med data som du ønsker å få slutning fra, og vi kjører det. Dette er på samme måte forekomstbasert, så du kan velge den optimale forekomsten for arbeidsmengden din. Siden det ikke er noe endepunkt i gang, betaler du kun for varigheten av jobben. Det er bra for å behandle gigabyte med data og jobbvarigheten kan være dager. Det er innebygde funksjoner som gjør arbeidet med strukturerte data enklere og optimaliseringer for automatisk distribusjon av strukturerte data. Noen eksempler på brukstilfeller er tilbøyelighetsmodellering, prediktivt vedlikehold og churn-prediksjon. Alle disse kan foregå offline i bulk fordi den ikke trenger å reagere på en bestemt hendelse.

Hosting av en modell på SageMaker Endpoints

I kjernen består SageMaker Real-Time Endpoints av en modell og infrastrukturen du velger å støtte endepunktet med. SageMaker bruker containere som vert for modeller, noe som betyr at du trenger en container som setter opp miljøet på riktig måte for rammeverket du bruker for hver modell du tilbyr. Hvis du for eksempel jobber med en Sklearn-modell, må du sende inn modellskriptene/dataene dine i en beholder som konfigurerer Sklearn på riktig måte. Heldigvis gir SageMaker administrerte bilder for populære rammeverk, som TensorFlow, PyTorch, Sklearn og HuggingFace. Du kan hente og bruke disse bildene ved å bruke høynivået SageMaker Python SDK og injiser modellskriptene og dataene dine i disse beholderne. I tilfelle SageMaker ikke har en støttet beholder, kan du også Bygg din egen container og push ditt eget tilpassede bilde, installer avhengighetene som er nødvendige for modellen din.

SageMaker støtter både trente og forhåndstrente modeller. I forrige avsnitt når vi snakker om modellskript/data, refererer vi til denne saken. Du kan enten montere et skript på beholderen din, eller hvis du har en forhåndstrent modellartefakt (for eksempel `model.joblib` for SKLearn), så kan du gi dette sammen med bildet ditt til SageMaker. For å forstå SageMaker Inference, er det tre hovedenheter du oppretter i prosessen med å lage endepunkt:

1. SageMaker Model Entity – Her kan du sende inn dine trente modelldata/modellskript og bildet du jobber med, enten det eies av AWS eller er bygget av deg.
2. Oppretting av endepunktkonfigurasjon – Her definerer du infrastrukturen din, noe som betyr at du velger forekomsttype, antall osv.
3. Oppretting av endepunkt – Dette er REST-endepunktet som er vert for modellen din som du påkaller for å få svar. La oss se på hvordan du kan bruke et administrert SageMaker-bilde og ditt eget spesialbygde bilde for å distribuere et endepunkt.

Krav til endepunkt i sanntid

1. Før du oppretter et endepunkt, må du forstå hvilken type modell du vil være vert for. Hvis det er en rammemodell, for eksempel TensorFlow, PyTorch eller MXNet, kan du bruke en av forhåndsbygde rammebilder.
   Hvis det er en tilpasset modell, eller du ønsker full fleksibilitet i å lage beholderen som SageMaker vil kjøre for slutning, kan du bygge din egen beholder.

SageMaker endepunkter består av en SageMaker modell og Sluttpunktkonfigurasjon.
Hvis du bruker Boto3, vil du lage begge objektene. Ellers, hvis du bruker SageMaker Python SDK, opprettes endepunktkonfigurasjonen på dine vegne når du bruker .deploy(..) funksjon.

SageMaker-enheter:

• SageMaker modell:
  • Inneholder detaljene til slutningsbildet, plassering av modellartefakter i Amazon Simple Storage Service (Amazon S3), nettverkskonfigurasjon, og AWS Identity and Access Management (IAM) rolle som skal brukes av endepunktet.
    • SageMaker krever at modellartefakter komprimeres i en .tar.gz fil. SageMaker trekker ut dette automatisk .tar.gz filen inn i /opt/ml/model/ katalogen i beholderen din. Hvis du bruker en av rammebeholderne, for eksempel TensorFlow, PyTorch eller MXNet, forventer beholderen at TAR-strukturen din er som følger:
      • tensorflow
        

        model.tar.gz/
        |--[model_version_number]/
        |--variables
        |--saved_model.pb
        code/
        |--inference.py
        |--requirements.txt

      • PyTorch
        

        model.tar.gz/
        |- model.pth
        |- code/
        |- inference.py
        |- requirements.txt # only for versions 1.3.1 and higher

      • MX Nett
        

        model.tar.gz/
        |- model-symbol.json
        |- model-shapes.json
        |- model-0000.params
        |- code/
            |- inference.py
            |- requirements.txt # only for versions 1.6.0 and higher

      • Sklearn
        

        model.tar.gz/
        |- model.joblib
        | code/ 
        |- inference.py

    • Når vi bruker et Framework-bilde, kan vi tilby et tilpasset inngangspunktskript, der vi kan implementere vår egen pre- og etterbehandling. I vårt tilfelle er inferensskriptet pakket i model.tar.gz under /code-katalogen.

• • Sluttpunktkonfigurasjon
    • Inneholder infrastrukturinformasjonen som kreves for å distribuere SageMaker-modellen til endepunktet.
    • For eksempel spesifiseres SageMaker-modellen vi opprettet her, i tillegg til antall forekomster og forekomster.

Frameworks og BYOC

• • Henter SageMaker-bilder
    • Denne delen er ikke alltid nødvendig og abstrahert av SageMaker Python SDK via estimatorer. Men hvis du ønsker å kunne hente et SageMaker administrert bilde for å utvide på det, så kan du få bildene som er tilgjengelige via SDK. Følgende er et eksempel på å hente et TF 2.2-bilde for slutning.

      import sagemaker
      tf_image = sagemaker.image_uris.retreive(framework="tensorflow", region="us-east-1",
      image_scope = "inference", version = "2.2", instance_type = "ml.c5.xlarge)
      print(tf_image)

  • rammer
    • I tilfelle du vil distribuere en rammemodell, for eksempel TensorFlow, PyTorch eller MXNet, trenger du bare modellartefaktene.
    • Se dokumentasjonen for distribusjon av modeller direkte fra modellartefakter for tensorflow, PyTorcheller MX Nett.

• • Velg mellom 1P og BYOC
    • SageMaker SDK abstraherer også håndtering av bildet, som du så i forrige Frameworks-seksjon. Den har ferdige estimatorer for Sklearn, TensorFlow og PyTorch som automatisk velger bildet for deg basert på versjonen du har valgt. Deretter kan du sende inn et opplærings-/slutningsmanus gjennom Skriptmodus inn i disse estimatorene.

      from sagemaker.pytorch import PyTorch #PyTorch Estimator within SageMaker SDK
      estimator_parameters = {"entry_point": "train_deploy_pytorch_without_dependencies.py",
      "source_dir": "pytorch_script","instance_type": train_instance_type,
      "instance_count": 1,"hyperparameters": hyperparameters,
      "role": role,"base_job_name": "pytorch-model","framework_version": "1.5",
      "py_version": "py3",}
      
      ## Model Training
      estimator = PyTorch(**estimator_parameters)estimator.fit(inputs)
      
      ## Deploy Trained model
      pytorch_predictor = estimator.deploy(initial_instance_count=1, instance_type="ml.m5.xlarge", endpoint_name=pytorch_endpoint_name)

    • Ikke alle pakker og bilder støttes av SageMaker, og i dette tilfellet må du ta med din egen container (BYOC). Dette betyr å bygge en Dockerfile som vil sette opp det riktige miljøet for modellserveringen din. Et eksempel på dette er Spacy NLP-modulen, og det er ingen administrerte SageMaker-beholdere for dette rammeverket. Derfor må du oppgi en Dockerfile som installerer Spacy. Inne i beholderen monterer du også modellinferensskriptene dine. La oss raskt diskutere komponentene du leverer i et Bring Your Own Container-format, da disse forblir konsekvente for de fleste eksempler.
      • «nginx.conf» er konfigurasjonsfilen for nginx-grensesnittet. Du trenger ikke å redigere denne filen, med mindre du ønsker å finjustere disse delene.
      • «predictor.py» er programmet som faktisk implementerer Flask-webserveren og modellkoden for applikasjonen din. Du kan ha flere Python-filer eller funksjoner i beholderen din som du kan kalle inn denne filen.
      • "tjene" er programmet startet når containeren startes for hosting. Den starter ganske enkelt gunicorn-serveren, som kjører flere forekomster av Flask-appen definert i predictor.py. Som nginx.conf, trenger du ikke å redigere denne filen med mindre det er ytterligere tuning du ønsker å utføre.
      • "tog" er programmet som startes når containeren kjøres for trening. Du vil endre dette programmet for å implementere treningsalgoritmen din. Hvis du tar med en forhåndsopplært modell eller rammeverk som Spacy, trenger du ikke denne filen.
      • "wsgi.py" er en liten innpakning som brukes til å starte Flask-appen. Du bør kunne ta denne filen som den er, med mindre du har endret navnet på filen predictor.py. I så fall må du sørge for at kartene er riktige her.

• • Egendefinert slutningsskript
    • SageMaker Framework-beholdere gir deg fleksibiliteten til å håndtere pre/post-behandling av forespørselen og modelllasting ved hjelp av et tilpasset inngangspunktscript/inference.py.
    • Se dokumentasjonen for å lage et tilpasset inference.py-skript for tensorflow, PyTorch og MX Nett.
  • Egendefinert beholder

Ulike måter du kan samhandle med SageMaker Endpoints på

Det er mange alternativer for å bruke SageMaker programmatisk, slik at du kan ringe de distribuerte modellene dine for å få slutninger. De AWS Command Line Interface (AWS CLI), REST APIer, AWS skyformasjon, AWS Cloud Development Kit (AWS CDK), og AWS SDK-er er vanlige verktøy som tilbys av AWS og støttes bredt av andre AWS-tjenester. For SageMaker har vi også en SageMaker Python SDK. La oss nå sammenligne de forskjellige alternativene for å opprette, påkalle og administrere SageMaker-endepunkter.

I tillegg til SageMaker CLI, er det to måter programmatisk du kan samhandle med Endpoints i SageMaker gjennom SDK-ene. La oss se på noen forskjeller mellom SageMaker Python SDK og Boto3 Python SDK:

1. Høynivå SageMaker "Python" SDK - Denne SDK er et åpen kildekode-bibliotek som gir høyere nivå abstraksjon spesielt ment for å kalle SageMaker APIer programmatisk ved hjelp av Python. Den gode delen av denne SDK-en er at det er veldig enkelt å kalle Sagemaker APIer, mange tunge løft er gjort allerede som å kalle APIene synkront/asynkronmodus (hjelper til å unngå polling), enklere forespørsel/svarskjema, mye mindre kode og mye enklere kode. SageMaker Python SDK gir flere abstraksjoner på høyt nivå for å jobbe med SageMaker. Pakken er ment å forenkle ulike ML-prosesser på SageMaker.
2. Lavnivå AWS SDK (Boto3 SDK) – Denne SDK fungerer på lavere nivå ved å la brukeren velge mellom de støttede programmeringsspråkene og ringe alle AWS-tjenester programmatisk. Dette er ikke bare spesifikt for SageMaker, men kan brukes generelt for alle AWS-tjenester. AWS SDK-ene på lavt nivå er tilgjengelige i ulike programmeringsspråk, som .NET, Python, Java, Node.js, etc. En av de populære SDK-ene som brukes er boto3 python SDK, som er populær i dataforskermiljøet for ML. Den gode delen av denne SDK er at den er veldig lett og tilgjengelig som standard installert på AWS Lambda Kjøretid. Videre kan du bruke denne SDK-en til å samhandle med alle AWS-tjenester utenfor SageMaker.

Begge disse SDK-ene kan brukes til de samme oppgavene, men i noen tilfeller er det mer intuitivt å bruke den ene mer enn den andre. SageMaker Python SDK anbefales for enkel testing, mens AWS SDK/Boto3 anbefales for produksjonsbruk for bedre kontroll på ytelsen. For eksempel gir SageMaker som en tjeneste forhåndsbygde og vedlikeholdte bilder for populære rammeverk, som Sklearn, PyTorch og TensorFlow. Det kan være spesielt nyttig å bruke SageMaker SDK for å hente dyplæringsbilder, trene modeller ved hjelp av estimatorer, og enkelt distribuere modellen ved hjelp av et enkelt API-kall. Et eksempel for å vise dette i aksjon kan bli funnet her..

På den annen side, noen ganger har du forhåndstrente modeller eller forskjellige rammeverk som du kanskje bruker. Dette krever en større grad av tilpasning, og SageMaker SDK tilbyr ikke alltid det. Vi har tre viktige trinn og tilsvarende boto3 API-kall som vi må utføre for å distribuere et endepunkt: Modellskaping, Oppretting av endepunktkonfigurasjonog Oppretting av endepunkt. De to første enhetene ble abstrahert med SageMaker SDK med våre støttede rammeverk, men vi ser disse detaljene med Boto3 SDK. Du finner et omfattende eksempel for å vise frem trinnene som er involvert i bruk av en Boto3 SDK for å opprette og administrere et endepunkt her..

Hensyn til SageMaker-hosting

SageMaker Real-Time Inference har to hovedoptimaliseringer som du kan vurdere: 1/ Ytelsesoptimalisering og 2/ Kostnadsoptimalisering. La oss først se på ytelsesoptimalisering, som når vi har å gjøre med latenssensitive arbeidsbelastninger, er hvert millisekund avgjørende. Det er forskjellige knotter du kan justere for å optimalisere latens og gjennomstrømning. På instansnivå kan du bruke Inferensanbefaling, vårt innebygde belastningstestverktøy, for å hjelpe deg med å velge riktig forekomsttype og telle for arbeidsmengden din. Å bruke riktig kombinasjon av databehandling vil hjelpe deg med både ytelse og kostnad. Du kan også stille inn på beholder- og rammenivå.
Spørsmål å stille deg selv inkluderer:

1. Hvilket rammeverk bruker du?
2. Er det noen miljøvariabler du kan justere i beholderen din?

Et eksempel på dette er maksimering TensorFlow-ytelse med SageMaker-beholdere. Et annet eksempel på beholdernivåoptimalisering er ved å bruke gRPC heller enn REST bak endepunktet ditt. Til slutt kan du også optimalisere på skriptnivå. Tar slutningskoden din ekstra tid ved visse blokker? Timing av hver eneste linje i skriptet ditt vil hjelpe deg med å fange opp eventuelle flaskehalser i koden din.

Det er tre måter å se på å forbedre utnyttelsen av ditt sanntidsendepunkt:

1. Multi-model Endpoints (MME)
   • Du kan være vert for tusenvis av modeller bak ett enkelt endepunkt. Dette er perfekt for brukstilfeller der du ikke trenger et dedikert endepunkt for hver av modellene dine. MME fungerer best når modellene har samme størrelse og forsinkelse og tilhører samme ML-rammeverk. Disse kan vanligvis brukes når du ikke trenger å ringe samme modell til enhver tid. Du kan dynamisk laste den respektive modellen inn på SageMaker Endpoint for å betjene forespørselen din. Du finner et eksempel som viser MME i aksjon her.. Hvis du vil lære mer om de forskjellige forbeholdene og beste praksis for hosting av modeller på MME, kan du se innlegget her..
2. Multi-Container Endpoints (MCE)
   • I stedet for å bruke flere endepunkter for å være vert for flere beholdere, kan du se på å være vert for opptil 15 beholdere på ett enkelt endepunkt. Hver av disse beholderne kan påkalles direkte. Derfor kan du se på å være vert for forskjellige modeller av forskjellige rammeverk, alt på ett enkelt endepunkt. Dette alternativet er best når beholdere har lignende bruks- og ytelsesegenskaper. Et eksempel som viser MCE kan bli funnet her.. Hvis du vil lære mer om de forskjellige forbeholdene og beste praksis for hosting av modeller på MCE, kan du se innlegget her..
3. Serial Inference Pipeline (SIP)
   • Hvis du har en pipeline med trinn i inferenslogikken din, kan du bruke Serial Inference Pipeline (SIP). SIP lar deg lenke 2-15 beholdere sammen bak ett enkelt endepunkt. SIP fungerer bra når du har for- og etterbehandlingstrinn. Hvis du vil lære mer om designmønstrene for serielle inferensrørledninger, kan du se innlegget her..

Den andre viktigste optimaliseringen å huske på er koste. Real-Time Inference er ett av tre alternativer for å lage SageMaker Endpoints. SageMaker Endpoints kjører til enhver tid med mindre de slettes. Derfor må du se på å forbedre utnyttelsen av endepunktet som igjen gir en kostnadsgevinst.

SageMaker tilbyr også spareplaner. Spareplaner kan redusere kostnadene dine med opptil 64 %. Dette er en 1- eller 3-årig forpliktelse til en konsistent mengde bruk ($/time). Se dette link for mer informasjon. Og se dette link for best å optimalisere kostnadene for Inference på Amazon SageMaker.

konklusjonen

I dette innlegget viste vi deg noen av de beste fremgangsmåtene for å velge mellom ulike vertsalternativer for modeller på SageMaker. Vi diskuterte SageMaker Endpoint-kravene, og kontrasterte også Framework- og BYOC-krav og funksjonalitet. Videre snakket vi om de forskjellige måtene du kan utnytte sanntidsendepunkter for å være vert for ML-modellene dine i produksjon. på en kostnadseffektiv måte, og har høy ytelse.

Se tilsvarende GitHub repository og prøv ut eksemplene.

---

Om forfatterne

Raghu Ramesha er en ML Solutions Architect med Amazon SageMaker Service-teamet. Han fokuserer på å hjelpe kunder med å bygge, distribuere og migrere ML-produksjonsarbeidsmengder til SageMaker i stor skala. Han spesialiserer seg på maskinlæring, AI og datasynsdomener, og har en mastergrad i informatikk fra UT Dallas. På fritiden liker han å reise og fotografere.

Ram Vegiraju er en ML-arkitekt med SageMaker Service-teamet. Han fokuserer på å hjelpe kunder med å bygge og optimalisere sine AI/ML-løsninger på Amazon SageMaker. På fritiden elsker han å reise og skrive.

Marc Karp er en ML-arkitekt med SageMaker Service-teamet. Han fokuserer på å hjelpe kunder med å designe, distribuere og administrere ML-arbeidsmengder i stor skala. På fritiden liker han å reise og utforske nye steder.

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.

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.