Saavuta matalaviiveinen isännöinti päätöspuupohjaisille ML-malleille NVIDIA Triton Inference Server -palvelimella Amazon SageMakerissa

Koneoppimismallien (ML) käyttöönotoilla voi nykyään olla erittäin vaativia suorituskyky- ja viivevaatimuksia yrityksille. Käyttötapaukset, kuten petosten havaitseminen ja mainosten sijoittelu, ovat esimerkkejä, joissa millisekunneilla on merkitystä ja ne ovat tärkeitä liiketoiminnan menestykselle. Tiukat palvelutason sopimukset (SLA) on täytettävä, ja tyypillinen pyyntö voi vaatia useita vaiheita, kuten esikäsittelyä, tietojen muuntamista, mallin valintalogiikkaa, mallien yhdistämistä ja jälkikäsittelyä. Mittakaavassa tämä tarkoittaa usein valtavan liikennemäärän ylläpitämistä ja samalla alhaisen viiveen ylläpitämistä. Yleisiä suunnittelumalleja ovat sarjapäätelmäputket, ensembles (scatter-gather) ja liiketoimintalogiikkatyönkulut, jotka johtavat pyynnön koko työnkulun toteuttamiseen suunnattuna asyklisenä kuvaajana (DAG). Työnkulkujen monimutkaistuessa tämä voi kuitenkin pidentyä kokonaisvastausaikoja, mikä puolestaan ​​voi vaikuttaa negatiivisesti loppukäyttäjän kokemuksiin ja vaarantaa liiketoimintatavoitteiden saavuttamisen. Triton pystyy käsittelemään näitä käyttötapauksia, joissa useita malleja kootaan liukuhihnassa ja niiden väliin on kytketty tulo- ja lähtötensorit, mikä auttaa sinua käsittelemään näitä työkuormia.

Kun arvioit tavoitteitasi suhteessa ML-mallin päättelyyn, monia vaihtoehtoja voidaan harkita, mutta harvat ovat yhtä päteviä ja todistettuja kuin Amazon Sage Maker with Triton-päätepalvelin. SageMaker Triton Inference Server -palvelimella on ollut suosittu valinta monille asiakkaille, koska se on suunniteltu maksimoimaan suoritusteho ja laitteiston käyttö erittäin alhaisella (yksinumeroisella millisekuntia) päättelyviiveellä. Siinä on laaja valikoima tuettuja ML-kehyksiä (mukaan lukien TensorFlow, PyTorch, ONNX, XGBoost ja NVIDIA TensorRT) ja infrastruktuurin taustaohjelmia, mukaan lukien NVIDIA GPU:t, CPU:t ja AWS Inferencia. Lisäksi Triton Inference Server on integroitu SageMakeriin, joka on täysin hallittu päästä päähän ML-palvelu, joka tarjoaa reaaliaikaisia ​​päättelyvaihtoehtoja mallin isännöintiin.

Tässä viestissä käymme läpi petosten havaitsemisryhmän työtaakan käyttöönottoa SageMakerissa Triton Inference Serverin avulla.

Ratkaisun yleiskatsaus

Jokaisella projektilla on oltava luettelo vaatimuksista ja panostusarvio, jotta voidaan arvioida projektin kokonaiskustannuksia. On tärkeää arvioida sijoitetun pääoman tuotto (ROI), joka tukee organisaation päätöstä. Joitakin huomioitavia seikkoja siirrettäessä työtaakkaa Tritoniin ovat:

Vaikutuksen estimointi on avainasemassa ohjelmistokehityksessä, ja sen mittaus perustuu usein epätäydellisiin, epävarmoihin ja meluisiin syötteisiin. ML-työkuormat eivät eroa toisistaan. Useat tekijät vaikuttavat ML-päätelmien arkkitehtuuriin, joista osa sisältää:

• Asiakaspuolen viivebudjetti – Se määrittää asiakkaan puoleisen edestakaisen matkan suurimman hyväksyttävän odotusajan päättelyvastaukselle, joka ilmaistaan ​​yleensä prosenttipisteinä. Työkuormituksissa, jotka vaativat lähes kymmenien millisekuntien viivebudjetin, verkkosiirrot voivat tulla kalliiksi, joten mallien käyttäminen reunalla olisi sopivampi.
• Datan hyötykuorman jakelukoko – Hyötykuorma, jota usein kutsutaan nimellä viestin runko, on asiakkaalta mallille välitetty pyyntötieto sekä mallista asiakkaalle välitetty vastaustieto. Hyötykuorman koolla on usein suuri vaikutus latenssiin, ja se on otettava huomioon.
• Tietomuoto – Tämä määrittää, kuinka hyötykuorma lähetetään ML-malliin. Muoto voi olla ihmisen luettavissa, kuten JSON ja CSV, mutta on myös binäärimuotoja, jotka ovat usein pakattuja ja kooltaan pienempiä. Tämä on kompromissi pakkauksen ylärajan ja siirtokoon välillä, mikä tarkoittaa, että CPU-jaksot ja latenssi lisätään pakkaamiseen tai purkamiseen, jotta verkon yli siirretyt tavut säästyy. Tämä viesti näyttää kuinka käyttää sekä JSON- että binäärimuotoja.
• Ohjelmistopino ja komponentit vaaditaan – Pino on kokoelma komponentteja, jotka toimivat yhdessä ML-sovelluksen tukemiseksi, mukaan lukien käyttöjärjestelmä, suoritusajat ja ohjelmistokerrokset. Tritonissa on sisäänrakennetut suositut ML-kehykset, ns taustoja, kuten ONNX, TensorFlow, FIL, OpenVINO, natiivi Python ja muut. Voit myös kirjoittaa a mukautettu tausta omille kotimaisille komponenteillesi. Tämä viesti käsittelee XGBoost-mallia ja tietojen esikäsittelyä, jotka siirrämme NVIDIA:n toimittamiin FIL- ja Python Triton -taustajärjestelmiin, vastaavasti.

Kaikilla näillä tekijöillä pitäisi olla keskeinen rooli työkuormien suorituskyvyn arvioinnissa, mutta tässä käyttötapauksessa keskitymme työhön, jota tarvitaan ML-mallien siirtämiseen SageMakeriin Triton Inference Serverin avulla. Erityisesti käytämme esimerkkiä petosten havaitsemiskokonaisuudesta, joka koostuu XGBoost-mallista, jonka esikäsittelylogiikka on kirjoitettu Pythonissa.

NVIDIA Triton Inference Server

Triton Inference Server on suunniteltu alusta alkaen, jotta tiimit voivat ottaa käyttöön, käyttää ja skaalata koulutettuja tekoälymalleja mistä tahansa GPU- tai CPU-pohjaisen infrastruktuurin viitekehyksestä. Lisäksi se on optimoitu tarjoamaan korkean suorituskyvyn mittakaavassa olevia päätelmiä ominaisuuksilla, kuten dynaaminen erä, samanaikaiset ajot, optimaalinen mallikonfiguraatio, mallikokonaisuus ja suoratoistotulojen tuki.

Seuraavassa kaaviossa on esimerkki NVIDIA Triton Ensemble -putkilinjasta.

Työkuormituksessa tulee ottaa huomioon Tritonin ja SageMaker-isännöinnin tarjoamat ominaisuudet tarjottujen etujen maksimoimiseksi. Esimerkiksi Triton tukee HTTP:tä sekä a C API, jotka mahdollistavat joustavuuden sekä hyötykuorman optimoinnin tarvittaessa. Kuten aiemmin mainittiin, Triton tukee useita suosittuja kehyksiä, mukaan lukien TensorFlow, PyTorch, ONNX, XGBoost ja NVIDIA TensorRT. Näitä kehyksiä tuetaan Triton-taustaohjelmien kautta, ja siinä harvinaisessa tapauksessa, että taustajärjestelmä ei tue käyttötapaasi, Tritonin avulla voit toteuttaa omasi ja integroida sen helposti.

