Alacsony késleltetésű tárhely elérése a döntési fa alapú ML-modellekhez az NVIDIA Triton Inference Serveren az Amazon SageMakeren

A gépi tanulási (ML) modellek telepítése nagyon szigorú teljesítmény- és késleltetési követelményeket támaszthat a mai vállalkozásokkal szemben. Az olyan felhasználási esetek, mint a csalásészlelés és a hirdetéselhelyezés, olyan példák, amikor az ezredmásodpercek számítanak, és kulcsfontosságúak az üzleti sikerhez. Szigorú szolgáltatási szintű megállapodásokat (SLA) kell teljesíteni, és egy tipikus kérés több lépést is igényelhet, például előfeldolgozást, adatátalakítást, modellkiválasztási logikát, modell-összesítést és utófeldolgozást. Nagy méretekben ez gyakran azt jelenti, hogy nagy mennyiségű forgalom fenntartása mellett alacsony késleltetést kell fenntartani. A gyakori tervezési minták közé tartoznak a soros következtetési folyamatok, az együttesek (szórási gyűjtés) és az üzleti logikai munkafolyamatok, amelyek eredményeképpen a kérés teljes munkafolyamata irányított aciklikus gráfként (DAG) valósul meg. Ahogy azonban a munkafolyamatok bonyolultabbá válnak, ez az általános válaszidő növekedéséhez vezethet, ami viszont negatívan befolyásolhatja a végfelhasználói élményt, és veszélyeztetheti az üzleti célokat. A Triton képes kezelni ezeket a felhasználási eseteket, amikor több modellt állítanak össze egy folyamatban, amelyek között bemeneti és kimeneti tenzorok vannak összekapcsolva, segítve ezzel a munkaterhelések kezelését.

Amikor az ML-modell-következtetéssel kapcsolatos céljait értékeli, számos lehetőség mérlegelhető, de kevés olyan alkalmas és bizonyított, mint Amazon SageMaker val vel Triton következtetési szerver. A Triton Inference Serverrel rendelkező SageMaker sok ügyfél népszerű választása volt, mert kifejezetten az átviteli sebesség és a hardver kihasználtságának maximalizálására készült, rendkívül alacsony (egy számjegyű ezredmásodperces) következtetési késleltetéssel. Támogatott ML keretrendszerek széles skálájával (többek között TensorFlow, PyTorch, ONNX, XGBoost és NVIDIA TensorRT) és infrastruktúra háttérrendszerekkel rendelkezik, beleértve az NVIDIA GPU-kat, CPU-kat és AWS Inferentia. Ezenkívül a Triton Inference Server integrálva van a SageMakerrel, egy teljesen felügyelt, végpontok közötti ML szolgáltatással, amely valós idejű következtetési lehetőségeket biztosít a modellek üzemeltetéséhez.

Ebben a bejegyzésben bemutatjuk a csalásészlelési csoport munkaterhelésének üzembe helyezését a SageMakerben a Triton Inference Server segítségével.

Megoldás áttekintése

Minden projekthez elengedhetetlen a követelmények listája és az erőfeszítések becslése, hogy megközelítőleg meg lehessen becsülni a projekt összköltségét. Fontos megbecsülni a befektetés megtérülését (ROI), amely alátámasztja a szervezet döntését. Néhány szempont, amelyet figyelembe kell venni, amikor a munkaterhelést áthelyezi a Tritonra:

Az erőfeszítés becslése kulcsfontosságú a szoftverfejlesztésben, és mérése gyakran hiányos, bizonytalan és zajos bemeneteken alapul. Az ML munkaterhelések nem különböznek egymástól. Az ML következtetés architektúráját több tényező is befolyásolja, amelyek közül néhány a következőket tartalmazza:

• Ügyféloldali késleltetési költségkeret – Meghatározza az ügyféloldali oda-vissza út maximális elfogadható várakozási idejét a következtetési válaszhoz, általában százalékokban kifejezve. A több tíz ezredmásodperces késleltetési költségkeretet igénylő munkaterhelések esetén a hálózati átvitelek megdrágulhatnak, így a modellek szélén való használata jobban megfelelne.
• Adatok hasznos teher elosztásának mérete – Hasznos teher, gyakran emlegetik üzenet törzse, az ügyféltől a modellhez továbbított kérési adatok, valamint a modelltől a klienshez továbbított válaszadatok. A hasznos teher mérete gyakran jelentős hatással van a késleltetésre, és ezt figyelembe kell venni.
• Adat formátuma – Meghatározza, hogy a hasznos teher hogyan kerüljön az ML modellbe. A formátum lehet ember által olvasható, például JSON és CSV, de vannak bináris formátumok is, amelyek gyakran tömörítettek és kisebb méretűek. Ez egy kompromisszum a tömörítési többlet és az átviteli méret között, ami azt jelenti, hogy a CPU-ciklusok és a várakozási idő hozzáadódik a tömörítéshez vagy kicsomagoláshoz, hogy megtakarítsák a hálózaton átvitt bájtokat. Ez a bejegyzés bemutatja, hogyan használhatja mind a JSON, mind a bináris formátumokat.
• Szoftververem és komponensek szükségesek – A verem olyan összetevők gyűjteménye, amelyek együtt működnek egy ML-alkalmazás támogatására, beleértve az operációs rendszert, a futási környezeteket és a szoftverrétegeket. A Triton beépített népszerű ML keretrendszerekkel érkezik, az ún backendek, például ONNX, TensorFlow, FIL, OpenVINO, natív Python és mások. Ön is írhat a egyéni háttérrendszer saját gyártású alkatrészekhez. Ez a bejegyzés egy XGBoost modellt és adat-előfeldolgozást mutat be, amelyeket az NVIDIA által biztosított FIL és Python Triton háttérrendszerekre helyezünk át.

Mindezek a tényezők létfontosságú szerepet játszanak a munkaterhelések teljesítményének értékelésében, de ebben a használati esetben arra a munkára összpontosítunk, amely ahhoz szükséges, hogy az ML-modelleket áthelyezzük a SageMakerbe a Triton Inference Server segítségével. Pontosabban, egy példát használunk egy csalásészlelő együttesre, amely Pythonban írt előfeldolgozási logikával rendelkező XGBoost modellből áll.

NVIDIA Triton következtetés szerver

A Triton Inference Servert az alapoktól kezdve úgy tervezték, hogy lehetővé tegye a csapatok számára a betanított AI-modellek telepítését, futtatását és méretezését bármilyen keretrendszerből GPU- vagy CPU-alapú infrastruktúrán. Ezen túlmenően úgy optimalizálták, hogy nagy teljesítményű következtetéseket kínáljon, olyan funkciókkal, mint a dinamikus kötegelés, párhuzamos futtatások, optimális modellkonfiguráció, modellegyüttes és streaming bemenetek támogatása.

A következő diagram egy példa NVIDIA Triton ensemble csővezetéket mutat be.

A munkaterhelésnek figyelembe kell vennie a Triton és a SageMaker hosting által biztosított képességeket, hogy maximalizálja a kínált előnyöket. Például a Triton támogatja a HTTP-t, valamint a C API, amelyek lehetővé teszik a rugalmasságot, valamint szükség esetén a hasznos teher optimalizálását. Amint korábban említettük, a Triton számos népszerű keretrendszert támogat, beleértve a TensorFlow-t, a PyTorch-ot, az ONNX-et, az XGBoost-ot és az NVIDIA TensorRT-t. Ezeket a keretrendszereket a Triton háttérrendszerek támogatják, és abban a ritka esetben, ha egy háttérprogram nem támogatja az Ön használati esetét, A Triton lehetővé teszi a saját megvalósítását és egyszerű integrálását.

A következő ábra az NVIDIA Triton architektúrára mutat példát.

NVIDIA Triton a SageMakeren

