A gépi tanulás rejtélyeinek tisztázása a széleken valós használati eseteken keresztül

él egy olyan kifejezés, amely egy olyan helyre utal, távol a felhőtől vagy egy nagy adatközponttól, ahol olyan számítógépes eszközzel (éleszközzel) rendelkezik, amely képes (edge) alkalmazások futtatására. Az élszámítás a munkaterhelések futtatása ezeken az éleszközökön. A gépi tanulás a széleken (ML@Edge) egy olyan koncepció, amely az ML-modellek helyi futtatásának képességét biztosítja az éleszközökön. Ezeket az ML modelleket ezután az élalkalmazás hívhatja meg. Az ML@Edge számos forgatókönyvnél fontos, ahol a nyers adatokat a felhőtől távol eső forrásokból gyűjtik. Ezek a forgatókönyvek speciális követelményekkel vagy korlátozásokkal is rendelkezhetnek:

• Alacsony késleltetésű, valós idejű előrejelzések
• Gyenge vagy nem létező kapcsolat a felhővel
• Jogi korlátozások, amelyek nem teszik lehetővé az adatok küldését külső szolgáltatásoknak
• Nagy adatkészletek, amelyeket helyileg elő kell feldolgozni, mielőtt válaszokat küldenének a felhőbe

Az alábbiakban felsorolunk néhány olyan felhasználási esetet, amelyek hasznosak lehetnek, ha az ML modellek az előrejelzésekhez használt adatokat előállító berendezések közelében futnak:

• Biztonság és védelem – A korlátozott területet, ahol nehézgépek dolgoznak egy automatizált kikötőben, kamera figyeli. Ha valaki tévedésből belép erre a területre, működésbe lép egy biztonsági mechanizmus, amely leállítja a gépeket és megvédi az embert.
• Előre látható karbantartás – A rezgés- és hangérzékelők adatokat gyűjtenek egy szélturbina sebességváltójából. Az anomália-észlelési modell feldolgozza az érzékelő adatait, és azonosítja, ha a berendezés rendellenességei vannak. Ha anomáliát észlel, az éleszköz valós időben indíthat készenléti mérést, hogy elkerülje a berendezés károsodását, például lekapcsolja a megszakításokat vagy leválasztja a generátort a hálózatról.
• Hibafelismerés a gyártósorokon – Egy kamera rögzíti a képeket a szállítószalagon lévő termékekről, és képosztályozási modellel dolgozza fel a képkockákat. Hiba észlelése esetén a termék kézi beavatkozás nélkül automatikusan kidobható.

Bár az ML@Edge számos felhasználási esetre képes, vannak összetett építészeti kihívások, amelyeket meg kell oldani a biztonságos, robusztus és megbízható tervezés érdekében. Ebből a bejegyzésből megtudhat néhány részletet az ML@Edge-ről, a kapcsolódó témákról, valamint arról, hogyan használhatja az AWS-szolgáltatásokat e kihívások leküzdésére, és teljes körű megoldást valósíthat meg az ML-hez a legszélsőségesebb munkaterhelés mellett.

Az ML@Edge áttekintése

Az ML@Edge és az Internet of Things (IoT) kapcsán gyakori a tévedés, ezért fontos tisztázni, hogy az ML@Edge miben különbözik az IoT-től, és hogy a kettő együtt hogyan nyújthat hatékony megoldást bizonyos esetekben.

Az ML@Edge-t használó élmegoldásnak két fő összetevője van: egy élalkalmazás és egy (az alkalmazás által meghívott) ML-modell, amely az éleszközön fut. Az ML@Edge egy vagy több ML-modell életciklusának vezérléséről szól, amelyek egy szélső eszközparkon vannak telepítve. Az ML modell életciklusa kezdődhet a felhő oldalon (on Amazon SageMakerpéldául), de általában a modell peremeszközön történő önálló telepítésével végződik. Minden forgatókönyv különböző ML modell életciklusokat igényel, amelyek több szakaszból is összeállíthatók, például adatgyűjtés; adatok előkészítése; modell építése, összeállítása és telepítése a szélső eszközre; modell betöltése és futtatása; és az életciklus megismétlése.

