Designmønstre til seriel inferens på Amazon SageMaker

Efterhånden som maskinlæring (ML) bliver mainstream og vinder bredere udbredelse, bliver ML-drevne applikationer mere og mere almindelige til at løse en række komplekse forretningsproblemer. Løsningen på disse komplekse forretningsproblemer kræver ofte brug af flere ML-modeller. Disse modeller kan kombineres sekventielt for at udføre forskellige opgaver, såsom forbehandling, datatransformation, modelvalg, inferensgenerering, inferenskonsolidering og efterbehandling. Organisationer har brug for fleksible muligheder for at orkestrere disse komplekse ML-arbejdsgange. Serielle inferenspipelines er et sådant designmønster til at arrangere disse arbejdsgange i en række trin, hvor hvert trin beriger eller viderebehandler det output, der er genereret af de foregående trin, og sender outputtet til næste trin i pipelinen.

Derudover bør disse serielle inferensrørledninger give følgende:

• Fleksibel og tilpasset implementering (afhængigheder, algoritmer, forretningslogik og så videre)
• Gentagelig og konsistent for produktionsimplementering
• Udifferentierede tunge løft ved at minimere infrastrukturstyring

I dette indlæg ser vi på nogle almindelige use cases for serielle inferenspipelines og gennemgår nogle implementeringsmuligheder for hver af disse use cases vha. Amazon SageMaker. Vi diskuterer også overvejelser for hver af disse implementeringsmuligheder.

Følgende tabel opsummerer de forskellige anvendelsestilfælde for seriel inferens, implementeringsovervejelser og muligheder. Disse diskuteres i dette indlæg.

I de følgende afsnit diskuterer vi hvert use case mere detaljeret.

Seriel inferenspipeline ved hjælp af inferensbeholdere

Anvendelsestilfælde for seriel inferens-pipeline har krav til at forbehandle indgående data, før en forudtrænet ML-model til generering af inferenser påberåbes. Derudover kan det i nogle tilfælde være nødvendigt at behandle de genererede slutninger yderligere, så de let kan forbruges af downstream-applikationer. Dette er et almindeligt scenarie for brugstilfælde, hvor en streamingdatakilde skal behandles i realtid, før en model kan monteres på den. Denne use case kan dog også vise sig for batch-inferens.

SageMaker giver mulighed for at tilpasse inferensbeholdere og bruge dem til at bygge en seriel inferenspipeline. Inferensbeholdere bruger SageMaker Inference Toolkit og er bygget på SageMaker Multi Model Server (MMS), som giver en fleksibel mekanisme til at betjene ML-modeller. Følgende diagram illustrerer et referencemønster for, hvordan man implementerer en seriel inferenspipeline ved hjælp af inferensbeholdere.

SageMaker MMS forventer et Python-script, der implementerer følgende funktioner for at indlæse modellen, forbehandle inputdata, hente forudsigelser fra modellen og efterbehandle outputdataene:

• input_fn() – Ansvarlig for deserialisering og forbehandling af inputdata
• model_fn() – Ansvarlig for at indlæse den trænede model fra artefakter Amazon Simple Storage Service (Amazon S3)
• forudsige_fn() – Ansvarlig for at generere slutninger fra modellen
• output_fn() – Ansvarlig for serialisering og efterbehandling af outputdata (inferenser)

For detaljerede trin til at tilpasse en inferensbeholder, se Tilpasning af din egen inferensbeholder.

Inferensbeholdere er et ideelt designmønster til seriel inferensrørledningsbrug med følgende primære overvejelser:

• Høj sammenhængskraft – Behandlingslogikken og den tilsvarende model driver enkelt virksomhedsfunktionalitet og skal placeres sammen
• Lav samlet latenstid – Den forløbne tid mellem, hvornår en slutningsanmodning fremsættes, og svar modtages

I en seriel inferenspipeline er behandlingslogikken og -modellen indkapslet i den samme enkelt beholder, så en stor del af invokationskaldene forbliver i beholderen. Dette hjælper med at reducere det samlede antal hop, hvilket resulterer i bedre overordnet latens og reaktionsevne af pipelinen.

Til brugssager, hvor let implementering er et vigtigt kriterium, kan inferensbeholdere også hjælpe, idet forskellige behandlingstrin i pipelinen placeres sammen i den samme beholder.

Seriel inferenspipeline ved hjælp af en SageMaker inferenspipeline

