Afmystificerende maskinlæring på kanten gennem reelle use cases

Edge er et udtryk, der refererer til en placering, langt fra skyen eller et stort datacenter, hvor du har en computerenhed (edge-enhed), der er i stand til at køre (edge-)applikationer. Edge computing er handlingen med at køre arbejdsbelastninger på disse edge-enheder. Machine learning at the edge (ML@Edge) er et koncept, der bringer muligheden for at køre ML-modeller lokalt til edge-enheder. Disse ML-modeller kan derefter påberåbes af edge-applikationen. ML@Edge er vigtig for mange scenarier, hvor rådata indsamles fra kilder langt fra skyen. Disse scenarier kan også have specifikke krav eller begrænsninger:

• Forudsigelser i realtid med lav latens
• Dårlig eller ikke-eksisterende forbindelse til skyen
• Juridiske begrænsninger, der ikke tillader afsendelse af data til eksterne tjenester
• Store datasæt, der skal forbehandles lokalt, før svar sendes til skyen

Følgende er nogle af mange use cases, der kan drage fordel af ML-modeller, der kører tæt på det udstyr, der genererer de data, der bruges til forudsigelserne:

• Sikkerhed og sikkerhed – Et begrænset område, hvor tunge maskiner opererer i en automatiseret havn, overvåges af et kamera. Hvis en person kommer ind i dette område ved en fejl, aktiveres en sikkerhedsmekanisme for at stoppe maskinerne og beskytte mennesket.
• Forebyggende vedligeholdelse – Vibrations- og lydsensorer indsamler data fra en vindmølles gearkasse. En anomalidetektionsmodel behandler sensordataene og identificerer, om der er uregelmæssigheder med udstyret. Hvis der opdages en uregelmæssighed, kan kantanordningen starte en beredskabsmåling i realtid for at undgå at beskadige udstyret, f.eks. aktivere pauserne eller afbryde generatoren fra nettet.
• Fejldetektering i produktionslinjer – Et kamera tager billeder af produkter på et transportbånd og behandler rammerne med en billedklassificeringsmodel. Hvis der opdages en defekt, kan produktet kasseres automatisk uden manuel indgriben.

Selvom ML@Edge kan håndtere mange use cases, er der komplekse arkitektoniske udfordringer, der skal løses for at have et sikkert, robust og pålideligt design. I dette indlæg lærer du nogle detaljer om ML@Edge, relaterede emner, og hvordan du bruger AWS-tjenester til at overvinde disse udfordringer og implementere en komplet løsning til din ML på kanten af ​​arbejdsbyrden.

ML@Edge oversigt

Der er en almindelig forvirring, når det kommer til ML@Edge og Internet of Things (IoT), derfor er det vigtigt at afklare, hvordan ML@Edge adskiller sig fra IoT, og hvordan de begge kunne komme sammen for at give en kraftfuld løsning i visse tilfælde.

En edge-løsning, der bruger ML@Edge, har to hovedkomponenter: en edge-applikation og en ML-model (påkaldt af applikationen), der kører på edge-enheden. ML@Edge handler om at kontrollere livscyklussen for en eller flere ML-modeller, der er implementeret til en flåde af edge-enheder. ML-modellens livscyklus kan starte på skysiden (på Amazon SageMaker, for eksempel), men ender normalt på en selvstændig implementering af modellen på edge-enheden. Hvert scenarie kræver forskellige ML-modellers livscyklusser, der kan sammensættes af mange stadier, såsom dataindsamling; forberedelse af data; modelbygning, kompilering og implementering til edge-enheden; model læsning og kørsel; og gentagelse af livscyklussen.

