Kjør og optimer flermodellslutninger med Amazon SageMaker multi-modellendepunkter

Amazon SageMaker multi-model endpoint (MME) gjør det mulig for deg å kostnadseffektivt distribuere og være vert for flere modeller i ett enkelt endepunkt og deretter horisontalt skalere endepunktet for å oppnå skala. Som illustrert i den følgende figuren, er dette en effektiv teknikk for å implementere multi-tenancy av modeller i maskinlæringsinfrastrukturen (ML). Vi har sett programvare som en tjeneste (SaaS)-bedrifter bruke denne funksjonen til å bruke hyper-personalisering i ML-modellene sine samtidig som de oppnår lavere kostnader.

For en oversikt på høyt nivå over hvordan MME fungerer, sjekk ut AWS Summit-videoen Skaler ML til neste nivå: Hosting for tusenvis av modeller på SageMaker. For å lære mer om hyper-personlig tilpassede brukstilfeller for flere leietakere som MME muliggjør, se Hvordan skalere maskinlæringsslutning for SaaS-brukstilfeller med flere leietakere.

I resten av dette innlegget dykker vi dypere inn i den tekniske arkitekturen til SageMaker MME og deler beste fremgangsmåter for å optimalisere multi-modell-endepunktene dine.

Bruk tilfeller som passer best for MME

SageMaker multi-modell endepunkter er godt egnet for å være vert for et stort antall modeller som du kan betjene gjennom en delt serveringsbeholder og du trenger ikke å få tilgang til alle modellene samtidig. Avhengig av størrelsen på endepunktforekomstminnet, kan en modell av og til bli lastet ut fra minnet til fordel for å laste en ny modell for å maksimere effektiv bruk av minnet, derfor må applikasjonen din være tolerant for sporadiske latenstidstopper på ulastede modeller.

MME er også designet for co-hosting-modeller som bruker samme ML-rammeverk fordi de bruker den delte beholderen til å laste flere modeller. Derfor, hvis du har en blanding av ML-rammeverk i modellflåten din (som PyTorch og TensorFlow), er SageMaker dedikerte endepunkter eller hosting med flere beholdere et bedre valg.

Endelig er MME egnet for applikasjoner som kan tolerere en sporadisk kaldstartsforsinkelse, fordi modellene lastes inn ved første påkalling og sjelden brukte modeller kan lastes ned fra minnet til fordel for lasting av nye modeller. Derfor, hvis du har en blanding av ofte og sjelden tilgang til modeller, kan et endepunkt med flere modeller effektivt betjene denne trafikken med færre ressurser og høyere kostnadsbesparelser.

Vi har også sett noen scenarier der kunder distribuerer en MME-klynge med nok samlet minnekapasitet til å passe alle modellene deres, og derved unngår modellavlastninger totalt, men likevel oppnår kostnadsbesparelser på grunn av den delte inferensinfrastrukturen.

Modell serveringsbeholdere

Når du bruker SageMaker Inference Toolkit eller en forhåndsbygd SageMaker modell serveringsbeholder som er kompatibel med MME, har beholderen Multi -modellserver (JVM-prosess) kjører. Den enkleste måten å ha Multi Model Server (MMS) integrert i din modellserveringsbeholder er å bruke SageMaker modell serveringsbeholdere kompatibel med MME (se etter de med Job Type=inferens og CPU/GPU=CPU). MMS er et åpen kildekode, lett-å-bruke verktøy for å betjene dype læringsmodeller. Den gir en REST API med en webserver for å betjene og administrere flere modeller på en enkelt vert. Det er imidlertid ikke obligatorisk å bruke MMS; du kan implementere din egen modellserver så lenge den implementerer APIer kreves av MME.

Når den brukes som en del av MME-plattformen, kanaliseres alle forutsi, laster og avlaster API-anrop til MMS eller din egen modellserver gjennom MME-dataplankontrolleren. API-anrop fra dataplankontrolleren gjøres kun over lokal vert for å forhindre uautorisert tilgang fra utenfor instansen. En av de viktigste fordelene med MMS er at det muliggjør et standardisert grensesnitt for lasting, lossing og påkalling av modeller med kompatibilitet på tvers av et bredt spekter av dyplæringsrammer.

Avansert konfigurasjon av MMS

Hvis du velger å bruke MMS for modellvisning, bør du vurdere følgende avanserte konfigurasjoner for å optimalisere skalerbarheten og gjennomstrømningen til MME-forekomstene dine.

Øk inferensparallellisme per modell

MMS oppretter en eller flere Python-arbeidsprosesser per modell basert på verdien av default_workers_per_model konfigurasjonsparameter. Disse Python-arbeiderne håndterer hver enkelt slutningsforespørsel ved å kjøre forbehandlings-, prediksjons- og etterbehandlingsfunksjoner du tilbyr. For mer informasjon, se tilpasset servicebehandler GitHub repo.

Å ha mer enn én modellarbeider øker parallelliteten til prediksjoner som kan betjenes av en gitt modell. Men når et stort antall modeller er vert for en instans med et stort antall CPUer, bør du utføre en belastningstest av MME-en din for å finne den optimale verdien for default_workers_per_model for å forhindre utmatting av minne eller CPU-ressurser.

