Kør og optimer multi-model inferens med Amazon SageMaker multi-model slutpunkter

Amazon SageMaker multi-model endpoint (MME) giver dig mulighed for omkostningseffektivt at implementere og hoste flere modeller i et enkelt endepunkt og derefter skalere endepunktet vandret for at opnå skala. Som illustreret i den følgende figur er dette en effektiv teknik til at implementere multi-tenancy af modeller i din maskinlæringsinfrastruktur (ML). Vi har set software as a service (SaaS)-virksomheder bruge denne funktion til at anvende hyper-personalisering i deres ML-modeller og samtidig opnå lavere omkostninger.

For et overblik på højt niveau over, hvordan MME fungerer, se AWS Summit-videoen Skaler ML til det næste niveau: Hosting af tusindvis af modeller på SageMaker. For at lære mere om de hyper-personaliserede, multi-tenant use cases, som MME muliggør, henvises til Sådan skalerer du maskinlæringsslutning til SaaS-brugssager med flere lejere.

I resten af ​​dette indlæg dykker vi dybere ned i den tekniske arkitektur af SageMaker MME og deler bedste praksis for at optimere dine multi-model slutpunkter.

Brug cases, der passer bedst til MME

SageMaker multi-model endpoints er velegnede til at hoste et stort antal modeller, som du kan betjene gennem en delt serveringscontainer, og du behøver ikke at få adgang til alle modellerne på samme tid. Afhængigt af størrelsen af ​​slutpunktforekomsthukommelsen kan en model lejlighedsvis blive fjernet fra hukommelsen til fordel for at indlæse en ny model for at maksimere effektiv brug af hukommelsen, derfor skal din applikation være tolerant over for lejlighedsvise latency-spidser på ikke-indlæste modeller.

MME er også designet til co-hosting af modeller, der bruger den samme ML-ramme, fordi de bruger den delte container til at indlæse flere modeller. Derfor, hvis du har en blanding af ML-frameworks i din modelflåde (såsom PyTorch og TensorFlow), er SageMaker dedikerede slutpunkter eller multi-container-hosting et bedre valg.

Endelig er MME velegnet til applikationer, der kan tolerere en lejlighedsvis koldstartsforsinkelse, fordi modeller indlæses ved første opkald, og sjældent brugte modeller kan aflastes fra hukommelsen til fordel for indlæsning af nye modeller. Derfor, hvis du har en blanding af ofte og sjældent tilgåede modeller, kan et multi-model slutpunkt effektivt betjene denne trafik med færre ressourcer og højere omkostningsbesparelser.

Vi har også set nogle scenarier, hvor kunder implementerer en MME-klynge med tilstrækkelig aggregeret hukommelseskapacitet til at passe til alle deres modeller, og derved undgår modelaflastninger helt, men alligevel opnår omkostningsbesparelser på grund af den delte inferensinfrastruktur.

Model serveringscontainere

Når du bruger SageMaker Inference Toolkit eller en forudbygget SageMaker model serveringscontainer, der er kompatibel med MME, har din container Multi Model Server (JVM-proces) kører. Den nemmeste måde at få Multi Model Server (MMS) indbygget i din modelserveringsbeholder er at bruge SageMaker model serveringscontainere kompatibel med MME (se efter dem med Job Type=inferens og CPU/GPU=CPU). MMS er et open source, letanvendeligt værktøj til betjening af dybe læringsmodeller. Det giver en REST API med en webserver til at betjene og administrere flere modeller på en enkelt vært. Det er dog ikke obligatorisk at bruge MMS; du kan implementere din egen modelserver, så længe den implementerer API'er påkrævet af MME.

Når det bruges som en del af MME-platformen, kanaliseres alle forudsigelige, indlæser og aflæs API-kald til MMS eller din egen modelserver gennem MME-dataplancontrolleren. API-kald fra dataplancontrolleren foretages kun over lokal vært for at forhindre uautoriseret adgang uden for instansen. En af de vigtigste fordele ved MMS er, at det muliggør en standardiseret grænseflade til indlæsning, aflæsning og påkaldelse af modeller med kompatibilitet på tværs af en bred vifte af deep learning-rammer.

