Oppnå hyperskaleringsytelse for modellservering ved å bruke NVIDIA Triton Inference Server på Amazon SageMaker

Maskinlæringsapplikasjoner (ML) er komplekse å distribuere og krever ofte flere ML-modeller for å betjene en enkelt slutningsforespørsel. En typisk forespørsel kan flyte på tvers av flere modeller med trinn som forbehandling, datatransformasjoner, modellvalglogikk, modellaggregering og etterbehandling. Dette har ført til utviklingen av vanlige designmønstre som serielle inferensrørledninger, ensembler (spredningsinnsamling) og forretningslogiske arbeidsflyter, noe som har resultert i å realisere hele arbeidsflyten for forespørselen som en rettet asyklisk graf (DAG). Men etter hvert som arbeidsflytene blir mer komplekse, fører dette til en økning i den totale responstiden, eller latens, for disse applikasjonene, noe som igjen påvirker den generelle brukeropplevelsen. Videre, hvis disse komponentene er vert for forskjellige forekomster, øker den ekstra nettverksforsinkelsen mellom disse forekomstene den totale ventetiden. Tenk på et eksempel på en populær ML-brukssak for en virtuell assistent i kundestøtte. En typisk forespørsel kan måtte gå gjennom flere trinn som involverer talegjenkjenning, naturlig språkbehandling (NLP), dialogstatussporing, dialogpolicy, tekstgenerering og til slutt tekst til tale. Dessuten, for å gjøre brukerinteraksjonen mer personlig, kan du også bruke avanserte, transformatorbaserte NLP-modeller som forskjellige versjoner av BERTI, BARTog GPT. Sluttresultatet er lange responstider for disse modellensemblene og en dårlig kundeopplevelse.

Et vanlig mønster for å oppnå lavere responstider uten å gå på bekostning av den totale gjennomstrømningen er å være vert for disse modellene på samme instans sammen med den lette forretningslogikken som er innebygd i den. Disse modellene kan videre innkapsles i enkelt eller flere beholdere på samme instans for å gi isolasjon for kjørende prosesser og holde ventetiden lav. I tillegg avhenger den generelle ventetiden også av inferensapplikasjonslogikk, modelloptimaliseringer, underliggende infrastruktur (inkludert databehandling, lagring og nettverk), og den underliggende webserveren som tar slutningsforespørsler. NVIDIA Triton Inference Server er en åpen kildekode-programvare for inferensservering med funksjoner for å maksimere gjennomstrømning og maskinvareutnyttelse med ultralav (ensifret millisekunder) inferensforsinkelse. Den har bred støtte for ML-rammeverk (inkludert TensorFlow, PyTorch, ONNX, XGBoost og NVIDIA TensorRT) og infrastruktur-backends, inkludert GPUer, CPUer og AWS slutning. I tillegg er Triton Inference Server integrert med Amazon SageMaker, en fullstendig administrert ende-til-ende ML-tjeneste, som gir sanntids slutningsalternativer inkludert enkelt og multi-modell vertskap. Disse slutningsalternativene inkluderer å være vert for flere modeller i samme beholder bak en enkelt endepunkt, og vertskap flere modeller med flere beholdere bak et enkelt endepunkt.

I november 2021 annonserte vi integreringen av Triton Inference Server på SageMaker. AWS jobbet tett med NVIDIA for å gjøre det mulig for deg å få det beste fra begge verdener og gjøre modellimplementering med Triton på AWS enklere.

I dette innlegget ser vi på beste praksis for distribusjon av transformatormodeller i stor skala på GPUer ved å bruke Triton Inference Server på SageMaker. Først starter vi med en oppsummering av nøkkelbegreper rundt latens i SageMaker, og en oversikt over retningslinjer for ytelsesjustering. Deretter gir vi en oversikt over Triton og dens funksjoner samt eksempelkode for distribusjon på SageMaker. Til slutt utfører vi belastningstester vha SageMaker Inference Recommender og oppsummer innsikten og konklusjonene fra lasttesting av en populær transformatormodell levert av Hugging Face.