ML@Edge-mekanismen er ikke ansvarlig for applikationens livscyklus. En anden tilgang bør anvendes til dette formål. Afkobling af ML-modellens livscyklus og applikationslivscyklus giver dig frihed og fleksibilitet til at fortsætte med at udvikle dem i forskellige hastigheder. Forestil dig en mobilapplikation, der integrerer en ML-model som en ressource som et billede eller en XML-fil. I dette tilfælde, hver gang du træner en ny model og ønsker at implementere den på mobiltelefonerne, skal du geninstallere hele applikationen. Dette bruger tid og penge og kan introducere fejl til din applikation. Ved at afkoble ML-modellens livscyklus udgiver du mobilappen én gang og implementerer så mange versioner af ML-modellen, som du har brug for.

Men hvordan hænger IoT sammen med ML@Edge? IoT relaterer sig til fysiske objekter indlejret med teknologier som sensorer, behandlingsevne og software. Disse objekter er forbundet med andre enheder og systemer over internettet eller andre kommunikationsnetværk for at udveksle data. Følgende figur illustrerer denne arkitektur. Konceptet blev oprindeligt skabt, da man tænkte på simple enheder, der blot indsamler data fra kanten, udfører simpel lokal behandling og sender resultatet til en mere kraftfuld computerenhed, der kører analyseprocesser, der hjælper mennesker og virksomheder i deres beslutningstagning. IoT-løsningen er ansvarlig for at kontrollere edge-applikationens livscyklus. For mere information om IoT, se Internet af ting.

Hvis du allerede har en IoT-applikation, kan du tilføje ML@Edge-funktioner for at gøre produktet mere effektivt, som vist i følgende figur. Husk på, at ML@Edge ikke er afhængig af IoT, men du kan kombinere dem for at skabe en mere kraftfuld løsning. Når du gør det, forbedrer du potentialet for din simple enhed til at generere realtidsindsigt til din virksomhed hurtigere end blot at sende data til skyen til senere behandling.

Hvis du skaber en ny kantløsning fra bunden med ML@Edge-funktioner, er det vigtigt at designe en fleksibel arkitektur, der understøtter både applikationens og ML-modellens livscyklus. Vi leverer nogle referencearkitekturer til edge-applikationer med ML@Edge senere i dette indlæg. Men lad os først dykke dybere ned i edge computing og lære, hvordan du vælger den korrekte edge-enhed til din løsning, baseret på miljøets begrænsninger.

edge computing

Afhængigt af hvor langt enheden er fra skyen eller et stort datacenter (base), skal tre hovedkarakteristika ved edge-enhederne overvejes for at maksimere systemets ydeevne og levetid: computer- og lagerkapacitet, tilslutningsmuligheder og strømforbrug. Det følgende diagram viser tre grupper af kantenheder, der kombinerer forskellige specifikationer for disse egenskaber, afhængigt af hvor langt fra de er fra basen.

Grupperne er som følger:

• MEC'er (Multi-access Edge Computing) – MEC'er eller små datacentre, karakteriseret ved lav eller ultra-lav latency og høj båndbredde, er almindelige miljøer, hvor ML@Edge kan give fordele uden store begrænsninger sammenlignet med cloud-arbejdsbelastninger. 5G-antenner og servere på fabrikker, lagre, laboratorier og så videre med minimale energibegrænsninger og med god internetforbindelse tilbyder forskellige måder at køre ML-modeller på GPU'er og CPU'er, virtuelle maskiner, containere og bare-metal-servere.
• Nær kanten – Det er, når mobilitet eller dataaggregering er krav, og enhederne har nogle begrænsninger med hensyn til strømforbrug og processorkraft, men stadig har nogle pålidelige tilslutningsmuligheder, dog med højere latenstid, med begrænset gennemløb og dyrere end "tæt på kanten." Mobilapplikationer, specifikke tavler til at accelerere ML-modeller eller simple enheder med kapacitet til at køre ML-modeller, dækket af trådløse netværk, er inkluderet i denne gruppe.
• Fjernkant – I dette ekstreme scenarie har edge-enheder alvorlige strømforbrug eller tilslutningsbegrænsninger. Som følge heraf er processorkraften også begrænset i mange scenarier med fjernkant. Landbrug, minedrift, overvågning og sikkerhed og søtransport er nogle områder, hvor fjerntliggende enheder spiller en vigtig rolle. Simple boards, normalt uden GPU'er eller andre AI-acceleratorer, er almindelige. De er designet til at indlæse og køre simple ML-modeller, gemme forudsigelserne i en lokal database og sove indtil næste forudsigelsescyklus. De enheder, der skal behandle realtidsdata, kan have store lokale lager for at undgå at miste data.

