Opnå hyperskaleringsydelse til modelbetjening ved hjælp af NVIDIA Triton Inference Server på Amazon SageMaker

Maskinlæringsapplikationer (ML) er komplekse at implementere og kræver ofte flere ML-modeller for at betjene en enkelt konklusionsanmodning. En typisk anmodning kan flyde på tværs af flere modeller med trin som forbehandling, datatransformationer, modelvalgslogik, modelaggregering og efterbehandling. Dette har ført til udviklingen af ​​almindelige designmønstre såsom serielle inferens-pipelines, ensembler (scatter-samling) og forretningslogiske arbejdsgange, hvilket resulterer i at realisere hele arbejdsgangen for anmodningen som en Directed Acyclic Graph (DAG). Men efterhånden som arbejdsgange bliver mere komplekse, fører dette til en stigning i den samlede responstid eller latens for disse applikationer, hvilket igen påvirker den overordnede brugeroplevelse. Ydermere, hvis disse komponenter hostes på forskellige forekomster, øger den yderligere netværksforsinkelse mellem disse forekomster den samlede ventetid. Overvej et eksempel på en populær ML-brugssag for en virtuel assistent i kundesupport. En typisk anmodning skal muligvis gennemgå flere trin, der involverer talegenkendelse, naturlig sprogbehandling (NLP), sporing af dialogtilstande, dialogpolitik, tekstgenerering og til sidst tekst til tale. Desuden kan du, for at gøre brugerinteraktionen mere personlig, også bruge state-of-art, transformer-baserede NLP-modeller som forskellige versioner af BERTI, BARTog GPT. Slutresultatet er lange svartider for disse modelensembler og en dårlig kundeoplevelse.

Et almindeligt mønster til at køre lavere svartider uden at gå på kompromis med den samlede gennemstrømning er at hoste disse modeller på samme instans sammen med den lette forretningslogik, der er indlejret i den. Disse modeller kan yderligere indkapsles i en enkelt eller flere containere på samme instans for at give isolering til kørende processer og holde latenstiden lav. Derudover afhænger den overordnede latens også af inferensapplikationslogik, modeloptimeringer, underliggende infrastruktur (inklusive databehandling, lagring og netværk) og den underliggende webserver, der tager slutningsanmodninger. NVIDIA Triton Inference Server er en open source-inferensserveringssoftware med funktioner til at maksimere gennemløb og hardwareudnyttelse med ultralav (encifrede millisekunder) inferensforsinkelse. Det har bred understøttelse af ML-frameworks (herunder TensorFlow, PyTorch, ONNX, XGBoost og NVIDIA TensorRT) og infrastruktur-backends, inklusive GPU'er, CPU'er og AWS-inferens. Derudover er Triton Inference Server integreret med Amazon SageMaker, en fuldt administreret end-to-end ML-tjeneste, der giver mulighed for real-time inferens, herunder enkelt , multi-model hosting. Disse slutningsmuligheder inkluderer hosting af flere modeller inden for den samme container bag en enkelt endepunktog hosting flere modeller med flere beholdere bag et enkelt endepunkt.

I november 2021 annoncerede vi integrationen af ​​Triton Inference Server på SageMaker. AWS arbejdede tæt sammen med NVIDIA for at gøre det muligt for dig at få det bedste fra begge verdener og gøre modelimplementering med Triton på AWS nemmere.

I dette indlæg ser vi på bedste praksis for implementering af transformermodeller i stor skala på GPU'er ved hjælp af Triton Inference Server på SageMaker. Først starter vi med en oversigt over nøglebegreber omkring latency i SageMaker og en oversigt over retningslinjer for præstationsjustering. Dernæst giver vi et overblik over Triton og dets funktioner samt eksempelkode til implementering på SageMaker. Til sidst udfører vi belastningstest vha SageMaker Inference Recommend og opsummer indsigten og konklusionerne fra belastningstest af en populær transformermodel leveret af Hugging Face.