Az ML@Edge mechanizmus nem felelős az alkalmazás életciklusáért. E célból más megközelítést kell alkalmazni. Az ML modell életciklusának és az alkalmazás életciklusának szétválasztása szabadságot és rugalmasságot biztosít Önnek, hogy különböző ütemben fejleszthesse azokat. Képzeljen el egy mobilalkalmazást, amely egy ML-modellt erőforrásként, például képként vagy XML-fájlként ágyaz be. Ebben az esetben minden alkalommal, amikor egy új modellt betanít, és azt a mobiltelefonokra kívánja telepíteni, újra kell telepítenie az egész alkalmazást. Ez időt és pénzt emészt fel, és hibákat okozhat az alkalmazásban. Az ML-modell életciklusának szétválasztásával egyszer közzéteszi a mobilalkalmazást, és az ML-modell annyi verzióját telepíti, amennyire szüksége van.

De hogyan kapcsolódik az IoT az ML@Edge-hez? Az IoT olyan fizikai objektumokhoz kapcsolódik, amelyek olyan technológiákkal vannak beágyazva, mint az érzékelők, a feldolgozási képesség és a szoftver. Ezek az objektumok az interneten vagy más kommunikációs hálózatokon keresztül csatlakoznak más eszközökhöz és rendszerekhez adatcsere céljából. A következő ábra ezt az architektúrát szemlélteti. A koncepció eredetileg olyan egyszerű eszközökre gondolt, amelyek csak adatokat gyűjtenek a szélről, egyszerű helyi feldolgozást hajtanak végre, és az eredményt egy erősebb számítási egységhez küldik, amely olyan elemző folyamatokat futtat, amelyek segítenek az embereknek és a vállalatoknak a döntéshozatalban. Az IoT-megoldás felelős az élalkalmazások életciklusának vezérléséért. Az IoT-vel kapcsolatos további információkért lásd: A tárgyak internete.

Ha már rendelkezik IoT-alkalmazással, ML@Edge-képességeket adhat hozzá a termék hatékonyabbá tételéhez, ahogy az a következő ábrán látható. Ne feledje, hogy az ML@Edge nem függ az IoT-től, de kombinálhatja őket egy hatékonyabb megoldás létrehozásához. Ezzel javítja az egyszerű eszközben rejlő lehetőségeket, hogy valós idejű betekintést nyújtson vállalkozása számára, mint hogy adatokat küldjön a felhőbe későbbi feldolgozás céljából.

Ha új élmegoldást hoz létre a semmiből az ML@Edge képességekkel, fontos, hogy olyan rugalmas architektúrát tervezzen, amely támogatja mind az alkalmazás, mind az ML modell életciklusát. Ebben a bejegyzésben néhány referenciaarchitektúrát biztosítunk az ML@Edge élalkalmazásokhoz. De először merüljünk el mélyebben az élszámítástechnikában, és tanuljuk meg, hogyan válasszuk ki a megfelelő éleszközt a megoldáshoz a környezet korlátai alapján.

Szélszámítás

Attól függően, hogy milyen messze van az eszköz a felhőtől vagy egy nagy adatközponttól (bázis), a peremeszközök három fő jellemzőjét kell figyelembe venni a rendszer teljesítményének és élettartamának maximalizálása érdekében: a számítási és tárolási kapacitást, a csatlakoztathatóságot és az energiafogyasztást. A következő diagram az éleszközök három csoportját mutatja, amelyek ezeknek a jellemzőknek a különböző specifikációit kombinálják, attól függően, hogy milyen messze vannak az alaptól.

A csoportok a következők:

• MEC-k (Multi-access Edge Computing) – Az alacsony vagy ultraalacsony késleltetéssel és nagy sávszélességgel jellemezhető MEC-k vagy kis adatközpontok olyan gyakori környezetek, ahol az ML@Edge nagy korlátozások nélkül hozhat előnyöket a felhőalapú munkaterheléshez képest. Az 5G antennák és szerverek gyárakban, raktárakban, laboratóriumokban és így tovább minimális energiakorlátozás mellett és jó internetkapcsolattal különböző módokat kínálnak az ML modellek GPU-kon és CPU-kon, virtuális gépeken, konténereken és csupasz fém szervereken való futtatására.
• Közel szél – Ilyenkor a mobilitás vagy az adataggregáció követelmény, és az eszközöknek vannak bizonyos korlátai az energiafogyasztást és a feldolgozási teljesítményt illetően, de még mindig rendelkeznek megbízható kapcsolattal, bár nagyobb késleltetéssel, korlátozott áteresztőképességgel és drágábban, mint a „szélhez közel”. Ebbe a csoportba tartoznak a mobilalkalmazások, az ML-modellek felgyorsítására szolgáló speciális kártyák vagy az ML-modellek futtatására alkalmas, vezeték nélküli hálózatokkal lefedett egyszerű eszközök.
• Távoli széle – Ebben a szélsőséges forgatókönyvben a szélső eszközöknek komoly energiafogyasztási vagy kapcsolódási korlátai vannak. Következésképpen a feldolgozási teljesítmény is korlátozott sok távoli forgatókönyvben. A mezőgazdaság, a bányászat, a felügyelet és a biztonság, valamint a tengeri szállítás néhány olyan terület, ahol a távoli eszközök fontos szerepet játszanak. Gyakoriak az egyszerű táblák, amelyek általában nem tartalmaznak GPU-t vagy más AI-gyorsítókat. Úgy tervezték, hogy betöltsék és futtassák az egyszerű ML-modelleket, elmentsék az előrejelzéseket egy helyi adatbázisba, és aludjanak a következő előrejelzési ciklusig. Azok az eszközök, amelyeknek valós idejű adatokat kell feldolgozniuk, nagy helyi tárolókkal rendelkezhetnek az adatvesztés elkerülése érdekében.

Kihívások

Gyakoriak az ML@Edge forgatókönyvek, ahol több száz vagy több ezer (esetleg több millió) eszköz fut ugyanazon modelleken és élalkalmazásokon. A rendszer méretezésekor fontos, hogy legyen egy robusztus megoldás, amely képes kezelni a támogatandó eszközök számát. Ez egy összetett feladat, és ezekhez a forgatókönyvekhez sok kérdést kell feltennie:

• Hogyan működtethetek ML-modelleket egy szélső eszközparkon?
• Hogyan építhetek, optimalizálhatok és telepíthetek ML-modelleket több szélső eszközre?
• Hogyan biztosíthatom a modellemet, miközben telepítem és a széleken futtatom?
• Hogyan tudom nyomon követni a modellem teljesítményét, és szükség esetén áttanítani?
• Hogyan küszöbölhetem ki egy nagy keretrendszer, például a TensorFlow vagy a PyTorch telepítését a korlátozott eszközömre?
• Hogyan tehetek közzé egy vagy több modellt az élalkalmazásommal egyszerű API-ként?
• Hogyan hozhatok létre új adatkészletet az éleszközök által rögzített hasznos terhekkel és előrejelzésekkel?
• Hogyan végezhetem el ezeket a feladatokat automatikusan (MLOps plusz ML@Edge)?

A következő részben ezekre a kérdésekre adunk választ a használati eseteken és referenciaarchitektúrákon keresztül. Azt is megbeszéljük, hogy mely AWS-szolgáltatásokat kombinálhatja komplett megoldások létrehozásához az egyes feltárt forgatókönyvekhez. Ha azonban egy nagyon egyszerű folyamattal szeretne kezdeni, amely leírja, hogyan használhatja az AWS által nyújtott szolgáltatásokat az ML@Edge megoldás létrehozásához, akkor ez egy példa:

A SageMaker segítségével könnyen készíthet adatkészletet, és elkészítheti a szélső eszközökön telepített ML-modelleket. Val vel Amazon SageMaker Neo, összeállíthatja és optimalizálhatja a betanított modellt a kiválasztott éleszközhöz. A modell összeállítása után csak egy kis futási időre van szükség a futtatásához (a szolgáltatás által biztosított). Amazon SageMaker Edge Manager felelős a szélső eszközparkjában telepített összes ML modell életciklusának kezeléséért. Az Edge Manager akár több millió eszközből álló flottát is képes kezelni. Az egyes szélső eszközökre telepített ügynök API-ként teszi közzé a telepített ML modelleket az alkalmazás számára. Az ügynök felelős a metrikák, hasznos adatok és előrejelzések összegyűjtéséért is, amelyeket felhasználhat a megfigyeléshez vagy egy új adatkészlet felépítéséhez, hogy szükség esetén újratanítsa a modellt. Végül azzal Amazon SageMaker csővezetékek, létrehozhat egy automatizált folyamatot, amely tartalmazza az összes szükséges lépést az ML-modellek felépítéséhez, optimalizálásához és eszközparkjában történő telepítéséhez. Ezt az automatizált folyamatot az Ön által meghatározott egyszerű események emberi beavatkozás nélkül indíthatják el.

1. használati eset

Tegyük fel, hogy egy repülőgépgyártó szeretné észlelni és nyomon követni az alkatrészeket és szerszámokat a gyártó hangárban. A termelékenység javítása érdekében az összes szükséges alkatrésznek és megfelelő szerszámnak rendelkezésre kell állnia a mérnökök számára a gyártás minden szakaszában. Olyan kérdésekre szeretnénk választ adni, mint: Hol van az A rész? vagy Hol van a B szerszám? Több IP-kameránk van már telepítve, és csatlakozik a helyi hálózathoz. A kamerák a teljes hangárt lefedik, és valós idejű HD videót tudnak közvetíteni a hálózaton keresztül.

AWS Panoráma ebben az esetben jól illeszkedik. Az AWS Panorama egy ML készüléket és felügyelt szolgáltatást biztosít, amely lehetővé teszi, hogy számítógépes látásmódot (CV) adjon hozzá meglévő IP-kameráihoz, és automatizálja. Az AWS Panorama lehetővé teszi, hogy önéletrajzot adjon meglévő Internet Protocol (IP) kameráihoz, és automatizálja azokat a feladatokat, amelyek hagyományosan emberi ellenőrzést és megfigyelést igényelnek.

A következő referencia-architektúrában az AWS Panorama Appliance-en futó alkalmazás főbb összetevőit mutatjuk be. A Panorama Application SDK segítségével egyszerűen rögzíthet videót kamerafolyamokból, következtetéseket vonhat le több ML-modellből, és feldolgozhatja az eredményeket egy tárolóban futó Python-kóddal. Bármely népszerű ML-könyvtárból, például TensorFlow, PyTorch vagy TensorRT modelleket futtathat. A modell eredményei integrálhatók a helyi hálózaton lévő üzleti rendszerekkel, így valós időben reagálhat az eseményekre.

A megoldás a következő lépésekből áll:

1. Csatlakoztasson és konfiguráljon AWS Panorama eszközt ugyanahhoz a helyi hálózathoz.
2. Tanítson meg egy ML-modellt (objektumészlelés), hogy azonosítsa az egyes keretekben lévő alkatrészeket és eszközöket.
3. Hozzon létre egy AWS Panorama alkalmazást, amely megkapja az ML-modellből származó előrejelzéseket, nyomkövetési mechanizmust alkalmaz minden objektumra, és elküldi az eredményeket egy valós idejű adatbázisba.
4. Az operátorok lekérdezéseket küldhetnek az adatbázisba az alkatrészek és eszközök megkeresésére.

2. használati eset

