Uppnå hyperskalig prestanda för modellvisning med NVIDIA Triton Inference Server på Amazon SageMaker

Applikationer för maskininlärning (ML) är komplicerade att implementera och kräver ofta flera ML-modeller för att tjäna en enda slutledningsbegäran. En typisk begäran kan flöda över flera modeller med steg som förbearbetning, datatransformationer, modellvalslogik, modellaggregation och efterbearbetning. Detta har lett till utvecklingen av vanliga designmönster som seriella inferenspipelines, ensembler (scatter collection) och affärslogiska arbetsflöden, vilket resulterat i att hela arbetsflödet för begäran realiseras som en Directed Acyclic Graph (DAG). Men eftersom arbetsflöden blir mer komplexa leder detta till en ökning av den totala svarstiden, eller latens, för dessa applikationer, vilket i sin tur påverkar den övergripande användarupplevelsen. Dessutom, om dessa komponenter finns på olika instanser, ökar den ytterligare nätverkslatensen mellan dessa instanser den totala latensen. Betrakta ett exempel på ett populärt ML-användningsfall för en virtuell assistent i kundsupport. En typisk begäran kan behöva gå igenom flera steg som involverar taligenkänning, naturlig språkbehandling (NLP), spårning av dialogtillstånd, dialogpolicy, textgenerering och slutligen text till tal. Dessutom, för att göra användarinteraktionen mer personlig kan du också använda toppmoderna, transformatorbaserade NLP-modeller som olika versioner av BERTI, BARToch GPT. Slutresultatet är långa svarstider för dessa modellensembler och en dålig kundupplevelse.

Ett vanligt mönster för att få lägre svarstider utan att kompromissa med den totala genomströmningen är att vara värd för dessa modeller på samma instans tillsammans med den lätta affärslogik som är inbäddad i den. Dessa modeller kan vidare kapslas in i enstaka eller flera behållare på samma instans för att ge isolering för pågående processer och hålla latensen låg. Dessutom beror den totala latensen också på slutledningsapplikationslogik, modelloptimeringar, underliggande infrastruktur (inklusive beräkning, lagring och nätverk) och den underliggande webbservern som tar emot begäranden om slutledning. NVIDIA Triton Inference Server är en öppen källkodsmjukvara för slutledningsbetjäning med funktioner för att maximera genomströmning och hårdvaruanvändning med ultralåg (ensiffriga millisekunder) slutledningslatens. Den har brett stöd för ML-ramverk (inklusive TensorFlow, PyTorch, ONNX, XGBoost och NVIDIA TensorRT) och infrastrukturbackends, inklusive GPU:er, CPU:er och AWS slutledning. Dessutom är Triton Inference Server integrerad med Amazon SageMaker, en fullständigt hanterad end-to-end ML-tjänst, som ger realtidsalternativ för slutledning inklusive enda och multimodell värdskap. Dessa slutledningsalternativ inkluderar att vara värd för flera modeller inom samma behållare bakom en enda slutpunktoch värd flera modeller med flera behållare bakom en enda slutpunkt.

I november 2021 meddelade vi integrationen av Triton Inference Server på SageMaker. AWS arbetade nära NVIDIA för att göra det möjligt för dig att få det bästa av två världar och göra modelldistribution med Triton på AWS enklare.

I det här inlägget tittar vi på bästa praxis för att distribuera transformatormodeller i stor skala på GPU:er med hjälp av Triton Inference Server på SageMaker. Först börjar vi med en sammanfattning av nyckelbegrepp kring latens i SageMaker, och en översikt över riktlinjer för prestandajustering. Därefter ger vi en översikt över Triton och dess funktioner samt exempelkod för implementering på SageMaker. Slutligen utför vi belastningstester med hjälp av SageMaker Inference Recommender och sammanfatta insikterna och slutsatserna från lasttestning av en populär transformatormodell från Hugging Face.

Du kan granska anteckningsbok vi brukade distribuera modeller och utföra belastningstester på egen hand med hjälp av koden på GitHub.

Prestandajustering och optimering för modellvisning på SageMaker

Prestandajustering och optimering är en empirisk process som ofta involverar flera iterationer. Antalet parametrar som ska ställas in är kombinatoriskt och uppsättningen av konfigurationsparametervärden är inte oberoende av varandra. Olika faktorer påverkar optimal parameterinställning, inklusive nyttolaststorlek, typ och antalet ML-modeller i flödesdiagrammet för slutledningsbegäran, lagringstyp, beräkningsinstanstyp, nätverksinfrastruktur, applikationskod, programvarukörning och konfiguration av slutledningsbetjäning med mera.