Udfordringer

Det er almindeligt at have ML@Edge-scenarier, hvor du har hundredvis eller tusinder (måske endda millioner) af enheder, der kører de samme modeller og edge-applikationer. Når du skalerer dit system, er det vigtigt at have en robust løsning, der kan administrere det antal enheder, du skal understøtte. Dette er en kompleks opgave, og til disse scenarier skal du stille mange spørgsmål:

• Hvordan betjener jeg ML-modeller på en flåde af enheder ved kanten?
• Hvordan bygger, optimerer og implementerer jeg ML-modeller til flere edge-enheder?
• Hvordan sikrer jeg min model, mens jeg installerer og kører den i kanten?
• Hvordan overvåger jeg min models ydeevne og genoplærer den, hvis det er nødvendigt?
• Hvordan fjerner jeg behovet for at installere en stor ramme som TensorFlow eller PyTorch på min begrænsede enhed?
• Hvordan eksponerer jeg en eller flere modeller med min edge-applikation som en simpel API?
• Hvordan opretter jeg et nyt datasæt med de nyttelaster og forudsigelser, der fanges af edge-enhederne?
• Hvordan udfører jeg alle disse opgaver automatisk (MLOps plus ML@Edge)?

I det næste afsnit giver vi svar på alle disse spørgsmål gennem eksempler på use cases og referencearkitekturer. Vi diskuterer også, hvilke AWS-tjenester du kan kombinere for at bygge komplette løsninger til hvert af de undersøgte scenarier. Men hvis du vil starte med et meget simpelt flow, der beskriver, hvordan du bruger nogle af de tjenester, der leveres af AWS til at skabe din ML@Edge-løsning, er dette et eksempel:

Med SageMaker kan du nemt forberede et datasæt og bygge de ML-modeller, der er implementeret til edge-enhederne. Med Amazon SageMaker Neo, kan du kompilere og optimere den model, du trænede, til den specifikke kant-enhed, du valgte. Efter kompilering af modellen behøver du kun en let køretid for at køre den (leveret af tjenesten). Amazon SageMaker Edge Manager er ansvarlig for at administrere livscyklussen for alle ML-modeller, der er implementeret på din flåde af edge-enheder. Edge Manager kan administrere flåder på op til millioner af enheder. En agent, der er installeret på hver enkelt af edge-enhederne, afslører de implementerede ML-modeller som en API til applikationen. Agenten er også ansvarlig for at indsamle metrikker, nyttelast og forudsigelser, som du kan bruge til at overvåge eller bygge et nyt datasæt for at genoptræne modellen, hvis det er nødvendigt. Endelig med Amazon SageMaker Pipelines, kan du oprette en automatiseret pipeline med alle de nødvendige trin for at bygge, optimere og implementere ML-modeller til din flåde af enheder. Denne automatiserede pipeline kan derefter udløses af simple hændelser, du definerer, uden menneskelig indgriben.

Brug case 1

Lad os sige, at en flyproducent ønsker at opdage og spore dele og værktøjer i produktionshangaren. For at forbedre produktiviteten skal alle de nødvendige dele og korrekte værktøjer være tilgængelige for ingeniørerne på hvert produktionstrin. Vi vil gerne kunne besvare spørgsmål som: Hvor er del A? eller hvor er værktøj B? Vi har flere IP-kameraer allerede installeret og forbundet til et lokalt netværk. Kameraerne dækker hele hangaren og kan streame HD-video i realtid gennem netværket.

