Uppnå hög prestanda i stor skala för modellvisning med Amazon SageMaker multi-model endpoints med GPU

Amazon SageMaker flermodell slutpunkter (MME) ger ett skalbart och kostnadseffektivt sätt att distribuera ett stort antal maskininlärningsmodeller (ML). Det ger dig möjligheten att distribuera flera ML-modeller i en enda serveringsbehållare bakom en enda slutpunkt. Därifrån hanterar SageMaker lastning och lossning av modellerna och skalning av resurser för din räkning baserat på dina trafikmönster. Du kommer att dra nytta av att dela och återanvända värdresurser och en minskad operativ börda av att hantera en stor mängd modeller.

I november 2022, MME har lagt till stöd för GPUs, som låter dig köra flera modeller på en enda GPU-enhet och skala GPU-instanser bakom en enda slutpunkt. Detta tillfredsställer den starka MME-efterfrågan på modeller för djupa neurala nätverk (DNN) som drar nytta av accelererad beräkning med GPU:er. Dessa inkluderar datorseende (CV), naturlig språkbehandling (NLP) och generativa AI-modeller. Skälen till efterfrågan inkluderar följande:

• DNN-modeller är vanligtvis stora i storlek och komplexitet och fortsätter att växa i snabb takt. Om man tar NLP-modeller som exempel, överskrider många av dem miljarder parametrar, vilket kräver GPU:er för att uppfylla kraven på låg latens och hög genomströmning.
• Vi har observerat ett ökat behov av att anpassa dessa modeller för att leverera hyperpersonaliserade upplevelser till enskilda användare. När mängden av dessa modeller ökar, finns det ett behov av en enklare lösning för att distribuera och operationalisera många modeller i stor skala.
• GPU-instanser är dyra och du vill återanvända dessa instanser så mycket som möjligt för att maximera GPU-användningen och minska driftskostnaderna.

Även om alla dessa skäl pekar på MME med GPU som ett idealiskt alternativ för DNN-modeller, rekommenderas det att utföra belastningstestning för att hitta rätt slutpunktskonfiguration som uppfyller dina användningsfallskrav. Många faktorer kan påverka belastningstestresultaten, såsom instanstyp, antal instanser, modellstorlek och modellarkitektur. Dessutom kan belastningstestning hjälpa till att styra strategierna för automatisk skalning med hjälp av rätt mätvärden snarare än iterativa försök och felmetoder.

Av dessa skäl har vi satt ihop det här inlägget för att hjälpa dig att utföra korrekt belastningstestning på MME:er med GPU och hitta den bästa konfigurationen för ditt ML-användningsfall. Vi delar våra belastningstestresultat för några av de mest populära DNN-modellerna i NLP och CV som värdas med hjälp av MMEs på olika instanstyper. Vi sammanfattar insikterna och slutsatserna från våra testresultat för att hjälpa dig fatta ett välgrundat beslut om hur du konfigurerar dina egna implementeringar. På vägen delar vi också vårt rekommenderade tillvägagångssätt för att utföra belastningstestning för MME på GPU. De verktyg och teknik som rekommenderas avgör det optimala antalet modeller som kan laddas per instanstyp och hjälper dig att uppnå bästa pris-prestanda.

Lösningsöversikt

För en introduktion till MME och MME med GPU, se Skapa en slutpunkt för flera modeller och Kör flera djupinlärningsmodeller på GPU med Amazon SageMaker multi-model endpoints. För sammanhanget med belastningstestning i det här inlägget kan du ladda ner vår exempelkod från GitHub repo att reproducera resultaten eller använda den som en mall för att benchmarka dina egna modeller. Det finns två bärbara datorer i repet: en för belastningstestande CV-modeller och en annan för NLP. Flera modeller av olika storlekar och arkitekturer jämfördes med olika typer av GPU-instanser: ml.g4dn.2xlarge, ml.g5.2xlarge och ml.p3.2xlarge. Detta bör ge ett rimligt tvärsnitt av prestanda över följande mätvärden för varje instans och modelltyp:

• Max antal modeller som kan laddas i GPU-minnet
• End-to-end svarslatens observerad på klientsidan för varje slutledningsfråga
• Max genomströmning av frågor per sekund som slutpunkten kan bearbeta utan fel
• Max nuvarande användare per instans innan en misslyckad begäran observeras

Följande tabell listar de testade modellerna.

Följande tabell listar de testade GPU-instanserna.

Som tidigare nämnts kod exempel kan anpassas till andra modeller och instanstyper.

