Masinõppe demüstifitseerimine äärealadel tegelike kasutusjuhtude kaudu

serv on termin, mis viitab pilvest või suurest andmekeskusest kaugel asuvale asukohale, kus teil on arvutiseade (servaseade), mis suudab käivitada (serva) rakendusi. Äärearvutus on nendes servaseadmetes töökoormuste käitamine. Masinõpe servas (ML@Edge) on kontseptsioon, mis toob ML-mudelite kohapeal käitamise võimaluse ääreseadmetesse. Neid ML-mudeleid saab seejärel kutsuda servarakendus. ML@Edge on oluline paljude stsenaariumide jaoks, kus töötlemata andmeid kogutakse pilvest kaugel asuvatest allikatest. Nendel stsenaariumidel võivad olla ka erinõuded või piirangud.

• Madala latentsusega reaalajas prognoosid
• Kehv või olematu ühenduvus pilvega
• Juriidilised piirangud, mis ei luba andmeid välisteenustele saata
• Suured andmestikud, mida tuleb enne pilve vastuste saatmist kohapeal eeltöödelda

Järgmised on mõned paljudest kasutusjuhtudest, mis võivad kasu saada ML-mudelitest, mis töötavad seadmete läheduses, mis genereerivad prognooside jaoks kasutatavaid andmeid.

• Turvalisus ja ohutus – Piiratud ala, kus rasked masinad töötavad automatiseeritud sadamas, jälgitakse kaameraga. Kui inimene satub sellesse piirkonda kogemata, aktiveeritakse masinate peatamiseks ja inimese kaitsmiseks turvamehhanism.
• Ennetav hooldus – Vibratsiooni- ja heliandurid koguvad andmeid tuuleturbiini käigukastist. Anomaaliate tuvastamise mudel töötleb anduri andmeid ja tuvastab, kui seadmega on kõrvalekaldeid. Kui avastatakse kõrvalekalle, saab servaseade alustada reaalajas ettenägematute mõõtmistega, et vältida seadmete kahjustamist, näiteks lülitada sisse pausid või ühendada generaator võrgust lahti.
• Defektide tuvastamine tootmisliinidel – Kaamera jäädvustab toodetest pilte konveierilindile ja töötleb kaadreid kujutiste klassifitseerimismudeliga. Defekti tuvastamisel saab toote automaatselt ära visata ilma käsitsi sekkumiseta.

Kuigi ML@Edge suudab lahendada paljusid kasutusjuhtumeid, tuleb turvalise, vastupidava ja usaldusväärse disaini saavutamiseks lahendada keerukaid arhitektuurilisi väljakutseid. Sellest postitusest saate teada mõned üksikasjad ML@Edge'i, sellega seotud teemade ja AWS-i teenuste kasutamise kohta nendest väljakutsetest ülesaamiseks ja oma ML-i jaoks tervikliku lahenduse juurutamiseks kõige suurema töökoormuse juures.

ML@Edge ülevaade

ML@Edge'i ja asjade Interneti (IoT) puhul on levinud segadus, mistõttu on oluline selgitada, mille poolest ML@Edge IoT-st erineb ja kuidas need mõlemad võiksid teatud juhtudel pakkuda võimsat lahendust.

ML@Edge'i kasutaval servalahendusel on kaks põhikomponenti: servarakendus ja servaseadmes töötav ML-mudel (rakenduse poolt välja kutsutud). ML@Edge eesmärk on juhtida ühe või mitme ML-mudeli elutsüklit, mis on kasutusele võetud ääreseadmete pargis. ML-mudeli elutsükkel võib alata pilve poolelt (sisse Amazon SageMakernäiteks), kuid tavaliselt lõpeb see mudeli eraldiseisva juurutamisega servaseadmes. Iga stsenaarium nõuab erinevaid ML-mudeli elutsükleid, mida saab koostada mitmest etapist, näiteks andmete kogumine; andmete ettevalmistamine; mudeli koostamine, koostamine ja juurutamine ääreseadmesse; mudeli laadimine ja töötamine; ja elutsükli kordamine.

