Saavuta hyperscale-suorituskyky mallin palvelemiseen käyttämällä NVIDIA Triton Inference Serveriä Amazon SageMakerissa

Koneoppimissovellukset (ML) ovat monimutkaisia ​​ottaa käyttöön ja vaativat usein useita ML-malleja palvelemaan yhtä päättelypyyntöä. Tyypillinen pyyntö voi virrata useiden mallien välillä vaiheilla, kuten esikäsittely, datamuunnos, mallin valintalogiikka, mallien yhdistäminen ja jälkikäsittely. Tämä on johtanut yleisten suunnittelumallien, kuten sarjapäätelmäputkien, ryhmien (scatter collection) ja liiketoimintalogiikan työnkulkujen, kehitykseen, mikä on johtanut pyynnön koko työnkulun toteuttamiseen suunnattuna asyklisenä kuvaajana (DAG). Työnkulkujen muuttuessa monimutkaisemmiksi tämä johtaa kuitenkin näiden sovellusten yleisen vasteaikojen tai latenssin pidentymiseen, mikä puolestaan ​​vaikuttaa yleiseen käyttökokemukseen. Lisäksi, jos näitä komponentteja isännöidään eri ilmentymissä, ylimääräinen verkon latenssi näiden ilmentymien välillä lisää kokonaisviivettä. Harkitse esimerkkiä suositusta ML-käyttötapauksesta asiakastuen virtuaaliassistentille. Tyypillinen pyyntö saattaa joutua käymään läpi useita vaiheita, joihin kuuluvat puheentunnistus, luonnollisen kielen käsittely (NLP), dialogitilan seuranta, dialogikäytäntö, tekstin luominen ja lopuksi tekstistä puheeksi. Lisäksi, jotta käyttäjän vuorovaikutus olisi yksilöllisempää, voit käyttää myös huippuluokan muuntajapohjaisia ​​NLP-malleja, kuten erilaisia ​​versioita BERTI, Bartja GPT. Lopputuloksena näiden mallikokonaisuuksien pitkät vasteajat ja huono asiakaskokemus.

Yleinen malli lyhentää vasteaikoja heikentämättä yleistä suorituskykyä on isännöidä nämä mallit samassa ilmentymässä ja siihen upotettu kevyt liiketoimintalogiikka. Nämä mallit voidaan lisäksi kapseloida yhteen tai useampaan säiliöön samassa ilmentymässä eristämään käynnissä olevia prosesseja ja pitämään latenssin alhaisena. Lisäksi yleinen viive riippuu myös päättelysovelluslogiikasta, mallin optimoinneista, taustalla olevasta infrastruktuurista (mukaan lukien laskenta, tallennus ja verkko) ja taustalla olevasta verkkopalvelimesta, joka tekee johtopäätöspyyntöjä. NVIDIA Triton Inference Server on avoimen lähdekoodin päätelmiä palveleva ohjelmisto, jonka ominaisuudet maksimoivat suorituskyvyn ja laitteiston käytön erittäin alhaisella (yksinumeroisella millisekuntia) päättelyviiveellä. Sillä on laaja tuki ML-kehyksille (mukaan lukien TensorFlow, PyTorch, ONNX, XGBoost ja NVIDIA TensorRT) ja infrastruktuurin taustajärjestelmille, mukaan lukien GPU:t, CPU:t ja AWS Inferencia. Lisäksi Triton Inference Server on integroitu Amazon Sage Maker, täysin hallittu päästä päähän ML-palvelu, joka tarjoaa reaaliaikaisia ​​päättelyvaihtoehtoja, mukaan lukien single ja monimalli isännöinti. Näihin päättelyvaihtoehtoihin kuuluu useiden mallien isännöinti samassa säiliössä a yksi päätepisteja isännöinti useita malleja useilla säiliöillä yhden päätepisteen takana.

Marraskuussa 2021 julkistimme Triton Inference Serverin integrointi SageMakeriin. AWS teki tiivistä yhteistyötä NVIDIAn kanssa, jotta voit saada molempien maailmojen parhaat puolet ja helpottaa mallin käyttöönottoa Tritonin kanssa AWS:ssä.