Observera att MME för närvarande endast stöder enstaka GPU-instanser. För listan över instanstyper som stöds, se Algoritmer, ramverk och instanser som stöds.

Benchmarkingproceduren består av följande steg:

1. Hämta en förtränad modell från ett modellnav.
2. Förbered modellartefakten för servering på SageMaker MMEs (se Kör flera djupinlärningsmodeller på GPU med Amazon SageMaker multi-model endpoints för mer detaljer).
3. Distribuera en SageMaker MME på en GPU-instans.
4. Bestäm det maximala antalet modeller som kan laddas in i GPU-minnet inom en angiven tröskel.
5. Använd Locust Load Testing Framework för att simulera trafik som slumpmässigt anropar modeller som laddas på instansen.
6. Samla in data och analysera resultaten.
7. Upprepa eventuellt steg 2–6 efter att ha kompilerat modellen till TensorRT.

Steg 4 och 5 kräver en djupare titt. Modeller i en SageMaker GPU MME laddas in i minnet på ett dynamiskt sätt. Därför laddar vi i steg 4 upp en initial modellartefakt till Amazon enkel lagringstjänst (Amazon S3) och anropa modellen för att ladda den i minnet. Efter den första anropet mäter vi mängden GPU-minne som förbrukas, gör en kopia av den ursprungliga modellen, anropar kopian av modellen för att ladda den i minnet och mäter igen den totala mängden GPU-minne som förbrukas. Denna process upprepas tills en specificerad procentuell tröskel för GPU-minnesanvändning har nåtts. För riktmärket satte vi tröskeln till 90 % för att ge en rimlig minnesbuffert för slutsatser om större partier eller lämna lite utrymme för att ladda andra mindre frekvent använda modeller.

Simulera användartrafik

Efter att vi har bestämt antalet modeller kan vi köra ett belastningstest med hjälp av Locust Load Testing Framework. Belastningstestet simulerar användarförfrågningar till slumpmässiga modeller och mäter automatiskt mätvärden som svarslatens och genomströmning.

Locust stöder anpassade belastningstestformer som låter dig definiera anpassade trafikmönster. Formen som användes i detta riktmärke visas i följande diagram. Under de första 30 sekunderna värms slutpunkten upp med 10 samtidiga användare. Efter 30 sekunder skapas nya användare med en hastighet av två per sekund, och når 20 samtidiga användare vid 40-sekundersstrecket. Slutpunkten benchmarkeras sedan stadigt med 20 samtidiga användare fram till 60-sekundersmärket, vid vilken punkt Locust igen börjar öka användare med två per sekund till 40 samtidiga användare. Det här mönstret med upprampning och konstant testning upprepas tills slutpunkten rampas upp till 200 samtidiga användare. Beroende på ditt användningsfall kanske du vill justera belastningstestformen i locust_benchmark_sm.py för att mer exakt återspegla dina förväntade trafikmönster. Om du till exempel har för avsikt att vara värd för större språkmodeller kanske ett belastningstest med 200 samtidiga användare inte är genomförbart för en modell som är värd för en enskild instans, och du kanske därför vill minska antalet användare eller öka antalet instanser. Du kanske också vill förlänga belastningstestets varaktighet för att mer exakt mäta ändpunktens stabilitet över en längre tidsperiod.

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

Observera att vi bara har benchmarkat slutpunkten med homogena modeller som alla körs på en konsekvent serveringsbas med antingen PyTorch eller TensorRT. Detta beror på att MME är bäst lämpade för att vara värd för många modeller med liknande egenskaper, såsom minnesförbrukning och svarstid. Benchmarking-mallarna som finns i GitHub repo kan fortfarande användas för att avgöra om servering av heterogena modeller på MME skulle ge önskad prestanda och stabilitet.

Benchmarkresultat för CV-modeller

Använd cv-benchmark.ipynb-anteckningsboken för att köra belastningstestning för datorseendemodeller. Du kan justera det förtränade modellnamnet och parametrarna för instanstyp till prestandabelastningstestning på olika kombinationer av modell och instanstyp. Vi testade medvetet tre CV-modeller i olika storleksintervall från minsta till största: resnet50 (25 miljoner), convnext_base (88M), och vit_large_patch16_224 (304M). Du kan behöva justera koden om du väljer en modell utanför den här listan. Dessutom ställer notebook-datorn in bildformen som standard till en 224x224x3 bildtensor. Kom ihåg att justera inmatningsformen därefter om du behöver jämföra modeller som tar en bild av olika storlek.

