Avmystifiserer maskinlæring på kanten gjennom reelle brukstilfeller

Edge er et begrep som refererer til et sted, langt fra skyen eller et stort datasenter, hvor du har en datamaskinenhet (kantenhet) som kan kjøre (kant)applikasjoner. Edge computing er handlingen for å kjøre arbeidsbelastninger på disse edge-enhetene. Machine learning at the edge (ML@Edge) er et konsept som bringer muligheten til å kjøre ML-modeller lokalt til edge-enheter. Disse ML-modellene kan deretter påberopes av edge-applikasjonen. ML@Edge er viktig for mange scenarier der rådata samles inn fra kilder langt fra skyen. Disse scenariene kan også ha spesifikke krav eller begrensninger:

• Lav latens, sanntids spådommer
• Dårlig eller ikke-eksisterende tilkobling til skyen
• Juridiske begrensninger som ikke tillater sending av data til eksterne tjenester
• Store datasett som må forhåndsbehandles lokalt før svar sendes til skyen

Følgende er noen av mange brukstilfeller som kan dra nytte av ML-modeller som kjører nær utstyret som genererer dataene som brukes for spådommene:

• Sikkerhet og sikkerhet – Et begrenset område der tunge maskiner opererer i en automatisert havn overvåkes av et kamera. Hvis en person kommer inn i dette området ved en feiltakelse, aktiveres en sikkerhetsmekanisme for å stoppe maskinene og beskytte mennesket.
• Forutsigbart vedlikehold – Vibrasjons- og lydsensorer samler inn data fra en girkasse til en vindturbin. En anomalideteksjonsmodell behandler sensordataene og identifiserer om det er uregelmessigheter med utstyret. Hvis en anomali oppdages, kan kantenheten starte en beredskapsmåling i sanntid for å unngå å skade utstyret, for eksempel koble inn bruddene eller koble generatoren fra nettet.
• Defektdeteksjon i produksjonslinjer – Et kamera tar bilder av produkter på et transportbånd og behandler rammene med en bildeklassifiseringsmodell. Hvis en defekt oppdages, kan produktet kasseres automatisk uten manuell inngripen.

Selv om ML@Edge kan håndtere mange bruksområder, er det komplekse arkitektoniske utfordringer som må løses for å ha en sikker, robust og pålitelig design. I dette innlegget lærer du noen detaljer om ML@Edge, relaterte emner og hvordan du bruker AWS-tjenester for å overvinne disse utfordringene og implementere en komplett løsning for ML-en din på kanten av arbeidsbelastningen.

ML@Edge oversikt

Det er en vanlig forvirring når det kommer til ML@Edge og Internet of Things (IoT), derfor er det viktig å avklare hvordan ML@Edge er forskjellig fra IoT og hvordan de begge kan komme sammen for å gi en kraftig løsning i visse tilfeller.

En edge-løsning som bruker ML@Edge har to hovedkomponenter: en edge-applikasjon og en ML-modell (påkalt av applikasjonen) som kjører på edge-enheten. ML@Edge handler om å kontrollere livssyklusen til en eller flere ML-modeller distribuert til en flåte av edge-enheter. ML-modellens livssyklus kan starte på skysiden (på Amazon SageMaker, for eksempel), men ender normalt på en frittstående distribusjon av modellen på edge-enheten. Hvert scenario krever forskjellige livssykluser for ML-modeller som kan settes sammen av mange stadier, for eksempel datainnsamling; data forberedelse; modellbygging, kompilering og distribusjon til kantenheten; modell lasting og kjøring; og gjenta livssyklusen.

ML@Edge-mekanismen er ikke ansvarlig for applikasjonens livssyklus. En annen tilnærming bør benyttes for dette formålet. Å koble fra ML-modellens livssyklus og applikasjonslivssyklusen gir deg friheten og fleksibiliteten til å fortsette å utvikle dem i forskjellige tempo. Tenk deg en mobilapplikasjon som bygger inn en ML-modell som en ressurs som et bilde eller en XML-fil. I dette tilfellet, hver gang du trener en ny modell og ønsker å distribuere den til mobiltelefonene, må du distribuere hele applikasjonen på nytt. Dette bruker tid og penger, og kan introdusere feil i applikasjonen din. Ved å koble fra ML-modellens livssyklus publiserer du mobilappen én gang og distribuerer så mange versjoner av ML-modellen du trenger.

