Dette blogginnlegget er skrevet av Jonathan Lee, Nelson Leung, Paul Min og Troy Squillaci fra Intel.
In Del 1 i dette innlegget diskuterte vi hvordan Intel®3DAT samarbeidet med AWS Machine Learning Professional Services (MLPS) for å bygge en skalerbar AI SaaS-applikasjon. 3DAT bruker datasyn og AI for å gjenkjenne, spore og analysere over 1,000 biomekaniske datapunkter fra standard video. Den lar kundene lage rike og kraftige biomekanikkdrevne produkter, som nett- og mobilapplikasjoner med detaljerte ytelsesdata og tredimensjonale visualiseringer.
I del 2 av dette innlegget dykker vi dypere inn i hvert trinn i arkitekturen. Vi utforsker AWS-tjenestene som brukes for å oppfylle 3DAT-designkravene, inkludert Amazon Kinesis datastrømmer og Amazon Elastic Kubernetes-tjeneste (Amazon EKS), for å skalerbart distribuere de nødvendige poseestimeringsmodellene for denne programvaren som en tjeneste (SaaS)-applikasjon.
Arkitekturoversikt
Det primære målet til MLPS-teamet var å produksjonalisere 2D- og 3D-posisjonsestimatmodellene og lage en funksjonell og skalerbar applikasjon. Følgende diagram illustrerer løsningsarkitekturen.
Den komplette arkitekturen er delt inn i fem hovedkomponenter:
- Brukerapplikasjonsgrensesnittlag
- Database
- Arbeidsflyt orkestrering
- Generering av skalerbar posisjonsestimatisering
- Driftsovervåking
La oss gå i detalj på hver komponent, deres interaksjoner og begrunnelsen bak designvalgene.
Brukerapplikasjonsgrensesnittlag
Følgende diagram viser applikasjonsgrensesnittlagene som gir brukertilgang og kontroll over applikasjonen og dens ressurser.
Disse tilgangspunktene støtter ulike brukstilfeller basert på ulike kundepersonligheter. For eksempel kan en applikasjonsbruker sende inn en jobb via CLI, mens en utvikler kan bygge en applikasjon ved å bruke Python SDK og legge inn posisjonsestimatintelligens i applikasjonene sine. CLI og SDK er bygget som modulære komponenter – begge lagene er omslag av API-laget, som er bygget ved å bruke Amazon API-gateway for å løse API-kallene og tilhørende AWS Lambda funksjoner, som tar seg av backend-logikken knyttet til hvert API-kall. Disse lagene var en avgjørende komponent for Intel OTG-teamet fordi det åpner opp en bred base av kunder som effektivt kan bruke denne SaaS-applikasjonen.
API-lag
Løsningen har et kjernesett med ni APIer, som tilsvarer typene objekter som opererer på denne plattformen. Hver API har en Python-fil som definerer API-handlingene som kan kjøres. Opprettelsen av nye objekter blir automatisk tildelt en objekt-ID sekvensielt. Attributtene til disse objektene lagres og spores i Amazon Aurora Serverløs database ved hjelp av denne IDen. Derfor knytter API-handlingene seg tilbake til funksjoner som er definert i en sentral fil som inneholder backend-logikken for spørring i Aurora-databasen. Denne backend-logikken bruker Boto3 Amazon RDS DataService-klient for å få tilgang til databaseklyngen.
Det ene unntaket er /job
API, som har en create_job
metode som håndterer videoinnsending for å opprette en ny behandlingsjobb. Denne metoden starter AWS trinnfunksjoner arbeidsflytlogikk for å kjøre jobben. Ved å bestå i en job_id
, bruker denne metoden Boto3 Step Functions klient å ringe start_execution
metode for en spesifisert stateMachineARN
(Amazon Resource Name).
De åtte objekt-API-ene har metodene og lignende tilgangsmønster som er oppsummert i følgende tabell.
Metodetype | Funksjonsnavn | Beskrivelse |
GET | list_[object_name]s |
Velger alle objekter av denne typen fra databasen og viser. |
POST | create_[object] |
Setter inn en ny objektpost med nødvendige inndata i databasen. |
GET | get_[object] |
Velger objektattributter basert på objekt-ID fra databasen og viser. |
PUT | update_[object] |
Oppdaterer en eksisterende objektpost med de nødvendige inngangene. |
SLETT | delete_[object] |
Sletter en eksisterende objektpost fra databasen basert på objekt-ID. |
Detaljene til de ni API-ene er som følger:
- /bruker – En bruker er identiteten til noen som er autorisert til å sende inn jobber til denne søknaden. Opprettelsen av en bruker krever et brukernavn, bruker-e-postadresse og gruppe-ID som brukeren tilhører.
- /brukergruppe – En brukergruppe er en samling brukere. Hver brukergruppe er tilordnet ett prosjekt og ett pipeline-parametersett. For å ha ulike nivåer (når det gjelder infrastrukturressurser og rørledningsparametere), deles brukerne inn i brukergrupper. Hver bruker kan kun tilhøre én brukergruppe. Opprettelsen av en brukergruppe krever en prosjekt-ID, pipeline-parametersett-ID, brukergruppenavn og brukergruppebeskrivelse. Merk at brukergrupper er forskjellige fra brukerroller definert i AWS-kontoen. Sistnevnte brukes til å gi ulike tilgangsnivåer basert på deres tilgangsroller (for eksempel admin).
- /prosjekt – Et prosjekt brukes til å gruppere ulike sett med infrastrukturelle ressurser. Et prosjekt er knyttet til en enkelt
project_cluster_url
(Aurora-klynge) for å registrere brukere, jobber og andre metadata, enproject_queue_arn
(Kinesis Data Streams ARN), og et databehandlingsmiljø (for øyeblikket kontrollert via Cortex) som brukes til å kjøre slutninger om rammebatchene eller etterbehandling på videoene. Hver brukergruppe er knyttet til ett prosjekt, og denne mekanismen er hvordan forskjellige nivåer aktiveres når det gjelder ventetid og datakraft for forskjellige brukergrupper. Opprettelsen av et prosjekt krever et prosjektnavn, prosjektklynge-URL og prosjektkø ARN. - /rørledning – En pipeline er assosiert med en enkelt konfigurasjon for en sekvens av prosesseringsbeholdere som utfører videobehandling i Amazon EKS-inferensgenereringsklyngen koordinert av Cortex (se avsnittet om videobehandlingsslutningsgenerering for flere detaljer). Vanligvis består dette av tre beholdere: forbehandling og dekoding, gjenstandsdeteksjon og positur-estimering. For eksempel er dekodings- og objektdeteksjonstrinnet det samme for 2D- og 3D-rørledningene, men å bytte ut den siste beholderen ved å bruke enten HRNet eller 3DMPPE resulterer i parametersettet for 2D vs. 3D-behandlingsrørledninger. Du kan opprette nye konfigurasjoner for å definere mulige rørledninger som kan brukes til prosessering, og det krever som input en ny Python-fil i Cortex-repoen som beskriver sekvensen av modellendepunkter som definerer den rørledningen (se avsnittet om generering av videobehandlingsslutninger ). Rørledningsendepunktet er Cortex-endepunktet som kalles for å behandle en enkelt ramme. Opprettelsen av en rørledning krever et rørledningsnavn, rørledningsbeskrivelse og rørledningsendepunkt.
- /pipeline_parameter_set – Et pipeline-parametersett er en fleksibel JSON-samling av flere parametere (en pipeline-konfigurasjonskjøring) for en bestemt pipeline, og legges til for å gi fleksibilitet for fremtidig tilpasning når det kreves flere pipeline-konfigurasjonskjøringer. Brukergrupper kan knyttes til et bestemt pipeline-parametersett, og formålet er å ha forskjellige grupper med parametere per brukergruppe og per pipeline. Dette var et viktig fremtidsrettet tillegg for Intel OTG for å bygge inn tilpasning som støtter portabilitet når forskjellige kunder, spesielt ISV-er, begynner å bruke applikasjonen.
- /pipeline_parameters – En enkelt samling av pipeline-parametere er en instansiering av et pipeline-parametersett. Dette gjør det til en 1:mange-tilordning av et pipeline-parametersett til pipeline-parametere. Denne APIen krever en rørlednings-ID for å assosieres med settet med rørledningsparametere som gjør det mulig å opprette en rørledning for en 1:1-tilordning av rørledningsparametere til rørledningen. De andre inngangene som kreves av denne APIen er en pipeline-parametersett-ID, pipeline-parameterverdi og pipeline-parameternavn.
- /video – Et videoobjekt brukes til å definere individuelle videoer som utgjør en .zip-pakke som sendes inn under en jobb. Denne filen er delt opp i flere videoer etter innsending. En video er relatert til
job_id
for jobben der .zip-pakken sendes inn, og Amazon enkel lagringstjeneste (Amazon S3)-baner for plasseringen av de råseparerte videoene og etterbehandlingsresultatene for hver video. Videoobjektet inneholder også en videofremdriftsprosent, som oppdateres konsekvent under behandling av individuelle framebatcher av den videoen, samt et videostatusflagg for fullstendig eller ikke fullført. Opprettelsen av en video krever en jobb-ID, videobane, videoresultatbane, videofremdriftsprosent og videostatus. - /ramme_batch - A
frame_batch
objekt er en mini-batch med rammer opprettet ved å prøve en enkelt video. Å separere en video i rammepartier i vanlig størrelse gir en spak for å justere latens og øker parallellisering og gjennomstrømning. Dette er den granulære enheten som kjøres gjennom Kinesis Data Streams for slutning. En opprettelse av en frame batch krever en video-ID, frame batch startnummer, frame batch sluttnummer, frame batch input bane, frame batch resultat bane og frame batch status. - /jobb – Dette interaksjons-APIet brukes til filinnsending for å starte en behandlingsjobb. Denne API-en har en annen funksjon enn andre objekt-API-er fordi den er den direkte banen for å samhandle med videobehandlingens backend Step Functions arbeidsflytkoordinering og Amazon EKS-klyngen. Denne APIen krever en bruker-ID, prosjekt-ID, pipeline-ID, pipeline-parametersett-ID, jobbparametere og jobbstatus. I jobbparameterne er det spesifisert en inngangsfilbane, som er plasseringen i Amazon S3 hvor .zip-pakken med videoer som skal behandles er plassert. Filopplasting håndteres med
upload_handler
metode, som genererer en forhåndsdefinert S3 URL for brukeren å plassere en fil. En WORKFLOW_STATEMACHINE_ARN er en miljøvariabel som sendes tilcreate_job
API for å spesifisere hvor en video .zip-pakke med en inngangsfilbane sendes inn for å starte en jobb.
Tabellen nedenfor oppsummerer API-funksjonene.
Metodetype | Funksjon | Beskrivelse |
GET | list_jobs |
Velger alle jobber fra databasen og viser. |
POST | create_ job |
Setter inn en ny jobbpost med bruker-ID, prosjekt-ID, pipeline-ID, pipeline-parametersett-ID, jobbresultatbane, jobbparametere og jobbstatus. |
GET | get_ job |
Velger jobbattributter basert på jobb-ID fra databasen og viser. |
GET | upload_handler |
Genererer en forhåndsdefinert S3-URL som plassering for .zip-filopplastingen. Krever et S3-bøttenavn og forventer en applikasjons-/zip-filtype. |
Python SDK-lag
Med utgangspunkt i API-ene opprettet teamet et Python SDK-klientbibliotek som en innpakning for å gjøre det enklere for utviklere å få tilgang til API-metodene. De brukte åpen kildekode Poesi, som håndterer Python-pakking og avhengighetsstyring. De opprettet en client.py
fil som inneholder funksjoner som omslutter hver av API-ene ved hjelp av Python requests
bibliotek for å håndtere API-forespørsler og unntak.
For at utviklere skal lansere Intel 3DAT SDK, må de installere og bygge Poetry-pakken. Deretter kan de legge til en enkel Python-import av intel_3dat_sdk
til hvilken som helst Python-kode.
For å bruke klienten kan du opprette en forekomst av klienten, og spesifisere API-endepunktet:
Du kan deretter bruke klienten til å kalle de individuelle metodene som f.eks create_pipeline
metode (se følgende kode), og tar inn de riktige argumentene som rørledningsnavn og rørledningsbeskrivelse.
CLI lag
På samme måte bygde teamet på API-ene for å lage et kommandolinjegrensesnitt for brukere som ønsker å få tilgang til API-metodene med et enkelt grensesnitt uten å måtte skrive Python-kode. De brukte åpen kildekode Python-pakken Klikk (Opprettingssett for kommandolinjegrensesnitt). Fordelene med dette rammeverket er vilkårlig nesting av kommandoer, automatisk hjelpesidegenerering og støtte for lat lasting av underkommandoer under kjøring. I den samme client.py
fil som i SDK, ble hver SDK-klientmetode pakket med Click og de nødvendige metodeargumentene ble konvertert til kommandolinjeflagg. Flagginngangene brukes da når SDK-kommandoen kalles.
For å starte CLI, kan du bruke CLI configure
kommando. Du blir bedt om endepunkts-URL:
Nå kan du bruke CLI til å kalle forskjellige kommandoer relatert til API-metodene, for eksempel:
Database
Som en database bruker denne applikasjonen Aurora Serverless til å lagre metadata knyttet til hver av APIene med MYSQL som databasemotor. Å velge Aurora Serverless-databasetjenesten overholder designprinsippet for å minimere infrastrukturelle overhead ved å bruke serverløse AWS-tjenester når det er mulig. Følgende diagram illustrerer denne arkitekturen.
De serverløs motormodus oppfyller det intermitterende bruksmønsteret fordi denne applikasjonen skaleres opp til nye kunder og arbeidsmengdene fortsatt er usikre. Når du starter et databaseendepunkt, er det ikke nødvendig med en spesifikk DB-forekomststørrelse, bare et minimums- og maksimumsområde for klyngekapasitet. Aurora Serverless håndterer passende klargjøring av en ruterflåte og fordeler arbeidsmengden mellom ressursene. Aurora Serverless utfører automatisk sikkerhetskopiering i minimum 1 dag opptil 35 dager. Teamet optimaliserte for sikkerhet ved å sette standarden til maksimalverdien på 35.
I tillegg brukte teamet Data API for å håndtere tilgang til Aurora Serverless-klyngen, som ikke krever en vedvarende tilkobling, og i stedet gir et sikkert HTTP-endepunkt og integrasjon med AWS SDK-er. Denne funksjonen bruker AWS Secrets Manager for å lagre databaselegitimasjonen slik at det ikke er nødvendig å eksplisitt gi legitimasjon. CREATE TABLE-skript ble skrevet i .sql-filer for hver av de ni tabellene som tilsvarer de ni API-ene. Fordi denne databasen inneholdt alle metadataene og tilstanden til objekter i systemet, ble API-metodene kjørt med de riktige SQL-kommandoene (for eksempel select * from Job
for list_jobs
API) og sendt til execute_statement
metode fra Amazon RDS-klienten i Data API.
Arbeidsflyt orkestrering
Den funksjonelle ryggraden i applikasjonen ble håndtert ved hjelp av Step Functions for å koordinere arbeidsflyten, som vist i følgende diagram.
Statsmaskinen besto av en sekvens av fire Lambda-funksjoner, som starter når en jobb sendes inn ved hjelp av create_job
metoden fra job
API. Bruker-ID, prosjekt-ID, pipeline-ID, pipeline-parametersett-ID, jobbresultatbane, jobbparametere og jobbstatus kreves for å opprette jobb. Du kan først laste opp en .zip-pakke med videofiler ved å bruke upload_handler
metode fra jobb-API for å generere en forhåndsdefinert S3-URL. Under jobbinnsending sendes inndatafilbanen via jobbparameterne for å spesifisere plasseringen til filen. Dette starter kjøringen av arbeidsflytstatusmaskinen, og utløser fire hovedtrinn:
- Initializer Lambda funksjon
- Innsender Lambda funksjon
- Fullføring Sjekk Lambda-funksjonen
- Collector Lambda funksjon
Initializer Lambda funksjon
Hovedfunksjonen til Initializer er å skille .zip-pakken i individuelle videofiler og forberede dem for innsenderen. Først lastes .zip-filen ned, og deretter pakkes hver enkelt fil, inkludert videofiler, ut og pakkes ut. Videoene, fortrinnsvis i .mp4-format, lastes opp tilbake til en S3-bøtte. Bruker create_video
metode i video
API, et videoobjekt opprettes med videobanen som input. Dette setter inn data om hver video i Aurora-databasen. Alle andre filtyper, for eksempel JSON-filer, betraktes som metadata og lastes opp på samme måte, men det opprettes ikke noe videoobjekt. En liste over navnene på filer og videofiler som er pakket ut, sendes til neste trinn.
Innsender Lambda funksjon
Innsender-funksjonen tar videofilene som ble trukket ut av initialisereren og lager mini-batcher med videorammer som bilder. De fleste nåværende datamaskinsynsmodeller i produksjon har blitt trent på bilder, så selv når video behandles, blir de først delt inn i bilderammer før modellslutning. Denne nåværende løsningen som bruker en toppmoderne poseestimeringsmodell er ikke annerledes – rammegruppene fra senderen sendes til Kinesis Data Streams for å starte inferensgenereringstrinnet.
Først lastes videofilen ned av Lambda-funksjonen. Bildefrekvensen og antall bilder beregnes ved å bruke FileVideoStream
modul fra imutils.video
behandlingsbibliotek. Rammene trekkes ut og grupperes i henhold til en spesifisert mini-batchstørrelse, som er en av nøkkelparameterne for denne rørledningen. Ved å bruke Python pickle-biblioteket blir dataene serialisert og lastet opp til Amazon S3. Deretter opprettes et frame batch-objekt og metadataoppføringen opprettes i Aurora-databasen. Denne Lambda-funksjonen ble bygget ved hjelp av en Dockerfile med avhengigheter på opencv-python
, numpy
og imutils
biblioteker.
Fullføring Sjekk Lambda-funksjonen
Fullføringssjekk-funksjonen fortsetter å spørre Aurora-databasen for å se, for hver video i .zip-pakken for denne nåværende jobben, hvor mange framebatcher som er i FULLFØRT-statusen. Når alle frame batcher for alle videoer er fullført, er denne kontrollprosessen fullført.
Collector Lambda funksjon
Collector-funksjonen tar utdataene fra slutningene som ble utført på hver frame under forbrukerstadiet og kombinerer dem på tvers av en rammebatch og på tvers av en video. De kombinerte sammenslåtte dataene lastes deretter opp til en S3-bøtte. Funksjonen påkaller deretter Cortex etterbehandlings-API for en bestemt ML-pipeline for å utføre eventuelle etterbehandlingsberegninger, og legger til de aggregerte resultatene via video til utdatabøtten. Mange av disse beregningene beregnes på tvers av rammer, for eksempel hastighet, akselerasjon og leddvinkel, så denne beregningen må utføres på de aggregerte dataene. De viktigste utdataene inkluderer hovedpunktdata (samlet i CSV-format), BMA-beregninger (som akselerasjon) og visuell overlegg av nøkkelpunkter lagt til hver ramme i en bildefil.
Generering av skalerbar posisjonsestimatisering
Behandlingsmotoren som driver skaleringen av ML-inferens skjer i dette stadiet. Det involverer tre hoveddeler, hver med sine egne samtidighetsspaker som kan stilles inn for latensavveininger (se følgende diagram).
Denne arkitekturen gir mulighet for eksperimentering med å teste latensgevinster, samt fleksibilitet for fremtiden når arbeidsbelastninger kan endres med ulike blandinger av sluttbrukersegmenter som får tilgang til applikasjonen.
Kinesis datastrømmer
Teamet valgte Kinesis Data Streams fordi det vanligvis brukes til å håndtere strømmedata, og i dette tilfellet passer det godt fordi det kan håndtere rammebatcher på en lignende måte for å gi skalerbarhet og parallellisering. I Submitter Lambda-funksjonen brukes Kinesis Boto3-klienten, med put_record
metode som sender inn metadataene knyttet til en enkelt frame batch, slik som frame batch ID, frame batch startramme, frame batch sluttframe, bildeform, bildefrekvens og video ID.
Vi definerte forskjellige jobbkø- og Kinesis-datastrømkonfigurasjoner for å angi nivåer av gjennomstrømning som knytter seg tilbake til prioritetsnivået til forskjellige brukergrupper. Tilgang til ulike nivåer av prosessorkraft kobles ved å sende en prosjektkø ARN når du oppretter et nytt prosjekt ved hjelp av project
API. Hver brukergruppe blir deretter knyttet til et bestemt prosjekt under opprettelsen av brukergruppen. Tre standard strømkonfigurasjoner er definert i AWS-serverløs applikasjonsmodell (AWS SAM) infrastrukturmal:
- standard -
JobStreamShardCount
- Prioritet -
PriorityJobStreamShardCount
- Høy prioritet -
HighPriorityJobStreamShardCount
Teamet brukte noen få forskjellige spaker for å differensiere prosessorkraften til hver strøm eller justere latensen til systemet, som oppsummert i følgende tabell.
spaken | Beskrivelse | Standardverdi |
Shard | En shard er hjemmehørende i Kinesis Data Streams; det er basisenheten for gjennomstrømning for inntak. Standard er 1MB/sek, som tilsvarer 1,000 dataposter per sekund. | 2 |
KinesisBatchSize |
Maksimalt antall poster som Kinesis Data Streams henter i en enkelt batch før påkalling av lambda-funksjonen. | 1 |
KinesisParallelizationFactor |
Antall partier som skal behandles fra hvert shard samtidig. | 1 |
Forbedret fan-out | Dataforbrukere som har forbedret fan-out aktivert, har en dedikert inntaksgjennomstrømning per forbruker (som standard 1 MB/sek.) i stedet for å dele gjennomstrømming mellom forbrukere. | Av |
Forbruker Lambda funksjon
Fra perspektivet til Kinesis Data Streams er en dataforbruker en AWS-tjeneste som henter data fra en datastrømshard mens data genereres i en strøm. Denne applikasjonen bruker en Consumer Lambda-funksjon, som aktiveres når meldinger sendes fra datastrømkøene. Hver forbrukerfunksjon behandler én rammebatch ved å utføre følgende trinn. Først ringes det synkront til Cortex-prosessor-APIet, som er endepunktet som er vert for modellslutningspipelinen (se neste avsnitt om Amazon EKS med Cortex for flere detaljer). Resultatene lagres i Amazon S3, og det gjøres en oppdatering av databasen ved å endre statusen til den behandlede rammebatchen til Complete
. Feilhåndtering er innebygd for å administrere Cortex API-kallet med en prøvesløyfe for å håndtere eventuelle 504-feil fra Cortex-klyngen, med antall gjenforsøk satt til 5.
Amazon EKS med Cortex for ML-inferens
Teamet brukte Amazon EKS, en administrert Kubernetes-tjeneste i AWS, som beregningsmotor for ML-inferens. Et designvalg ble tatt for å bruke Amazon EKS til å være vert for ML-endepunkter, noe som gir fleksibiliteten til å kjøre oppstrøms Kubernetes med mulighet for klynger som begge er fullstendig administrert i AWS via AWS Fargate, eller lokal maskinvare via Amazon EKS hvor som helst. Dette var en kritisk del av funksjonalitet ønsket av Intel OTG, som ga muligheten til å koble denne applikasjonen til spesialisert maskinvare på stedet, for eksempel.
De tre ML-modellene som var byggesteinene for å konstruere inferensrørledningene var en tilpasset Yolo-modell (for objektdeteksjon), en tilpasset HRNet-modell (for 2D-positurestimering) og en 3DMPPE-modell (for 3D-positurestimering) (se forrige ML-seksjonen for mer informasjon). De brukte åpen kildekode Cortex bibliotek for å håndtere distribusjon og administrasjon av ML-inferenspipeline-endepunkter, og lansering og distribusjon av Amazon EKS-klynger. Hver av disse modellene ble pakket inn i Docker-beholdere - modellfiler ble lagret i Amazon S3 og modellbilder ble lagret i Amazon Elastic Container Registry (Amazon ECR) – og distribuert som Cortex Realtime APIer. Versjoner av modellbeholderne som kjører på CPU og GPU ble laget for å gi fleksibilitet for typen datamaskinvare. I fremtiden, hvis flere modeller eller modellrørledninger må legges til, kan de ganske enkelt lage flere Cortex Realtime APIer.
De konstruerte deretter inferensrørledninger ved å komponere Cortex Realtime-modell-API-ene til Cortex Realtime-pipeline-APIer. En enkelt Realtime pipeline API besto av å kalle en sekvens av Realtime modell APIer. Forbruker Lambda-funksjonene behandlet en pipeline
API som en svart boks, ved å bruke et enkelt API-kall for å hente den endelige slutningsutgangen for et bilde. To rørledninger ble opprettet: en 2D-rørledning og en 3D-rørledning.
2D-pipelinen kombinerer et dekodingsforbehandlingstrinn, objektdeteksjon ved hjelp av en tilpasset Yolo-modell for å lokalisere utøveren og produsere grensebokser, og til slutt en tilpasset HRNet-modell for å lage 2D-nøkkelpunkter for positur-estimering.
3D-pipelinen kombinerer et dekodingsforbehandlingstrinn, objektdeteksjon ved hjelp av en tilpasset Yolo-modell for å lokalisere utøveren og produsere grensebokser, og til slutt en 3DMPPE-modell for å lage 3D-nøkkelpunkter for positur-estimering.
Etter å ha generert konklusjoner på en batch med rammer, inkluderer hver rørledning også et separat etterbehandlingsendepunkt i sanntid Cortex som genererer tre hovedutganger:
- Aggregerte hovednøkkel peker data inn i én enkelt CSV-fil
- BMA-beregninger (som akselerasjon)
- Visuelt overlegg av nøkkelpunkter lagt til hver ramme i en bildefil
Collector Lambda-funksjonen sender de riktige metadataene knyttet til en bestemt video, slik som bilde-ID-ene og S3-plasseringene til posisjonsestimatinferensutgangene, til endepunktet for å generere disse etterbehandlingsutdataene.
Cortex er designet for å integreres med Amazon EKS, og krever kun en klyngekonfigurasjonsfil og en enkel kommando for å starte en Kubernetes-klynge:
En annen spak for ytelsesinnstilling var forekomstkonfigurasjonen for dataklyngene. Tre lag ble opprettet med varierende blandinger av M5- og G4dn-forekomster, kodifisert som .yaml-filer med spesifikasjoner som klyngenavn, region og forekomstkonfigurasjon og -miks. M5-forekomster er CPU-baserte med lavere kostnader og G4dn er GPU-baserte med høyere kostnader for å gi noen avveininger mellom kostnad og ytelse.
Driftsovervåking
For å opprettholde operative loggingsstandarder inkluderer alle Lambda-funksjoner kode for å registrere og innta logger via Amazon Kinesis Data Firehose. For eksempel logges hver rammebatch som behandles fra Sender Lambda-funksjonen med tidsstempelet, navnet på handlingen og Lambda-funksjonssvaret JSON og lagres i Amazon S3. Følgende diagram illustrerer dette trinnet i arkitekturen.
Utplassering
Utrullingen håndteres ved hjelp av AWS SAM, et åpen kildekode-rammeverk for å bygge serverløse applikasjoner i AWS. AWS SAM gjør det mulig å kodifisere infrastrukturdesign, inkludert funksjoner, APIer, databaser og hendelseskildetilordninger, og enkelt distribueres i nye AWS-miljøer. Under distribusjon blir AWS SAM-syntaksen oversatt til AWS skyformasjon for å håndtere infrastrukturen.
A template.yaml
filen inneholder infrastrukturspesifikasjonene sammen med justerbare parametere, for eksempel Kinesis Data Streams latency spaker beskrevet i de foregående avsnittene. EN samconfig.toml
filen inneholder distribusjonsparametere som stabelnavn, S3-bøttenavn der applikasjonsfiler som Lambda-funksjonskode er lagret, og ressurskoder for sporingskostnader. Et deploy.sh shell-skript med de enkle kommandoene er alt som kreves for å bygge og distribuere hele malen:
Brukerarbeidsflyt
For å oppsummere, etter at infrastrukturen har blitt distribuert, kan du følge denne arbeidsflyten for å komme i gang:
- Opprett en Intel 3DAT-klient ved å bruke klientbiblioteket.
- Bruk API-en til å lage en ny forekomst av en rørledning som tilsvarer den nødvendige behandlingstypen, for eksempel en for 3D-positurestimering.
- Opprett en ny forekomst av et prosjekt, passerer i cluster ARN og Kinesis køen ARN.
- Opprett en ny forekomst av et pipeline-parametersett.
- Opprett en ny forekomst av pipeline-parametere som tilordnes til pipeline-parametersettet.
- Opprett en ny brukergruppe som er knyttet til en prosjekt-ID og en pipeline-parametersett-ID.
- Opprett en ny bruker som er tilknyttet brukergruppen.
- Last opp en .zip-fil med videoer til Amazon S3 ved å bruke en forhåndsdefinert S3-URL generert av opplastingsfunksjonen i jobb-API.
- Send inn en
create_job
API-kall, med jobbparametere som spesifiserer plassering av videofilene. Dette starter behandlingsjobben.
konklusjonen
Applikasjonen er nå live og klar til å bli testet med både idrettsutøvere og trenere. Intel OTG er glade for å gjøre nyskapende positur-estimeringsteknologi ved hjelp av datasyn tilgjengelig for en rekke brukere, fra utviklere til idrettsutøvere til partnere fra programvareleverandører.
AWS-teamet brenner for å hjelpe kunder som Intel OTG med å akselerere deres ML-reise, fra idé- og oppdagelsesstadiet med ML Solutions Lab til herdings- og distribusjonsstadiet med AWS ML ProServe. Vi vil alle følge nøye med på OL i Tokyo i 2021 denne sommeren for å se for oss all fremgangen som ML kan låse opp innen sport.
Kom i gang i dag! Utforsk brukssaken din med tjenestene nevnt i dette innlegget og mange andre på AWS-administrasjonskonsoll.
Om forfatterne
Han mann er Senior Manager- Machine Learning & AI hos AWS med base i San Diego, CA. Han har en doktorgrad i ingeniørfag fra Northwestern University og har flere års erfaring som ledelseskonsulent med rådgivning til kunder innen produksjon, finansielle tjenester og energi. I dag jobber han lidenskapelig med kunder fra en rekke bransjer for å utvikle og implementere maskinlæring og AI-løsninger på AWS. Han liker å følge NBA og spille basketball på fritiden.
Iman Kamyabi er en ML-ingeniør med AWS Professional Services. Han har jobbet med et bredt spekter av AWS-kunder for å fremme beste praksis for å sette opp repeterbare og pålitelige ML-rørledninger.
Jonathan Lee er direktør for Sports Performance Technology, Olympic Technology Group i Intel. Han studerte anvendelsen av maskinlæring til helse som en undergrad ved UCLA og under utdannelsesarbeidet ved University of Oxford. Karrieren hans har fokusert på algoritme- og sensorutvikling for helse og menneskelig ytelse. Han leder nå 3D Athlete Tracking-prosjektet hos Intel.
Nelson Leung er plattformarkitekt i Sports Performance CoE hos Intel, hvor han definerer end-to-end arkitektur for banebrytende produkter som forbedrer atletens ytelse. Han leder også implementering, distribusjon og produktisering av disse maskinlæringsløsninger i stor skala til forskjellige Intel-partnere.
Troy Squillaci er DecSecOps-ingeniør hos Intel hvor han leverer profesjonelle programvareløsninger til kunder gjennom DevOps beste praksis. Han liker å integrere AI-løsninger i skalerbare plattformer i en rekke domener.
Paul Min er en Associate Solutions Architect Intern hos Amazon Web Services (AWS), hvor han hjelper kunder på tvers av ulike bransjevertikaler med å fremme sitt oppdrag og akselerere deres skyadopsjon. Tidligere hos Intel jobbet han som Software Engineering Intern for å hjelpe til med å utvikle 3D Athlete Tracking Cloud SDK. Utenom jobben liker Paul å spille golf og kan høres synge.
- 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/the-intel3d-athlete-tracking-3dat-scalable-architecture-deploys-pose-estimation-models-using-amazon-kinesis-data-streams- og-amazon-eks/
- "
- &
- 000
- 100
- 2021
- 3d
- Om oss
- akselerere
- adgang
- tilgjengelig
- Ifølge
- Logg inn
- tvers
- Handling
- handlinger
- tillegg
- Ytterligere
- admin
- Adopsjon
- AI
- algoritme
- Alle
- Amazon
- Amazon Web Services
- blant
- api
- APIer
- Søknad
- søknader
- hensiktsmessig
- arkitektur
- argumenter
- tildelt
- Førsteamanuensis
- idrettsutøvere
- attributter
- Automatisk
- AWS
- Backup
- basketball
- før du
- Fordeler
- BEST
- beste praksis
- Svart
- Blogg
- kroppen
- Eske
- bygge
- Bygning
- ring
- Kapasitet
- hvilken
- Karriere
- saker
- sentral
- Champion
- endring
- valg
- klienter
- Cloud
- kode
- samling
- oppsamler
- kombinert
- komponent
- Beregn
- datamaskin
- Konfigurasjon
- tilkobling
- konsulent
- forbruker
- Forbrukere
- Container
- Containere
- inneholder
- fortsetter
- kontroll
- koordinere
- Kjerne
- Tilsvarende
- skape
- opprettet
- skaper
- Opprette
- skaperverket
- Credentials
- kritisk
- avgjørende
- Gjeldende
- I dag
- skikk
- kunde
- Kunder
- skjærekant
- dato
- Database
- databaser
- dag
- dedikert
- dypere
- leverer
- utplassere
- utplassert
- distribusjon
- Distribueres
- utforming
- designet
- detalj
- detaljert
- detaljer
- Gjenkjenning
- utvikle
- Utvikler
- utviklere
- Utvikling
- forskjellig
- differensiere
- direkte
- Regissør
- Funnet
- skjermer
- Docker
- ikke
- domener
- ned
- under
- lett
- emalje
- Endpoint
- energi
- Motor
- ingeniør
- Ingeniørarbeid
- Miljø
- Event
- eksempel
- opphisset
- eksisterende
- forventer
- erfaring
- utforske
- Trekk
- Endelig
- finansiell
- finansielle tjenester
- Først
- passer
- FLÅTE
- fleksibilitet
- fleksibel
- fokuserte
- følge
- etter
- følger
- format
- fremtidsrettet
- RAMME
- Rammeverk
- funksjon
- funksjonelle
- funksjonalitet
- funksjoner
- framtid
- generere
- genererer
- generasjonen
- Giving
- mål
- god
- GPU
- oppgradere
- Gruppe
- Gruppens
- håndtere
- Håndtering
- maskinvare
- Helse
- hørt
- hjelpe
- hjelpe
- hjelper
- her.
- høyere
- Hvordan
- HTTPS
- menneskelig
- Identitet
- bilde
- iverksette
- gjennomføring
- viktig
- inkludere
- inkluderer
- Inkludert
- individuelt
- bransjer
- industri
- Infrastruktur
- innovative
- inngang
- Setter inn
- installere
- integrert
- integrering
- Intel
- Intelligens
- interaksjon
- Interface
- IT
- Jobb
- Jobb
- reise
- nøkkel
- lab
- lansere
- lansere
- Fører
- læring
- Nivå
- Bibliotek
- linje
- Liste
- lasting
- plassering
- steder
- maskin
- maskinlæring
- laget
- vedlikeholde
- større
- GJØR AT
- mann
- administrer
- fikk til
- ledelse
- produksjon
- kart
- kartlegging
- nevnt
- metoder
- Metrics
- minimum
- Oppdrag
- ML
- Mobil
- Mobilapplikasjoner
- modell
- modeller
- modulære
- mer
- mest
- flere
- navn
- NBA
- nødvendig
- behov
- Antall
- OL
- åpner
- betjene
- optimalisert
- Alternativ
- rekkefølge
- Annen
- egen
- Oxford
- pakke
- del
- Spesielt
- spesielt
- partnere
- Passerer
- lidenskapelig
- Mønster
- prosent
- ytelse
- utfører
- perspektiv
- brikke
- plattform
- Plattformer
- spiller
- Poesi
- poeng
- mulig
- makt
- kraftig
- Forbered
- forrige
- primære
- prinsipp
- prioritet
- prosess
- Prosesser
- prosessering
- prosessor
- produsere
- Produksjon
- Produkter
- profesjonell
- prosjekt
- gi
- gir
- formål
- område
- Raw
- realtime
- gjenkjenne
- rekord
- poster
- om
- pålitelig
- forespørsler
- krever
- påkrevd
- Krav
- Krever
- ressurs
- Ressurser
- svar
- Resultater
- Kjør
- rennende
- Sikkerhet
- San
- skalerbarhet
- skalerbar
- Skala
- skalering
- SDK
- sikre
- segmenter
- server~~POS=TRUNC
- tjeneste
- Tjenester
- sett
- innstilling
- Form
- deling
- Shell
- vist
- lignende
- på samme måte
- Enkelt
- Størrelse
- So
- Software
- programvare som en tjeneste
- software engineering
- løsning
- Solutions
- noen
- Noen
- spesialisert
- spesifikasjoner
- fart
- Sports
- stable
- Scene
- Standard
- standarder
- Begynn
- startet
- starter
- Tilstand
- state-of-the-art
- status
- lagring
- oppbevare
- stream
- streaming
- innsendt
- I ettertid
- sommer
- støtte
- Støtter
- system
- ta
- lag
- Teknologi
- Testing
- derfor
- Gjennom
- SLIPS
- tid
- i dag
- sammen
- tokyo
- spor
- Sporing
- typer
- typisk
- UCLA
- universitet
- University of Oxford
- låse opp
- Oppdater
- bruke
- Brukere
- utnytte
- verdi
- variasjon
- ulike
- vertikaler
- video
- videoer
- syn
- web
- webtjenester
- HVEM
- uten
- Arbeid
- arbeidet
- arbeid
- år