Om du använder SageMaker för att distribuera ML-modeller måste du välja en beräkningsinstans med bästa pris-prestanda, vilket är en komplicerad och iterativ process som kan ta veckor av experiment. Först måste du välja rätt ML-instanstyp av över 70 alternativ baserat på resurskraven för dina modeller och storleken på indata. Därefter måste du optimera modellen för den valda instanstypen. Slutligen måste du tillhandahålla och hantera infrastruktur för att köra belastningstester och justera molnkonfigurationen för optimal prestanda och kostnad. Allt detta kan fördröja modellimplementeringen och tiden till marknaden. Dessutom måste du utvärdera avvägningarna mellan latens, genomströmning och kostnad för att välja den optimala distributionskonfigurationen. SageMaker Inference Recommender väljer automatiskt rätt beräkningsinstanstyp, instansantal, containerparametrar och modelloptimeringar för slutledning för att maximera genomströmningen, minska latens och minimera kostnaden.

Realtids slutledning och latens i SageMaker

SageMaker inferens i realtid är idealisk för slutledningsarbetsbelastningar där du har interaktiva realtidskrav med låg latens. Det finns fyra vanligast använda mätvärden för att övervaka inferensbegärans latens för SageMaker slutpunkter för slutpunkter

• Behållarfördröjning – Tiden det tar att skicka förfrågan, hämta svaret från modellens behållare och slutföra slutledning i behållaren. Detta mått är tillgängligt i Amazon CloudWatch som en del av Anropsstatistik publicerad av SageMaker.
• Modellens latens – Den totala tiden som alla SageMaker-containrar tar i en slutledningspipeline. Detta mått är tillgängligt i Amazon CloudWatch som en del av Anropsstatistik publicerad av SageMaker.
• Overhead latens – Mätt från det att SageMaker tar emot förfrågan tills den returnerar ett svar till klienten, minus modellens latens. Detta mått är tillgängligt i Amazon CloudWatch som en del av Anropsstatistik publicerad av SageMaker.
• End-to-end latens – Mätt från det att klienten skickar inferensförfrågan tills den får ett svar tillbaka. Kunder kan publicera detta som ett anpassat mått i Amazon CloudWatch.

Följande diagram illustrerar dessa komponenter.

Behållarens latens beror på flera faktorer; följande är bland de viktigaste:

• Underliggande protokoll (HTTP(s)/gRPC) som används för att kommunicera med slutledningsservern
• Overhead relaterade till att skapa nya TLS-anslutningar
• Deserialiseringstid för begäran/svarets nyttolast
• Begär kö- och batchfunktioner som tillhandahålls av den underliggande slutledningsservern
• Begär schemaläggningsfunktioner som tillhandahålls av den underliggande slutledningsservern
• Underliggande körtidsprestanda för slutledningsservern
• Prestanda för förbearbetnings- och efterbearbetningsbibliotek innan man anropar modellprediktionsfunktionen
• Underliggande ML-ramverk-backend-prestanda
• Modellspecifika och hårdvaruspecifika optimeringar

I det här inlägget fokuserar vi främst på att optimera behållarens latens tillsammans med total genomströmning och kostnad. Specifikt utforskar vi prestandajustering av Triton Inference Server som körs inuti en SageMaker-behållare.

Använda fallöversikt

Att distribuera och skala NLP-modeller i en produktionsuppställning kan vara ganska utmanande. NLP-modeller är ofta mycket stora och innehåller miljontals modellparametrar. Optimala modellkonfigurationer krävs för att tillfredsställa de stränga kraven på prestanda och skalbarhet för NLP-tillämpningar i produktionsklass.

I det här inlägget benchmarkar vi ett NLP-användningsfall med hjälp av en SageMaker-slutpunkt i realtid baserad på en Triton Inference Server-behållare och rekommenderar prestandajusteringsoptimeringar för vårt ML-användningsfall. Vi använder en stor, förutbildad transformatorbaserad Hugging Face BERT stor utan hölje modell, som har cirka 336 miljoner modellparametrar. Inmatningsmeningen som används för den binära klassificeringsmodellen är vadderad och trunkerad till en maximal indatasekvenslängd på 512 tokens. Slutledningsbelastningstestet simulerar 500 anrop per sekund (30,000 XNUMX maximala anrop per minut) och ModelLatency på mindre än 0.5 sekunder (500 millisekunder).