Men hvordan korrelerer IoT med ML@Edge? IoT er relatert til fysiske objekter innebygd med teknologier som sensorer, prosesseringsevne og programvare. Disse objektene er koblet til andre enheter og systemer over internett eller andre kommunikasjonsnettverk, for å utveksle data. Følgende figur illustrerer denne arkitekturen. Konseptet ble opprinnelig skapt når man tenkte på enkle enheter som bare samler inn data fra kanten, utfører enkel lokal prosessering og sender resultatet til en kraftigere dataenhet som kjører analyseprosesser som hjelper mennesker og bedrifter i deres beslutningstaking. IoT-løsningen er ansvarlig for å kontrollere edge-applikasjonens livssyklus. For mer informasjon om IoT, se Internet of Things.

Hvis du allerede har en IoT-applikasjon, kan du legge til ML@Edge-funksjoner for å gjøre produktet mer effektivt, som vist i følgende figur. Husk at ML@Edge ikke er avhengig av IoT, men du kan kombinere dem for å lage en kraftigere løsning. Når du gjør det, forbedrer du potensialet til den enkle enheten din for å generere sanntidsinnsikt for bedriften din raskere enn å bare sende data til skyen for senere behandling.

Hvis du lager en ny kantløsning fra bunnen av med ML@Edge-funksjoner, er det viktig å designe en fleksibel arkitektur som støtter både applikasjonens og ML-modellens livssyklus. Vi gir noen referansearkitekturer for edge-applikasjoner med ML@Edge senere i dette innlegget. Men først, la oss dykke dypere inn i edge computing og lære hvordan du velger riktig edge-enhet for løsningen din, basert på begrensningene i miljøet.

Edge computing

Avhengig av hvor langt enheten er fra nettskyen eller et stort datasenter (base), må tre hovedkarakteristika ved kantenhetene vurderes for å maksimere ytelsen og levetiden til systemet: data- og lagringskapasitet, tilkoblingsmuligheter og strømforbruk. Følgende diagram viser tre grupper av kantenheter som kombinerer ulike spesifikasjoner av disse egenskapene, avhengig av hvor langt fra de er fra basen.

Gruppene er som følger:

• MECs (Multi-Access Edge Computing) – MEC-er eller små datasentre, preget av lav eller ultralav latens og høy båndbredde, er vanlige miljøer der ML@Edge kan gi fordeler uten store begrensninger sammenlignet med skyarbeidsmengder. 5G-antenner og servere på fabrikker, varehus, laboratorier og så videre med minimale energibegrensninger og med god internettforbindelse tilbyr forskjellige måter å kjøre ML-modeller på GPUer og CPUer, virtuelle maskiner, containere og bare-metal-servere.
• Nær kanten – Dette er når mobilitet eller dataaggregering er krav og enhetene har noen begrensninger angående strømforbruk og prosessorkraft, men fortsatt har noen pålitelig tilkobling, men med høyere latens, med begrenset gjennomstrømning og dyrere enn «nær kanten». Mobilapplikasjoner, spesifikke kort for å akselerere ML-modeller, eller enkle enheter med kapasitet til å kjøre ML-modeller, dekket av trådløse nettverk, er inkludert i denne gruppen.
• Ytterste kant – I dette ekstreme scenariet har edge-enheter alvorlige strømforbruk eller tilkoblingsbegrensninger. Følgelig er prosessorkraft også begrenset i mange fjernscenarier. Landbruk, gruvedrift, overvåking og sikkerhet, og maritim transport er noen områder der fjernkantenheter spiller en viktig rolle. Enkle brett, normalt uten GPUer eller andre AI-akseleratorer, er vanlige. De er designet for å laste og kjøre enkle ML-modeller, lagre spådommene i en lokal database og hvile til neste prediksjonssyklus. Enhetene som trenger å behandle sanntidsdata kan ha store lokale lagringsenheter for å unngå å miste data.

