Oppnå høy ytelse i stor skala for modellvisning ved å bruke Amazon SageMaker multi-modell endepunkter med GPU

Amazon SageMaker flermodell-endepunkter (MMEer) gir en skalerbar og kostnadseffektiv måte å distribuere et stort antall maskinlæringsmodeller (ML). Det gir deg muligheten til å distribuere flere ML-modeller i en enkelt serveringsbeholder bak et enkelt endepunkt. Derfra administrerer SageMaker lasting og lossing av modellene og skaleringsressurser på dine vegne basert på trafikkmønstrene dine. Du vil dra nytte av å dele og gjenbruke vertsressurser og en redusert driftsbyrde ved å administrere et stort antall modeller.

I november 2022, MMEer la til støtte for GPUs, som lar deg kjøre flere modeller på en enkelt GPU-enhet og skalere GPU-forekomster bak et enkelt endepunkt. Dette tilfredsstiller den sterke MME-etterspørselen etter DNN-modeller (Deep Neural Network) som drar nytte av akselerert databehandling med GPUer. Disse inkluderer datasyn (CV), naturlig språkbehandling (NLP) og generative AI-modeller. Årsakene til etterspørselen inkluderer følgende:

• DNN-modeller er vanligvis store i størrelse og kompleksitet og fortsetter å vokse i raskt tempo. Med NLP-modeller som eksempel, overskrider mange av dem milliarder av parametere, noe som krever at GPU-er tilfredsstiller lav latens og høye gjennomstrømningskrav.
• Vi har observert et økt behov for å tilpasse disse modellene for å levere hypertilpassede opplevelser til individuelle brukere. Etter hvert som antallet av disse modellene øker, er det behov for en enklere løsning for å distribuere og operasjonalisere mange modeller i stor skala.
• GPU-forekomster er dyre, og du vil gjenbruke disse forekomstene så mye som mulig for å maksimere GPU-utnyttelsen og redusere driftskostnadene.

Selv om alle disse årsakene peker på MME-er med GPU som et ideelt alternativ for DNN-modeller, anbefales det å utføre belastningstesting for å finne den riktige endepunktkonfigurasjonen som tilfredsstiller brukskravene dine. Mange faktorer kan påvirke lasttestingsresultatene, for eksempel forekomsttype, antall forekomster, modellstørrelse og modellarkitektur. I tillegg kan belastningstesting hjelpe til med å veilede de automatiske skaleringsstrategiene ved å bruke riktige beregninger i stedet for iterative prøve- og feilmetoder.

Av disse grunnene har vi satt sammen dette innlegget for å hjelpe deg med å utføre riktig belastningstesting på MME-er med GPU og finne den beste konfigurasjonen for ML-brukssaken. Vi deler våre lasttestingsresultater for noen av de mest populære DNN-modellene i NLP og CV som er vert ved bruk av MME-er på forskjellige instanstyper. Vi oppsummerer innsikten og konklusjonen fra testresultatene våre for å hjelpe deg med å ta en informert beslutning om å konfigurere dine egne distribusjoner. Underveis deler vi også vår anbefalte tilnærming til å utføre lasttesting for MME-er på GPU. Verktøyene og teknikken som anbefales bestemmer det optimale antallet modeller som kan lastes per forekomsttype og hjelper deg med å oppnå best pris-ytelse.

Løsningsoversikt

For en introduksjon til MMEer og MMEer med GPU, se Opprett et endepunkt for flere modeller og Kjør flere dyplæringsmodeller på GPU med Amazon SageMaker multi-modell endepunkter. For sammenheng med lasttesting i dette innlegget, kan du laste ned prøvekoden vår fra GitHub repo å reprodusere resultatene eller bruke den som en mal for å benchmarke dine egne modeller. Det er to bærbare datamaskiner i repoen: en for lasttesting av CV-modeller og en annen for NLP. Flere modeller av varierende størrelser og arkitekturer ble benchmarket på forskjellige typer GPU-instanser: ml.g4dn.2xlarge, ml.g5.2xlarge og ml.p3.2xlarge. Dette bør gi et rimelig tverrsnitt av ytelse på tvers av følgende beregninger for hver forekomst og modelltype:

• Maks antall modeller som kan lastes inn i GPU-minnet
• End-to-end responsforsinkelse observert på klientsiden for hver inferensspørring
• Maks gjennomstrømning av spørringer per sekund som endepunktet kan behandle uten feil
• Maks gjeldende brukere per forekomst før en mislykket forespørsel observeres

Tabellen nedenfor viser modellene som er testet.

Tabellen nedenfor viser GPU-forekomstene som er testet.

Som tidligere nevnt, er kodeeksempel kan adopteres til andre modeller og instanstyper.