Följande tabell sammanfattar vår benchmark-konfiguration.

NVIDIA Triton Inference Server

Triton Inference Server är speciellt utformad för att möjliggöra skalbar, snabb och enkel distribution av modeller i produktionen. Triton stöder en mängd stora AI-ramverk, inklusive TensorFlow, TensorRT, PyTorch, XGBoost och ONNX. Med Python och C++ anpassade backend kan du också implementera din inferensarbetsbelastning för mer anpassade användningsfall.

Viktigast av allt, Triton tillhandahåller en enkel konfigurationsbaserad installation för att vara värd för dina modeller, som exponerar en rik uppsättning prestandaoptimeringsfunktioner som du kan använda med liten kodningsansträngning.

Triton ökar slutledningsprestanda genom att maximera hårdvaruanvändningen med olika optimeringstekniker (samtidiga modellkörningar och dynamisk batchning är de mest använda). Att hitta de optimala modellkonfigurationerna från olika kombinationer av dynamiska batchstorlekar och antalet samtidiga modellinstanser är nyckeln för att uppnå realtids slutledning inom lågkostnadsservering med Triton.

Dynamisk batchning

Många utövare tenderar att köra slutledning sekventiellt när servern anropas med flera oberoende förfrågningar. Även om det är lättare att installera, är det vanligtvis inte den bästa praxisen att använda GPU:s datorkraft. För att hantera detta erbjuder Triton de inbyggda optimeringar av dynamisk batchning att kombinera dessa oberoende slutledningsbegäranden på serversidan för att dynamiskt bilda en större batch för att öka genomströmningen. Följande diagram illustrerar Tritons runtime-arkitektur.

I den föregående arkitekturen når alla förfrågningar den dynamiska batchern först innan de går in i de faktiska modellschemaläggningsköerna för att vänta på slutledning. Du kan ställa in dina föredragna batchstorlekar för dynamisk batchning med hjälp av föredragen_batchstorlek inställningar i modellkonfigurationen. (Observera att den bildade batchstorleken måste vara mindre än max_batch_size modellen stöder.) Du kan också konfigurera max_queue_delay_microseconds för att ange den maximala fördröjningstiden i batchern för att vänta på andra förfrågningar att gå med i batchen baserat på dina latenskrav.

Följande kodavsnitt visar hur du kan lägga till den här funktionen med modellkonfigurationsfiler för att ställa in dynamisk batchning med en föredragen batchstorlek på 16 för den faktiska slutsatsen. Med de nuvarande inställningarna anropas modellinstansen omedelbart när den föredragna batchstorleken på 16 uppnås eller fördröjningstiden på 100 mikrosekunder har förflutit sedan den första begäran nådde den dynamiska batchern.

dynamic_batching { preferred_batch_size: 16 max_queue_delay_microseconds: 100 }

Kör modeller samtidigt

En annan viktig optimering som erbjuds i Triton för att maximera hårdvaruanvändningen utan extra latensoverhead är samtidigt modellutförande, vilket gör att flera modeller eller flera kopior av samma modell kan köras parallellt. Denna funktion gör det möjligt för Triton att hantera flera slutledningsförfrågningar samtidigt, vilket ökar slutledningskapaciteten genom att använda annars inaktiv beräkningskraft på hårdvaran.

Följande bild visar hur du enkelt kan konfigurera olika modellimplementeringspolicyer med bara några rader kodändringar. Till exempel visar konfiguration A (vänster) att du kan sända samma konfiguration av två modellinstanser av bert-large-uncased till alla tillgängliga GPU:er. Däremot visar konfiguration B (mitten) en annan konfiguration endast för GPU 0, utan att ändra policyerna på de andra GPU:erna. Du kan också distribuera instanser av olika modeller på en enda GPU, som visas i konfiguration C (höger).

I konfiguration C kan beräkningsinstansen hantera två samtidiga förfrågningar för DistilGPT-2-modellen och sju samtidiga förfrågningar för bert-large-uncased modell parallellt. Med dessa optimeringar kan hårdvaruresurserna utnyttjas bättre för serveringsprocessen, och därigenom förbättra genomströmningen och ge bättre kostnadseffektivitet för din arbetsbörda.

TensorRT

NVIDIA TensorRT är en SDK för högpresterande djupinlärningsinferens som fungerar sömlöst med Triton. TensorRT, som stöder alla större ramverk för djupinlärning, inkluderar en slutledningsoptimerare och körtid som ger låg latens och hög genomströmning för att köra slutsatser med enorma mängder data via kraftfulla optimeringar.