Tässä viestissä tarkastelemme parhaita käytäntöjä muuntajamallien käyttöönottamiseksi mittakaavassa GPU:illa käyttämällä SageMakerin Triton Inference Serveriä. Ensin aloitamme yhteenvedolla SageMakerin latenssiin liittyvistä keskeisistä käsitteistä ja yleiskatsauksesta suorituskyvyn viritysohjeisiin. Seuraavaksi tarjoamme yleiskatsauksen Tritonista ja sen ominaisuuksista sekä esimerkkikoodin käyttöönottoa varten SageMakerissa. Lopuksi suoritamme kuormitustestejä käyttämällä SageMakerin päättelysuositus ja tee yhteenveto Hugging Facen tarjoaman suositun muuntajamallin kuormitustestauksen oivalluksista ja johtopäätöksistä.

Voit tarkistaa muistikirja käytimme malleja ja suoritimme kuormitustestejä itse käyttämällä koodia GitHub.

Suorituskyvyn viritys ja optimointi mallien tarjoamista varten SageMakerissa

Suorituskyvyn viritys ja optimointi on empiirinen prosessi, joka sisältää usein useita iteraatioita. Virittävien parametrien määrä on kombinatorinen, ja konfigurointiparametrien arvot eivät ole toisistaan ​​riippumattomia. Useat tekijät vaikuttavat optimaaliseen parametrien viritykseen, mukaan lukien hyötykuorman koko, tyyppi ja ML-mallien lukumäärä päättelypyynnön vuokaaviossa, tallennustyyppi, laskentaesiintymän tyyppi, verkkoinfrastruktuuri, sovelluskoodi, päätelmiä palvelevan ohjelmiston ajonaika ja kokoonpano ja paljon muuta.

Jos käytät SageMakeria ML-mallien käyttöönotossa, sinun on valittava laskentaesiintymä, jolla on paras hinta-suorituskyky, mikä on monimutkainen ja iteratiivinen prosessi, joka voi viedä viikkoja kokeiluun. Ensin sinun on valittava oikea ML-ilmentymätyyppi yli 70 vaihtoehdosta mallijesi resurssivaatimusten ja syöttötietojen koon perusteella. Seuraavaksi sinun on optimoitava malli valitulle ilmentymätyypille. Lopuksi sinun on luotava ja hallittava infrastruktuuri, jotta voit suorittaa kuormitustestejä ja säätää pilviasetuksia optimaalisen suorituskyvyn ja kustannusten saavuttamiseksi. Kaikki tämä voi viivyttää mallin käyttöönottoa ja markkinoille tuloa. Lisäksi sinun on arvioitava viiveen, suorituskyvyn ja kustannusten väliset kompromissit optimaalisen käyttöönottokokoonpanon valitsemiseksi. SageMakerin päättelysuositus valitsee automaattisesti oikean laskentaesiintymän tyypin, ilmentymien lukumäärän, säilön parametrit ja mallin optimoinnit päätelmiä varten maksimoidakseen suorituskyvyn, vähentääkseen viivettä ja minimoikseen kustannuksia.

Reaaliaikainen päättely ja latenssi SageMakerissa

SageMakerin reaaliaikainen päättely on ihanteellinen päättelytyökuormille, joissa sinulla on reaaliaikaisia, interaktiivisia, alhaisen latenssin vaatimuksia. SageMaker-päätelmäpäätepisteiden päättelypyyntöjen viiveen seuraamiseen on neljä yleisimmin käytettyä mittaria.

• Säilön viive – Aika, joka kuluu pyynnön lähettämiseen, vastauksen hakemiseen mallin säilöstä ja päätelmien tekemiseen säilössä. Tämä mittari on saatavilla Amazon CloudWatchissa osana Kutsun metriikka julkaissut SageMaker.
• Mallin latenssi – Kaikkien SageMaker-säiliöiden yhteenlaskettu aika päätelmäputki. Tämä mittari on saatavilla Amazon CloudWatchissa osana Kutsun metriikka julkaissut SageMaker.
• Overhead latenssi – Mitattu ajasta, jolloin SageMaker vastaanottaa pyynnön, kunnes se palauttaa vastauksen asiakkaalle, vähennettynä mallin viiveellä. Tämä mittari on saatavilla Amazon CloudWatchissa osana Kutsun metriikka julkaissut SageMaker.
• Päästä päähän -latenssi – Mitataan siitä hetkestä, kun asiakas lähettää päättelypyynnön, kunnes se saa vastauksen takaisin. Asiakkaat voivat julkaista tämän mukautettuna mittarina Amazon CloudWatchissa.