Du kan gennemgå notesbog vi plejede at implementere modeller og udføre belastningstest på egen hånd ved hjælp af koden på GitHub.

Ydeevnejustering og optimering til modelservering på SageMaker

Ydeevnejustering og optimering er en empirisk proces, der ofte involverer flere iterationer. Antallet af parametre, der skal indstilles, er kombinatorisk, og sættet af konfigurationsparameterværdier er ikke uafhængige af hinanden. Forskellige faktorer påvirker optimal parameterjustering, herunder nyttelaststørrelse, type og antallet af ML-modeller i inferensanmodningsflowgrafen, lagertype, computerinstanstype, netværksinfrastruktur, applikationskode, inferensserveringssoftwareruntime og konfiguration og mere.

Hvis du bruger SageMaker til at implementere ML-modeller, skal du vælge en computerforekomst med den bedste pris-ydelse, hvilket er en kompliceret og iterativ proces, der kan tage ugers eksperimentering. Først skal du vælge den rigtige ML-instanstype ud af over 70 muligheder baseret på dine modellers ressourcekrav og størrelsen af ​​inputdataene. Dernæst skal du optimere modellen til den valgte instanstype. Til sidst skal du klargøre og administrere infrastruktur for at køre belastningstests og justere cloud-konfigurationen for optimal ydeevne og omkostninger. Alt dette kan forsinke modelimplementeringen og time to market. Derudover skal du evaluere afvejningen mellem latenstid, gennemløb og omkostninger for at vælge den optimale implementeringskonfiguration. SageMaker Inference Recommend vælger automatisk den rigtige computerforekomsttype, forekomstantal, containerparametre og modeloptimeringer til slutning for at maksimere gennemløbet, reducere latens og minimere omkostningerne.

Realtidsslutning og latens i SageMaker

SageMaker inferens i realtid er ideel til inferens-arbejdsbelastninger, hvor du har real-time, interaktive krav med lav latens. Der er fire mest almindeligt anvendte målinger til overvågning af slutningsanmodningsforsinkelse for SageMaker slutningsendepunkter

• Containerforsinkelse – Den tid det tager at sende anmodningen, hente svaret fra modellens container og fuldføre konklusion i containeren. Denne metrik er tilgængelig i Amazon CloudWatch som en del af Invokationsmålinger udgivet af SageMaker.
• Model latens – Den samlede tid, som alle SageMaker-containere tager i en slutningspipeline. Denne metrik er tilgængelig i Amazon CloudWatch som en del af Invokationsmålinger udgivet af SageMaker.
• Overhead latens – Målt fra det tidspunkt, hvor SageMaker modtager anmodningen, indtil den returnerer et svar til klienten, minus modelforsinkelsen. Denne metrik er tilgængelig i Amazon CloudWatch som en del af Invokationsmålinger udgivet af SageMaker.
• End-to-end latens – Målt fra det tidspunkt, klienten sender slutningsanmodningen, indtil den modtager et svar tilbage. Kunder kan udgive dette som en tilpasset metric i Amazon CloudWatch.

Følgende diagram illustrerer disse komponenter.

Containerforsinkelse afhænger af flere faktorer; følgende er blandt de vigtigste:

• Underliggende protokol (HTTP(s)/gRPC) bruges til at kommunikere med inferensserveren
• Overhead relateret til oprettelse af nye TLS-forbindelser
• Deserialiseringstid for anmodningen/svarets nyttelast
• Anmod om kø- og batchfunktioner leveret af den underliggende inferensserver
• Anmod om planlægningsfunktioner leveret af den underliggende inferensserver
• Inferensserverens underliggende runtime-ydelse
• Ydeevne for forbehandlings- og efterbehandlingsbiblioteker før kald af modelforudsigelsesfunktionen
• Underliggende ML framework backend ydeevne
• Modelspecifikke og hardwarespecifikke optimeringer