Következő felhasználási esetünkhöz képzeljük el, hogy egy műszerkamerát hozunk létre olyan járművek számára, amelyek számos helyzetben támogatni tudják a vezetőt, például elkerülve a gyalogosokat. CV25 tábla az Ambaralla-tól. Az ML modellek tárolása korlátozott rendszererőforrásokkal rendelkező eszközökön nehéz lehet. Ebben az esetben tegyük fel, hogy már rendelkezünk egy jól bevált OTA (over-the-air) kézbesítési mechanizmussal a szükséges alkalmazás-összetevők telepítéséhez a szélső eszközön. Mindazonáltal továbbra is hasznunkra válna, ha magának a modellnek az OTA-telepítését végezhetnénk el, ezáltal elkülönítve az alkalmazás életciklusát és a modell életciklusát.

Amazon SageMaker Edge Manager és a Amazon SageMaker Neo jól illeszkedik ehhez a használati esethez.

Az Edge Manager megkönnyíti az ML edge fejlesztők számára, hogy ugyanazokat az ismerős eszközöket használják a felhőben vagy az Edge-eszközökön. Csökkenti a modellek gyártásához szükséges időt és erőfeszítést, miközben lehetővé teszi a modellek minőségének folyamatos nyomon követését és javítását eszközparkjában. A SageMaker Edge tartalmaz egy OTA-telepítési mechanizmust, amely segít a modellek telepítésében a flottában az alkalmazástól vagy az eszköz firmware-étől függetlenül. Az Edge Manager ügynök lehetővé teszi több modell futtatását ugyanazon az eszközön. Az ügynök előrejelzési adatokat gyűjt az Ön által szabályozott logika, például az időközök alapján, és feltölti a felhőbe, hogy időnként újra betanítsa a modelleket. A SageMaker Edge kriptográfiailag aláírja a modelleket, így ellenőrizheti, hogy nem manipulálták-e, miközben a felhőből a szélső eszközre kerül.

A Neo egy fordító, mint szolgáltatás, és különösen jól illeszkedik ehhez a használati esethez. A Neo automatikusan optimalizálja az ML-modelleket, hogy következtetéseket lehessen levonni a felhőpéldányokon és a szélső eszközökön, hogy gyorsabban futhassanak a pontosság vesztesége nélkül. Kezdje egy ML modellel, amely az egyikkel készült támogatott keretek és a SageMakerben vagy bárhol máshol képezték ki. Ezután válassza ki a cél hardverplatformot (lásd a listát támogatott eszközök). A Neo egyetlen kattintással optimalizálja a betanított modellt, és egy olyan csomagba állítja össze, amely a könnyű SageMaker Edge futtatókörnyezet használatával futtatható. A fordító egy ML-modellt használ a teljesítményoptimalizálások alkalmazásához, amelyek a legjobb elérhető teljesítményt kinyerik a modellhez a felhőpéldányon vagy az éleszközön. Ezután telepítse a modellt SageMaker-végpontként vagy támogatott peremeszközökön, és megkezdje az előrejelzések készítését.

A következő diagram ezt az architektúrát szemlélteti.

A megoldás munkafolyamata a következő lépésekből áll:

1. A fejlesztő összeállítja, betanítja, érvényesíti és létrehozza a végső modellműterméket, amelyet telepíteni kell a műszerkamerára.
2. Hívja meg Neót a betanított modell összeállításához.
3. A SageMaker Edge ügynök az Edge eszközön, jelen esetben a műszerkamerán van telepítve és konfigurálva.
4. Hozzon létre egy telepítési csomagot aláírt modellel és a SageMaker Edge ügynök által az optimalizált modell betöltéséhez és meghívásához használt futási idővel.
5. Telepítse a csomagot a meglévő OTA-telepítési mechanizmussal.
6. Az élalkalmazás kölcsönhatásba lép a SageMaker Edge ügynökkel, hogy következtetéseket vonjon le.
7. Az ügynök konfigurálható (ha szükséges), hogy valós idejű minta bemeneti adatokat küldjön az alkalmazásból modellfigyelés és -finomítás céljából.

3. használati eset