Merk at MME-er for øyeblikket bare støtter enkelt GPU-forekomster. For listen over støttede forekomsttyper, se Støttede algoritmer, rammeverk og forekomster.

Benchmarking-prosedyren består av følgende trinn:

1. Hent en forhåndstrent modell fra en modellhub.
2. Forbered modellartefakten for servering på SageMaker MME-er (se Kjør flere dyplæringsmodeller på GPU med Amazon SageMaker multi-modell endepunkter for flere detaljer).
3. Distribuer en SageMaker MME på en GPU-forekomst.
4. Bestem det maksimale antallet modeller som kan lastes inn i GPU-minnet innenfor en spesifisert terskel.
5. Bruk Locust Load Testing Framework for å simulere trafikk som tilfeldig påkaller modeller lastet på forekomsten.
6. Samle inn data og analyser resultatene.
7. Gjenta eventuelt trinn 2–6 etter å ha kompilert modellen til TensorRT.

Trinn 4 og 5 garanterer en dypere titt. Modeller i en SageMaker GPU MME lastes inn i minnet på en dynamisk måte. Derfor laster vi i trinn 4 opp en innledende modellartefakt til Amazon enkel lagringstjeneste (Amazon S3) og påkalle modellen for å laste den inn i minnet. Etter den første påkallingen måler vi mengden forbrukt GPU-minne, lager en kopi av den opprinnelige modellen, påkaller kopien av modellen for å laste den inn i minnet, og igjen måler den totale mengden GPU-minne som forbrukes. Denne prosessen gjentas til en spesifisert prosentterskel for GPU-minneutnyttelse er nådd. For benchmark setter vi terskelen til 90 % for å gi en rimelig minnebuffer for å konkludere på større batcher eller la det være plass til å laste inn andre mindre ofte brukte modeller.

Simuler brukertrafikk

Etter at vi har bestemt antall modeller, kan vi kjøre en lasttest ved hjelp av Locust Load Testing Framework. Lasttesten simulerer brukerforespørsler til tilfeldige modeller og måler automatisk beregninger som responsforsinkelse og gjennomstrømning.

Locust støtter tilpassede belastningstestformer som lar deg definere tilpassede trafikkmønstre. Formen som ble brukt i denne referansen er vist i følgende diagram. I løpet av de første 30 sekundene varmes endepunktet opp med 10 samtidige brukere. Etter 30 sekunder blir nye brukere skapt med en hastighet på to per sekund, og når 20 samtidige brukere ved 40-sekundersmerket. Endepunktet benchmarkes deretter jevnt og trutt med 20 samtidige brukere frem til 60-sekundersmerket, på hvilket tidspunkt Locust igjen begynner å øke brukerne med to per sekund til 40 samtidige brukere. Dette mønsteret med ramping opp og jevn testing gjentas til endepunktet er rampet opp til 200 samtidige brukere. Avhengig av bruken din, kan det være lurt å justere belastningstestformen i locust_benchmark_sm.py for å gjenspeile de forventede trafikkmønstrene dine mer nøyaktig. Hvis du for eksempel har tenkt å være vert for større språkmodeller, kan det hende at en belastningstest med 200 samtidige brukere ikke er gjennomførbar for en modell som er vert for en enkelt forekomst, og det kan derfor være lurt å redusere antall brukere eller øke antallet forekomster. Det kan også være lurt å forlenge varigheten av lasttesten for mer nøyaktig å måle endepunktets stabilitet over lengre tid.

stages = [
{"duration": 30, "users": 10, "spawn_rate": 5},
{"duration": 60, "users": 20, "spawn_rate": 1},
{"duration": 90, "users": 40, "spawn_rate": 2},
…
]

Legg merke til at vi bare har benchmarked endepunktet med homogene modeller som alle kjører på en konsistent serveringsbase ved å bruke enten PyTorch eller TensorRT. Dette er fordi MME-er er best egnet for å være vert for mange modeller med lignende egenskaper, som minneforbruk og responstid. Benchmarking-malene gitt i GitHub repo kan fortsatt brukes til å bestemme om servering av heterogene modeller på MME-er vil gi ønsket ytelse og stabilitet.

Referanseresultater for CV-modeller

Bruk cv-benchmark.ipynb-notisboken til å kjøre lasttesting for datamaskinsynsmodeller. Du kan justere det forhåndstrente modellnavnet og instanstypeparameterne til ytelsesbelastningstesting på forskjellige modell- og instanstypekombinasjoner. Vi testet med vilje tre CV-modeller i forskjellige størrelsesområder fra minste til største: resnet50 (25 millioner), convnext_base (88M), og vit_large_patch16_224 (304M). Du må kanskje justere til koden hvis du velger en modell utenfor denne listen. i tillegg setter den bærbare datamaskinen inn bildeformen som standard til en 224x224x3 bildetensor. Husk å justere inndataformen i henhold til dette hvis du trenger å benchmarke modeller som tar bilder i en annen størrelse.