Seuraava kaavio havainnollistaa näitä komponentteja.

Säilön viive riippuu useista tekijöistä; seuraavat ovat tärkeimpiä:

• Taustalla oleva protokolla (HTTP(t)/gRPC), jota käytetään kommunikointiin päättelypalvelimen kanssa
• Uusien TLS-yhteyksien luomiseen liittyvät lisäkustannukset
• Pyynnön/vastauksen hyötykuorman serialisointiaika
• Pyydä taustalla olevan päättelypalvelimen tarjoamia jonotus- ja erätoimintoja
• Pyydä taustalla olevan päättelypalvelimen tarjoamia ajoitusominaisuuksia
• Päätelmäpalvelimen ajonaikainen suorituskyky
• Esi- ja jälkikäsittelykirjastojen suorituskyky ennen mallin ennustusfunktion kutsumista
• Taustalla olevan ML-kehyksen taustajärjestelmän suorituskyky
• Mallikohtaiset ja laitteistokohtaiset optimoinnit

Tässä viestissä keskitymme ensisijaisesti säilön latenssin optimointiin sekä kokonaiskapasiteettiin ja kustannuksiin. Tarkemmin sanottuna tutkimme SageMaker-säilön sisällä toimivaa Triton Inference Serverin suorituskyvyn viritystä.

Käytä tapauskatsausta

NLP-mallien käyttöönotto ja skaalaaminen tuotantoasetuksissa voi olla melko haastavaa. NLP-mallit ovat usein kooltaan erittäin suuria ja sisältävät miljoonia malliparametreja. Optimaaliset mallikonfiguraatiot vaaditaan tuotantotason NLP-sovellusten tiukkojen suorituskyky- ja skaalautuvuusvaatimusten täyttämiseksi.

Tässä viestissä vertailemme NLP-käyttötapausta käyttämällä SageMaker-reaaliaikaista päätepistettä, joka perustuu Triton Inference Server -säilöön, ja suosittelemme suorituskyvyn virityksen optimointia ML-käyttötapauksellemme. Käytämme suurta, esikoulutettua muuntajapohjaista Hugging Facea BERT iso koteloitu malli, jolla on noin 336 miljoonaa malliparametria. Binääriluokittelumallissa käytetty syöttölause on täytetty ja katkaistu siten, että syötesekvenssin enimmäispituus on 512 merkkiä. Päätelmäkuormitustesti simuloi 500 kutsua sekunnissa (enintään 30,000 XNUMX kutsua minuutissa) ja ModelLatency alle 0.5 sekuntia (500 millisekuntia).

Seuraavassa taulukossa on yhteenveto vertailuarvomme kokoonpanosta.

NVIDIA Triton Inference Server

Triton Inference Server on erityisesti suunniteltu mahdollistamaan skaalautuva, nopea ja helppo mallien käyttöönotto tuotannossa. Triton tukee useita merkittäviä AI-kehyksiä, mukaan lukien TensorFlow, TensorRT, PyTorch, XGBoost ja ONNX. Python- ja C++ mukautettujen taustaohjelmien avulla voit myös toteuttaa päättelytyökuormituksen mukautetuissa käyttötapauksissa.

Mikä tärkeintä, Triton tarjoaa yksinkertaisen konfigurointiin perustuvan asennuksen malleidesi isännöintiä varten, mikä paljastaa runsaan joukon suorituskyvyn optimointiominaisuuksia, joita voit käyttää pienellä koodauksella.

Triton lisää päättelyn suorituskykyä maksimoimalla laitteiston käytön erilaisilla optimointitekniikoilla (samanaikaiset malliajot ja dynaaminen eräajo ovat yleisimmin käytettyjä). Optimaalisten mallikonfiguraatioiden löytäminen dynaamisten eräkokojen ja samanaikaisten malliesiintymien lukumäärän erilaisista yhdistelmistä on avainasemassa, jotta voidaan tehdä reaaliaikaisia ​​päätelmiä edullisessa Triton-palvelussa.

Dynaaminen eräajo