Utfordringer

Det er vanlig å ha ML@Edge-scenarier der du har hundrevis eller tusenvis (kanskje til og med millioner) av enheter som kjører de samme modellene og edge-applikasjonene. Når du skalerer systemet ditt, er det viktig å ha en robust løsning som kan administrere antallet enheter du trenger å støtte. Dette er en kompleks oppgave, og for disse scenariene må du stille mange spørsmål:

• Hvordan betjener jeg ML-modeller på en flåte av enheter på kanten?
• Hvordan bygger, optimaliserer og distribuerer jeg ML-modeller til flere edge-enheter?
• Hvordan sikrer jeg modellen min mens jeg distribuerer og kjører den på kanten?
• Hvordan overvåker jeg modellens ytelse og omskoler den om nødvendig?
• Hvordan eliminerer jeg behovet for å installere et stort rammeverk som TensorFlow eller PyTorch på min begrensede enhet?
• Hvordan eksponerer jeg en eller flere modeller med min edge-applikasjon som en enkel API?
• Hvordan oppretter jeg et nytt datasett med nyttelastene og spådommene fanget opp av edge-enhetene?
• Hvordan gjør jeg alle disse oppgavene automatisk (MLOps pluss ML@Edge)?

I neste avsnitt gir vi svar på alle disse spørsmålene gjennom eksempler på brukstilfeller og referansearkitekturer. Vi diskuterer også hvilke AWS-tjenester du kan kombinere for å bygge komplette løsninger for hvert av de utforskede scenariene. Men hvis du vil starte med en veldig enkel flyt som beskriver hvordan du bruker noen av tjenestene som tilbys av AWS for å lage din ML@Edge-løsning, er dette et eksempel:

Med SageMaker kan du enkelt forberede et datasett og bygge ML-modellene som distribueres til edge-enhetene. Med Amazon SageMaker Neo, kan du kompilere og optimalisere modellen du trente til den spesifikke edge-enheten du valgte. Etter å ha kompilert modellen trenger du bare en lett kjøretid for å kjøre den (levert av tjenesten). Amazon SageMaker Edge Manager er ansvarlig for å administrere livssyklusen til alle ML-modeller som er distribuert til flåten av edge-enheter. Edge Manager kan administrere flåter på opptil millioner av enheter. En agent, installert på hver av edge-enhetene, avslører de distribuerte ML-modellene som en API for applikasjonen. Agenten er også ansvarlig for å samle inn beregninger, nyttelast og spådommer som du kan bruke til å overvåke eller bygge et nytt datasett for å trene modellen om nødvendig. Til slutt med Amazon SageMaker-rørledninger, kan du opprette en automatisert pipeline med alle trinnene som kreves for å bygge, optimalisere og distribuere ML-modeller til flåten av enheter. Denne automatiserte pipelinen kan deretter utløses av enkle hendelser du definerer, uten menneskelig innblanding.

Bruk sak 1

La oss si at en flyprodusent ønsker å oppdage og spore deler og verktøy i produksjonshangaren. For å forbedre produktiviteten, må alle nødvendige deler og riktige verktøy være tilgjengelige for ingeniørene på hvert trinn av produksjonen. Vi ønsker å kunne svare på spørsmål som: Hvor er del A? eller Hvor er verktøy B? Vi har flere IP-kameraer allerede installert og koblet til et lokalt nettverk. Kameraene dekker hele hangaren og kan streame sanntids HD-video gjennom nettverket.

AWS Panorama passer fint inn i dette tilfellet. AWS Panorama tilbyr en ML-enhet og administrert tjeneste som lar deg legge til datasyn (CV) til din eksisterende flåte av IP-kameraer og automatisere. AWS Panorama gir deg muligheten til å legge til CV til dine eksisterende Internet Protocol (IP) kameraer og automatisere oppgaver som tradisjonelt krever menneskelig inspeksjon og overvåking.

