Bereik hoge prestaties op schaal voor modelweergave met behulp van Amazon SageMaker multi-model endpoints met GPU

Amazon Sage Maker eindpunten met meerdere modellen (MME's) bieden een schaalbare en kosteneffectieve manier om een ​​groot aantal machine learning (ML)-modellen in te zetten. Het geeft u de mogelijkheid om meerdere ML-modellen te implementeren in een enkele dienende container achter een enkel eindpunt. Van daaruit beheert SageMaker namens u het laden en lossen van de modellen en het schalen van bronnen op basis van uw verkeerspatronen. U profiteert van het delen en hergebruiken van hostingbronnen en een verminderde operationele last van het beheer van een groot aantal modellen.

In november 2022, MME's hebben ondersteuning voor GPU toegevoegds, waarmee u meerdere modellen op één GPU-apparaat kunt uitvoeren en GPU-instanties kunt schalen achter één enkel eindpunt. Dit voldoet aan de sterke MME-vraag naar deep neural network (DNN)-modellen die profiteren van versnelde rekenkracht met GPU's. Deze omvatten computervisie (CV), natuurlijke taalverwerking (NLP) en generatieve AI-modellen. De redenen voor de vraag zijn de volgende:

• DNN-modellen zijn doorgaans groot in omvang en complexiteit en blijven in hoog tempo groeien. Als we NLP-modellen als voorbeeld nemen, overschrijden veel ervan miljarden parameters, waardoor GPU's moeten voldoen aan lage latentie en hoge doorvoervereisten.
• We hebben gemerkt dat er meer behoefte is aan het aanpassen van deze modellen om hypergepersonaliseerde ervaringen te bieden aan individuele gebruikers. Naarmate het aantal van deze modellen toeneemt, is er behoefte aan een eenvoudigere oplossing om veel modellen op schaal te implementeren en te operationaliseren.
• GPU-instanties zijn duur en u wilt deze instanties zoveel mogelijk hergebruiken om het GPU-gebruik te maximaliseren en de bedrijfskosten te verlagen.

Hoewel al deze redenen erop wijzen dat MME's met GPU een ideale optie zijn voor DNN-modellen, is het raadzaam om belastingstests uit te voeren om de juiste eindpuntconfiguratie te vinden die voldoet aan uw use case-vereisten. Veel factoren kunnen de resultaten van de belastingtest beïnvloeden, zoals het type instantie, het aantal instanties, de modelgrootte en de modelarchitectuur. Bovendien kunnen belastingstests helpen bij het begeleiden van strategieën voor automatisch schalen met behulp van de juiste statistieken in plaats van iteratieve methoden van vallen en opstaan.

Om die redenen hebben we dit bericht samengesteld om u te helpen bij het uitvoeren van de juiste belastingstests op MME's met GPU en om de beste configuratie voor uw ML-gebruiksscenario te vinden. We delen onze belastingtestresultaten voor enkele van de meest populaire DNN-modellen in NLP en CV gehost met behulp van MME's op verschillende instantietypen. We vatten de inzichten en conclusies van onze testresultaten samen om u te helpen een weloverwogen beslissing te nemen over het configureren van uw eigen implementaties. Onderweg delen we ook onze aanbevolen aanpak voor het uitvoeren van belastingstests voor MME's op GPU. De aanbevolen tools en technieken bepalen het optimale aantal modellen dat per instantietype kan worden geladen en helpen u de beste prijs-prestatieverhouding te bereiken.

Overzicht oplossingen

Voor een inleiding tot MME's en MME's met GPU, zie Maak een eindpunt met meerdere modellen en Voer meerdere deep learning-modellen uit op GPU met Amazon SageMaker multi-model endpoints. Voor de context van belastingtesten in dit bericht kunt u onze voorbeeldcode downloaden van de GitHub repo om de resultaten te reproduceren of als sjabloon te gebruiken om uw eigen modellen te benchmarken. Er zijn twee notebooks in de repo: een voor het testen van CV-modellen en een andere voor NLP. Verschillende modellen van verschillende groottes en architecturen werden gebenchmarkt op verschillende soorten GPU-instanties: ml.g4dn.2xlarge, ml.g5.2xlarge en ml.p3.2xlarge. Dit zou een redelijke dwarsdoorsnede van de prestaties moeten opleveren voor de volgende statistieken voor elke instantie en elk modeltype:

• Maximaal aantal modellen dat in GPU-geheugen kan worden geladen
• End-to-end responslatentie waargenomen aan de clientzijde voor elke deductiequery
• Maximale doorvoer van query's per seconde die het eindpunt foutloos kan verwerken
• Max. huidige gebruikers per instantie voordat een mislukt verzoek wordt waargenomen

De volgende tabel geeft een overzicht van de geteste modellen.

De volgende tabel bevat de geteste GPU-exemplaren.

Zoals eerder vermeld, de code voorbeeld kan worden overgenomen in andere modellen en instantietypen.

Houd er rekening mee dat MME's momenteel alleen afzonderlijke GPU-exemplaren ondersteunen. Raadpleeg voor de lijst met ondersteunde instantietypen Ondersteunde algoritmen, frameworks en instances.

De benchmarkingprocedure bestaat uit de volgende stappen:

1. Haal een vooraf getraind model op uit een modelhub.
2. Bereid het modelartefact voor op SageMaker MME's (zie Voer meerdere deep learning-modellen uit op GPU met Amazon SageMaker multi-model endpoints voor meer details).
3. Implementeer een SageMaker MME op een GPU-instantie.
4. Bepaal het maximale aantal modellen dat binnen een bepaalde drempel in het GPU-geheugen kan worden geladen.
5. Gebruik het Locust Load Testing Framework om verkeer te simuleren dat willekeurig modellen aanroept die op de instantie zijn geladen.
6. Verzamel gegevens en analyseer de resultaten.
7. Herhaal eventueel stap 2-6 na het compileren van het model naar TensorRT.

Stappen 4 en 5 rechtvaardigen een diepere blik. Modellen binnen een SageMaker GPU MME worden op een dynamische manier in het geheugen geladen. Daarom uploaden we in stap 4 een eerste modelartefact naar Amazon eenvoudige opslagservice (Amazon S3) en roep het model aan om het in het geheugen te laden. Na de eerste aanroep meten we de hoeveelheid verbruikt GPU-geheugen, maken we een kopie van het oorspronkelijke model, roepen we de kopie van het model aan om het in het geheugen te laden en meten we opnieuw de totale hoeveelheid verbruikt GPU-geheugen. Dit proces wordt herhaald totdat een opgegeven procentuele drempel van GPU-geheugengebruik is bereikt. Voor de benchmark hebben we de drempel op 90% gezet om een ​​redelijke geheugenbuffer te bieden voor het maken van conclusies over grotere batches of om wat ruimte over te laten om andere, minder vaak gebruikte modellen te laden.

Simuleer gebruikersverkeer

Nadat we het aantal modellen hebben bepaald, kunnen we een belastingstest uitvoeren met behulp van de Locust Load-testkader. De belastingstest simuleert gebruikersverzoeken naar willekeurige modellen en meet automatisch statistieken zoals responslatentie en doorvoer.

Locust ondersteunt aangepaste belastingstestvormen waarmee u aangepaste verkeerspatronen kunt definiëren. De vorm die in deze benchmark is gebruikt, wordt weergegeven in de volgende grafiek. In de eerste 30 seconden wordt het endpoint opgewarmd met 10 gelijktijdige gebruikers. Na 30 seconden worden er nieuwe gebruikers gegenereerd met een snelheid van twee per seconde, waarbij na 20 seconden 40 gelijktijdige gebruikers worden bereikt. Het eindpunt wordt vervolgens gestaag gebenchmarkt met 20 gelijktijdige gebruikers tot de 60-secondenmarkering, waarna Locust opnieuw gebruikers begint op te voeren met twee per seconde tot 40 gelijktijdige gebruikers. Dit patroon van opvoeren en continu testen wordt herhaald totdat het eindpunt is opgevoerd tot 200 gelijktijdige gebruikers. Afhankelijk van uw gebruikssituatie, wilt u misschien de vorm van de belastingstest in locust_benchmark_sm.py aanpassen om uw verwachte verkeerspatronen nauwkeuriger weer te geven. Als u bijvoorbeeld van plan bent om grotere taalmodellen te hosten, is een belastingstest met 200 gelijktijdige gebruikers mogelijk niet haalbaar voor een model dat op één instantie wordt gehost, en daarom wilt u misschien het aantal gebruikers verminderen of het aantal instanties verhogen. U kunt ook de duur van de belastingstest verlengen om de stabiliteit van het eindpunt over een langere periode nauwkeuriger te meten.

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

Houd er rekening mee dat we het eindpunt alleen hebben gebenchmarkt met homogene modellen die allemaal op een consistente serverbasis draaien met behulp van PyTorch of TensorRT. Dit komt omdat MME's het meest geschikt zijn voor het hosten van veel modellen met vergelijkbare kenmerken, zoals geheugengebruik en responstijd. De benchmarking-sjablonen in de GitHub repo kan nog steeds worden gebruikt om te bepalen of het bedienen van heterogene modellen op MME's de gewenste prestaties en stabiliteit zou opleveren.

Benchmarkresultaten voor cv-modellen

Gebruik de cv-benchmark.ipynb-notebook om belastingstests uit te voeren voor computer vision-modellen. U kunt de vooraf getrainde modelnaam en instantietypeparameters aanpassen aan prestatiebelastingtests op verschillende combinaties van model en instantietype. We hebben met opzet drie CV-modellen getest in verschillende maten, van klein tot groot: resnet50 (25 miljoen), convnext_base (88 miljoen), en vit_large_patch16_224 (304M). Mogelijk moet u zich aanpassen aan de code als u een model buiten deze lijst kiest. bovendien stelt de notebook de invoerbeeldvorm standaard in op een 224x224x3 beeldtensor. Vergeet niet om de invoervorm dienovereenkomstig aan te passen als u modellen wilt benchmarken die een afbeelding van een andere grootte maken.

Nadat u het hele notitieblok hebt doorlopen, krijgt u verschillende prestatieanalysevisualisaties. De eerste twee beschrijven de modelprestaties met betrekking tot toenemende gelijktijdige gebruikers. De volgende afbeeldingen zijn de voorbeeldvisualisaties die zijn gegenereerd voor de ResNet50 model draait op ml.g4dn.2xlarge, waarbij PyTorch (links) wordt vergeleken met TensorRT (rechts). De grafieken op de bovenste lijn tonen de latentie en doorvoer van het model op de y-as met een toenemend aantal gelijktijdige clientwerknemers op de x-as. De onderste staafdiagrammen tonen het aantal geslaagde en mislukte verzoeken.

Als we alle door ons geteste computer vision-modellen bekijken, zien we het volgende:

• Latentie (in milliseconden) is hoger en doorvoer (verzoeken per seconde) is lager voor grotere modellen (resnet50 > convnext_base > vit_large_patch16_224).
• De toename van de latentie is evenredig met het aantal gebruikers naarmate er meer verzoeken in de wachtrij staan ​​op de inferentieserver.
• Grote modellen verbruiken meer rekenresources en kunnen hun maximale doorvoerlimieten bereiken met minder gebruikers dan een kleiner model. Dit wordt waargenomen met de vit_large_patch16_224 model, dat het eerste mislukte verzoek registreerde bij 140 gelijktijdige gebruikers. Omdat het aanzienlijk groter was dan de andere twee geteste modellen, had het ook de meeste mislukte verzoeken bij hogere gelijktijdigheid. Dit is een duidelijk signaal dat het eindpunt verder moet schalen dan een enkele instantie als het de bedoeling is om meer dan 140 gelijktijdige gebruikers te ondersteunen.

Aan het einde van de notebookrun krijgt u ook een samenvattende vergelijking van PyTorch vs. TensorRT-modellen voor elk van de vier belangrijkste statistieken. Uit onze benchmarktests zagen de CV-modellen allemaal een boost in modelprestaties na TensorRT-compilatie. Onze nemen ResNet50 model weer als voorbeeld, daalde de latentie met 32% terwijl de doorvoer met 18% toenam. Hoewel het maximale aantal gelijktijdige gebruikers hetzelfde bleef voor ResNet50, zagen de andere twee modellen beide een verbetering van 14% in het aantal gelijktijdige gebruikers dat ze kunnen ondersteunen. De prestatieverbetering van TensorRT ging echter ten koste van een hoger geheugengebruik, wat resulteerde in minder modellen die door MME's werden geladen. De impact is meer voor modellen die een convolutioneel neuraal netwerk (CNN) gebruiken. Ons ResNet50-model verbruikte zelfs ongeveer twee keer zoveel GPU-geheugen van PyTorch naar TensorRT, wat resulteerde in 50% minder geladen modellen (46 vs. 23). We diagnosticeren dit gedrag verder in de volgende sectie.

Benchmarkresultaten voor NLP-modellen

Gebruik voor de NLP-modellen het notitieblok nlp-benchmark.ipynb om de belastingstest uit te voeren. De opzet van de notebook zou er ongeveer hetzelfde uit moeten zien. We hebben twee NLP-modellen getest: bert-base-uncased (109M) en roberta-large (335M). Het vooraf getrainde model en de tokenizer worden beide gedownload van de Hugging Face-hub en de testpayload wordt gegenereerd vanuit de tokenizer met behulp van een voorbeeldtekenreeks. De maximale reekslengte is standaard 128. Als u langere reeksen moet testen, vergeet dan niet om die parameter aan te passen. Het doorlopen van het NLP-notebook genereert dezelfde set visualisaties: Pytorch (links) versus TensorRT (rechts).

Hieruit zagen we nog meer prestatievoordeel van TensorRT voor NLP-modellen. Het nemen van de roberta-large model op een ml.g4dn.2xlarge-instantie bijvoorbeeld, daalde de inferentielatentie dramatisch van 180 milliseconden naar 56 milliseconden (een verbetering van 70%), terwijl de doorvoer met 406% verbeterde van 33 verzoeken per seconde naar 167. Bovendien is het maximale aantal gelijktijdige gebruikers verhoogd met 50%; mislukte verzoeken werden pas waargenomen toen we 180 gelijktijdige gebruikers bereikten, vergeleken met 120 voor het oorspronkelijke PyTorch-model. In termen van geheugengebruik zagen we één model minder geladen voor TensorRT (van negen modellen naar acht). De negatieve impact is echter veel kleiner in vergelijking met wat we hebben waargenomen met de op CNN gebaseerde modellen.

Analyse van geheugengebruik

De volgende tabel toont de volledige analyse van de impact op het geheugengebruik van PyTorch naar TensorRT. We vermeldden eerder dat op CNN gebaseerde modellen negatiever worden beïnvloed. De ResNet50 model had een vermindering van meer dan 50% in het aantal geladen modellen voor alle drie de GPU-instantietypen. Convnext_base had een nog grotere reductie van ongeveer 70% over de hele linie. Aan de andere kant is de impact op de transformatormodellen klein of gemengd. vit_large_patch16_224 en roberta-large had een gemiddelde reductie van respectievelijk circa 20% en 3% bert-base-uncased had een verbetering van ongeveer 40%.

Als we kijken naar alle gegevenspunten als geheel met betrekking tot de superieure prestaties op het gebied van latentie, doorvoer en betrouwbaarheid, en de kleine impact op het maximale aantal geladen modellen, raden we het TensorRT-model aan voor op transformatoren gebaseerde modelarchitecturen. Voor CNN's zijn we van mening dat verdere analyse van de kostenprestaties nodig is om ervoor te zorgen dat het prestatievoordeel opweegt tegen de kosten van extra hostinginfrastructuur.

De volgende tabellen geven een overzicht van onze volledige benchmarkresultaten voor alle statistieken voor alle drie typen GPU-instanties.

De volgende tabel geeft een overzicht van de resultaten voor alle instantietypen. De instantie ml.g5.2xlarge levert de beste prestaties, terwijl de instantie ml.p3.2xlarge over het algemeen ondermaats presteert ondanks dat het de duurste van de drie is. De g5- en g4dn-exemplaren bieden de beste waarde voor inferentieworkloads.

Opruimen

Nadat u uw belastingstest hebt voltooid, ruimt u de gegenereerde bronnen op om extra kosten te voorkomen. De belangrijkste bronnen zijn de SageMaker-eindpunten en modelartefactbestanden in Amazon S3. Om het u gemakkelijk te maken, hebben de notebookbestanden de volgende opschooncode om u te helpen ze te verwijderen:

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

Conclusie

In dit bericht hebben we onze testresultaten en analyse gedeeld voor verschillende diepe neurale netwerkmodellen die draaien op SageMaker multi-model endpoints met GPU. De resultaten en inzichten die we hebben gedeeld, zouden een redelijke dwarsdoorsnede moeten bieden van de prestaties van verschillende statistieken en instantietypen. Tijdens het proces hebben we ook onze aanbevolen benadering geïntroduceerd om benchmarktests uit te voeren voor SageMaker MME's met GPU. De tools en voorbeeldcode die we hebben verstrekt, kunnen u helpen snel aan de slag te gaan met uw benchmarktests en een beter geïnformeerde beslissing nemen over hoe u honderden DNN-modellen kosteneffectief kunt hosten op versnelde computerhardware. Om aan de slag te gaan met het benchmarken van uw eigen modellen met MME-ondersteuning voor GPU, raadpleegt u Ondersteunde algoritmen, frameworks en instances en GitHub repo voor aanvullende voorbeelden en documentatie.

Over de auteurs

James Wu is Senior AI/ML Specialist Solution Architect bij AWS. klanten helpen bij het ontwerpen en bouwen van AI/ML-oplossingen. James' werk omvat een breed scala aan ML-gebruikscasussen, met een primaire interesse in computervisie, deep learning en het opschalen van ML in de hele onderneming. Voordat hij bij AWS kwam, was James meer dan 10 jaar architect, ontwikkelaar en technologieleider, waarvan 6 jaar in engineering en 4 jaar in marketing- en reclamesectoren.

Vikram Elango is een AI/ML Specialist Solutions Architect bij Amazon Web Services, gevestigd in Virginia, VS. Vikram helpt klanten uit de financiële en verzekeringssector met design en thought leadership om machine learning-applicaties op grote schaal te bouwen en te implementeren. Hij is momenteel gefocust op natuurlijke taalverwerking, verantwoorde AI, inferentie-optimalisatie en het opschalen van ML in de hele onderneming. In zijn vrije tijd houdt hij van reizen, wandelen, koken en kamperen met zijn gezin.

Simon Zamarin is een AI / ML Solutions Architect die zich voornamelijk richt op het helpen van klanten om waarde uit hun data-assets te halen. In zijn vrije tijd brengt Simon graag tijd door met familie, leest hij sci-fi en werkt hij aan verschillende doe-het-zelfprojecten.

Saurabh Trikande is Senior Product Manager voor Amazon SageMaker Inference. Hij heeft een passie voor het werken met klanten en wordt gemotiveerd door het doel om machine learning te democratiseren. Hij richt zich op kernuitdagingen met betrekking tot het inzetten van complexe ML-applicaties, multi-tenant ML-modellen, kostenoptimalisaties en het toegankelijker maken van de inzet van deep learning-modellen. In zijn vrije tijd houdt Saurabh van wandelen, leren over innovatieve technologieën, TechCrunch volgen en tijd doorbrengen met zijn gezin.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• Platoblockchain. Web3 Metaverse Intelligentie. Kennis versterkt. Toegang hier.
• Bron: https://aws.amazon.com/blogs/machine-learning/achieve-high-performance-at-scale-for-model-serving-using-amazon-sagemaker-multi-model-endpoints-with-gpu/