SageMaker hosting A szolgáltatások a SageMaker funkcióinak készletét jelentik, amelyek célja a modellek telepítésének és kiszolgálásának megkönnyítése. Számos lehetőséget kínál az ML-modellek könnyű üzembe helyezéséhez, automatikus méretezéséhez, figyeléséhez és optimalizálásához, a különböző felhasználási esetekre szabva. Ez azt jelenti, hogy a telepítéseket minden típusú használati mintára optimalizálhatja, a tartós és mindig elérhető kiszolgáló nélküli opciókkal az átmeneti, hosszú távú vagy kötegelt következtetési igényekig.

A SageMaker tárhely ernyője alatt található a SageMaker következtetést levonó Deep Learning Container (DLC) készlete is, amelyek a megfelelő támogatott ML keretrendszerhez megfelelő modellkiszolgálószoftverrel előre csomagolva érkeznek. Ez lehetővé teszi, hogy magas következtetési teljesítményt érjen el modellkiszolgáló-beállítás nélkül, ami gyakran a modelltelepítés legbonyolultabb technikai aspektusa, és általában nem része az adatkutatók készségeinek. A Triton következtetési szerver most van elérhető a SageMaker DLC-ken.

A lehetőségek széles skálája, a modularitás és a különféle kiszolgálási keretrendszerek egyszerű használata teszi a SageMaker-t és a Tritont erőteljes párosításra.

NVIDIA FIL háttérrendszer támogatás

Aktivitáskövető A Triton 22.05-ös verziója, az NVIDIA mostantól támogatja a számos népszerű ML-keretrendszer, köztük az XGBoost, a LightGBM, a Scikit-learn és a cuML által kiképzett erdőmodelleket. Ha a FIL-háttérrendszert használja a Tritonhoz, győződjön meg arról, hogy az Ön által megadott modelltermékek támogatottak. Például a FIL támogatja model_type xgboost, xgboost_json, lightgbmvagy treelite_checkpoint, jelezve, hogy a megadott modell XGBoost bináris, XGBoost JSON formátum, LightGBM szövegformátum vagy Treelite bináris formátumú-e.

Ez a háttértámogatás elengedhetetlen ahhoz, hogy a példánkban használjuk, mert a FIL támogatja az XGBoost modelleket. Az egyetlen szempont, amelyet ellenőrizni kell, annak biztosítása, hogy az általunk telepített modell támogatja-e a bináris vagy JSON formátumokat.

A megfelelő modellformátum biztosításán kívül egyéb szempontokat is figyelembe kell venni. A Triton FIL-háttérprogramja konfigurálható lehetőségeket biztosít a fejlesztők számára a munkaterhelések hangolásához és a modellfutási teljesítmény optimalizálásához. A konfiguráció dynamic_batching lehetővé teszi a Triton számára, hogy kliensoldali kéréseket tartson és kötegeljen a szerver oldalon, hogy hatékonyan használja a FIL párhuzamos számításait a teljes köteg együttes következtetésére. Az opció max_queue_delay_microseconds hibamentes szabályozást kínál arra vonatkozóan, mennyi ideig vár a Triton a köteg létrehozására. A FIL Shapley magyarázóval érkezik, amely a konfigurációval aktiválható treeshap_output; azonban szem előtt kell tartania, hogy a Shapley kimenetei rontják a teljesítményt a kimeneti mérete miatt. Egy másik fontos szempont az storage_type hogy kompromisszumot hozzon a memória helyigénye és a futási idő között. Például a tárolás SPARSE-ként való használata csökkentheti a memóriafelhasználást, míg a DENSE csökkentheti a modell futtatási teljesítményét a nagyobb memóriahasználat rovására. A legjobb választás kiválasztása a munkaterheléstől és a várakozási idő költségvetésétől függ, ezért javasoljuk, hogy tekintse át alaposabban a FIL backend GYIK és a a FIL-ben elérhető konfigurációk listája.

