Dette er del 3 av serien vår hvor vi designer og implementerer en MLOps pipeline for visuell kvalitetsinspeksjon på kanten. I dette innlegget fokuserer vi på hvordan man automatiserer edge-distribusjonsdelen av ende-til-ende MLOps-pipeline. Vi viser deg hvordan du bruker AWS IoT Greengrass å håndtere modellslutning på kanten og hvordan automatisere prosessen ved hjelp av AWS trinnfunksjoner og andre AWS-tjenester.
Løsningsoversikt
In Del 1 av denne serien la vi ut en arkitektur for vår ende-til-ende MLOps-pipeline som automatiserer hele maskinlæringsprosessen (ML), fra datamerking til modellopplæring og distribusjon på kanten. I Del 2, viste vi hvordan man automatiserer merkings- og modellopplæringsdelene av rørledningen.
Eksemplet brukt for denne serien er en visuell kvalitetsinspeksjonsløsning som kan oppdage defekter på metalletiketter, som du kan distribuere som en del av en produksjonsprosess. Følgende diagram viser høynivåarkitekturen til MLOps-rørledningen vi definerte i begynnelsen av denne serien. Hvis du ikke har lest den ennå, anbefaler vi å sjekke ut Del 1.
Automatisering av edge-distribusjon av en ML-modell
Etter at en ML-modell har blitt trent og evaluert, må den distribueres til et produksjonssystem for å generere forretningsverdi ved å lage spådommer om innkommende data. Denne prosessen kan fort bli kompleks i en kantsetting der modellene må distribueres og kjøres på enheter som ofte er plassert langt unna skymiljøet som modellene har blitt trent i. Følgende er noen av utfordringene som er unike for maskinlæring på kanten:
- ML-modeller må ofte optimaliseres på grunn av ressursbegrensninger på edge-enheter
- Edge-enheter kan ikke omdistribueres eller til og med erstattes som en server i skyen, så du trenger en robust modelldistribusjon og enhetsadministrasjonsprosess
- Kommunikasjon mellom enheter og skyen må være effektiv og sikker fordi den ofte krysser upålitelige nettverk med lav båndbredde
La oss se hvordan vi kan takle disse utfordringene med AWS-tjenester i tillegg til å eksportere modellen i ONNX-formatet, som lar oss for eksempel bruke optimaliseringer som kvantisering for å redusere modellstørrelsen for begrensningsenheter. ONNX gir også optimaliserte kjøretider for de vanligste maskinvareplattformene.
For å bryte ned edge-distribusjonsprosessen, krever vi to komponenter:
- En distribusjonsmekanisme for modellleveransen, som inkluderer selve modellen og noe forretningslogikk for å administrere og samhandle med modellen
- En arbeidsflytmotor som kan orkestrere hele prosessen for å gjøre dette robust og repeterbart
I dette eksemplet bruker vi forskjellige AWS-tjenester for å bygge vår automatiserte edge-distribusjonsmekanisme, som integrerer alle de nødvendige komponentene vi diskuterte.
For det første simulerer vi en kantenhet. For å gjøre det enkelt for deg å gå gjennom ende-til-ende arbeidsflyten, bruker vi en Amazon Elastic Compute Cloud (Amazon EC2) forekomst for å simulere en edge-enhet ved å installere AWS IoT Greengrass Core-programvaren på forekomsten. Du kan også bruke EC2-instanser til å validere de forskjellige komponentene i en QA-prosess før du distribuerer til en faktisk kantproduksjonsenhet. AWS IoT Greengrass er en Internet of Things (IoT) åpen kildekode edge runtime og skytjeneste som hjelper deg med å bygge, distribuere og administrere edge-enhetsprogramvare. AWS IoT Greengrass reduserer innsatsen for å bygge, distribuere og administrere avansert enhetsprogramvare på en sikker og skalerbar måte. Etter at du har installert AWS IoT Greengrass Core-programvaren på enheten din, kan du legge til eller fjerne funksjoner og komponenter og administrere IoT-enhetsapplikasjonene dine ved å bruke AWS IoT Greengrass. Den tilbyr mange innebygde komponenter for å gjøre livet ditt enklere, for eksempel StreamManager- og MQTT-meglerkomponentene, som du kan bruke til å kommunisere sikkert med skyen, som støtter ende-til-ende-kryptering. Du kan bruke disse funksjonene til å laste opp konklusjonsresultater og bilder effektivt.
I et produksjonsmiljø vil du typisk ha et industrikamera som leverer bilder som ML-modellen skal produsere spådommer for. For oppsettet vårt simulerer vi denne bildeinngangen ved å laste opp en forhåndsinnstilling av bilder til en spesifikk katalog på kantenheten. Vi bruker deretter disse bildene som slutningsinndata for modellen.
Vi delte den overordnede distribusjons- og slutningsprosessen inn i tre påfølgende trinn for å distribuere en sky-trent ML-modell til et edge-miljø og bruke den til spådommer:
- Forbered – Pakk den opplærte modellen for edge-distribusjon.
- Distribuer – Overføring av modell- og slutningskomponenter fra skyen til edge-enheten.
- slutning – Last inn modellen og kjør inferenskode for bildeforutsigelser.
Følgende arkitekturdiagram viser detaljene i denne tre-trinns prosessen og hvordan vi implementerte den med AWS-tjenester.
I de følgende avsnittene diskuterer vi detaljene for hvert trinn og viser hvordan du kan bygge inn denne prosessen i en automatisert og repeterbar orkestrering og CI/CD-arbeidsflyt for både ML-modellene og tilsvarende slutningskode.
Forbered
Edge-enheter kommer ofte med begrenset databehandling og minne sammenlignet med et skymiljø der kraftige CPUer og GPUer enkelt kan kjøre ML-modeller. Ulike modelloptimeringsteknikker lar deg skreddersy en modell for en spesifikk programvare- eller maskinvareplattform for å øke prediksjonshastigheten uten å miste nøyaktigheten.
I dette eksemplet eksporterte vi den trente modellen i treningspipelinen til ONNX-formatet for portabilitet, mulige optimaliseringer, samt optimaliserte kantkjøringstider, og registrerte modellen innenfor Amazon SageMaker modellregister. I dette trinnet oppretter vi en ny Greengrass-modellkomponent inkludert den siste registrerte modellen for påfølgende distribusjon.
Distribuer
En sikker og pålitelig distribusjonsmekanisme er nøkkelen når du distribuerer en modell fra skyen til en edge-enhet. Fordi AWS IoT Greengrass allerede har et robust og sikkert edge-distribusjonssystem, bruker vi dette til våre distribusjonsformål. Før vi ser på distribusjonsprosessen vår i detalj, la oss gjøre en rask oppsummering av hvordan AWS IoT Greengrass-implementeringer fungerer. Kjernen i AWS IoT Greengrass-implementeringssystemet er komponenter, som definerer programvaremodulene som er distribuert til en edge-enhet som kjører AWS IoT Greengrass Core. Disse kan enten være private komponenter som du bygger eller offentlige komponenter som leveres enten av AWS eller det bredere Greengrass-samfunnet. Flere komponenter kan pakkes sammen som en del av en distribusjon. En distribusjonskonfigurasjon definerer komponentene som er inkludert i en distribusjon og distribusjonens målenheter. Den kan enten defineres i en distribusjonskonfigurasjonsfil (JSON) eller via AWS IoT Greengrass-konsollen når du oppretter en ny distribusjon.
Vi lager følgende to Greengrass-komponenter, som deretter distribueres til edge-enheten via distribusjonsprosessen:
- Pakket modell (privat komponent) – Denne komponenten inneholder den opplærte og ML-modellen i ONNX-format.
- Inferenskode (privat komponent) – Bortsett fra selve ML-modellen, må vi implementere litt applikasjonslogikk for å håndtere oppgaver som dataforberedelse, kommunikasjon med modellen for slutning og etterbehandling av slutningsresultater. I vårt eksempel har vi utviklet en Python-basert privat komponent for å håndtere følgende oppgaver:
- Installer de nødvendige kjøretidskomponentene som Ultralytics YOLOv8 Python-pakken.
- I stedet for å ta bilder fra en livestream fra kameraet, simulerer vi dette ved å laste inn forberedte bilder fra en spesifikk katalog og klargjøre bildedataene i henhold til modellens inndatakrav.
- Foreta slutningsanrop mot den lastede modellen med de forberedte bildedataene.
- Sjekk spådommene og last opp slutningsresultater tilbake til skyen.
Hvis du vil ha en dypere titt på inferenskoden vi bygde, kan du se GitHub repo.
slutning
Modellslutningsprosessen på kantenheten starter automatisk etter at utplasseringen av de nevnte komponentene er fullført. Den tilpassede slutningskomponenten kjører med jevne mellomrom ML-modellen med bilder fra en lokal katalog. Inferensresultatet per bilde returnert fra modellen er en tensor med følgende innhold:
- Selvtillit scorer – Hvor sikker modellen er på deteksjonene
- Objektkoordinater – Skrapeobjektkoordinatene (x, y, bredde, høyde) oppdaget av modellen i bildet
I vårt tilfelle sørger slutningskomponenten for å sende slutningsresultater til et spesifikt MQTT-emne på AWS IoT hvor det kan leses for videre behandling. Disse meldingene kan sees via MQTT-testklienten på AWS IoT-konsollen for feilsøking. I en produksjonsinnstilling kan du velge å automatisk varsle et annet system som tar seg av å fjerne defekte metallmerker fra produksjonslinjen.
orkestre
Som sett i de foregående delene, kreves det flere trinn for å forberede og distribuere en ML-modell, den tilsvarende slutningskoden og den nødvendige kjøretiden eller agenten til en edge-enhet. Step Functions er en fullstendig administrert tjeneste som lar deg orkestrere disse dedikerte trinnene og designe arbeidsflyten i form av en tilstandsmaskin. Den serverløse karakteren til denne tjenesten og native Step Functions-funksjoner som AWS service API-integrasjoner lar deg raskt sette opp denne arbeidsflyten. Innebygde funksjoner som gjenforsøk eller logging er viktige punkter for å bygge robuste orkestrasjoner. For flere detaljer om selve tilstandsmaskindefinisjonen, se GitHub repository eller sjekk tilstandsmaskingrafen på Step Functions-konsollen etter at du har implementert dette eksemplet i kontoen din.
Infrastrukturdistribusjon og integrering i CI/CD
CI/CD-rørledningen for å integrere og bygge alle nødvendige infrastrukturkomponenter følger det samme mønsteret illustrert i Del 1 av denne serien. Vi bruker AWS skyutviklingssett (AWS CDK) for å distribuere de nødvendige rørledningene fra AWS CodePipeline.
Læring
Det er flere måter å bygge en arkitektur for et automatisert, robust og sikkert ML-modell edge-distribusjonssystem på, som ofte er veldig avhengig av brukstilfellet og andre krav. Men her er noen lærdommer vi ønsker å dele med deg:
- Vurder på forhånd om tillegget AWS IoT Greengrass dataressurskrav Passer saken din, spesielt med enheter med begrenset kant.
- Etabler en distribusjonsmekanisme som integrerer et verifiseringstrinn av de utplasserte artefaktene før de kjøres på kantenheten for å sikre at ingen tukling skjedde under overføring.
- Det er god praksis å holde distribusjonskomponentene på AWS IoT Greengrass så modulære og selvstendige som mulig for å kunne distribuere dem uavhengig. For eksempel, hvis du har en relativt liten inferenskodemodul, men en stor ML-modell når det gjelder størrelse, vil du ikke alltid distribuere dem begge hvis bare inferenskoden har endret seg. Dette er spesielt viktig når du har begrenset båndbredde eller høykostnadsutstyrstilkobling.
konklusjonen
Dette avslutter vår tredelte serie om å bygge en ende-til-ende MLOps-rørledning for visuell kvalitetsinspeksjon ved kanten. Vi så på tilleggsutfordringene som følger med å distribuere en ML-modell på kanten som modellpakking eller kompleks distribusjonsorkestrering. Vi implementerte rørledningen på en helautomatisert måte slik at vi kan sette modellene våre i produksjon på en robust, sikker, repeterbar og sporbar måte. Bruk gjerne arkitekturen og implementeringen utviklet i denne serien som utgangspunkt for ditt neste ML-aktiverte prosjekt. Hvis du har spørsmål om hvordan du arkitekter og bygger et slikt system for ditt miljø, vennligst nå ut. For andre emner og brukstilfeller, se vår Maskinlæring og IOT blogger.
Om forfatterne
Michael Roth er en senior løsningsarkitekt hos AWS som støtter produksjonskunder i Tyskland for å løse deres forretningsutfordringer gjennom AWS-teknologi. Ved siden av jobb og familie er han interessert i sportsbiler og liker italiensk kaffe.
Jörg Wöhrle er en løsningsarkitekt hos AWS, og jobber med produksjonskunder i Tyskland. Med en lidenskap for automatisering har Joerg jobbet som programvareutvikler, DevOps-ingeniør og Site Reliability Engineer i sitt liv før AWS. Utenfor skyene er han en ambisiøs løper og liker kvalitetstid med familien. Så hvis du har en DevOps-utfordring eller ønsker å løpe: gi ham beskjed.
Johannes Langer er Senior Solutions Architect hos AWS, og jobber med bedriftskunder i Tyskland. Johannes brenner for å bruke maskinlæring for å løse reelle forretningsproblemer. I sitt personlige liv liker Johannes å jobbe med oppussingsprosjekter og tilbringe tid utendørs med familien.
- SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
- PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
- PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
- PlatoESG. Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
- PlatoHelse. Bioteknologisk og klinisk etterretning. Tilgang her.
- kilde: https://aws.amazon.com/blogs/machine-learning/build-an-end-to-end-mlops-pipeline-for-visual-quality-inspection-at-the-edge-part-3/
- : har
- :er
- :hvor
- $OPP
- 150
- 7
- a
- I stand
- Om oss
- Ifølge
- Logg inn
- nøyaktighet
- faktiske
- legge til
- tillegg
- Ytterligere
- avansere
- Etter
- mot
- Agent
- Alle
- tillate
- tillater
- allerede
- også
- alltid
- Amazon
- Amazon EC2
- Amazon Web Services
- ambisiøs
- an
- og
- En annen
- noen
- api
- Søknad
- søknader
- Påfør
- påføring
- arkitektur
- ER
- AS
- side
- At
- automatisere
- Automatisert
- automatiserer
- automatisk
- Automatisering
- borte
- AWS
- AWS IoT Greengrass
- tilbake
- Båndbredde
- BE
- fordi
- bli
- vært
- før du
- Begynnelsen
- foruten
- mellom
- Beyond
- Stor
- blogger
- både
- bredere
- megler
- bygge
- Bygning
- bygget
- innebygd
- buntet
- virksomhet
- men
- by
- Samtaler
- rom
- CAN
- evner
- hvilken
- biler
- saken
- saker
- utfordre
- utfordringer
- endret
- sjekk
- kontroll
- kunde
- Cloud
- kode
- Kaffe
- Kom
- Felles
- kommunisere
- Kommunikasjon
- sammenlignet
- komplekse
- komponent
- komponenter
- Beregn
- trygg
- Konfigurasjon
- Tilkobling
- påfølgende
- Konsoll
- begrensninger
- inneholder
- innhold
- Kjerne
- kjerneprogramvare
- Tilsvarende
- Kostnad
- skape
- Opprette
- skikk
- Kunder
- dato
- Dataklargjøring
- bestemme
- dedikert
- dypere
- definere
- definert
- definerer
- definisjon
- levere
- levering
- avhengig
- utplassere
- utplassert
- utplasserings
- distribusjon
- distribusjoner
- utforming
- detalj
- detaljer
- oppdage
- oppdaget
- utviklet
- Utvikler
- Utvikling
- enhet
- Enheter
- forskjellig
- diskutere
- diskutert
- Divided
- do
- ikke
- ned
- to
- under
- hver enkelt
- enklere
- lett
- Edge
- effektiv
- effektivt
- innsats
- enten
- embed
- kryptering
- ende til ende
- Motor
- ingeniør
- sikre
- Enterprise
- Hele
- Miljø
- spesielt
- evaluert
- Selv
- eksempel
- familie
- langt
- Mote
- defekt
- Egenskaper
- føler
- Noen få
- filet
- passer
- Fokus
- etter
- følger
- Til
- skjema
- format
- Gratis
- fra
- fullt
- funksjoner
- videre
- generere
- Tyskland
- Go
- god
- GPU
- graf
- håndtere
- skjedde
- maskinvare
- Ha
- høyde
- hjelper
- her.
- Høy
- høyt nivå
- ham
- hans
- Hjemprodukt
- Hvordan
- Hvordan
- Men
- HTML
- http
- HTTPS
- if
- bilde
- bilder
- iverksette
- gjennomføring
- implementert
- viktig
- forbedring
- in
- inkludert
- inkluderer
- Inkludert
- Innkommende
- Øke
- uavhengig av hverandre
- industriell
- Infrastruktur
- inngang
- installere
- installere
- f.eks
- integrere
- Integrerer
- integrering
- integrasjoner
- samhandle
- interessert
- Internet
- Internett av ting
- inn
- IOT
- IoT-enhet
- IT
- italiensk
- selv
- jpg
- JSON
- bare
- Hold
- nøkkel
- Vet
- merking
- siste
- læring
- la
- Life
- i likhet med
- Begrenset
- linje
- leve
- laste
- lasting
- lokal
- ligger
- logging
- logikk
- Se
- så
- å miste
- Lot
- maskin
- maskinlæring
- gjøre
- Making
- administrer
- fikk til
- ledelse
- produksjon
- mekanisme
- Minne
- meldinger
- metall
- Michael
- ML
- MLOps
- modell
- modeller
- modulære
- Moduler
- Moduler
- mer
- mest
- flere
- innfødt
- Natur
- Trenger
- behov
- Ny
- neste
- Nei.
- objekt
- of
- Tilbud
- ofte
- on
- åpen kildekode
- optimalisert
- or
- orkestre
- Annen
- vår
- ut
- utendørs
- samlet
- pakke
- emballasje
- del
- deler
- lidenskap
- lidenskapelig
- Mønster
- for
- personlig
- rørledning
- plattform
- Plattformer
- plato
- Platon Data Intelligence
- PlatonData
- vær så snill
- Point
- poeng
- portabilitet
- mulig
- Post
- kraftig
- praksis
- prediksjon
- Spådommer
- forberedelse
- Forbered
- forberedt
- forbereder
- privat
- problemer
- prosess
- prosessering
- produsere
- Produksjon
- prosjekt
- prosjekter
- forutsatt
- gir
- offentlig
- formål
- sette
- Python
- Q & A
- kvalitet
- spørsmål
- Rask
- raskt
- Lese
- ekte
- oppsummering
- anbefaler
- redusere
- reduserer
- referere
- om
- registrert
- relativt
- pålitelighet
- pålitelig
- fjerne
- fjerne
- repeterbar
- erstattet
- krever
- påkrevd
- Krav
- ressurs
- resultere
- Resultater
- robust
- Kjør
- runner
- rennende
- går
- sagemaker
- samme
- skalerbar
- skraper
- seksjoner
- sikre
- sikkert
- se
- sett
- sending
- senior
- Serien
- server
- server~~POS=TRUNC
- tjeneste
- Tjenester
- sett
- innstilling
- oppsett
- Del
- bør
- Vis
- viste
- Viser
- nettstedet
- Størrelse
- liten
- So
- Software
- løsning
- Solutions
- LØSE
- noen
- spesifikk
- fart
- utgifter
- Sports
- Start
- starter
- Tilstand
- Trinn
- Steps
- rett fram
- stream
- senere
- slik
- Støtte
- system
- takle
- tar
- ta
- Target
- oppgaver
- teknikker
- Teknologi
- vilkår
- test
- Det
- De
- Staten
- deres
- Dem
- deretter
- Disse
- ting
- denne
- De
- tre
- tre-trinns
- Gjennom
- tid
- til
- sammen
- Tema
- temaer
- sporbar
- trent
- Kurs
- overføre
- to
- typisk
- unik
- Opplasting
- us
- bruke
- bruk sak
- brukt
- ved hjelp av
- VALIDERE
- verdi
- Verifisering
- veldig
- av
- ønsker
- Vei..
- måter
- we
- web
- webtjenester
- VI VIL
- når
- hvilken
- hele
- bredde
- med
- innenfor
- uten
- Arbeid
- arbeidet
- arbeidsflyt
- arbeid
- ville
- X
- ennå
- Du
- Din
- zephyrnet