Designmønstre for seriell slutning på Amazon SageMaker

Etter hvert som maskinlæring (ML) blir mainstream og får bredere bruk, blir ML-drevne applikasjoner stadig mer vanlige for å løse en rekke komplekse forretningsproblemer. Løsningen på disse komplekse forretningsproblemene krever ofte bruk av flere ML-modeller. Disse modellene kan kombineres sekvensielt for å utføre ulike oppgaver, som forbehandling, datatransformasjon, modellvalg, inferensgenerering, inferenskonsolidering og etterbehandling. Organisasjoner trenger fleksible alternativer for å orkestrere disse komplekse ML-arbeidsflytene. Serielle inferensrørledninger er et slikt designmønster for å ordne disse arbeidsflytene i en serie trinn, hvor hvert trinn beriker eller viderebehandler utdataene generert av de foregående trinnene og sender utdataene til neste trinn i rørledningen.

I tillegg bør disse serielle inferensrørledningene gi følgende:

• Fleksibel og tilpasset implementering (avhengigheter, algoritmer, forretningslogikk og så videre)
• Repeterbar og konsistent for produksjonsimplementering
• Udifferensierte tunge løft ved å minimere infrastrukturstyring

I dette innlegget ser vi på noen vanlige brukstilfeller for serielle inferensrørledninger og går gjennom noen implementeringsalternativer for hver av disse brukstilfellene ved å bruke Amazon SageMaker. Vi diskuterer også hensyn for hvert av disse implementeringsalternativene.

Tabellen nedenfor oppsummerer de forskjellige brukstilfellene for serieslutning, implementeringsbetraktninger og alternativer. Disse er omtalt i dette innlegget.

I de følgende avsnittene diskuterer vi hvert brukstilfelle mer detaljert.

Seriell inferensrørledning ved bruk av inferensbeholdere

Brukstilfeller for serie-inferens-rørledninger har krav til å forhåndsbehandle innkommende data før man påkaller en forhåndstrent ML-modell for å generere slutninger. I tillegg, i noen tilfeller, kan det hende at de genererte slutningene må behandles videre, slik at de lett kan konsumeres av nedstrømsapplikasjoner. Dette er et vanlig scenario for brukstilfeller der en strømmingsdatakilde må behandles i sanntid før en modell kan monteres på den. Imidlertid kan denne brukssaken også manifestere seg for batchslutning.

SageMaker tilbyr et alternativ for å tilpasse inferensbeholdere og bruke dem til å bygge en seriell inferensrørledning. Inferensbeholdere bruker SageMaker Inference Toolkit og er bygget på SageMaker Multi Model Server (MMS), som gir en fleksibel mekanisme for å betjene ML-modeller. Følgende diagram illustrerer et referansemønster for hvordan man implementerer en seriell inferensrørledning ved bruk av inferensbeholdere.

SageMaker MMS forventer et Python-skript som implementerer følgende funksjoner for å laste modellen, forhåndsbehandle inndata, hente spådommer fra modellen og etterbehandle utdataene:

• input_fn () – Ansvarlig for deserialisering og forbehandling av inndata
• modell_fn () – Ansvarlig for å laste inn den trente modellen fra artefakter Amazon enkel lagringstjeneste (Amazon S3)
• predict_fn () – Ansvarlig for å generere slutninger fra modellen
• output_fn() – Ansvarlig for serialisering og etterbehandling av utdataene (slutninger)

For detaljerte trinn for å tilpasse en slutningsbeholder, se Tilpasning av din egen inferensbeholder.

Inferensbeholdere er et ideelt designmønster for brukstilfeller for seriel inferensrørledning med følgende primære hensyn:

• Høy samhørighet – Behandlingslogikken og den tilsvarende modellen driver enkeltbedriftsfunksjonalitet og må samlokaliseres
• Lav total ventetid – Tiden som har gått mellom når en slutningsforespørsel sendes til svar mottas

I en seriell inferensrørledning er prosesseringslogikken og modellen innkapslet i den samme enkeltbeholderen, så mye av påkallingsanropene forblir i beholderen. Dette bidrar til å redusere det totale antallet hopp, noe som resulterer i bedre total ventetid og respons på rørledningen.

Også for brukstilfeller der enkel implementering er et viktig kriterium, kan slutningsbeholdere hjelpe, med ulike behandlingstrinn i rørledningen være samlokalisert i samme beholder.

