Opnå høj ydeevne i skala til modelvisning ved hjælp af Amazon SageMaker multi-model endpoints med GPU

Amazon SageMaker multi-model slutpunkter (MME'er) giver en skalerbar og omkostningseffektiv måde at implementere et stort antal maskinlæringsmodeller (ML). Det giver dig mulighed for at implementere flere ML-modeller i en enkelt serveringsbeholder bag et enkelt slutpunkt. Derfra administrerer SageMaker indlæsning og losning af modellerne og skalering af ressourcer på dine vegne baseret på dine trafikmønstre. Du vil drage fordel af at dele og genbruge hostingressourcer og en reduceret driftsbyrde ved at administrere en stor mængde modeller.

I november 2022, MME'er tilføjede understøttelse af GPUs, som giver dig mulighed for at køre flere modeller på en enkelt GPU-enhed og skalere GPU-forekomster bag et enkelt slutpunkt. Dette opfylder den stærke MME-efterspørgsel efter DNN-modeller (Deep Neural Network), der drager fordel af accelereret beregning med GPU'er. Disse omfatter computersyn (CV), naturlig sprogbehandling (NLP) og generative AI-modeller. Årsagerne til efterspørgslen omfatter følgende:

• DNN-modeller er typisk store i størrelse og kompleksitet og fortsætter med at vokse i et hurtigt tempo. Tager man NLP-modeller som et eksempel, overstiger mange af dem milliarder af parametre, hvilket kræver, at GPU'er opfylder krav til lav latenstid og høj gennemstrømning.
• Vi har observeret et øget behov for at tilpasse disse modeller til at levere hyper-personaliserede oplevelser til individuelle brugere. Efterhånden som antallet af disse modeller stiger, er der behov for en lettere løsning til at implementere og operationalisere mange modeller i skala.
• GPU-forekomster er dyre, og du vil genbruge disse forekomster så meget som muligt for at maksimere GPU-udnyttelsen og reducere driftsomkostningerne.

Selvom alle disse grunde peger på, at MME'er med GPU er en ideel mulighed for DNN-modeller, tilrådes det at udføre belastningstest for at finde den rigtige endepunktskonfiguration, der opfylder dine krav til brug. Mange faktorer kan påvirke belastningstestresultaterne, såsom instanstype, antal instanser, modelstørrelse og modelarkitektur. Derudover kan belastningstest hjælpe med at guide de automatiske skaleringsstrategier ved at bruge de rigtige metrics frem for iterative forsøg og fejlmetoder.

Af disse grunde har vi sammensat dette indlæg for at hjælpe dig med at udføre korrekt belastningstest på MME'er med GPU og finde den bedste konfiguration til din ML-brugssituation. Vi deler vores belastningstestresultater for nogle af de mest populære DNN-modeller i NLP og CV hostet ved hjælp af MME'er på forskellige instanstyper. Vi opsummerer indsigten og konklusionerne fra vores testresultater for at hjælpe dig med at træffe en informeret beslutning om at konfigurere dine egne implementeringer. Undervejs deler vi også vores anbefalede tilgang til udførelse af belastningstest for MME'er på GPU. De anbefalede værktøjer og teknikker bestemmer det optimale antal modeller, der kan indlæses pr. instanstype, og hjælper dig med at opnå den bedste pris-ydelse.

Løsningsoversigt

For en introduktion til MME'er og MME'er med GPU, se Opret et multi-model slutpunkt , Kør flere deep learning-modeller på GPU med Amazon SageMaker multi-model endpoints. I forbindelse med belastningstest i dette indlæg kan du downloade vores eksempelkode fra GitHub repo at gengive resultaterne eller bruge det som en skabelon til at benchmarke dine egne modeller. Der er to notesbøger til rådighed i repoen: en til belastningstest CV-modeller og en anden til NLP. Adskillige modeller af varierende størrelser og arkitekturer blev benchmarket på forskellige typer GPU-instanser: ml.g4dn.2xlarge, ml.g5.2xlarge og ml.p3.2xlarge. Dette bør give et rimeligt tværsnit af ydeevnen på tværs af følgende metrics for hver forekomst og modeltype:

• Maks. antal modeller, der kan indlæses i GPU-hukommelsen
• End-to-end-svarforsinkelse observeret på klientsiden for hver slutningsforespørgsel
• Maks. gennemløb af forespørgsler pr. sekund, som slutpunktet kan behandle uden fejl
• Maks. nuværende brugere pr. tilfælde, før en mislykket anmodning observeres

Følgende tabel viser de testede modeller.

Følgende tabel viser de testede GPU-forekomster.

Som tidligere nævnt er kode eksempel kan anvendes til andre modeller og instanstyper.

Bemærk, at MME'er i øjeblikket kun understøtter enkelte GPU-instanser. Se listen over understøttede instanstyper Understøttede algoritmer, rammer og instanser.

Benchmarking-proceduren består af følgende trin:

1. Hent en fortrænet model fra en modelhub.
2. Forbered modelartefakten til servering på SageMaker MME'er (se Kør flere deep learning-modeller på GPU med Amazon SageMaker multi-model endpoints for flere detaljer).
3. Implementer en SageMaker MME på en GPU-instans.
4. Bestem det maksimale antal modeller, der kan indlæses i GPU-hukommelsen inden for en specificeret grænse.
5. Brug Locust Load Testing Framework til at simulere trafik, der tilfældigt kalder modeller indlæst på instansen.
6. Indsamle data og analyser resultaterne.
7. Gentag eventuelt trin 2-6 efter kompilering af modellen til TensorRT.

Trin 4 og 5 garanterer et dybere kig. Modeller i en SageMaker GPU MME indlæses i hukommelsen på en dynamisk måde. Derfor uploader vi i trin 4 en indledende modelartefakt til Amazon Simple Storage Service (Amazon S3) og påkald modellen for at indlæse den i hukommelsen. Efter den indledende påkaldelse måler vi mængden af ​​forbrugt GPU-hukommelse, laver en kopi af den oprindelige model, påkalder kopien af ​​modellen for at indlæse den i hukommelsen og måler igen den samlede mængde GPU-hukommelse, der forbruges. Denne proces gentages, indtil en specificeret procentgrænse for GPU-hukommelsesudnyttelse er nået. For benchmark satte vi tærsklen til 90 % for at give en rimelig hukommelsesbuffer til at konkludere på større batches eller efterlade noget plads til at indlæse andre mindre hyppigt brugte modeller.

Simuler brugertrafik

Efter at vi har fastlagt antallet af modeller, kan vi køre en belastningstest ved hjælp af Locust Load Testing Framework. Belastningstesten simulerer brugeranmodninger til tilfældige modeller og måler automatisk metrics såsom responsforsinkelse og gennemløb.

Locust understøtter tilpassede belastningstestformer, der giver dig mulighed for at definere brugerdefinerede trafikmønstre. Formen, der blev brugt i dette benchmark, er vist i følgende diagram. I de første 30 sekunder varmes endepunktet op med 10 samtidige brugere. Efter 30 sekunder opstår nye brugere med en hastighed på to i sekundet, og når 20 samtidige brugere ved 40-sekunders mærket. Slutpunktet benchmarkes derefter støt med 20 samtidige brugere indtil 60-sekunders mærket, hvorpå Locust igen begynder at øge brugerne med to i sekundet indtil 40 samtidige brugere. Dette mønster med rampe op og konstant test gentages, indtil endepunktet er rampet op til 200 samtidige brugere. Afhængigt af dit brugstilfælde vil du måske justere belastningstestformen i locust_benchmark_sm.py for mere præcist at afspejle dine forventede trafikmønstre. For eksempel, hvis du har til hensigt at hoste større sprogmodeller, er en belastningstest med 200 samtidige brugere muligvis ikke mulig for en model, der hostes på en enkelt forekomst, og du kan derfor ønske at reducere brugerantallet eller øge antallet af forekomster. Du vil måske også forlænge varigheden af ​​belastningstesten for mere præcist at måle endepunktets stabilitet over en længere periode.

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

Bemærk, at vi kun har benchmarket slutpunktet med homogene modeller, der alle kører på en ensartet serveringsbase ved hjælp af enten PyTorch eller TensorRT. Dette skyldes, at MME'er er bedst egnede til at hoste mange modeller med lignende egenskaber, såsom hukommelsesforbrug og responstid. Benchmarking-skabelonerne i GitHub repo kan stadig bruges til at bestemme, om betjening af heterogene modeller på MME'er ville give den ønskede ydeevne og stabilitet.

Benchmark resultater for CV-modeller

Brug cv-benchmark.ipynb notesbogen til at køre belastningstest for computervisionsmodeller. Du kan justere det forudtrænede modelnavn og instanstypeparametre til ydelsesbelastningstest på forskellige model- og instanstypekombinationer. Vi testede bevidst tre CV-modeller i forskellige størrelsesintervaller fra mindste til største: resnet50 (25 mio.), convnext_base (88M), og vit_large_patch16_224 (304M). Du skal muligvis justere til koden, hvis du vælger en model uden for denne liste. Derudover indstiller den bærbare computer inputbilledformen til en 224x224x3 billedtensor. Husk at justere inputformen i overensstemmelse hermed, hvis du skal benchmarke modeller, der tager billeder i en anden størrelse.

Når du har kørt hele notesbogen igennem, får du adskillige visualiseringer af præstationsanalyse. De to første beskriver modellens ydeevne med hensyn til stigende samtidige brugere. De følgende figurer er eksempler på visualiseringer, der er genereret for ResNet50 model, der kører på ml.g4dn.2xlarge, sammenligner PyTorch (venstre) vs. TensorRT (højre). Graferne på den øverste linje viser modellens latens og gennemløb på y-aksen med et stigende antal samtidige klientarbejdere afspejlet på x-aksen. De nederste søjlediagrammer viser antallet af vellykkede og mislykkede anmodninger.

Når vi kiggede på tværs af alle de computersynsmodeller, vi testede, observerede vi følgende:

• Latency (i millisekunder) er højere, og gennemløb (anmodninger pr. sekund) er lavere for større modeller (resnet50 > convnext_base > vit_large_patch16_224).
• Forøgelse af latency er proportional med antallet af brugere, da flere anmodninger står i kø på inferensserveren.
• Store modeller bruger flere computerressourcer og kan nå deres maksimale gennemløbsgrænser med færre brugere end en mindre model. Dette observeres med vit_large_patch16_224 model, som registrerede den første mislykkede anmodning hos 140 samtidige brugere. Da den var betydeligt større end de to andre testede modeller, havde den også de fleste overordnede mislykkede anmodninger ved højere samtidighed. Dette er et klart signal om, at endepunktet skal skaleres ud over en enkelt instans, hvis hensigten er at understøtte mere end 140 samtidige brugere.

I slutningen af ​​notebook-kørslen får du også en sammenfattende sammenligning af PyTorch vs. TensorRT-modeller for hver af de fire nøglemålinger. Fra vores benchmark-test fik CV-modellerne alle et løft i modelydelsen efter TensorRT-kompilering. Tager vores ResNet50 model som eksemplet igen faldt latensen med 32 %, mens gennemløbet steg med 18 %. Selvom det maksimale antal samtidige brugere forblev det samme i ResNet50, så de to andre modeller begge en forbedring på 14 % i antallet af samtidige brugere, som de kan understøtte. TensorRT-ydeevneforbedringen kom dog på bekostning af højere hukommelsesudnyttelse, hvilket resulterede i færre modeller indlæst af MME'er. Virkningen er mere for modeller, der bruger et foldningsneuralt netværk (CNN). Faktisk forbrugte vores ResNet50-model cirka det dobbelte af GPU-hukommelsen fra PyTorch til TensorRT, hvilket resulterede i 50 % færre indlæste modeller (46 vs. 23). Vi diagnosticerer denne adfærd yderligere i det følgende afsnit.

Benchmark resultater for NLP-modeller

For NLP-modellerne skal du bruge nlp-benchmark.ipynb-notebooken til at køre belastningstesten. Opsætningen af ​​notesbogen skulle ligne meget. Vi testede to NLP-modeller: bert-base-uncased (109M) og roberta-large (335M). Den forudtrænede model og tokenizeren downloades begge fra Hugging Face-hubben, og testnyttelasten genereres fra tokenizeren ved hjælp af en prøvestreng. Max sekvenslængde er som standard sat til 128. Hvis du har brug for at teste længere strenge, skal du huske at justere denne parameter. At køre gennem NLP-notebooken genererer det samme sæt visualiseringer: Pytorch (venstre) vs TensorRT (højre).

Fra disse observerede vi endnu mere ydeevnefordel ved TensorRT til NLP-modeller. At tage roberta-large model på en ml.g4dn.2xlarge forekomst faldt f.eks. inferenslatens drastisk fra 180 millisekunder til 56 millisekunder (en 70 % forbedring), mens gennemløbet blev forbedret med 406 % fra 33 anmodninger pr. sekund til 167. Derudover er det maksimale antal samtidige brugere steg med 50 %; mislykkede anmodninger blev ikke observeret, før vi nåede 180 samtidige brugere, sammenlignet med 120 for den originale PyTorch-model. Med hensyn til hukommelsesudnyttelse så vi en model færre indlæst til TensorRT (fra ni modeller til otte). Den negative påvirkning er dog meget mindre sammenlignet med, hvad vi observerede med de CNN-baserede modeller.

Analyse af hukommelsesudnyttelse

Følgende tabel viser den fulde analyse af hukommelsesudnyttelsespåvirkning fra PyTorch til TensorRT. Vi nævnte tidligere, at CNN-baserede modeller påvirkes mere negativt. Det ResNet50 modellen havde en reduktion på over 50 % i antallet af modeller, der blev indlæst på tværs af alle tre GPU-instanstyper. Convnext_base havde en endnu større reduktion på ca. 70 % over hele linjen. På den anden side er påvirkningen af ​​transformermodellerne lille eller blandet. vit_large_patch16_224 , roberta-large havde en gennemsnitlig reduktion på henholdsvis cirka 20 % og 3 %, mens bert-base-uncased havde en forbedring på cirka 40 %.

Ser vi på alle datapunkterne som helhed med hensyn til den overlegne ydeevne i latens, gennemløb og pålidelighed og den mindre indvirkning på det maksimale antal indlæste modeller, anbefaler vi TensorRT-modellen til transformerbaserede modelarkitekturer. For CNN'er mener vi, at der er behov for yderligere analyse af omkostningsydelsen for at sikre, at præstationsfordelen opvejer omkostningerne ved yderligere hostinginfrastruktur.

Følgende tabeller viser vores komplette benchmark-resultater for alle metrics på tværs af alle tre GPU-instanstyper.

Følgende tabel opsummerer resultaterne på tværs af alle instanstyper. ml.g5.2xlarge-forekomsten giver den bedste ydeevne, hvorimod ml.p3.2xlarge-forekomsten generelt klarer sig dårligere på trods af at den er den dyreste af de tre. g5- og g4dn-forekomsterne viser den bedste værdi for inferensarbejdsbelastninger.

Ryd op

Når du har gennemført din belastningstest, skal du rydde op i de genererede ressourcer for at undgå at pådrage dig yderligere omkostninger. De vigtigste ressourcer er SageMaker-endepunkterne og modelartefaktfiler i Amazon S3. For at gøre det nemt for dig har notebook-filerne følgende oprydningskode til at hjælpe dig med at slette dem:

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

Konklusion

I dette indlæg delte vi vores testresultater og analyser for forskellige dybe neurale netværksmodeller, der kører på SageMaker multi-model endpoints med GPU. De resultater og indsigter, vi delte, bør give et rimeligt tværsnit af ydeevnen på tværs af forskellige metrics og instanstyper. I processen introducerede vi også vores anbefalede tilgang til at køre benchmarktest for SageMaker MME'er med GPU. Værktøjerne og prøvekoden, vi har leveret, kan hjælpe dig med at komme hurtigt i gang med din benchmark-test og træffe en mere informeret beslutning om, hvordan du omkostningseffektivt hoster hundredvis af DNN-modeller på accelereret computerhardware. For at komme i gang med at benchmarke dine egne modeller med MME-understøttelse til GPU, se Understøttede algoritmer, rammer og instanser og GitHub repo for yderligere eksempler og dokumentation.

Om forfatterne

James Wu er Senior AI/ML Specialist Solution Architect hos AWS. hjælpe kunder med at designe og bygge AI/ML-løsninger. James' arbejde dækker en bred vifte af ML use cases med en primær interesse i computervision, deep learning og skalering af ML på tværs af virksomheden. Inden han kom til AWS, var James arkitekt, udvikler og teknologileder i over 10 år, herunder 6 år inden for ingeniørvidenskab og 4 år i marketing- og reklamebranchen.

Vikram Elango er en AI/ML Specialist Solutions Architect hos Amazon Web Services, baseret i Virginia USA. Vikram hjælper finans- og forsikringsbranchens kunder med design, tankelederskab til at bygge og implementere maskinlæringsapplikationer i stor skala. Han er i øjeblikket fokuseret på naturlig sprogbehandling, ansvarlig AI, inferensoptimering og skalering af ML på tværs af virksomheden. I sin fritid nyder han at rejse, vandre, lave mad og campere med sin familie.

Simon Zamarin er en AI/ML Solutions Architect, hvis hovedfokus er at hjælpe kunder med at udvinde værdi fra deres dataaktiver. I sin fritid nyder Simon at bruge tid med familien, læse sci-fi og arbejde på forskellige DIY-husprojekter.

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.

• SEO Powered Content & PR Distribution. Bliv forstærket i dag.
• Platoblokkæde. Web3 Metaverse Intelligence. Viden forstærket. Adgang 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/