Efter att ha kört igenom hela anteckningsboken får du flera visualiseringar av prestandaanalyser. De två första beskriver modellens prestanda med avseende på ökande samtidiga användare. Följande figurer är exempelvisualiseringar som genereras för ResNet50 modell som körs på ml.g4dn.2xlarge, där PyTorch (vänster) jämförs med TensorRT (höger). Diagrammen på översta raden visar modellens latens och genomströmning på y-axeln med ett ökande antal samtidiga klientarbetare som reflekteras på x-axeln. De nedre stapeldiagrammen visar antalet lyckade och misslyckade förfrågningar.

När vi tittade på alla datorseendemodeller vi testade, observerade vi följande:

• Latensen (i millisekunder) är högre och genomströmningen (förfrågningar per sekund) är lägre för större modeller (resnet50 > convnext_base > vit_large_patch16_224).
• Latensökningen är proportionell mot antalet användare eftersom fler förfrågningar står i kö på slutledningsservern.
• Stora modeller förbrukar mer beräkningsresurser och kan nå sina maximala genomströmningsgränser med färre användare än en mindre modell. Detta observeras med vit_large_patch16_224 modell, som registrerade den första misslyckade begäran vid 140 samtidiga användare. Eftersom den var betydligt större än de andra två testade modellerna hade den de flesta misslyckade förfrågningarna vid högre samtidighet också. Detta är en tydlig signal om att slutpunkten skulle behöva skalas utöver en enda instans om avsikten är att stödja fler än 140 samtidiga användare.

I slutet av notebookkörningen får du också en sammanfattande jämförelse av PyTorch vs TensorRT-modeller för var och en av de fyra nyckelmåtten. Från våra benchmark-tester såg CV-modellerna alla ett uppsving i modellprestanda efter TensorRT-kompileringen. Tar vår ResNet50 modell som exemplet igen, fördröjningen minskade med 32 % medan genomströmningen ökade med 18 %. Även om det maximala antalet samtidiga användare förblev detsamma under ResNet50, såg de andra två modellerna båda en 14 % förbättring av antalet samtidiga användare som de kan stödja. TensorRT-prestandaförbättringen kom dock på bekostnad av högre minnesanvändning, vilket resulterade i färre modeller som laddades av MME. Effekten är mer för modeller som använder ett konvolutionellt neuralt nätverk (CNN). Faktum är att vår ResNet50-modell förbrukade ungefär dubbelt så mycket GPU-minne från PyTorch till TensorRT, vilket resulterade i 50 % färre laddade modeller (46 mot 23). Vi diagnostiserar detta beteende ytterligare i följande avsnitt.

Benchmarkresultat för NLP-modeller

För NLP-modellerna, använd nlp-benchmark.ipynb-anteckningsboken för att köra belastningstestet. Konfigurationen av den bärbara datorn bör se väldigt lika ut. Vi testade två NLP-modeller: bert-base-uncased (109M) och roberta-large (335M). Den förtränade modellen och tokenizern laddas båda ner från Hugging Face-navet, och testnyttolasten genereras från tokenizern med hjälp av en provsträng. Max sekvenslängd är standardinställd på 128. Om du behöver testa längre strängar, kom ihåg att justera den parametern. Att köra igenom NLP-anteckningsboken genererar samma uppsättning visualiseringar: Pytorch (vänster) vs TensorRT (höger).

Från dessa observerade vi ännu mer prestandafördelar med TensorRT för NLP-modeller. Att ta roberta-large modell på en ml.g4dn.2xlarge instans minskade till exempel slutledningslatens dramatiskt från 180 millisekunder till 56 millisekunder (en 70 % förbättring), medan genomströmningen förbättrades med 406 % från 33 förfrågningar per sekund till 167. Dessutom, det maximala antalet samtidiga användare ökade med 50 %; misslyckade förfrågningar observerades inte förrän vi nådde 180 samtidiga användare, jämfört med 120 för den ursprungliga PyTorch-modellen. När det gäller minnesanvändning såg vi en modell färre laddad för TensorRT (från nio modeller till åtta). Den negativa effekten är dock mycket mindre jämfört med vad vi observerade med de CNN-baserade modellerna.

Analys av minnesanvändning

Följande tabell visar den fullständiga analysen av påverkan på minnesutnyttjandet från PyTorch till TensorRT. Vi nämnde tidigare att CNN-baserade modeller påverkas mer negativt. De ResNet50 modellen hade en över 50 % minskning av antalet modeller som laddades över alla tre GPU-instanstyper. Convnext_base hade en ännu större minskning på cirka 70 % över hela linjen. Å andra sidan är påverkan på transformatormodellerna liten eller blandad. vit_large_patch16_224 och roberta-large hade en genomsnittlig minskning på cirka 20 % respektive 3 %, medan bert-base-uncased hade en förbättring på cirka 40 %.