AWS Panorama passer fint ind i dette tilfælde. AWS Panorama leverer et ML-apparat og en administreret service, der giver dig mulighed for at tilføje computersyn (CV) til din eksisterende flåde af IP-kameraer og automatisere. AWS Panorama giver dig mulighed for at tilføje CV til dine eksisterende Internet Protocol (IP) kameraer og automatisere opgaver, der traditionelt kræver menneskelig inspektion og overvågning.

I den følgende referencearkitektur viser vi hovedkomponenterne i applikationen, der kører på en AWS Panorama Appliance. Panorama Application SDK gør det nemt at optage video fra kamerastreams, udføre inferens med en pipeline af flere ML-modeller og behandle resultaterne ved hjælp af Python-kode, der kører inde i en container. Du kan køre modeller fra ethvert populært ML-bibliotek såsom TensorFlow, PyTorch eller TensorRT. Resultaterne fra modellen kan integreres med forretningssystemer på dit lokale netværk, så du kan reagere på begivenheder i realtid.

Løsningen består af følgende trin:

1. Tilslut og konfigurer en AWS Panorama-enhed til det samme lokale netværk.
2. Træn en ML-model (objektdetektion) for at identificere dele og værktøjer i hver ramme.
3. Byg en AWS Panorama-applikation, der henter forudsigelserne fra ML-modellen, anvender en sporingsmekanisme på hvert objekt og sender resultaterne til en realtidsdatabase.
4. Operatørerne kan sende forespørgsler til databasen for at finde delene og værktøjerne.

Brug case 2

Forestil dig til vores næste brugssag, at vi skaber et dashcam til køretøjer, der er i stand til at støtte føreren i mange situationer, såsom at undgå fodgængere, baseret på en CV25 board fra Ambaralla. Det kan være svært at hoste ML-modeller på en enhed med begrænsede systemressourcer. Lad os i dette tilfælde antage, at vi allerede har en veletableret over-the-air (OTA) leveringsmekanisme på plads til at implementere de nødvendige applikationskomponenter på edge-enheden. Vi ville dog stadig drage fordel af muligheden for at udføre OTA-implementering af selve modellen og derved isolere applikationens livscyklus og modellivscyklus.

Amazon SageMaker Edge Manager , Amazon SageMaker Neo passer godt til denne brugssag.

Edge Manager gør det nemt for ML edge-udviklere at bruge de samme velkendte værktøjer i skyen eller på edge-enheder. Det reducerer den tid og indsats, der kræves for at få modeller i produktion, samtidig med at du løbende kan overvåge og forbedre modelkvaliteten på tværs af din enhedsflåde. SageMaker Edge inkluderer en OTA-implementeringsmekanisme, der hjælper dig med at implementere modeller på flåden uafhængigt af applikationen eller enhedsfirmwaren. Det Edge Manager agent giver dig mulighed for at køre flere modeller på den samme enhed. Agenten indsamler forudsigelsesdata baseret på den logik, du kontrollerer, såsom intervaller, og uploader dem til skyen, så du med jævne mellemrum kan genoptræne dine modeller over tid. SageMaker Edge signerer dine modeller kryptografisk, så du kan verificere, at der ikke blev pillet ved den, når den bevæger sig fra skyen til enheden.

Neo er en compiler som en service og en særlig god pasform i denne use case. Neo optimerer automatisk ML-modeller til slutninger om cloud-instanser og edge-enheder for at køre hurtigere uden tab af nøjagtighed. Du starter med en ML-model bygget med en af understøttede rammer og uddannet i SageMaker eller andre steder. Derefter vælger du din målhardwareplatform (se listen over understøttede enheder). Med et enkelt klik optimerer Neo den trænede model og kompilerer den til en pakke, der kan køres ved hjælp af den lette SageMaker Edge runtime. Compileren bruger en ML-model til at anvende ydeevneoptimeringerne, der uddrager den bedst tilgængelige ydeevne for din model på cloud-instansen eller edge-enheden. Du implementerer derefter modellen som et SageMaker-slutpunkt eller på understøttede edge-enheder og begynder at lave forudsigelser.

Følgende diagram illustrerer denne arkitektur.