I dette indlæg fokuserer vi primært på at optimere container latency sammen med overordnet gennemløb og omkostninger. Specifikt udforsker vi performance tuning Triton Inference Server, der kører inde i en SageMaker-beholder.

Brug case oversigt

Det kan være ret udfordrende at implementere og skalere NLP-modeller i et produktionssetup. NLP-modeller er ofte meget store i størrelse og indeholder millioner af modelparametre. Optimale modelkonfigurationer er nødvendige for at opfylde de strenge krav til ydeevne og skalerbarhed for NLP-applikationer i produktionskvalitet.

I dette indlæg benchmarker vi en NLP-brugscase ved hjælp af et SageMaker-endepunkt i realtid baseret på en Triton Inference Server-container og anbefaler optimeringer til justering af ydeevne til vores ML-brugscase. Vi bruger et stort, fortrænet transformerbaseret Hugging Face BERT stor ukappet model, som har omkring 336 millioner modelparametre. Den inputsætning, der bruges til den binære klassifikationsmodel, er polstret og afkortet til en maksimal inputsekvenslængde på 512 tokens. Inferensbelastningstesten simulerer 500 kald pr. sekund (30,000 maksimale kald pr. minut) og ModelLatency på mindre end 0.5 sekunder (500 millisekunder).

Følgende tabel opsummerer vores benchmark-konfiguration.

NVIDIA Triton Inference Server

Triton Inference Server er specielt designet til at muliggøre skalerbar, hurtig og nem implementering af modeller i produktionen. Triton understøtter en række større AI-frameworks, herunder TensorFlow, TensorRT, PyTorch, XGBoost og ONNX. Med Python og C++ brugerdefinerede backend kan du også implementere din inferensarbejdsbelastning til mere tilpassede brugssager.

Vigtigst af alt, Triton leverer en simpel konfigurationsbaseret opsætning til at hoste dine modeller, som afslører et rigt sæt af ydeevneoptimeringsfunktioner, som du kan bruge med en lille kodeindsats.

Triton øger inferens ydeevne ved at maksimere hardwareudnyttelsen med forskellige optimeringsteknikker (samtidige modelkørsler og dynamisk batching er de mest anvendte). At finde de optimale modelkonfigurationer fra forskellige kombinationer af dynamiske batchstørrelser og antallet af samtidige modelforekomster er nøglen til at opnå realtidsslutning inden for lavpris betjening ved hjælp af Triton.

Dynamisk batching

Mange praktikere har en tendens til at køre inferens sekventielt, når serveren påkaldes med flere uafhængige anmodninger. Selvom det er lettere at konfigurere, er det normalt ikke den bedste praksis at bruge GPU's computerkraft. For at imødegå dette tilbyder Triton de indbyggede optimeringer af dynamisk batching at kombinere disse uafhængige slutningsanmodninger på serversiden for at danne en større batch dynamisk for at øge gennemløbet. Følgende diagram illustrerer Triton runtime-arkitekturen.

I den foregående arkitektur når alle anmodningerne først den dynamiske batcher, før de går ind i de faktiske modelplanlægningskøer for at vente på inferens. Du kan indstille dine foretrukne batchstørrelser til dynamisk batching ved hjælp af foretrukket_batch_størrelse indstillinger i modelkonfigurationen. (Bemærk, at den dannede batchstørrelse skal være mindre end max_batch_size modellen understøtter.) Du kan også konfigurere max_queue_delay_microseconds for at angive den maksimale forsinkelsestid i batcheren for at vente på andre anmodninger om at slutte sig til batchen baseret på dine latenskrav.

Det følgende kodestykke viser, hvordan du kan tilføje denne funktion med modelkonfigurationsfiler for at indstille dynamisk batching med en foretrukken batchstørrelse på 16 for den faktiske slutning. Med de aktuelle indstillinger påkaldes modelforekomsten øjeblikkeligt, når den foretrukne batchstørrelse på 16 er opfyldt, eller forsinkelsestiden på 100 mikrosekunder er gået, siden den første anmodning nåede den dynamiske batcher.

