Det här blogginlägget är skrivet av Jonathan Lee, Nelson Leung, Paul Min och Troy Squillaci från Intel.
In del 1 i det här inlägget diskuterade vi hur Intel®3DAT samarbetade med AWS Machine Learning Professional Services (MLPS) för att bygga en skalbar AI SaaS-applikation. 3DAT använder datorseende och AI för att känna igen, spåra och analysera över 1,000 XNUMX biomekaniska datapunkter från standardvideo. Det tillåter kunder att skapa rika och kraftfulla biomekanikdrivna produkter, såsom webb- och mobilapplikationer med detaljerad prestandadata och tredimensionella visualiseringar.
I del 2 av det här inlägget dyker vi djupare in i varje steg i arkitekturen. Vi utforskar AWS-tjänsterna som används för att uppfylla 3DAT-designkraven, inklusive Amazon Kinesis dataströmmar och Amazon Elastic Kubernetes-tjänst (Amazon EKS), för att skalbart distribuera de nödvändiga modellerna för positionsuppskattning för denna programvara som en tjänst (SaaS)-applikation.
Arkitekturöversikt
Det primära målet för MLPS-teamet var att produktionsalisera 2D- och 3D-positionsuppskattningsmodellens pipelines och skapa en funktionell och skalbar applikation. Följande diagram illustrerar lösningsarkitekturen.
Hela arkitekturen är uppdelad i fem huvudkomponenter:
- Användarapplikationsgränssnittsskikt
- Databas
- Arbetsflödesorkestrering
- Generering av skalbar ställningsuppskattning
- Driftövervakning
Låt oss gå in i detalj på varje komponent, deras interaktioner och logiken bakom designvalen.
Användarapplikationsgränssnittsskikt
Följande diagram visar applikationsgränssnittsskikten som ger användaråtkomst och kontroll över applikationen och dess resurser.
Dessa åtkomstpunkter stöder olika användningsfall baserat på olika kundpersoner. Till exempel kan en applikationsanvändare skicka in ett jobb via CLI, medan en utvecklare kan bygga en applikation med Python SDK och bädda in positionsuppskattningsintelligens i sina applikationer. CLI och SDK är byggda som modulära komponenter – båda lagren är omslag av API-lagret, som är byggt med Amazon API Gateway för att lösa API-anrop och tillhörande AWS Lambda funktioner, som tar hand om backend-logiken som är associerad med varje API-anrop. Dessa lager var en avgörande komponent för Intel OTG-teamet eftersom det öppnar upp en bred bas av kunder som effektivt kan använda denna SaaS-applikation.
API-lager
Lösningen har en kärnuppsättning av nio API:er, som motsvarar de typer av objekt som fungerar på denna plattform. Varje API har en Python-fil som definierar API-åtgärderna som kan köras. Skapandet av nya objekt tilldelas automatiskt ett objekt-ID sekventiellt. Attributen för dessa objekt lagras och spåras i Amazon Aurora Serverlös databas med detta ID. Därför kopplar API-åtgärderna tillbaka till funktioner som är definierade i en central fil som innehåller backend-logiken för att fråga efter Aurora-databasen. Denna backend-logik använder Boto3 Amazon RDS DataService-klient för att komma åt databasklustret.
Det enda undantaget är /job
API, som har en create_job
metod som hanterar videoinlämning för att skapa ett nytt bearbetningsjobb. Denna metod startar AWS stegfunktioner arbetsflödeslogik för att köra jobbet. Genom att passera i en job_id
, använder den här metoden Boto3 Step Functions klient att ringa start_execution
metod för en specificerad stateMachineARN
(Amazon Resource Name).
De åtta objekt-API:erna har metoderna och liknande åtkomstmönster som sammanfattas i följande tabell.
Metodtyp | Funktionsnamn | Beskrivning |
FÅ | list_[object_name]s |
Väljer alla objekt av denna typ från databasen och visar. |
POST | create_[object] |
Infogar en ny objektpost med nödvändiga indata i databasen. |
FÅ | get_[object] |
Väljer objektattribut baserat på objekt-ID från databasen och visar. |
SÄTTA | update_[object] |
Uppdaterar en befintlig objektpost med nödvändiga ingångar. |
RADERA | delete_[object] |
Tar bort en befintlig objektpost från databasen baserat på objekt-ID. |
Detaljerna för de nio API:erna är följande:
- /användare – En användare är identiteten för någon som är behörig att skicka in jobb till denna ansökan. Skapandet av en användare kräver ett användarnamn, användarens e-postadress och grupp-ID som användaren tillhör.
- /användargrupp – En användargrupp är en samling användare. Varje användargrupp mappas till ett projekt och en pipelineparameteruppsättning. För att ha olika nivåer (när det gäller infrastrukturresurser och pipelineparametrar) delas användarna in i användargrupper. Varje användare kan endast tillhöra en användargrupp. Skapandet av en användargrupp kräver ett projekt-ID, pipelineparameteruppsättnings-ID, användargruppsnamn och användargruppsbeskrivning. Observera att användargrupper skiljer sig från användarroller som definierats i AWS-kontot. Den senare används för att ge olika åtkomstnivåer baserat på deras åtkomstroller (till exempel admin).
- /projekt – Ett projekt används för att gruppera olika uppsättningar av infrastrukturella resurser. Ett projekt är kopplat till en singel
project_cluster_url
(Aurora-kluster) för att registrera användare, jobb och annan metadata, enproject_queue_arn
(Kinesis Data Streams ARN) och en datorkörningsmiljö (för närvarande kontrollerad via Cortex) som används för att köra slutledning om bildrutorna eller efterbearbeta videorna. Varje användargrupp är kopplad till ett projekt, och denna mekanism är hur olika nivåer aktiveras när det gäller latens och beräkningskraft för olika grupper av användare. Skapandet av ett projekt kräver ett projektnamn, projektkluster-URL och projektkö ARN. - /rörledning – En pipeline är associerad med en enda konfiguration för en sekvens av bearbetningsbehållare som utför videobearbetning i Amazon EKS-inferensgenereringsklustret koordinerat av Cortex (se avsnittet om videobearbetningsinferensgenerering för mer information). Vanligtvis består detta av tre behållare: förbearbetning och avkodning, objektdetektering och ställningsuppskattning. Till exempel är avkodnings- och objektdetekteringssteget desamma för 2D- och 3D-pipelines, men att byta ut den sista behållaren med antingen HRNet eller 3DMPPE resulterar i parameteruppsättningen för 2D- kontra 3D-behandlingspipelines. Du kan skapa nya konfigurationer för att definiera möjliga pipelines som kan användas för bearbetning, och det kräver som indata en ny Python-fil i Cortex-repo som beskriver sekvensen av modelländpunkters anrop som definierar den pipeline (se avsnittet om generering av videobearbetning av slutpunkter ). Pipeline-ändpunkten är Cortex-ändpunkten som anropas för att bearbeta en enda bildruta. Skapandet av en pipeline kräver ett pipelinenamn, pipelinebeskrivning och pipelineslutpunkt.
- /pipeline_parameter_set – En pipeline-parameteruppsättning är en flexibel JSON-samling av flera parametrar (en pipelinekonfigurationskörning) för en viss pipeline och läggs till för att ge flexibilitet för framtida anpassning när flera pipelinekonfigurationskörningar krävs. Användargrupper kan associeras med en viss pipelineparameteruppsättning, och dess syfte är att ha olika grupper av parametrar per användargrupp och per pipeline. Detta var ett viktigt framåtblickande tillägg för Intel OTG att bygga in anpassning som stöder portabilitet när olika kunder, särskilt ISV:er, börjar använda applikationen.
- /pipeline_parameters – En enda samling pipelineparametrar är en instansiering av en pipelineparameteruppsättning. Detta gör det till en 1:många-mappning av en pipelineparameteruppsättning till pipelineparametrar. Detta API kräver ett pipeline-ID för att associeras med den uppsättning pipelineparametrar som gör det möjligt att skapa en pipeline för en 1:1-mappning av pipelineparametrar till pipeline. De andra indata som krävs av detta API är ett pipelineparameteruppsättnings-ID, pipelineparametrarnas värde och pipelineparametrarnas namn.
- /video – Ett videoobjekt används för att definiera enskilda videor som utgör ett .zip-paket som skickas in under ett jobb. Den här filen är uppdelad i flera videor efter inlämning. En video är relaterad till
job_id
för jobbet där .zip-paketet skickas in, och Amazon enkel lagringstjänst (Amazon S3) sökvägar för platsen för de råseparerade videorna och efterbearbetningsresultaten för varje video. Videoobjektet innehåller också en videoframstegsprocent, som uppdateras konsekvent under bearbetning av individuella bildrutor av den videon, samt en videostatusflagga för komplett eller ej komplett. Skapandet av en video kräver ett jobb-ID, videosökväg, videoresultatsökväg, videoframstegsprocent och videostatus. - /frame_batch - En
frame_batch
objekt är en mini-batch av bildrutor skapade genom att sampla en enskild video. Att separera en video i rampartier i normal storlek ger en spak för att justera latens och ökar parallellisering och genomströmning. Detta är den granulära enheten som körs genom Kinesis dataströmmar för slutledning. För att skapa en rambatch krävs ett video-ID, rambatchstartnummer, rambatchslutnummer, rambatchinmatningsväg, rambatchresultatsökväg och rambatchstatus. - /jobb – Detta interaktions-API används för filinlämning för att starta ett bearbetningsjobb. Detta API har en annan funktion än andra objekt-API:er eftersom det är den direkta vägen för att interagera med videobearbetningsbackend Step Functions arbetsflödeskoordinering och Amazon EKS-kluster. Detta API kräver ett användar-ID, projekt-ID, pipeline-ID, pipelineparameteruppsättnings-ID, jobbparametrar och jobbstatus. I jobbparametrarna anges en sökväg för indatafil, vilket är platsen i Amazon S3 där .zip-paketet med videor som ska bearbetas finns. Filuppladdning hanteras med
upload_handler
metod, som genererar en förutbestämd S3 URL för användaren att placera en fil. En WORKFLOW_STATEMACHINE_ARN är en miljövariabel som skickas tillcreate_job
API för att ange var ett video .zip-paket med en indatafilsökväg skickas för att starta ett jobb.
Följande tabell sammanfattar API:s funktioner.
Metodtyp | Funktion | Beskrivning |
FÅ | list_jobs |
Väljer alla jobb från databasen och visar. |
POST | create_ job |
Infogar en ny jobbpost med användar-ID, projekt-ID, pipeline-ID, pipelineparameteruppsättnings-ID, jobbresultatsökväg, jobbparametrar och jobbstatus. |
FÅ | get_ job |
Väljer jobbattribut baserat på jobb-ID från databasen och visar. |
FÅ | upload_handler |
Genererar en förinställd S3-URL som plats för .zip-filuppladdningen. Kräver ett S3-hinknamn och förväntar sig en applikations-/zip-filtyp. |
Python SDK-lager
Med utgångspunkt i API:erna skapade teamet ett Python SDK-klientbibliotek som ett omslag för att göra det lättare för utvecklare att komma åt API-metoderna. De använde öppen källkod Poesi, som hanterar Python-paketering och beroendehantering. De skapade en client.py
fil som innehåller funktioner som omsluter var och en av API:erna med Python requests
bibliotek för att hantera API-förfrågningar och undantag.
För att utvecklare ska kunna lansera Intel 3DAT SDK måste de installera och bygga Poetry-paketet. Sedan kan de lägga till en enkel Python-import av intel_3dat_sdk
till valfri Python-kod.
För att använda klienten kan du skapa en instans av klienten och ange API-slutpunkten:
Du kan sedan använda klienten för att anropa de individuella metoderna som t.ex create_pipeline
metod (se följande kod), som tar in de rätta argumenten som pipelinenamn och pipelinebeskrivning.
CLI-lager
På samma sätt byggde teamet på API:erna för att skapa ett kommandoradsgränssnitt för användare som vill komma åt API-metoderna med ett enkelt gränssnitt utan att behöva skriva Python-kod. De använde Python-paketet med öppen källkod Klicka (Command Line Interface Creation Kit). Fördelarna med detta ramverk är godtycklig kapsling av kommandon, automatisk generering av hjälpsidor och stöd för lat inläsning av underkommandon vid körning. I samma client.py
fil som i SDK:n, lindades varje SDK-klientmetod med Click och de nödvändiga metodargumenten konverterades till kommandoradsflaggor. Flaggingångarna används sedan när SDK-kommandot anropas.
För att starta CLI kan du använda CLI configure
kommando. Du uppmanas att ange slutpunkts-URL:
Nu kan du använda CLI för att anropa olika kommandon relaterade till API-metoderna, till exempel:
Databas
Som en databas använder den här applikationen Aurora Serverless för att lagra metadata som är associerade med var och en av API:erna med MYSQL som databasmotor. Att välja Aurora Serverless-databastjänst följer designprincipen för att minimera infrastrukturella kostnader genom att använda serverlösa AWS-tjänster när det är möjligt. Följande diagram illustrerar denna arkitektur.
Smakämnen serverlöst motorläge uppfyller det intermittenta användningsmönstret eftersom denna applikation skalas upp till nya kunder och arbetsbelastningen fortfarande är osäkra. När du startar en databasslutpunkt krävs inte en specifik DB-instansstorlek, bara ett minimi- och maximumintervall för klusterkapacitet. Aurora Serverless hanterar lämplig provisionering av en routerflotta och fördelar arbetsbelastningen mellan resurserna. Aurora Serverless utför automatiskt säkerhetskopiering i minst 1 dag upp till 35 dagar. Teamet optimerade för säkerhet genom att ställa in standardvärdet på maxvärdet 35.
Dessutom använde laget Data API för att hantera åtkomst till Aurora Serverless-klustret, som inte kräver en beständig anslutning, och istället tillhandahåller en säker HTTP-slutpunkt och integration med AWS SDK:er. Denna funktion använder AWS Secrets Manager för att lagra databasuppgifterna så att det inte finns något behov av att uttryckligen skicka inloggningsuppgifter. CREATE TABLE-skript skrevs i .sql-filer för var och en av de nio tabellerna som motsvarar de nio API:erna. Eftersom denna databas innehöll alla metadata och tillstånd för objekt i systemet, kördes API-metoderna med lämpliga SQL-kommandon (till exempel select * from Job
för list_jobs
API) och skickas till execute_statement
metod från Amazon RDS-klienten i Data API.
Arbetsflödesorkestrering
Applikationens funktionella ryggrad hanterades med hjälp av Step Functions för att koordinera arbetsflödet, som visas i följande diagram.
Tillståndsmaskinen bestod av en sekvens av fyra lambdafunktioner, som startar när ett jobb skickas in med hjälp av create_job
metod från job
API. Användar-ID, projekt-ID, pipeline-ID, pipelineparameteruppsättnings-ID, sökväg för jobbresultat, jobbparametrar och jobbstatus krävs för att skapa jobb. Du kan först ladda upp ett .zip-paket med videofiler med hjälp av upload_handler
metod från jobb-API:et för att generera en förutbestämd S3-URL. Under inlämning av jobb skickas indatafilens sökväg via jobbparametrarna, för att ange filens plats. Detta startar körningen av arbetsflödestillståndsmaskinen och utlöser fyra huvudsteg:
- Initializer Lambda funktion
- Insändare Lambdafunktion
- Slutförande Kontrollera Lambda-funktionen
- Collector Lambda funktion
Initializer Lambda funktion
Initialiserarens huvudfunktion är att separera .zip-paketet i individuella videofiler och förbereda dem för avsändaren. Först laddas .zip-filen ned och sedan packas varje enskild fil, inklusive videofiler, upp och extraheras. Videorna, helst i .mp4-format, laddas upp i en S3-bucket. Använda create_video
metod i video
API, ett videoobjekt skapas med videosökvägen som indata. Detta infogar data om varje video i Aurora-databasen. Alla andra filtyper, som JSON-filer, anses vara metadata och laddas upp på liknande sätt, men inget videoobjekt skapas. En lista med namn på filer och videofiler som extraherats skickas till nästa steg.
Insändare Lambdafunktion
Submitter-funktionen tar videofilerna som extraherades av Initializer och skapar mini-batcher av videoramar som bilder. De flesta nuvarande datorseende modeller i produktionen har tränats på bilder så även när video bearbetas separeras de först i bildramar innan modellen sluter sig. Den här nuvarande lösningen som använder en toppmodern modell för poseringsuppskattning är inte annorlunda – ramsatserna från insändaren skickas till Kinesis Data Streams för att initiera steget att generera slutledning.
Först laddas videofilen ner av Lambda-funktionen. Bildfrekvensen och antalet bildrutor beräknas med hjälp av FileVideoStream
modul från imutils.video
bearbetningsbibliotek. Ramarna extraheras och grupperas enligt en specificerad minibatchstorlek, vilket är en av de nyckelparametrar som kan avstämmas i denna pipeline. Med hjälp av Python pickle-biblioteket serialiseras data och laddas upp till Amazon S3. Därefter skapas ett frame batch-objekt och metadataposten skapas i Aurora-databasen. Denna Lambda-funktion byggdes med hjälp av en Dockerfile med beroenden på opencv-python
, numpy
och imutils
bibliotek.
Slutförande Kontrollera Lambda-funktionen
Funktionen Completion Check fortsätter att fråga i Aurora-databasen för att se, för varje video i .zip-paketet för det här aktuella jobbet, hur många bildrutor som har statusen COMPLETED. När alla bildrutor för alla videor är klara är denna kontrollprocess klar.
Collector Lambda funktion
Samlarfunktionen tar utdata från slutledningarna som utfördes på varje bildruta under konsumentstadiet och kombinerar dem över en bildrutebatch och över en video. Den kombinerade sammanslagna datan laddas sedan upp till en S3-bucket. Funktionen anropar sedan Cortex efterbearbetnings-API för en viss ML-pipeline för att utföra eventuella efterbearbetningsberäkningar och lägger till de aggregerade resultaten via video till utdatahinken. Många av dessa mätvärden beräknas över ramar, såsom hastighet, acceleration och ledvinkel, så denna beräkning måste utföras på aggregerad data. De huvudsakliga utdata inkluderar nyckelpunkters data (sammanställd i CSV-format), BMA-beräkningar (som acceleration) och visuell överlagring av nyckelpunkter som läggs till varje bildruta i en bildfil.
Generering av skalbar ställningsuppskattning
Bearbetningsmotorn som driver skalningen av ML-inferens sker i detta skede. Det involverar tre huvuddelar, var och en med sina egna samtidighetsspakar som kan ställas in för latensavvägningar (se följande diagram).
Den här arkitekturen möjliggör experimentering med att testa latensvinster, såväl som flexibilitet för framtiden när arbetsbelastningar kan ändras med olika blandningar av slutanvändarsegment som kommer åt applikationen.
Kinesis dataströmmar
Teamet valde Kinesis Data Streams eftersom det vanligtvis används för att hantera strömmande data, och i det här fallet passar det bra eftersom det kan hantera rambatcher på ett liknande sätt för att ge skalbarhet och parallellisering. I Submitter Lambda-funktionen används Kinesis Boto3-klienten, med put_record
metod som skickar in metadata som är associerade med en enskild bildrutebatch, såsom frame batch ID, frame batch start frame, frame batch slut frame, bildform, bildhastighet och video ID.
Vi definierade olika konfigurationer för jobbköer och Kinesis-dataströmmar för att ställa in nivåer av genomströmning som kopplar tillbaka till prioritetsnivån för olika användargrupper. Tillgång till olika nivåer av processorkraft är länkad genom att skicka en projektkö ARN när du skapar ett nytt projekt med hjälp av project
API. Varje användargrupp kopplas sedan till ett visst projekt när användargruppen skapas. Tre standardströmkonfigurationer definieras i AWS serverlös applikationsmodell (AWS SAM) infrastrukturmall:
- Standard -
JobStreamShardCount
- Budget -
PriorityJobStreamShardCount
- Hög prioritet -
HighPriorityJobStreamShardCount
Teamet använde några olika spakar för att differentiera processorkraften för varje ström eller justera systemets latens, vilket sammanfattas i följande tabell.
Spak | Beskrivning | Standardvärde |
Skärva | En skärva är inbyggd i Kinesis Dataströmmar; det är basenheten för genomströmning för intag. Standard är 1MB/sek, vilket motsvarar 1,000 XNUMX dataposter per sekund. | 2 |
KinesisBatchSize |
Det maximala antalet poster som Kinesis Data Streams hämtar i en enda batch innan lambdafunktionen för konsumenter anropas. | 1 |
KinesisParallelizationFactor |
Antalet batcher som ska bearbetas från varje shard samtidigt. | 1 |
Förbättrad fan-out | Datakonsumenter som har aktiverat utökad fan-out har en dedikerad intagsgenomströmning per konsument (som standardinställningen 1 MB/sek) istället för att dela kapaciteten mellan konsumenter. | off |
Konsument Lambda funktion
Ur Kinesis Data Streams perspektiv är en datakonsument en AWS-tjänst som hämtar data från en dataströmsbit när data genereras i en ström. Denna applikation använder en Consumer Lambda-funktion, som anropas när meddelanden skickas från dataströmsköerna. Varje konsumentfunktion bearbetar en rambatch genom att utföra följande steg. Först görs ett anrop till Cortex-processorns API synkront, vilket är den slutpunkt som är värd för modellinferenspipeline (se nästa avsnitt om Amazon EKS med Cortex för mer information). Resultaten lagras i Amazon S3, och en uppdatering görs av databasen genom att ändra statusen för den bearbetade rambatchen till Complete
. Felhantering är inbyggd för att hantera Cortex API-anropet med en återförsöksslinga för att hantera eventuella 504-fel från Cortex-klustret, med antalet återförsök inställt på 5.
Amazon EKS med Cortex för ML-inferens
Teamet använde Amazon EKS, en hanterad Kubernetes-tjänst i AWS, som beräkningsmotor för ML-inferens. Ett designval gjordes för att använda Amazon EKS för att vara värd för ML-slutpunkter, vilket ger flexibiliteten att köra uppströms Kubernetes med möjlighet till kluster som båda helt hanteras i AWS via AWS Fargate, eller lokal hårdvara via Amazon EKS var som helst. Detta var en viktig del av funktionalitet som önskades av Intel OTG, som gav möjligheten att koppla upp den här applikationen till specialiserad hårdvara på plats, till exempel.
De tre ML-modellerna som var byggstenarna för att konstruera inferenspipelines var en anpassad Yolo-modell (för objektdetektering), en anpassad HRNet-modell (för 2D-positionsuppskattning) och en 3DMPPE-modell (för 3D-positionsuppskattning) (se föregående ML-sektionen för mer information). De använde öppen källkod Cortex bibliotek för att hantera distribution och hantering av ML-slutpunkter för pipeline-slutpunkter, och lansering och distribution av Amazon EKS-kluster. Var och en av dessa modeller paketerades i Docker-behållare – modellfiler lagrades i Amazon S3 och modellbilder lagrades i Amazon Elastic Container Registry (Amazon ECR) – och distribueras som Cortex Realtime API:er. Versioner av modellbehållarna som körs på CPU och GPU skapades för att ge flexibilitet för typen av datorhårdvara. I framtiden, om ytterligare modeller eller modellpipelines behöver läggas till, kan de helt enkelt skapa ytterligare Cortex Realtime API:er.
De konstruerade sedan slutledningspipelines genom att sammansätta Cortex Realtime-modellens API:er till Cortex Realtime pipeline-API:er. Ett enda Realtime pipeline API bestod av anrop av en sekvens av Realtime modell API:er. Konsumentlambdafunktionerna behandlade en pipeline
API som en svart låda, med ett enda API-anrop för att hämta den slutliga slutledningsutgången för en bild. Två pipelines skapades: en 2D-pipeline och en 3D-pipeline.
2D-pipelinen kombinerar ett avkodningsförbearbetningssteg, objektdetektering med hjälp av en anpassad Yolo-modell för att lokalisera atleten och producera begränsningsrutor, och slutligen en anpassad HRNet-modell för att skapa 2D-nyckelpunkter för ställningsuppskattning.
3D-pipelinen kombinerar ett avkodningsförbearbetningssteg, objektdetektering med hjälp av en anpassad Yolo-modell för att lokalisera idrottaren och producera begränsningsrutor, och slutligen en 3DMPPE-modell för att skapa 3D-nyckelpunkter för ställningsuppskattning.
Efter att ha genererat slutsatser om en grupp ramar, inkluderar varje pipeline också en separat efterbearbetningsändpunkt i Realtime Cortex som genererar tre huvudutgångar:
- Aggregerad huvudnyckel pekar data till en enda CSV-fil
- BMA-beräkningar (som acceleration)
- Visuell överlagring av nyckelpunkter som läggs till varje bildruta i en bildfil
Collector Lambda-funktionen skickar lämplig metadata som är associerad med en viss video, såsom bildrute-ID:n och S3-platserna för ställningsuppskattningsinferensutgångarna, till slutpunkten för att generera dessa efterbearbetningsutgångar.
Cortex är designat för att integreras med Amazon EKS och kräver bara en klusterkonfigurationsfil och ett enkelt kommando för att starta ett Kubernetes-kluster:
En annan spak för prestandajustering var instanskonfigurationen för beräkningsklustren. Tre nivåer skapades med olika mixar av M5- och G4dn-instanser, kodifierade som .yaml-filer med specifikationer som klusternamn, region och instanskonfiguration och mix. M5-instanser är CPU-baserade till lägre kostnad och G4dn är GPU-baserade med högre kostnader för att ge vissa avvägningar mellan kostnad och prestanda.
Driftövervakning
För att upprätthålla operativa loggningsstandarder inkluderar alla Lambda-funktioner kod för att registrera och mata loggar via Amazon Kinesis Data Firehose. Till exempel loggas varje rambatch som bearbetas från Submitter Lambda-funktionen med tidsstämpeln, namnet på åtgärden och Lambda-funktionens svar JSON och sparas i Amazon S3. Följande diagram illustrerar detta steg i arkitekturen.
konfiguration
Implementeringen hanteras med AWS SAM, ett ramverk med öppen källkod för att bygga serverlösa applikationer i AWS. AWS SAM gör att infrastrukturdesign, inklusive funktioner, API:er, databaser och händelsekällmappningar, kan kodifieras och enkelt distribueras i nya AWS-miljöer. Under distributionen översätts AWS SAM-syntaxen till AWS molnformation att hantera infrastrukturförsörjningen.
A template.yaml
filen innehåller infrastrukturspecifikationerna tillsammans med inställbara parametrar, såsom Kinesis Data Streams latensspakar som beskrivs i de föregående avsnitten. A samconfig.toml
filen innehåller distributionsparametrar som stacknamn, S3-bucket-namn där programfiler som Lambda-funktionskod lagras och resurstaggar för spårningskostnad. Ett deploy.sh-skalskript med de enkla kommandona är allt som krävs för att bygga och distribuera hela mallen:
Användarens arbetsflöde
Sammanfattningsvis, efter att infrastrukturen har distribuerats kan du följa detta arbetsflöde för att komma igång:
- Skapa en Intel 3DAT-klient med hjälp av klientbiblioteket.
- Använd API:et för att skapa en ny instans av en pipeline som motsvarar den typ av bearbetning som krävs, till exempel en för 3D-positionsuppskattning.
- Skapa en ny instans av ett projekt, passera i klustret ARN och Kinesis kö ARN.
- Skapa en ny instans av en pipelineparameteruppsättning.
- Skapa en ny instans av pipelineparametrar som mappar till pipelineparameteruppsättningen.
- Skapa en ny användargrupp som är associerad med ett projekt-ID och ett parameteruppsättnings-ID för pipeline.
- Skapa en ny användare som är associerad med användargruppen.
- Ladda upp en .zip-fil med videor till Amazon S3 med en fördefinierad S3-URL som genereras av uppladdningsfunktionen i jobb-API:et.
- Skicka in en
create_job
API-anrop, med jobbparametrar som anger plats för videofilerna. Detta startar bearbetningsjobbet.
Slutsats
Applikationen är nu live och redo att testas med både idrottare och tränare. Intel OTG är glada över att göra innovativ poseringsuppskattningsteknik med hjälp av datorseende tillgänglig för en mängd olika användare, från utvecklare till idrottare till programvaruleverantörer.
AWS-teamet brinner för att hjälpa kunder som Intel OTG att accelerera sin ML-resa, från idé- och upptäcktsstadiet med ML Solutions Lab till härdnings- och implementeringsstadiet med AWS ML ProServe. Vi kommer alla att titta noga på OS i Tokyo 2021 i sommar för att föreställa oss alla framsteg som ML kan låsa upp inom sport.
Kom igång idag! Utforska ditt användningsfall med de tjänster som nämns i det här inlägget och många andra på AWS Management Console.
Om författarna
Han Man är Senior Manager- Machine Learning & AI på AWS baserad i San Diego, CA. Han har en doktorsexamen i teknik från Northwestern University och har flera års erfarenhet som managementkonsult med rådgivning till kunder inom tillverkning, finansiella tjänster och energi. Idag arbetar han passionerat med kunder från en mängd olika branscher för att utveckla och implementera maskininlärning och AI-lösningar på AWS. Han tycker om att följa NBA och spela basket på fritiden.
Iman Kamyabi är en ML-ingenjör med AWS Professional Services. Han har arbetat med ett brett spektrum av AWS-kunder för att kämpa för bästa praxis för att sätta upp repeterbara och pålitliga ML-pipelines.
Jonathan Lee är chef för Sports Performance Technology, Olympic Technology Group på Intel. Han studerade tillämpningen av maskininlärning på hälsa som grundutbildare vid UCLA och under sitt examensarbete vid University of Oxford. Hans karriär har fokuserat på utveckling av algoritmer och sensorer för hälsa och mänsklig prestanda. Han leder nu 3D Athlete Tracking-projektet hos Intel.
Nelson Leung är plattformsarkitekt i Sports Performance CoE hos Intel, där han definierar end-to-end-arkitektur för avancerade produkter som förbättrar idrottarens prestanda. Han leder också implementering, distribution och produktisering av dessa maskininlärningslösningar i stor skala till olika Intel-partners.
Troy Squillaci är DecSecOps-ingenjör på Intel där han levererar professionella mjukvarulösningar till kunder genom DevOps bästa praxis. Han tycker om att integrera AI-lösningar i skalbara plattformar inom en mängd olika domäner.
Paul Min är en Associate Solutions Architect Intern på Amazon Web Services (AWS), där han hjälper kunder över olika branschvertikaler att utveckla sitt uppdrag och påskynda deras molnintroduktion. Tidigare på Intel arbetade han som Software Engineering Intern för att hjälpa till att utveckla 3D Athlete Tracking Cloud SDK. Utanför jobbet tycker Paul om att spela golf och kan höras sjunga.
- Myntsmart. Europas bästa bitcoin- och kryptobörs.
- Platoblockchain. Web3 Metaverse Intelligence. Kunskap förstärkt. FRI TILLGÅNG.
- CryptoHawk. Altcoin radar. Gratis provperiod.
- Källa: https://aws.amazon.com/blogs/machine-learning/the-intel3d-athlete-tracking-3dat-scalable-architecture-deploys-pose-estimation-models-using-amazon-kinesis-data-streams- och-amazon-eks/
- "
- &
- 000
- 100
- 2021
- 3d
- Om oss
- accelerera
- tillgång
- tillgänglig
- Enligt
- Konto
- tvärs
- Handling
- åtgärder
- Dessutom
- Annat
- administration
- Antagande
- AI
- algoritm
- Alla
- amason
- Amazon Web Services
- bland
- api
- API: er
- Ansökan
- tillämpningar
- lämpligt
- arkitektur
- argument
- delad
- Associate
- idrottare
- attribut
- Automat
- AWS
- säkerhetskopiering
- Basketboll
- innan
- Fördelarna
- BÄST
- bästa praxis
- Svart
- Blogg
- kropp
- Box
- SLUTRESULTAT
- Byggnad
- Ring
- Kapacitet
- vilken
- Karriär
- fall
- centrala
- champion
- byta
- val
- klienter
- cloud
- koda
- samling
- Kollektorn
- kombinerad
- komponent
- Compute
- dator
- konfiguration
- anslutning
- konsult
- Konsumenten
- konsumenter
- Behållare
- Behållare
- innehåller
- fortsätter
- kontroll
- samordna
- Kärna
- Motsvarande
- skapa
- skapas
- skapar
- Skapa
- skapande
- referenser
- kritisk
- avgörande
- Aktuella
- För närvarande
- beställnings
- kund
- Kunder
- allra senaste
- datum
- Databas
- databaser
- dag
- dedicerad
- djupare
- levererar
- distribuera
- utplacerade
- utplacering
- vecklas ut
- Designa
- utformade
- detalj
- detaljerad
- detaljer
- Detektering
- utveckla
- Utvecklare
- utvecklare
- Utveckling
- olika
- skilja
- rikta
- Direktör
- Upptäckten
- displayer
- Hamnarbetare
- inte
- domäner
- ner
- under
- lätt
- Slutpunkt
- energi
- Motor
- ingenjör
- Teknik
- Miljö
- händelse
- exempel
- exciterade
- befintliga
- förväntar
- erfarenhet
- utforska
- Leverans
- Slutligen
- finansiella
- finansiella tjänster
- Förnamn
- passa
- FLOTTA
- Flexibilitet
- flexibel
- fokuserade
- följer
- efter
- följer
- format
- framåtblickande
- RAM
- Ramverk
- fungera
- funktionella
- funktionalitet
- funktioner
- framtida
- generera
- generera
- generering
- Ge
- Målet
- god
- GPU
- uppgradera
- Grupp
- Gruppens
- hantera
- Arbetsmiljö
- hårdvara
- Hälsa
- hört
- hjälpa
- hjälpa
- hjälper
- här.
- högre
- Hur ser din drömresa ut
- HTTPS
- humant
- Identitet
- bild
- genomföra
- genomförande
- med Esport
- innefattar
- innefattar
- Inklusive
- individuellt
- industrier
- industrin
- Infrastruktur
- innovativa
- ingång
- Insert
- installera
- integrerade
- integrering
- Intel
- Intelligens
- interaktion
- Gränssnitt
- IT
- Jobb
- Lediga jobb
- resa
- Nyckel
- lab
- lansera
- lansera
- Leads
- inlärning
- Nivå
- Bibliotek
- linje
- Lista
- läser in
- läge
- platser
- Maskinen
- maskininlärning
- gjord
- bibehålla
- större
- GÖR
- människa
- hantera
- förvaltade
- ledning
- Produktion
- karta
- kartläggning
- nämnts
- metoder
- Metrics
- minsta
- Mission
- ML
- Mobil
- Mobila applikationer
- modell
- modeller
- modulära
- mer
- mest
- multipel
- namn
- NBA
- nödvändigt för
- behov
- antal
- OS
- öppnas
- driva
- optimerad
- Alternativet
- beställa
- Övriga
- egen
- oxford
- paket
- del
- särskilt
- särskilt
- partner
- Förbi
- brinner
- Mönster
- procentuell
- prestanda
- utför
- perspektiv
- bit
- plattform
- Plattformar
- i
- Poesi
- poäng
- möjlig
- kraft
- den mäktigaste
- Förbered
- föregående
- primär
- Principen
- prioritet
- process
- processer
- bearbetning
- Processorn
- producera
- Produktion
- Produkter
- professionell
- projektet
- ge
- ger
- Syftet
- område
- Raw
- realtid
- känner igen
- post
- register
- om
- pålitlig
- förfrågningar
- kräver
- Obligatorisk
- Krav
- Kräver
- resurs
- Resurser
- respons
- Resultat
- Körning
- rinnande
- Säkerhet
- San
- skalbarhet
- skalbar
- Skala
- skalning
- sDK
- säkra
- segment
- Server
- service
- Tjänster
- in
- inställning
- Forma
- delning
- Shell
- visas
- liknande
- Liknande
- Enkelt
- Storlek
- So
- Mjukvara
- mjukvara som en service
- mjukvaruutveckling
- lösning
- Lösningar
- några
- någon
- specialiserad
- specifikationer
- fart
- Sporter
- stapel
- Etapp
- standard
- standarder
- starta
- igång
- startar
- Ange
- state-of-the-art
- status
- förvaring
- lagra
- ström
- streaming
- lämnats
- Senare
- sommar
- stödja
- Stöder
- system
- tar
- grupp
- Teknologi
- Testning
- därför
- Genom
- SLIPS
- tid
- i dag
- tillsammans
- Tokyo
- spår
- Spårning
- typer
- typiskt
- UCLA
- universitet
- University of Oxford
- låsa
- Uppdatering
- användning
- användare
- Använda
- värde
- mängd
- olika
- vertikaler
- Video
- Video
- syn
- webb
- webbservice
- VEM
- utan
- Arbete
- arbetade
- arbetssätt
- år