Avanceret konfiguration af MMS

Hvis du vælger at bruge MMS til modelvisning, skal du overveje følgende avancerede konfigurationer for at optimere skalerbarheden og gennemløbet af dine MME-forekomster.

Øg inferens parallelitet pr. model

MMS opretter en eller flere Python-arbejdsprocesser pr. model baseret på værdien af default_workers_per_model konfigurationsparameter. Disse Python-arbejdere håndterer hver enkelt slutningsanmodning ved at køre enhver forbehandling, forudsigelse og efterbehandlingsfunktion, du leverer. For mere information, se brugerdefineret service handler GitHub repo.

At have mere end én modelarbejder øger paralleliteten af ​​forudsigelser, der kan betjenes af en given model. Men når et stort antal modeller hostes på en instans med et stort antal CPU'er, bør du udføre en belastningstest af din MME for at finde den optimale værdi for default_workers_per_model for at forhindre udmattelse af hukommelse eller CPU-ressourcer.

Design til trafikspidser

Hver MMS-proces i en slutpunktinstans har en anmodningskø, der kan konfigureres med job_queue_size parameter (standard er 100). Dette bestemmer antallet af anmodninger, MMS vil stå i kø, når alle arbejdsprocesser er optaget. Brug denne parameter til at finjustere reaktionsevnen af ​​dine slutpunktsforekomster, efter du har besluttet dig for det optimale antal arbejdere pr. model.

I et optimalt forhold mellem arbejdere pr. model burde standardværdien på 100 være tilstrækkelig i de fleste tilfælde. Men i de tilfælde, hvor anmodningstrafik til endepunktet stiger usædvanligt, kan du reducere størrelsen af ​​køen, hvis du vil have, at endepunktet ikke hurtigt kan overføre kontrollen til applikationen eller øge køstørrelsen, hvis du ønsker, at endepunktet skal absorbere spidsen .

Maksimer hukommelsesressourcer pr. instans

Når du bruger flere arbejdsprocesser pr. model, indlæser hver arbejdsproces som standard sin egen kopi af modellen. Dette kan reducere den tilgængelige instanshukommelse for andre modeller. Du kan optimere hukommelsesudnyttelsen ved at dele en enkelt model mellem arbejdsprocesser ved at indstille konfigurationsparameteren preload_model=true. Her udveksler du reduceret inferensparallelisme (på grund af en enkelt modelforekomst) med mere hukommelseseffektivitet. Denne indstilling sammen med flere arbejdsprocesser kan være et godt valg til brugssager, hvor modelforsinkelsen er lav, men du har tungere forbehandling og efterbehandling (udføres af arbejdsprocesserne) pr. slutningsanmodning.

Indstil værdier for avancerede MMS-konfigurationer

MMS bruger en config.properties-fil til at gemme konfigurationer. MMS bruger følgende rækkefølge til at finde denne config.properties-fil:

1. Hvis MMS_CONFIG_FILE miljøvariablen er indstillet, indlæser MMS konfigurationen fra miljøvariablen.
2. Hvis --mms-config parameter sendes til MMS, indlæser den konfigurationen fra parameteren.
3. Hvis der er en config.properties i den aktuelle mappe, hvor brugeren starter MMS, indlæser den config.properties fil fra den aktuelle arbejdsmappe.

Hvis ingen af ​​ovenstående er specificeret, indlæser MMS den indbyggede konfiguration med standardværdier.

Følgende er et kommandolinjeeksempel på at starte MMS med en eksplicit konfigurationsfil:

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

Nøglemålinger til at overvåge din endpoint-ydelse