Tegyük fel, hogy ügyfele olyan alkalmazást fejleszt, amely észleli a szélturbina mechanizmusainak rendellenességeit (például a sebességváltót, a generátort vagy a rotort). A cél a berendezés károsodásának minimalizálása a helyi védelmi eljárások menet közbeni futtatásával. Ezek a turbinák nagyon drágák, és olyan helyeken helyezkednek el, amelyek nem könnyen hozzáférhetők. Mindegyik turbina felszerelhető egy NVIDIA Jetson eszközzel, amely figyeli a turbina szenzoradatait. Ezután megoldásra van szükségünk az adatok rögzítésére és egy ML algoritmus használatára az anomáliák észlelésére. Szükségünk van egy OTA-mechanizmusra is, hogy az eszközön lévő szoftvereket és ML-modelleket naprakészen tartsuk.

AWS IoT Greengrass V2 az Edge Managerrel együtt jól illeszkedik ehhez a használati esethez. Az AWS IoT Greengrass egy nyílt forráskódú IoT szélső futásidejű és felhőszolgáltatás, amely segít az IoT-alkalmazások felépítésében, üzembe helyezésében és kezelésében az eszközökön. Az AWS IoT Greengrass segítségével előre beépített szoftvermodulok segítségével készíthet élvonalbeli alkalmazásokat alkatrészek, amely csatlakoztathatja a szélső eszközeit AWS-szolgáltatásokhoz vagy harmadik féltől származó szolgáltatásokhoz. Az AWS IoT Greengrass ezen képessége megkönnyíti az eszközök telepítését az eszközökön, beleértve a SageMaker Edge ügynököt. Az AWS IoT Greengrass felelős az alkalmazás életciklusának kezeléséért, míg az Edge Manager leválasztja az ML modell életciklusát. Ez rugalmasságot biztosít a teljes megoldás fejlesztéséhez azáltal, hogy egymástól függetlenül telepíti az élalkalmazások és az ML modellek új verzióit. A következő diagram ezt az architektúrát szemlélteti.

A megoldás a következő lépésekből áll:

1. A fejlesztő megépíti, betanítja, érvényesíti és létrehozza a végső modellműterméket, amelyet telepíteni kell a szélturbinára.
2. Hívja meg Neót a betanított modell összeállításához.
3. Hozzon létre egy modellösszetevőt az Edge Manager segítségével az AWS IoT Greengrass V2 integrációjával.
4. Az AWS IoT Greengrass V2 beállítása.
5. Hozzon létre egy következtetési összetevőt az AWS IoT Greengrass V2 használatával.
6. Az élalkalmazás kölcsönhatásba lép a SageMaker Edge ügynökkel, hogy következtetéseket vonjon le.
7. Az ügynök konfigurálható (ha szükséges), hogy valós idejű minta bemeneti adatokat küldjön az alkalmazásból modellfigyelés és -finomítás céljából.

4. használati eset

Végső felhasználási esetünkben nézzünk meg egy konténereket szállító hajót, ahol minden konténerben van néhány érzékelő, és jelet továbbít a helyileg telepített számítási és tárolási infrastruktúrába. A kihívás az, hogy tudni akarjuk az egyes edények tartalmát, és az áruk állapotát a hőmérséklet, a páratartalom és a benne lévő gázok alapján. Ezenkívül nyomon akarjuk követni az egyes konténerekben lévő összes árut. Az út során nincs internetkapcsolat, és az út hónapokig is eltarthat. Az ezen az infrastruktúrán futó ML modelleknek elő kell feldolgozniuk az adatokat, és információkat kell generálniuk minden kérdésünk megválaszolásához. A keletkezett adatokat hónapokig helyben kell tárolni. Az élalkalmazás az összes következtetést egy helyi adatbázisban tárolja, majd szinkronizálja az eredményeket a felhővel, amikor a hajó megközelíti a kikötőt.

AWS Snowcone és a AWS hógolyó tól AWS Snow család nagyon jól illeszkedik ehhez a használati esethez.