En anden variation af den serielle inferenspipeline kræver en klarere afkobling mellem de forskellige trin i pipelinen (såsom dataforbehandling, inferensgenerering, dataefterbehandling og formatering og serialisering). Dette kan skyldes en række forskellige årsager:

• afkobling – Forskellige trin i rørledningen har et klart defineret formål og skal køres på separate containere på grund af de underliggende afhængigheder. Dette hjælper også med at holde rørledningen velstruktureret.
• rammer – Forskellige trin i pipelinen bruger specifikke rammer, der passer til formålet (såsom scikit eller Spark ML) og skal derfor køres på separate beholdere.
• Ressource isolation – Forskellige trin i rørledningen har varierende krav til ressourceforbrug og skal derfor køres på separate beholdere for mere fleksibilitet og kontrol.

For lidt mere komplekse serielle slutningspipelines kan der desuden være flere trin involveret for at behandle en anmodning og generere en slutning. Ud fra et operationelt synspunkt kan det derfor være en fordel at hoste disse trin på separate containere for bedre funktionel isolering og lette lettere opgraderinger og forbedringer (ændre et trin uden at påvirke andre modeller eller behandlingstrin).

Hvis din use case stemmer overens med nogle af disse overvejelser, en SageMaker inferens pipeline giver en nem og fleksibel mulighed for at bygge en seriel inferenspipeline. Følgende diagram illustrerer et referencemønster for, hvordan man implementerer en seriel inferenspipeline ved hjælp af flere trin hostet på dedikerede containere ved hjælp af en SageMaker inferenspipeline.

En SageMaker-inferenspipeline består af en lineær sekvens på 2-15 containere, der behandler anmodninger om slutninger om data. Inferenspipelinen giver mulighed for at bruge forudtrænede SageMaker indbyggede algoritmer eller brugerdefinerede algoritmer pakket i Docker-containere. Containerne hostes på den samme underliggende instans, hvilket hjælper med at reducere den samlede latenstid og minimere omkostningerne.

Det følgende kodestykke viser, hvordan flere behandlingstrin og modeller kan kombineres for at skabe en seriel inferenspipeline.

Vi starter med at bygge og specificere Spark ML- og XGBoost-baserede modeller, som vi agter at bruge som en del af pipelinen:

from sagemaker.model import Model
from sagemaker.pipeline_model import PipelineModel
from sagemaker.sparkml.model import SparkMLModel
sparkml_data = 's3://{}/{}/{}'.format(s3_model_bucket, s3_model_key_prefix, 'model.tar.gz')
sparkml_model = SparkMLModel(model_data=sparkml_data)
xgb_model = Model(model_data=xgb_model.model_data, image=training_image)

Modellerne arrangeres derefter sekventielt inden for pipelinemodeldefinitionen:

model_name = 'serial-inference-' + timestamp_prefix
endpoint_name = 'serial-inference-ep-' + timestamp_prefix
sm_model = PipelineModel(name=model_name, role=role, models=[sparkml_model, xgb_model])

Inferenspipelinen implementeres derefter bag et slutpunkt til realtidsslutning ved at specificere typen og antallet af værts-ML-forekomster:

sm_model.deploy(initial_instance_count=1, instance_type='ml.c4.xlarge', endpoint_name=endpoint_name)

Hele den samlede inferenspipeline kan betragtes som en SageMaker-model, som du kan bruge til enten at lave forudsigelser i realtid eller behandle batch-transformationer direkte uden nogen ekstern forbehandling. Inden for en inferenspipelinemodel håndterer SageMaker påkaldelser som en sekvens af HTTP-anmodninger, der stammer fra en ekstern applikation. Den første container i pipelinen håndterer den indledende anmodning, udfører en vis behandling og sender derefter det mellemliggende svar som en anmodning til den anden container i pipelinen. Dette sker for hver container i pipelinen og returnerer endelig det endelige svar til den kaldende klientapplikation.

SageMaker inference pipelines er fuldt administreret. Når pipelinen er implementeret, installerer og kører SageMaker alle de definerede containere på hver af Amazon Elastic Compute Cloud (Amazon EC2)-instanser klargjort som en del af slutpunkt- eller batchtransformationsjobbet. Ydermere, fordi containerne er co-placeret og hostet på den samme EC2-instans, reduceres den samlede pipeline-latens.

Seriemodelensemble ved hjælp af en SageMaker-inferenspipeline