Monilla toimijoilla on tapana suorittaa johtopäätös peräkkäin, kun palvelinta kutsutaan useilla itsenäisillä pyynnöillä. Vaikka käyttöönotto onkin helpompi, se ei yleensä ole paras käytäntö käyttää GPU:n laskentatehoa. Tämän ratkaisemiseksi Triton tarjoaa sisäänrakennetut optimoinnit dynaaminen erä yhdistää nämä riippumattomat päättelypyynnöt palvelinpuolella suuremman erän muodostamiseksi dynaamisesti suorituskyvyn lisäämiseksi. Seuraava kaavio havainnollistaa Tritonin ajonaikaista arkkitehtuuria.

Edellisessä arkkitehtuurissa kaikki pyynnöt saavuttavat ensin dynaamisen erän ennen kuin ne siirtyvät todellisiin mallin ajoitusjonoihin odottamaan päätelmiä. Voit määrittää haluamasi eräkoot dynaamista erää varten käyttämällä ensisijainen_erän_koko asetukset mallin kokoonpanossa. (Huomaa, että muodostetun erän koon on oltava pienempi kuin max_erän_koko malli tukee.) Voit myös määrittää max_queue_delay_microseconds määrittääksesi enimmäisviiveen eräajossa, jotta se odottaa muita pyyntöjä liittyä joukkoon latenssivaatimustesi perusteella.

Seuraava koodinpätkä näyttää, kuinka voit lisätä tämän ominaisuuden mallin määritystiedostoihin asettaaksesi dynaamisen erän ensisijaiseksi eräkooksi 16 todellista päättelyä varten. Nykyisillä asetuksilla malliinstanssi kutsutaan välittömästi, kun haluttu eräkoko 16 täyttyy tai 100 mikrosekunnin viiveaika on kulunut siitä, kun ensimmäinen pyyntö saavutti dynaamisen erän.

dynamic_batching { preferred_batch_size: 16 max_queue_delay_microseconds: 100 }

Mallit käynnissä samanaikaisesti

Toinen Tritonissa tarjottu olennainen optimointi laitteiston käytön maksimoimiseksi ilman ylimääräisiä latenssikustannuksia on samanaikainen mallin suoritus, joka mahdollistaa useiden mallien tai saman mallin useiden kopioiden käytön rinnakkain. Tämän ominaisuuden ansiosta Triton pystyy käsittelemään useita päättelypyyntöjä samanaikaisesti, mikä lisää päättelyn suorituskykyä käyttämällä laitteiston muutoin käyttämättömänä olevaa laskentatehoa.

Seuraava kuva näyttää, kuinka voit helposti määrittää eri mallien käyttöönottokäytännöt vain muutaman rivin koodimuutoksilla. Esimerkiksi konfiguraatio A (vasemmalla) osoittaa, että voit lähettää saman kokoonpanon kahdesta malliinstanssista bert-large-uncased kaikkiin käytettävissä oleviin GPU:ihin. Sitä vastoin kokoonpano B (keskellä) näyttää erilaisen kokoonpanon vain GPU 0:lle muuttamatta muiden GPU:iden käytäntöjä. Voit myös ottaa käyttöön eri mallien ilmentymiä yhdessä grafiikkasuorittimessa, kuten kokoonpanossa C (oikealla) näkyy.

Konfiguraatiossa C laskenta-ilmentymä voi käsitellä kahta samanaikaista pyyntöä DistilGPT-2-mallille ja seitsemän samanaikaista pyyntöä bert-large-uncased malli rinnakkain. Näillä optimoinnilla laitteistoresurssit voidaan hyödyntää paremmin palveluprosessissa, mikä parantaa suorituskykyä ja parantaa työtaakkaasi kustannustehokkuutta.

TensorRT

NVIDIA TensorRT on SDK korkean suorituskyvyn syväoppimisen päättelyyn, joka toimii saumattomasti Tritonin kanssa. TensorRT, joka tukee kaikkia merkittäviä syväoppimiskehystä, sisältää päätelmien optimoijan ja suoritusajan, joka tarjoaa alhaisen viiveen ja suuren suorituskyvyn, jotta voidaan suorittaa johtopäätöksiä valtavilla tietomäärillä tehokkaiden optimointien avulla.