ML@Edge mehhanism ei vastuta rakenduse elutsükli eest. Selleks tuleks kasutada teistsugust lähenemist. ML-mudeli elutsükli ja rakenduse elutsükli lahtisidumine annab teile vabaduse ja paindlikkuse, et neid erinevas tempos edasi arendada. Kujutage ette mobiilirakendust, mis manustab ML-mudeli ressursina, näiteks pildi või XML-failina. Sellisel juhul peate iga kord, kui koolitate uut mudelit ja soovite seda mobiiltelefonides juurutada, kogu rakenduse ümber paigutama. See kulutab aega ja raha ning võib teie rakendusse tuua vigu. ML-mudeli elutsükli lahtisidumisel avaldate mobiilirakenduse ühe korra ja juurutate nii palju ML-mudeli versioone, kui vajate.

Aga kuidas on asjade internet korrelatsioonis ML@Edge'iga? IoT on seotud füüsiliste objektidega, mis on manustatud selliste tehnoloogiatega nagu andurid, töötlemisvõime ja tarkvara. Need objektid on andmete vahetamiseks ühendatud teiste seadmete ja süsteemidega Interneti või muude sidevõrkude kaudu. Järgmine joonis illustreerib seda arhitektuuri. Mõiste loodi algselt, kui mõelda lihtsatele seadmetele, mis lihtsalt koguvad andmeid servast, teostavad lihtsat kohalikku töötlemist ja saadavad tulemuse võimsamasse andmetöötlusüksusesse, mis juhib analüütilisi protsesse, mis aitavad inimesi ja ettevõtteid nende otsuste tegemisel. IoT lahendus vastutab servarakenduse elutsükli juhtimise eest. IoT kohta lisateabe saamiseks vaadake Asjade Internet.

Kui teil on juba IoT rakendus, saate toote tõhusamaks muutmiseks lisada ML@Edge'i võimalusi, nagu on näidatud järgmisel joonisel. Pidage meeles, et ML@Edge ei sõltu asjade Internetist, kuid saate neid kombineerida, et luua võimsam lahendus. Kui teete seda, parandate oma lihtsa seadme potentsiaali luua oma ettevõtte jaoks reaalajas teavet kiiremini kui lihtsalt andmete saatmiseks pilve hilisemaks töötlemiseks.

Kui loote uue servalahenduse nullist ML@Edge'i võimalustega, on oluline kujundada paindlik arhitektuur, mis toetab nii rakenduse kui ka ML-mudeli elutsükleid. Pakume hiljem selles postituses mõningaid viitearhitektuure ML@Edge'i servarakenduste jaoks. Kuid esmalt sukeldume sügavamale servaarvutusse ja õpime, kuidas valida oma lahendusele õige servaseade, lähtudes keskkonnapiirangutest.

Servade arvutamine

Olenevalt sellest, kui kaugel seade pilvest või suurest andmekeskusest (baasist) asub, tuleb süsteemi jõudluse ja pikaealisuse maksimeerimiseks arvesse võtta ääreseadmete kolme peamist omadust: andmetöötlus- ja salvestusmaht, ühenduvus ja energiatarve. Järgmisel diagrammil on näidatud kolm servaseadmete rühma, mis ühendavad nende omaduste erinevad spetsifikatsioonid, olenevalt sellest, kui kaugel need alusest asuvad.

Rühmad on järgmised:

• MEC-id (mitme juurdepääsuga servaarvutus) – MEC-id või väikesed andmekeskused, mida iseloomustab madal või ülimadal latentsusaeg ja suur ribalaius, on tavalised keskkonnad, kus ML@Edge võib pilve töökoormusega võrreldes kasu tuua ilma suurte piiranguteta. 5G antennid ja serverid tehastes, ladudes, laborites jne minimaalsete energiapiirangutega ja hea Interneti-ühendusega pakuvad erinevaid viise ML-mudelite käitamiseks GPU-des ja CPU-des, virtuaalmasinates, konteinerites ja metallist serverites.
• Serva lähedal – See on siis, kui mobiilsus või andmete koondamine on nõuded ja seadmetel on teatud piirangud energiatarbimise ja töötlemisvõimsuse osas, kuid neil on siiski usaldusväärne ühenduvus, kuigi suurema latentsusajaga, piiratud läbilaskevõimega ja kallim kui "serva lähedal". Sellesse rühma kuuluvad mobiilirakendused, spetsiaalsed plaadid ML-mudelite kiirendamiseks või lihtsad seadmed, mis on võimelised töötama ML-mudeleid ja mis on kaetud traadita võrguga.
• Kauge serv – Selle äärmusliku stsenaariumi korral on servaseadmetel tõsised energiatarbimise või ühenduvuspiirangud. Sellest tulenevalt on töötlemisvõimsus ka paljude kaugemate stsenaariumide korral piiratud. Põllumajandus, kaevandamine, järelevalve ja julgeolek ning meretransport on mõned valdkonnad, kus kaugemal asuvad seadmed mängivad olulist rolli. Levinud on lihtsad plaadid, tavaliselt ilma GPU-de või muude AI-kiirenditeta. Need on mõeldud lihtsate ML-mudelite laadimiseks ja käitamiseks, ennustuste salvestamiseks kohalikku andmebaasi ja magama jäämiseks kuni järgmise ennustustsüklini. Seadmetel, mis peavad töötlema reaalajas andmeid, võivad andmete kadumise vältimiseks olla suured kohalikud salvestusruumid.