En ensemblemodel er en tilgang i ML, hvor flere ML-modeller kombineres og bruges som en del af slutningsprocessen for at generere endelige slutninger. Motivationerne for ensemblemodeller kunne blandt andet omfatte forbedring af nøjagtigheden, reduktion af modellens følsomhed over for specifikke inputfunktioner og reduktion af enkeltmodelbias. I dette indlæg fokuserer vi på use cases relateret til et seriel modelensemble, hvor flere ML-modeller kombineres sekventielt som en del af en seriel inferenspipeline.

Lad os overveje et specifikt eksempel relateret til et seriemodelensemble, hvor vi skal gruppere en brugers uploadede billeder baseret på bestemte temaer eller emner. Denne pipeline kunne bestå af tre ML-modeller:

• Model 1 – Accepterer et billede som input og evaluerer billedkvalitet baseret på billedopløsning, orientering og mere. Denne model forsøger derefter at opskalere billedkvaliteten og sender de behandlede billeder, der opfylder en vis kvalitetstærskel, til den næste model (model 2).
• Model 2 – Accepterer billeder valideret gennem Model 1 og udfører billedgenkendelse at identificere objekter, steder, personer, tekst og andre tilpassede handlinger og koncepter i billeder. Outputtet fra Model 2, der indeholder identificerede objekter, sendes til Model 3.
• Model 3 – Accepterer outputtet fra Model 2 og udfører naturlig sprogbehandling (NLP) opgaver såsom emnemodellering til at gruppere billeder sammen baseret på temaer. For eksempel kan billeder grupperes baseret på placering eller identificerede personer. Outputtet (grupperinger) sendes tilbage til klientapplikationen.

Følgende diagram illustrerer et referencemønster for, hvordan man implementerer flere ML-modeller hostet på et seriel modelensemble ved hjælp af en SageMaker-inferenspipeline.

Som diskuteret tidligere styres SageMaker-inferenspipelinen, hvilket sætter dig i stand til at fokusere på ML-modellens valg og udvikling, samtidig med at de udifferentierede tunge løft, der er forbundet med at bygge den serielle ensemble-pipeline, reduceres.

Derudover er nogle af de overvejelser, der er diskuteret tidligere omkring afkobling, algoritme og rammevalg for modeludvikling og implementering, også relevante her. For eksempel, fordi hver model er hostet på en separat container, har du fleksibilitet til at vælge den ML-ramme, der passer bedst til hver model og din overordnede brugssituation. Derudover kan du fra et afkoblings- og driftsmæssigt synspunkt fortsætte med at opgradere eller ændre individuelle trin meget lettere uden at påvirke andre modeller.

SageMaker inference pipeline er også integreret med SageMaker modelregistrering til modelkatalogisering, versionering, metadataadministration og styret udrulning til produktionsmiljøer for at understøtte ensartet operationel bedste praksis. SageMaker inference pipeline er også integreret med amazoncloudwatch for at muliggøre overvågning af multi-container-modellerne i inferensrørledninger. Du kan også få synlighed ind realtidsmålinger for bedre at forstå påkald og latens for hver container i pipelinen, hvilket hjælper med fejlfinding og ressourceoptimering.

Seriel inferenspipeline (med målrettet modelopkald fra en gruppe) ved hjælp af en SageMaker inferenspipeline