Du kan se gjennom bærbare vi pleide å distribuere modeller og utføre belastningstester på egen hånd ved å bruke koden på GitHub.

Ytelsesjustering og optimalisering for modellservering på SageMaker

Ytelsesjustering og -optimalisering er en empirisk prosess som ofte involverer flere iterasjoner. Antallet parametere som skal justeres er kombinatorisk og settet med konfigurasjonsparameterverdier er ikke uavhengige av hverandre. Ulike faktorer påvirker optimal parameterinnstilling, inkludert nyttelaststørrelse, type og antall ML-modeller i flytdiagrammet for slutningsforespørsel, lagringstype, dataforekomsttype, nettverksinfrastruktur, applikasjonskode, kjøretid og konfigurasjon for inferensservering av programvare og mer.

Hvis du bruker SageMaker for å distribuere ML-modeller, må du velge en beregningsforekomst med best prisytelse, som er en komplisert og iterativ prosess som kan ta uker med eksperimentering. Først må du velge riktig ML-instanstype av over 70 alternativer basert på ressurskravene til modellene dine og størrelsen på inndataene. Deretter må du optimalisere modellen for den valgte forekomsttypen. Til slutt må du klargjøre og administrere infrastruktur for å kjøre belastningstester og justere skykonfigurasjonen for optimal ytelse og kostnad. Alt dette kan forsinke modelldistribusjon og tid til markedet. I tillegg må du evaluere avveiningene mellom ventetid, gjennomstrømning og kostnad for å velge den optimale distribusjonskonfigurasjonen. SageMaker Inference Recommender velger automatisk riktig beregningsforekomsttype, antall forekomster, beholderparametere og modelloptimaliseringer for slutninger for å maksimere gjennomstrømningen, redusere ventetiden og minimere kostnadene.

Sanntidsslutning og latens i SageMaker

SageMaker sanntidsslutning er ideell for slutningsarbeidsbelastninger der du har sanntids, interaktive krav med lav latens. Det er fire mest brukte beregninger for å overvåke ventetid for slutningsforespørsel for SageMaker slutningsendepunkter

• Beholderforsinkelse – Tiden det tar å sende forespørselen, hente svaret fra modellens beholder og fullføre slutningen i beholderen. Denne beregningen er tilgjengelig i Amazon CloudWatch som en del av Invokasjonsberegninger utgitt av SageMaker.
• Modellforsinkelse – Den totale tiden det tar for alle SageMaker-beholdere i en slutningsrørledning. Denne beregningen er tilgjengelig i Amazon CloudWatch som en del av Invokasjonsberegninger utgitt av SageMaker.
• Overhead latens – Målt fra det tidspunktet SageMaker mottar forespørselen til den returnerer et svar til klienten, minus modellforsinkelsen. Denne beregningen er tilgjengelig i Amazon CloudWatch som en del av Invokasjonsberegninger utgitt av SageMaker.
• End-to-end latens – Målt fra klienten sender slutningsforespørselen til den mottar svar tilbake. Kunder kan publisere dette som en egendefinert beregning i Amazon CloudWatch.

Følgende diagram illustrerer disse komponentene.

Beholderforsinkelse avhenger av flere faktorer; følgende er blant de viktigste:

• Underliggende protokoll (HTTP(er)/gRPC) som brukes til å kommunisere med inferensserveren
• Overhead knyttet til å opprette nye TLS-forbindelser
• Deserialiseringstid for forespørsel/svar nyttelast
• Be om kø- og batchfunksjoner levert av den underliggende inferensserveren
• Be om planleggingsfunksjoner levert av den underliggende inferensserveren
• Underliggende kjøretidsytelse til inferensserveren
• Ytelse av forbehandlings- og etterbehandlingsbiblioteker før du kaller modellprediksjonsfunksjonen
• Underliggende ML-rammeverk-backend-ytelse
• Modellspesifikke og maskinvarespesifikke optimaliseringer

I dette innlegget fokuserer vi først og fremst på å optimalisere containerforsinkelse sammen med total gjennomstrømning og kostnad. Spesifikt utforsker vi ytelsesjustering av Triton Inference Server som kjører inne i en SageMaker-beholder.