TensorRT optimoi kaavion minimoidakseen muistin jalanjäljen vapauttamalla tarpeetonta muistia ja käyttämällä sitä tehokkaasti uudelleen. Lisäksi TensorRT-kokoelma yhdistää harvat toiminnot mallikaavion sisällä muodostaen suuremman ytimen, jotta vältytään useiden pienten ytimen käynnistysten aiheuttamalta. Ytimen automaattinen viritys auttaa sinua hyödyntämään laitteistoa täysimääräisesti valitsemalla kohde-GPU:n parhaan algoritmin. CUDA-striimien avulla mallit voivat toimia rinnakkain, mikä maksimoi GPU-käyttösi parhaan suorituskyvyn saavuttamiseksi. Viimeisenä mutta ei vähäisimpänä, kvantisointitekniikka voi käyttää täysin Tensor-ytimien sekoitettua tarkkuuskiihdytystä mallin ajamiseen FP32:ssa, TF32:ssa, FP16:ssa ja INT8:ssa parhaan päättelykyvyn saavuttamiseksi.

Triton SageMaker-isännöinnissä

SageMaker-isännöinti palvelut ovat joukko SageMakerin ominaisuuksia, joiden tarkoituksena on helpottaa mallin käyttöönottoa ja palvelua. Se tarjoaa useita vaihtoehtoja eri käyttötapauksiin räätälöityjen ML-mallien helpottamiseen, automaattiseen skaalaukseen, valvontaan ja optimointiin. Tämä tarkoittaa, että voit optimoida käyttöönotot kaikentyyppisille käyttötavoille aina pysyvistä ja aina saatavilla olevista palvelimettomista vaihtoehdoista tilapäisiin, pitkään jatkuviin tai eräpäättelytarpeisiin.

SageMaker-hosting-sateenvarjossa on myös joukko SageMaker-päätelmä Deep Learning Containers -säilöjä (DLC), jotka toimitetaan valmiiksi pakattuna sopivan mallin palvelinohjelmiston kanssa vastaavaa tuettua ML-kehystä varten. Tämän avulla voit saavuttaa korkean johtopäätöksen suorituskyvyn ilman mallipalvelimen asennusta, mikä on usein mallin käyttöönoton monimutkaisin tekninen näkökohta, eikä se yleensä kuulu tietotieteilijän taitoon. Triton-päätelmäpalvelin on nyt saatavissa SageMaker Deep Learning Containersissa (DLC).

Tämä laaja valikoima vaihtoehtoja, modulaarisuus ja erilaisten tarjoilukehysten helppokäyttöisyys tekevät SageMakerista ja Tritonista tehokkaan parin.

SageMaker Inference Recommender -testitulosten vertailuun

Käytämme SageMaker Inference Recommender -ohjelmaa kokeilujen suorittamiseen. SageMaker Inference Recommender tarjoaa kahdentyyppisiä töitä: oletus- ja edistynyt työt, kuten seuraavassa kaaviossa näkyy.

Oletustyö tarjoaa suosituksia ilmentymätyypeistä, joissa on vain malli ja näytteen hyötykuorma vertailua varten. Instanssesuositusten lisäksi palvelu tarjoaa myös suorituskykyä parantavia ajonaikaisia ​​parametreja. Oletustyön suositusten tarkoituksena on kaventaa esiintymän hakua. Joissakin tapauksissa se voi olla ilmentymäperhe, ja toisissa se voi olla tietyt ilmentymätyypit. Oletustyön tulokset syötetään sitten lisätyöhön.

Edistyksellinen työ tarjoaa enemmän säätimiä suorituskyvyn hienosäätöä varten. Nämä ohjaimet simuloivat todellista ympäristöä ja tuotannon vaatimuksia. Näihin ohjauksiin kuuluu liikennekuvio, jonka tarkoituksena on lavastella vertailuarvojen pyyntökuvio. Voit asettaa ramppeja tai tasaista liikennettä käyttämällä liikennekuvion useita vaiheita. Esimerkiksi an InitialNumberOfUsers 1, SpawnRate 1, ja KestoSekunteina 600:sta saattaa johtaa 10 minuutin ramppiliikenteeseen, kun 1 samanaikainen käyttäjä on alussa ja 10 lopussa. Lisäksi ohjaimissa MaxInvocations ja Model LatencyThresholds asettaa tuotannon kynnyksen, joten kun jokin kynnysarvoista ylittyy, benchmarking pysähtyy.

Lopuksi, suositusmittareita sisältävät suorituskyvyn, latenssin maksimiläpäisykyvyllä ja päättelykohtaisen hinnan, joten niitä on helppo verrata.