Seriell inferensrørledning ved hjelp av en SageMaker-inferensrørledning

En annen variant av brukssaken for serieslutningsrørledning krever klarere frakobling mellom de ulike trinnene i rørledningen (som dataforbehandling, inferensgenerering, etterbehandling av data og formatering og serialisering). Dette kan skyldes en rekke årsaker:

• dekobling – Ulike trinn i rørledningen har et klart definert formål og må kjøres på separate beholdere på grunn av de underliggende avhengighetene som er involvert. Dette bidrar også til å holde rørledningen godt strukturert.
• rammer – Ulike trinn i rørledningen bruker spesifikke rammeverk som passer til formålet (som scikit eller Spark ML) og må derfor kjøres på separate beholdere.
• Ressursisolering – Ulike trinn i rørledningen har varierende krav til ressursforbruk og må derfor kjøres på separate beholdere for mer fleksibilitet og kontroll.

Videre, for litt mer komplekse serielle slutningsrørledninger, kan flere trinn være involvert for å behandle en forespørsel og generere en slutning. Derfor, fra et operasjonelt synspunkt, kan det være fordelaktig å være vert for disse trinnene på separate beholdere for bedre funksjonell isolasjon, og forenkle enklere oppgraderinger og forbedringer (endre ett trinn uten å påvirke andre modeller eller behandlingstrinn).

Hvis din brukstilfelle stemmer overens med noen av disse vurderingene, a SageMaker inferensrørledning gir et enkelt og fleksibelt alternativ for å bygge en seriell inferensrørledning. Følgende diagram illustrerer et referansemønster for hvordan man implementerer en seriell inferenspipeline ved hjelp av flere trinn som er vert på dedikerte containere ved bruk av en SageMaker inferenspipeline.

En SageMaker-inferenspipeline består av en lineær sekvens på 2–15 beholdere som behandler forespørsler om slutninger om data. Inferensrørledningen gir muligheten til å bruke forhåndstrente SageMaker innebygde algoritmer eller tilpassede algoritmer pakket i Docker-beholdere. Beholderne er vert for den samme underliggende forekomsten, noe som bidrar til å redusere den totale ventetiden og minimere kostnadene.

Følgende kodebit viser hvordan flere behandlingstrinn og modeller kan kombineres for å lage en seriell slutningspipeline.

Vi starter med å bygge og spesifisere Spark ML og XGBoost-baserte modeller som vi har tenkt å bruke som en del av 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)

Modellene blir deretter ordnet sekvensielt innenfor pipeline-modelldefinisjonen:

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])

Inferensrørledningen blir deretter distribuert bak et endepunkt for sanntidsslutning ved å spesifisere typen og antall verts-ML-forekomster:

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

Hele den sammensatte inferensrørledningen kan betraktes som en SageMaker-modell som du kan bruke til å lage enten sanntidsprediksjoner eller prosesser batchtransformasjoner direkte, uten ekstern forbehandling. Innenfor en slutningspipeline-modell håndterer SageMaker påkallinger som en sekvens av HTTP-forespørsler som kommer fra en ekstern applikasjon. Den første beholderen i rørledningen håndterer den første forespørselen, utfører en del behandling og sender deretter mellomsvaret som en forespørsel til den andre beholderen i rørledningen. Dette skjer for hver beholder i rørledningen, og returnerer til slutt det endelige svaret til den anropende klientapplikasjonen.

SageMaker inferensrørledninger er fullt administrert. Når rørledningen er distribuert, installerer og kjører SageMaker alle de definerte beholderne på hver av Amazon Elastic Compute Cloud (Amazon EC2)-forekomster klargjort som en del av endepunkt- eller batchtransformeringsjobben. Videre, fordi beholderne er samlokalisert og vert på samme EC2-instans, reduseres den totale pipeline-latensen.

Seriell modellensemble som bruker en SageMaker-inferensrørledning

En ensemblemodell er en tilnærming i ML der flere ML-modeller kombineres og brukes som en del av slutningsprosessen for å generere endelige slutninger. Motivasjonene for ensemblemodeller kan inkludere å forbedre nøyaktigheten, redusere modellens følsomhet for spesifikke inngangsfunksjoner og redusere enkeltmodellskjevhet, blant andre. I dette innlegget fokuserer vi på brukstilfellene knyttet til et seriemodellensemble, der flere ML-modeller kombineres sekvensielt som en del av en seriell inferenspipeline.