SageMaker multi-model slutpunkter (MME'er) giver en omkostningseffektiv løsning til at implementere et stort antal ML-modeller bag et enkelt slutpunkt. Motivationerne for at bruge multi-model endpoints kunne omfatte at påkalde en specifik tilpasset model baseret på anmodningsegenskaber (såsom oprindelse, geografisk placering, brugertilpasning og så videre) eller blot at hoste flere modeller bag det samme slutpunkt for at opnå omkostningsoptimering.

Når du implementerer flere modeller på et enkelt multi-model-aktiveret slutpunkt, deler alle modeller beregningsressourcerne og modelbeholderen. SageMaker-inferenspipelinen kan implementeres på en MME, hvor en af ​​containerne i pipelinen dynamisk kan betjene anmodninger baseret på den specifikke model, der påberåbes. Fra et pipeline-perspektiv har modellerne identiske forbehandlingskrav og forventer det samme funktionssæt, men er trænet til at tilpasse sig en specifik adfærd. Det følgende diagram illustrerer et referencemønster for, hvordan denne integrerede pipeline ville fungere.

Med MME'er bør inferensanmodningen, der stammer fra klientapplikationen, specificere den målmodel, der skal påberåbes. Den første container i pipelinen håndterer den indledende anmodning, udfører en vis behandling og sender derefter det mellemliggende svar som en anmodning til den anden container i pipelinen, som er vært for flere modeller. Baseret på den målmodel, der er specificeret i slutningsanmodningen, påkaldes modellen for at generere en slutning. Den genererede slutning sendes til den næste beholder i pipelinen for yderligere behandling. Dette sker for hver efterfølgende container i pipelinen, og til sidst returnerer SageMaker det endelige svar til den kaldende klientapplikation.

Flere modelartefakter findes i en S3-spand. Når en specifik model påkaldes, indlæser SageMaker den dynamisk på den container, der er vært for slutpunktet. Hvis modellen allerede er indlæst i containerens hukommelse, er opkaldet hurtigere, fordi SageMaker ikke behøver at downloade modellen fra Amazon S3. Hvis instanshukommelsesudnyttelsen er høj, og en ny model påkaldes og derfor skal indlæses, fjernes ubrugte modeller fra hukommelsen. De aflastede modeller forbliver dog i instansens lagervolumen og kan indlæses i containerens hukommelse senere igen uden at blive downloadet fra S3-bøtten igen.

En af de vigtigste overvejelser ved brug af MME'er er at forstå modelankaldelsesforsinkelsesadfærd. Som diskuteret tidligere indlæses modeller dynamisk i containerens hukommelse for den instans, der er vært for slutpunktet, når de kaldes. Derfor kan modelkaldelsen tage længere tid, når den påkaldes for første gang. Når modellen allerede er i instansbeholderens hukommelse, er de efterfølgende kald hurtigere. Hvis en instanshukommelsesudnyttelse er høj, og en ny model skal indlæses, fjernes ubrugte modeller. Hvis forekomstens lagervolumen er fuld, slettes ubrugte modeller fra lagervolumen. SageMaker styrer fuldt ud lastning og losning af modellerne, uden at du behøver at foretage dig nogle specifikke handlinger. Det er dog vigtigt at forstå denne adfærd, fordi den har konsekvenser for modelkaldelsesforsinkelsen og derfor den samlede ende-til-ende-latens.

Muligheder for pipeline-hosting

SageMaker giver flere forekomst type muligheder at vælge imellem for udrulning af ML-modeller og opbygning af slutningspipelines, baseret på dit brugstilfælde, gennemløb og omkostningskrav. For eksempel kan du vælge CPU- eller GPU-optimerede instanser til at bygge serielle inferenspipelines, på en enkelt container eller på tværs af flere containere. Der er dog nogle gange krav, hvor det ønskes at have fleksibilitet og support til at køre modeller på CPU- eller GPU-baserede instanser inden for samme pipeline for yderligere fleksibilitet.

Du kan nu bruge NVIDIA Triton Inference Server til at tjene modeller til inferens på SageMaker til heterogene beregningskrav. Tjek ud Implementer hurtig og skalerbar AI med NVIDIA Triton Inference Server i Amazon SageMaker for yderligere detaljer.

Konklusion

Efterhånden som organisationer opdager og bygger nye løsninger drevet af ML, bør de nødvendige værktøjer til at orkestrere disse pipelines være fleksible nok til at understøtte baseret på en given use case, samtidig med at de forenkler og reducerer de løbende driftsomkostninger. SageMaker giver flere muligheder for at designe og bygge disse serielle inferens-workflows baseret på dine krav.

Vi ser frem til at høre fra dig om, hvilke use cases du bygger ved hjælp af serielle inferenspipelines. Hvis du har spørgsmål eller feedback, så del dem i kommentarerne.

Om forfatterne

Rahul Sharma er Senior Solutions Architect hos AWS Data Lab, der hjælper AWS-kunder med at designe og bygge AI/ML-løsninger. Før han kom til AWS, har Rahul tilbragt flere år i finans- og forsikringssektoren og hjulpet kunder med at bygge data- og analytiske platforme.

Anand Prakash er Senior Solutions Architect hos AWS Data Lab. Anand fokuserer på at hjælpe kunder med at designe og bygge AI/ML, dataanalyse og databaseløsninger for at accelerere deres vej til produktion.

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 computing og kunstig intelligens. Han fokuserer på Deep learning, herunder NLP og Computer Vision domæner. Han hjælper kunder med at opnå højtydende modelslutning på SageMaker.

Saurabh Trikande er Senior Product Manager for Amazon SageMaker Inference. Han brænder for at arbejde med kunder og gøre machine learning mere tilgængelig. I sin fritid nyder Saurabh at vandre, lære om innovative teknologier, følge TechCrunch og tilbringe tid med sin familie.