I den følgende referansearkitekturen viser vi hovedkomponentene i applikasjonen som kjører på en AWS Panorama Appliance. Panorama Application SDK gjør det enkelt å fange video fra kamerastrømmer, utføre slutninger med en pipeline av flere ML-modeller og behandle resultatene ved å bruke Python-kode som kjører inne i en beholder. Du kan kjøre modeller fra et hvilket som helst populært ML-bibliotek som TensorFlow, PyTorch eller TensorRT. Resultatene fra modellen kan integreres med forretningssystemer på ditt lokale nettverk, slik at du kan svare på hendelser i sanntid.

Løsningen består av følgende trinn:

1. Koble til og konfigurer en AWS Panorama-enhet til det samme lokale nettverket.
2. Tren en ML-modell (objektdeteksjon) for å identifisere deler og verktøy i hver ramme.
3. Bygg en AWS Panorama-applikasjon som henter spådommene fra ML-modellen, bruker en sporingsmekanisme på hvert objekt og sender resultatene til en sanntidsdatabase.
4. Operatørene kan sende forespørsler til databasen for å finne delene og verktøyene.

Bruk sak 2

For vår neste brukssituasjon, forestill deg at vi lager et dashcam for kjøretøy som er i stand til å støtte sjåføren i mange situasjoner, for eksempel å unngå fotgjengere, basert på en CV25 brett fra Ambaralla. Å være vert for ML-modeller på en enhet med begrensede systemressurser kan være vanskelig. I dette tilfellet, la oss anta at vi allerede har en veletablert over-the-air (OTA) leveringsmekanisme på plass for å distribuere applikasjonskomponentene som trengs på edge-enheten. Imidlertid vil vi fortsatt dra nytte av muligheten til å utføre OTA-distribusjon av selve modellen, og dermed isolere applikasjonens livssyklus og modelllivssyklus.

Amazon SageMaker Edge Manager og Amazon SageMaker Neo passer godt for denne brukssaken.

Edge Manager gjør det enkelt for ML edge-utviklere å bruke de samme kjente verktøyene i skyen eller på edge-enheter. Det reduserer tiden og innsatsen som kreves for å få modeller til produksjon, samtidig som du kan kontinuerlig overvåke og forbedre modellkvaliteten på tvers av enhetsparken. SageMaker Edge inkluderer en OTA-distribusjonsmekanisme som hjelper deg med å distribuere modeller på flåten uavhengig av applikasjonen eller enhetens fastvare. De Edge Manager-agent lar deg kjøre flere modeller på samme enhet. Agenten samler inn prediksjonsdata basert på logikken du kontrollerer, for eksempel intervaller, og laster dem opp til skyen slik at du med jevne mellomrom kan trene om modellene dine over tid. SageMaker Edge signerer modellene dine kryptografisk slik at du kan verifisere at den ikke ble tuklet med når den beveger seg fra skyen til kantenheten.

Neo er en kompilator som en tjeneste og passer spesielt godt i denne brukssaken. Neo optimerer automatisk ML-modeller for slutninger om skyforekomster og edge-enheter for å kjøre raskere uten tap av nøyaktighet. Du starter med en ML-modell bygget med en av støttede rammer og opplært i SageMaker eller andre steder. Deretter velger du din målmaskinvareplattform, (se listen over støttede enheter). Med et enkelt klikk optimerer Neo den trente modellen og kompilerer den til en pakke som kan kjøres ved hjelp av den lette SageMaker Edge runtime. Kompilatoren bruker en ML-modell for å bruke ytelsesoptimaliseringene som trekker ut den beste tilgjengelige ytelsen for modellen din på skyforekomsten eller edge-enheten. Du distribuerer deretter modellen som et SageMaker-endepunkt eller på støttede edge-enheter og begynner å lage spådommer.

Følgende diagram illustrerer denne arkitekturen.

Løsningsarbeidsflyten består av følgende trinn:

1. Utvikleren bygger, trener, validerer og lager den endelige modellartefakten som må distribueres til dashcam.
2. Påkall Neo for å kompilere den trente modellen.
3. SageMaker Edge-agenten er installert og konfigurert på Edge-enheten, i dette tilfellet dashcam.
4. Opprett en distribusjonspakke med en signert modell og kjøretiden som brukes av SageMaker Edge-agenten for å laste og starte den optimaliserte modellen.
5. Distribuer pakken ved å bruke den eksisterende OTA-distribusjonsmekanismen.
6. Edge-applikasjonen samhandler med SageMaker Edge-agenten for å gjøre slutninger.
7. Agenten kan konfigureres (om nødvendig) til å sende sanntids eksempelinndata fra applikasjonen for modellovervåking og foredlingsformål.

Bruk sak 3

Anta at kunden din utvikler en applikasjon som oppdager uregelmessigheter i mekanismene til en vindturbin (som girkassen, generatoren eller rotoren). Målet er å minimere skadene på utstyret ved å kjøre lokale beskyttelsesprosedyrer i farten. Disse turbinene er svært dyre og plassert på steder som ikke er lett tilgjengelige. Hver turbin kan utstyres med en NVIDIA Jetson-enhet for å overvåke sensordata fra turbinen. Vi trenger da en løsning for å fange opp dataene og bruke en ML-algoritme for å oppdage anomalier. Vi trenger også en OTA-mekanisme for å holde programvaren og ML-modellene på enheten oppdatert.

AWS IoT Greengrass V2 sammen med Edge Manager passer godt i denne brukssaken. AWS IoT Greengrass er en åpen kildekode IoT edge runtime og skytjeneste som hjelper deg med å bygge, distribuere og administrere IoT-applikasjoner på enhetene dine. Du kan bruke AWS IoT Greengrass til å bygge kantapplikasjoner ved å bruke forhåndsbygde programvaremoduler, kalt komponenter, som kan koble edge-enhetene dine til AWS-tjenester eller tredjepartstjenester. Denne evnen til AWS IoT Greengrass gjør det enkelt å distribuere eiendeler til enheter, inkludert en SageMaker Edge-agent. AWS IoT Greengrass er ansvarlig for å administrere applikasjonens livssyklus, mens Edge Manager kobler fra ML-modellens livssyklus. Dette gir deg fleksibiliteten til å fortsette å utvikle hele løsningen ved å distribuere nye versjoner av edge-applikasjonen og ML-modeller uavhengig. Følgende diagram illustrerer denne arkitekturen.

Løsningen består av følgende trinn:

1. Utvikleren bygger, trener, validerer og lager den endelige modellartefakten som må distribueres til vindturbinen.
2. Påkall Neo for å kompilere den trente modellen.
3. Lag en modellkomponent ved å bruke Edge Manager med AWS IoT Greengrass V2-integrasjon.
4. Sett opp AWS IoT Greengrass V2.
5. Lag en slutningskomponent ved å bruke AWS IoT Greengrass V2.
6. Edge-applikasjonen samhandler med SageMaker Edge-agenten for å gjøre slutninger.
7. Agenten kan konfigureres (om nødvendig) til å sende sanntids eksempelinndata fra applikasjonen for modellovervåking og foredlingsformål.

Bruk sak 4

For vår siste brukssituasjon, la oss se på et fartøy som transporterer containere, der hver container har et par sensorer og strømmer et signal til databehandlings- og lagringsinfrastrukturen som er distribuert lokalt. Utfordringen er at vi ønsker å vite innholdet i hver container, og tilstanden til varene basert på temperatur, fuktighet og gasser inne i hver container. Vi ønsker også å spore alle varene i hver av containerne. Det er ingen internettforbindelse under hele reisen, og reisen kan ta måneder. ML-modellene som kjører på denne infrastrukturen bør forhåndsbehandle dataene og generere informasjon for å svare på alle spørsmålene våre. Dataene som genereres må lagres lokalt i flere måneder. Edgeapplikasjonen lagrer alle slutninger i en lokal database og synkroniserer deretter resultatene med skyen når fartøyet nærmer seg havnen.

