Цей пост у блозі написаний у співавторстві Джонатаном Лі, Нельсоном Люнгом, Полом Міном і Троєм Сквіллачі з Intel.
In Частина 1 У цій публікації ми обговорили, як Intel®3DAT співпрацює з Професійні послуги машинного навчання AWS (MLPS) для створення масштабованої програми AI SaaS. 3DAT використовує комп’ютерний зір та AI для розпізнавання, відстеження та аналізу понад 1,000 точок біомеханічних даних зі стандартного відео. Це дозволяє клієнтам створювати багаті та потужні продукти на основі біомеханіки, такі як веб-додатки та мобільні додатки з детальними даними про продуктивність та тривимірною візуалізацією.
У другій частині цієї статті ми глибше занурюємося в кожен етап архітектури. Ми досліджуємо послуги AWS, які використовуються для задоволення вимог до проектування 2DAT, зокрема Потоки даних Amazon Kinesis та Послуга Amazon Elastic Kubernetes (Amazon EKS), щоб масштабно розгорнути необхідні моделі оцінки пози для цього програмного забезпечення як сервісної програми (SaaS).
Огляд архітектури
Основною метою команди MLPS було виробництво конвеєрів моделі оцінки 2D та 3D пози та створення функціонального та масштабованого додатка. Наступна діаграма ілюструє архітектуру рішення.
Повна архітектура розбита на п'ять основних компонентів:
- Шари інтерфейсу програми користувача
- Database
- Оркестровка робочого процесу
- Формування висновку з масштабованою оцінкою пози
- Оперативний моніторинг
Давайте детально розглянемо кожен компонент, їх взаємодію та обґрунтування вибору дизайну.
Шари інтерфейсу програми користувача
Наступна діаграма показує рівні інтерфейсу програми, які забезпечують доступ користувачам і контроль над програмою та її ресурсами.
Ці точки доступу підтримують різні варіанти використання на основі різних персон клієнтів. Наприклад, користувач програми може надіслати завдання через CLI, тоді як розробник може створити додаток за допомогою Python SDK і вбудувати інтелектуальну оцінку пози у свої програми. CLI і SDK створені як модульні компоненти — обидва рівні є обгортками рівня API, створеного за допомогою API -шлюз Amazon для вирішення викликів API і пов’язаний AWS Lambda функції, які піклуються про логіку сервера, пов’язану з кожним викликом API. Ці рівні були важливим компонентом для команди Intel OTG, оскільки вони відкривають широку базу клієнтів, які можуть ефективно використовувати цю програму SaaS.
Рівень API
Рішення має базовий набір з дев’яти API, які відповідають типам об’єктів, які працюють на цій платформі. Кожен API має файл Python, який визначає дії API, які можна виконувати. Створення нових об'єктів автоматично присвоюється послідовно ідентифікатор об'єкта. Атрибути цих об’єктів зберігаються та відстежуються в Amazon Aurora без сервера бази даних, використовуючи цей ідентифікатор. Тому дії API пов’язані з функціями, які визначені в центральному файлі, який містить логіку сервера для запитів до бази даних Aurora. Ця логіка сервера використовує Boto3 Клієнт Amazon RDS DataService для доступу до кластера бази даних.
Єдиним винятком є /job
API, який має a create_job
метод, який обробляє подачу відео для створення нового завдання обробки. Цей метод запускає Функції кроку AWS логіка робочого процесу для виконання завдання. Проходячи в а job_id
, цей метод використовує Boto3 Клієнт функцій кроку зателефонувати start_execution
метод для вказаного stateMachineARN
(Назва ресурсу Amazon).
Вісім об’єктів API мають методи та подібний шаблон доступу, зведений у наступній таблиці.
Тип методу | Назва функції | Опис |
GET | list_[object_name]s |
Вибирає всі об’єкти цього типу з бази даних і відображає. |
POST | create_[object] |
Вставляє в базу даних новий запис об’єкта з необхідними входами. |
GET | get_[object] |
Вибирає атрибути об’єкта на основі ідентифікатора об’єкта з бази даних та відображає. |
PUT | update_[object] |
Оновлює наявний запис об’єкта з необхідними входами. |
DELETE | delete_[object] |
Видаляє наявний запис об’єкта з бази даних на основі ідентифікатора об’єкта. |
Нижче наведено відомості про дев’ять API:
- /користувач – Користувач – це особа, уповноважена надсилати завдання до цієї програми. Для створення користувача потрібні ім’я користувача, електронна адреса користувача та ідентифікатор групи, до якої належить користувач.
- /група_користувачів – Група користувачів – це набір користувачів. Кожна група користувачів зіставляється з одним проектом і одним набором параметрів конвеєра. Щоб мати різні рівні (з точки зору інфраструктурних ресурсів і параметрів конвеєра), користувачів поділяють на групи користувачів. Кожен користувач може належати лише до однієї групи користувачів. Для створення групи користувачів потрібні ідентифікатор проекту, ідентифікатор набору параметрів конвеєра, ім’я групи користувачів та опис групи користувачів. Зауважте, що групи користувачів відрізняються від ролей користувачів, визначених в обліковому записі AWS. Останній використовується для надання різного рівня доступу на основі їхніх ролей доступу (наприклад, адміністратора).
- /проект – Проект використовується для групування різних наборів інфраструктурних ресурсів разом. Проект асоціюється з синглом
project_cluster_url
(кластер Aurora) для запису користувачів, завдань та інших метаданих, aproject_queue_arn
(Kinesis Data Streams ARN), а також обчислювальне середовище виконання (на даний момент керується через Cortex), що використовується для виконання висновку щодо пакетів кадрів або постобробки відео. Кожна група користувачів пов’язана з одним проектом, і цей механізм дозволяє використовувати різні рівні з точки зору затримки та обчислювальної потужності для різних груп користувачів. Для створення проекту потрібні ім’я проекту, URL-адреса кластера проекту та ARN черги проекту. - / трубопровід – Конвеєр пов’язаний з єдиною конфігурацією для послідовності контейнерів обробки, які виконують обробку відео в кластері генерування висновків Amazon EKS, координованого Cortex (додаткову інформацію див. у розділі про створення висновку для обробки відео). Зазвичай він складається з трьох контейнерів: попередня обробка та декодування, виявлення об’єктів та оцінка пози. Наприклад, крок декодування та виявлення об’єктів однакові для 2D та 3D конвеєрів, але заміна останнього контейнера за допомогою HRNet або 3DMPPE призводить до набору параметрів для конвеєрів обробки 2D та 3D. Ви можете створити нові конфігурації для визначення можливих конвеєрів, які можна використовувати для обробки, і для цього потрібен новий файл Python в репозиторії Cortex, який детально описує послідовність викликів кінцевих точок моделі, які визначають цей конвеєр (див. розділ про створення висновків для обробки відео ). Кінцева точка конвеєра — це кінцева точка Cortex, яка викликається для обробки окремого кадру. Для створення конвеєра потрібні ім’я конвеєра, його опис і кінцева точка конвеєра.
- /pipeline_parameter_set – Набір параметрів конвеєра — це гнучкий набір JSON із кількох параметрів (серед виконання конфігурації конвеєра) для певного конвеєра, який додається, щоб забезпечити гнучкість для майбутнього налаштування, коли потрібне виконання кількох конфігурацій. Групи користувачів можуть бути пов’язані з певним набором параметрів конвеєра, і його призначення полягає в тому, щоб мати різні групи параметрів для групи користувачів і для кожного конвеєра. Це було важливим перспективним доповненням для Intel OTG, щоб вбудувати налаштування, які підтримують портативність, коли різні клієнти, зокрема ISV, починають використовувати програму.
- /pipeline_parameters – Окрема колекція параметрів конвеєра є екземпляром набору параметрів конвеєра. Це робить його 1:багато відображенням параметра конвеєра, набору параметрів конвеєра. Цей API вимагає, щоб ідентифікатор конвеєра був пов’язаний з набором параметрів конвеєра, що дозволяє створити конвеєр для відображення параметрів конвеєра 1:1 до конвеєра. Інші вхідні дані, необхідні для цього API, – це ідентифікатор набору параметрів конвеєра, значення параметрів конвеєра та ім’я параметрів конвеєра.
- /відео – Об’єкт відео використовується для визначення окремих відео, які складають пакет .zip, поданий під час роботи. Після надсилання цей файл розбивається на кілька відео. Відео пов’язане з
job_id
для завдання, де подано пакет .zip, і Служба простого зберігання Amazon (Amazon S3) шляхи розташування необроблених розділених відео та результатів постобробки кожного відео. Відеооб’єкт також містить відсоток прогресу відео, який послідовно оновлюється під час обробки окремих пакетів кадрів цього відео, а також прапорець статусу відео для завершення чи незавершення. Для створення відео потрібен ідентифікатор завдання, шлях до відео, шлях результатів відео, відсоток прогресу відео та статус відео. - /frame_batch - A
frame_batch
Об’єкт – це міні-пакет кадрів, створений шляхом вибірки одного відео. Поділ відео на пакети кадрів звичайного розміру забезпечує важіль для налаштування затримки та збільшує розпаралелювання та пропускну здатність. Це детальний блок, який запускається через Kinesis Data Streams для висновку. Для створення пакету кадрів потрібен ідентифікатор відео, номер початку партії кадрів, номер кінця партії кадрів, шлях введення пакету кадрів, шлях результатів пакету кадрів і статус пакету кадрів. - /робота – Цей API взаємодії використовується для подання файлів, щоб почати роботу з обробки. Цей API має функцію, відмінну від інших API об’єктів, оскільки це прямий шлях для взаємодії з координацією робочого процесу бекенда обробки відео та кластером Amazon EKS. Для цього API потрібні ідентифікатор користувача, ідентифікатор проекту, ідентифікатор конвеєра, ідентифікатор набору параметрів конвеєра, параметри завдання та статус завдання. У параметрах завдання вказується шлях до вхідного файлу, який є місцем розташування в Amazon S3, де знаходиться пакет відео .zip для обробки. Завантаження файлів здійснюється за допомогою
upload_handler
метод, який генерує попередньо підписану URL-адресу S3, щоб користувач міг розмістити файл. WORKFLOW_STATEMACHINE_ARN – це змінна середовища, яка передається доcreate_job
API, щоб указати, куди надсилається відеопакет .zip із вхідним шляхом до файлу, щоб почати роботу.
У наступній таблиці підсумовуються функції API.
Тип методу | функція | Опис |
GET | list_jobs |
Вибирає всі вакансії з бази даних і відображає. |
POST | create_ job |
Вставляє новий запис завдання з ідентифікатором користувача, ідентифікатором проекту, ідентифікатором конвеєра, ідентифікатором набору параметрів конвеєра, шляхом до результатів завдання, параметрами завдання та статусом завдання. |
GET | get_ job |
Вибирає атрибути завдання на основі ідентифікатора завдання з бази даних і відображається. |
GET | upload_handler |
Генерує попередньо підписану URL-адресу S3 як місце для завантаження файлу .zip. Потрібне ім’я сегмента S3 і очікується тип файлу програми/zip. |
Рівень SDK Python
Спираючись на API, команда створила клієнтську бібліотеку Python SDK як обгортку, щоб полегшити розробникам доступ до методів API. Вони використовували відкритий код Поезія, який обробляє пакування Python та керування залежностями. Вони створили а client.py
файл, який містить функції, що обгортають кожен із API за допомогою Python requests
бібліотека для обробки запитів і винятків API.
Щоб розробники запустили Intel 3DAT SDK, їм потрібно встановити та створити пакет Poetry. Потім вони можуть додати простий імпорт Python intel_3dat_sdk
до будь-якого коду Python.
Щоб використовувати клієнт, ви можете створити екземпляр клієнта, вказавши кінцеву точку API:
Потім ви можете використовувати клієнт для виклику окремих методів, таких як create_pipeline
метод (див. наступний код), беручи відповідні аргументи, такі як назва конвеєра та опис конвеєра.
Рівень CLI
Аналогічно, команда створила API для створення інтерфейсу командного рядка для користувачів, які хочуть отримати доступ до методів API за допомогою простого інтерфейсу без необхідності писати код Python. Вони використовували пакет Python з відкритим кодом Натисніть (Набір для створення інтерфейсу командного рядка). Перевагами цього фреймворка є довільне вкладення команд, автоматичне створення сторінки довідки та підтримка відкладеного завантаження підкоманд під час виконання. У той же самий client.py
Як і в SDK, кожен метод клієнта SDK був обгорнутий за допомогою Click, а необхідні аргументи методу були перетворені на прапорці командного рядка. Потім вхідні дані прапорів використовуються під час виклику команди SDK.
Щоб запустити CLI, ви можете використовувати CLI configure
команда. Вам буде запропоновано ввести URL-адресу кінцевої точки:
Тепер ви можете використовувати CLI для виклику різних команд, пов’язаних з методами API, наприклад:
Database
Як база даних, ця програма використовує Aurora Serverless для зберігання метаданих, пов’язаних з кожним із API, з MYSQL як механізмом баз даних. Вибір служби баз даних Aurora без сервера дотримується принципу проектування, щоб мінімізувати накладні витрати на інфраструктуру за рахунок використання безсерверних служб AWS, коли це можливо. Наступна діаграма ілюструє цю архітектуру.
Команда безсерверний режим двигуна відповідає шаблону періодичного використання, оскільки ця програма масштабується до нових клієнтів, а робочі навантаження все ще невизначені. Під час запуску кінцевої точки бази даних не потрібен певний розмір екземпляра БД, лише мінімальний і максимальний діапазон для ємності кластера. Aurora Serverless обробляє відповідне забезпечення парку маршрутизаторів і розподіляє робоче навантаження між ресурсами. Aurora Serverless автоматично зберігає резервні копії від 1 до 35 днів. Команда оптимізувала для безпеки, встановивши за замовчуванням максимальне значення 35.
Крім того, команда використовувала API даних для обробки доступу до безсерверного кластера Aurora, який не вимагає постійного з’єднання, а натомість забезпечує безпечну кінцеву точку HTTP та інтеграцію з пакетами SDK AWS. Ця функція використовує Менеджер секретів AWS щоб зберігати облікові дані бази даних, щоб не було необхідності явно передавати облікові дані. Сценарії CREATE TABLE були написані у файлах .sql для кожної з дев’яти таблиць, які відповідають дев’яти API. Оскільки ця база даних містила всі метадані та стан об’єктів у системі, методи API запускалися з використанням відповідних команд SQL (наприклад select * from Job
для list_jobs
API) і передано до execute_statement
метод із клієнта Amazon RDS в Data API.
Оркестровка робочого процесу
Функціональна основа програми оброблялася за допомогою крокових функцій для координації робочого процесу, як показано на наступній діаграмі.
Кінцевий автомат складався з послідовності чотирьох лямбда-функцій, яка запускається, коли завдання подається за допомогою create_job
метод з job
API. Ідентифікатор користувача, ідентифікатор проекту, ідентифікатор конвеєра, ідентифікатор набору параметрів конвеєра, шлях результатів завдання, параметри завдання та статус завдання необхідні для створення завдання. Ви можете спочатку завантажити пакет відеофайлів .zip за допомогою upload_handler
метод із API завдання для створення попередньо підписаної URL-адреси S3. Під час подання завдання шлях до вхідного файлу передається через параметри завдання, щоб указати розташування файлу. Це запускає запуск кінцевого автомата робочого процесу, запускаючи чотири основні кроки:
- Лямбда-функція ініціализатора
- Лямбда-функція відправника
- Завершення перевірки лямбда-функції
- Функція колектора лямбда
Лямбда-функція ініціализатора
Основна функція ініціализатора — розділити пакет .zip на окремі відеофайли та підготувати їх до відправника. Спочатку завантажується файл .zip, а потім кожен окремий файл, включаючи відеофайли, розархівується та розпаковується. Відео, бажано у форматі .mp4, завантажуються назад у відро S3. Використання create_video
метод у video
API, відеооб’єкт створюється з відеошляхом як вхідним. Це вставляє дані про кожне відео в базу даних Aurora. Будь-які інші типи файлів, наприклад файли JSON, вважаються метаданими і завантажуються аналогічним чином, але відеооб’єкт не створюється. Список імен файлів і витягнутих відеофайлів передається на наступний крок.
Лямбда-функція відправника
Функція Submitter бере відеофайли, витягнуті ініціализатором, і створює міні-пакети відеокадрів як зображення. Більшість сучасних моделей комп’ютерного зору, що випускаються, були навчені на зображеннях, тому навіть під час обробки відео вони спочатку поділяються на кадри зображення, перш ніж зробити висновок моделі. Це поточне рішення з використанням найсучаснішої моделі оцінки пози нічим не відрізняється — пакети кадрів від Відправника передаються до Kinesis Data Streams, щоб ініціювати крок генерації висновку.
Спочатку відеофайл завантажується функцією Лямбда. Частота кадрів і кількість кадрів розраховується за допомогою FileVideoStream
модуль з imutils.video
бібліотека обробки. Кадри витягуються та групуються відповідно до заданого розміру міні-партії, що є одним із ключових настроюваних параметрів цього конвеєра. За допомогою бібліотеки pickle Python дані серіалізуються та завантажуються в Amazon S3. Згодом створюється пакетний об’єкт кадру, а запис метаданих створюється в базі даних Aurora. Ця лямбда-функція була створена за допомогою Dockerfile із залежностями від opencv-python
, numpy
та imutils
бібліотеки.
Завершення перевірки лямбда-функції
Функція перевірки завершення продовжує запитувати базу даних Aurora, щоб побачити для кожного відео в пакеті .zip для цього поточного завдання, скільки пакетів кадрів перебувають у статусі COMPLETED. Коли всі пакети кадрів для всіх відео завершено, цей процес перевірки завершено.
Функція колектора лямбда
Функція Collector приймає результати висновків, які були зроблені для кожного кадру під час етапу Споживача, і об’єднує їх у пакеті кадрів та у відео. Потім об’єднані об’єднані дані завантажуються в сегмент S3. Потім функція викликає API постобробки Cortex для певного конвеєра ML, щоб виконати будь-які обчислення постобробки, і додає агреговані результати за відео до вихідного сегмента. Багато з цих показників обчислюються між кадрами, як-от швидкість, прискорення та кут з’єднання, тому цей розрахунок потрібно виконувати на основі агрегованих даних. Основні вихідні дані включають дані про основні точки тіла (зведені у формат CSV), обчислення BMA (наприклад, прискорення) та візуальне накладання ключових точок, доданих до кожного кадру у файлі зображення.
Формування висновку з масштабованою оцінкою пози
На цьому етапі працює механізм обробки, який забезпечує масштабування висновку ML. Він включає три основні частини, кожна з яких має власні важелі паралельності, які можна налаштувати на компроміси затримки (див. наступну діаграму).
Ця архітектура дає змогу експериментувати з тестуванням збільшення затримки, а також гнучкості на майбутнє, коли робочі навантаження можуть змінюватися з різними комбінаціями сегментів кінцевих користувачів, які мають доступ до програми.
Потоки даних Kinesis
Команда обрала Kinesis Data Streams, оскільки він зазвичай використовується для обробки потокових даних, і в цьому випадку він добре підходить, оскільки може обробляти пакети кадрів подібним чином, щоб забезпечити масштабованість і паралелізацію. У функції Submitter Lambda використовується клієнт Kinesis Boto3 з put_record
метод передачі метаданих, пов’язаних з одним пакетом кадрів, таких як ідентифікатор пакету кадрів, початковий кадр пакету кадрів, кінцевий кадр пакету кадрів, форма зображення, частота кадрів та ідентифікатор відео.
Ми визначили різні конфігурації черги завдань і потоку даних Kinesis, щоб встановити рівні пропускної здатності, які пов’язані з рівнем пріоритету різних груп користувачів. Доступ до різних рівнів обчислювальної потужності пов’язується шляхом передачі черги проекту ARN під час створення нового проекту за допомогою project
API. Кожна група користувачів потім пов’язується з певним проектом під час створення групи користувачів. У файлі визначено три конфігурації потоку за замовчуванням Модель безсерверного додатка AWS Шаблон інфраструктури (AWS SAM):
- стандарт -
JobStreamShardCount
- Пріоритет -
PriorityJobStreamShardCount
- Високий пріоритет -
HighPriorityJobStreamShardCount
Команда використовувала кілька різних важелів, щоб диференціювати потужність обробки кожного потоку або налаштувати затримку системи, як підсумовано в наступній таблиці.
Важіль | Опис | Значення за замовчуванням |
осколок | Осколок є рідним для Kinesis Data Streams; це базова одиниця пропускної здатності для прийому. За замовчуванням встановлено 1 МБ/с, що дорівнює 1,000 записів даних в секунду. | 2 |
KinesisBatchSize |
Максимальна кількість записів, які Kinesis Data Streams отримує за один пакет перед викликом споживчої лямбда-функції. | 1 |
KinesisParallelizationFactor |
Кількість партій, які потрібно обробляти з кожного сегмента одночасно. | 1 |
Посилене розвіювання | Споживачі даних, у яких активовано розширену пропускну здатність, мають виділену пропускну здатність для кожного споживача (наприклад, 1 МБ/с за замовчуванням), замість того, щоб розподіляти пропускну здатність між споживачами. | від |
Споживча лямбда-функція
З точки зору Kinesis Data Streams, споживач даних — це служба AWS, яка отримує дані з фрагмента потоку даних, коли дані генеруються в потоці. Ця програма використовує функцію Consumer Lambda, яка викликається, коли повідомлення передаються з черг потоку даних. Кожна функція споживача обробляє один пакет кадрів, виконуючи наступні кроки. Спочатку синхронно здійснюється виклик API процесора Cortex, який є кінцевою точкою, на якій розміщується конвеєр висновку моделі (докладніше дивіться в наступному розділі щодо Amazon EKS з Cortex). Результати зберігаються в Amazon S3, а оновлення бази даних здійснюється шляхом зміни статусу обробленого пакету кадрів на Complete
. Обробка помилок вбудована для керування викликом Cortex API за допомогою циклу повторення для обробки будь-яких помилок 504 із кластеру Cortex, при цьому кількість повторних спроб встановлено на 5.
Amazon EKS з Cortex для висновку ML
Команда використовувала Amazon EKS, керований сервіс Kubernetes в AWS, як обчислювальний механізм для ML. Було прийнято рішення щодо використання Amazon EKS для розміщення кінцевих точок ML, що надає гнучкість запуску Kubernetes із виходом за потоком із можливістю кластерів, які повністю керуються в AWS через AWS Fargate, або локальне обладнання через Amazon EKS Anywhere. Це була критична частина функціональності, яку хотів Intel OTG, який надав можливість підключити цю програму, наприклад, до спеціалізованого локального обладнання.
Три моделі ML, які були будівельними блоками для побудови конвеєрів висновку, були спеціальною моделлю Yolo (для виявлення об'єктів), спеціальною моделлю HRNet (для оцінки 2D пози) і моделлю 3DMPPE (для оцінки 3D пози) (див. попередній Розділ ML для більш детальної інформації). Вони використовували відкритий код Кора бібліотека для керування розгортанням і керуванням кінцевими точками конвеєра ML, а також запуском і розгортанням кластерів Amazon EKS. Кожна з цих моделей була упакована в контейнери Docker — файли моделей зберігалися в Amazon S3, а зображення моделей зберігалися в Реєстр контейнерів Amazon Elastic (Amazon ECR) — і розгорнуто як API Cortex Realtime. Версії контейнерів моделі, які працюють на ЦП і ГП, були створені для забезпечення гнучкості для типу обчислювального обладнання. У майбутньому, якщо потрібно буде додати додаткові моделі або конвеєри моделей, вони можуть просто створити додаткові API Cortex Realtime.
Потім вони побудували конвеєри висновку, об’єднавши API моделі Cortex Realtime в API конвеєрів Cortex Realtime. Єдиний API конвеєра реального часу складався з виклику послідовності API моделі реального часу. Оброблені функції Consumer Lambda a pipeline
API як чорний ящик із використанням одного виклику API для отримання остаточного висновку для зображення. Було створено два конвеєри: 2D-конвеєр і 3D-конвеєр.
Конвеєр 2D поєднує в собі етап попередньої обробки декодування, виявлення об’єктів за допомогою спеціальної моделі Yolo для визначення місцезнаходження спортсмена та створення обмежувальних рамок і, нарешті, користувацьку модель HRNet для створення 2D ключових точок для оцінки пози.
Конвеєр 3D поєднує етап попередньої обробки декодування, виявлення об’єктів за допомогою спеціальної моделі Yolo для визначення місцезнаходження спортсмена та створення обмежувальних рамок, і, нарешті, модель 3DMPPE для створення 3D ключових точок для оцінки пози.
Після генерування висновків для пакету кадрів кожен конвеєр також включає окрему кінцеву точку Cortex для постобробки в реальному часі, яка генерує три основні вихідні дані:
- Зведені основні дані про основні точки в один файл CSV
- Розрахунки BMA (наприклад, прискорення)
- Візуальне накладання ключових точок, доданих до кожного кадру у файлі зображення
Функція Collector Lambda надає кінцевій точці відповідні метадані, пов’язані з конкретним відео, наприклад ідентифікатори кадрів і розташування S3 вихідних висновків оцінки пози, для створення цих результатів постобробки.
Cortex розроблено для інтеграції з Amazon EKS, і для запуску кластера Kubernetes потрібні лише файл конфігурації кластера та проста команда:
Іншим важелем для налаштування продуктивності була конфігурація екземпляра для обчислювальних кластерів. Було створено три рівні з різними комбінаціями екземплярів M5 та G4dn, кодифікованими як файли .yaml із такими специфікаціями, як назва кластера, регіон, конфігурація та комбінація екземплярів. Екземпляри M5 базуються на процесорі з нижчою ціною, а G4dn — на основі GPU з більшою вартістю, щоб забезпечити певний компроміс між ціною та продуктивністю.
Оперативний моніторинг
Щоб підтримувати оперативні стандарти ведення журналів, усі функції Lambda включають код для запису та прийому журналів Amazon Kinesis Data Firehose. Наприклад, кожен пакет кадрів, оброблений за допомогою функції Submitter Lambda, реєструється з міткою часу, назвою дії та відповіддю функції Lambda JSON і зберігається в Amazon S3. Наступна діаграма ілюструє цей крок в архітектурі.
розгортання
Розгортання здійснюється за допомогою AWS SAM, платформи з відкритим вихідним кодом для створення безсерверних додатків в AWS. AWS SAM дозволяє кодифікувати та легко розгортати проект інфраструктури, включаючи функції, API, бази даних та зіставлення джерел подій, у нових середовищах AWS. Під час розгортання синтаксис AWS SAM перекладається на AWS CloudFormation обробляти надання інфраструктури.
A template.yaml
файл містить специфікації інфраструктури разом із параметрами, які можна налаштувати, такими як важелі затримки Kinesis Data Streams, детально описані в попередніх розділах. А samconfig.toml
файл містить такі параметри розгортання, як ім’я стека, ім’я сегмента S3, де зберігаються файли програми, як-от код функції лямбда, і теги ресурсів для відстеження вартості. Сценарій оболонки deploy.sh із простими командами — це все, що потрібно для створення та розгортання всього шаблону:
Потік роботи користувача
Підводячи підсумок, після розгортання інфраструктури ви можете розпочати роботу, наведену нижче.
- Створіть клієнт Intel 3DAT за допомогою клієнтської бібліотеки.
- Використовуйте API, щоб створити новий екземпляр конвеєра, який відповідає типу необхідної обробки, наприклад, для оцінки 3D пози.
- Створіть новий екземпляр проекту, передавши в кластер ARN і чергу Kinesis ARN.
- Створіть новий екземпляр набору параметрів конвеєра.
- Створіть новий екземпляр параметрів конвеєра, які відповідають набору параметрів конвеєра.
- Створіть нову групу користувачів, пов’язану з ідентифікатором проекту та ідентифікатором набору параметрів конвеєра.
- Створіть нового користувача, пов’язаного з групою користувачів.
- Завантажте файл .zip із відео в Amazon S3, використовуючи попередньо підписану URL-адресу S3, згенеровану функцією завантаження в API завдання.
- Надіслати a
create_job
Виклик API з параметрами завдання, які вказують розташування відеофайлів. Це розпочинає роботу з обробки.
Висновок
Тепер додаток працює і готовий до тестування як зі спортсменами, так і з тренерами. Intel OTG з радістю робить інноваційну технологію оцінки пози з використанням комп’ютерного зору доступною для різних користувачів, від розробників до спортсменів і партнерів із постачальників програмного забезпечення.
Команда AWS прагне допомогти замовникам, таким як Intel OTG, прискорити свій шлях машинного навчання, від стадії створення ідеї та відкриття з ML Solutions Lab до етапу посилення та розгортання з AWS ML ProServe. Ми всі будемо уважно спостерігати за Олімпійськими іграми в Токіо 2021 року цього літа, щоб уявити весь прогрес, який ML може розкрити в спорті.
Почніть сьогодні! Дослідіть свій варіант використання за допомогою служб, згаданих у цій публікації та багатьох інших на Консоль управління AWS.
Про авторів
Хан Ман є старшим менеджером з машинного навчання та штучного інтелекту в AWS, що в Сан-Дієго, Каліфорнія. Він має ступінь доктора інженерних наук у Північно-Західному університеті та багаторічний досвід роботи консультантом з управління, який консультує клієнтів у сфері виробництва, фінансових послуг та енергетики. Сьогодні він пристрасно працює з клієнтами з різних галузей, щоб розробити та впровадити рішення машинного навчання та штучного інтелекту на AWS. Він любить стежити за НБА і грати в баскетбол у вільний час.
Іман Кам'ябі є інженером ML із AWS Professional Services. Він працював з багатьма клієнтами AWS, щоб відстоювати передові практики створення повторюваних і надійних конвеєрів ML.
Джонатан Лі є директором з технологій спортивних результатів, Olympic Technology Group в Intel. Він вивчав застосування машинного навчання для здоров’я, будучи студентом в UCLA та під час своєї дипломної роботи в Оксфордському університеті. Його кар'єра була зосереджена на розробці алгоритмів і сенсорів для здоров'я та продуктивності людини. Зараз він керує проектом 3D відстеження спортсменів в Intel.
Нельсон Люнг є архітектором платформи в Sports Performance CoE в Intel, де він визначає наскрізну архітектуру для передових продуктів, які покращують результативність спортсменів. Він також керує впровадженням, розгортанням і виробництвом цих рішень машинного навчання в масштабі різних партнерів Intel.
Трой Сквіллачі є інженером DecSecOps в Intel, де він надає клієнтам професійні програмні рішення через найкращі методи DevOps. Йому подобається інтегрувати рішення AI в масштабовані платформи в різних областях.
Павло Мін є асоційованим архітектором рішень, стажером у Amazon Web Services (AWS), де він допомагає клієнтам у різних галузевих галузях просувати свою місію та прискорювати їхнє впровадження в хмару. Раніше в Intel він працював стажером з розробки програмного забезпечення, щоб допомогти розробити 3D Athlete Tracking Cloud SDK. Поза роботою Пол любить грати в гольф і його можна почути як співає.
- Coinsmart. Найкраща в Європі біржа біткойн та криптовалют.
- Платоблокчейн. Web3 Metaverse Intelligence. Розширені знання. БЕЗКОШТОВНИЙ ДОСТУП.
- CryptoHawk. Альткойн Радар. Безкоштовне випробування.
- Джерело: https://aws.amazon.com/blogs/machine-learning/the-intel3d-athlete-tracking-3dat-scalable-architecture-deploys-pose-estimation-models-using-amazon-kinesis-data-streams- and-amazon-eks/
- "
- &
- 000
- 100
- 2021
- 3d
- МЕНЮ
- прискорювати
- доступ
- доступною
- За
- рахунки
- через
- дію
- дії
- доповнення
- Додатковий
- адмін
- Прийняття
- AI
- алгоритм
- ВСІ
- Amazon
- Amazon Web Services
- серед
- API
- Інтерфейси
- додаток
- застосування
- відповідний
- архітектура
- аргументація
- призначений
- Юрист
- спортсменів
- Атрибути
- автоматичний
- AWS
- резервна копія
- баскетбол
- перед тим
- Переваги
- КРАЩЕ
- передового досвіду
- Black
- Блог
- тіло
- Box
- будувати
- Створюємо
- call
- потужність
- який
- кар'єра
- випадків
- центральний
- чемпіон
- зміна
- вибір
- клієнтів
- хмара
- код
- збір
- колектор
- комбінований
- компонент
- обчислення
- комп'ютер
- конфігурація
- зв'язку
- консультант
- споживач
- Споживачі
- Контейнер
- Контейнери
- містить
- триває
- контроль
- координувати
- Core
- Відповідний
- створювати
- створений
- створює
- створення
- створення
- Повноваження
- критичний
- вирішальне значення
- Поточний
- В даний час
- виготовлений на замовлення
- клієнт
- Клієнти
- передовий
- дані
- Database
- базами даних
- день
- присвячених
- глибше
- постачає
- розгортання
- розгорнути
- розгортання
- розгортає
- дизайн
- призначений
- деталь
- докладно
- деталі
- Виявлення
- розвивати
- Розробник
- розробників
- розробка
- різний
- диференціювати
- прямий
- Директор
- відкриття
- дисплеїв
- Docker
- Ні
- домени
- вниз
- під час
- легко
- Кінцева точка
- енергія
- двигун
- інженер
- Машинобудування
- Навколишнє середовище
- Event
- приклад
- збуджений
- існуючий
- чекає
- досвід
- дослідити
- особливість
- в кінці кінців
- фінансовий
- фінансові послуги
- Перший
- відповідати
- ФЛЕТ
- Гнучкість
- гнучкий
- увагу
- стежити
- після
- слідує
- формат
- перспективний
- FRAME
- Рамки
- функція
- функціональний
- функціональність
- Функції
- майбутнє
- породжувати
- породжує
- покоління
- дає
- мета
- добре
- GPU
- випускник
- Group
- Групи
- обробляти
- Обробка
- апаратні засоби
- здоров'я
- почутий
- допомога
- допомогу
- допомагає
- тут
- вище
- Як
- HTTPS
- людина
- Особистість
- зображення
- здійснювати
- реалізація
- важливо
- включати
- includes
- У тому числі
- індивідуальний
- промисловості
- промисловість
- Інфраструктура
- інноваційний
- вхід
- Вставки
- встановлювати
- інтегрований
- інтеграція
- Intel
- Інтелект
- взаємодія
- інтерфейс
- IT
- робота
- Джобс
- подорож
- ключ
- lab
- запуск
- запуск
- Веде за собою
- вивчення
- рівень
- бібліотека
- Лінія
- список
- погрузка
- розташування
- місць
- машина
- навчання за допомогою машини
- made
- підтримувати
- основний
- РОБОТИ
- людина
- управляти
- вдалося
- управління
- виробництво
- карта
- відображення
- згаданий
- методика
- Метрика
- мінімальний
- Місія
- ML
- Mobile
- Мобільні програми
- модель
- Моделі
- модульний
- більше
- найбільш
- множинний
- Імена
- NBA
- необхідно
- потреби
- номер
- Олімпійські ігри
- Відкриється
- працювати
- оптимізований
- варіант
- порядок
- Інше
- власний
- Оксфорд
- пакет
- частина
- приватність
- особливо
- партнери
- Проходження
- пристрасний
- Викрійки
- відсоток
- продуктивність
- виконанні
- перспектива
- частина
- платформа
- Платформи
- ігри
- Поезія
- точок
- це можливо
- влада
- потужний
- Готувати
- попередній
- первинний
- принцип
- пріоритет
- процес
- процеси
- обробка
- процесор
- виробляти
- Production
- Продукти
- професійний
- проект
- забезпечувати
- забезпечує
- мета
- діапазон
- Сировина
- реальному часі
- визнавати
- запис
- облік
- про
- надійний
- запитів
- вимагати
- вимагається
- Вимога
- Вимагається
- ресурс
- ресурси
- відповідь
- результати
- прогін
- біг
- Безпека
- Сан -
- масштабованість
- масштабовані
- шкала
- Масштабування
- Sdk
- безпечний
- сегменти
- Без сервера
- обслуговування
- Послуги
- комплект
- установка
- Форма
- поділ
- Склад
- показаний
- аналогічний
- Аналогічно
- простий
- Розмір
- So
- Софтвер
- програмне забезпечення як послуга
- розробка програмного забезпечення
- рішення
- Рішення
- деякі
- Хтось
- спеціалізований
- специфікації
- швидкість
- SPORTS
- стек
- Стажування
- standard
- стандартів
- старт
- почалася
- починається
- стан
- впроваджений
- Статус
- зберігання
- зберігати
- потік
- потоковий
- представлений
- Згодом
- літо
- підтримка
- Опори
- система
- взяття
- команда
- Технологія
- Тестування
- отже
- через
- TIE
- час
- сьогодні
- разом
- Токіо
- трек
- Відстеження
- Типи
- типово
- UCLA
- університет
- Оксфордський університет
- відімкнути
- Оновити
- використання
- користувачі
- використовує
- значення
- різноманітність
- різний
- вертикалі
- Відео
- Відео
- бачення
- Web
- веб-сервіси
- ВООЗ
- без
- Work
- працював
- робочий
- років