La oss vurdere et spesifikt eksempel knyttet til et seriemodellensemble der vi må gruppere en brukers opplastede bilder basert på bestemte temaer eller emner. Denne rørledningen kan bestå av tre ML-modeller:

• modell 1 – Godtar et bilde som input og evaluerer bildekvalitet basert på bildeoppløsning, orientering og mer. Denne modellen prøver deretter å oppskalere bildekvaliteten og sender de behandlede bildene som oppfyller en viss kvalitetsterskel til neste modell (modell 2).
• modell 2 – Godtar bilder validert gjennom Model 1 og utfører bildegjenkjenning for å identifisere objekter, steder, personer, tekst og andre tilpassede handlinger og konsepter i bilder. Utdataene fra Model 2 som inneholder identifiserte objekter sendes til Model 3.
• modell 3 – Godtar utdata fra Model 2 og utfører naturlig språkbehandling (NLP) oppgaver som emnemodellering for gruppering av bilder basert på temaer. For eksempel kan bilder grupperes basert på plassering eller identifiserte personer. Utdataene (grupperingene) sendes tilbake til klientapplikasjonen.

Følgende diagram illustrerer et referansemønster for hvordan du implementerer flere ML-modeller som er vert for et seriemodellensemble ved å bruke en SageMaker-inferenspipeline.

Som diskutert tidligere administreres SageMaker-inferensrørledningen, noe som lar deg fokusere på ML-modellvalg og utvikling, samtidig som du reduserer de udifferensierte tunge løftene forbundet med å bygge den serielle ensemblerørledningen.

I tillegg er noen av betraktningene diskutert tidligere rundt frakobling, algoritme og rammeverk for modellutvikling og distribusjon relevante her også. For eksempel, fordi hver modell er vert på en separat beholder, har du fleksibilitet til å velge ML-rammeverket som passer best for hver modell og ditt generelle bruksområde. Fra et frakoblings- og driftsmessig synspunkt kan du dessuten fortsette å oppgradere eller endre individuelle trinn mye lettere, uten å påvirke andre modeller.

SageMaker-inferensrørledningen er også integrert med SageMaker modellregister for modellkatalogisering, versjonering, metadataadministrasjon og styrt distribusjon til produksjonsmiljøer for å støtte konsistente operasjonelle beste praksis. SageMaker-inferensrørledningen er også integrert med Amazon CloudWatch for å muliggjøre overvåking av multibeholdermodellene i inferensrørledninger. Du kan også få innsyn i sanntidsmålinger for å bedre forstå påkallinger og ventetid for hver beholder i pipelinen, noe som hjelper med feilsøking og ressursoptimalisering.

Seriell slutningspipeline (med målrettet modellanrop fra en gruppe) ved bruk av en SageMaker slutningspipeline

SageMaker multi-modell endepunkter (MME) gir en kostnadseffektiv løsning for å distribuere et stort antall ML-modeller bak ett enkelt endepunkt. Motivasjonene for å bruke multi-modell endepunkter kan inkludere å påkalle en spesifikk tilpasset modell basert på forespørselsegenskaper (som opprinnelse, geografisk plassering, brukertilpasning og så videre) eller ganske enkelt å være vert for flere modeller bak samme endepunkt for å oppnå kostnadsoptimalisering.

Når du distribuerer flere modeller på et enkelt multi-modellaktivert endepunkt, deler alle modellene dataressursene og modellbeholderen. SageMaker-inferensrørledningen kan distribueres på en MME, der en av beholderne i rørledningen dynamisk kan betjene forespørsler basert på den spesifikke modellen som påkalles. Fra et rørledningsperspektiv har modellene identiske forbehandlingskrav og forventer det samme funksjonssettet, men er opplært til å tilpasse seg en bestemt atferd. Følgende diagram illustrerer et referansemønster for hvordan denne integrerte rørledningen ville fungere.

Med MMEer bør slutningsforespørselen som stammer fra klientapplikasjonen spesifisere målmodellen som må påberopes. Den første beholderen i rørledningen håndterer den første forespørselen, utfører en del behandling, og sender deretter mellomsvaret som en forespørsel til den andre beholderen i rørledningen, som er vert for flere modeller. Basert på målmodellen spesifisert i slutningsforespørselen, påkalles modellen for å generere en slutning. Den genererte slutningen sendes til neste beholder i rørledningen for videre behandling. Dette skjer for hver påfølgende container i pipelinen, og til slutt returnerer SageMaker det endelige svaret til den anropende klientapplikasjonen.