Løsningsarbejdsgangen består af følgende trin:

1. Udvikleren bygger, træner, validerer og skaber den endelige modelartefakt, der skal implementeres til dashcam.
2. Påkald Neo for at kompilere den trænede model.
3. SageMaker Edge-agenten er installeret og konfigureret på Edge-enheden, i dette tilfælde dashcam.
4. Opret en implementeringspakke med en signeret model og den kørselstid, som SageMaker Edge-agenten bruger til at indlæse og kalde den optimerede model.
5. Implementer pakken ved hjælp af den eksisterende OTA-implementeringsmekanisme.
6. Edge-applikationen interagerer med SageMaker Edge-agenten for at gøre slutninger.
7. Agenten kan konfigureres (hvis påkrævet) til at sende real-time prøveinputdata fra applikationen til modelovervågning og forfiningsformål.

Brug case 3

Antag, at din kunde udvikler en applikation, der registrerer uregelmæssigheder i mekanismerne i en vindmølle (som gearkassen, generatoren eller rotoren). Målet er at minimere skaderne på udstyret ved at køre lokale beskyttelsesprocedurer i farten. Disse møller er meget dyre og placeret på steder, der ikke er let tilgængelige. Hver turbine kan udstyres med en NVIDIA Jetson-enhed til at overvåge sensordata fra turbinen. Vi har så brug for en løsning til at fange dataene og bruge en ML-algoritme til at opdage uregelmæssigheder. Vi har også brug for en OTA-mekanisme til at holde softwaren og ML-modellerne på enheden opdateret.

AWS IoT Greengrass V2 sammen med Edge Manager passer godt i denne brugssituation. AWS IoT Greengrass er en open source IoT edge runtime og cloud-tjeneste, der hjælper dig med at bygge, implementere og administrere IoT-applikationer på dine enheder. Du kan bruge AWS IoT Greengrass til at bygge edge-applikationer ved hjælp af forudbyggede softwaremoduler, kaldet komponenter, der kan forbinde dine edge-enheder til AWS-tjenester eller tredjepartstjenester. Denne evne hos AWS IoT Greengrass gør det nemt at implementere aktiver til enheder, inklusive en SageMaker Edge-agent. AWS IoT Greengrass er ansvarlig for at administrere applikationens livscyklus, mens Edge Manager afkobler ML-modellens livscyklus. Dette giver dig fleksibiliteten til at fortsætte med at udvikle hele løsningen ved at implementere nye versioner af edge-applikationen og ML-modeller uafhængigt. Følgende diagram illustrerer denne arkitektur.

Løsningen består af følgende trin:

1. Udvikleren bygger, træner, validerer og skaber den endelige modelartefakt, der skal installeres på vindmøllen.
2. Påkald Neo for at kompilere den trænede model.
3. Opret en modelkomponent ved hjælp af Edge Manager med AWS IoT Greengrass V2-integration.
4. Konfigurer AWS IoT Greengrass V2.
5. Opret en inferenskomponent ved hjælp af AWS IoT Greengrass V2.
6. Edge-applikationen interagerer med SageMaker Edge-agenten for at gøre slutninger.
7. Agenten kan konfigureres (hvis påkrævet) til at sende real-time prøveinputdata fra applikationen til modelovervågning og forfiningsformål.

Brug case 4

Til vores sidste brugssag, lad os se på et fartøj, der transporterer containere, hvor hver container har et par sensorer og streamer et signal til computer- og lagerinfrastrukturen, der er installeret lokalt. Udfordringen er, at vi gerne vil kende indholdet af hver beholder, og varens tilstand baseret på temperatur, luftfugtighed og gasser inde i hver beholder. Vi ønsker også at spore alle varerne i hver af containerne. Der er ingen internetforbindelse under hele rejsen, og rejsen kan tage måneder. ML-modellerne, der kører på denne infrastruktur, bør forbehandle dataene og generere information for at besvare alle vores spørgsmål. De genererede data skal opbevares lokalt i flere måneder. Edge-applikationen gemmer alle inferenser i en lokal database og synkroniserer derefter resultaterne med skyen, når fartøjet nærmer sig havnen.