Nøglemålingerne, der kan hjælpe dig med at optimere din MME, er typisk relateret til CPU- og hukommelsesudnyttelse og inferensforsinkelse. Metrics på instansniveau udsendes af MMS, hvorimod latency-metrikkene kommer fra MME. I dette afsnit diskuterer vi de typiske målinger, som du kan bruge til at forstå og optimere din MME.

Endpoint-forekomstniveau-metrics (MMS-metrics)

På hjemmesiden for oprettelse af en konto skal du indtaste postnummeret for dit service-eller faktureringsområde i feltet, der er markeret (A) på billedet ovenfor. liste over MMS-metrics, CPUUtilization og MemoryUtilization kan hjælpe dig med at vurdere, om din forekomst eller MME-klyngen har den rigtige størrelse. Hvis begge metrics har procentsatser mellem 50-80 %, er din MME den rigtige størrelse.

Typisk er lav CPUUtilization og høj MemoryUtilization en indikation af en overprovisioneret MME-klynge, fordi det angiver, at sjældent påkaldte modeller ikke aflæses. Dette kan skyldes et højere end optimalt antal endpoint-instanser, der er klargjort til MME'en, og derfor er en aggregeret hukommelse, der er højere end optimal, tilgængelig for sjældent tilgåede modeller til at forblive i hukommelsen. Omvendt betyder tæt på 100 % udnyttelse af disse metrics, at din klynge er underprovisioneret, så du skal justere din klyngeautomatiske skaleringspolitik.

Metrics på platformsniveau (MME-metrics)

På hjemmesiden for oprettelse af en konto skal du indtaste postnummeret for dit service-eller faktureringsområde i feltet, der er markeret (A) på billedet ovenfor. komplet liste over MME-målinger, en nøglemetrik, der kan hjælpe dig med at forstå latensen af ​​din inferensanmodning, er ModelCacheHit. Denne metrik viser det gennemsnitlige forhold mellem påkaldeanmodninger, for hvilke modellen allerede var indlæst i hukommelsen. Hvis dette forhold er lavt, angiver det, at din MME-klynge er underprovisioneret, fordi der sandsynligvis ikke er nok samlet hukommelseskapacitet i MME-klyngen til antallet af unikke modelankaldelser, hvilket derfor forårsager, at modeller ofte fjernes fra hukommelsen.

Erfaringer fra feltet og strategier til optimering af MME

Vi har set følgende anbefalinger fra nogle af de høje anvendelser af MME på tværs af en række kunder.

Vandret skalering med mindre forekomster er bedre end vertikal skalering med større forekomster

Du kan opleve begrænsning af modelkald, når du kører høje anmodninger per sekund (RPS) på færre endpoint-forekomster. Der er interne grænser for antallet af kald pr. sekund (indlæsninger og aflæsninger, der kan ske samtidigt på en instans), og derfor er det altid bedre at have et højere antal mindre instanser. At køre et højere antal mindre forekomster betyder en højere samlet kapacitet af disse grænser for slutpunktet.

En anden fordel ved horisontal skalering med mindre forekomster er, at du reducerer risikoen for at opbruge forekomstens CPU og hukommelsesressourcer, når du kører MMS med højere niveauer af parallelitet sammen med et højere antal modeller i hukommelsen (som beskrevet tidligere i dette indlæg).

At undgå tæsk er et fælles ansvar

Tærskning i MME er, når modeller ofte fjernes fra hukommelsen og genindlæses på grund af utilstrækkelig hukommelse, enten i en individuel forekomst eller samlet i klyngen.

Fra et brugsperspektiv bør du tilpasse individuelle slutpunktforekomster i den rigtige størrelse og den overordnede størrelse af MME-klyngen i den rigtige størrelse for at sikre, at der er tilstrækkelig hukommelseskapacitet til rådighed pr. forekomst og også samlet for klyngen til din brug. MME-platformens routerflåde vil også maksimere cache-hittet.

Vær ikke aggressiv med bin-packning for mange modeller på færre, større hukommelsesforekomster