Seuraavassa kaaviossa on esimerkki NVIDIA Triton -arkkitehtuurista.

NVIDIA Triton SageMakerissa

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 päättelyn suorituskyvyn ilman mallipalvelimen asennusta, mikä on usein mallin käyttöönoton monimutkaisin tekninen osa, eikä se yleensä kuulu tietotieteilijän taitoon. Triton-päätelmäpalvelin on nyt saatavissa SageMaker DLC:issä.

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

NVIDIA FIL -taustatuki

Kanssa Tritonin versio 22.05, NVIDIA tukee nyt useiden suosittujen ML-kehysten, mukaan lukien XGBoost, LightGBM, Scikit-learn ja cuML, kouluttamia metsämalleja. Kun käytät Tritonin FIL-taustaohjelmaa, varmista, että toimittamasi malliartefaktit ovat tuettuja. Esimerkiksi FIL tukee model_type xgboost, xgboost_json, lightgbmtai treelite_checkpoint, joka osoittaa, onko toimitettu malli XGBoost-binäärimuodossa, XGBoost JSON-muodossa, LightGBM-tekstimuodossa tai Treelite-binäärimuodossa.

Tämä taustatuki on välttämätöntä, jotta voimme käyttää esimerkissämme, koska FIL tukee XGBoost-malleja. Ainoa tarkistettava seikka on varmistaa, että käyttämämme malli tukee binääri- tai JSON-muotoja.

Sen lisäksi, että varmistat, että sinulla on oikea mallimuoto, on otettava huomioon myös muita näkökohtia. Tritonin FIL-taustaohjelma tarjoaa konfiguroitavia vaihtoehtoja kehittäjille työkuormituksen säätämiseksi ja mallin suorituskyvyn optimoimiseksi. Kokoonpano dynamic_batching sallii Tritonin pitää asiakaspuolen pyynnöt ja jakaa ne palvelinpuolella, jotta FIL:n rinnakkaislaskentaa voidaan käyttää tehokkaasti päättelemään koko erä yhdessä. Vaihtoehto max_queue_delay_microseconds tarjoaa varman hallinnan siitä, kuinka kauan Triton odottaa erän muodostamista. FIL:n mukana tulee Shapley-selittäjä, joka voidaan aktivoida määrityksellä treeshap_output; Sinun tulee kuitenkin muistaa, että Shapley-lähdöt heikentävät suorituskykyä tulostekoonsa vuoksi. Toinen tärkeä näkökohta on storage_type jotta voidaan tehdä kompromissi muistin jalanjäljen ja suoritusajan välillä. Esimerkiksi tallennustilan käyttäminen SPARSE-muodossa voi vähentää muistin kulutusta, kun taas DENSE voi heikentää mallin suorituskykyä suuremman muistin käytön kustannuksella. Parhaan valinnan tekeminen kullekin näistä riippuu työmäärästäsi ja viivebudjetistasi, joten suosittelemme tutustumaan tarkemmin kaikkiin FIL-taustajärjestelmän UKK ja luettelo FIL:ssä saatavilla olevista kokoonpanoista.

Vaiheet mallin isännöimiseksi tritonilla

Katsotaanpa petosten havaitsemisen käyttötapaustamme esimerkkinä siitä, mitä tulee ottaa huomioon siirrettäessä työtaakkaa Tritoniin.

Tunnista työmääräsi

Tässä käyttötapauksessa meillä on petosten havaitsemismalli, jota käytetään vähittäisasiakkaan kassalla. Päätelmäliukuhihna käyttää XGBoost-algoritmia esikäsittelylogiikalla, joka sisältää tietojen valmistelun esikäsittelyä varten.