AWS snøkjegle og AWS snøball fra AWS Snow Family kan passe veldig bra i denne brukssaken.

AWS Snowcone er en liten, robust og sikker kantdatabehandlings- og datamigrasjonsenhet. Snowcone er designet i henhold til OSHA-standarden for en person som kan løftes. Snowcone lar deg kjøre avanserte arbeidsbelastninger ved hjelp av Amazon Elastic Compute Cloud (Amazon EC2) databehandling og lokal lagring i tøffe, frakoblede feltmiljøer som oljerigger, søke- og redningskjøretøyer, militære steder eller fabrikkgulv, samt eksterne kontorer, sykehus og kinoer.

Snowball legger til mer databehandling sammenlignet med Snowcone og kan derfor passe godt for mer krevende applikasjoner. Compute Optimized-funksjonen gir en valgfri NVIDIA Tesla V100 GPU sammen med EC2-instanser for å akselerere en applikasjons ytelse i frakoblede miljøer. Med GPU-alternativet kan du kjøre applikasjoner som avansert ML og full motion videoanalyse i miljøer med liten eller ingen tilkobling.

På toppen av EC2-forekomsten har du friheten til å bygge og distribuere alle typer edge-løsninger. For eksempel: du kan bruke Amazon ECS eller annen containeradministrator for å distribuere edge-applikasjonen, Edge Manager Agent og ML-modellen som individuelle containere. Denne arkitekturen vil ligne Use Case 2 (bortsett fra at den vil fungere offline mesteparten av tiden), med tillegg av et beholderbehandlingsverktøy.

Følgende diagram illustrerer denne løsningsarkitekturen.

For å implementere denne løsningen, bestiller du bare din Snow-enhet fra AWS-administrasjonskonsoll og lanser ressursene dine.

konklusjonen

I dette innlegget diskuterte vi de forskjellige aspektene ved edge som du kan velge å jobbe med basert på din brukssituasjon. Vi diskuterte også noen av nøkkelkonseptene rundt ML@Edge og hvordan frakobling av applikasjonslivssyklusen og ML-modellens livssyklus gir deg friheten til å utvikle dem uten noen avhengighet av hverandre. Vi la vekt på hvordan det å velge riktig kantenhet for arbeidsmengden din og stille de riktige spørsmålene under løsningsprosessen kan hjelpe deg med å jobbe bakover og begrense de riktige AWS-tjenestene. Vi presenterte også ulike brukstilfeller sammen med referansearkitekturer for å inspirere deg til å lage dine egne løsninger som vil fungere for din arbeidsmengde.

---

Om forfatterne

Dinesh Kumar Subramani er en senior løsningsarkitekt med UKIR SMB-teamet, basert i Edinburgh, Skottland. Han spesialiserer seg på kunstig intelligens og maskinlæring. Dinesh liker å jobbe med kunder på tvers av bransjer for å hjelpe dem med å løse problemene deres med AWS-tjenester. Utenom jobben elsker han å tilbringe tid med familien, spille sjakk og nyte musikk på tvers av sjangere.

Samir Araújo er AI/ML Solutions Architect hos AWS. Han hjelper kunder med å lage AI/ML-løsninger som løser deres forretningsutfordringer ved hjelp av AWS. Han har jobbet med flere AI/ML-prosjekter relatert til datasyn, naturlig språkbehandling, prognoser, ML på kanten og mer. Han liker å leke med maskinvare og automatiseringsprosjekter på fritiden, og han har en spesiell interesse for robotikk.

• Myntsmart. Europas beste Bitcoin og Crypto Exchange.
• Platoblokkkjede. Web3 Metaverse Intelligence. Kunnskap forsterket. FRI TILGANG.
• CryptoHawk. Altcoin Radar. Gratis prøveperiode.
• Kilde: https://aws.amazon.com/blogs/machine-learning/demystifying-machine-learning-at-the-edge-through-real-use-cases/