Kom godt i gang med at implementere realtidsmodeller på Amazon SageMaker

Amazon SageMaker er en fuldt administreret tjeneste, der giver enhver udvikler og dataforsker mulighed for hurtigt at bygge, træne og implementere maskinlæringsmodeller (ML) i stor skala. ML realiseres i inferens. SageMaker tilbyder fire Inference muligheder:

1. Realtidsslutning
2. Serverløs slutning
3. Asynkron inferens
4. Batch transformation

Disse fire muligheder kan bredt klassificeres i online- og batch-inferensmuligheder. I Online Inference forventes anmodninger at blive behandlet, efterhånden som de ankommer, og den forbrugende applikation forventer et svar efter hver anmodning er behandlet. Dette kan enten ske synkront (realtidsinferens, serverløs) eller asynkront (asynkron inferens). I et synkront mønster er den forbrugende applikation blokeret og kan ikke fortsætte, før den modtager et svar. Disse arbejdsbelastninger har en tendens til at være realtidsapplikationer, såsom online registrering af kreditkortsvindel, hvor svar forventes i størrelsesordenen millisekunder til sekunder og anmodningsnyttelast er lille (nogle få MB). I det asynkrone mønster er applikationsoplevelsen ikke blokeret (for eksempel indsendelse af et forsikringskrav via en mobilapp), og det kræver normalt større nyttelaststørrelser og/eller længere behandlingstider. I Offline-inferens behandles en aggregering (batch) af slutningsanmodninger sammen, og svar gives kun, efter at hele batchen er blevet behandlet. Normalt er disse arbejdsbelastninger ikke forsinkelsesfølsomme, involverer store mængder (flere GB'er) af data og er planlagt til en regelmæssig kadence (kør f.eks. objektgenkendelse på optagelser fra sikkerhedskameraer sidst på dagen eller behandle løndata ved slutningen af ​​måneden).

Ved de bare knogler, SageMaker Real-Time Inference består af en(e) model(er), rammen/beholderen, som du arbejder med, og infrastrukturen/instanserne, der understøtter dit implementerede slutpunkt. I dette indlæg vil vi undersøge, hvordan du kan oprette og påberåbe et enkelt modelslutpunkt.

Valg af modelimplementeringsmulighed

Det kan være svært at vælge den rigtige inferenstype, og den følgende enkle guide kan hjælpe dig. Det er ikke et strengt flowdiagram, så hvis du opdager, at en anden mulighed fungerer bedre for dig, så er du velkommen til at bruge dem. Især Real-Time Inference er en fantastisk mulighed for at hoste dine modeller, når du har lav og konsekvent latency (i størrelsesordenen millisekunder eller sekunder) og gennemløbsfølsomme arbejdsbelastninger. Du kan styre instanstypen og tælle bag dit slutpunkt, mens du også konfigurerer AutoScaling politik for at håndtere trafikken. Der er to andre SageMaker Inference muligheder, som du også kan bruge til at oprette et slutpunkt. Asynkron inferens er, når du har store nyttelaststørrelser og båndbredde næsten i realtid. Dette er en god mulighed, især for NLP- og Computer Vision-modeller, der har længere forbehandlingstider. Serverløs inferens er en fantastisk mulighed, når du har intermitterende trafik og ikke ønsker at administrere infrastrukturskalering. Opskriften på oprettelse af et slutpunkt forbliver den samme, uanset hvilken slutningstype du vælger. I dette indlæg vil vi fokusere på at skabe et instansbaseret slutpunkt i realtid, men du kan nemt tilpasse det til en af ​​de andre inferensindstillinger baseret på din use-case. Til sidst foregår Batch-inferens offline, så du kan levere et sæt data, som du ønsker at få slutninger fra, og vi kører det. Dette er på samme måde instansbaseret, så du kan vælge den optimale instans til din arbejdsbyrde. Da der ikke er noget endepunkt i gang, betaler du kun for varigheden af ​​jobbet. Det er godt til at behandle gigabyte data, og jobbets varighed kan være dage. Der er indbyggede funktioner til at gøre arbejdet med strukturerede data nemmere og optimeringer til automatisk at distribuere strukturerede data. Nogle eksempler på brugssager er tilbøjelighedsmodellering, prædiktiv vedligeholdelse og churn-forudsigelse. Alle disse kan finde sted offline i bulk, fordi det ikke behøver at reagere på en bestemt begivenhed.

Hosting af en model på SageMaker Endpoints

I kernen består SageMaker Real-Time Endpoints af en model og den infrastruktur, som du vælger at støtte Endpointet med. SageMaker bruger containere til at hoste modeller, hvilket betyder, at du har brug for en container, der korrekt sætter miljøet op til den ramme, du bruger for hver model, du leverer. Hvis du f.eks. arbejder med en Sklearn-model, skal du sende dine modelscripts/data ind i en container, der konfigurerer Sklearn korrekt. Heldigvis leverer SageMaker administrerede billeder til populære rammer, såsom TensorFlow, PyTorch, Sklearn og HuggingFace. Du kan hente og bruge disse billeder ved at bruge det høje niveau SageMaker Python SDK og injicer dine modelscripts og data i disse beholdere. I tilfælde af at SageMaker ikke har en understøttet container, kan du også Byg din egen container og skub dit eget brugerdefinerede billede, installer de afhængigheder, der er nødvendige for din model.

SageMaker understøtter både trænede og fortrænede modeller. I det foregående afsnit, når vi taler om modelscripts/data, refererer vi til denne sag. Du kan enten montere et script på din container, eller hvis du har en forudtrænet modelartefakt (f.eks. `model.joblib` for SKLearn), så kan du give dette sammen med dit billede til SageMaker. For at forstå SageMaker Inference er der tre hovedenheder, som du vil oprette i processen med oprettelse af Endpoint:

1. SageMaker Model Entity – Her kan du videregive dine trænede modeldata/modelscript og dit billede, som du arbejder med, uanset om det er ejet af AWS eller bygget af dig.
2. Oprettelse af endepunktskonfiguration – Her definerer du din infrastruktur, hvilket betyder, at du vælger instanstype, antal osv.
3. Oprettelse af slutpunkt – Dette er REST-endepunktet, der er vært for din model, som du påberåber dig for at få et svar. Lad os se på, hvordan du kan bruge et administreret SageMaker-billede og dit eget specialbyggede billede til at implementere et slutpunkt.

Krav til slutpunkt i realtid

1. Før du opretter et slutpunkt, skal du forstå, hvilken type model du vil være vært for. Hvis det er en rammemodel, såsom TensorFlow, PyTorch eller MXNet, så kan du bruge en af forudbyggede Framework-billeder.
   Hvis det er en brugerdefineret model, eller du gerne vil have fuld fleksibilitet i at skabe den container, som SageMaker vil køre for slutninger, så kan du bygge din egen container.

SageMaker-endepunkter består af en SageMaker model , Slutpunktskonfiguration.
Hvis du bruger Boto3, vil du oprette begge objekter. Ellers, hvis du bruger SageMaker Python SDK, oprettes endepunktskonfigurationen på dine vegne, når du bruger .deploy(..) funktion.

SageMaker-enheder:

• SageMaker model:
  • Indeholder detaljerne i inferensbilledet, placeringen af ​​modelartefakter i Amazon Simple Storage Service (Amazon S3), netværkskonfiguration, og AWS Identity and Access Management (IAM) rolle, der skal bruges af slutpunktet.
    • SageMaker kræver, at dine modelartefakter komprimeres i en .tar.gz fil. SageMaker udtrækker automatisk dette .tar.gz fil i /opt/ml/model/ mappe i din container. Hvis du bruger en af ​​rammebeholderne, såsom TensorFlow, PyTorch eller MXNet, forventer containeren, at din TAR-struktur 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 Net
        

        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 bruger et Framework-billede, kan vi levere et brugerdefineret indgangs-script, hvor vi kan implementere vores egen præ- og efterbehandling. I vores tilfælde er inferensscriptet pakket i model.tar.gz under mappen /code.

• • Slutpunktskonfiguration
    • Indeholder de infrastrukturoplysninger, der kræves for at implementere SageMaker-modellen til slutpunktet.
    • For eksempel er den SageMaker-model, vi har oprettet, specificeret her, såvel som forekomsttypen og antallet af initiale forekomster.

Frameworks og BYOC

• • Henter SageMaker-billeder
    • Denne del er ikke altid nødvendig og abstraheret af SageMaker Python SDK via estimatorer. Men hvis du gerne vil kunne hente et SageMaker-administreret billede til at udvide på det, så kan du få de billeder, der er tilgængelige via SDK. Det følgende er et eksempel på at hente et TF 2.2-billede til 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
    • Hvis du ønsker at implementere en rammemodel, såsom TensorFlow, PyTorch eller MXNet, er alt hvad du behøver, modelartefakterne.
    • Se dokumentationen for implementering af modeller direkte fra modelartefakter for TensorFlow, PyTorch eller MX Net.

• • Vælg mellem 1P og BYOC
    • SageMaker SDK abstraherer også håndteringen af ​​billedet, som du så i det forrige Frameworks-afsnit. Det har færdige estimatorer til Sklearn, TensorFlow og PyTorch, der automatisk vælger billedet for dig baseret på den version, du har valgt. Så kan du sende et trænings-/inferensmanuskript igennem Script-tilstand ind i disse estimatorer.

      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 billeder understøttes af SageMaker, og i dette tilfælde skal du medbring din egen container (BYOC). Dette betyder at bygge en Dockerfile, der opsætter det rigtige miljø til din modelservering. Et eksempel på dette er Spacy NLP-modulet, og der er ingen administrerede SageMaker-containere til denne ramme. Derfor skal du levere en Dockerfile, der installerer Spacy. Inden i beholderen monterer du også dine modelslutningsscripts. Lad os hurtigt diskutere de komponenter, du leverer i et Bring Your Own Container-format, da disse forbliver konsekvente i de fleste eksempler.
      • "nginx.conf" er konfigurationsfilen for nginx frontend. Du behøver ikke at redigere denne fil, medmindre du ønsker at justere disse dele.
      • "predictor.py" er det program, der rent faktisk implementerer Flask-webserveren og modelkoden til din applikation. Du kan have yderligere Python-filer eller funktioner i din container, som du kan kalde i denne fil.
      • "tjene" er programmet startet, når containeren startes til hosting. Den starter ganske enkelt gunicorn-serveren, som kører flere forekomster af Flask-appen defineret i predictor.py. Ligesom nginx.conf, behøver du ikke at redigere denne fil, medmindre der er yderligere tuning, som du gerne vil udføre.
      • "tog" er det program, der startes, når containeren køres til træning. Du vil ændre dette program for at implementere din træningsalgoritme. Hvis du medbringer en fortrænet model eller ramme som Spacy, behøver du ikke denne fil.
      • "wsgi.py" er en lille indpakning, der bruges til at starte Flask-appen. Du burde være i stand til at tage denne fil som den er, medmindre du har ændret navnet på din predictor.py fil. I så fald skal du sørge for at kortlægge korrekt her.

• • Brugerdefineret inferensscript
    • SageMaker Framework-containere giver dig fleksibiliteten til at håndtere før/efterbehandling af anmodningen og modelindlæsning ved hjælp af et brugerdefineret indgangs-script/inference.py.
    • Se dokumentationen for at oprette et brugerdefineret inference.py-script til TensorFlow, PyTorch , MX Net.
  • Brugerdefineret container

Forskellige måder, du kan interagere med SageMaker Endpoints på

Der er mange muligheder for at bruge SageMaker programmatisk, så du kan ringe til dine installerede modeller for at få slutninger. Det AWS Command Line Interface (AWS CLI), REST API'er, AWS CloudFormation, AWS Cloud Development Kit (AWS CDK), og AWS SDK'er er almindelige værktøjer, der tilbydes af AWS og bredt understøttet af andre AWS-tjenester. Til SageMaker har vi også en SageMaker Python SDK. Lad os nu sammenligne de forskellige muligheder for at oprette, påberåbe og administrere SageMaker-endepunkter.

Foruden SageMaker CLI, er der to måder programmatisk, hvorpå du kan interagere med Endpoints i SageMaker gennem SDK'erne. Lad os se på nogle forskelle mellem SageMaker Python SDK , Boto3 Python SDK:

1. SageMaker "Python" SDK på højt niveau - Dette SDK er et open source-bibliotek, der giver abstraktion på højere niveau, specifikt beregnet til at kalde SageMaker API'er programmatisk ved hjælp af Python. Den gode del af denne SDK er, at det er meget nemt at kalde sagemaker API'er, masser af tunge løft udføres allerede som at kalde API'erne synkront/async mode (hjælper med at undgå polling), enklere anmodning/svar skema, meget mindre kode og meget enklere kode. SageMaker Python SDK giver adskillige abstraktioner på højt niveau til at arbejde med SageMaker. Pakken er beregnet til at forenkle forskellige ML-processer på SageMaker.
2. Low-level AWS SDK (Boto3 SDK) – Denne SDK fungerer på det lavere niveau ved at give brugeren mulighed for at vælge mellem de understøttede programmeringssprog og kalde alle AWS-tjenester programmatisk. Dette er ikke kun specifikt for SageMaker, men kan bruges generelt til alle AWS-tjenester. AWS SDK'erne på lavt niveau er tilgængelige i forskellige programmeringssprog, såsom .NET, Python, Java, Node.js osv. Et af de populære SDK'er, der bruges, er boto3 python SDK, som er populært i dataforskermiljøet for ML. Den gode del af denne SDK er, at den er meget let og tilgængelig som standard installeret på AWS Lambda Runtime. Desuden kan du bruge denne SDK til at interagere med enhver AWS-tjeneste uden for SageMaker.

Begge disse SDK'er kan bruges til de samme opgaver, men i nogle tilfælde er det mere intuitivt at bruge den ene mere end den anden. SageMaker Python SDK anbefales til nem test, mens AWS SDK/Boto3 anbefales til produktionsbrug for bedre kontrol med ydeevnen. For eksempel leverer SageMaker as a service forudbyggede og vedligeholdte billeder til populære frameworks, såsom Sklearn, PyTorch og TensorFlow. Det kan være særligt nyttigt at bruge SageMaker SDK til at hente deep learning billeder, træne modeller vha estimatorer, og implementer nemt modellen ved hjælp af et simpelt API-kald. Et eksempel til at vise dette i aktion kan findes link..

På den anden side har du nogle gange fortrænede modeller eller forskellige rammer, som du måske bruger. Dette kræver en større portion tilpasning, og SageMaker SDK tilbyder ikke altid det. Vi har tre vigtige trin og tilsvarende boto3 API-kald, som vi skal udføre for at implementere et slutpunkt: Modelskabelse, Oprettelse af slutpunktskonfigurationog Oprettelse af slutpunkt. De første to enheder blev abstraheret ud med SageMaker SDK med vores understøttede rammer, men vi ser disse detaljer med Boto3 SDK. Et omfattende eksempel for at vise de trin, der er involveret i at bruge et Boto3 SDK til at oprette og administrere et slutpunkt, kan findes link..

Overvejelser ved SageMaker-hosting

SageMaker Real-Time Inference har to hovedoptimeringer, som du kan overveje: 1/ Ydelsesoptimering og 2/ Omkostningsoptimering. Lad os først se på præstationsoptimering, som når vi har at gøre med latensfølsomme arbejdsbelastninger, er hvert millisekund afgørende. Der er forskellige knapper, som du kan indstille for at optimere din latenstid og gennemløb. På instansniveau kan du bruge Inferensanbefaling, vores indbyggede belastningstestværktøj, for at hjælpe dig med at vælge den rigtige instanstype og tælle for din arbejdsbyrde. Brug af den rigtige kombination af computer vil hjælpe dig med både ydeevne og omkostninger. Du kan også tune på container- og rammeniveau.
Spørgsmål at stille dig selv inkluderer:

1. Hvilken ramme bruger du?
2. Er der nogen miljøvariabler, som du kan justere i din container?

Et eksempel på dette er maksimering TensorFlow ydeevne med SageMaker containere. Et andet eksempel på optimering af containerniveau er ved at bruge gRPC snarere end REST bag dit endepunkt. Endelig kan du også optimere på script-niveau. Tager din slutningskode ekstra tid ved bestemte blokke? Timing af hver eneste linje i dit script hjælper dig med at fange eventuelle flaskehalse i din kode.

Der er tre måder at se på forbedring af udnyttelsen af dit realtidsslutpunkt:

1. Multi-model Endpoints (MME)
   • Du kan hoste tusindvis af modeller bag et enkelt slutpunkt. Dette er perfekt til brugssager, hvor du ikke har brug for et dedikeret slutpunkt til hver enkelt af dine modeller. MME fungerer bedst, når modellerne har ens størrelse og forsinkelse og tilhører den samme ML-ramme. Disse kan typisk bruges, når du ikke behøver at ringe til den samme model hele tiden. Du kan dynamisk indlæse den respektive model på SageMaker Endpoint for at betjene din anmodning. Et eksempel, der viser MME i aktion, kan findes link.. Hvis du vil lære mere om de forskellige forbehold og bedste praksis for hosting af modeller på MME, så se indlægget link..
2. Multi-Container Endpoints (MCE)
   • I stedet for at bruge flere slutpunkter til at være vært for flere containere, kan du se på at hoste op til 15 containere på et enkelt slutpunkt. Hver af disse beholdere kan påberåbes direkte. Derfor kan du se på hosting af forskellige modeller af forskellige rammer alle på et enkelt slutpunkt. Denne mulighed er bedst, når beholdere udviser lignende brugs- og ydeevneegenskaber. Et eksempel, der viser MCE, kan findes link.. Hvis du vil lære mere om de forskellige forbehold og bedste praksis for hosting af modeller på MCE, så se indlægget link..
3. Serial Inference Pipeline (SIP)
   • Hvis du har en pipeline af trin i din inferenslogik, kan du måske bruge Serial Inference Pipeline (SIP). SIP lader dig kæde 2-15 containere sammen bag et enkelt endepunkt. SIP fungerer godt, når du har forbehandlings- og efterbehandlingstrin. Hvis du vil lære mere om designmønstrene for serielle inferensrørledninger, så se indlægget link..

Den anden vigtigste optimering at huske på er koste. Real-Time Inference er en af ​​tre muligheder inden for oprettelse af SageMaker Endpoints. SageMaker Endpoints kører på alle tidspunkter, medmindre de slettes. Derfor skal du se på at forbedre udnyttelsen af ​​endepunktet, hvilket igen giver en omkostningsfordel.

SageMaker tilbyder også spareplaner. Spareplaner kan reducere dine omkostninger med op til 64 %. Dette er en 1- eller 3-årig forpligtelse til en ensartet mængde forbrug ($/time). Se dette link for mere information. Og se dette link for bedst at optimere omkostningerne til Inference på Amazon SageMaker.

Konklusion

I dette indlæg viste vi dig nogle af de bedste praksisser for at vælge mellem forskellige modelhostingmuligheder på SageMaker. Vi diskuterede SageMaker Endpoint-kravene og modsatte også Framework- og BYOC-krav og funktionalitet. Desuden talte vi om de forskellige måder, du kan udnytte Real-Time Endpoints til at hoste dine ML-modeller i produktionen. på en omkostningseffektiv måde og har høj ydeevne.

Se den tilsvarende GitHub repository og prøv eksemplerne.

---

Om forfatterne

Raghu Ramesha er en ML Solutions Architect hos Amazon SageMaker Service-teamet. Han fokuserer på at hjælpe kunder med at opbygge, implementere og migrere ML-produktionsarbejdsbelastninger til SageMaker i stor skala. Han har specialiseret sig i maskinlæring, kunstig intelligens og computersyn og har en mastergrad i datalogi fra UT Dallas. I sin fritid nyder han at rejse og fotografere.

Ram Vegiraju er ML-arkitekt hos SageMaker Service-teamet. Han fokuserer på at hjælpe kunder med at bygge og optimere deres AI/ML-løsninger på Amazon SageMaker. I sin fritid elsker han at rejse og skrive.

Marc Karp er ML-arkitekt hos SageMaker Service-teamet. Han fokuserer på at hjælpe kunder med at designe, implementere og administrere ML-arbejdsbelastninger i stor skala. I sin fritid nyder han at rejse og udforske nye steder.

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.

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.