Etter å ha kjørt gjennom hele notatboken, vil du få flere ytelsesanalysevisualiseringer. De to første beskriver modellytelsen med hensyn til økende samtidige brukere. De følgende figurene er eksempelvisualiseringer generert for ResNet50 modell som kjører på ml.g4dn.2xlarge, og sammenligner PyTorch (venstre) vs. TensorRT (høyre). De øverste linjegrafene viser modellens latens og gjennomstrømning på y-aksen med økende antall samtidige klientarbeidere reflektert på x-aksen. De nederste søylediagrammene viser antallet vellykkede og mislykkede forespørsler.

Når vi ser på alle datasynsmodellene vi testet, observerte vi følgende:

• Latency (i millisekunder) er høyere, og gjennomstrømning (forespørsler per sekund) er lavere for større modeller (resnet50 > convnext_base > vit_large_patch16_224).
• Økning av ventetid er proporsjonal med antall brukere ettersom flere forespørsler står i kø på inferensserveren.
• Store modeller bruker mer dataressurser og kan nå sine maksimale gjennomstrømningsgrenser med færre brukere enn en mindre modell. Dette observeres med vit_large_patch16_224 modell, som registrerte den første mislykkede forespørselen hos 140 samtidige brukere. Siden den er betydelig større enn de to andre modellene som ble testet, hadde den de fleste mislykkede forespørslene ved høyere samtidighet også. Dette er et tydelig signal om at endepunktet må skaleres utover en enkelt forekomst hvis intensjonen er å støtte mer enn 140 samtidige brukere.

På slutten av notebook-kjøringen får du også en sammenfattende sammenligning av PyTorch vs. TensorRT-modeller for hver av de fire nøkkelberegningene. Fra vår benchmark-testing så alle CV-modellene et løft i modellytelsen etter TensorRT-samlingen. Tar vår ResNet50 modell som eksempelet igjen, ventetiden gikk ned med 32 % mens gjennomstrømningen økte med 18 %. Selv om det maksimale antallet samtidige brukere forble det samme for ResNet50, så de to andre modellene begge en forbedring på 14 % i antall samtidige brukere som de kan støtte. TensorRT-ytelsesforbedringen kom imidlertid på bekostning av høyere minneutnyttelse, noe som resulterte i færre modeller lastet av MME-er. Virkningen er mer for modeller som bruker et konvolusjonelt nevralt nettverk (CNN). Faktisk forbrukte vår ResNet50-modell omtrent det dobbelte av GPU-minnet fra PyTorch til TensorRT, noe som resulterte i 50 % færre modeller lastet (46 vs. 23). Vi diagnostiserer denne atferden ytterligere i den følgende delen.

Referanseresultater for NLP-modeller

For NLP-modeller, bruk nlp-benchmark.ipynb-notisboken for å kjøre belastningstesten. Oppsettet til den bærbare datamaskinen skal se veldig likt ut. Vi testet to NLP-modeller: bert-base-uncased (109M) og roberta-large (335M). Den forhåndstrente modellen og tokenizeren lastes begge ned fra Hugging Face-huben, og testnyttelasten genereres fra tokenizeren ved hjelp av en prøvestreng. Maks sekvenslengde er standard på 128. Hvis du trenger å teste lengre strenger, husk å justere den parameteren. Å kjøre gjennom NLP-notisboken genererer det samme settet med visualiseringer: Pytorch (venstre) vs TensorRT (høyre).

Fra disse observerte vi enda mer ytelsesfordeler med TensorRT for NLP-modeller. Tar roberta-large modell på en ml.g4dn.2xlarge forekomst, for eksempel reduserte inferenslatensen dramatisk fra 180 millisekunder til 56 millisekunder (en 70 % forbedring), mens gjennomstrømningen ble forbedret med 406 % fra 33 forespørsler per sekund til 167. I tillegg er det maksimale antallet samtidige brukere økte med 50 %; mislykkede forespørsler ble ikke observert før vi nådde 180 samtidige brukere, sammenlignet med 120 for den originale PyTorch-modellen. Når det gjelder minneutnyttelse, så vi en modell færre lastet for TensorRT (fra ni modeller til åtte). Imidlertid er den negative effekten mye mindre sammenlignet med det vi observerte med de CNN-baserte modellene.

Analyse av minneutnyttelse