A modell elhelyezésének lépései a tritonon

Nézzük meg a csalásfelderítési használati esetünket annak példájaként, hogy mit kell figyelembe venni, amikor egy munkaterhelést áthelyezünk a Tritonra.

Határozza meg munkaterhelését

Ebben a felhasználási esetben csalásészlelési modellt használunk a lakossági vásárló fizetési folyamata során. A következtetési folyamat egy XGBoost algoritmust használ előfeldolgozási logikával, amely magában foglalja az adatok előkészítését az előfeldolgozáshoz.

Határozza meg a jelenlegi és célzott teljesítménymutatókat és egyéb célokat, amelyek alkalmazhatók

Előfordulhat, hogy a végpontok közötti következtetési idő túl sokáig tart ahhoz, hogy elfogadható legyen. A cél az lehet, hogy a több tíz ezredmásodperces késleltetésről egy számjegyű késleltetésre lépjen ugyanazon kérelmek mennyisége és megfelelő átviteli sebessége mellett. Megállapítja, hogy az idő nagy részét az adat-előfeldolgozás és az XGBoost modell emészti fel. Más tényezők, például a hálózat és a hasznos teher mérete minimális szerepet játszanak a végpontok közötti következtetési időhöz kapcsolódó többletterhelésben.

Dolgozzon visszafelé annak meghatározásához, hogy a Triton képes-e fogadni az Ön munkaterhelését az Ön igényei alapján

Annak megállapításához, hogy a Triton megfelel-e az Ön igényeinek, két fő aggodalomra ad okot. Az első annak biztosítása, hogy a Triton egy elfogadható kezelőfelület-beállítással, például HTTP vagy C API-val tudjon szolgálni.

Amint azt korábban említettük, fontos annak meghatározása is, hogy a Triton támogat-e olyan háttérrendszert, amely képes kiszolgálni az Ön műtermékeit. A Triton számos funkciót támogat backendek amelyek testreszabottak különféle keretrendszerek, például a PyTorch és a TensorFlow támogatására. Ellenőrizze, hogy a modellek támogatottak-e, és hogy a Triton által elvárt megfelelő modellformátummal rendelkezik-e. Ehhez először ellenőrizze, hogy a Triton háttérrendszer milyen modellformátumokat támogat. Sok esetben ez nem igényel változtatásokat a modellen. Más esetekben előfordulhat, hogy a modellt más formátumra kell átalakítani. A forrás- és célformátumtól függően különféle lehetőségek állnak rendelkezésre, mint például az a Python pácfájl a Treelite bináris ellenőrzőpont formátumának használatához.

Erre a felhasználási esetre meghatározzuk a FIL háttérrendszer módosítás nélkül támogatja az XGBoost modellt, és használhatjuk a Python háttérrendszer az előfeldolgozáshoz. A Triton együttes funkciójával tovább optimalizálhatja munkaterhelését azáltal, hogy elkerüli a költséges hálózati hívásokat a tárhelypéldányok között.

Készítsen tervet, és becsülje meg, mennyi erőfeszítést igényel a Triton tárhelyszolgáltatáshoz való használata

Beszéljünk arról a tervről, hogy a modelljeit a Tritonba helyezi át. Minden Triton telepítéshez a következőkre van szükség:

• A Triton-háttérprogramokhoz szükséges modelltermékek
• Triton konfigurációs fájlok
• Megfelelő szerkezetű modelltár mappa

A bejegyzés későbbi részében bemutatunk egy példát arra, hogyan lehet létrehozni ezeket a telepítési függőségeket.

Futtassa a tervet, és érvényesítse az eredményeket

Miután létrehozta a szükséges fájlokat és melléktermékeket a megfelelően felépített modelltárban, hangolnia kell a központi telepítést, és tesztelnie kell annak ellenőrzésére, hogy elérte-e a célmutatókat.