Väljakutsed

Tavalised on ML@Edge stsenaariumid, kus teil on sadu või tuhandeid (võib-olla isegi miljoneid) seadmeid, mis käitavad samu mudeleid ja servarakendusi. Süsteemi skaleerimisel on oluline omada tugevat lahendust, mis suudab hallata toetatavate seadmete arvu. See on keeruline ülesanne ja nende stsenaariumide puhul peate esitama palju küsimusi.

• Kuidas kasutada ML-mudeleid äärealadel asuvates seadmetes?
• Kuidas luua, optimeerida ja juurutada ML-mudeleid mitmes servaseadmes?
• Kuidas kaitsta oma mudelit selle servas juurutamise ja käitamise ajal?
• Kuidas jälgida oma mudeli jõudlust ja vajadusel seda ümber õpetada?
• Kuidas kõrvaldada vajadus oma piiratud seadmesse installida suur raamistik, nagu TensorFlow või PyTorch?
• Kuidas kuvada üks või mitu mudelit oma servarakendusega lihtsa API-na?
• Kuidas luua uut andmestikku servaseadmete jäädvustatud kasulike koormuste ja ennustustega?
• Kuidas teha kõiki neid ülesandeid automaatselt (MLOps pluss ML@Edge)?

Järgmises jaotises anname kõigile neile küsimustele vastused näidiskasutusjuhtumite ja viitearhitektuuride kaudu. Samuti arutame, milliseid AWS-teenuseid saate kombineerida, et luua iga uuritud stsenaariumi jaoks terviklikke lahendusi. Kui soovite aga alustada väga lihtsast voost, mis kirjeldab, kuidas kasutada mõnda AWS-i pakutavat teenust oma ML@Edge lahenduse loomiseks, on see näide:

SageMakeriga saate hõlpsalt ette valmistada andmestiku ja luua ML-mudeleid, mis juurutatakse ääreseadmetesse. Koos Amazon SageMaker Neo, saate treenitud mudeli koostada ja optimeerida konkreetsele valitud servaseadmele. Pärast mudeli koostamist vajate selle käitamiseks vaid kerget tööaega (teenuse pakub). Amazon SageMaker Edge Manager vastutab kõigi teie servaseadmete pargis kasutusele võetud ML-mudelite elutsükli haldamise eest. Edge Manager saab hallata kuni miljoneid seadmeid. Igasse servaseadmesse installitud agent paljastab juurutatud ML-mudelid rakendusele API-na. Agent vastutab ka mõõdikute, kasulike koormuste ja prognooside kogumise eest, mida saate kasutada jälgimiseks või uue andmestiku koostamiseks, et vajadusel mudelit ümber õpetada. Lõpuks koos Amazon SageMakeri torujuhtmed, saate luua automatiseeritud konveieri kõigi toimingutega, mis on vajalikud ML-mudelite loomiseks, optimeerimiseks ja oma seadmepargis juurutamiseks. Selle automatiseeritud konveieri saab seejärel käivitada teie määratletud lihtsate sündmustega ilma inimese sekkumiseta.

Kasutusjuhtum 1

Oletame, et lennukitootja soovib tootmisangaaris tuvastada ja jälgida osi ja tööriistu. Tootlikkuse parandamiseks peavad kõik vajalikud osad ja õiged tööriistad olema igas tootmisetapis inseneride käsutuses. Soovime vastata järgmistele küsimustele: Kus on osa A? või Kus on tööriist B? Meil on mitu IP-kaamerat juba installitud ja ühendatud kohalikku võrku. Kaamerad katavad kogu angaari ja saavad reaalajas HD-videot võrgu kaudu striimida.

