Ce billet de blog est co-écrit par Jonathan Lee, Nelson Leung, Paul Min et Troy Squillaci d'Intel.
In Partie 1 de cet article, nous avons expliqué comment Intel®3DAT a collaboré avec Services professionnels d'apprentissage automatique AWS (MLPS) pour créer une application AI SaaS évolutive. 3DAT utilise la vision par ordinateur et l'IA pour reconnaître, suivre et analyser plus de 1,000 XNUMX points de données biomécaniques à partir d'une vidéo standard. Il permet aux clients de créer des produits biomécaniques riches et puissants, tels que des applications Web et mobiles avec des données de performances détaillées et des visualisations en trois dimensions.
Dans la partie 2 de cet article, nous approfondissons chaque étape de l'architecture. Nous explorons les services AWS utilisés pour répondre aux exigences de conception 3DAT, y compris Flux de données Amazon Kinesis ainsi que le Service Amazon Elastic Kubernetes (Amazon EKS), afin de déployer de manière évolutive les modèles d'estimation de pose nécessaires pour cette application logicielle en tant que service (SaaS).
Aperçu de l'architecture
L'objectif principal de l'équipe MLPS était de produire les pipelines de modèles d'estimation de pose 2D et 3D et de créer une application fonctionnelle et évolutive. Le diagramme suivant illustre l'architecture de la solution.
L'architecture complète est décomposée en cinq composants principaux :
- Couches d'interface d'application utilisateur
- Base de données
- Orchestration des flux de travail
- Génération d'inférence d'estimation de pose évolutive
- Suivi opérationnel
Entrons dans les détails de chaque composant, de leurs interactions et de la justification des choix de conception.
Couches d'interface d'application utilisateur
Le schéma suivant montre les couches d'interface d'application qui fournissent l'accès utilisateur et le contrôle de l'application et de ses ressources.
Ces points d'accès prennent en charge différents cas d'utilisation basés sur différentes personnalités de clients. Par exemple, un utilisateur d'application peut soumettre une tâche via la CLI, tandis qu'un développeur peut créer une application à l'aide du SDK Python et intégrer l'intelligence d'estimation de pose dans ses applications. La CLI et le SDK sont construits en tant que composants modulaires - les deux couches sont des enveloppes de la couche API, qui est construite à l'aide Passerelle d'API Amazon pour résoudre les appels d'API et AWS Lambda associé fonctions, qui s'occupent de la logique backend associée à chaque appel d'API. Ces couches étaient un élément crucial pour l'équipe Intel OTG car elles ouvrent une large base de clients qui peuvent utiliser efficacement cette application SaaS.
Couche API
La solution dispose d'un ensemble de base de neuf API, qui correspondent aux types d'objets qui fonctionnent sur cette plate-forme. Chaque API possède un fichier Python qui définit les actions d'API pouvant être exécutées. La création de nouveaux objets se voit automatiquement attribuer un ID d'objet de manière séquentielle. Les attributs de ces objets sont stockés et suivis dans le Amazon Aurora sans serveur base de données utilisant cet ID. Par conséquent, les actions de l'API sont liées aux fonctions définies dans un fichier central qui contient la logique principale pour interroger la base de données Aurora. Cette logique backend utilise le Boto3 Client Amazon RDS DataService pour accéder au cluster de bases de données.
La seule exception est la /job
API, qui a un create_job
méthode qui gère la soumission vidéo pour créer une nouvelle tâche de traitement. Cette méthode lance le Fonctions d'étape AWS logique de flux de travail pour exécuter le travail. En passant dans un job_id
, cette méthode utilise le Boto3 Client Step Functions appeler le start_execution
méthode pour une donnée stateMachineARN
(Nom de la ressource Amazon).
Les huit API d'objet ont les méthodes et le modèle d'accès similaire comme résumé dans le tableau suivant.
Type de méthode | Nom de la fonction | Description |
ÉCONOMISEZ | list_[object_name]s |
Sélectionne tous les objets de ce type dans la base de données et les affiche. |
POSTEZ | create_[object] |
Insère un nouvel enregistrement d'objet avec les entrées requises dans la base de données. |
ÉCONOMISEZ | get_[object] |
Sélectionne les attributs d'objet en fonction de l'ID d'objet dans la base de données et s'affiche. |
PUT | update_[object] |
Met à jour un enregistrement d'objet existant avec les entrées requises. |
EFFACER | delete_[object] |
Supprime un enregistrement d'objet existant de la base de données en fonction de l'ID d'objet. |
Les détails des neuf API sont les suivants :
- / utilisateur – Un utilisateur est l'identité d'une personne autorisée à soumettre des travaux à cette application. La création d'un utilisateur nécessite un nom d'utilisateur, une adresse e-mail d'utilisateur et un ID de groupe auquel l'utilisateur appartient.
- /groupe_utilisateur – Un groupe d'utilisateurs est un ensemble d'utilisateurs. Chaque groupe d'utilisateurs est mappé à un projet et à un ensemble de paramètres de pipeline. Pour avoir différents niveaux (en termes de ressources d'infrastructure et de paramètres de pipeline), les utilisateurs sont divisés en groupes d'utilisateurs. Chaque utilisateur ne peut appartenir qu'à un seul groupe d'utilisateurs. La création d'un groupe d'utilisateurs nécessite un ID de projet, un ID d'ensemble de paramètres de pipeline, un nom de groupe d'utilisateurs et une description de groupe d'utilisateurs. Notez que les groupes d'utilisateurs sont différents des rôles d'utilisateur définis dans le compte AWS. Ce dernier est utilisé pour fournir différents niveaux d'accès en fonction de leurs rôles d'accès (par exemple admin).
- /projet – Un projet est utilisé pour regrouper différents ensembles de ressources d'infrastructure. Un projet est associé à un seul
project_cluster_url
(cluster Aurora) pour enregistrer les utilisateurs, les travaux et d'autres métadonnées, unproject_queue_arn
(Kinesis Data Streams ARN) et un environnement d'exécution de calcul (actuellement contrôlé via Cortex) utilisé pour exécuter l'inférence sur les lots d'images ou le post-traitement sur les vidéos. Chaque groupe d'utilisateurs est associé à un projet, et ce mécanisme est la façon dont différents niveaux sont activés en termes de latence et de puissance de calcul pour différents groupes d'utilisateurs. La création d'un projet nécessite un nom de projet, une URL de cluster de projet et un ARN de file d'attente de projet. - /pipeline – Un pipeline est associé à une configuration unique pour une séquence de conteneurs de traitement qui effectuent le traitement vidéo dans le cluster de génération d'inférence Amazon EKS coordonné par Cortex (voir la section sur la génération d'inférence de traitement vidéo pour plus de détails). En règle générale, cela se compose de trois conteneurs : prétraitement et décodage, détection d'objet et estimation de pose. Par exemple, l'étape de décodage et de détection d'objet est la même pour les pipelines 2D et 3D, mais l'échange du dernier conteneur à l'aide de HRNet ou de 3DMPPE entraîne le jeu de paramètres pour les pipelines de traitement 2D et 3D. Vous pouvez créer de nouvelles configurations pour définir les pipelines possibles qui peuvent être utilisés pour le traitement, et cela nécessite en entrée un nouveau fichier Python dans le référentiel Cortex qui détaille la séquence d'appels de points de terminaison du modèle qui définissent ce pipeline (voir la section sur la génération d'inférences de traitement vidéo ). Le point de terminaison du pipeline est le point de terminaison Cortex qui est appelé pour traiter une seule trame. La création d'un pipeline nécessite un nom de pipeline, une description de pipeline et un point de terminaison de pipeline.
- /pipeline_parameter_set – Un ensemble de paramètres de pipeline est une collection JSON flexible de plusieurs paramètres (un runtime de configuration de pipeline) pour un pipeline particulier, et est ajouté pour offrir une flexibilité pour une personnalisation future lorsque plusieurs runtimes de configuration de pipeline sont nécessaires. Les groupes d'utilisateurs peuvent être associés à un ensemble de paramètres de pipeline particulier, et son but est d'avoir différents groupes de paramètres par groupe d'utilisateurs et par pipeline. Il s'agissait d'un ajout prospectif important pour Intel OTG afin d'intégrer la personnalisation qui prend en charge la portabilité lorsque différents clients, en particulier les ISV, commencent à utiliser l'application.
- /paramètres_pipeline – Une collection unique de paramètres de pipeline est une instanciation d'un ensemble de paramètres de pipeline. Cela en fait un mappage 1: plusieurs d'un jeu de paramètres de pipeline sur des paramètres de pipeline. Cette API nécessite un ID de pipeline à associer à l'ensemble de paramètres de pipeline qui permet la création d'un pipeline pour un mappage 1:1 des paramètres de pipeline au pipeline. Les autres entrées requises par cette API sont un ID d'ensemble de paramètres de pipeline, une valeur de paramètres de pipeline et un nom de paramètres de pipeline.
- /vidéo – Un objet vidéo est utilisé pour définir des vidéos individuelles qui composent un package .zip soumis lors d'une tâche. Ce fichier est divisé en plusieurs vidéos après la soumission. Une vidéo est liée à la
job_id
pour le travail où le package .zip est soumis, et Service de stockage simple Amazon (Amazon S3) pour l'emplacement des vidéos brutes séparées et les résultats de post-traitement de chaque vidéo. L'objet vidéo contient également un pourcentage de progression de la vidéo, qui est constamment mis à jour lors du traitement des lots d'images individuels de cette vidéo, ainsi qu'un indicateur d'état de la vidéo pour complet ou non complet. La création d'une vidéo nécessite un ID de tâche, un chemin vidéo, un chemin de résultats vidéo, un pourcentage de progression vidéo et un statut vidéo. - /frame_batch - A
frame_batch
L'objet est un mini-lot d'images créé en échantillonnant une seule vidéo. La séparation d'une vidéo en lots d'images de taille normale fournit un levier pour régler la latence et augmente la parallélisation et le débit. Il s'agit de l'unité granulaire qui est exécutée via Kinesis Data Streams pour l'inférence. La création d'un lot d'images nécessite un ID vidéo, un numéro de début de lot d'images, un numéro de fin de lot d'images, un chemin d'entrée de lot d'images, un chemin de résultats de lot d'images et un état de lot d'images. - /travail – Cette API d'interaction est utilisée pour la soumission de fichiers afin de démarrer une tâche de traitement. Cette API a une fonction différente des autres API d'objet, car il s'agit du chemin direct pour interagir avec la coordination du flux de travail Step Functions du backend de traitement vidéo et le cluster Amazon EKS. Cette API nécessite un ID utilisateur, un ID de projet, un ID de pipeline, un ID d'ensemble de paramètres de pipeline, des paramètres de tâche et un état de tâche. Dans les paramètres de la tâche, un chemin d'accès au fichier d'entrée est spécifié, qui est l'emplacement dans Amazon S3 où se trouve le package .zip des vidéos à traiter. Le téléchargement de fichiers est géré avec le
upload_handler
méthode, qui génère une URL S3 pré-signée pour que l'utilisateur place un fichier. Un WORKFLOW_STATEMACHINE_ARN est une variable d'environnement transmise aucreate_job
API pour spécifier où un package vidéo .zip avec un chemin de fichier d'entrée est soumis pour démarrer une tâche.
Le tableau suivant résume les fonctions de l'API.
Type de méthode | Fonction | Description |
ÉCONOMISEZ | list_jobs |
Sélectionne tous les travaux de la base de données et les affiche. |
POSTEZ | create_ job |
Insère un nouvel enregistrement de tâche avec l'ID utilisateur, l'ID de projet, l'ID de pipeline, l'ID d'ensemble de paramètres de pipeline, le chemin des résultats de la tâche, les paramètres de la tâche et l'état de la tâche. |
ÉCONOMISEZ | get_ job |
Sélectionne les attributs du travail en fonction de l'ID du travail dans la base de données et s'affiche. |
ÉCONOMISEZ | upload_handler |
Génère une URL S3 présignée comme emplacement pour le téléchargement du fichier .zip. Nécessite un nom de compartiment S3 et attend un type de fichier application/zip. |
Couche du SDK Python
En s'appuyant sur les API, l'équipe a créé une bibliothèque client Python SDK en tant que wrapper pour faciliter l'accès des développeurs aux méthodes de l'API. Ils ont utilisé l'open-source Poésie, qui gère l'empaquetage Python et la gestion des dépendances. Ils ont créé un client.py
fichier contenant des fonctions encapsulant chacune des API à l'aide de Python requests
bibliothèque pour gérer les demandes d'API et les exceptions.
Pour que les développeurs lancent le SDK Intel 3DAT, ils doivent installer et créer le package Poetry. Ensuite, ils peuvent ajouter une simple importation Python de intel_3dat_sdk
à n'importe quel code Python.
Pour utiliser le client, vous pouvez créer une instance du client, en spécifiant le point de terminaison de l'API :
Vous pouvez ensuite utiliser le client pour appeler les méthodes individuelles telles que le create_pipeline
(voir le code suivant), en prenant les arguments appropriés tels que le nom du pipeline et la description du pipeline.
Couche CLI
De même, l'équipe s'est appuyée sur les API pour créer une interface de ligne de commande pour les utilisateurs qui souhaitent accéder aux méthodes de l'API avec une interface simple sans avoir à écrire de code Python. Ils ont utilisé le package Python open-source Cliquez (Kit de création d'interface de ligne de commande). Les avantages de ce cadre sont l'imbrication arbitraire des commandes, la génération automatique de pages d'aide et la prise en charge du chargement différé des sous-commandes au moment de l'exécution. Dans le même client.py
comme dans le SDK, chaque méthode client du SDK a été encapsulée à l'aide de Click et les arguments de méthode requis ont été convertis en indicateurs de ligne de commande. Les entrées de drapeau sont ensuite utilisées lors de l'appel de la commande SDK.
Pour lancer la CLI, vous pouvez utiliser le CLI configure
commande. Vous êtes invité à saisir l'URL du point de terminaison :
Vous pouvez désormais utiliser la CLI pour appeler différentes commandes liées aux méthodes de l'API, par exemple :
Base de données
En tant que base de données, cette application utilise Aurora Serverless pour stocker les métadonnées associées à chacune des API avec MYSQL comme moteur de base de données. Le choix du service de base de données Aurora Serverless respecte le principe de conception visant à minimiser les frais d'infrastructure en utilisant les services AWS sans serveur lorsque cela est possible. Le schéma suivant illustre cette architecture.
Les mode moteur sans serveur répond au modèle d'utilisation intermittente, car cette application s'adapte à de nouveaux clients et les charges de travail sont encore incertaines. Lors du lancement d'un point de terminaison de base de données, une taille d'instance de base de données spécifique n'est pas requise, uniquement une plage minimale et maximale pour la capacité du cluster. Aurora Serverless gère le provisionnement approprié d'une flotte de routeurs et répartit la charge de travail entre les ressources. Aurora Serverless effectue automatiquement la conservation des sauvegardes pendant au moins 1 jour jusqu'à 35 jours. L'équipe a optimisé la sécurité en définissant la valeur par défaut sur la valeur maximale de 35.
De plus, l'équipe a utilisé le API de données pour gérer l'accès au cluster Aurora Serverless, qui ne nécessite pas de connexion persistante, et fournit à la place un point de terminaison HTTP sécurisé et une intégration avec les kits SDK AWS. Cette fonction utilise AWS Secrets Manager pour stocker les informations d'identification de la base de données afin qu'il ne soit pas nécessaire de transmettre explicitement les informations d'identification. Les scripts CREATE TABLE ont été écrits dans des fichiers .sql pour chacune des neuf tables correspondant aux neuf API. Étant donné que cette base de données contenait toutes les métadonnées et l'état des objets du système, les méthodes de l'API ont été exécutées à l'aide des commandes SQL appropriées (par exemple select * from Job
pour le list_jobs
API) et transmis à l'API execute_statement
méthode du client Amazon RDS dans l'API de données.
Orchestration des flux de travail
L'épine dorsale fonctionnelle de l'application a été gérée à l'aide de Step Functions pour coordonner le flux de travail, comme illustré dans le diagramme suivant.
La machine d'état consistait en une séquence de quatre fonctions Lambda, qui démarre lorsqu'une tâche est soumise à l'aide de la create_job
méthode de la job
API. L'ID utilisateur, l'ID du projet, l'ID du pipeline, l'ID de l'ensemble de paramètres du pipeline, le chemin des résultats de la tâche, les paramètres de la tâche et l'état de la tâche sont requis pour la création de la tâche. Vous pouvez d'abord télécharger un package .zip de fichiers vidéo en utilisant le upload_handler
de l'API du travail pour générer une URL S3 présignée. Lors de la soumission du travail, le chemin du fichier d'entrée est transmis via les paramètres du travail, pour spécifier l'emplacement du fichier. Cela démarre l'exécution de la machine d'état du workflow, déclenchant quatre étapes principales :
- Fonction Lambda d'initialisation
- Fonction Lambda de l'émetteur
- Vérification de l'achèvement de la fonction Lambda
- Fonction Lambda du collecteur
Fonction Lambda d'initialisation
La fonction principale de l'initialisateur est de séparer le package .zip en fichiers vidéo individuels et de les préparer pour l'émetteur. Tout d'abord, le fichier .zip est téléchargé, puis chaque fichier individuel, y compris les fichiers vidéo, est décompressé et extrait. Les vidéos, de préférence au format .mp4, sont téléchargées dans un compartiment S3. En utilisant le create_video
méthode dans le video
API, un objet vidéo est créé avec le chemin vidéo en entrée. Cela insère des données sur chaque vidéo dans la base de données Aurora. Tous les autres types de fichiers, tels que les fichiers JSON, sont considérés comme des métadonnées et téléchargés de la même manière, mais aucun objet vidéo n'est créé. Une liste des noms de fichiers et de fichiers vidéo extraits est transmise à l'étape suivante.
Fonction Lambda de l'émetteur
La fonction Submitter prend les fichiers vidéo qui ont été extraits par l'initialisateur et crée des mini-lots d'images vidéo sous forme d'images. La plupart des modèles de vision par ordinateur actuellement en production ont été entraînés sur des images, de sorte que même lorsque la vidéo est traitée, elles sont d'abord séparées en images avant l'inférence du modèle. Cette solution actuelle utilisant un modèle d'estimation de pose de pointe n'est pas différente : les lots d'images de l'émetteur sont transmis à Kinesis Data Streams pour lancer l'étape de génération d'inférence.
Tout d'abord, le fichier vidéo est téléchargé par la fonction Lambda. La fréquence d'images et le nombre d'images sont calculés à l'aide de la FileVideoStream
module de la imutils.video
bibliothèque de traitement. Les trames sont extraites et regroupées selon une taille de mini-lot spécifiée, qui est l'un des paramètres clés réglables de ce pipeline. À l'aide de la bibliothèque Python Pickle, les données sont sérialisées et téléchargées sur Amazon S3. Par la suite, un objet de lot de trames est créé et l'entrée de métadonnées est créée dans la base de données Aurora. Cette fonction Lambda a été créée à l'aide d'un Dockerfile avec des dépendances sur opencv-python
, numpy
ainsi que
imutils
bibliothèques.
Vérification de l'achèvement de la fonction Lambda
La fonction de vérification de l'achèvement continue d'interroger la base de données Aurora pour voir, pour chaque vidéo dans le package .zip pour cette tâche en cours, combien de lots d'images sont à l'état TERMINÉ. Lorsque tous les lots d'images pour toutes les vidéos sont terminés, ce processus de vérification est terminé.
Fonction Lambda du collecteur
La fonction Collector prend les sorties des inférences qui ont été effectuées sur chaque image au cours de l'étape Consommateur et les combine sur un lot d'images et sur une vidéo. Les données fusionnées combinées sont ensuite chargées dans un compartiment S3. La fonction appelle ensuite l'API de post-traitement Cortex pour un pipeline ML particulier afin d'effectuer tous les calculs de post-traitement, et ajoute les résultats agrégés par vidéo au compartiment de sortie. Bon nombre de ces métriques sont calculées sur plusieurs images, telles que la vitesse, l'accélération et l'angle de l'articulation, ce calcul doit donc être effectué sur les données agrégées. Les principaux résultats incluent les données des points clés du corps (agrégées au format CSV), les calculs BMA (tels que l'accélération) et la superposition visuelle des points clés ajoutés à chaque image dans un fichier image.
Génération d'inférence d'estimation de pose évolutive
Le moteur de traitement qui alimente la mise à l'échelle de l'inférence ML se produit à cette étape. Il implique trois éléments principaux, chacun ayant ses propres leviers de simultanéité qui peuvent être réglés pour des compromis de latence (voir le schéma suivant).
Cette architecture permet d'expérimenter les gains de latence de test, ainsi que la flexibilité pour l'avenir lorsque les charges de travail peuvent changer avec différentes combinaisons de segments d'utilisateurs finaux qui accèdent à l'application.
Flux de données Kinesis
L'équipe a choisi Kinesis Data Streams car il est généralement utilisé pour gérer les données en streaming, et dans ce cas, il est bien adapté car il peut gérer les lots de trames de la même manière pour fournir évolutivité et parallélisation. Dans la fonction Submitter Lambda, le client Kinesis Boto3 est utilisé, avec le put_record
méthode transmettant les métadonnées associées à un seul lot d'images, telles que l'ID du lot d'images, l'image de début du lot d'images, l'image de fin du lot d'images, la forme de l'image, la fréquence d'images et l'ID vidéo.
Nous avons défini diverses configurations de files d'attente de tâches et de flux de données Kinesis pour définir des niveaux de débit liés au niveau de priorité des différents groupes d'utilisateurs. L'accès à différents niveaux de puissance de traitement est lié en transmettant un ARN de file d'attente de projet lors de la création d'un nouveau projet à l'aide de project
API. Chaque groupe d'utilisateurs est ensuite lié à un projet particulier lors de la création du groupe d'utilisateurs. Trois configurations de flux par défaut sont définies dans le Modèle d'application sans serveur AWS Modèle d'infrastructure (AWS SAM) :
- Standard -
JobStreamShardCount
- Priorité -
PriorityJobStreamShardCount
- Haute priorité -
HighPriorityJobStreamShardCount
L'équipe a utilisé quelques leviers différents pour différencier la puissance de traitement de chaque flux ou régler la latence du système, comme résumé dans le tableau suivant.
Levier | Description | Valeur par défaut |
Tesson | Une partition est native de Kinesis Data Streams ; c'est l'unité de base du débit pour l'ingestion. La valeur par défaut est de 1 Mo/s, ce qui équivaut à 1,000 XNUMX enregistrements de données par seconde. | 2 |
KinesisBatchSize |
Le nombre maximal d'enregistrements que Kinesis Data Streams récupère dans un seul lot avant d'appeler la fonction Lambda consommateur. | 1 |
KinesisParallelizationFactor |
Le nombre de lots à traiter simultanément à partir de chaque partition. | 1 |
Distribution améliorée | Les consommateurs de données dont la diffusion améliorée est activée disposent d'un débit d'ingestion dédié par consommateur (par exemple, 1 Mo/s par défaut) au lieu de partager le débit entre les consommateurs. | de |
Fonction Lambda consommateur
Du point de vue de Kinesis Data Streams, un consommateur de données est un service AWS qui récupère les données d'une partition de flux de données lorsque les données sont générées dans un flux. Cette application utilise une fonction Consumer Lambda, qui est appelée lorsque des messages sont transmis à partir des files d'attente de flux de données. Chaque fonction Consommateur traite un lot de trames en effectuant les étapes suivantes. Tout d'abord, un appel est effectué de manière synchrone vers l'API du processeur Cortex, qui est le point de terminaison qui héberge le pipeline d'inférence de modèle (voir la section suivante concernant Amazon EKS avec Cortex pour plus de détails). Les résultats sont stockés dans Amazon S3 et une mise à jour est apportée à la base de données en modifiant le statut du lot de trames traité en Complete
. La gestion des erreurs est intégrée pour gérer l'appel de l'API Cortex avec une boucle de nouvelle tentative pour gérer toutes les erreurs 504 du cluster Cortex, avec un nombre de tentatives défini sur 5.
Amazon EKS avec Cortex pour l'inférence ML
L'équipe a utilisé Amazon EKS, un service Kubernetes géré dans AWS, comme moteur de calcul pour l'inférence ML. Un choix de conception a été fait pour utiliser Amazon EKS pour héberger des points de terminaison ML, offrant la flexibilité d'exécuter Kubernetes en amont avec l'option de clusters entièrement gérés dans AWS via AWSFargate, ou du matériel sur site via Amazon EKS n'importe où. Il s'agissait d'une fonctionnalité essentielle souhaitée par Intel OTG, qui offrait la possibilité de connecter cette application à du matériel spécialisé sur site, par exemple.
Les trois modèles ML qui étaient les éléments de base pour la construction des pipelines d'inférence étaient un modèle Yolo personnalisé (pour la détection d'objets), un modèle HRNet personnalisé (pour l'estimation de pose 2D) et un modèle 3DMPPE (pour l'estimation de pose 3D) (voir le précédent section ML pour plus de détails). Ils ont utilisé l'open-source Cortex bibliothèque pour gérer le déploiement et la gestion des points de terminaison du pipeline d'inférence ML, ainsi que le lancement et le déploiement des clusters Amazon EKS. Chacun de ces modèles a été regroupé dans des conteneurs Docker. Les fichiers de modèle ont été stockés dans Amazon S3 et les images de modèle ont été stockées dans Registre des conteneurs élastiques Amazon (Amazon ECR) et déployés en tant qu'API Cortex Realtime. Des versions des conteneurs de modèles qui s'exécutent sur CPU et GPU ont été créées pour offrir une flexibilité pour le type de matériel de calcul. À l'avenir, si des modèles ou des pipelines de modèles supplémentaires doivent être ajoutés, ils peuvent simplement créer des API Cortex Realtime supplémentaires.
Ils ont ensuite construit des pipelines d'inférence en composant ensemble les API du modèle Cortex Realtime dans les API du pipeline Cortex Realtime. Une seule API de pipeline en temps réel consistait à appeler une séquence d'API de modèle en temps réel. Les fonctions Consumer Lambda ont traité un pipeline
API en tant que boîte noire, utilisant un seul appel d'API pour récupérer la sortie d'inférence finale pour une image. Deux pipelines ont été créés : un pipeline 2D et un pipeline 3D.
Le pipeline 2D combine une étape de prétraitement de décodage, une détection d'objet à l'aide d'un modèle Yolo personnalisé pour localiser l'athlète et produire des boîtes englobantes, et enfin un modèle HRNet personnalisé pour créer des points clés 2D pour l'estimation de la pose.
Le pipeline 3D combine une étape de prétraitement de décodage, une détection d'objet à l'aide d'un modèle Yolo personnalisé pour localiser l'athlète et produire des boîtes englobantes, et enfin un modèle 3DMPPE pour créer des points clés 3D pour l'estimation de la pose.
Après avoir généré des inférences sur un lot de trames, chaque pipeline inclut également un point de terminaison Realtime Cortex de post-traitement distinct qui génère trois sorties principales :
- Données agrégées sur les points clés du corps dans un seul fichier CSV
- Calculs BMA (tels que l'accélération)
- Superposition visuelle des points clés ajoutés à chaque image dans un fichier image
La fonction Collector Lambda soumet les métadonnées appropriées associées à une vidéo particulière, telles que les ID de trame et les emplacements S3 des sorties d'inférence d'estimation de pose, au point de terminaison pour générer ces sorties de post-traitement.
Cortex est conçu pour être intégré à Amazon EKS et ne nécessite qu'un fichier de configuration de cluster et une simple commande pour lancer un cluster Kubernetes :
Un autre levier de réglage des performances était la configuration des instances pour les clusters de calcul. Trois niveaux ont été créés avec différents mélanges d'instances M5 et G4dn, codifiés sous forme de fichiers .yaml avec des spécifications telles que le nom du cluster, la région et la configuration et le mélange d'instances. Les instances M5 sont basées sur un CPU à moindre coût et G4dn sont basées sur un GPU à un coût plus élevé pour fournir des compromis coût/performance.
Suivi opérationnel
Pour maintenir les normes de journalisation opérationnelles, toutes les fonctions Lambda incluent du code pour enregistrer et ingérer les journaux via Firehose de données Amazon Kinesis. Par exemple, chaque lot de trames traité à partir de la fonction Submitter Lambda est enregistré avec l'horodatage, le nom de l'action et la réponse de la fonction Lambda JSON et enregistré dans Amazon S3. Le schéma suivant illustre cette étape de l'architecture.
Déploiement
Le déploiement est géré à l'aide d'AWS SAM, un framework open source pour la création d'applications sans serveur dans AWS. AWS SAM permet de codifier et de déployer facilement la conception de l'infrastructure, y compris les fonctions, les API, les bases de données et les mappages de sources d'événements dans de nouveaux environnements AWS. Lors du déploiement, la syntaxe AWS SAM est traduite en AWS CloudFormation gérer le provisionnement de l'infrastructure.
A template.yaml
Le fichier contient les spécifications de l'infrastructure ainsi que des paramètres réglables, tels que les leviers de latence Kinesis Data Streams détaillés dans les sections précédentes. UN samconfig.toml
Le fichier contient des paramètres de déploiement tels que le nom de la pile, le nom du compartiment S3 où les fichiers d'application tels que le code de la fonction Lambda sont stockés et les balises de ressource pour le suivi des coûts. Un script shell deploy.sh avec les commandes simples est tout ce qui est nécessaire pour créer et déployer l'intégralité du modèle :
Flux de travail utilisateur
En résumé, une fois l'infrastructure déployée, vous pouvez suivre ce workflow pour commencer :
- Créez un client Intel 3DAT à l'aide de la bibliothèque client.
- Utilisez l'API pour créer une nouvelle instance d'un pipeline correspondant au type de traitement requis, par exemple pour l'estimation de pose 3D.
- Créez une nouvelle instance d'un projet, en transmettant l'ARN du cluster et l'ARN de la file d'attente Kinesis.
- Créez une nouvelle instance d'un ensemble de paramètres de pipeline.
- Créez une nouvelle instance de paramètres de pipeline qui correspondent au jeu de paramètres de pipeline.
- Créez un nouveau groupe d'utilisateurs associé à un ID de projet et à un ID d'ensemble de paramètres de pipeline.
- Créez un nouvel utilisateur associé au groupe d'utilisateurs.
- Téléchargez un fichier .zip de vidéos sur Amazon S3 à l'aide d'une URL S3 pré-signée générée par la fonction de téléchargement dans l'API de travail.
- Soumettre un
create_job
Appel API, avec des paramètres de travail qui spécifient l'emplacement des fichiers vidéo. Cela démarre le travail de traitement.
Conclusion
L'application est maintenant en ligne et prête à être testée avec des athlètes et des entraîneurs. Intel OTG est ravi de rendre la technologie innovante d'estimation de pose utilisant la vision par ordinateur accessible à une variété d'utilisateurs, des développeurs aux athlètes en passant par les partenaires éditeurs de logiciels.
L'équipe AWS se passionne pour aider les clients comme Intel OTG à accélérer leur parcours ML, de l'étape d'idéation et de découverte avec ML Solutions Lab à l'étape de durcissement et de déploiement avec AWS ML ProServe. Nous surveillerons tous de près les Jeux olympiques de Tokyo en 2021 cet été pour imaginer tous les progrès que le ML peut débloquer dans le sport.
Commencer aujourd'hui! Explorez votre cas d'utilisation avec les services mentionnés dans cet article et bien d'autres sur le Console de gestion AWS.
À propos des auteurs
Homme Han est Senior Manager - Machine Learning & AI chez AWS basé à San Diego, CA. Il est titulaire d'un doctorat en ingénierie de l'Université Northwestern et possède plusieurs années d'expérience en tant que consultant en gestion conseillant des clients dans les domaines de la fabrication, des services financiers et de l'énergie. Aujourd'hui, il travaille avec passion avec des clients de divers secteurs pour développer et mettre en œuvre des solutions d'apprentissage automatique et d'IA sur AWS. Il aime suivre la NBA et jouer au basket pendant son temps libre.
Iman Kamyabi est un ingénieur ML avec AWS Professional Services. Il a travaillé avec un large éventail de clients AWS pour défendre les meilleures pratiques dans la mise en place de pipelines ML reproductibles et fiables.
Jonathan Lee est le directeur de la technologie des performances sportives, Olympic Technology Group chez Intel. Il a étudié l'application de l'apprentissage automatique à la santé en tant que premier cycle à l'UCLA et pendant ses études supérieures à l'Université d'Oxford. Sa carrière s'est concentrée sur le développement d'algorithmes et de capteurs pour la santé et la performance humaine. Il dirige désormais le projet 3D Athlete Tracking chez Intel.
Nelson Leung est l'architecte de plate-forme du CdE de la performance sportive chez Intel, où il définit une architecture de bout en bout pour des produits de pointe qui améliorent les performances des athlètes. Il dirige également la mise en œuvre, le déploiement et la production de ces solutions d'apprentissage automatique à grande échelle pour différents partenaires Intel.
Troy Squillaci est un ingénieur DecSecOps chez Intel où il fournit des solutions logicielles professionnelles aux clients grâce aux meilleures pratiques DevOps. Il aime intégrer des solutions d'IA dans des plateformes évolutives dans une variété de domaines.
Paul Min est un stagiaire architecte de solutions associé chez Amazon Web Services (AWS), où il aide les clients de différents secteurs verticaux à faire avancer leur mission et à accélérer leur adoption du cloud. Auparavant chez Intel, il a travaillé comme stagiaire en ingénierie logicielle pour aider à développer le SDK 3D Athlete Tracking Cloud. En dehors du travail, Paul aime jouer au golf et peut être entendu chanter.
- Coinsmart. Le meilleur échange Bitcoin et Crypto d'Europe.
- Platoblockchain. Intelligence métaverse Web3. Connaissance amplifiée. ACCÈS LIBRE.
- CryptoHawk. Radar Altcoins. Essai gratuit.
- Source : https://aws.amazon.com/blogs/machine-learning/the-intel3d-athlete-tracking-3dat-scalable-architecture-deploys-pose-estimation-models-using-amazon-kinesis-data-streams- et-amazon-eks/
- "
- &
- 000
- 100
- 2021
- 3d
- Qui sommes-nous
- accélérer
- accès
- accessible
- Selon
- Compte
- à travers
- Action
- actes
- ajout
- Supplémentaire
- admin
- Adoption
- AI
- algorithme
- Tous
- Amazon
- Amazon Web Services
- parmi
- api
- Apis
- Application
- applications
- approprié
- architecture
- arguments
- attribué
- Associé(e)
- athlètes
- attributs
- Automatique
- AWS
- sauvegarde
- Basketball
- before
- avantages.
- LES MEILLEURS
- les meilleures pratiques
- Noir
- Blog
- corps
- Box
- construire
- Développement
- Appelez-nous
- Compétences
- les soins
- Carrière
- cas
- central
- champion
- Change
- choix
- CLIENTS
- le cloud
- code
- collection
- collectionneur
- combiné
- composant
- calcul
- ordinateur
- configuration
- connexion
- consultant
- consommateur
- Les consommateurs
- Contenant
- Conteneurs
- contient
- continue
- des bactéries
- coordonner
- Core
- Correspondant
- engendrent
- créée
- crée des
- La création
- création
- Lettres de créance
- critique
- crucial
- Courant
- Lecture
- Customiser
- des clients
- Clients
- En investissant dans une technologie de pointe, les restaurants peuvent non seulement rester compétitifs dans un marché en constante évolution, mais aussi améliorer significativement l'expérience de leurs clients.
- données
- Base de données
- bases de données
- journée
- dévoué
- profond
- offre
- déployer
- déployé
- déploiement
- déploie
- Conception
- un
- détail
- détaillé
- détails
- Détection
- développer
- Développeur
- mobiles
- Développement
- différent
- différencier
- Directeur
- découverte
- affiche
- Docker
- Ne fait pas
- domaines
- down
- pendant
- même
- Endpoint
- énergie
- Moteur
- ingénieur
- ENGINEERING
- Environment
- événement
- exemple
- excité
- existant
- attend
- Découvrez
- explorez
- Fonctionnalité
- finalement
- la traduction de documents financiers
- services financiers
- Prénom
- s'adapter
- FLOTTE
- Flexibilité
- flexible
- concentré
- suivre
- Abonnement
- suit
- le format
- tourné vers l'avenir
- CADRE
- Framework
- fonction
- fonctionnel
- fonctions
- avenir
- générer
- générateur
- génération
- Don
- objectif
- Bien
- GPU
- diplôme
- Réservation de groupe
- Groupes
- manipuler
- Maniabilité
- Matériel
- Santé
- entendu
- vous aider
- aider
- aide
- ici
- augmentation
- Comment
- HTTPS
- humain
- Active
- image
- Mettre en oeuvre
- la mise en oeuvre
- important
- comprendre
- inclut
- Y compris
- individuel
- secteurs
- industrie
- Infrastructure
- technologie innovante
- contribution
- Inserts
- installer
- des services
- l'intégration
- Intel
- Intelligence
- l'interaction
- Interfaces
- IT
- Emploi
- Emplois
- chemin
- ACTIVITES
- laboratoire
- lancer
- lancement
- Conduit
- apprentissage
- Niveau
- Bibliothèque
- Gamme
- Liste
- chargement
- emplacement
- emplacements
- click
- machine learning
- LES PLANTES
- maintenir
- majeur
- FAIT DU
- man
- gérer
- gérés
- gestion
- fabrication
- Localisation
- cartographie
- mentionné
- méthodes
- Métrique
- minimum
- Mission
- ML
- Breeze Mobile
- Applications mobiles
- modèle
- numériques jumeaux (digital twin models)
- application
- PLUS
- (en fait, presque toutes)
- plusieurs
- noms
- NBA
- nécessaire
- Besoins
- nombre
- Jeux olympiques
- ouvre
- fonctionner
- optimisé
- Option
- de commander
- Autre
- propre
- Oxford
- paquet
- partie
- particulier
- particulièrement
- partenaires,
- En passant
- passionné
- Patron de Couture
- pourcentage
- performant
- effectuer
- objectifs
- pièce
- plateforme
- Plateformes
- jouer
- Poésie
- des notes bonus
- possible
- power
- solide
- Préparer
- précédent
- primaire
- principe
- priorité
- processus
- les process
- traitement
- Processeur
- produire
- Vidéo
- Produits
- professionels
- Projet
- fournir
- fournit
- but
- gamme
- raw
- en temps réel
- reconnaître
- record
- Articles
- en ce qui concerne
- fiable
- demandes
- exigent
- conditions
- Exigences
- a besoin
- ressource
- Ressources
- réponse
- Résultats
- Courir
- pour le running
- Sécurité
- San
- Évolutivité
- évolutive
- Escaliers intérieurs
- mise à l'échelle
- Sdk
- sécurisé
- segments
- Sans serveur
- service
- Services
- set
- mise
- Forme
- partage
- coquillage
- montré
- similaires
- De même
- étapes
- Taille
- So
- Logiciels
- logiciel en tant que service
- génie logiciel
- sur mesure
- Solutions
- quelques
- Quelqu'un
- spécialisé
- caractéristiques
- vitesse
- Sports
- empiler
- Étape
- Standard
- Normes
- Commencer
- j'ai commencé
- départs
- Région
- state-of-the-art
- Statut
- storage
- Boutique
- courant
- streaming
- soumis
- Par la suite
- été
- Support
- Les soutiens
- combustion propre
- prise
- équipe
- Technologie
- Essais
- donc
- Avec
- ATTACHER
- fiable
- aujourd'hui
- ensemble
- tokyo
- suivre
- Tracking
- types
- typiquement
- UCLA
- université
- Université d'Oxford
- ouvrir
- Mises à jour
- utilisé
- utilisateurs
- Utilisant
- Plus-value
- variété
- divers
- verticales
- Vidéo
- Vidéos
- vision
- web
- services Web
- WHO
- sans
- Activités principales
- travaillé
- de travail
- années