Design for trafikktopper

Hver MMS-prosess i en endepunktforekomst har en forespørselskø som kan konfigureres med job_queue_size parameter (standard er 100). Dette bestemmer antall forespørsler MMS vil stå i kø når alle arbeidsprosesser er opptatt. Bruk denne parameteren til å finjustere responsen til endepunktforekomstene dine etter at du har bestemt deg for det optimale antallet arbeidere per modell.

I et optimalt forhold mellom arbeidere per modell bør standardverdien på 100 være tilstrekkelig i de fleste tilfeller. Men for de tilfellene der forespørselen om trafikk til endepunktet øker uvanlig, kan du redusere størrelsen på køen hvis du vil at endepunktet ikke raskt skal kunne overføre kontrollen til applikasjonen eller øke køstørrelsen hvis du vil at endepunktet skal absorbere toppen .

Maksimer minneressurser per forekomst

Når du bruker flere arbeidsprosesser per modell, laster hver arbeidsprosess som standard inn sin egen kopi av modellen. Dette kan redusere det tilgjengelige forekomstminnet for andre modeller. Du kan optimalisere minneutnyttelsen ved å dele en enkelt modell mellom arbeidsprosesser ved å angi konfigurasjonsparameteren preload_model=true. Her bytter du ut redusert inferensparallellisme (på grunn av en enkelt modellforekomst) med mer minneeffektivitet. Denne innstillingen sammen med flere arbeidsprosesser kan være et godt valg for brukstilfeller der modellforsinkelsen er lav, men du har tyngre forbehandling og etterbehandling (gjort av arbeidsprosessene) per slutningsforespørsel.

Angi verdier for avanserte MMS-konfigurasjoner

MMS bruker en config.properties-fil til å lagre konfigurasjoner. MMS bruker følgende rekkefølge for å finne denne config.properties-filen:

1. Dersom MMS_CONFIG_FILE miljøvariabelen er satt, laster MMS konfigurasjonen fra miljøvariabelen.
2. Dersom --mms-config parameteren sendes til MMS, laster den inn konfigurasjonen fra parameteren.
3. Hvis det er en config.properties i gjeldende mappe der brukeren starter MMS, laster den inn config.properties fil fra gjeldende arbeidskatalog.

Hvis ingen av de ovennevnte er spesifisert, laster MMS den innebygde konfigurasjonen med standardverdier.

Følgende er et kommandolinjeeksempel på å starte MMS med en eksplisitt konfigurasjonsfil:

multi-model-server --start --mms-config /home/mms/config.properties

Nøkkelberegninger for å overvåke endepunktytelsen din

Nøkkelberegningene som kan hjelpe deg med å optimalisere MME-en din, er vanligvis relatert til CPU- og minneutnyttelse og slutningsforsinkelse. Beregningene på forekomstnivå sendes ut av MMS, mens latensverdiene kommer fra MME. I denne delen diskuterer vi de typiske beregningene du kan bruke for å forstå og optimalisere MME.

Beregninger på endepunktforekomstnivå (MMS-beregninger)

Fra liste over MMS-beregninger, CPUUtilization og MemoryUtilization kan hjelpe deg med å vurdere om forekomsten eller MME-klyngen din har riktig størrelse eller ikke. Hvis begge beregningene har prosenter mellom 50–80 %, har MME-en din riktig størrelse.

Vanligvis er lav CPUUtilization og høy MemoryUtilization en indikasjon på en overprovisionert MME-klynge fordi det indikerer at sjelden påkalte modeller ikke blir lastet ut. Dette kan være på grunn av et høyere enn optimalt antall endepunktforekomster som er klargjort for MME, og derfor er høyere enn optimalt samlet minne tilgjengelig for sjelden tilgang til modeller for å forbli i minnet. Omvendt betyr nær 100 % utnyttelse av disse beregningene at klyngen din er undertilpasset, så du må justere retningslinjene for automatisk skalering av klyngen.

Beregninger på plattformnivå (MME-beregninger)

Fra fullstendig liste over MME-målinger, en nøkkelberegning som kan hjelpe deg å forstå ventetiden til slutningsforespørselen din, er ModelCacheHit. Denne beregningen viser det gjennomsnittlige forholdet mellom påkallingsforespørsler som modellen allerede var lastet inn i minnet for. Hvis dette forholdet er lavt, indikerer det at MME-klyngen din er undertilpasset fordi det sannsynligvis ikke er nok samlet minnekapasitet i MME-klyngen for antall unike modellanrop, noe som derfor fører til at modeller ofte blir lastet ut fra minnet.

Lærdom fra feltet og strategier for å optimalisere MME

Vi har sett følgende anbefalinger fra noen av de høyskala brukene av MME på tvers av en rekke kunder.

Horisontal skalering med mindre forekomster er bedre enn vertikal skalering med større forekomster