Følgende tabell viser den fullstendige analysen av innvirkning på minneutnyttelse fra PyTorch til TensorRT. Vi nevnte tidligere at CNN-baserte modeller påvirkes mer negativt. De ResNet50 modellen hadde en over 50 % reduksjon i antall modeller lastet på tvers av alle tre GPU-forekomsttypene. Convnext_base hadde en enda større reduksjon på omtrent 70 % over hele linja. På den annen side er påvirkningen på transformatormodellene liten eller blandet. vit_large_patch16_224 og roberta-large hadde en gjennomsnittlig reduksjon på henholdsvis ca. 20 % og 3 %, mens bert-base-uncased hadde en forbedring på omtrent 40 %.

Ser vi på alle datapunktene som en helhet med hensyn til overlegen ytelse i latens, gjennomstrømning og pålitelighet, og den mindre innvirkningen på det maksimale antallet modeller som lastes, anbefaler vi TensorRT-modellen for transformatorbaserte modellarkitekturer. For CNN-er tror vi at ytterligere kostnadsytelsesanalyse er nødvendig for å sikre at ytelsesfordelen oppveier kostnadene ved ekstra hostinginfrastruktur.

Følgende tabeller viser våre fullstendige referanseresultater for alle beregningene på tvers av alle tre GPU-forekomsttypene.

Tabellen nedenfor oppsummerer resultatene på tvers av alle forekomsttyper. ml.g5.2xlarge-forekomsten gir best ytelse, mens ml.p3.2xlarge-forekomsten generelt sett underpresterer til tross for at den er den dyreste av de tre. g5- og g4dn-forekomstene viser den beste verdien for slutningsarbeidsbelastninger.

Rydd opp

Etter at du har fullført belastningstesten, må du rydde opp i de genererte ressursene for å unngå ekstra kostnader. Hovedressursene er SageMaker-endepunktene og modellartefaktfiler i Amazon S3. For å gjøre det enkelt for deg har notisbokfilene følgende oppryddingskode for å hjelpe deg med å slette dem:

delete_endpoint(sm_client, sm_model_name, endpoint_config_name, endpoint_name) ! aws s3 rm --recursive {trt_mme_path}

konklusjonen

I dette innlegget delte vi våre testresultater og analyser for forskjellige dype nevrale nettverksmodeller som kjører på SageMaker multi-modell endepunkter med GPU. Resultatene og innsikten vi delte, bør gi et rimelig tverrsnitt av ytelse på tvers av ulike beregninger og forekomsttyper. I prosessen introduserte vi også vår anbefalte tilnærming for å kjøre benchmark-testing for SageMaker MME-er med GPU. Verktøyene og eksempelkoden vi har levert, kan hjelpe deg med å raskt starte referansetestingen og ta en mer informert beslutning om hvordan du kostnadseffektivt skal være vert for hundrevis av DNN-modeller på akselerert databehandling. For å komme i gang med benchmarking av dine egne modeller med MME-støtte for GPU, se Støttede algoritmer, rammeverk og forekomster og GitHub repo for ytterligere eksempler og dokumentasjon.

Om forfatterne

James Wu er senior AI/ML spesialistløsningsarkitekt hos AWS. hjelpe kunder med å designe og bygge AI/ML-løsninger. James sitt arbeid dekker et bredt spekter av ML-brukstilfeller, med en primær interesse for datasyn, dyp læring og skalering av ML på tvers av bedriften. Før han begynte i AWS, var James arkitekt, utvikler og teknologileder i over 10 år, inkludert 6 år innen ingeniørfag og 4 år i markedsførings- og reklamebransjen.

Vikram Elango er en AI/ML Specialist Solutions Architect hos Amazon Web Services, basert i Virginia USA. Vikram hjelper finans- og forsikringsbransjens kunder med design, tankelederskap for å bygge og distribuere maskinlæringsapplikasjoner i stor skala. Han er for tiden fokusert på naturlig språkbehandling, ansvarlig AI, inferensoptimalisering og skalering av ML på tvers av bedriften. På fritiden liker han å reise, gå fotturer, lage mat og campe med familien.

Simon Zamarin er en AI / ML-løsningsarkitekt som har hovedfokus på å hjelpe kunder med å hente ut verdi fra dataenes eiendeler. På fritiden liker Simon å tilbringe tid med familien, lese sci-fi og jobbe med forskjellige DIY-husprosjekter.

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.

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• Platoblokkkjede. Web3 Metaverse Intelligence. Kunnskap forsterket. Tilgang her.
• kilde: https://aws.amazon.com/blogs/machine-learning/achieve-high-performance-at-scale-for-model-serving-using-amazon-sagemaker-multi-model-endpoints-with-gpu/