Bruk saksoversikt

Det kan være ganske utfordrende å distribuere og skalere NLP-modeller i et produksjonsoppsett. NLP-modeller er ofte svært store i størrelse, og inneholder millioner av modellparametere. Optimale modellkonfigurasjoner kreves for å tilfredsstille de strenge ytelses- og skalerbarhetskravene til NLP-applikasjoner i produksjonsgrad.

I dette innlegget benchmarker vi en NLP-brukssak ved å bruke et SageMaker-endepunkt i sanntid basert på en Triton Inference Server-beholder og anbefaler optimalisering av ytelsesjustering for ML-brukssaken vår. Vi bruker en stor, ferdigtrent transformatorbasert Hugging Face BERT stor ukappet modell, som har omtrent 336 millioner modellparametere. Inndatasetningen som brukes for den binære klassifiseringsmodellen er polstret og avkortet til en maksimal inngangssekvenslengde på 512 tokens. Inferensbelastningstesten simulerer 500 påkallinger per sekund (30,000 XNUMX maksimale påkallinger per minutt) og ModelLatency på mindre enn 0.5 sekunder (500 millisekunder).

Tabellen nedenfor oppsummerer referansekonfigurasjonen vår.

NVIDIA Triton Inference Server

Triton Inference Server er spesielt utviklet for å muliggjøre skalerbar, rask og enkel distribusjon av modeller i produksjon. Triton støtter en rekke store AI-rammeverk, inkludert TensorFlow, TensorRT, PyTorch, XGBoost og ONNX. Med Python og C++ tilpasset backend kan du også implementere arbeidsbelastningen din for mer tilpassede brukstilfeller.

Det viktigste er at Triton tilbyr et enkelt konfigurasjonsbasert oppsett for å være vert for modellene dine, som avslører et rikt sett med ytelsesoptimaliseringsfunksjoner du kan bruke med liten kodeinnsats.

Triton øker slutningsytelsen ved å maksimere maskinvareutnyttelsen med forskjellige optimaliseringsteknikker (samtidige modellkjøringer og dynamisk batching er de mest brukte). Å finne de optimale modellkonfigurasjonene fra ulike kombinasjoner av dynamiske batchstørrelser og antall samtidige modellforekomster er nøkkelen til å oppnå sanntidsslutning innen lavkostservering ved bruk av Triton.

Dynamisk batching

Mange utøvere har en tendens til å kjøre inferens sekvensielt når serveren påkalles med flere uavhengige forespørsler. Selv om det er enklere å sette opp, er det vanligvis ikke den beste praksisen å bruke GPUs datakraft. For å løse dette tilbyr Triton de innebygde optimaliseringene av dynamisk batching å kombinere disse uavhengige slutningsforespørslene på serversiden for å danne en større batch dynamisk for å øke gjennomstrømningen. Følgende diagram illustrerer Tritons kjøretidsarkitektur.

I den foregående arkitekturen når alle forespørslene først den dynamiske batcheren før de går inn i de faktiske modellplanleggerkøene for å vente på slutning. Du kan angi dine foretrukne batchstørrelser for dynamisk batching ved å bruke foretrukket_batch_størrelse innstillinger i modellkonfigurasjonen. (Merk at den dannede batchstørrelsen må være mindre enn max_batch_size modellen støtter.) Du kan også konfigurere max_queue_delay_microseconds for å spesifisere maksimal forsinkelsestid i batcheren for å vente på andre forespørsler om å bli med i batchen basert på dine latenskrav.

Følgende kodebit viser hvordan du kan legge til denne funksjonen med modellkonfigurasjonsfiler for å angi dynamisk batching med en foretrukket batchstørrelse på 16 for den faktiske slutningen. Med de gjeldende innstillingene blir modellforekomsten påkalt umiddelbart når den foretrukne batchstørrelsen på 16 er oppfylt eller forsinkelsestiden på 100 mikrosekunder har gått siden den første forespørselen nådde den dynamiske batcheren.

dynamic_batching { preferred_batch_size: 16 max_queue_delay_microseconds: 100 }

