Bereik hyperscale-prestaties voor modelserving met NVIDIA Triton Inference Server op Amazon SageMaker

Machine learning (ML)-applicaties zijn complex om te implementeren en vereisen vaak meerdere ML-modellen om een ​​enkel deductieverzoek te verwerken. Een typisch verzoek kan over meerdere modellen stromen met stappen zoals voorverwerking, gegevenstransformaties, logica voor modelselectie, modelaggregatie en naverwerking. Dit heeft geleid tot de evolutie van gemeenschappelijke ontwerppatronen, zoals seriële inferentiepijplijnen, ensembles (verspreidingsverzameling) en bedrijfslogica-workflows, resulterend in het realiseren van de volledige workflow van het verzoek als een Directed Acyclic Graph (DAG). Naarmate workflows echter complexer worden, leidt dit tot een toename van de algehele responstijden of latentie van deze applicaties, wat op zijn beurt invloed heeft op de algehele gebruikerservaring. Bovendien, als deze componenten op verschillende instanties worden gehost, verhoogt de extra netwerklatentie tussen deze instanties de algehele latentie. Overweeg een voorbeeld van een populaire ML-use-case voor een virtuele assistent in klantenondersteuning. Een typisch verzoek moet mogelijk verschillende stappen doorlopen, waaronder spraakherkenning, natuurlijke taalverwerking (NLP), het volgen van dialoogstatus, dialoogbeleid, het genereren van tekst en ten slotte tekst-naar-spraak. Om de gebruikersinteractie persoonlijker te maken, kunt u bovendien geavanceerde, op transformatoren gebaseerde NLP-modellen gebruiken, zoals verschillende versies van BERT, BART en GPT. Het eindresultaat is lange responstijden voor deze modellenensembles en een slechte klantervaring.

Een veelvoorkomend patroon om kortere responstijden te realiseren zonder de algehele doorvoer in gevaar te brengen, is om deze modellen op dezelfde instantie te hosten, samen met de lichtgewicht bedrijfslogica die erin is ingebed. Deze modellen kunnen verder worden ingekapseld in enkele of meerdere containers op dezelfde instantie om isolatie te bieden voor lopende processen en de latentie laag te houden. Bovendien hangt de algehele latentie ook af van de toepassingslogica, modeloptimalisaties, de onderliggende infrastructuur (inclusief rekenkracht, opslag en netwerken) en de onderliggende webserver die gevolgtrekkingsverzoeken accepteert. NVIDIA Triton Inference-server is een open-source inferentieservicesoftware met functies om de doorvoer en het hardwaregebruik te maximaliseren met ultralage (eencijferige milliseconden) inferentielatentie. Het heeft brede ondersteuning van ML-frameworks (waaronder TensorFlow, PyTorch, ONNX, XGBoost en NVIDIA TensorRT) en infrastructuur-backends, waaronder GPU's, CPU's en AWS Inferentie. Bovendien is Triton Inference Server geïntegreerd met Amazon Sage Maker, een volledig beheerde end-to-end ML-service, die real-time inferentie-opties biedt, waaronder single en multi-model hosting. Deze gevolgtrekkingsopties omvatten het hosten van meerdere modellen binnen dezelfde container achter een enkel eindpunt, en hosting meerdere modellen met meerdere containers achter een enkel eindpunt.

In november 2021 maakten we bekend de integratie van Triton Inference Server op SageMaker. AWS werkte nauw samen met NVIDIA om u in staat te stellen het beste uit twee werelden te halen en de implementatie van modellen met Triton op AWS eenvoudiger te maken.

In dit bericht bekijken we best practices voor het op grote schaal inzetten van transformatormodellen op GPU's met behulp van Triton Inference Server op SageMaker. Eerst beginnen we met een samenvatting van de belangrijkste concepten rond latentie in SageMaker en een overzicht van richtlijnen voor het afstemmen van prestaties. Vervolgens geven we een overzicht van Triton en zijn functies, evenals voorbeeldcode voor implementatie op SageMaker. Ten slotte voeren we belastingtesten uit met behulp van SageMaker Inferentie Aanbeveling en vat de inzichten en conclusies samen van belastingtesten van een populair transformatormodel van Hugging Face.