Du kan oppleve struping på modellanrop når du kjører høye forespørsler per sekund (RPS) på færre endepunktforekomster. Det er interne grenser for antall påkallinger per sekund (laster og losser som kan skje samtidig på en forekomst), og derfor er det alltid bedre å ha et høyere antall mindre forekomster. Å kjøre et høyere antall mindre forekomster betyr en høyere samlet kapasitet for disse grensene for endepunktet.

En annen fordel med horisontal skalering med mindre forekomster er at du reduserer risikoen for å tømme forekomstens CPU og minneressurser når du kjører MMS med høyere nivåer av parallellitet, sammen med et høyere antall modeller i minnet (som beskrevet tidligere i dette innlegget).

Å unngå knekk er et felles ansvar

Knusing i MME er når modeller ofte blir lastet ut fra minnet og lastet inn på nytt på grunn av utilstrekkelig minne, enten i en individuell forekomst eller samlet i klyngen.

Fra et bruksperspektiv bør du gi rett størrelse på individuelle endepunktforekomster og riktig størrelse på den totale størrelsen på MME-klyngen for å sikre at nok minnekapasitet er tilgjengelig per forekomst og også samlet for klyngen for ditt brukstilfelle. MME-plattformens ruterflåte vil også maksimere cache-treffet.

Ikke vær aggressiv med å pakke for mange modeller på færre, større minneforekomster

Minne er ikke den eneste ressursen på forekomsten å være klar over. Andre ressurser som CPU kan være en begrensende faktor, som vist i følgende lasttestresultater. I noen andre tilfeller har vi også observert at andre kjerneressurser som prosess-ID-er blir oppbrukt på en forekomst, på grunn av en kombinasjon av for mange modeller som lastes inn og det underliggende ML-rammeverket (som TensorFlow) gytende tråder per modell som var multipler av tilgjengelige vCPUer.

Følgende ytelsestest viser et eksempel på CPU-begrensninger som påvirker modellforsinkelsen. I denne testen ga et enkelt forekomstendepunkt med en stor forekomst, mens det hadde mer enn nok minne til å holde alle fire modellene i minnet, relativt dårligere modellforsinkelser under belastning sammenlignet med et sluttpunkt med fire mindre forekomster.

endepunktmodelllatens for enkeltforekomster

enkeltforekomst endepunkt CPU og minneutnyttelse

endepunktmodellforsinkelse i fire forekomster

fire forekomst endepunkt CPU og minneutnyttelse

For å oppnå både ytelse og kostnadseffektivitet, lag riktig størrelse på MME-klyngen med et høyere antall mindre forekomster som samlet gir deg optimalt minne og CPU-kapasitet samtidig som det er relativt på nivå med kostnadene med færre, men større minneforekomster.

Mental modell for optimalisering av MME

Det er fire nøkkeltall du alltid bør vurdere når du skal tilpasse MME-en din:

• Antall og størrelse på modellene
• Antall unike modeller som påberopes på et gitt tidspunkt
• Forekomsttypen og størrelsen
• Forekomsttellingen bak endepunktet

Start med de to første punktene, fordi de informerer det tredje og fjerde. For eksempel, hvis det ikke er nok forekomster bak endepunktet for antallet eller størrelsen på unike modeller du har, vil det samlede minnet for endepunktet være lavt, og du vil se et lavere cache-treffforhold og thrashing på endepunktnivået fordi MME vil laste og losse modeller inn og ut av minnet ofte.

På samme måte, hvis påkallelsene for unike modeller er høyere enn det samlede minnet for alle forekomster bak endepunktet, vil du se et lavere hurtigbuffertreff. Dette kan også skje hvis størrelsen på forekomster (spesielt minnekapasiteten) er for liten.

Vertikal skalering med virkelig store minneforekomster kan også føre til problemer fordi selv om modellene kan passe inn i minnet, kan andre ressurser som CPU- og kjerneprosesser og trådgrenser være oppbrukt. Last test horisontal skalering i pre-produksjon for å få det optimale antallet og størrelsen på forekomster for din MME.

Oppsummering

I dette innlegget fikk du en dypere forståelse av MME-plattformen. Du lærte hvilke tekniske brukstilfeller MME er egnet for og gjennomgikk arkitekturen til MME-plattformen. Du fikk en dypere forståelse av rollen til hver komponent innenfor MME-arkitekturen og hvilke komponenter du direkte kan påvirke ytelsen til. Til slutt tok du en dypere titt på konfigurasjonsparameterne som du kan justere for å optimalisere MME for ditt bruksområde og beregningene du bør overvåke for å opprettholde optimal ytelse.

For å komme i gang med MME, gjennomgå Amazon SageMaker Multi-Model Endpoints som bruker XGBoost og Vert for flere modeller i én beholder bak ett endepunkt.

om forfatteren

Syed Jaffry er en hovedløsningsarkitekt med AWS. Han jobber med en rekke selskaper fra mellomstore organisasjoner, store bedrifter, finansielle tjenester og ISV-er for å hjelpe dem med å bygge og drifte kostnadseffektive og skalerbare AI/ML-applikasjoner i skyen.

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.