Tunnista nykyiset ja tavoitesuorituskykymittarit ja muut mahdollisesti soveltuvat tavoitteet

Saatat huomata, että päästä päähän -päättelyaikasi kestää liian kauan ollakseen hyväksyttävää. Tavoitteesi voisi olla siirtyä kymmenien millisekuntien viiveestä yksinumeroiseen viiveeseen samalla pyyntömäärällä ja vastaavalla suorituskyvyllä. Päätät, että suurin osa ajasta kuluu tietojen esikäsittelyyn ja XGBoost-malliin. Muilla tekijöillä, kuten verkon ja hyötykuorman koolla, on minimaalinen rooli päästä päähän -päättelyaikaan liittyvään yleiskustannuksiin.

Selvitä taaksepäin, pystyykö Triton isännöimään työtaakkaasi tarpeidesi perusteella

Jotta voit määrittää, pystyykö Triton vastaamaan tarpeisiisi, sinun on kiinnitettävä huomiota kahteen pääasialliseen huolenaiheeseen. Ensimmäinen on varmistaa, että Triton voi palvella hyväksyttävällä käyttöliittymävaihtoehdolla, kuten HTTP- tai C-sovellusliittymällä.

Kuten aiemmin mainittiin, on myös tärkeää määrittää, tukeeko Triton taustajärjestelmää, joka voi palvella esineitäsi. Triton tukee useita taustoja jotka on räätälöity tukemaan erilaisia ​​kehyksiä, kuten PyTorch ja TensorFlow. Tarkista, että mallejasi tuetaan ja että sinulla on oikea mallimuoto, jota Triton odottaa. Voit tehdä tämän tarkistamalla ensin, mitä mallimuotoja Triton-taustaosa tukee. Monissa tapauksissa tämä ei vaadi malliin muutoksia. Muissa tapauksissa mallisi saattaa edellyttää muuntamista toiseen muotoon. Lähde- ja kohdemuodosta riippuen käytettävissä on useita vaihtoehtoja, kuten muunnos a Python suolakurkkutiedosto käyttää Treeliten binaarista tarkistuspistemuotoa.

Tätä käyttötapausta varten määritämme FIL-taustaohjelma voi tukea XGBoost-mallia ilman muutoksia ja että voimme käyttää Python-taustaohjelma esikäsittelyä varten. Tritonin ensemble-ominaisuuden avulla voit edelleen optimoida työtaakkaasi välttämällä kalliita verkkopuheluita isännöintiinstanssien välillä.

Luo suunnitelma ja arvioi Tritonin käyttö isännöintiin

Puhutaanpa suunnitelmasta siirtää mallisi Tritoniin. Jokainen Tritonin käyttöönotto edellyttää seuraavaa:

• Triton-taustaohjelmien vaatimat malliartefaktit
• Triton-määritystiedostot
• Mallin arkistokansio, jolla on oikea rakenne

Näytämme esimerkin näiden käyttöönottoriippuvuuksien luomisesta myöhemmin tässä viestissä.

Suorita suunnitelma ja vahvista tulokset

Kun olet luonut tarvittavat tiedostot ja artefaktit oikein rakennetussa mallivarastossa, sinun on viritettävä käyttöönottosi ja testattava se varmistaaksesi, että olet nyt saavuttanut tavoitemittarisi.

Tässä vaiheessa voit käyttää SageMakerin päättelysuositus määrittääksesi, mikä päätepisteinstanssityyppi sopii sinulle parhaiten tarpeidesi perusteella. Lisäksi Triton tarjoaa työkaluja rakentamisen optimointiin parantaaksesi suorituskykyä.

Täytäntöönpano

Katsotaan nyt täytäntöönpanon yksityiskohtia. Tätä varten olemme laatineet kaksi muistikirjaa, jotka tarjoavat esimerkin siitä, mitä voidaan odottaa. The ensimmäinen muistikirja näyttää annetun XGBoost-mallin harjoittelun sekä esikäsittelylogiikan, jota käytetään sekä harjoitteluun että päättelyaikaan. The toinen muistikirja näyttää, kuinka valmistamme tarvittavat esineet Tritonin käyttöönottoa varten.