Om vi ​​tittar på alla datapunkter som helhet när det gäller den överlägsna prestandan i latens, genomströmning och tillförlitlighet, och den mindre påverkan på det maximala antalet laddade modeller, rekommenderar vi TensorRT-modellen för transformatorbaserade modellarkitekturer. För CNN anser vi att ytterligare kostnadsanalyser behövs för att säkerställa att prestandafördelarna överväger kostnaden för ytterligare värdinfrastruktur.

Följande tabeller listar våra fullständiga benchmarkresultat för alla mätvärden för alla tre GPU-instanstyper.

Följande tabell sammanfattar resultaten för alla instanstyper. ml.g5.2xlarge-instansen ger bäst prestanda, medan ml.p3.2xlarge-instansen i allmänhet underpresterar trots att den är den dyraste av de tre. G5- och g4dn-instanserna visar det bästa värdet för slutledningsarbetsbelastningar.

Städa upp

När du har slutfört ditt belastningsteste, rensa upp de genererade resurserna för att undvika extra kostnader. Huvudresurserna är SageMaker-ändpunkterna och modellartefaktfiler i Amazon S3. För att göra det enkelt för dig har anteckningsbokens filer följande rensningskod som hjälper dig att radera dem:

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

Slutsats

I det här inlägget delade vi våra testresultat och analys för olika djupa neurala nätverksmodeller som körs på SageMaker multi-model endpoints med GPU. Resultaten och insikterna vi delade bör ge ett rimligt tvärsnitt av prestanda över olika mätvärden och instanstyper. I processen introducerade vi också vårt rekommenderade tillvägagångssätt för att köra benchmark-testning för SageMaker MME med GPU. Verktygen och exempelkoden vi tillhandahåller kan hjälpa dig att snabbt komma igång med ditt benchmarktestning och fatta ett mer välgrundat beslut om hur du kostnadseffektivt ska vara värd för hundratals DNN-modeller på accelererad beräkningshårdvara. För att komma igång med att benchmarka dina egna modeller med MME-stöd för GPU, se Algoritmer, ramverk och instanser som stöds och GitHub repo för ytterligare exempel och dokumentation.

Om författarna

James Wu är Senior AI/ML Specialist Solution Architect på AWS. hjälpa kunder att designa och bygga AI/ML-lösningar. James arbete täcker ett brett spektrum av ML-användningsfall, med ett primärt intresse för datorseende, djupinlärning och skalning av ML över hela företaget. Innan han började på AWS var James arkitekt, utvecklare och teknikledare i över 10 år, inklusive 6 år inom ingenjörsbranschen och 4 år inom marknadsförings- och reklambranschen.

Vikram Elango är en AI/ML Specialist Solutions Architect på Amazon Web Services, baserad i Virginia, USA. Vikram hjälper finans- och försäkringsbranschens kunder med design, tankeledarskap att bygga och distribuera maskininlärningsapplikationer i stor skala. Han är för närvarande fokuserad på naturlig språkbehandling, ansvarsfull AI, slutledningsoptimering och skalning av ML över hela företaget. På fritiden tycker han om att resa, vandra, laga mat och campa med sin familj.

Simon Zamarin är en AI / ML-lösningsarkitekt vars huvudsakliga fokus är att hjälpa kunder att extrahera värde från sina datatillgångar. På sin fritid tycker Simon om att spendera tid med familjen, läsa sci-fi och arbeta med olika DIY-husprojekt.

Saurabh Trikande är senior produktchef för Amazon SageMaker Inference. Han brinner för att arbeta med kunder och motiveras av målet att demokratisera maskininlärning. Han fokuserar på kärnutmaningar relaterade till att distribuera komplexa ML-applikationer, multi-tenant ML-modeller, kostnadsoptimeringar och att göra implementeringen av djupinlärningsmodeller mer tillgänglig. På sin fritid gillar Saurabh att vandra, lära sig om innovativ teknik, följa TechCrunch och umgås med sin familj.

• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• Platoblockchain. Web3 Metaverse Intelligence. Kunskap förstärkt. Tillgång här.
• Källa: https://aws.amazon.com/blogs/machine-learning/achieve-high-performance-at-scale-for-model-serving-using-amazon-sagemaker-multi-model-endpoints-with-gpu/