dynamic_batching { preferred_batch_size: 16 max_queue_delay_microseconds: 100 }

Kører modeller samtidigt

En anden vigtig optimering, der tilbydes i Triton for at maksimere hardwareudnyttelsen uden yderligere ventetid, er samtidig modeludførelse, som gør det muligt for flere modeller eller flere kopier af den samme model at køre parallelt. Denne funktion gør det muligt for Triton at håndtere flere inferensanmodninger samtidigt, hvilket øger inferensgennemstrømningen ved at bruge ellers inaktiv computerkraft på hardwaren.

Følgende figur viser, hvordan du nemt kan konfigurere forskellige modelimplementeringspolitikker med kun få linjers kodeændringer. For eksempel viser konfiguration A (venstre), at du kan udsende den samme konfiguration af to modelforekomster af bert-large-uncased til alle tilgængelige GPU'er. I modsætning hertil viser konfiguration B (midten) kun en anden konfiguration for GPU 0 uden at ændre politikkerne på de andre GPU'er. Du kan også implementere forekomster af forskellige modeller på en enkelt GPU, som vist i konfiguration C (højre).

I konfiguration C kan compute-instansen håndtere to samtidige anmodninger for DistilGPT-2-modellen og syv samtidige anmodninger for bert-large-uncased model parallelt. Med disse optimeringer kan hardwareressourcerne udnyttes bedre til serveringsprocessen og derved forbedre gennemløbet og give bedre omkostningseffektivitet for din arbejdsbyrde.

TensorRT

NVIDIA TensorRT er et SDK til højtydende dyb læringsslutning, der fungerer problemfrit med Triton. TensorRT, som understøtter alle større deep learning-rammeværker, inkluderer en inferensoptimering og runtime, der leverer lav latenstid og høj gennemstrømning til at køre inferenser med enorme mængder data via kraftfulde optimeringer.

TensorRT optimerer grafen for at minimere hukommelsesfodaftryk ved at frigøre unødvendig hukommelse og effektivt genbruge den. Derudover fusionerer TensorRT-kompileringen de sparsomme operationer inde i modelgrafen for at danne en større kerne for at undgå overhead af flere små kernelanceringer. Kernel auto-tuning hjælper dig med at udnytte hardwaren fuldt ud ved at vælge den bedste algoritme på din mål-GPU. CUDA-streams gør det muligt for modeller at køre parallelt for at maksimere din GPU-udnyttelse for den bedste ydeevne. Sidst, men ikke mindst, kan kvantiseringsteknikken fuldt ud udnytte Tensor-kernernes acceleration med blandet præcision til at køre modellen i FP32, TF32, FP16 og INT8 for at opnå den bedste inferensydelse.

Triton på SageMaker-hosting

SageMaker hosting tjenester er et sæt af SageMaker-funktioner, der har til formål at gøre modelimplementering og betjening lettere. Det giver en række muligheder for nemt at implementere, automatisk skalere, overvåge og optimere ML-modeller, der er skræddersyet til forskellige anvendelsestilfælde. Dette betyder, at du kan optimere dine udrulninger til alle typer brugsmønstre, fra vedvarende og altid tilgængelige med serverløse muligheder, til forbigående, langvarige eller batch-inferensbehov.