Ensimmäisessä muistikirjassa näkyy organisaatiossasi oleva muistikirja, joka käyttää NOPEA kirjastot ja RAPIDS Conda -ydin. Tämä ilmentymä toimii AWS:n tarjoamassa G4DN-ilmentymätyypissä, joka on GPU-kiihdytetty NVIDIA T4 -suorittimilla.

Esikäsittelytehtävät tässä esimerkissä hyötyvät GPU-kiihdytyksestä ja käyttävät voimakkaasti cuML- ja cuDF-kirjastoja. Esimerkki tästä on seuraavassa koodissa, jossa näytämme kategorisen etiketin koodauksen cuML:n avulla. Tuotamme myös a label_encoders.pkl tiedosto, jota voimme käyttää sarjoittamaan kooderit ja käyttämään niitä esikäsittelyyn päättelyajan aikana.

Ensimmäinen muistikirja päättyy kouluttamalla XGBoost-mallimme ja tallentamalla esineet vastaavasti.

Tässä skenaariossa koulutuskoodi oli jo olemassa, eikä malliin tarvita muutoksia koulutushetkellä. Lisäksi, vaikka käytimme GPU-kiihdytystä esikäsittelyyn koulutuksen aikana, aiomme käyttää suorittimia esikäsittelyyn päättelyhetkellä. Selitämme lisää myöhemmin postauksessa.

Siirrytään nyt toiseen muistikirjaan ja muistetaan, mitä tarvitsemme onnistuneeseen Tritonin käyttöönottoon.

Ensinnäkin tarvitsemme taustaohjelmien vaatimat malliartefaktit. Tiedostoja, jotka meidän on luotava tälle kokoonpanolle, ovat:

• Esikäsittely artefaktit (model.py, label_encoders.pkl)
• XGBoost-mallin esineet (xgboost.json)

Tritonin Python-taustaohjelma edellyttää, että käytämme Conda-ympäristöä riippuvuutena. Tässä tapauksessa käytämme Python-taustaa raakatietojen esikäsittelyyn ennen niiden syöttämistä FIL-taustajärjestelmässä suoritettavaan XGBoost-malliin. Vaikka käytimme alun perin RAPIDS cuDF- ja cuML-kirjastoja tietojen esikäsittelyyn (kuten aiemmin viitattiin GPU:llamme), käytämme tässä Pandasta ja Scikit-learnia esikäsittelyriippuvuuksina päättelyaikaan (käyttämällä CPU:ta). Teemme tämän kolmesta syystä:

• Osoittaaksesi kuinka luoda Conda-ympäristö riippuvuuksillesi ja miten se pakataan odotettu muoto Tritonin Python-taustaohjelmalla.
• Esittämällä esikäsittelymallin, joka toimii Python-taustajärjestelmässä prosessorissa, kun XGBoost-malli toimii GPU:ssa FIL-taustajärjestelmässä, havainnollistamme, kuinka jokainen Tritonin ensemble-putkilinjan malli voi toimia eri kehystaustajärjestelmässä ja eri laitteistoilla eri laitteilla. kokoonpanot.
• Se korostaa, kuinka RAPIDS-kirjastot (cuDF, cuML) ovat yhteensopivia prosessorivastineidensa (Pandas, Scikit-learn) kanssa. Tällä tavalla voimme näyttää kuinka LabelEncoders cuML:ssä luotua voidaan käyttää Scikit-learnissä ja päinvastoin. Huomaa, että jos aiot esikäsitellä suuria määriä taulukkotietoa päättelyn aikana, voit silti käyttää RAPIDSia grafiikkasuorittimen kiihdyttämiseen.