AWS Panoraam sobib sel juhul kenasti. AWS Panorama pakub ML-seadet ja hallatavat teenust, mis võimaldab teil lisada arvutinägemise (CV) oma olemasolevasse IP-kaameraparki ja automatiseerida. AWS Panorama annab teile võimaluse lisada CV-d oma olemasolevatele Interneti-protokolli (IP) kaameratele ja automatiseerida ülesandeid, mis tavaliselt nõuavad inimese kontrolli ja jälgimist.

Järgmises võrdlusarhitektuuris näitame AWS Panorama Appliance'is töötava rakenduse peamisi komponente. Rakenduse Panorama SDK abil on lihtne kaameravoogudest video jäädvustada, mitme ML-mudeli konveieri abil järeldusi teha ja tulemusi konteineris töötava Pythoni koodi abil töödelda. Saate käitada mudeleid mis tahes populaarsest ML-teegist, näiteks TensorFlow, PyTorch või TensorRT. Mudeli tulemusi saab integreerida oma kohtvõrgu ärisüsteemidega, mis võimaldab sündmustele reaalajas reageerida.

Lahendus koosneb järgmistest sammudest:

1. Ühendage ja konfigureerige AWS Panorama seade samasse kohalikku võrku.
2. Treenige ML-mudelit (objekti tuvastamine), et tuvastada igas kaadris olevad osad ja tööriistad.
3. Looge AWS-i panoraamrakendus, mis hangib ML-mudeli ennustused, rakendab igale objektile jälgimismehhanismi ja saadab tulemused reaalajas andmebaasi.
4. Operaatorid saavad osade ja tööriistade leidmiseks andmebaasi päringuid saata.

Kasutusjuhtum 2

Järgmiseks kasutusjuhtumiks kujutage ette, et loome sõidukitele armatuurkaamera, mis suudab juhti paljudes olukordades toetada, näiteks jalakäijaid vältides. CV25 plaat firmalt Ambaralla. ML-mudelite hostimine piiratud süsteemiressurssidega seadmes võib olla keeruline. Sel juhul oletame, et meil on juba väljakujunenud õhu kaudu edastamise mehhanism (OTA) vajalike rakenduse komponentide juurutamiseks ääreseadmesse. Siiski tuleks meile siiski kasu mudeli enda OTA juurutamise võimalusest, eraldades seeläbi rakenduse elutsükli ja mudeli elutsükli.

Amazon SageMaker Edge Manager ja Amazon SageMaker Neo sobib hästi selle kasutusjuhtumi jaoks.

Edge Manager teeb ML edge'i arendajatele lihtsaks samade tuttavate tööriistade kasutamise pilves või servaseadmetes. See vähendab mudelite tootmisse jõudmiseks kuluvat aega ja vaeva, võimaldades samal ajal pidevalt jälgida ja parandada mudeli kvaliteeti kogu oma seadmepargis. SageMaker Edge sisaldab OTA juurutusmehhanismi, mis aitab teil mudelid pargis juurutada, sõltumata rakendusest või seadme püsivarast. The Edge Manageri agent võimaldab ühes seadmes käitada mitut mudelit. Agent kogub teie juhitaval loogikal põhinevaid ennustusandmeid (nt intervallid) ja laadib need pilve üles, et saaksite oma mudeleid aja jooksul perioodiliselt ümber õpetada. SageMaker Edge allkirjastab teie mudelid krüptograafiliselt, et saaksite kontrollida, kas seda pilvest servaseadmesse liikudes ei muudetud.

Neo on teenusena kompilaator ja sobib sellesse kasutusjuhtu eriti hästi. Neo optimeerib automaatselt ML-mudeleid, et teha järeldusi pilve eksemplaridel ja servaseadmetel, et need töötaksid kiiremini ilma täpsuse vähenemiseta. Alustate ML-mudeliga, mis on ehitatud ühega toetatud raamistikud ja koolitatud SageMakeris või mujal. Seejärel valite oma sihtriistvaraplatvormi (vt loendit toetatud seadmed). Ühe klõpsuga optimeerib Neo treenitud mudeli ja koostab selle paketiks, mida saab käitada kerge SageMaker Edge käitusajaga. Kompilaator kasutab ML-mudelit, et rakendada jõudluse optimeerimisi, mis ekstraheerivad teie mudeli jaoks parima saadaoleva jõudluse pilveeksemplaris või servaseadmes. Seejärel juurutate mudeli SageMakeri lõpp-punktina või toetatud servaseadmetes ja hakkate ennustama.

Järgmine diagramm illustreerib seda arhitektuuri.