TensorRT optimerar grafen för att minimera minnesfotavtryck genom att frigöra onödigt minne och effektivt återanvända det. Dessutom smälter TensorRT-kompileringen samman de glesa operationerna inuti modelldiagrammet för att bilda en större kärna för att undvika overhead av flera små kärnlanseringar. Kernel auto-tuning hjälper dig att fullt ut använda hårdvaran genom att välja den bästa algoritmen på din mål-GPU. CUDA-strömmar gör att modeller kan köras parallellt för att maximera din GPU-användning för bästa prestanda. Sist men inte minst kan kvantiseringstekniken fullt ut använda den blandade precisionsaccelerationen av Tensor-kärnorna för att köra modellen i FP32, TF32, FP16 och INT8 för att uppnå bästa slutledningsprestanda.

Triton på SageMaker-värd

SageMaker-värd tjänster är en uppsättning SageMaker-funktioner som syftar till att göra modelldistribution och betjäning enklare. Det ger en mängd olika alternativ för att enkelt distribuera, automatiskt skala, övervaka och optimera ML-modeller som är skräddarsydda för olika användningsfall. Detta innebär att du kan optimera dina distributioner för alla typer av användningsmönster, från beständiga och alltid tillgängliga med serverlösa alternativ till övergående, långvariga eller batch slutledningsbehov.

Under SageMakers värdparaply finns också uppsättningen SageMaker inference Deep Learning Containers (DLC), som kommer förpackade med lämplig modell av servermjukvara för deras motsvarande stödda ML-ramverk. Detta gör att du kan uppnå hög slutledningsprestanda utan modellserverinstallation, vilket ofta är den mest komplexa tekniska aspekten av modelldistribution och i allmänhet inte är en del av en datavetares kompetensuppsättning. Triton inferensserver är nu tillgänglig på SageMaker Deep Learning Containers (DLC).

Denna bredd av alternativ, modularitet och användarvänlighet för olika serveringsramverk gör SageMaker och Triton till en kraftfull matchning.

SageMaker Inference Recommender för benchmarking av testresultat

Vi använder SageMaker Inference Recommender för att köra våra experiment. SageMaker Inference Recommender erbjuder två typer av jobb: standard och avancerad, som illustreras i följande diagram.

Standardjobbet ger rekommendationer om instanstyper med bara modellen och ett exempel på nyttolast att jämföra. Förutom instansrekommendationer erbjuder tjänsten även körtidsparametrar som förbättrar prestandan. Standardjobbets rekommendationer är avsedda att begränsa instanssökningen. I vissa fall kan det vara instansfamiljen och i andra kan det vara de specifika instanstyperna. Resultaten av standardjobbet matas sedan in i det avancerade jobbet.

Det avancerade jobbet erbjuder fler kontroller för att ytterligare finjustera prestandan. Dessa kontroller simulerar den verkliga miljön och produktionskraven. Bland dessa kontroller finns trafikmönstret, som syftar till att iscensätta förfrågningsmönstret för riktmärkena. Du kan ställa in ramper eller stadig trafik genom att använda trafikmönstrets flera faser. Till exempel en InitialNumberOfUsers av 1, SpawnRate av 1 och DurationInSeconds av 600 kan resultera i ramptrafik på 10 minuter med 1 samtidig användare i början och 10 i slutet. Dessutom, på kontrollerna, MaxInvocations och ModelLatencyThresholds ställ in produktionströskeln, så när ett av tröskelvärdena överskrids stoppas benchmarkingen.

Slutligen rekommendationsmått inkluderar genomströmning, latens vid maximal genomströmning och kostnad per slutledning, så det är lätt att jämföra dem.

Vi använder den avancerade jobbtypen SageMaker Inference Recommender för att köra våra experiment för att få ytterligare kontroll över trafikmönstren och finjustera konfigurationen av serveringsbehållaren.

Experimentuppställning

Vi använder den anpassade belastningstestfunktionen i SageMaker Inference Recommender för att jämföra NLP-profilen som beskrivs i vårt användningsfall. Vi definierar först följande förutsättningar relaterade till NLP-modellen och ML-uppgiften. SageMaker Inference Recommender använder denna information för att hämta en slutledning Docker-bild från Amazon Elastic Container Registry (Amazon ECR) och registrera modellen med SageMakers modellregister.

Trafikmönsterkonfigurationerna i SageMaker Inference Recommender tillåter oss att definiera olika faser för det anpassade belastningstestet. Laddningstestet startar med två första användare och skapar två nya användare varje minut, under en total varaktighet av 25 minuter (1500 sekunder), som visas i följande kod:

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