Muista, että loimme label_encoders.pkl tiedosto ensimmäiseen muistikirjaan. Luokkakoodaukselle ei voi tehdä muuta kuin sisällyttää se koodaukseen model.py tiedosto esikäsittelyä varten.

Luodaksemme Triton Python -taustajärjestelmän vaatiman model.py-tiedoston noudatamme taustajärjestelmän vaatima muotoilu ja sisällyttää Python-logiikkamme käsittelemään saapuvan tensorin ja käyttämään aiemmin viitattua etikettikooderia. Voit tarkastella tiedosto käytetään esikäsittelyyn.

XGBoost-mallille ei tarvitse tehdä enempää. Koulutimme mallin ensimmäisessä kannettavassa, ja Tritonin FIL-taustaosa ei vaadi ylimääräistä vaivaa XGBoost-malleilta.

Seuraavaksi tarvitsemme Triton-määritystiedostot. Jokainen Triton-sarjan malli vaatii a config.pbtxt tiedosto. Lisäksi luomme myös a config.pbtxt tiedosto koko yhtyeelle. Nämä tiedostot antavat Tritonille mahdollisuuden tietää kokonaisuuden metatiedot, kuten odottamamme tulot ja lähdöt, sekä auttaa määrittelemään kokonaisuuteen liittyvän DAG:n.

Lopuksi, jotta voimme ottaa mallin käyttöön Tritonissa, tarvitsemme mallin arkistokansiollamme oikean kansiorakenteen. Tritonilla on erityisiä vaatimuksia mallivaraston asettelulle. Ylimmän tason mallin arkistohakemistossa jokaisella mallilla on oma alihakemistonsa, joka sisältää tiedot vastaavasta mallista. Jokaisessa Tritonin mallihakemistossa on oltava vähintään yksi numeerinen alihakemisto, joka edustaa mallin versiota. Meidän käyttötapauksessamme tuloksena olevan rakenteen pitäisi näyttää seuraavalta.

Kun meillä on nämä kolme edellytystä, luomme pakatun tiedoston pakkaukseksi käyttöönottoa varten ja lataamme sen Amazonin yksinkertainen tallennuspalvelu (Amazon S3).

Voimme nyt luoda SageMaker-mallin mallivarastosta, jonka latasimme Amazon S3:een edellisessä vaiheessa.

Tässä vaiheessa tarjoamme myös lisäympäristömuuttujan SAGEMAKER_TRITON_DEFAULT_MODEL_NAME, joka määrittää Tritonin lataaman mallin nimen. Tämän avaimen arvon tulee vastata Amazon S3:een ladatun mallipaketin kansion nimeä. Tämä muuttuja on valinnainen yksittäisen mallin tapauksessa. Ensemble-mallien tapauksessa tämä avain on määritettävä, jotta Triton käynnistyy SageMakerissa.

Lisäksi voit asettaa SAGEMAKER_TRITON_BUFFER_MANAGER_THREAD_COUNT ja SAGEMAKER_TRITON_THREAD_COUNT lankojen määrän optimoimiseksi. Molemmat määritysarvot auttavat säätämään prosessoreissasi olevien säikeiden määrää, joten voit mahdollisesti saada paremman hyödyn lisäämällä näitä arvoja prosessoreille, joissa on suurempi määrä ytimiä. Useimmissa tapauksissa oletusarvot toimivat usein hyvin, mutta saattaa olla syytä kokeilla, voidaanko työkuormituksillasi saada lisää tehokkuutta.

Edellisellä mallilla luomme päätepisteen konfiguraation, jossa voimme määrittää päätepisteeseen haluttujen esiintymien tyypin ja määrän.

Lopuksi luomme edellisen päätepisteen kokoonpanon avulla uuden SageMaker-päätepisteen ja odotamme, että käyttöönotto on valmis. Tila vaihtuu muotoon InService sen jälkeen, kun käyttöönotto on onnistunut.