Kjører modeller samtidig

En annen viktig optimalisering som tilbys i Triton for å maksimere maskinvareutnyttelsen uten ekstra ventetid er samtidig modellutførelse, som lar flere modeller eller flere kopier av samme modell kjøre parallelt. Denne funksjonen gjør det mulig for Triton å håndtere flere slutningsforespørsler samtidig, noe som øker slutningsgjennomstrømningen ved å bruke ellers inaktiv datakraft på maskinvaren.

Følgende figur viser hvordan du enkelt kan konfigurere ulike modellimplementeringspolicyer med bare noen få linjer med kodeendringer. For eksempel viser konfigurasjon A (venstre) at du kan kringkaste den samme konfigurasjonen av to modellforekomster av bert-large-uncased til alle tilgjengelige GPUer. I kontrast viser konfigurasjon B (midt) en annen konfigurasjon kun for GPU 0, uten å endre policyene på de andre GPUene. Du kan også distribuere forekomster av forskjellige modeller på en enkelt GPU, som vist i konfigurasjon C (til høyre).

I konfigurasjon C kan beregningsinstansen håndtere to samtidige forespørsler for DistilGPT-2-modellen og syv samtidige forespørsler for bert-large-uncased modell parallelt. Med disse optimaliseringene kan maskinvareressursene utnyttes bedre for serveringsprosessen, og dermed forbedre gjennomstrømningen og gi bedre kostnadseffektivitet for arbeidsmengden din.

TensorRT

NVIDIA TensorRT er en SDK for høyytelses dyp læringsslutning som fungerer sømløst med Triton. TensorRT, som støtter alle større rammeverk for dyp læring, inkluderer en slutningsoptimalisering og kjøretid som gir lav latens og høy gjennomstrømning for å kjøre slutninger med enorme datamengder via kraftige optimaliseringer.

TensorRT optimerer grafen for å minimere minnefotavtrykket ved å frigjøre unødvendig minne og effektivt gjenbruke det. I tillegg smelter TensorRT-kompileringen sammen de sparsomme operasjonene inne i modellgrafen for å danne en større kjerne for å unngå overhead av flere små kjernelanseringer. Autotuning av kjernen hjelper deg med å utnytte maskinvaren fullt ut ved å velge den beste algoritmen på mål-GPUen. CUDA-strømmer gjør det mulig for modeller å kjøre parallelt for å maksimere GPU-utnyttelsen for best ytelse. Sist, men ikke minst, kan kvantiseringsteknikken fullt ut bruke den blandede presisjonsakselerasjonen til Tensor-kjernene for å kjøre modellen i FP32, TF32, FP16 og INT8 for å oppnå den beste slutningsytelsen.

Triton på SageMaker-hosting

SageMaker hosting tjenester er settet med SageMaker-funksjoner som tar sikte på å gjøre modelldistribusjon og visning enklere. Den gir en rekke alternativer for enkelt å distribuere, automatisk skalere, overvåke og optimalisere ML-modeller skreddersydd for ulike bruksområder. Dette betyr at du kan optimalisere distribusjonene dine for alle typer bruksmønstre, fra vedvarende og alltid tilgjengelige med serverløse alternativer, til forbigående, langvarige eller batch-inferensbehov.

Under SageMaker-vertsparaplyen er også settet med SageMaker inference Deep Learning Containers (DLC-er), som leveres ferdigpakket med passende modellserverprogramvare for deres tilsvarende støttede ML-rammeverk. Dette lar deg oppnå høy slutningsytelse uten modellserveroppsett, som ofte er det mest komplekse tekniske aspektet ved modelldistribusjon og generelt sett ikke er en del av en dataforskers ferdigheter. Triton-inferensserveren er nå tilgjengelig på SageMaker Deep Learning Containers (DLC).

Denne bredden av alternativer, modulariteten og brukervennligheten til forskjellige serveringsrammer gjør SageMaker og Triton til en kraftig match.

SageMaker Inference Recommender for benchmarking av testresultater

Vi bruker SageMaker Inference Recommender for å kjøre eksperimentene våre. SageMaker Inference Recommender tilbyr to typer jobber: standard og avansert, som illustrert i følgende diagram.