Käytämme SageMaker Inference Recommenderin edistynyttä työtyyppiä kokeilujen suorittamiseen saadaksemme lisähallintaa liikennemalleista ja hienosäätääksemme käyttösäilön asetuksia.

Kokeilun asetukset

Käytämme SageMaker Inference Recommenderin mukautettua kuormitustestiominaisuutta käyttötapauksessamme kuvatun NLP-profiilin vertailuun. Ensin määritellään seuraavat NLP-malliin ja ML-tehtävään liittyvät edellytykset. SageMaker Inference Recommender käyttää näitä tietoja johtopäätöksen Docker-kuvan hakemiseen Amazonin elastisten säiliörekisteri (Amazon ECR) ja rekisteröi malli SageMaker-mallirekisteriin.

SageMaker Inference Recommenderin liikennekuvioiden konfiguraatiot antavat meille mahdollisuuden määrittää eri vaiheet mukautetulle kuormitustestille. Kuormitustesti alkaa kahdella ensimmäisellä käyttäjällä ja synnyttää kaksi uutta käyttäjää joka minuutti yhteensä 25 minuutin (1500 sekunnin) ajan seuraavan koodin mukaisesti:

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

Kokeilemme saman mallin kuormitustestausta kahdessa eri tilassa. PyTorch-pohjaisissa kokeissa käytetään standardia, muuttumatonta PyTorch-mallia. TensorRT-pohjaisia ​​kokeita varten muunnamme PyTorch-mallin TensorRT-moottoriksi etukäteen.

Käytämme näissä kahdessa mallissa erilaisia ​​suorituskyvyn optimointiominaisuuksien yhdistelmiä, joista on yhteenveto seuraavassa taulukossa.

Testitulokset ja havainnot

Teimme kuormitustestejä kolmelle esiintymätyypille samassa g4dn-perheessä: ml.g4dn.xlarge, ml.g4dn.2xlarge ja ml.g4dn.12xlarge. Kaikilla g4dn-instanssityypeillä on pääsy NVIDIA T4 Tensor Core -grafiikkasuorittimiin ja 2. sukupolven Intel Cascade Lake -suorittimiin. Ilmentymätyyppien valinnan logiikka oli, että käytettävissä oli sekä ilmentymä, jossa oli vain yksi grafiikkasuoritin, että ilmentymä, jolla oli pääsy useisiin GPU:ihin – neljä tapauksessa ml.g4dn.12xlarge. Lisäksi halusimme testata, voisiko vCPU-kapasiteetin lisääminen instanssissa vain yhdellä käytettävissä olevalla GPU:lla parantaa kustannus-suorituskykysuhdetta.

Käydään ensin läpi yksittäisen optimoinnin nopeuttaminen. Seuraava kaavio osoittaa, että TensorRT-optimointi vähentää mallin latenssia 50 % verrattuna PyTorchin alkuperäiseen viiveeseen ml.g4dn.xlarge-esiintymässä. Tämä latenssin pieneneminen kasvaa yli kolminkertaiseksi ml.g4dn.12xlarge-monigrafiikkasuorittimissa. Samaan aikaan 30 %:n suorituskyvyn parannus on johdonmukainen molemmissa tapauksissa, mikä johtaa parempaan kustannustehokkuuteen TensorRT-optimointien soveltamisen jälkeen.

Dynaamisen erän avulla voimme saada lähes kaksinkertaisen suorituskyvyn parannuksella käyttämällä samaa laitteistoarkkitehtuuria kaikissa kokeissa ml.g2dn.xlarge, ml.g4dn.4xlarge ja ml.g2dn.4xlarge ilman havaittavaa latenssin kasvua.

Samoin samanaikainen mallin suoritus mahdollistaa noin 3–4-kertaisen suorituskyvyn parannuksen maksimoimalla grafiikkasuorittimen käyttöasteen ml.g4dn.xlarge-esiintymässä ja noin 2-kertaisen parannuksen sekä ml.g4dn.2xlarge-esiintymässä että usean grafiikkasuorittimen ml:n ilmentymässä. g4dn.12xlarge.. Tämä suorituskyvyn kasvu tulee ilman ylimääräisiä viiveitä.

Mikä parasta, voimme integroida kaikki nämä optimoinnit tarjotaksemme parhaan suorituskyvyn käyttämällä laitteistoresursseja täysimääräisesti. Seuraavassa taulukossa ja kaavioissa on yhteenveto kokeissamme saamistamme tuloksista.