Vi experimenterar med lasttestning av samma modell i två olika tillstånd. De PyTorch-baserade experimenten använder den oförändrade standardmodellen PyTorch. För TensorRT-baserade experiment konverterar vi PyTorch-modellen till en TensorRT-motor i förväg.

Vi använder olika kombinationer av prestandaoptimeringsfunktionerna på dessa två modeller, sammanfattade i följande tabell.

Testresultat och observationer

Vi genomförde belastningstester för tre instanstyper inom samma g4dn-familj: ml.g4dn.xlarge, ml.g4dn.2xlarge och ml.g4dn.12xlarge. Alla g4dn-instanstyper har tillgång till NVIDIA T4 Tensor Core GPU:er och 2nd Generation Intel Cascade Lake-processorer. Logiken bakom valet av instanstyper var att ha både en instans med endast en GPU tillgänglig, såväl som en instans med tillgång till flera GPU:er – fyra i fallet ml.g4dn.12xlarge. Dessutom ville vi testa om en ökning av vCPU-kapaciteten på instansen med endast en tillgänglig GPU skulle ge en förbättring av kostnads-prestandaförhållandet.

Låt oss först gå igenom snabbheten för den individuella optimeringen. Följande graf visar att TensorRT-optimering ger en 50 % minskning av modelllatens jämfört med den ursprungliga i PyTorch på ml.g4dn.xlarge-instansen. Denna latensreduktion växer till över tre gånger på multi-GPU-instanserna av ml.g4dn.12xlarge. Samtidigt är 30 % genomströmningsförbättring konsekvent i båda fallen, vilket resulterar i bättre kostnadseffektivitet efter tillämpning av TensorRT-optimeringar.

Med dynamisk batchning kan vi komma nära 2x förbättring i genomströmning med samma hårdvaruarkitektur på alla experimentinstanser av ml.g4dn.xlarge, ml.g4dn.2xlarge och ml.g4dn.12xlarge utan märkbar latencysökning.

På liknande sätt möjliggör samtidig modellexekvering oss att erhålla cirka 3-4x förbättring i genomströmning genom att maximera GPU-användningen på ml.g4dn.xlarge-instansen och cirka 2x förbättring på både ml.g4dn.2xlarge-instansen och multi-GPU-instansen av ml. g4dn.12xlarge.. Denna genomströmningsökning kommer utan någon overhead i latensen.

Ännu bättre, vi kan integrera alla dessa optimeringar för att ge bästa prestanda genom att utnyttja hårdvaruresurserna till fullo. Följande tabell och grafer sammanfattar resultaten vi fick i våra experiment.

[1] Det initiala antalet instanser i tabellen ovan är det rekommenderade antalet instanser som ska användas med en automatisk skalningspolicy för att upprätthålla kraven på genomströmning och latens för din arbetsbelastning.

[2] Kostnaden per timme i tabellen ovan beräknas baserat på det initiala antalet instanser och priset för instanstypen.

Resultaten validerar mestadels effekten som förväntades av olika prestandaoptimeringsfunktioner:

• TensorRT-kompileringen har den mest tillförlitliga effekten över alla instanstyper. Transaktioner per minut per instans ökade med 30–35 %, med en konsekvent kostnadsminskning på cirka 25 % jämfört med TensorRT-motorns prestanda med standard PyTorch BERT (pt-base). Den ökade prestandan hos TensorRT-motorn förstärks och utnyttjas av de andra testade prestandajusteringsfunktionerna.
• Att ladda två modeller på varje GPU (instansgrupp) fördubblade nästan strikt alla uppmätta mätvärden. Antalet anrop per minut och instans ökade med cirka 80–90 %, vilket gav en kostnadsminskning i intervallet 50 %, nästan som om vi skulle använda två GPU:er. Faktiskt, amazoncloudwatch mätvärden för våra experiment på g4dn.2xlarge (som ett exempel) bekräftar att både CPU- och GPU-användningen fördubblas när vi konfigurerar en instansgrupp med två modeller.

Ytterligare tips om prestanda och kostnadsoptimering

Riktmärket som presenteras i det här inlägget skrapade precis på ytan av de möjliga funktionerna och teknikerna som du kan använda med Triton för att förbättra slutledningsprestanda. Dessa sträcker sig från dataförbehandlingstekniker, som att skicka binära nyttolaster till modellservern eller nyttolaster med större partier, till inbyggda Triton-funktioner, som följande:

• Modelluppvärmning, vilket förhindrar initiala, långsamma slutledningsbegäranden genom att fullständigt initiera modellen innan den första slutledningsbegäran tas emot.
• Svarscache, som cachar upprepade förfrågningar.
• Modellsammansättning, som gör att du kan skapa en pipeline av en eller flera modeller och anslutningen av ingångs- och utgångstensorer mellan dessa modeller. Detta öppnar möjligheten att lägga till förbearbetnings- och efterbearbetningssteg, eller till och med slutsatser med andra modeller, till bearbetningsflödet för varje begäran.

Vi förväntar oss att testa och jämföra dessa tekniker och funktioner i ett framtida inlägg, så håll utkik!

Slutsats

I det här inlägget utforskade vi några parametrar som du kan använda för att maximera prestandan för din SageMaker realtidsslutpunkt för att servera PyTorch BERT-modeller med Triton Inference Server. Vi använde SageMaker Inference Recommender för att utföra benchmarking-testerna för att finjustera dessa parametrar. Dessa parametrar är i huvudsak relaterade till TensorRT-baserad modelloptimering, vilket leder till nästan 50 % förbättring av svarstider jämfört med den icke-optimerade versionen. Dessutom ledde att köra modeller samtidigt och använda dynamisk batchning av Triton till nästan 70 % ökning av genomströmningen. Finjustering av dessa parametrar ledde också till en total minskning av slutledningskostnaden.

Det bästa sättet att härleda de korrekta värdena är genom experiment. Men för att börja bygga empirisk kunskap om prestandajustering och optimering kan du observera kombinationerna av olika Triton-relaterade parametrar och deras effekt på prestanda över ML-modeller och SageMaker ML-instanser.

SageMaker tillhandahåller verktygen för att ta bort de odifferentierade tunga lyften från varje steg i ML-livscykeln, och underlättar därigenom de snabba experimenterande och utforskningar som behövs för att helt optimera dina modellinstallationer.

Du kan hitta den bärbara datorn som används för belastningstestning och distribution på GitHub. Du kan uppdatera Triton-konfigurationer och SageMaker Inference Recommender-inställningar för att bäst passa ditt användningsfall för att uppnå kostnadseffektiva och bäst presterande slutledningsarbetsbelastningar.

Om författarna

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.

João Moura är en AI/ML Specialist Solutions Architect på Amazon Web Services. Han fokuserar mest på NLP-användningsfall och att hjälpa kunder att optimera utbildning och implementering av Deep Learning-modeller. Han är också en aktiv förespråkare för ML-lösningar med låg kod och ML-specialiserad hårdvara.

Mohan Gandhi är senior mjukvaruingenjör på AWS. Han har varit med AWS de senaste 9 åren och har arbetat med olika AWS-tjänster som EMR, EFA och RDS på utposter. För närvarande fokuserar han på att förbättra SageMaker Inference Experience. På fritiden tycker han om att vandra och springa maraton.

Dhawal Patel är en huvudarkitekt för maskininlärning på AWS. Han har arbetat med organisationer som sträcker sig från stora företag till medelstora startups med problem relaterade till distribuerad datoranvändning och artificiell intelligens. Han fokuserar på djupinlärning inklusive NLP- och Computer Vision-domäner. Han hjälper kunder att uppnå högpresterande modellslutningar på SageMaker.

Santosh Bhavani är Senior teknisk produktchef med Amazon SageMaker Elastic Inference team. Han fokuserar på att hjälpa SageMaker-kunder att påskynda modellinferens och distribution. På fritiden tycker han om att resa, spela tennis och dricka mycket Pu'er-te.

Jiahong Liu är en lösningsarkitekt på Cloud Service Provider-teamet på NVIDIA. Han hjälper kunder att ta till sig maskininlärning och AI-lösningar som utnyttjar NVIDIAs accelererade datoranvändning för att hantera deras utbildnings- och slutledningsutmaningar. På sin fritid tycker han om origami, gör-det-själv-projekt och att spela basket.

• Myntsmart. Europas bästa bitcoin- och kryptobörs.
• Platoblockchain. Web3 Metaverse Intelligence. Kunskap förstärkt. FRI TILLGÅNG.
• CryptoHawk. Altcoin radar. Gratis provperiod.
• Källa: https://aws.amazon.com/blogs/machine-learning/achieve-hyperscale-performance-for-model-serving-using-nvidia-triton-inference-server-on-amazon-sagemaker/