AWS snekegle , AWS snebold fra AWS snefamilie kunne passe meget godt i denne brugssag.

AWS Snowcone er en lille, robust og sikker edge computing og datamigreringsenhed. Snowcone er designet til OSHA-standarden for en en-persons løfteanordning. Snowcone giver dig mulighed for at køre edge workloads vha Amazon Elastic Compute Cloud (Amazon EC2) databehandling og lokal lagring i barske, afbrudte feltmiljøer såsom olieboreplatforme, eftersøgnings- og redningskøretøjer, militærpladser eller fabriksgulve samt fjerntliggende kontorer, hospitaler og biografer.

Snowball tilføjer mere databehandling sammenlignet med Snowcone og kan derfor passe godt til mere krævende applikationer. Compute Optimized-funktionen giver en valgfri NVIDIA Tesla V100 GPU sammen med EC2-instanser for at accelerere en applikations ydeevne i afbrudte miljøer. Med GPU-indstillingen kan du køre applikationer såsom avanceret ML og videoanalyse i fuld bevægelse i miljøer med ringe eller ingen tilslutningsmuligheder.

Ud over EC2-instansen har du friheden til at bygge og implementere enhver form for edge-løsning. For eksempel: du kan bruge Amazon ECS eller anden containeradministrator til at implementere edge-applikationen, Edge Manager Agent og ML-modellen som individuelle containere. Denne arkitektur vil ligne Use Case 2 (bortset fra at den vil fungere offline det meste af tiden), med tilføjelsen af ​​et containerstyringsværktøj.

Følgende diagram illustrerer denne løsningsarkitektur.

For at implementere denne løsning skal du blot bestille din Snow-enhed fra AWS Management Console og start dine ressourcer.

Konklusion

I dette indlæg diskuterede vi de forskellige aspekter af edge, som du kan vælge at arbejde med baseret på din use case. Vi diskuterede også nogle af nøglebegreberne omkring ML@Edge, og hvordan afkobling af applikationslivscyklussen og ML-modellens livscyklus giver dig frihed til at udvikle dem uden nogen afhængighed af hinanden. Vi understregede, hvordan det at vælge den rigtige kant-enhed til din arbejdsbyrde og stille de rigtige spørgsmål under løsningsprocessen kan hjælpe dig med at arbejde baglæns og indsnævre de rigtige AWS-tjenester. Vi præsenterede også forskellige use cases sammen med referencearkitekturer for at inspirere dig til at skabe dine egne løsninger, der passer til din arbejdsbyrde.

---

Om forfatterne

Dinesh Kumar Subramani er Senior Solutions Architect hos UKIR SMB-teamet med base i Edinburgh, Skotland. Han har specialiseret sig i kunstig intelligens og maskinlæring. Dinesh nyder at arbejde med kunder på tværs af brancher for at hjælpe dem med at løse deres problemer med AWS-tjenester. Uden for arbejdet elsker han at tilbringe tid med sin familie, spille skak og nyde musik på tværs af genrer.

Samir Araújo er AI/ML Solutions Architect hos AWS. Han hjælper kunder med at skabe AI/ML-løsninger, der løser deres forretningsmæssige udfordringer ved hjælp af AWS. Han har arbejdet på adskillige AI/ML-projekter relateret til computersyn, naturlig sprogbehandling, prognoser, ML ved kanten og mere. Han kan lide at lege med hardware og automatiseringsprojekter i sin fritid, og han har en særlig interesse for robotteknologi.

• Coinsmart. Europas bedste Bitcoin og Crypto Exchange.
• Platoblokkæde. Web3 Metaverse Intelligence. Viden forstærket. FRI ADGANG.
• CryptoHawk. Altcoin radar. Gratis prøveversion.
• Kilde: https://aws.amazon.com/blogs/machine-learning/demystifying-machine-learning-at-the-edge-through-real-use-cases/