Hukommelse er ikke den eneste ressource på instansen, man skal være opmærksom på. Andre ressourcer som CPU kan være en begrænsende faktor, som det ses i følgende belastningstestresultater. I nogle andre tilfælde har vi også observeret, at andre kerneressourcer, såsom proces-id'er, er opbrugt på en instans, på grund af en kombination af for mange modeller, der indlæses, og den underliggende ML-ramme (såsom TensorFlow) gydende tråde pr. model, der var multipla af tilgængelige vCPU'er.

Følgende ydelsestest viser et eksempel på CPU-begrænsninger, der påvirker modelforsinkelse. I denne test producerede et enkelt forekomstendepunkt med en stor forekomst, mens det havde mere end nok hukommelse til at holde alle fire modeller i hukommelsen, forholdsvis værre modelforsinkelser under belastning sammenlignet med et slutpunkt med fire mindre forekomster.

enkelt instans slutpunktsmodel latens

enkelt instans slutpunkt CPU og hukommelsesudnyttelse

fire tilfælde slutpunktsmodel latens

fire tilfælde slutpunkt CPU & hukommelse udnyttelse

For at opnå både ydeevne og omkostningseffektivitet skal du tilpasse din MME-klynge i den rigtige størrelse med et højere antal mindre forekomster, der samlet giver dig den optimale hukommelse og CPU-kapacitet, mens den er relativt på niveau med omkostningerne med færre, men større hukommelsesforekomster.

Mental model til optimering af MME

Der er fire nøglemålinger, som du altid bør overveje, når du skal tilpasse din MME til den rigtige størrelse:

• Modellernes antal og størrelse
• Antallet af unikke modeller, der aktiveres på et givet tidspunkt
• Forekomstens type og størrelse
• Forekomsten tæller bag endepunktet

Start med de to første punkter, fordi de informerer det tredje og fjerde. For eksempel, hvis der ikke er nok forekomster bag endepunktet for antallet eller størrelsen af ​​unikke modeller, du har, vil den samlede hukommelse for endepunktet være lav, og du vil se et lavere cache-hitforhold og tæsk på endepunktsniveauet, fordi MME'en vil indlæse og aflæse modeller i og ud af hukommelsen ofte.

På samme måde, hvis påkaldelserne for unikke modeller er højere end den samlede hukommelse for alle forekomster bag endepunktet, vil du se et lavere cache-hit. Dette kan også ske, hvis størrelsen af ​​forekomster (især hukommelseskapacitet) er for lille.

Lodret skalering med virkelig store hukommelsesforekomster kan også føre til problemer, fordi selvom modellerne kan passe ind i hukommelsen, kan andre ressourcer som CPU- og kerneprocesser og trådgrænser være opbrugt. Indlæs test vandret skalering i præproduktion for at få det optimale antal og størrelse af forekomster til din MME.

Resumé

I dette indlæg fik du en dybere forståelse af MME-platformen. Du lærte, hvilke tekniske use cases MME er egnet til, og gennemgik MME-platformens arkitektur. Du fik en dybere forståelse af hver enkelt komponents rolle inden for MME-arkitekturen, og hvilke komponenter du direkte kan påvirke ydeevnen af. Endelig fik du et dybere kig på de konfigurationsparametre, som du kan justere for at optimere MME til dit brugstilfælde, og de målinger, du bør overvåge for at opretholde optimal ydeevne.

Gennemgå for at komme i gang med MME Amazon SageMaker Multi-Model Endpoints ved hjælp af XGBoost , Vær vært for flere modeller i én container bag ét slutpunkt.

Om forfatteren

Syed Jaffry er Principal Solutions Architect hos AWS. Han arbejder med en række virksomheder fra mellemstore organisationer, store virksomheder, finansielle tjenester og ISV'er for at hjælpe dem med at bygge og drive omkostningseffektive og skalerbare AI/ML-applikationer i skyen.

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.