Ezen a ponton használhatja SageMaker Inference Recommender hogy meghatározza, melyik végpontpéldánytípus a legmegfelelőbb az Ön igényeinek megfelelően. Ezenkívül a Triton eszközöket biztosít az összeépítés optimalizálásához a jobb teljesítmény érdekében.

Implementáció

Most pedig nézzük a megvalósítás részleteit. Ehhez két jegyzetfüzetet készítettünk, amelyek példát mutatnak arra, hogy mire lehet számítani. Az első notebook bemutatja az adott XGBoost modell betanítását, valamint a betanításhoz és a következtetési időhöz használt előfeldolgozási logikát. Az második jegyzetfüzet bemutatja, hogyan készítjük elő a telepítéshez szükséges műtermékeket a Tritonon.

Az első jegyzetfüzet egy meglévő jegyzetfüzetet jelenít meg a szervezetében, amely a következőt használja ZUHATAG könyvtárak és a RAPIDS Conda kernel. Ez a példány az AWS által biztosított G4DN-példánytípuson fut, amelyet NVIDIA T4 processzorokkal gyorsított GPU.

Ebben a példában az előfeldolgozási feladatok profitálnak a GPU-gyorsításból, és nagymértékben használják a cuML- és cuDF-könyvtárakat. Példa erre a következő kódban, ahol a cuML kategorikus címkekódolását mutatjuk be. Emellett generálunk a label_encoders.pkl fájl, amellyel a kódolókat sorba rendezhetjük, és előfeldolgozásra használhatjuk a következtetési idő alatt.

Az első notebook az XGBoost modell betanításával és a műtermékek ennek megfelelő elmentésével zárul.

Ebben a forgatókönyvben a betanítási kód már létezett, és nincs szükség a modell módosítására a betanítás időpontjában. Ezen túlmenően, bár GPU-gyorsítást használtunk az előfeldolgozáshoz a képzés során, azt tervezzük, hogy CPU-kat használunk az előfeldolgozáshoz a következtetési időben. A bejegyzés későbbi részében bővebben kifejtjük.

Térjünk át a második notebookra, és emlékezzünk vissza, mire van szükségünk a sikeres Triton telepítéshez.

Először is szükségünk van a háttérprogramok által igényelt modelltermékekre. A fájlok, amelyeket létre kell hoznunk ehhez az együtteshez, a következők:

• Műtermékek előfeldolgozása (model.py, label_encoders.pkl)
• XGBoost modell műtermékek (xgboost.json)

A Triton Python háttérprogramja megköveteli, hogy egy Conda környezetet használjunk függőségként. Ebben az esetben a Python-háttérprogramot használjuk a nyers adatok előfeldolgozására, mielőtt betápláljuk azokat a FIL-háttérrendszerben futó XGBoost-modellbe. Annak ellenére, hogy eredetileg RAPIDS cuDF és cuML könyvtárakat használtunk az adatok előfeldolgozásához (ahogyan korábban a GPU-nkkal hivatkoztunk), itt a Pandas és a Scikit-learn előfeldolgozási függőségeket használjuk a következtetési idő (a CPU segítségével) előfeldolgozásaként. Ezt három okból tesszük:

• Megmutatja, hogyan hozhat létre Conda környezetet a függőségeihez, és hogyan csomagolja azt a formátum várható a Triton Python háttérprogramja.
• A Python háttérrendszerben futó előfeldolgozási modell bemutatásával a CPU-n, míg az XGBoost modell a GPU-n fut a FIL-háttérrendszerben, bemutatjuk, hogy a Triton ensemble-folyamatában lévő egyes modellek hogyan futhatnak különböző keretrendszer-háttérrendszeren, és hogyan futhatnak különböző hardvereken különböző konfigurációk.
• Kiemeli, hogy a RAPIDS-könyvtárak (cuDF, cuML) hogyan kompatibilisek CPU-társaikkal (Pandas, Scikit-learn). Így meg tudjuk mutatni, hogyan LabelEncoders A cuML-ben létrehozott szöveg használható a Scikit-learnben és fordítva. Vegye figyelembe, hogy ha nagy mennyiségű táblázatos adat előfeldolgozása várható a következtetési idő alatt, továbbra is használhatja a RAPIDS-t a GPU-gyorsításhoz.