U kunt de bekijken notitieboekje Vroeger implementeerden we modellen en voerden we zelf belastingstests uit met behulp van de code op GitHub.

Prestatieafstemming en optimalisatie voor modelweergave op SageMaker

Het afstemmen en optimaliseren van prestaties is een empirisch proces waarbij vaak meerdere iteraties betrokken zijn. Het aantal af te stemmen parameters is combinatorisch en de set configuratieparameterwaarden is niet onafhankelijk van elkaar. Verschillende factoren zijn van invloed op de optimale afstemming van parameters, waaronder de grootte, het type en het aantal ML-modellen van de ML-modellen in de stroomgrafiek van de inferentieverzoeken, het opslagtype, het type rekeninstantie, de netwerkinfrastructuur, de toepassingscode, de runtime en configuratie van de software voor inferentiediensten, en meer.

Als u SageMaker gebruikt voor het implementeren van ML-modellen, moet u een rekeninstantie selecteren met de beste prijs-prestatieverhouding, wat een gecompliceerd en iteratief proces is dat weken van experimenteren kan vergen. Eerst moet u het juiste ML-instantietype kiezen uit meer dan 70 opties op basis van de resourcevereisten van uw modellen en de grootte van de invoergegevens. Vervolgens moet u het model optimaliseren voor het geselecteerde instantietype. Ten slotte moet u de infrastructuur inrichten en beheren om belastingstests uit te voeren en de cloudconfiguratie af te stemmen voor optimale prestaties en kosten. Dit alles kan de implementatie van modellen en de time-to-market vertragen. Bovendien moet u de wisselwerking tussen latentie, doorvoer en kosten evalueren om de optimale implementatieconfiguratie te selecteren. SageMaker Inferentie Aanbeveling selecteert automatisch het juiste type rekeninstance, het aantal instances, containerparameters en modeloptimalisaties voor gevolgtrekkingen om de doorvoer te maximaliseren, latentie te verminderen en kosten te minimaliseren.

Realtime gevolgtrekking en latentie in SageMaker

SageMaker realtime gevolgtrekking is ideaal voor inferentieworkloads waarbij u real-time, interactieve vereisten met lage latentie hebt. Er zijn vier meest gebruikte metrische gegevens voor het bewaken van de latentie van inferentieverzoeken voor SageMaker-inferentie-eindpunten

• Containerlatentie – De tijd die nodig is om het verzoek te verzenden, het antwoord uit de container van het model op te halen en de conclusie in de container te voltooien. Deze statistiek is beschikbaar in Amazon CloudWatch als onderdeel van de Aanroepstatistieken uitgegeven door SageMaker.
• Modellatentie – De totale tijd die alle SageMaker-containers in een inferentie pijplijn. Deze statistiek is beschikbaar in Amazon CloudWatch als onderdeel van de Aanroepstatistieken uitgegeven door SageMaker.
• Overhead latentie – Gemeten vanaf het moment dat SageMaker het verzoek ontvangt totdat het een antwoord naar de client retourneert, minus de modellatentie. Deze statistiek is beschikbaar in Amazon CloudWatch als onderdeel van de Aanroepstatistieken uitgegeven door SageMaker.
• End-to-end latentie – Gemeten vanaf het moment dat de client het inferentieverzoek verzendt totdat deze een antwoord terugkrijgt. Klanten kunnen dit publiceren als een aangepaste statistiek in Amazon CloudWatch.

Het volgende diagram illustreert deze componenten.

De latentie van containers is afhankelijk van verschillende factoren; de volgende behoren tot de belangrijkste:

• Onderliggend protocol (HTTP('s)/gRPC) gebruikt om te communiceren met de inferentieserver
• Overhead gerelateerd aan het maken van nieuwe TLS-verbindingen
• Deserialisatietijd van de aanvraag/antwoord-payload
• Queuing- en batchfuncties aanvragen die worden geleverd door de onderliggende inferentieserver
• Vraag planningsmogelijkheden geleverd door de onderliggende inferentieserver
• Onderliggende runtime-prestaties van de inferentieserver
• Prestaties van preprocessing- en postprocessing-bibliotheken voordat de modelvoorspellingsfunctie wordt aangeroepen
• Onderliggende back-endprestaties van ML-framework
• Modelspecifieke en hardwarespecifieke optimalisaties

In dit bericht richten we ons voornamelijk op het optimaliseren van de containerlatentie, samen met de algehele doorvoer en kosten. We onderzoeken met name prestatieafstemming Triton Inference Server die in een SageMaker-container draait.

Gebruik case-overzicht

Het implementeren en schalen van NLP-modellen in een productieopstelling kan behoorlijk uitdagend zijn. NLP-modellen zijn vaak erg groot en bevatten miljoenen modelparameters. Er zijn optimale modelconfiguraties vereist om te voldoen aan de strenge prestatie- en schaalbaarheidseisen van NLP-toepassingen op productieniveau.

In dit bericht benchmarken we een NLP-use-case met behulp van een real-time eindpunt van SageMaker op basis van een Triton Inference Server-container en bevelen we prestatieafstemmingsoptimalisaties aan voor onze ML-use-case. We gebruiken een grote, vooraf getrainde, op transformatoren gebaseerde Hugging Face BERT groot onverpakt model, dat ongeveer 336 miljoen modelparameters heeft. De invoerzin die wordt gebruikt voor het binaire classificatiemodel wordt opgevuld en afgekapt tot een maximale lengte van de invoerreeks van 512 tokens. De inferentiebelastingstest simuleert 500 aanroepen per seconde (maximaal 30,000 aanroepen per minuut) en ModelLatency van minder dan 0.5 seconden (500 milliseconden).

De volgende tabel vat onze benchmarkconfiguratie samen.

NVIDIA Triton Inference-server

Triton Inference Server is speciaal ontworpen om schaalbare, snelle en eenvoudige implementatie van modellen in productie mogelijk te maken. Triton ondersteunt verschillende belangrijke AI-frameworks, waaronder TensorFlow, TensorRT, PyTorch, XGBoost en ONNX. Met de aangepaste backend van Python en C++ kunt u uw inferentiewerklast ook implementeren voor meer op maat gemaakte use-cases.

Het belangrijkste is dat Triton een eenvoudige, op configuratie gebaseerde setup biedt voor het hosten van uw modellen, die een uitgebreide reeks prestatie-optimalisatiefuncties blootlegt die u kunt gebruiken met weinig codeerinspanning.

Triton verbetert de inferentieprestaties door het hardwaregebruik te maximaliseren met verschillende optimalisatietechnieken (gelijktijdige modelruns en dynamische batching worden het meest gebruikt). Het vinden van de optimale modelconfiguraties uit verschillende combinaties van dynamische batchgroottes en het aantal gelijktijdige modelexemplaren is de sleutel tot real-time gevolgtrekking binnen goedkope services met behulp van Triton.

Dynamische batchverwerking

Veel beoefenaars hebben de neiging om inferentie opeenvolgend uit te voeren wanneer de server wordt aangeroepen met meerdere onafhankelijke verzoeken. Hoewel het eenvoudiger is om in te stellen, is het meestal niet de beste manier om de rekenkracht van de GPU te gebruiken. Om dit aan te pakken, biedt Triton de ingebouwde optimalisaties van dynamisch batchen om deze onafhankelijke inferentieverzoeken aan de serverzijde te combineren om dynamisch een grotere batch te vormen om de doorvoer te vergroten. Het volgende diagram illustreert de Triton-runtime-architectuur.

In de voorgaande architectuur bereiken alle aanvragen eerst de dynamische batcher voordat ze de werkelijke wachtrijen van de modelplanner binnenkomen om te wachten op gevolgtrekking. U kunt uw gewenste batchgroottes voor dynamische batching instellen met behulp van de gewenste_batch_grootte instellingen in de modelconfiguratie. (Merk op dat de gevormde batchgrootte kleiner moet zijn dan de max_batch_grootte het model ondersteunt.) U kunt ook configureren max_queue_delay_microseconden om de maximale vertragingstijd in de batcher op te geven om te wachten op andere verzoeken om deel te nemen aan de batch op basis van uw latentievereisten.

Het volgende codefragment laat zien hoe u deze functie kunt toevoegen met modelconfiguratiebestanden om dynamische batching in te stellen met een voorkeursbatchgrootte van 16 voor de daadwerkelijke gevolgtrekking. Met de huidige instellingen wordt de modelinstantie onmiddellijk aangeroepen wanneer de gewenste batchgrootte van 16 is bereikt of de vertragingstijd van 100 microseconden is verstreken sinds het eerste verzoek de dynamische batcher bereikte.

dynamic_batching { preferred_batch_size: 16 max_queue_delay_microseconds: 100 }

Modellen gelijktijdig uitvoeren

Een andere essentiële optimalisatie die wordt aangeboden in Triton om het hardwaregebruik te maximaliseren zonder extra latency-overhead is gelijktijdige modeluitvoering, waarmee meerdere modellen of meerdere exemplaren van hetzelfde model parallel kunnen worden uitgevoerd. Deze functie stelt Triton in staat om meerdere inferentieverzoeken tegelijkertijd af te handelen, wat de deductiedoorvoer verhoogt door gebruik te maken van anders inactieve rekenkracht op de hardware.

De volgende afbeelding laat zien hoe u eenvoudig verschillende beleidsregels voor modelimplementatie kunt configureren met slechts een paar regels codewijzigingen. Configuratie A (links) laat bijvoorbeeld zien dat u dezelfde configuratie van twee modelexemplaren kunt uitzenden bert-large-uncased naar alle beschikbare GPU's. Configuratie B (midden) toont daarentegen alleen een andere configuratie voor GPU 0, zonder het beleid op de andere GPU's te wijzigen. U kunt ook instanties van verschillende modellen op één GPU implementeren, zoals weergegeven in configuratie C (rechts).

In configuratie C kan de rekeninstantie twee gelijktijdige verzoeken voor het DistilGPT-2-model en zeven gelijktijdige verzoeken voor het bert-large-uncased parallel modelleren. Met deze optimalisaties kunnen de hardwareresources beter worden gebruikt voor het serveringproces, waardoor de doorvoer verbetert en uw werklast kostenefficiënter wordt.

TensorRT

NVIDIA TensorRT is een SDK voor high-performance deep learning-inferentie die naadloos samenwerkt met Triton. TensorRT, dat elk belangrijk deep learning-framework ondersteunt, bevat een inferentie-optimizer en runtime die lage latentie en hoge doorvoer levert om inferenties uit te voeren met enorme hoeveelheden gegevens via krachtige optimalisaties.

TensorRT optimaliseert de grafiek om de geheugenvoetafdruk te minimaliseren door onnodig geheugen vrij te maken en efficiënt te hergebruiken. Bovendien combineert de TensorRT-compilatie de schaarse bewerkingen in de modelgrafiek om een ​​grotere kernel te vormen om de overhead van meerdere kleine kernellanceringen te vermijden. Auto-tuning van de kernel helpt u de hardware volledig te benutten door het beste algoritme op uw doel-GPU te selecteren. Met CUDA-streams kunnen modellen parallel worden uitgevoerd om uw GPU-gebruik te maximaliseren voor de beste prestaties. Last but not least kan de kwantiseringstechniek de mixed-precision-versnelling van de Tensor-kernen volledig gebruiken om het model in FP32, TF32, FP16 en INT8 uit te voeren om de beste gevolgtrekkingsprestaties te bereiken.

Triton op SageMaker-hosting

SageMaker-hosting services zijn de reeks SageMaker-functies die zijn bedoeld om de implementatie en bediening van modellen te vergemakkelijken. Het biedt een verscheidenheid aan opties voor het eenvoudig implementeren, automatisch schalen, bewaken en optimaliseren van ML-modellen die zijn afgestemd op verschillende gebruikssituaties. Dit betekent dat u uw implementaties kunt optimaliseren voor alle soorten gebruikspatronen, van permanent en altijd beschikbaar met serverloze opties tot tijdelijke, langlopende of batch-inferentiebehoeften.

Onder de SageMaker-hostingparaplu bevindt zich ook de set SageMaker-inferentie Deep Learning Containers (DLC's), die voorverpakt zijn met de juiste modelserversoftware voor hun overeenkomstige ondersteunde ML-framework. Hierdoor kunt u hoge inferentieprestaties bereiken zonder configuratie van een modelserver, wat vaak het meest complexe technische aspect van modelimplementatie is en in het algemeen geen deel uitmaakt van de vaardigheden van een datawetenschapper. Triton-inferentieserver is nu Beschikbaar op SageMaker Deep Learning-containers (DLC).

Dit brede scala aan opties, modulariteit en gebruiksgemak van verschillende serveerframes maakt SageMaker en Triton een krachtige match.

SageMaker Inference Recommender voor het benchmarken van testresultaten

We gebruiken SageMaker Inference Recommender om onze experimenten uit te voeren. SageMaker Inference Recommender biedt twee soorten taken: standaard en geavanceerd, zoals geïllustreerd in het volgende diagram.

De standaardtaak biedt aanbevelingen voor instantietypen met alleen het model en een voorbeeld van een payload om te benchmarken. Naast instantie-aanbevelingen biedt de service ook runtime-parameters die de prestaties verbeteren. De aanbevelingen van de standaardtaak zijn bedoeld om het zoeken naar instanties te beperken. In sommige gevallen kan het de instantiefamilie zijn, en in andere gevallen kunnen het de specifieke instantietypen zijn. De resultaten van de standaardtaak worden vervolgens ingevoerd in de geavanceerde taak.

De geavanceerde taak biedt meer bedieningselementen om de prestaties verder te verfijnen. Deze controles simuleren de echte omgeving en productie-eisen. Een van deze controles is het verkeerspatroon, dat tot doel heeft het verzoekpatroon voor de benchmarks in scène te zetten. U kunt hellingen of constant verkeer instellen door gebruik te maken van de meerdere fasen van het verkeerspatroon. Bijvoorbeeld een InitialNumberOfUsers van 1, Spawnsnelheid van 1, en DuurInSeconden van 600 kan resulteren in platformverkeer van 10 minuten met 1 gelijktijdige gebruiker aan het begin en 10 aan het einde. Bovendien, op de bedieningselementen, MaxInvocaties en Modellatentiedrempels stel de productiedrempel in, dus wanneer een van de drempels wordt overschreden, stopt de benchmarking.

Tenslotte aanbevelingsstatistieken omvatten doorvoer, latentie bij maximale doorvoer en kosten per gevolgtrekking, dus het is gemakkelijk om ze te vergelijken.

We gebruiken het geavanceerde taaktype van SageMaker Inference Recommender om onze experimenten uit te voeren om extra controle te krijgen over de verkeerspatronen en om de configuratie van de dienende container te verfijnen.

Experimentopstelling

We gebruiken de aangepaste belastingstestfunctie van SageMaker Inference Recommender om het NLP-profiel zoals beschreven in onze use case te benchmarken. We definiëren eerst de volgende vereisten met betrekking tot het NLP-model en de ML-taak. SageMaker Inference Recommender gebruikt deze informatie om een ​​inferentie Docker-image op te halen Amazon Elastic Container-register (Amazon ECR) en registreer het model bij het SageMaker-modelregister.

Met de verkeerspatroonconfiguraties in SageMaker Inference Recommender kunnen we verschillende fasen definiëren voor de aangepaste belastingstest. De belastingstest begint met twee eerste gebruikers en genereert elke minuut twee nieuwe gebruikers, voor een totale duur van 25 minuten (1500 seconden), zoals weergegeven in de volgende code:

"TrafficPattern": { "TrafficType": "PHASES", "Phases": [ { "InitialNumberOfUsers": 2, "SpawnRate": 2, "DurationInSeconds": 1500 }, ],
}

We experimenteren met belastingstests van hetzelfde model in twee verschillende toestanden. De op PyTorch gebaseerde experimenten gebruiken het standaard, ongewijzigde PyTorch-model. Voor de op TensorRT gebaseerde experimenten zetten we het PyTorch-model vooraf om in een TensorRT-engine.

We passen verschillende combinaties van de functies voor prestatieoptimalisatie toe op deze twee modellen, samengevat in de volgende tabel.

Testresultaten en observaties

We hebben belastingstests uitgevoerd voor drie instantietypen binnen dezelfde g4dn-familie: ml.g4dn.xlarge, ml.g4dn.2xlarge en ml.g4dn.12xlarge. Alle g4dn-instantietypen hebben toegang tot NVIDIA T4 Tensor Core GPU's en 2e generatie Intel Cascade Lake-processors. De logica achter de keuze van instantietypen was om zowel een instantie te hebben met slechts één GPU beschikbaar, als een instantie met toegang tot meerdere GPU's - vier in het geval van ml.g4dn.12xlarge. Daarnaast wilden we testen of het verhogen van de vCPU-capaciteit op de instantie met slechts één beschikbare GPU een verbetering van de kosten-prestatieverhouding zou opleveren.

Laten we eerst de versnelling van de individuele optimalisatie bekijken. De volgende grafiek laat zien dat TensorRT-optimalisatie zorgt voor een vermindering van 50% in modellatentie in vergelijking met de oorspronkelijke in PyTorch op de ml.g4dn.xlarge-instantie. Deze vertragingsvermindering groeit tot meer dan drie keer op de multi-GPU-instanties van ml.g4dn.12xlarge. Ondertussen is de doorvoerverbetering van 30% consistent in beide gevallen, wat resulteert in een betere kosteneffectiviteit na het toepassen van TensorRT-optimalisaties.

Met dynamische batching kunnen we bijna 2x verbetering in doorvoer krijgen met dezelfde hardware-architectuur op alle experimenten van ml.g4dn.xlarge, ml.g4dn.2xlarge en ml.g4dn.12xlarge zonder merkbare toename van de latentie.

Evenzo stelt gelijktijdige modeluitvoering ons in staat om ongeveer 3-4x verbetering in doorvoer te verkrijgen door het GPU-gebruik te maximaliseren op ml.g4dn.xlarge-instantie en ongeveer 2x verbetering op zowel de ml.g4dn.2xlarge-instantie als de multi-GPU-instantie van ml. g4dn.12xlarge.. Deze doorvoerverhoging komt zonder enige overhead in de latentie.

Sterker nog, we kunnen al deze optimalisaties integreren om de beste prestaties te leveren door de hardwarebronnen ten volle te benutten. De volgende tabel en grafieken vatten de resultaten samen die we in onze experimenten hebben verkregen.

[1] Het aanvankelijke aantal exemplaren in de bovenstaande tabel is het aanbevolen aantal exemplaren dat moet worden gebruikt met een beleid voor automatisch schalen om de doorvoer- en latentievereisten voor uw werkbelasting te behouden.

[2] De kosten per uur in de bovenstaande tabel worden berekend op basis van het aantal eerste exemplaren en de prijs voor het type exemplaar.

Resultaten valideren meestal de impact die werd verwacht van verschillende functies voor prestatieoptimalisatie:

• TensorRT-compilatie heeft de meest betrouwbare impact op alle instantietypen. Transacties per minuut per instantie namen toe met 30-35%, met een consistente kostenverlaging van ongeveer 25% in vergelijking met de prestaties van de TensorRT-engine ten opzichte van de standaard PyTorch BERT (pt-base). De verbeterde prestaties van de TensorRT-engine worden versterkt door en benut door de andere geteste prestatieafstemmingsfuncties.
• Door twee modellen op elke GPU (instantiegroep) te laden, werden alle gemeten statistieken bijna strikt verdubbeld. Aanroepen per minuut per instantie namen met ongeveer 80-90% toe, wat een kostenverlaging van 50% opleverde, bijna alsof we twee GPU's gebruikten. In werkelijkheid, Amazon Cloud Watch statistieken voor onze experimenten op g4dn.2xlarge (als voorbeeld) bevestigen dat zowel CPU- als GPU-gebruik verdubbelt wanneer we een instantiegroep van twee modellen configureren.

Verdere tips voor prestatie- en kostenoptimalisatie

De benchmark die in dit bericht wordt gepresenteerd, heeft zojuist de oppervlakte bekrast van de mogelijke functies en technieken die u met Triton kunt gebruiken om de inferentieprestaties te verbeteren. Deze variëren van technieken voor het voorbewerken van gegevens, zoals het verzenden van binaire payloads naar de modelserver of payloads met grotere batches, tot native Triton-functies, zoals de volgende:

• Modelopwarming, waarmee initiële, langzame deductieverzoeken worden voorkomen door het model volledig te initialiseren voordat het eerste deductieverzoek wordt ontvangen.
• Reactiecache, die herhaalde verzoeken in de cache opslaat.
• Model samenstellen, waarmee u een pijplijn van een of meer modellen kunt maken en de invoer- en uitvoertensoren tussen die modellen kunt verbinden. Dit opent de mogelijkheid om preprocessing- en postprocessing-stappen toe te voegen, of zelfs gevolgtrekkingen met andere modellen, aan de verwerkingsstroom voor elk verzoek.

We verwachten deze technieken en functies in een toekomstige post te testen en te benchmarken, dus houd het in de gaten!

Conclusie

In dit bericht hebben we enkele parameters onderzocht die u kunt gebruiken om de prestaties van uw SageMaker real-time eindpunt te maximaliseren voor het bedienen van PyTorch BERT-modellen met Triton Inference Server. We hebben SageMaker Inference Recommender gebruikt om de benchmarktests uit te voeren om deze parameters te verfijnen. Deze parameters zijn in wezen gerelateerd aan op TensorRT gebaseerde modeloptimalisatie, wat leidt tot bijna 50% verbetering in responstijden in vergelijking met de niet-geoptimaliseerde versie. Bovendien leidde het gelijktijdig draaien van modellen en het gebruik van dynamische batching van Triton tot een toename van de doorvoer met bijna 70%. Het nauwkeurig afstemmen van deze parameters leidde ook tot een algehele verlaging van de inferentiekosten.

De beste manier om de juiste waarden af ​​te leiden, is door te experimenteren. Om echter empirische kennis op te bouwen over het afstemmen en optimaliseren van prestaties, kunt u de combinaties van verschillende Triton-gerelateerde parameters en hun effect op de prestaties van ML-modellen en SageMaker ML-instanties observeren.

SageMaker biedt de tools om het ongedifferentieerde zware werk uit elke fase van de ML-levenscyclus te verwijderen, waardoor het snelle experimenteren en verkennen wordt vergemakkelijkt dat nodig is om uw modelimplementaties volledig te optimaliseren.

U vindt de notebook die wordt gebruikt voor het testen en implementeren van de belasting op GitHub. U kunt Triton-configuraties en SageMaker Inference Recommender-instellingen bijwerken zodat deze het beste passen bij uw gebruiksscenario om kosteneffectieve en best presterende inferentie-workloads te realiseren.

Over de auteurs

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.

Joao Moura is een AI/ML Specialist Solutions Architect bij Amazon Web Services. Hij richt zich vooral op NLP-use-cases en helpt klanten bij het optimaliseren van Deep Learning-modeltraining en -implementatie. Hij is ook een actief voorstander van low-code ML-oplossingen en ML-gespecialiseerde hardware.

Mohan Ghandi is Senior Software Engineer bij AWS. Hij werkt al 9 jaar bij AWS en heeft aan verschillende AWS-services gewerkt, zoals EMR, EFA en RDS op Outposts. Momenteel richt hij zich op het verbeteren van de SageMaker Inference Experience. In zijn vrije tijd houdt hij van wandelen en marathons lopen.

Dhawal Patel is een Principal Machine Learning Architect bij AWS. Hij heeft gewerkt met organisaties variërend van grote ondernemingen tot middelgrote startups aan problemen met betrekking tot gedistribueerde computing en kunstmatige intelligentie. Hij richt zich op Deep learning inclusief NLP en Computer Vision domeinen. Hij helpt klanten bij het bereiken van high-performance modelinferentie op SageMaker.

Santosh Bhavani is Senior Technical Product Manager bij het Amazon SageMaker Elastic Inference-team. Hij richt zich op het helpen van SageMaker-klanten bij het versnellen van modelinferentie en -implementatie. In zijn vrije tijd houdt hij van reizen, tennissen en veel Pu'er-thee drinken.

Jiahong Liu is Solution Architect in het Cloud Service Provider-team van NVIDIA. Hij helpt klanten bij het adopteren van machine learning en AI-oplossingen die gebruikmaken van NVIDIA Accelerated Computing om hun trainings- en inferentie-uitdagingen aan te pakken. In zijn vrije tijd houdt hij van origami, doe-het-zelfprojecten en basketbal.

• Coinsmart. Europa's beste Bitcoin- en crypto-uitwisseling.
• Platoblockchain. Web3 Metaverse Intelligentie. Kennis versterkt. GRATIS TOEGANG.
• CryptoHawk. Altcoin-radar. Gratis proefversie.
• Bron: https://aws.amazon.com/blogs/machine-learning/achieve-hyperscale-performance-for-model-serving-using-nvidia-triton-inference-server-on-amazon-sagemaker/