Standardjobben gir anbefalinger om forekomsttyper med bare modellen og et eksempel på nyttelast som skal måles. I tillegg til forekomstanbefalinger tilbyr tjenesten også kjøretidsparametere som forbedrer ytelsen. Standardjobbens anbefalinger er ment å begrense forekomstsøket. I noen tilfeller kan det være instansfamilien, og i andre kan det være de spesifikke instanstypene. Resultatene av standardjobben mates deretter inn i den avanserte jobben.

Den avanserte jobben tilbyr flere kontroller for å finjustere ytelsen ytterligere. Disse kontrollene simulerer det virkelige miljøet og produksjonskravene. Blant disse kontrollene er trafikkmønsteret, som tar sikte på å iscenesette forespørselsmønsteret for benchmarkene. Du kan stille inn ramper eller jevn trafikk ved å bruke trafikkmønsterets flere faser. For eksempel en InitialNumberOfUsers av 1, SpawnRate av 1, og DurationInSeconds på 600 kan resultere i rampetrafikk på 10 minutter med 1 samtidig bruker i begynnelsen og 10 på slutten. I tillegg, på kontrollene, MaxInvocations og ModelLatency Thresholds sett terskelen for produksjon, så når en av tersklene overskrides, stopper benchmarkingen.

Endelig, anbefalingsmålinger inkluderer gjennomstrømning, latens ved maksimal gjennomstrømning og kostnad per slutning, så det er enkelt å sammenligne dem.

Vi bruker den avanserte jobbtypen SageMaker Inference Recommender for å kjøre eksperimentene våre for å få ytterligere kontroll over trafikkmønstrene, og finjustere konfigurasjonen av serveringsbeholderen.

Eksperimentoppsett

Vi bruker den tilpassede belastningstestfunksjonen til SageMaker Inference Recommender for å benchmarke NLP-profilen som er skissert i vårt brukstilfelle. Vi definerer først følgende forutsetninger knyttet til NLP-modellen og ML-oppgaven. SageMaker Inference Recommender bruker denne informasjonen til å hente et inferens Docker-bilde fra Amazon Elastic Container Registry (Amazon ECR) og registrer modellen med SageMaker modellregister.

Trafikkmønsterkonfigurasjonene i SageMaker Inference Recommender lar oss definere forskjellige faser for den tilpassede belastningstesten. Lastetesten starter med to første brukere og skaper to nye brukere hvert minutt, i en total varighet på 25 minutter (1500 sekunder), som vist i følgende kode:

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

Vi eksperimenterer med lasttesting av samme modell i to forskjellige tilstander. De PyTorch-baserte eksperimentene bruker standard, uendret PyTorch-modell. For TensorRT-baserte eksperimenter konverterer vi PyTorch-modellen til en TensorRT-motor på forhånd.

Vi bruker forskjellige kombinasjoner av ytelsesoptimaliseringsfunksjonene på disse to modellene, oppsummert i tabellen nedenfor.

Testresultater og observasjoner

Vi utførte belastningstester for tre instanstyper innenfor samme g4dn-familie: ml.g4dn.xlarge, ml.g4dn.2xlarge og ml.g4dn.12xlarge. Alle g4dn-forekomsttyper har tilgang til NVIDIA T4 Tensor Core GPUer og 2. generasjons Intel Cascade Lake-prosessorer. Logikken bak valget av instanstyper var å ha både en instans med kun én GPU tilgjengelig, samt en instans med tilgang til flere GPUer – fire i tilfellet ml.g4dn.12xlarge. I tillegg ønsket vi å teste om å øke vCPU-kapasiteten på forekomsten med bare én tilgjengelig GPU ville gi en forbedring av kostnads-ytelse-forholdet.

