Dette blogindlæg er skrevet af Jonathan Lee, Nelson Leung, Paul Min og Troy Squillaci fra Intel.
In del 1 i dette indlæg diskuterede vi, hvordan Intel®3DAT samarbejdede med AWS Machine Learning Professional Services (MLPS) til at bygge en skalerbar AI SaaS-applikation. 3DAT bruger computervision og AI til at genkende, spore og analysere over 1,000 biomekaniske datapunkter fra standardvideo. Det giver kunderne mulighed for at skabe rige og kraftfulde biomekanik-drevne produkter, såsom web- og mobilapplikationer med detaljerede ydeevnedata og tredimensionelle visualiseringer.
I del 2 af dette indlæg dykker vi dybere ned i hvert trin i arkitekturen. Vi udforsker de AWS-tjenester, der bruges til at opfylde 3DAT-designkravene, herunder Amazon Kinesis datastrømme , Amazon Elastic Kubernetes Service (Amazon EKS), for skalerbart at implementere de nødvendige positionsestimatmodeller for denne software as a service (SaaS) applikation.
Arkitektur oversigt
Det primære mål for MLPS-teamet var at produktionsalisere 2D- og 3D-poseestimeringsmodelpipelines og skabe en funktionel og skalerbar applikation. Følgende diagram illustrerer løsningsarkitekturen.
Den komplette arkitektur er opdelt i fem hovedkomponenter:
- Brugerapplikationsgrænsefladelag
- Database
- Workflow orkestrering
- Generering af skalerbar stillingsestimatisering
- Driftsovervågning
Lad os gå i detaljer om hver komponent, deres interaktioner og rationalet bag designvalgene.
Brugerapplikationsgrænsefladelag
Følgende diagram viser applikationsgrænsefladelagene, der giver brugeradgang og kontrol over applikationen og dens ressourcer.
Disse adgangspunkter understøtter forskellige use cases baseret på forskellige kundepersoner. For eksempel kan en applikationsbruger indsende et job via CLI'et, hvorimod en udvikler kan bygge en applikation ved hjælp af Python SDK og indlejre pose-estimeringsintelligens i deres applikationer. CLI og SDK er bygget som modulære komponenter - begge lag er indpakninger af API-laget, som er bygget vha. Amazon API Gateway for at løse API-kaldene og tilhørende AWS Lambda funktioner, som tager sig af backend-logikken forbundet med hvert API-kald. Disse lag var en afgørende komponent for Intel OTG-teamet, fordi det åbner op for en bred base af kunder, der effektivt kan bruge denne SaaS-applikation.
API-lag
Løsningen har et kernesæt på ni API'er, som svarer til de typer objekter, der opererer på denne platform. Hver API har en Python-fil, der definerer de API-handlinger, der kan køres. Oprettelse af nye objekter tildeles automatisk et objekt-id sekventielt. Attributterne for disse objekter gemmes og spores i Amazon Aurora serverløs database ved hjælp af dette ID. Derfor binder API-handlingerne sig tilbage til funktioner, der er defineret i en central fil, der indeholder backend-logikken til forespørgsel i Aurora-databasen. Denne backend-logik bruger Boto3 Amazon RDS DataService-klient for at få adgang til databaseklyngen.
Den ene undtagelse er /job
API, som har en create_job
metode, der håndterer videoindsendelse til oprettelse af et nyt behandlingsjob. Denne metode starter AWS-trinfunktioner workflowlogik til at køre jobbet. Ved at bestå i en job_id
, bruger denne metode Boto3 Trinfunktioner klient at kalde start_execution
metode til en specificeret stateMachineARN
(Amazon ressourcenavn).
De otte objekt-API'er har metoderne og lignende adgangsmønster som opsummeret i følgende tabel.
Metodetype | Funktionsnavn | Beskrivelse |
GET | list_[object_name]s |
Vælger alle objekter af denne type fra databasen og viser. |
POST | create_[object] |
Indsætter en ny objektpost med nødvendige input i databasen. |
GET | get_[object] |
Vælger objektattributter baseret på objekt-id'et fra databasen og viser. |
PUT | update_[object] |
Opdaterer en eksisterende objektpost med de nødvendige input. |
SLET | delete_[object] |
Sletter en eksisterende objektpost fra databasen baseret på objekt-id. |
Detaljerne for de ni API'er er som følger:
- /bruger – En bruger er identiteten på en person, der er autoriseret til at sende job til denne ansøgning. Oprettelse af en bruger kræver et brugernavn, bruger-e-mail og gruppe-id, som brugeren tilhører.
- /brugergruppe – En brugergruppe er en samling af brugere. Hver brugergruppe er knyttet til ét projekt og ét pipeline-parametersæt. For at have forskellige niveauer (med hensyn til infrastrukturelle ressourcer og pipeline-parametre) er brugerne opdelt i brugergrupper. Hver bruger kan kun tilhøre én brugergruppe. Oprettelse af en brugergruppe kræver et projekt-id, et pipeline-parametersæt-id, brugergruppenavn og brugergruppebeskrivelse. Bemærk, at brugergrupper er forskellige fra brugerroller defineret i AWS-kontoen. Sidstnævnte bruges til at give forskellige adgangsniveauer baseret på deres adgangsroller (for eksempel admin).
- /projekt – Et projekt bruges til at gruppere forskellige sæt af infrastrukturelle ressourcer sammen. Et projekt er knyttet til en enkelt
project_cluster_url
(Aurora-klynge) til registrering af brugere, job og andre metadata, enproject_queue_arn
(Kinesis Data Streams ARN) og et computer-runtime-miljø (i øjeblikket styret via Cortex), der bruges til at køre inferens på frame-batches eller efterbehandling på videoerne. Hver brugergruppe er knyttet til ét projekt, og denne mekanisme er, hvordan forskellige niveauer aktiveres med hensyn til latens og regnekraft for forskellige grupper af brugere. Oprettelse af et projekt kræver et projektnavn, projektklynge-URL og projektkø ARN. - /pipeline – En pipeline er forbundet med en enkelt konfiguration for en sekvens af behandlingscontainere, der udfører videobehandling i Amazon EKS-inferensgenereringsklyngen koordineret af Cortex (se afsnittet om videobehandlingsinferensgenerering for flere detaljer). Typisk består dette af tre beholdere: forbehandling og afkodning, objektdetektering og positur-estimering. For eksempel er afkodnings- og objektdetektionstrinnet det samme for 2D- og 3D-pipelines, men udskiftning af den sidste container ved hjælp af enten HRNet eller 3DMPPE resulterer i parametersættet for 2D- vs. 3D-behandlingspipelines. Du kan oprette nye konfigurationer for at definere mulige pipelines, der kan bruges til behandling, og det kræver som input en ny Python-fil i Cortex-repoen, der detaljerer sekvensen af model-endepunkter-kald, der definerer den pipeline (se afsnittet om generering af videobearbejdning inferens ). Pipeline-endepunktet er Cortex-endepunktet, der kaldes til at behandle en enkelt frame. Oprettelse af en pipeline kræver et pipelinenavn, en pipelinebeskrivelse og et pipelineslutpunkt.
- /pipeline_parameter_set – Et pipeline-parametersæt er en fleksibel JSON-samling af flere parametre (en pipeline-konfigurations-runtime) for en bestemt pipeline og tilføjes for at give fleksibilitet til fremtidig tilpasning, når der kræves flere pipeline-konfigurations-runtimes. Brugergrupper kan knyttes til et bestemt pipeline-parametersæt, og dets formål er at have forskellige grupper af parametre pr. brugergruppe og pr. pipeline. Dette var en vigtig fremadrettet tilføjelse for Intel OTG til at indbygge tilpasning, der understøtter portabilitet, efterhånden som forskellige kunder, især ISV'er, begynder at bruge applikationen.
- /pipeline_parameters – En enkelt samling af pipeline-parametre er en instansiering af et pipeline-parametersæt. Dette gør det til en 1:mange mapping af et pipeline-parametersæt til pipeline-parametre. Denne API kræver et pipeline-id for at associere med det sæt af pipelineparametre, der gør det muligt at oprette en pipeline til en 1:1-mapping af pipelineparametre til pipelinen. De andre input, der kræves af denne API, er et pipelineparametersæt-id, pipelineparametreværdi og pipelineparametrenavn.
- /video – Et videoobjekt bruges til at definere individuelle videoer, der udgør en .zip-pakke indsendt under et job. Denne fil er opdelt i flere videoer efter indsendelse. En video er relateret til
job_id
for det job, hvor .zip-pakken indsendes, og Amazon Simple Storage Service (Amazon S3) stier til placeringen af de rå-separerede videoer og efterbehandlingsresultaterne for hver video. Videoobjektet indeholder også en videofremskridtsprocent, som konsekvent opdateres under behandlingen af individuelle framebatches af den video, samt et videostatusflag for fuldført eller ikke fuldført. Oprettelse af en video kræver et job-id, videosti, videoresultatsti, videofremskridtsprocent og videostatus. - /ramme_batch - A
frame_batch
objekt er en mini-batch af frames oprettet ved at sample en enkelt video. Adskillelse af en video i rammebatches i almindelig størrelse giver et håndtag til at justere latens og øger parallelisering og gennemløb. Dette er den granulære enhed, der køres gennem Kinesis-datastrømme til slutning. En oprettelse af en frame batch kræver et video-id, frame batch startnummer, frame batch slutnummer, frame batch inputsti, frame batch resultatsti og frame batch status. - /job – Denne interaktions-API bruges til filindsendelse for at starte et behandlingsjob. Denne API har en anden funktion end andre objekt-API'er, fordi det er den direkte sti til at interagere med videobehandlingens backend Step Functions workflow-koordinering og Amazon EKS-klyngen. Denne API kræver et bruger-id, projekt-id, pipeline-id, pipeline-parametersæt-id, jobparametre og jobstatus. I jobparametrene er der angivet en inputfilsti, som er det sted i Amazon S3, hvor .zip-pakken med videoer, der skal behandles, er placeret. Filupload håndteres med
upload_handler
metode, som genererer en foruddefineret S3 URL, så brugeren kan placere en fil. En WORKFLOW_STATEMACHINE_ARN er en miljøvariabel, der sendes tilcreate_job
API til at angive, hvor en video .zip-pakke med en inputfilsti sendes for at starte et job.
Følgende tabel opsummerer API'ens funktioner.
Metodetype | Funktion | Beskrivelse |
GET | list_jobs |
Vælger alle job fra databasen og viser. |
POST | create_ job |
Indsætter en ny jobpost med bruger-id, projekt-id, pipeline-id, pipeline-parametersæt-id, jobresultatsti, jobparametre og jobstatus. |
GET | get_ job |
Vælger jobattributter baseret på job-id fra databasen og viser. |
GET | upload_handler |
Genererer en foruddefineret S3-URL som placering for upload af .zip-fil. Kræver et S3 bucket navn og forventer en applikation/zip filtype. |
Python SDK-lag
Med udgangspunkt i API'erne oprettede teamet et Python SDK-klientbibliotek som en indpakning for at gøre det nemmere for udviklere at få adgang til API-metoderne. De brugte open source Poetry, som håndterer Python-pakning og afhængighedsstyring. De skabte en client.py
fil, der indeholder funktioner, der ombryder hver af API'erne ved hjælp af Python requests
bibliotek til at håndtere API-anmodninger og undtagelser.
For at udviklere kan lancere Intel 3DAT SDK, skal de installere og bygge Poetry-pakken. Derefter kan de tilføje en simpel Python-import af intel_3dat_sdk
til enhver Python-kode.
For at bruge klienten kan du oprette en forekomst af klienten og angive API-slutpunktet:
Du kan derefter bruge klienten til at kalde de enkelte metoder som f.eks create_pipeline
metode (se følgende kode), idet du tager de korrekte argumenter ind, såsom pipelinenavn og pipelinebeskrivelse.
CLI lag
På samme måde byggede teamet på API'erne for at skabe en kommandolinjegrænseflade til brugere, der ønsker at få adgang til API-metoderne med en ligetil grænseflade uden at skulle skrive Python-kode. De brugte open source Python-pakken Klik (Kommandolinjegrænsefladeoprettelseskit). Fordelene ved denne ramme er den vilkårlige indlejring af kommandoer, automatisk generering af hjælpesider og understøttelse af doven indlæsning af underkommandoer under kørsel. I det samme client.py
fil som i SDK, blev hver SDK-klientmetode pakket med Click, og de påkrævede metodeargumenter blev konverteret til kommandolinjeflag. Flagindgangene bruges derefter, når SDK-kommandoen kaldes.
For at starte CLI kan du bruge CLI configure
kommando. Du bliver bedt om slutpunktets URL:
Nu kan du bruge CLI til at kalde forskellige kommandoer relateret til API-metoderne, for eksempel:
Database
Som en database bruger denne applikation Aurora Serverless til at gemme metadata knyttet til hver af API'erne med MYSQL som databasemotor. Valg af Aurora Serverless-databasetjenesten overholder designprincippet for at minimere infrastrukturelle omkostninger ved at bruge serverløse AWS-tjenester, når det er muligt. Følgende diagram illustrerer denne arkitektur.
serverløs motortilstand opfylder det intermitterende brugsmønster, fordi denne applikation skalerer op til nye kunder, og arbejdsbelastningen er stadig usikker. Når du starter et databaseslutpunkt, kræves der ikke en specifik DB-instansstørrelse, kun et minimums- og maksimuminterval for klyngekapacitet. Aurora Serverless håndterer passende levering af en routerflåde og fordeler arbejdsbyrden mellem ressourcerne. Aurora Serverless udfører automatisk sikkerhedskopiering i minimum 1 dag op til 35 dage. Holdet optimerede til sikkerhed ved at indstille standardværdien til den maksimale værdi på 35.
Derudover brugte holdet Data API at håndtere adgangen til Aurora Serverless-klyngen, som ikke kræver en vedvarende forbindelse, og i stedet giver et sikkert HTTP-slutpunkt og integration med AWS SDK'er. Denne funktion bruger AWS Secrets Manager at gemme database-legitimationsoplysningerne, så der ikke er behov for eksplicit at videregive legitimationsoplysninger. CREATE TABLE-scripts blev skrevet i .sql-filer for hver af de ni tabeller, der svarer til de ni API'er. Fordi denne database indeholdt alle metadata og tilstand for objekter i systemet, blev API-metoderne kørt ved hjælp af de relevante SQL-kommandoer (f.eks. select * from Job
for list_jobs
API) og videregivet til execute_statement
metode fra Amazon RDS-klienten i Data API.
Workflow orkestrering
Applikationens funktionelle rygrad blev håndteret ved hjælp af Trinfunktioner til at koordinere arbejdsgangen, som vist i følgende diagram.
Statsmaskinen bestod af en sekvens af fire Lambda-funktioner, som starter, når et job indsendes ved hjælp af create_job
metode fra job
API. Bruger-id, projekt-id, pipeline-id, pipeline-parametersæt-id, jobresultatsti, jobparametre og jobstatus er påkrævet for at oprette job. Du kan først uploade en .zip-pakke med videofiler ved hjælp af upload_handler
metode fra job-API'en til at generere en foruddefineret S3-URL. Under jobafsendelse sendes inputfilstien via jobparametrene for at angive filens placering. Dette starter kørslen af workflow-tilstandsmaskinen og udløser fire hovedtrin:
- Initializer Lambda funktion
- Indsender Lambda funktion
- Afslutning Tjek Lambda-funktion
- Collector Lambda funktion
Initializer Lambda funktion
Initializerens hovedfunktion er at adskille .zip-pakken i individuelle videofiler og forberede dem til afsenderen. Først downloades .zip-filen, og derefter pakkes hver enkelt fil, inklusive videofiler, ud og udpakkes. Videoerne, helst i .mp4-format, uploades tilbage til en S3-bøtte. Bruger create_video
metode i video
API oprettes et videoobjekt med videostien som input. Dette indsætter data på hver video i Aurora-databasen. Alle andre filtyper, såsom JSON-filer, betragtes som metadata og uploades på samme måde, men der oprettes ikke noget videoobjekt. En liste over navnene på filer og videofiler, der er pakket ud, sendes til næste trin.
Indsender Lambda funktion
Submitter-funktionen tager de videofiler, der blev udtrukket af initialiseringen, og opretter mini-batches af videorammer som billeder. De fleste nuværende computervisionsmodeller i produktionen er blevet trænet i billeder, så selv når video behandles, bliver de først adskilt i billedrammer før modelslutning. Denne nuværende løsning, der bruger en state-of-the-art model for positur-estimering, er ikke anderledes – rammebatchene fra afsenderen sendes til Kinesis Data Streams for at starte inferensgenereringstrinnet.
Først downloades videofilen af Lambda-funktionen. Billedhastigheden og antallet af billeder beregnes ved hjælp af FileVideoStream
modul fra imutils.video
behandlingsbibliotek. Rammerne udtrækkes og grupperes i henhold til en specificeret mini-batchstørrelse, som er en af de vigtigste tunerbare parametre i denne pipeline. Ved hjælp af Python pickle-biblioteket serialiseres dataene og uploades til Amazon S3. Efterfølgende oprettes et frame batch-objekt, og metadataindtastningen oprettes i Aurora-databasen. Denne Lambda-funktion blev bygget ved hjælp af en Dockerfile med afhængigheder på opencv-python
, numpy
og imutils
biblioteker.
Afslutning Tjek Lambda-funktion
Funktionen Completion Check fortsætter med at forespørge Aurora-databasen for at se, for hver video i .zip-pakken for dette aktuelle job, hvor mange framebatches der er i FULDFØRT-statussen. Når alle framebatches for alle videoer er færdige, er denne kontrolproces fuldført.
Collector Lambda funktion
Collector-funktionen tager output fra de slutninger, der blev udført på hver frame i forbrugerstadiet og kombinerer dem på tværs af en frame-batch og på tværs af en video. De kombinerede flettede data uploades derefter til en S3-bøtte. Funktionen kalder derefter Cortex-efterbehandlings-API'en for en bestemt ML-pipeline for at udføre eventuelle efterbehandlingsberegninger og tilføjer de aggregerede resultater via video til output-bøtten. Mange af disse målinger beregnes på tværs af rammer, såsom hastighed, acceleration og ledvinkel, så denne beregning skal udføres på de aggregerede data. De primære output inkluderer data for hovednøglepunkter (aggregeret i CSV-format), BMA-beregninger (såsom acceleration) og visuel overlejring af nøglepunkter tilføjet til hver ramme i en billedfil.
Generering af skalerbar stillingsestimatisering
Bearbejdningsmotoren, der driver skaleringen af ML-inferens, sker i denne fase. Det involverer tre hoveddele, hver med deres egne samtidighedsgreb, der kan indstilles til latency-afvejninger (se følgende diagram).
Denne arkitektur giver mulighed for eksperimentering med at teste latensgevinster samt fleksibilitet for fremtiden, når arbejdsbelastninger kan ændre sig med forskellige blandinger af slutbrugersegmenter, der får adgang til applikationen.
Kinesis datastrømme
Teamet valgte Kinesis Data Streams, fordi det typisk bruges til at håndtere streamingdata, og i dette tilfælde passer det godt, fordi det kan håndtere frame-batches på en lignende måde for at give skalerbarhed og parallelisering. I Submitter Lambda-funktionen bruges Kinesis Boto3-klienten med put_record
metode, der overfører de metadata, der er knyttet til en enkelt frame batch, såsom frame batch ID, frame batch start frame, frame batch slut frame, billedform, frame rate og video ID.
Vi definerede forskellige jobkø- og Kinesis-datastrømkonfigurationer for at indstille niveauer af gennemløb, der binder tilbage til prioritetsniveauet for forskellige brugergrupper. Adgang til forskellige niveauer af processorkraft er forbundet ved at sende en projektkø ARN, når der oprettes et nyt projekt ved hjælp af project
API. Hver brugergruppe er derefter knyttet til et bestemt projekt under oprettelse af brugergruppe. Tre standard stream-konfigurationer er defineret i AWS serverløs applikationsmodel (AWS SAM) infrastrukturskabelon:
- standard -
JobStreamShardCount
- Prioritet -
PriorityJobStreamShardCount
- Høj prioritet -
HighPriorityJobStreamShardCount
Holdet brugte et par forskellige håndtag til at differentiere processorkraften for hver strøm eller justere latensen af systemet, som opsummeret i følgende tabel.
Håndtag | Beskrivelse | Standard værdi |
shard | Et shard er hjemmehørende i Kinesis Data Streams; det er basisenheden for gennemløb til indtagelse. Standarden er 1 MB/sek., hvilket svarer til 1,000 dataposter i sekundet. | 2 |
KinesisBatchSize |
Det maksimale antal poster, som Kinesis Data Streams henter i en enkelt batch, før forbrugerens Lambda-funktion aktiveres. | 1 |
KinesisParallelizationFactor |
Antallet af batches, der skal behandles fra hvert shard samtidigt. | 1 |
Forbedret fan-out | Dataforbrugere, der har aktiveret udvidet fan-out, har en dedikeret indtagelsesgennemstrømning pr. forbruger (såsom standarden 1 MB/sek.) i stedet for at dele kapaciteten på tværs af forbrugere. | af |
Forbruger Lambda funktion
Fra Kinesis Data Streams perspektiv er en dataforbruger en AWS-tjeneste, der henter data fra et datastrømsshard, efterhånden som data genereres i en strøm. Denne applikation bruger en Consumer Lambda-funktion, som aktiveres, når meddelelser sendes fra datastrømskøerne. Hver forbrugerfunktion behandler én rammebatch ved at udføre følgende trin. Først foretages et opkald til Cortex-processor-API'en synkront, som er det endepunkt, der er vært for modelinferenspipelinen (se næste afsnit vedrørende Amazon EKS med Cortex for flere detaljer). Resultaterne gemmes i Amazon S3, og der foretages en opdatering af databasen ved at ændre status for den behandlede frame batch til Complete
. Fejlhåndtering er indbygget til at administrere Cortex API-kaldet med en genforsøgsløkke til at håndtere eventuelle 504-fejl fra Cortex-klyngen, med antallet af genforsøg sat til 5.
Amazon EKS med Cortex til ML-inferens
Holdet brugte Amazon EKS, en administreret Kubernetes-tjeneste i AWS, som beregningsmotor til ML-inferens. Der blev truffet et designvalg for at bruge Amazon EKS til at hoste ML-endepunkter, hvilket giver fleksibiliteten til at køre opstrøms Kubernetes med mulighed for klynger, begge fuldt administreret i AWS via AWS Fargate, eller lokal hardware via Amazon EKS hvor som helst. Dette var et kritisk stykke funktionalitet, som Intel OTG ønskede, og som gav muligheden for at tilslutte denne applikation til f.eks. specialiseret on-premises hardware.
De tre ML-modeller, der var byggestenene til at konstruere inferensrørledningerne, var en brugerdefineret Yolo-model (til objektdetektering), en brugerdefineret HRNet-model (til 2D-poseestimering) og en 3DMPPE-model (til 3D-poseestimering) (se den forrige ML sektion for flere detaljer). De brugte open source Cortex bibliotek til at håndtere udrulning og administration af ML-inferenspipeline-endepunkter og lancering og udrulning af Amazon EKS-klynger. Hver af disse modeller blev pakket ind i Docker-containere - modelfiler blev gemt i Amazon S3 og modelbilleder blev gemt i Amazon Elastic Container Registry (Amazon ECR) – og implementeret som Cortex Realtime API'er. Versioner af modelbeholderne, der kører på CPU og GPU, blev skabt for at give fleksibilitet til typen af computerhardware. Hvis der i fremtiden skal tilføjes yderligere modeller eller modelpipelines, kan de blot oprette yderligere Cortex Realtime API'er.
De konstruerede derefter inferenspipelines ved at sammensætte Cortex Realtime model API'erne til Cortex Realtime pipeline API'er. En enkelt Realtime pipeline API bestod af at kalde en sekvens af Realtime model API'er. Forbruger lambda-funktionerne behandlet en pipeline
API som en sort boks, der bruger et enkelt API-kald til at hente den endelige slutningsoutput for et billede. To pipelines blev oprettet: en 2D pipeline og en 3D pipeline.
2D-pipelinen kombinerer et afkodnings-forbehandlingstrin, objektdetektering ved hjælp af en brugerdefineret Yolo-model til at lokalisere atleten og producere afgrænsningsbokse, og endelig en tilpasset HRNet-model til at skabe 2D-nøglepunkter til estimering af posering.
3D-pipelinen kombinerer et afkodnings-forbehandlingstrin, objektdetektering ved hjælp af en tilpasset Yolo-model til at lokalisere atleten og producere afgrænsningsbokse og endelig en 3DMPPE-model til at skabe 3D-nøglepunkter til estimering af posering.
Efter at have genereret slutninger om en batch af frames, inkluderer hver pipeline også et separat efterbehandlings-Realtime Cortex-slutpunkt, der genererer tre hovedoutput:
- Aggregerede kropsnøgler peger data ind i en enkelt CSV-fil
- BMA-beregninger (såsom acceleration)
- Visuel overlejring af nøglepunkter tilføjet til hver ramme i en billedfil
Collector Lambda-funktionen sender de passende metadata, der er knyttet til en bestemt video, såsom frame-id'er og S3-placeringer af positestimeringsinferensoutput, til slutpunktet for at generere disse efterbehandlingsoutput.
Cortex er designet til at blive integreret med Amazon EKS og kræver kun en klyngekonfigurationsfil og en simpel kommando for at starte en Kubernetes-klynge:
En anden håndtag til justering af ydeevne var instanskonfigurationen for computerklyngerne. Der blev oprettet tre lag med forskellige blandinger af M5- og G4dn-forekomster, kodificeret som .yaml-filer med specifikationer såsom klyngenavn, region og forekomstkonfiguration og -mix. M5-forekomster er lavere omkostninger CPU-baserede og G4dn er højere omkostninger GPU-baserede for at give nogle omkostninger/ydelse-afvejninger.
Driftsovervågning
For at opretholde operationelle logningsstandarder inkluderer alle Lambda-funktioner kode til at registrere og indlæse logfiler via Amazon Kinesis Data Firehose. For eksempel logges hver framebatch, der behandles fra Submitter Lambda-funktionen, med tidsstemplet, navnet på handlingen og Lambda-funktionsvaret JSON og gemmes i Amazon S3. Følgende diagram illustrerer dette trin i arkitekturen.
Deployment
Implementeringen håndteres ved hjælp af AWS SAM, en open source-ramme til opbygning af serverløse applikationer i AWS. AWS SAM muliggør, at infrastrukturdesign, herunder funktioner, API'er, databaser og hændelseskildekortlægninger, kan kodificeres og nemt implementeres i nye AWS-miljøer. Under implementeringen oversættes AWS SAM-syntaksen til AWS CloudFormation til at håndtere infrastrukturforsyningen.
A template.yaml
fil indeholder infrastrukturspecifikationerne sammen med justerbare parametre, såsom Kinesis Data Streams latency håndtag, der er beskrevet i de foregående afsnit. EN samconfig.toml
fil indeholder implementeringsparametre såsom staknavn, S3-spandnavn, hvor applikationsfiler som Lambda-funktionskode er gemt, og ressourcetags til sporing af omkostninger. Et deploy.sh shell-script med de simple kommandoer er alt, der kræves for at bygge og implementere hele skabelonen:
Bruger arbejdsflow
For at opsummere, efter at infrastrukturen er blevet implementeret, kan du følge denne arbejdsgang for at komme i gang:
- Opret en Intel 3DAT-klient ved hjælp af klientbiblioteket.
- Brug API'et til at oprette en ny forekomst af en pipeline, der svarer til den type behandling, der kræves, såsom en til 3D-positur-estimering.
- Opret en ny forekomst af et projekt, der passerer i klyngen ARN og Kinesis køen ARN.
- Opret en ny forekomst af et pipeline-parametersæt.
- Opret en ny forekomst af pipelineparametre, der knytter sig til pipelineparametersættet.
- Opret en ny brugergruppe, der er knyttet til et projekt-id og et pipeline-parametersæt-id.
- Opret en ny bruger, der er tilknyttet brugergruppen.
- Upload en .zip-fil med videoer til Amazon S3 ved hjælp af en foruddefineret S3 URL genereret af uploadfunktionen i job-API'en.
- Indsend en
create_job
API-kald med jobparametre, der angiver placeringen af videofilerne. Dette starter behandlingsopgaven.
Konklusion
Applikationen er nu live og klar til at blive testet med både atleter og trænere. Intel OTG er begejstret for at gøre innovativ poseestimeringsteknologi ved hjælp af computervision tilgængelig for en række brugere, fra udviklere til atleter til softwareleverandørpartnere.
AWS-teamet brænder for at hjælpe kunder som Intel OTG med at accelerere deres ML-rejse, fra idé- og opdagelsesstadiet med ML Solutions Lab til hærdnings- og implementeringsfasen med AWS ML ProServe. Vi vil alle følge nøje med ved OL i Tokyo 2021 til sommer for at forestille os alle de fremskridt, som ML kan låse op inden for sport.
Kom i gang i dag! Udforsk din use case med de tjenester, der er nævnt i dette indlæg og mange andre på AWS Management Console.
Om forfatterne
Han mand er Senior Manager- Machine Learning & AI hos AWS med base i San Diego, CA. Han har en ph.d. i ingeniørvidenskab fra Northwestern University og har flere års erfaring som ledelseskonsulent med rådgivning til kunder inden for fremstilling, finansielle tjenesteydelser og energi. I dag arbejder han lidenskabeligt med kunder fra en række forskellige brancher for at udvikle og implementere machine learning & AI-løsninger på AWS. Han nyder at følge NBA og spille basketball i sin fritid.
Iman Kamyabi er en ML-ingeniør med AWS Professional Services. Han har arbejdet med en bred vifte af AWS-kunder for at forkæmpe bedste praksis ved opsætning af repeterbare og pålidelige ML-pipelines.
Jonathan Lee er direktør for Sports Performance Technology, Olympic Technology Group hos Intel. Han studerede anvendelsen af maskinlæring på sundhed som en undergrad ved UCLA og under sit kandidatarbejde ved University of Oxford. Hans karriere har fokuseret på algoritme- og sensorudvikling til sundhed og menneskelig præstation. Han leder nu 3D Atlet Tracking-projektet hos Intel.
Nelson Leung er Platform Architect i Sports Performance CoE hos Intel, hvor han definerer end-to-end arkitektur for avancerede produkter, der forbedrer atletens præstation. Han leder også implementeringen, implementeringen og produktiseringen af disse maskinlæringsløsninger i stor skala til forskellige Intel-partnere.
Troy Squillaci er DecSecOps-ingeniør hos Intel, hvor han leverer professionelle softwareløsninger til kunder gennem DevOps bedste praksis. Han nyder at integrere AI-løsninger i skalerbare platforme i en række forskellige domæner.
Paul Min er Associate Solutions Architect Intern hos Amazon Web Services (AWS), hvor han hjælper kunder på tværs af forskellige brancher med at fremme deres mission og fremskynde deres cloud-adoption. Tidligere hos Intel arbejdede han som softwareingeniørpraktikant for at hjælpe med at udvikle 3D Athlete Tracking Cloud SDK. Uden for arbejdet nyder Paul at spille golf og kan høres synge.
- 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/the-intel3d-athlete-tracking-3dat-scalable-architecture-deploys-pose-estimation-models-using-amazon-kinesis-data-streams- og-amazon-eks/
- "
- &
- 000
- 100
- 2021
- 3d
- Om
- fremskynde
- adgang
- tilgængelig
- Ifølge
- Konto
- tværs
- Handling
- aktioner
- Desuden
- Yderligere
- admin
- Vedtagelse
- AI
- algoritme
- Alle
- Amazon
- Amazon Web Services
- blandt
- api
- API'er
- Anvendelse
- applikationer
- passende
- arkitektur
- argumenter
- tildelt
- Associate
- atleter
- attributter
- Automatisk Ur
- AWS
- backup
- Basketball
- før
- fordele
- BEDSTE
- bedste praksis
- Sort
- Blog
- krop
- Boks
- bygge
- Bygning
- ringe
- Kapacitet
- hvilken
- Karriere
- tilfælde
- central
- champion
- lave om
- valg
- kunder
- Cloud
- kode
- samling
- solfanger
- kombineret
- komponent
- Compute
- computer
- Konfiguration
- tilslutning
- konsulent
- forbruger
- Forbrugere
- Container
- Beholdere
- indeholder
- fortsætter
- kontrol
- koordinere
- Core
- Tilsvarende
- skabe
- oprettet
- skaber
- Oprettelse af
- skabelse
- Legitimationsoplysninger
- kritisk
- afgørende
- Nuværende
- For øjeblikket
- skik
- kunde
- Kunder
- banebrydende
- data
- Database
- databaser
- dag
- dedikeret
- dybere
- leverer
- indsætte
- indsat
- implementering
- udruller
- Design
- konstrueret
- detail
- detaljeret
- detaljer
- Detektion
- udvikle
- Udvikler
- udviklere
- Udvikling
- forskellige
- differentiere
- direkte
- Direktør
- opdagelse
- displays
- Docker
- Er ikke
- Domæner
- ned
- i løbet af
- nemt
- Endpoint
- energi
- Engine (Motor)
- ingeniør
- Engineering
- Miljø
- begivenhed
- eksempel
- ophidset
- eksisterende
- forventer
- erfaring
- udforske
- Feature
- Endelig
- finansielle
- finansielle tjenesteydelser
- Fornavn
- passer
- FLÅDE
- Fleksibilitet
- fleksibel
- fokuserede
- følger
- efter
- følger
- format
- fremadrettet
- FRAME
- Framework
- funktion
- funktionel
- funktionalitet
- funktioner
- fremtiden
- generere
- generere
- generation
- Give
- mål
- godt
- GPU
- eksamen
- gruppe
- Gruppens
- håndtere
- Håndtering
- Hardware
- Helse
- hørt
- hjælpe
- hjælpe
- hjælper
- link.
- højere
- Hvordan
- HTTPS
- menneskelig
- Identity
- billede
- gennemføre
- implementering
- vigtigt
- omfatter
- omfatter
- Herunder
- individuel
- industrier
- industrien
- Infrastruktur
- innovativ
- indgang
- Indsætter
- installere
- integreret
- integration
- Intel
- Intelligens
- interaktion
- grænseflade
- IT
- Job
- Karriere
- rejse
- Nøgle
- lab
- lancere
- lancering
- Leads
- læring
- Niveau
- Bibliotek
- Line (linje)
- Liste
- lastning
- placering
- placeringer
- maskine
- machine learning
- lavet
- vedligeholde
- større
- maerker
- mand
- administrere
- lykkedes
- ledelse
- Produktion
- kort
- kortlægning
- nævnte
- metoder
- Metrics
- minimum
- Mission
- ML
- Mobil
- Mobile applikationer
- model
- modeller
- modulær
- mere
- mest
- flere
- navne
- NBA
- nødvendig
- behov
- nummer
- OL
- åbner
- betjene
- optimeret
- Option
- ordrer
- Andet
- egen
- Oxford
- pakke
- del
- særlig
- især
- partnere
- Passing
- lidenskabelige
- Mønster
- procentdel
- ydeevne
- udfører
- perspektiv
- stykke
- perron
- Platforme
- spiller
- Poetry
- punkter
- mulig
- magt
- vigtigste
- Forbered
- tidligere
- primære
- princippet
- prioritet
- behandle
- Processer
- forarbejdning
- Processor
- producere
- produktion
- Produkter
- professionel
- projekt
- give
- giver
- formål
- rækkevidde
- Raw
- realtime
- genkende
- optage
- optegnelser
- om
- pålidelig
- anmodninger
- kræver
- påkrævet
- Krav
- Kræver
- ressource
- Ressourcer
- svar
- Resultater
- Kør
- kører
- Sikkerhed
- San
- Skalerbarhed
- skalerbar
- Scale
- skalering
- SDK
- sikker
- segmenter
- Serverless
- tjeneste
- Tjenester
- sæt
- indstilling
- Shape
- deling
- Shell
- vist
- lignende
- Tilsvarende
- Simpelt
- Størrelse
- So
- Software
- software som en tjeneste
- software Engineering
- løsninger
- Løsninger
- nogle
- Nogen
- specialiserede
- specifikationer
- hastighed
- Sport
- stable
- Stage
- standard
- standarder
- starte
- påbegyndt
- starter
- Tilstand
- state-of-the-art
- Status
- opbevaring
- butik
- strøm
- streaming
- indsendt
- Efterfølgende
- sommer
- support
- Understøtter
- systemet
- tager
- hold
- Teknologier
- Test
- derfor
- Gennem
- TIE
- tid
- i dag
- sammen
- tokyo
- spor
- Sporing
- typer
- typisk
- UCLA
- universitet
- University of Oxford
- låse
- Opdatering
- brug
- brugere
- Ved hjælp af
- værdi
- række
- forskellige
- vertikaler
- video
- Videoer
- vision
- web
- webservices
- WHO
- uden
- Arbejde
- arbejdede
- arbejder
- år