Under SageMaker hosting-paraplyen er også sættet af SageMaker inference Deep Learning Containers (DLC'er), som leveres færdigpakket med den passende model serversoftware til deres tilsvarende understøttede ML-ramme. Dette giver dig mulighed for at opnå høj slutningsydelse uden modelserveropsætning, hvilket ofte er det mest komplekse tekniske aspekt af modelimplementering og generelt ikke er en del af en dataforskers færdigheder. Triton-inferensserveren er nu til rådighed på SageMaker Deep Learning Containers (DLC).

Denne bredde af muligheder, modularitet og brugervenlighed af forskellige serveringsrammer gør SageMaker og Triton til et stærkt match.

SageMaker Inference Recommender til benchmarking af testresultater

Vi bruger SageMaker Inference Recommender til at køre vores eksperimenter. SageMaker Inference Recommender tilbyder to typer job: standard og avanceret, som illustreret i følgende diagram.

Standardjobbet giver anbefalinger om instanstyper med kun modellen og en prøve-nyttelast til benchmark. Ud over instansanbefalinger tilbyder tjenesten også runtime-parametre, der forbedrer ydeevnen. Standardjobbets anbefalinger er beregnet til at indsnævre instanssøgningen. I nogle tilfælde kan det være instansfamilien, og i andre kan det være de specifikke instanstyper. Resultaterne af standardjobbet føres derefter ind i det avancerede job.

Det avancerede job tilbyder flere kontroller for yderligere at finjustere ydeevnen. Disse kontroller simulerer det virkelige miljø og produktionskrav. Blandt disse kontroller er trafikmønsteret, som har til formål at iscenesætte anmodningsmønsteret for benchmarks. Du kan indstille ramper eller stabil trafik ved at bruge trafikmønstrets flere faser. For eksempel en InitialNumberOfUsers af 1, SpawnRate af 1, og DurationInSeconds på 600 kan resultere i rampetrafik på 10 minutter med 1 samtidig bruger i begyndelsen og 10 i slutningen. Derudover, på kontrollerne, MaxInvocations , ModelLatencyThresholds indstille tærsklen for produktion, så når en af ​​tærsklerne overskrides, stopper benchmarkingen.

Endelig anbefalingsmålinger inkludere gennemløb, latens ved maksimal gennemløb og pris pr. slutning, så det er nemt at sammenligne dem.

Vi bruger den avancerede jobtype SageMaker Inference Recommender til at køre vores eksperimenter for at få yderligere kontrol over trafikmønstrene og finjustere konfigurationen af ​​serveringscontaineren.

Eksperimentopsætning

Vi bruger den tilpassede belastningstestfunktion i SageMaker Inference Recommender til at benchmarke den NLP-profil, der er skitseret i vores use case. Vi definerer først følgende forudsætninger relateret til NLP-modellen og ML-opgaven. SageMaker Inference Recommender bruger denne information til at trække et inferens Docker-billede fra Amazon Elastic Container Registry (Amazon ECR) og registrer modellen med SageMaker-modelregistret.

Trafikmønsterkonfigurationerne i SageMaker Inference Recommender giver os mulighed for at definere forskellige faser for den tilpassede belastningstest. Belastningstesten starter med to indledende brugere og afføder to nye brugere hvert minut, i en samlet varighed på 25 minutter (1500 sekunder), som vist i følgende kode:

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

Vi eksperimenterer med belastningsteste den samme model i to forskellige tilstande. De PyTorch-baserede eksperimenter bruger den uændrede standard PyTorch-model. Til de TensorRT-baserede eksperimenter konverterer vi PyTorch-modellen til en TensorRT-motor på forhånd.

Vi anvender forskellige kombinationer af ydelsesoptimeringsfunktionerne på disse to modeller, opsummeret i følgende tabel.

Testresultater og observationer

Vi udførte belastningstests for tre instanstyper inden for den samme g4dn-familie: ml.g4dn.xlarge, ml.g4dn.2xlarge og ml.g4dn.12xlarge. Alle g4dn-instanstyper har adgang til NVIDIA T4 Tensor Core GPU'er og 2. generations Intel Cascade Lake-processorer. Logikken bag valget af instanstyper var at have både en instans med kun én GPU tilgængelig, samt en instans med adgang til flere GPU'er – fire i tilfælde af ml.g4dn.12xlarge. Derudover ønskede vi at teste, om en forøgelse af vCPU-kapaciteten på instansen med kun én tilgængelig GPU ville give en forbedring af omkostnings-ydelsesforholdet.

Lad os først gennemgå fremskyndelsen af ​​den individuelle optimering. Følgende graf viser, at TensorRT-optimering giver en 50 % reduktion i modellatens sammenlignet med den oprindelige i PyTorch på ml.g4dn.xlarge-instansen. Denne latensreduktion vokser til mere end tre gange på multi-GPU-forekomsterne af ml.g4dn.12xlarge. I mellemtiden er gennemløbsforbedringen på 30 % konsekvent i begge tilfælde, hvilket resulterer i bedre omkostningseffektivitet efter anvendelse af TensorRT-optimeringer.

Med dynamisk batching kan vi komme tæt på 2x forbedring af gennemløbet ved at bruge den samme hardwarearkitektur på alle eksperimenter, for eksempel ml.g4dn.xlarge, ml.g4dn.2xlarge og ml.g4dn.12xlarge uden mærkbar latensstigning.

På samme måde gør samtidig modeludførelse os i stand til at opnå omkring 3-4x forbedring i gennemløbet ved at maksimere GPU-udnyttelsen på ml.g4dn.xlarge-forekomsten og omkring 2x forbedring på både ml.g4dn.2xlarge-forekomsten og multi-GPU-forekomsten af ​​ml. g4dn.12xlarge.. Denne gennemstrømningsstigning kommer uden nogen overhead i latensen.

Endnu bedre, vi kan integrere alle disse optimeringer for at give den bedste ydeevne ved at udnytte hardwareressourcerne fuldt ud. Følgende tabel og grafer opsummerer de resultater, vi opnåede i vores eksperimenter.

[1] Det indledende antal forekomster i ovenstående tabel er det anbefalede antal forekomster, der skal bruges sammen med en autoskaleringspolitik for at opretholde gennemløbs- og latenskravene for din arbejdsbyrde.

[2] Pris pr. time i ovenstående tabel er beregnet ud fra det oprindelige antal forekomster og prisen for forekomsttypen.

Resultaterne validerer for det meste den effekt, der var forventet af forskellige præstationsoptimeringsfunktioner:

• TensorRT-kompilering har den mest pålidelige effekt på tværs af alle instanstyper. Transaktioner pr. minut pr. instans steg med 30-35 %, med en konsekvent omkostningsreduktion på ca. 25 % sammenlignet med TensorRT-motorens ydeevne til standard PyTorch BERT (pt-base). Den øgede ydeevne af TensorRT-motoren er forstærket af og udnyttet af de andre testede ydeevnejusteringsfunktioner.
• Indlæsning af to modeller på hver GPU (instansgruppe) fordoblede næsten alle målte metrics. Påkaldelser pr. minut pr. instans steg med ca. 80-90 %, hvilket gav en omkostningsreduktion i intervallet 50 %, næsten som om vi brugte to GPU'er. Faktisk, amazoncloudwatch målinger for vores eksperimenter på g4dn.2xlarge (som et eksempel) bekræfter, at både CPU- og GPU-udnyttelsen fordobles, når vi konfigurerer en forekomstgruppe på to modeller.

Yderligere tip til ydeevne og omkostningsoptimering

Det benchmark, der præsenteres i dette indlæg, har lige ridset overfladen af ​​de mulige funktioner og teknikker, som du kan bruge med Triton til at forbedre slutningsydelsen. Disse spænder fra dataforbehandlingsteknikker, såsom at sende binære nyttelaster til modelserveren eller nyttelaster med større batches, til native Triton-funktioner, såsom følgende:

• Model opvarmning, som forhindrer indledende, langsomme slutningsanmodninger ved fuldstændig at initialisere modellen før den første slutningsanmodning modtages.
• Svarcache, som cacher gentagne anmodninger.
• Modelsammensætning, som giver dig mulighed for at oprette en pipeline af en eller flere modeller og tilslutning af input- og outputtensorer mellem disse modeller. Dette åbner muligheden for at tilføje forbehandlings- og efterbehandlingstrin, eller endda slutninger med andre modeller, til behandlingsflowet for hver anmodning.

Vi forventer at teste og benchmarke disse teknikker og funktioner i et fremtidigt indlæg, så følg med!

Konklusion

I dette indlæg undersøgte vi et par parametre, som du kan bruge til at maksimere ydeevnen af ​​dit SageMaker-endepunkt i realtid til at betjene PyTorch BERT-modeller med Triton Inference Server. Vi brugte SageMaker Inference Recommender til at udføre benchmarking-testene for at finjustere disse parametre. Disse parametre er i bund og grund relateret til TensorRT-baseret modeloptimering, hvilket fører til næsten 50 % forbedring i responstider sammenlignet med den ikke-optimerede version. Derudover førte kørsel af modeller samtidigt og brug af dynamisk batching af Triton til en stigning på næsten 70 % i gennemløbet. Finjustering af disse parametre førte også til en samlet reduktion af slutningsomkostninger.

Den bedste måde at udlede de korrekte værdier på er gennem eksperimentering. Men for at begynde at opbygge empirisk viden om ydeevnejustering og optimering kan du observere kombinationerne af forskellige Triton-relaterede parametre og deres effekt på ydeevnen på tværs af ML-modeller og SageMaker ML-instanser.

SageMaker leverer værktøjerne til at fjerne de udifferentierede tunge løft fra hver fase af ML-livscyklussen og letter derved den hurtige eksperimentering og udforskning, der er nødvendig for fuldt ud at optimere dine modelimplementeringer.

Du kan finde den notebook, der bruges til belastningstest og implementering på GitHub. Du kan opdatere Triton-konfigurationer og SageMaker Inference Recommender-indstillinger, så de passer bedst til din brugssituation for at opnå omkostningseffektive og bedst ydende inferensarbejdsbelastninger.

Om forfatterne

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.

João Moura er AI/ML Specialist Solutions Architect hos Amazon Web Services. Han fokuserer mest på NLP use-cases og hjælper kunder med at optimere Deep Learning modeltræning og implementering. Han er også en aktiv fortaler for lavkode ML-løsninger og ML-specialiseret hardware.

Mohan Gandhi er senior softwareingeniør hos AWS. Han har været hos AWS i de sidste 9 år og har arbejdet på forskellige AWS-tjenester som EMR, EFA og RDS på Outposts. I øjeblikket er han fokuseret på at forbedre SageMaker Inference Experience. I sin fritid nyder han at vandre og løbe maraton.

Dhawal Patel er Principal Machine Learning Architect hos AWS. Han har arbejdet med organisationer lige fra store virksomheder til mellemstore startups om problemer relateret til distribueret computing og kunstig intelligens. Han fokuserer på Deep learning, herunder NLP og Computer Vision domæner. Han hjælper kunder med at opnå højtydende modelslutning på SageMaker.

Santosh Bhavani er Senior Technical Product Manager hos Amazon SageMaker Elastic Inference-teamet. Han fokuserer på at hjælpe SageMaker-kunder med at fremskynde modelslutning og implementering. I sin fritid nyder han at rejse, spille tennis og drikke masser af Pu'er-te.

Jiahong Liu er løsningsarkitekt på Cloud Service Provider-teamet hos NVIDIA. Han hjælper kunder med at anvende machine learning og AI-løsninger, der udnytter NVIDIA accelereret computing til at løse deres trænings- og inferensudfordringer. I sin fritid nyder han origami, gør-det-selv-projekter og at spille basketball.

• Coinsmart. Europas bedste Bitcoin og Crypto Exchange.
• Platoblokkæde. Web3 Metaverse Intelligence. Viden forstærket. FRI ADGANG.
• CryptoHawk. Altcoin radar. Gratis prøveversion.
• Kilde: https://aws.amazon.com/blogs/machine-learning/achieve-hyperscale-performance-for-model-serving-using-nvidia-triton-inference-server-on-amazon-sagemaker/