[1] Alkuperäinen esiintymien määrä yllä olevassa taulukossa on niiden esiintymien suositeltu lukumäärä, joita käytetään automaattisen skaalauskäytännön kanssa työkuormituksen suorituskyvyn ja latenssivaatimusten ylläpitämiseksi.

[2] Yllä olevan taulukon tuntihinta on laskettu instanssityypin alkuperäisen esiintymän määrän ja hinnan perusteella.

Tulokset vahvistavat useimmiten eri suorituskyvyn optimointiominaisuuksien odotetun vaikutuksen:

• TensorRT-kokoelmalla on luotettavin vaikutus kaikissa ilmentymätyypeissä. Tapahtumat minuuttia kohden instanssia kohti kasvoivat 30–35 %, ja kustannukset laskivat jatkuvasti noin 25 % verrattuna TensorRT-moottorin suorituskykyyn oletusarvoiseen PyTorch BERT:hen (pt-base). TensorRT-moottorin lisääntynyt suorituskyky täydentyy ja hyödynnetään muilla testatuilla suorituskyvyn viritysominaisuuksilla.
• Kahden mallin lataaminen kuhunkin GPU:hun (instanssiryhmä) lähes kaksinkertaisti kaikki mitatut tiedot. Kutsujen määrä per instanssi kasvoi noin 80–90 %, mikä johti 50 %:n kustannussäästöihin, melkein kuin käyttäisimme kahta GPU:ta. Itse asiassa, amazonin pilvikello g4dn.2xlarge-kokeilujemme mittarit (esimerkiksi) vahvistavat, että sekä suorittimen että grafiikkasuorittimen käyttö kaksinkertaistuu, kun määritämme kahden mallin esiintymäryhmän.

Lisää suorituskyky- ja kustannusoptimointivinkkejä

Tässä viestissä esitetty vertailuarvo vain raaputtaa pintaa mahdollisista ominaisuuksista ja tekniikoista, joita voit käyttää Tritonin kanssa päättelyn suorituskyvyn parantamiseen. Nämä vaihtelevat tietojen esikäsittelytekniikoista, kuten binäärihyötykuormien lähettämisestä mallipalvelimelle tai suurempia eriä sisältävistä hyötykuormista, Tritonin alkuperäisiin ominaisuuksiin, kuten seuraaviin:

• Mallin lämmittely, joka estää alkuperäiset, hitaat päättelypyynnöt alustamalla mallin kokonaan ennen kuin ensimmäinen päättelypyyntö vastaanotetaan.
• Vastausvälimuisti, joka tallentaa välimuistiin toistuvat pyynnöt.
• Mallin kokoonpano, jonka avulla voit luoda liukuhihnan yhdestä tai useammasta mallista ja yhdistää tulo- ja lähtötensorit näiden mallien välillä. Tämä avaa mahdollisuuden lisätä esikäsittely- ja jälkikäsittelyvaiheita tai jopa päätellä muiden mallien kanssa kunkin pyynnön käsittelyvirtaan.

Aiomme testata ja vertailla näitä tekniikoita ja ominaisuuksia tulevassa postauksessa, joten pysy kuulolla!

Yhteenveto

Tässä viestissä tutkimme muutamia parametreja, joiden avulla voit maksimoida SageMakerin reaaliaikaisen päätepisteesi suorituskyvyn palvellaksesi PyTorch BERT -malleja Triton Inference Serverin kanssa. Käytimme SageMaker Inference Recommender -ohjelmaa vertailutestien tekemiseen näiden parametrien hienosäätämiseksi. Nämä parametrit liittyvät pohjimmiltaan TensorRT-pohjaiseen mallin optimointiin, mikä johtaa lähes 50 % parannukseen vasteajoissa verrattuna optimoimattomaan versioon. Lisäksi mallien samanaikainen käyttäminen ja Tritonin dynaamisen erän käyttö johti lähes 70 %:n kasvuun suorituskyvyssä. Näiden parametrien hienosäätö johti myös päättelykustannusten yleiseen laskuun.