Se siitä! Päätepisteesi on nyt valmis testausta ja validointia varten. Tässä vaiheessa saatat haluta käyttää erilaisia ​​työkaluja, jotka auttavat optimoimaan ilmentymätyypit ja kokoonpanot parhaan mahdollisen suorituskyvyn saavuttamiseksi. Seuraavassa kuvassa on esimerkki hyödyistä, jotka voidaan saavuttaa käyttämällä FIL-taustaohjelmaa Tritonin XGBoost-mallissa.

Yhteenveto

Tässä viestissä opastimme sinut XGBoost-ensemble-työkuorman käyttöönotossa SageMakerissa Triton Inference Serverin avulla. Työkuormien siirtäminen Tritoniin SageMakerissa voi olla hyödyllistä sijoitetun pääoman tuottoa. Kuten missä tahansa teknologian käyttöönotossa, tarkistusprosessi ja suunnitelma ovat avainasemassa, ja esitimme viisivaiheisen prosessin, joka opastaa sinua läpi, mitä sinun tulee ottaa huomioon siirtäessäsi työtaakkaasi. Lisäksi syvennyimme vaiheisiin, joita tarvitaan Python-esikäsittelyä ja XGBoost-mallia käyttävän kokonaisuuden käyttöönottamiseksi SageMakerin Tritonissa.

SageMaker tarjoaa työkalut erottumattoman raskaiden nostojen poistamiseen ML-elinkaaren jokaisesta vaiheesta, mikä helpottaa nopeaa kokeilua ja tutkimista, joita tarvitaan mallin käyttöönottojen täydelliseen optimointiin. SageMaker-isännöintituki Triton Inference Serverille mahdollistaa matalan viiveen, korkean transaktioiden sekunnissa (TPS) työkuormituksen.

Löydät tässä esimerkissä käytetyt muistikirjat osoitteesta GitHub.

---

Kirjailijasta

James Park on ratkaisuarkkitehti Amazon Web Servicesissä. Hän työskentelee Amazon.comin kanssa suunnitella, rakentaa ja ottaa käyttöön teknologiaratkaisuja AWS:ssä, ja hän on erityisen kiinnostunut tekoälystä ja koneoppimisesta. Vapaa-ajallaan hän etsii uusia kulttuureja, uusia kokemuksia ja pysyy ajan tasalla viimeisimmistä teknologiatrendeistä.

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.

Kshitiz Gupta on NVIDIA:n ratkaisuarkkitehti. Hän nauttii pilviasiakkaiden kouluttamisesta NVIDIAn tarjoamista GPU-AI-tekniikoista ja heidän avustamisestaan ​​heidän koneoppimis- ja syväoppimissovellustensa nopeuttamisessa. Työn ulkopuolella hän nauttii juoksemisesta, patikoinnista ja villieläinten katselusta.

Bruno Aguiar de Melo on ohjelmistokehitysinsinööri Amazon.comissa, jossa hän auttaa tiederyhmiä rakentamaan, ottamaan käyttöön ja vapauttamaan ML-työkuormia. Hän on kiinnostunut instrumentoinnista ja ohjattavista näkökohdista ML-mallinnus-/suunnitteluvaiheessa, jotka on otettava huomioon ja mitattava oivalluksella, että mallin suorituskyky on yhtä tärkeä kuin mallin laadun suorituskyky, erityisesti latenssirajoitteisissa käyttötapauksissa. Vapaa-ajallaan hän nauttii viinistä, lautapeleistä ja ruoanlaitosta.

Eliuth Triana on NVIDIA:n kehittäjäsuhdepäällikkö. Hän yhdistää Amazon- ja AWS-tuotejohtajat, kehittäjät ja tutkijat NVIDIA-teknologioihin ja tuotejohtajiin nopeuttaakseen Amazonin ML/DL-työkuormia, EC2-tuotteita ja AWS AI -palveluita. Lisäksi Eliuth on intohimoinen maastopyöräilijä, hiihtäjä ja pokerinpelaaja.