La oss først gå over hastigheten på den individuelle optimaliseringen. Følgende graf viser at TensorRT-optimalisering gir en 50 % reduksjon i modelllatens sammenlignet med den opprinnelige i PyTorch på ml.g4dn.xlarge-forekomsten. Denne latensreduksjonen vokser til over tre ganger på multi-GPU-forekomstene av ml.g4dn.12xlarge. I mellomtiden er gjennomstrømsforbedringen på 30 % konsistent i begge tilfeller, noe som resulterer i bedre kostnadseffektivitet etter bruk av TensorRT-optimaliseringer.

Med dynamisk batching kan vi få nær 2x forbedring i gjennomstrømning ved å bruke den samme maskinvarearkitekturen på alle eksperimenter for eksempel ml.g4dn.xlarge, ml.g4dn.2xlarge og ml.g4dn.12xlarge uten merkbar latenstidsøkning.

På samme måte gjør samtidig modellkjøring oss i stand til å oppnå omtrent 3-4x forbedring i gjennomstrømning ved å maksimere GPU-utnyttelsen på ml.g4dn.xlarge-forekomsten og omtrent 2x forbedring på både ml.g4dn.2xlarge-forekomsten og multi-GPU-forekomsten av ml. g4dn.12xlarge.. Denne gjennomstrømningsøkningen kommer uten noen overhead i latensen.

Enda bedre, vi kan integrere alle disse optimaliseringene for å gi den beste ytelsen ved å utnytte maskinvareressursene til det fulle. Følgende tabell og grafer oppsummerer resultatene vi oppnådde i våre eksperimenter.

[1] Innledende antall forekomster i tabellen ovenfor er det anbefalte antallet forekomster som skal brukes med en autoskaleringspolicy for å opprettholde gjennomstrømnings- og latenskravene for arbeidsbelastningen din.

[2] Kostnad per time i tabellen ovenfor er beregnet basert på innledende antall forekomster og pris for forekomsttypen.

Resultatene validerer for det meste effekten som var forventet av forskjellige ytelsesoptimeringsfunksjoner:

• TensorRT-kompilering har den mest pålitelige innvirkningen på tvers av alle instanstyper. Transaksjoner per minutt per forekomst økte med 30–35 %, med en konsekvent kostnadsreduksjon på omtrent 25 % sammenlignet med TensorRT-motorens ytelse med standard PyTorch BERT (pt-base). Den økte ytelsen til TensorRT-motoren kombineres med og utnyttes av de andre testede ytelsesjusteringsfunksjonene.
• Lasting av to modeller på hver GPU (forekomstgruppe) doblet nesten alle målte beregninger. Påkallinger per minutt per forekomst økte med ca. 80–90 %, noe som ga en kostnadsreduksjon på 50 %, nesten som om vi brukte to GPUer. Faktisk, Amazon CloudWatch beregninger for våre eksperimenter på g4dn.2xlarge (som et eksempel) bekrefter at både CPU- og GPU-bruk dobles når vi konfigurerer en forekomstgruppe med to modeller.

Ytterligere tips om ytelse og kostnadsoptimalisering

Benchmarken presentert i dette innlegget skrapte nettopp i overflaten av de mulige funksjonene og teknikkene du kan bruke med Triton for å forbedre slutningsytelsen. Disse spenner fra dataforbehandlingsteknikker, som å sende binære nyttelaster til modellserveren eller nyttelaster med større batcher, til native Triton-funksjoner, som følgende:

• Modelloppvarming, som forhindrer innledende, langsomme slutningsforespørsler ved å initialisere modellen fullstendig før den første slutningsforespørselen mottas.
• Svarbuffer, som bufrer gjentatte forespørsler.
• Modellensembling, som lar deg lage en pipeline av én eller flere modeller og tilkobling av inngangs- og utgangstensorer mellom disse modellene. Dette åpner muligheten for å legge til forbehandlings- og etterbehandlingstrinn, eller til og med slutninger med andre modeller, til behandlingsflyten for hver forespørsel.

Vi forventer å teste og benchmarke disse teknikkene og funksjonene i et fremtidig innlegg, så følg med!

konklusjonen