Emlékezzünk vissza, hogy mi hoztuk létre a label_encoders.pkl fájlt az első jegyzetfüzetbe. Nincs más teendőnk a kategóriakódolásnál, mint hogy beépítsük a kódolásunkba model.py fájl előfeldolgozásra.

A Triton Python háttérrendszer által igényelt model.py fájl létrehozásához betartjuk a a háttér által igényelt formázás és tartalmazza a Python-logikánkat a bejövő tenzor feldolgozásához és a korábban hivatkozott címkekódoló használatához. Áttekintheti a filé előfeldolgozásra használják.

Az XGBoost modell esetében semmi mást nem kell tenni. Az első notebookban betanítottuk a modellt, és a Triton FIL háttérrendszere nem igényel további erőfeszítéseket az XGBoost modelleknél.

Ezután szükségünk van a Triton konfigurációs fájljaira. A Triton együttes minden modellje megköveteli a config.pbtxt fájlt. Emellett létrehozunk a config.pbtxt fájl az együttes egészére vonatkozóan. Ezek a fájlok lehetővé teszik a Triton számára, hogy megismerje az együttes metaadatait, például a várt bemenetekkel és kimenetekkel, valamint segít meghatározni az együtteshez társított DAG-t.

Végül egy modell Tritonon való üzembe helyezéséhez szükségünk van a modelltár mappánkra, hogy megfelelő mappaszerkezettel rendelkezzen. A Tritonnak speciális követelményei vannak a modelltár elrendezésére vonatkozóan. A legfelső szintű modelltároló könyvtáron belül minden modellnek saját alkönyvtára van, amely tartalmazza a megfelelő modell információit. A Triton minden modellkönyvtárának tartalmaznia kell legalább egy numerikus alkönyvtárat, amely a modell egy verzióját képviseli. A mi felhasználási esetünkben az eredményül kapott szerkezet a következőképpen néz ki.

Miután ez a három előfeltétel megvan, létrehozunk egy tömörített fájlt csomagolásként a telepítéshez, és feltöltjük ide Amazon egyszerű tárolási szolgáltatás (Amazon S3).

Most már létrehozhatunk egy SageMaker modellt abból a modelltárból, amelyet az előző lépésben feltöltöttünk az Amazon S3-ra.

Ebben a lépésben megadjuk a további környezeti változót is SAGEMAKER_TRITON_DEFAULT_MODEL_NAME, amely megadja a Triton által betöltendő modell nevét. A kulcs értékének meg kell egyeznie az Amazon S3-ra feltöltött modellcsomagban található mappanévvel. Ez a változó nem kötelező egyetlen modell esetén. Ensemble modellek esetén ezt a kulcsot meg kell adni ahhoz, hogy a Triton elinduljon a SageMakerben.

Ezenkívül beállíthatja SAGEMAKER_TRITON_BUFFER_MANAGER_THREAD_COUNT és SAGEMAKER_TRITON_THREAD_COUNT a szálak számának optimalizálásához. Mindkét konfigurációs érték segít behangolni a CPU-kon futó szálak számát, így jobb kihasználtságot érhet el, ha növeli ezeket az értékeket a több maggal rendelkező CPU-k esetében. Az esetek többségében az alapértelmezett értékek gyakran jól működnek, de érdemes lehet kísérletezni, hátha további hatékonyságot érhet el a munkaterhelés.

Az előző modellel létrehozunk egy végpont konfigurációt, ahol megadhatjuk a végpontban kívánt példányok típusát és számát.

Végül az előző végpont-konfigurációt használjuk egy új SageMaker-végpont létrehozásához, és várjuk meg a központi telepítés befejezését. Az állapot a következőre változik: InService miután a telepítés sikeres volt.