Paras tapa saada oikeat arvot on kokeilemalla. Kuitenkin aloittaaksesi empiirisen tiedon rakentamisen suorituskyvyn virittämisestä ja optimoinnista, voit tarkkailla eri Tritoniin liittyvien parametrien yhdistelmiä ja niiden vaikutusta suorituskykyyn ML-malleissa ja SageMaker ML -esiintymissä.

SageMaker tarjoaa työkalut erottumattoman raskaiden nostojen poistamiseen ML:n elinkaaren jokaisesta vaiheesta, mikä helpottaa nopeaa kokeilua ja tutkimista, joita tarvitaan mallin käyttöönottojen täydelliseen optimointiin.

Löydät kuormitustestaukseen ja käyttöönottoon käytetyn muistikirjan osoitteesta GitHub. Voit päivittää Triton-kokoonpanot ja SageMaker Inference Recommender -asetukset käyttötapauksiisi sopiviksi saavuttaaksesi kustannustehokkaat ja parhaiten toimivat päättelytyökuormitukset.

Tietoja Tekijät

Vikram Elango on AI/ML Specialist Solutions -arkkitehti Amazon Web Servicesissä, jonka kotipaikka on Virginia USA. Vikram auttaa rahoitus- ja vakuutusalan asiakkaita suunnittelulla, ajattelujohtajuudella rakentamaan ja ottamaan käyttöön koneoppimissovelluksia mittakaavassa. Hän keskittyy tällä hetkellä luonnollisen kielen käsittelyyn, vastuulliseen tekoälyyn, päätelmien optimointiin ja ML:n skaalaukseen koko yrityksessä. Vapaa-ajallaan hän nauttii matkustamisesta, vaeltamisesta, ruoanlaitosta ja telttailusta perheensä kanssa.

João Moura on AI/ML Specialist Solutions -arkkitehti Amazon Web Servicesissä. Hän keskittyy enimmäkseen NLP-käyttötapauksiin ja auttaa asiakkaita optimoimaan Deep Learning -mallin koulutusta ja käyttöönottoa. Hän on myös aktiivinen matalakoodin ML-ratkaisujen ja ML-spesifisten laitteistojen kannattaja.

Mohan Gandhi on vanhempi ohjelmistosuunnittelija AWS:ssä. Hän on työskennellyt AWS:ssä viimeiset 9 vuotta ja työskennellyt useissa AWS-palveluissa, kuten EMR, EFA ja RDS Outpostsissa. Tällä hetkellä hän keskittyy parantamaan SageMaker Inference -kokemusta. Vapaa-ajallaan hän harrastaa patikointia ja maratonjuoksua.

Dhawal Patel on AWS:n koneoppimisarkkitehti. Hän on työskennellyt organisaatioiden kanssa suurista yrityksistä keskikokoisiin startup-yrityksiin hajautettuun tietojenkäsittelyyn ja tekoälyyn liittyvien ongelmien parissa. Hän keskittyy syväoppimiseen, mukaan lukien NLP- ja Computer Vision -alueet. Hän auttaa asiakkaita tekemään korkean suorituskyvyn mallipäätelmiä SageMakerissa.

Santosh Bhavani on Amazon SageMaker Elastic Inference -tiimin vanhempi tekninen tuotepäällikkö. Hän keskittyy auttamaan SageMaker-asiakkaita nopeuttamaan mallin päättelyä ja käyttöönottoa. Vapaa-ajallaan hän nauttii matkustamisesta, tenniksestä ja juomisesta paljon Pu'er-teetä.

Jiahong Liu on ratkaisuarkkitehti NVIDIA:n Cloud Service Provider -tiimissä. Hän auttaa asiakkaita ottamaan käyttöön koneoppimis- ja tekoälyratkaisuja, jotka hyödyntävät NVIDIA:n nopeutettua tietojenkäsittelyä vastaamaan heidän koulutus- ja päättelyhaasteisiinsa. Vapaa-ajallaan hän nauttii origamista, tee-se-itse-projekteista ja koripallon pelaamisesta.

• Coinsmart. Euroopan paras Bitcoin- ja kryptopörssi.
• Platoblockchain. Web3 Metaverse Intelligence. Tietoa laajennettu. VAPAA PÄÄSY.
• CryptoHawk. Altcoinin tutka. Ilmainen kokeilu.
• Lähde: https://aws.amazon.com/blogs/machine-learning/achieve-hyperscale-performance-for-model-serving-using-nvidia-triton-inference-server-on-amazon-sagemaker/