Az AWS Snowcone egy kicsi, strapabíró és biztonságos számítástechnikai és adatmigrációs eszköz. A Snowcone-t az OSHA szabványnak megfelelően egyszemélyes emelhető eszközhöz tervezték. A Snowcone lehetővé teszi szélsőséges munkaterhelések futtatását Amazon rugalmas számítási felhő (Amazon EC2) számítástechnika és helyi tárolás zord, szétkapcsolt terepi környezetben, például olajfúrótornyokon, kutató-mentő járműveken, katonai helyszíneken vagy gyártelepeken, valamint távoli irodákban, kórházakban és filmszínházakban.

A Snowball több számítási lehetőséget kínál a Snowcone-hoz képest, ezért kiválóan illeszkedik az igényesebb alkalmazásokhoz. A Compute Optimized funkció opcionális NVIDIA Tesla V100 GPU-t és EC2-példányokat biztosít, hogy felgyorsítsa az alkalmazások teljesítményét leválasztott környezetben. A GPU opcióval olyan alkalmazásokat futtathat, mint a fejlett ML és a teljes mozgásos videoelemzés olyan környezetben, ahol kevés vagy nincs kapcsolat.

Az EC2 példányon felül szabadon építhet és telepíthet bármilyen élvonalbeli megoldást. Például: használhatod Amazon ECS vagy más tárolókezelő az élalkalmazás, az Edge Manager Agent és az ML-modell egyedi tárolóként történő üzembe helyezéséhez. Ez az architektúra hasonló lenne a Use Case 2-hez (kivéve, hogy az idő nagy részében offline módban működik), egy tárolókezelő eszköz hozzáadásával.

A következő ábra szemlélteti ezt a megoldás architektúrát.

A megoldás megvalósításához egyszerűen rendelje meg Snow készülékét a AWS felügyeleti konzol és indítsa el az erőforrásait.

Következtetés

Ebben a bejegyzésben megvitattuk az él különböző szempontjait, amelyekkel a használati esete alapján választhat. Megvitattuk az ML@Edge néhány kulcsfontosságú fogalmát is, és azt, hogy az alkalmazás-életciklus és az ML-modell életciklusának szétválasztása hogyan ad szabadságot ezek fejlesztésére anélkül, hogy egymástól függene. Hangsúlyoztuk, hogy a munkaterhelésnek megfelelő éleszköz kiválasztása és a megfelelő kérdések megoldása a megoldási folyamat során segíthet visszafelé dolgozni, és leszűkíteni a megfelelő AWS-szolgáltatásokat. Különböző használati eseteket és referenciaarchitektúrákat is bemutattunk, hogy ösztönözzük Önt saját megoldások létrehozására, amelyek megfelelnek a munkaterhelésnek.

---

A szerzőkről

Dinesh Kumar Subramani Senior Solutions Architect az UKIR SMB csapatánál, székhelye Edinburghban, Skóciában. Szakterülete a mesterséges intelligencia és a gépi tanulás. Dinesh szívesen dolgozik az ügyfelekkel az iparágakban, hogy segítsen nekik megoldani az AWS-szolgáltatásokkal kapcsolatos problémáikat. A munkán kívül szeret a családjával tölteni az idejét, sakkozni és különféle műfajú zenét élvezni.

Samir Araújo az AWS AI/ML megoldások építésze. Segít ügyfeleinek olyan AI/ML megoldások létrehozásában, amelyek az AWS segítségével megoldják üzleti kihívásaikat. Számos AI/ML projekten dolgozott, amelyek a számítógépes látással, a természetes nyelvi feldolgozással, az előrejelzéssel, az ML szélén és még sok mással kapcsolatosak. Szabadidejében szeret hardveres és automatizálási projektekkel játszani, és különösen a robotika érdekli.

• Coinsmart. Európa legjobb Bitcoin- és kriptográfiai tőzsdéje.
• Platoblockchain. Web3 metaverzum intelligencia. Felerősített tudás. SZABAD HOZZÁFÉRÉS.
• CryptoHawk. Altcoin radar. Ingyenes próbaverzió.
• Forrás: https://aws.amazon.com/blogs/machine-learning/demystifying-machine-learning-at-the-edge-through-real-use-cases/