Ez az! A végpont készen áll a tesztelésre és az érvényesítésre. Ezen a ponton érdemes lehet különféle eszközöket használni a példánytípusok és konfigurációk optimalizálásához a lehető legjobb teljesítmény elérése érdekében. A következő ábra egy példát mutat be azokra a nyereségekre, amelyeket a FIL háttérrendszer használatával lehet elérni egy XGBoost modellhez a Tritonon.

Összegzésként

Ebben a bejegyzésben végigvezettük Önt egy XGBoost ensemble munkaterhelés telepítésén a SageMakerben a Triton Inference Server segítségével. A munkaterhelések áthelyezése a Tritonra a SageMakeren jótékony megtérülést jelenthet a befektetésen. Mint minden technológiai átvételnél, itt is kulcsfontosságú az átvilágítási folyamat és a terv, és egy ötlépéses folyamatot részleteztünk, amely végigvezeti Önt, mit kell figyelembe vennie a munkaterhelések áthelyezésekor. Ezen túlmenően mélyrehatóan belemerültünk a Python előfeldolgozást és XGBoost modellt használó együttes telepítéséhez szükséges lépésekbe a SageMaker Tritonon.

A SageMaker olyan eszközöket biztosít, amelyekkel az ML életciklusának minden szakaszában eltávolítható a differenciálatlan nehéz teher, megkönnyítve ezzel a gyors kísérletezést és feltárást, amely a modellbevezetések teljes optimalizálásához szükséges. A SageMaker tárhely-támogatás a Triton Inference Server számára alacsony késleltetésű, magas tranzakciók másodpercenkénti (TPS) munkaterhelést tesz lehetővé.

A példához használt notebookokat itt találja GitHub.

---

A szerzőről

James Parker az Amazon Web Services megoldástervezője. Együttműködik az Amazon.com-tal az AWS technológiai megoldások tervezésében, kiépítésében és üzembe helyezésében, és különösen érdeklődik az AI és a gépi tanulás iránt. Szabadidejében szívesen keres új kultúrákat, új tapasztalatokat, és naprakész marad a legújabb technológiai trendekkel.

Jiahong Liu az NVIDIA Cloud Service Provider csapatának megoldástervezője. Segíti az ügyfeleket a gépi tanulási és mesterséges intelligencia-megoldások elfogadásában, amelyek az NVIDIA gyorsított számítástechnikáját használják ki a képzési és következtetési kihívások megoldására. Szabadidejében szereti az origamit, a barkácsprojekteket és a kosárlabdát.

Kshitiz Gupta az NVIDIA megoldástervezője. Szívesen oktatja felhőügyfeleit az NVIDIA által kínált GPU AI-technológiákról, és segít nekik gépi tanulási és mély tanulási alkalmazásaik felgyorsításában. Munkán kívül szeret futni, túrázni és vadvilágot nézni.

Bruno Aguiar de Melo az Amazon.com szoftverfejlesztő mérnöke, ahol segít a tudományos csapatoknak ML munkaterhelések felépítésében, telepítésében és kiadásában. Érdekelnek az ML modellezési/tervezési fázisban a műszerezettség és a vezérelhető szempontok, amelyeket figyelembe kell venni és mérni kell abból a belátásból, hogy a modellvégrehajtási teljesítmény ugyanolyan fontos, mint a modell minőségi teljesítménye, különösen a késleltetési korlátos felhasználási esetekben. Szabadidejében szeret borozni, társasjátékozni és főzni.

Eliuth Triana az NVIDIA fejlesztői kapcsolatok menedzsere. Összeköti az Amazon és az AWS termékvezetőit, fejlesztőit és tudósait az NVIDIA technológusaival és termékvezetőivel, hogy felgyorsítsa az Amazon ML/DL munkaterhelését, az EC2-termékeket és az AWS AI-szolgáltatásokat. Emellett Eliuth szenvedélyes hegyikerékpáros, síelő és pókerjátékos.