Flere modellartefakter er bevart i en S3-bøtte. Når en spesifikk modell påkalles, laster SageMaker den dynamisk inn på beholderen som er vert for endepunktet. Hvis modellen allerede er lastet inn i beholderens minne, er påkallingen raskere fordi SageMaker ikke trenger å laste ned modellen fra Amazon S3. Hvis minneutnyttelsen for forekomster er høy og en ny modell påkalles og derfor må lastes, lastes ubrukte modeller ut fra minnet. De avlastede modellene forblir imidlertid i forekomstens lagringsvolum, og kan lastes inn i beholderens minne senere igjen, uten å bli lastet ned fra S3-bøtten igjen.

En av hovedhensynene ved bruk av MME-er er å forstå atferd med ventetid for modellanrop. Som diskutert tidligere, lastes modeller dynamisk inn i beholderens minne til forekomsten som er vert for endepunktet når de påkalles. Derfor kan modellpåkallelsen ta lengre tid når den påkalles for første gang. Når modellen allerede er i forekomstbeholderens minne, er de påfølgende påkallingene raskere. Hvis minneutnyttelsen for en forekomst er høy og en ny modell må lastes, blir ubrukte modeller avlastet. Hvis forekomstens lagringsvolum er fullt, slettes ubrukte modeller fra lagringsvolumet. SageMaker styrer fullt ut lasting og lossing av modellene, uten at du trenger å gjøre noen spesifikke handlinger. Det er imidlertid viktig å forstå denne virkemåten fordi den har implikasjoner på modellpåkallingsforsinkelsen og dermed den generelle ende-til-ende-latensen.

Alternativer for pipeline-hosting

SageMaker gir flere instanstype alternativer å velge mellom for å distribuere ML-modeller og bygge ut slutningsrørledninger, basert på dine brukstilfeller, gjennomstrømming og kostnadskrav. Du kan for eksempel velge CPU- eller GPU-optimaliserte forekomster for å bygge serielle inferensrørledninger, på en enkelt beholder eller på tvers av flere beholdere. Imidlertid er det noen ganger krav der det er ønskelig å ha fleksibilitet og støtte for å kjøre modeller på CPU- eller GPU-baserte instanser innenfor samme pipeline for ekstra fleksibilitet.

Du kan nå bruke NVIDIA Triton Inference Server til å tjene modeller for slutning på SageMaker for heterogene beregningskrav. Sjekk ut Distribuer rask og skalerbar AI med NVIDIA Triton Inference Server i Amazon SageMaker for ytterligere detaljer.

konklusjonen

Etter hvert som organisasjoner oppdager og bygger nye løsninger drevet av ML, bør verktøyene som kreves for å orkestrere disse rørledningene være fleksible nok til å støtte basert på en gitt brukssituasjon, samtidig som de forenkler og reduserer de pågående driftskostnadene. SageMaker gir flere alternativer for å designe og bygge disse serielle slutningsarbeidsflytene, basert på dine krav.

Vi ser frem til å høre fra deg om hvilke brukssaker du bygger ved hjelp av serielle inferensrørledninger. Hvis du har spørsmål eller tilbakemeldinger, vennligst del dem i kommentarene.

Om forfatterne

Rahul Sharma er en senior løsningsarkitekt ved AWS Data Lab, og hjelper AWS-kunder med å designe og bygge AI/ML-løsninger. Før han begynte i AWS, har Rahul tilbrakt flere år i finans- og forsikringssektoren, og hjulpet kunder med å bygge data- og analytiske plattformer.

Anand Prakash er senior løsningsarkitekt ved AWS Data Lab. Anand fokuserer på å hjelpe kunder med å designe og bygge AI/ML, dataanalyse og databaseløsninger for å akselerere veien til produksjon.

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 Computer Vision-domener. Han hjelper kundene med å oppnå høy ytelse modellslutning på SageMaker.

Saurabh Trikande er senior produktsjef for Amazon SageMaker Inference. Han brenner for å jobbe med kunder og gjøre maskinlæring mer tilgjengelig. På fritiden liker Saurabh å gå tur, lære om innovative teknologier, følge TechCrunch og tilbringe tid med familien.