I dette innlegget utforsket vi noen parametere som du kan bruke for å maksimere ytelsen til ditt SageMaker sanntidsendepunkt for å betjene PyTorch BERT-modeller med Triton Inference Server. Vi brukte SageMaker Inference Recommender for å utføre benchmarking-testene for å finjustere disse parameterne. Disse parameterne er i hovedsak relatert til TensorRT-basert modelloptimalisering, noe som fører til nesten 50 % forbedring i responstider sammenlignet med den ikke-optimaliserte versjonen. I tillegg førte kjøring av modeller samtidig og bruk av dynamisk batching av Triton til nesten 70 % økning i gjennomstrømming. Finjustering av disse parametrene førte også til en generell reduksjon av slutningskostnadene.

Den beste måten å utlede de riktige verdiene på er gjennom eksperimentering. For å begynne å bygge empirisk kunnskap om ytelsesjustering og -optimalisering, kan du imidlertid observere kombinasjonene av forskjellige Triton-relaterte parametere og deres effekt på ytelsen på tvers av ML-modeller og SageMaker ML-forekomster.

SageMaker gir verktøyene for å fjerne de udifferensierte tunge løftene fra hvert trinn i ML-livssyklusen, og letter dermed den raske eksperimenteringen og utforskningen som trengs for å optimalisere modelldistribusjonene dine.

Du kan finne den bærbare datamaskinen som brukes til belastningstesting og distribusjon på GitHub. Du kan oppdatere Triton-konfigurasjoner og SageMaker Inference Recommender-innstillinger slik at de passer best til din brukssituasjon for å oppnå kostnadseffektive og best-ytende inferensarbeidsbelastninger.

Om forfatterne

Vikram Elango er en AI/ML Specialist Solutions Architect hos Amazon Web Services, basert i Virginia USA. Vikram hjelper finans- og forsikringsbransjens kunder med design, tankelederskap for å bygge og distribuere maskinlæringsapplikasjoner i stor skala. Han er for tiden fokusert på naturlig språkbehandling, ansvarlig AI, inferensoptimalisering og skalering av ML på tvers av bedriften. På fritiden liker han å reise, gå fotturer, lage mat og campe med familien.

João Moura er en AI/ML Specialist Solutions Architect hos Amazon Web Services. Han fokuserer for det meste på NLP use-cases og å hjelpe kunder med å optimalisere Deep Learning modellopplæring og distribusjon. Han er også en aktiv talsmann for lavkode ML-løsninger og ML-spesialisert maskinvare.

Mohan Gandhi er senior programvareingeniør hos AWS. Han har vært med AWS de siste 9 årene og har jobbet med ulike AWS-tjenester som EMR, EFA og RDS på utposter. For tiden er han fokusert på å forbedre SageMaker Inference Experience. På fritiden liker han å gå tur og løpe maraton.

Dhawal Patel er en hovedmaskinlæringsarkitekt ved AWS. Han har jobbet med organisasjoner som spenner fra store bedrifter til mellomstore startups med problemer knyttet til distribuert databehandling og kunstig intelligens. Han fokuserer på dyp læring inkludert NLP- og Computer Vision-domener. Han hjelper kundene med å oppnå høy ytelse modellslutning på SageMaker.

Santosh Bhavani er senior teknisk produktsjef med Amazon SageMaker Elastic Inference team. Han fokuserer på å hjelpe SageMaker-kunder med å akselerere modellinnledning og distribusjon. På fritiden liker han å reise, spille tennis og drikke mye Pu'er-te.

Jiahong Liu er løsningsarkitekt i Cloud Service Provider-teamet hos NVIDIA. Han hjelper klienter med å ta i bruk maskinlæring og AI-løsninger som utnytter NVIDIA-akselerert databehandling for å møte deres trenings- og slutningsutfordringer. På fritiden liker han origami, DIY-prosjekter og å spille basketball.

• Myntsmart. Europas beste Bitcoin og Crypto Exchange.
• Platoblokkkjede. Web3 Metaverse Intelligence. Kunnskap forsterket. FRI TILGANG.
• CryptoHawk. Altcoin Radar. Gratis prøveperiode.
• Kilde: https://aws.amazon.com/blogs/machine-learning/achieve-hyperscale-performance-for-model-serving-using-nvidia-triton-inference-server-on-amazon-sagemaker/