Lahenduse töövoog koosneb järgmistest sammudest.

1. Arendaja koostab, koolitab, kinnitab ja loob lõpliku mudeliartefakti, mis tuleb armatuurkaamerasse juurutada.
2. Treenitud mudeli koostamiseks kutsuge välja Neo.
3. Agent SageMaker Edge on installitud ja konfigureeritud Edge'i seadmesse, antud juhul armatuurkaamerasse.
4. Looge juurutuspakett allkirjastatud mudeli ja käitusajaga, mida SageMaker Edge agent kasutab optimeeritud mudeli laadimiseks ja käivitamiseks.
5. Juurutage pakett olemasoleva OTA juurutusmehhanismi abil.
6. Servarakendus suhtleb järelduste tegemiseks SageMaker Edge agendiga.
7. Agenti saab konfigureerida (vajadusel) saatma rakendusest mudeli jälgimise ja täiustamise eesmärgil reaalajas näidissisendandmeid.

Kasutusjuhtum 3

Oletame, et teie klient töötab välja rakendust, mis tuvastab tuuleturbiini mehhanismide (nt käigukasti, generaatori või rootori) kõrvalekalded. Eesmärk on minimeerida seadmete kahjustusi, käivitades lennult kohalikke kaitseprotseduure. Need turbiinid on väga kallid ja asuvad kohtades, kuhu pole kergesti ligipääsetav. Iga turbiini saab varustada NVIDIA Jetsoni seadmega, et jälgida turbiini anduri andmeid. Seejärel vajame lahendust andmete kogumiseks ja ML-algoritmi abil kõrvalekallete tuvastamiseks. Vajame ka OTA-mehhanismi, et hoida seadmes oleva tarkvara ja ML-mudelid ajakohasena.

AWS IoT Greengrass V2 koos Edge Manageriga sobivad sellisel juhul hästi. AWS IoT Greengrass on avatud lähtekoodiga asjade Interneti serva käitus- ja pilveteenus, mis aitab teil oma seadmetes asjade Interneti-rakendusi luua, juurutada ja hallata. AWS IoT Greengrassi abil saate luua servarakendusi, kasutades eelehitatud tarkvaramooduleid, nn komponendid, mis suudab ühendada teie servaseadmed AWS-i teenuste või kolmandate osapoolte teenustega. See AWS IoT Greengrassi võimalus muudab varade, sealhulgas SageMaker Edge'i agendi, hõlpsa juurutamise seadmetesse. AWS IoT Greengrass vastutab rakenduse elutsükli haldamise eest, Edge Manager aga seob lahti ML-mudeli elutsükli. See annab teile paindlikkuse kogu lahenduse edasiarendamiseks, juurutades iseseisvalt uusi servarakenduse ja ML-mudelite versioone. Järgmine diagramm illustreerib seda arhitektuuri.

Lahendus koosneb järgmistest sammudest:

1. Arendaja ehitab, koolitab, kinnitab ja loob lõpliku mudeliartefakti, mis tuleb tuuleturbiinile kasutusele võtta.
2. Treenitud mudeli koostamiseks kutsuge välja Neo.
3. Looge mudelikomponent Edge Manageri abil koos AWS IoT Greengrass V2 integratsiooniga.
4. Seadistage AWS IoT Greengrass V2.
5. Looge järelduskomponent, kasutades AWS IoT Greengrass V2.
6. Servarakendus suhtleb järelduste tegemiseks SageMaker Edge agendiga.
7. Agenti saab konfigureerida (vajadusel) saatma rakendusest mudeli jälgimise ja täiustamise eesmärgil reaalajas näidissisendandmeid.

Kasutusjuhtum 4

Meie lõppkasutuse puhul vaatame konteinereid vedavat laeva, kus igal konteineril on paar andurit ja see edastab signaali lokaalselt kasutusele võetud arvutus- ja salvestusinfrastruktuurile. Väljakutse seisneb selles, et tahame teada iga konteineri sisu ja kauba seisukorda temperatuuri, niiskuse ja iga konteineri sees olevate gaaside põhjal. Samuti tahame jälgida kõiki kaupu igas konteineris. Kogu reisi jooksul puudub Interneti-ühendus ja reis võib kesta kuid. Selles infrastruktuuris töötavad ML-mudelid peaksid andmeid eeltöötlema ja looma teavet, et vastata kõigile meie küsimustele. Loodud andmeid tuleb hoida lokaalselt mitu kuud. Servarakendus salvestab kõik järeldused kohalikku andmebaasi ja sünkroonib seejärel tulemused pilvega, kui laev sadamale läheneb.

AWS lumekoon ja AWS lumepall alates AWS Snow Family võiks sellisel juhul väga hästi sobida.

AWS Snowcone on väike, vastupidav ja turvaline andmetöötlus- ja andmete migratsiooniseade. Snowcone on loodud OSHA standardi järgi ühele inimesele tõstetava seadme jaoks. Snowcone võimaldab teil kasutada servade töökoormust Amazon Elastic Compute Cloud (Amazon EC2) andmetöötlus ja kohalik salvestuskoht karmides, lahtiühendatud välikeskkondades, nagu naftapuurtornid, otsingu- ja päästesõidukid, sõjaväeobjektid või tehase põrandad, aga ka kaugkontorid, haiglad ja kinod.

Snowball lisab Snowcone'iga võrreldes rohkem andmetöötlust ja võib seetõttu sobida suurepäraselt ka nõudlikumate rakenduste jaoks. Funktsioon Compute Optimized pakub valikulist NVIDIA Tesla V100 GPU-d koos EC2 eksemplaridega, et kiirendada rakenduse jõudlust lahtiühendatud keskkondades. GPU valikuga saate käivitada selliseid rakendusi nagu täiustatud ML ja täielik liikumisvideo analüüs keskkondades, kus ühenduvus on väike või puudub üldse.

Lisaks EC2 eksemplarile on teil vabadus ehitada ja juurutada mis tahes tüüpi servalahendusi. Näiteks: saate kasutada Amazon ECS või muu konteinerihaldur, et juurutada servarakendus, Edge Manager Agent ja ML-mudel üksikute konteineritena. See arhitektuur oleks sarnane 2. kasutusjuhtumiga (välja arvatud see, et see töötab suurema osa ajast võrguühenduseta), millele on lisatud konteinerihalduri tööriist.

Selle lahenduse arhitektuuri illustreerib järgmine diagramm.

Selle lahenduse rakendamiseks tellige lihtsalt oma Snow seade aadressilt AWS-i juhtimiskonsool ja käivitage oma ressursid.

Järeldus

Selles postituses arutasime serva erinevaid aspekte, millega saate oma kasutusjuhtumi põhjal töötada. Arutasime ka mõningaid ML@Edge'i põhikontseptsioone ja seda, kuidas rakenduse elutsükli ja ML-mudeli elutsükli lahtisidumine annab teile vabaduse neid arendada ilma üksteisest sõltumata. Rõhutasime, kuidas oma töökoormuse jaoks õige servaseadme valimine ja õigete küsimuste esitamine lahendusprotsessi ajal aitab teil tagasi töötada ja õigeid AWS-teenuseid kitsendada. Samuti tutvustasime erinevaid kasutusjuhtumeid koos võrdlusarhitektuuridega, et inspireerida teid looma oma lahendusi, mis teie töökoormuse jaoks sobivad.

---

Autoritest

Dinesh Kumar Subramani on UKIR SMB meeskonna vanemlahenduste arhitekt, mis asub Šotimaal Edinburghis. Ta on spetsialiseerunud tehisintellektile ja masinõppele. Dineshile meeldib töötada klientidega erinevates tööstusharudes, et aidata neil AWS-i teenustega seotud probleeme lahendada. Väljaspool tööd meeldib talle perega aega veeta, malet mängida ja erinevate žanrite muusikat nautida.

Samir Araújo on AWS-i AI/ML-lahenduste arhitekt. Ta aitab klientidel luua AI/ML-lahendusi, mis lahendavad AWS-i abil nende äriprobleeme. Ta on töötanud mitme AI/ML projekti kallal, mis on seotud arvutinägemise, loomuliku keele töötlemise, prognoosimise, ML ääres ja muuga. Talle meeldib vabal ajal mängida riistvara- ja automaatikaprojektidega ning ta tunneb erilist huvi robootika vastu.

• Münditark. Euroopa parim Bitcoini ja krüptobörs.
• Platoblockchain. Web3 metaversiooni intelligentsus. Täiustatud teadmised. TASUTA PÄÄS.
• CryptoHawk. Altcoini radar. Tasuta prooviversioon.
• Allikas: https://aws.amazon.com/blogs/machine-learning/demystifying-machine-learning-at-the-edge-through-real-use-cases/