Демістифікація машинного навчання на периферії за допомогою реальних випадків використання

край – це термін, який відноситься до місця, далекого від хмари або великого центру обробки даних, де у вас є комп’ютерний пристрій (граничний пристрій), здатний запускати (граничні) програми. Пограничні обчислення — це акт виконання робочих навантажень на цих граничних пристроях. Машинне навчання на межі (ML@Edge) — це концепція, яка дає можливість запускати моделі ML локально на периферійних пристроях. Ці моделі ML потім можуть бути викликані граничною програмою. ML@Edge важливий для багатьох сценаріїв, коли вихідні дані збираються з джерел, віддалених від хмари. Ці сценарії також можуть мати особливі вимоги або обмеження:

• Передбачення в режимі реального часу з низькою затримкою
• Погане або відсутнє підключення до хмари
• Правові обмеження, які не дозволяють надсилати дані зовнішнім службам
• Великі набори даних, які потрібно попередньо обробити локально, перш ніж надсилати відповіді в хмару

Нижче наведено деякі з багатьох випадків використання, які можуть отримати користь від моделей ML, які працюють поблизу обладнання, яке генерує дані, що використовуються для прогнозів:

• Безпека та безпека – Зона обмеженого доступу, де важкі машини працюють в автоматизованому порту, контролюється камерою. Якщо людина помилково потрапляє в цю зону, спрацьовує запобіжний механізм, щоб зупинити машини та захистити людину.
• Прогнозне обслуговування – Датчики вібрації та звуку збирають дані від коробки передач вітрогенератора. Модель виявлення аномалій обробляє дані датчика та визначає, чи є аномалії з обладнанням. Якщо виявлено аномалію, крайовий пристрій може почати вимірювання непередбачених обставин в режимі реального часу, щоб уникнути пошкодження обладнання, наприклад, включити розриви або відключити генератор від мережі.
• Виявлення дефектів у виробничих лініях – Камера фіксує зображення продуктів на конвеєрній стрічці та обробляє кадри за допомогою моделі класифікації зображень. Якщо виявлено дефект, виріб можна викинути автоматично без ручного втручання.

Хоча ML@Edge може вирішити багато випадків використання, існують складні архітектурні проблеми, які необхідно вирішити, щоб мати безпечний, надійний та надійний дизайн. У цій публікації ви дізнаєтеся деякі відомості про ML@Edge, пов’язані теми та як використовувати служби AWS для подолання цих проблем і впровадження повного рішення для вашого ML на граничному робочому навантаженні.

Огляд ML@Edge

Існує загальна плутанина, коли справа доходить до ML@Edge та Інтернету речей (IoT), тому важливо прояснити, чим ML@Edge відрізняється від IoT і як вони обидва можуть об’єднатися, щоб забезпечити потужне рішення в певних випадках.

Граничне рішення, яке використовує ML@Edge, має два основні компоненти: крайову програму та модель ML (викликана програмою), що виконується на граничному пристрої. ML@Edge — це контроль за життєвим циклом однієї або кількох моделей ML, розгорнутих на парку периферійних пристроїв. Життєвий цикл моделі ML може початися на стороні хмари (вкл Amazon SageMaker, наприклад), але зазвичай закінчується автономним розгортанням моделі на граничному пристрої. Кожен сценарій вимагає різних життєвих циклів моделі ML, які можуть складатися з багатьох етапів, таких як збір даних; підготовка даних; створення моделі, компіляція та розгортання на граничному пристрої; завантаження та запуск моделі; і повторення життєвого циклу.

Механізм ML@Edge не несе відповідальності за життєвий цикл програми. Для цього слід застосувати інший підхід. Роз’єднання життєвого циклу моделі ML і життєвого циклу програми дає вам свободу та гнучкість, щоб продовжувати розвивати їх різними темпами. Уявіть собі мобільну програму, яка вбудовує модель ML як ресурс, як-от зображення або файл XML. У цьому випадку щоразу, коли ви навчаєте нову модель і хочете розгорнути її на мобільних телефонах, вам потрібно повторно розгорнути всю програму. Це забирає час і гроші, а також може призвести до помилок у вашій програмі. Відокремлюючи життєвий цикл моделі ML, ви публікуєте мобільний додаток один раз і розгортаєте стільки версій моделі ML, скільки вам потрібно.

Але як IoT співвідноситься з ML@Edge? IoT відноситься до фізичних об’єктів, вбудованих із такими технологіями, як датчики, можливості обробки та програмне забезпечення. Ці об’єкти підключаються до інших пристроїв і систем через Інтернет або інші комунікаційні мережі для обміну даними. Наступний малюнок ілюструє цю архітектуру. Концепція була спочатку створена, коли думали про прості пристрої, які просто збирають дані з периферії, виконують просту локальну обробку та надсилають результат до потужнішого обчислювального комплексу, який запускає аналітичні процеси, які допомагають людям і компаніям приймати рішення. Рішення IoT відповідає за контроль життєвого циклу периферійної програми. Додаткову інформацію про IoT див Інтернет речей.

Якщо у вас уже є додаток IoT, ви можете додати можливості ML@Edge, щоб зробити продукт більш ефективним, як показано на наступному малюнку. Майте на увазі, що ML@Edge не залежить від Інтернету речей, але ви можете об’єднати їх, щоб створити більш потужне рішення. Коли ви це робите, ви покращуєте потенціал свого простого пристрою, щоб генерувати статистику в реальному часі для вашого бізнесу швидше, ніж просто надсилати дані в хмару для подальшої обробки.

Якщо ви створюєте нове граничне рішення з нуля з можливостями ML@Edge, важливо розробити гнучку архітектуру, яка підтримує життєвий цикл програми та моделі ML. Ми надаємо деякі еталонні архітектури для граничних додатків із ML@Edge пізніше в цій публікації. Але спочатку давайте глибше зануримося в периферійні обчислення та дізнаємося, як вибрати правильний крайовий пристрій для вашого рішення, виходячи з обмежень середовища.

Крайові обчислення

Залежно від того, наскільки далеко пристрій знаходиться від хмари або великого центру обробки даних (бази), необхідно враховувати три основні характеристики периферійних пристроїв, щоб максимізувати продуктивність і довговічність системи: ємність обчислень і зберігання даних, підключення та енергоспоживання. На наступній схемі показано три групи крайових пристроїв, які поєднують різні характеристики цих характеристик, залежно від того, наскільки вони віддалені від основи.

Групи такі:

• MEC (пограничні обчислення з багатьма доступом) – MEC або невеликі центри обробки даних, що характеризуються низькою або наднизькою затримкою та високою пропускною здатністю, є поширеними середовищами, де ML@Edge може принести переваги без великих обмежень у порівнянні з хмарними робочими навантаженнями. Антени та сервери 5G на фабриках, складах, лабораторіях тощо з мінімальними енергетичними обмеженнями та з хорошим підключенням до Інтернету пропонують різні способи запуску моделей ML на графічних і центральних процесорах, віртуальних машинах, контейнерах та відкритих серверах.
• Близький край – Це коли мобільність або агрегація даних є вимогами, і пристрої мають певні обмеження щодо споживання енергії та потужності обробки, але все ще мають певну надійність підключення, хоча з більшою затримкою, з обмеженою пропускною здатністю та дорожче, ніж «близько до межі». До цієї групи входять мобільні додатки, спеціальні плати для прискорення моделей ML або прості пристрої з можливістю запуску моделей ML, які охоплюються бездротовими мережами.
• Далекий край – У цьому екстремальному сценарії граничні пристрої мають серйозні обмеження щодо споживання електроенергії або підключення. Отже, обчислювальна потужність також обмежена в багатьох сценаріях дальнього краю. Сільське господарство, видобуток корисних копалин, спостереження та безпека, а також морський транспорт – це деякі сфери, де пристрої відіграють важливу роль. Прості плати, як правило, без графічних процесорів або інших прискорювачів AI, поширені. Вони призначені для завантаження та запуску простих моделей ML, збереження прогнозів у локальній базі даних і сну до наступного циклу передбачення. Пристрої, яким потрібно обробляти дані в режимі реального часу, можуть мати великі локальні сховища, щоб уникнути втрати даних.

Виклики

Зазвичай у сценарії ML@Edge є сотні чи тисячі (можливо, навіть мільйони) пристроїв, на яких запущені ті самі моделі та граничні програми. Коли ви масштабуєте свою систему, важливо мати надійне рішення, яке може керувати кількістю пристроїв, які вам потрібно підтримувати. Це складне завдання, і для цих сценаріїв вам потрібно поставити багато запитань:

• Як керувати моделями ML на парку пристроїв на периферії?
• Як створити, оптимізувати та розгорнути моделі машинного навчання на кількох периферійних пристроях?
• Як захистити мою модель під час розгортання та запуску на краю?
• Як контролювати продуктивність моєї моделі та перенавчати її, якщо потрібно?
• Як усунути необхідність встановлення великого фреймворку, такого як TensorFlow або PyTorch, на моєму обмеженому пристрої?
• Як показати одну або кілька моделей із моїм крайовим додатком як простий API?
• Як створити новий набір даних із корисними навантаженнями та прогнозами, отриманими граничними пристроями?
• Як виконати всі ці завдання автоматично (MLOps плюс ML@Edge)?

У наступному розділі ми надаємо відповіді на всі ці запитання за допомогою прикладів використання та еталонної архітектури. Ми також обговорюємо, які сервіси AWS можна об’єднати, щоб створити повні рішення для кожного з розглянутих сценаріїв. Однак, якщо ви хочете почати з дуже простого процесу, який описує, як використовувати деякі послуги, що надаються AWS для створення рішення ML@Edge, це приклад:

За допомогою SageMaker ви можете легко підготувати набір даних і створити моделі ML, які розгортаються на периферійних пристроях. З Amazon SageMaker Neo, ви можете зібрати й оптимізувати модель, яку ви навчили, для конкретного вибраного крайового пристрою. Після компіляції моделі вам потрібен лише легкий час виконання (надається сервісом). Amazon SageMaker Edge Manager відповідає за керування життєвим циклом усіх моделей ML, розгорнутих у вашому парку периферійних пристроїв. Edge Manager може керувати парком до мільйонів пристроїв. Агент, встановлений на кожному з граничних пристроїв, надає розгорнуті моделі ML як API для програми. Агент також відповідає за збір показників, корисного навантаження та прогнозів, які ви можете використовувати для моніторингу або створення нового набору даних для перенавчання моделі, якщо це необхідно. Нарешті, с Трубопроводи Amazon SageMaker, ви можете створити автоматизований конвеєр з усіма кроками, необхідними для створення, оптимізації та розгортання моделей машинного навчання на вашому парку пристроїв. Цей автоматизований конвеєр може бути запущений простими подіями, які ви визначаєте, без втручання людини.

Випадок використання 1

Скажімо, виробник літака хоче виявити та відстежити деталі та інструменти у виробничому ангарі. Щоб підвищити продуктивність, усі необхідні деталі та правильні інструменти повинні бути доступними для інженерів на кожному етапі виробництва. Ми хочемо мати можливість відповісти на такі запитання: Де частина А? або Де знаходиться інструмент B? У нас уже встановлено кілька IP-камер, які підключені до локальної мережі. Камери охоплюють весь ангар і можуть транслювати HD-відео в режимі реального часу через мережу.

Панорама AWS добре вписується в даному випадку. AWS Panorama надає пристрій ML і керовану послугу, яка дає змогу додавати комп’ютерне бачення (CV) до наявного парку IP-камер та автоматизувати. AWS Panorama дає вам можливість додавати резюме до ваших існуючих камер Інтернет-протоколу (IP) і автоматизувати завдання, які традиційно вимагають перевірки та моніторингу.

У наступній довідковій архітектурі ми показуємо основні компоненти програми, що працює на пристрої AWS Panorama Appliance. Panorama Application SDK дозволяє легко знімати відео з потоків камери, виконувати висновки з конвеєром кількох моделей ML та обробляти результати за допомогою коду Python, що працює всередині контейнера. Ви можете запускати моделі з будь-якої популярної бібліотеки ML, наприклад TensorFlow, PyTorch або TensorRT. Результати моделі можна інтегрувати з бізнес-системами у вашій локальній мережі, дозволяючи реагувати на події в режимі реального часу.

Рішення складається з наступних кроків:

1. Підключіть і налаштуйте пристрій AWS Panorama до тієї ж локальної мережі.
2. Навчіть модель ML (виявлення об’єктів) для визначення деталей та інструментів у кожному кадрі.
3. Створіть програму AWS Panorama, яка отримує прогнози від моделі ML, застосовує механізм відстеження до кожного об’єкта та надсилає результати до бази даних у реальному часі.
4. Оператори можуть надсилати запити до бази даних, щоб знайти деталі та інструменти.

Випадок використання 2

Для нашого наступного випадку уявіть, що ми створюємо відеореєстратор для транспортних засобів, здатних підтримувати водія в багатьох ситуаціях, наприклад уникати пішоходів, на основі Дошка CV25 від Ambaralla. Розміщення моделей ML на пристрої з обмеженими системними ресурсами може бути складним. У цьому випадку припустимо, що ми вже маємо добре налагоджений механізм доставки по повітрю (OTA) для розгортання компонентів програми, необхідних на граничному пристрої. Однак ми все одно виграємо від можливості розгортання самої моделі OTA, ізолюючи тим самим життєвий цикл програми та життєвий цикл моделі.

Amazon SageMaker Edge Manager та Amazon SageMaker Neo добре підходить для цього випадку використання.

Edge Manager дозволяє розробникам ML edge легко використовувати ті ж знайомі інструменти в хмарі або на периферійних пристроях. Це скорочує час і зусилля, необхідні для запуску моделей у виробництво, а також дозволяє постійно відстежувати та покращувати якість моделей у парку пристроїв. SageMaker Edge включає механізм розгортання OTA, який допомагає вам розгортати моделі в парку, незалежно від програми або мікропрограмного забезпечення пристрою. The Агент Edge Manager дозволяє запускати кілька моделей на одному пристрої. Агент збирає дані прогнозування на основі логіки, якою ви керуєте, наприклад інтервалів, і завантажує їх у хмару, щоб ви могли періодично перенавчати свої моделі з часом. SageMaker Edge криптографічно підписує ваші моделі, щоб ви могли переконатися, що вони не були підроблені під час переміщення з хмари на крайовий пристрій.

Neo — це компілятор як сервіс, який особливо добре підходить для цього випадку. Neo автоматично оптимізує моделі ML для висновку про хмарні екземпляри та граничні пристрої, щоб працювати швидше без втрати точності. Ви починаєте з моделі ML, створеної з одним із підтримувані фреймворки і навчався в SageMaker або де-небудь ще. Потім ви вибираєте цільову апаратну платформу (див. список підтримувані пристрої). Одним клацанням миші Neo оптимізує навчену модель і компілює її в пакет, який можна запускати за допомогою легкого середовища виконання SageMaker Edge. Компілятор використовує модель ML для застосування оптимізації продуктивності, яка забезпечує найкращу доступну продуктивність для вашої моделі на хмарному екземплярі або граничному пристрої. Потім ви розгортаєте модель як кінцеву точку SageMaker або на підтримуваних периферійних пристроях і починаєте робити прогнози.

Наступна схема ілюструє цю архітектуру.

Робочий процес рішення складається з наступних кроків:

1. Розробник створює, навчає, перевіряє та створює остаточний артефакт моделі, який потрібно розгорнути на відеореєстраторі.
2. Викличте Neo для компіляції навченої моделі.
3. Агент SageMaker Edge встановлюється та налаштовується на пристрої Edge, у цьому випадку на відеореєстраторі.
4. Створіть пакет розгортання з підписаною моделлю та середовищем виконання, яке використовує агент SageMaker Edge для завантаження та виклику оптимізованої моделі.
5. Розгорніть пакет, використовуючи існуючий механізм розгортання OTA.
6. Гранична програма взаємодіє з агентом SageMaker Edge, щоб зробити висновки.
7. Агент можна налаштувати (якщо потрібно) для надсилання зразків вхідних даних у реальному часі з програми для моніторингу та уточнення моделі.

Випадок використання 3

Припустимо, що ваш клієнт розробляє програму, яка виявляє аномалії в механізмах вітрової турбіни (наприклад, редуктор, генератор або ротор). Мета полягає в тому, щоб мінімізувати пошкодження обладнання, виконуючи локальні процедури захисту на льоту. Ці турбіни дуже дорогі і розташовані в важкодоступних місцях. Кожна турбіна може бути оснащена пристроєм NVIDIA Jetson для моніторингу даних датчиків з турбіни. Тоді нам знадобиться рішення для збору даних і використання алгоритму ML для виявлення аномалій. Нам також потрібен механізм OTA, щоб оновлювати програмне забезпечення та моделі ML на пристрої.

AWS IoT Greengrass V2 разом із Edge Manager добре підходить для цього випадку використання. AWS IoT Greengrass — це програма IoT edge з відкритим кодом і хмарна служба, яка допомагає створювати, розгортати та керувати додатками IoT на своїх пристроях. Ви можете використовувати AWS IoT Greengrass для створення периферійних додатків за допомогою попередньо вбудованих програмних модулів, званих Компоненти, який може підключати ваші периферійні пристрої до служб AWS або сторонніх служб. Ця здатність AWS IoT Greengrass полегшує розгортання активів на пристроях, включаючи агент SageMaker Edge. AWS IoT Greengrass відповідає за керування життєвим циклом програми, а Edge Manager відокремлює життєвий цикл моделі ML. Це дає вам гнучкість, щоб продовжувати розвивати ціле рішення, розгортаючи нові версії граничної програми та моделі ML незалежно. Наступна діаграма ілюструє цю архітектуру.

Рішення складається з наступних кроків:

1. Розробник будує, навчає, перевіряє та створює остаточний артефакт моделі, який потрібно розгорнути на вітровій турбіні.
2. Викличте Neo для компіляції навченої моделі.
3. Створіть компонент моделі за допомогою Edge Manager з інтеграцією AWS IoT Greengrass V2.
4. Налаштуйте AWS IoT Greengrass V2.
5. Створіть компонент висновку за допомогою AWS IoT Greengrass V2.
6. Гранична програма взаємодіє з агентом SageMaker Edge, щоб зробити висновки.
7. Агент можна налаштувати (якщо потрібно) для надсилання зразків вхідних даних у реальному часі з програми для моніторингу та уточнення моделі.

Випадок використання 4

Для нашого останнього варіанту використання давайте розглянемо судно, що транспортує контейнери, де кожен контейнер має пару датчиків і передає сигнал до інфраструктури обчислень і зберігання, розгорнутої локально. Проблема полягає в тому, що ми хочемо знати вміст кожного контейнера та стан товарів на основі температури, вологості та газів всередині кожного контейнера. Ми також хочемо відстежувати всі товари в кожному з контейнерів. Протягом усього рейсу немає підключення до Інтернету, і подорож може тривати місяцями. Моделі ML, що працюють на цій інфраструктурі, повинні попередньо обробляти дані та генерувати інформацію, щоб відповісти на всі наші запитання. Згенеровані дані потрібно зберігати локально протягом місяців. Гранична програма зберігає всі висновки в локальній базі даних, а потім синхронізує результати з хмарою, коли судно наближається до порту.

AWS Snowcone та AWS Snowball від AWS Snow Family може дуже добре вписатися в цей варіант використання.

AWS Snowcone — це невеликий, надійний і безпечний пристрій для периферійних обчислень і переміщення даних. Snowcone розроблено відповідно до стандарту OSHA для підйомного пристрою для однієї людини. Snowcone дозволяє виконувати граничні робочі навантаження за допомогою Обчислювальна хмара Amazon Elastic (Amazon EC2) і локальне зберігання в суворих, відключених польових середовищах, таких як нафтові вишки, пошуково-рятувальні машини, військові об’єкти або заводи, а також віддалені офіси, лікарні та кінотеатри.

Snowball додає більше обчислень у порівнянні зі Snowcone, і тому може чудово підійти для більш вимогливих додатків. Функція Compute Optimized забезпечує додатковий графічний процесор NVIDIA Tesla V100 разом із екземплярами EC2 для прискорення продуктивності програми у відключених середовищах. З опцією GPU ви можете запускати такі додатки, як розширене машинне навчання та аналіз повного відео у середовищі з невеликим підключенням або без нього.

Крім екземпляра EC2, у вас є свобода створювати та розгортати будь-який тип крайнього рішення. Наприклад: ви можете використовувати Amazon ECS або інший менеджер контейнерів для розгортання граничної програми, агента Edge Manager і моделі ML як окремих контейнерів. Ця архітектура буде схожа на варіант використання 2 (за винятком того, що вона буде працювати в автономному режимі більшу частину часу), з додаванням інструмента керування контейнерами.

Наступна діаграма ілюструє цю архітектуру рішення.

Щоб реалізувати це рішення, просто замовте свій пристрій Snow у Консоль управління AWS і запустіть свої ресурси.

Висновок

У цій публікації ми обговорили різні аспекти edge, з якими ви можете працювати на основі вашого варіанту використання. Ми також обговорили деякі з ключових концепцій навколо ML@Edge і те, як відокремлення життєвого циклу програми та життєвого циклу моделі ML дає вам свободу розвивати їх без будь-якої залежності один від одного. Ми підкреслили, що вибір правильного граничного пристрою для вашого робочого навантаження та постановка правильних запитань під час процесу вирішення може допомогти вам працювати назад і звузити список правильних служб AWS. Ми також представили різні варіанти використання разом із еталонними архітектурами, щоб надихнути вас на створення власних рішень, які підійдуть для вашого робочого навантаження.

---

Про авторів

Дінеш Кумар Субрамані є старшим архітектором рішень у команді UKIR SMB, яка базується в Единбурзі, Шотландія. Він спеціалізується на штучному інтелекті та машинному навчанні. Дінеш любить працювати з клієнтами в різних галузях, щоб допомогти їм вирішити їхні проблеми із сервісами AWS. Поза роботою він любить проводити час із сім’єю, грати в шахи та насолоджуватися музикою різних жанрів.

Самір Араужо є архітектором рішень AI/ML в AWS. Він допомагає клієнтам створювати рішення AI/ML, які вирішують їхні бізнес-задачі за допомогою AWS. Він працював над кількома проектами AI/ML, пов’язаними з комп’ютерним баченням, обробкою природної мови, прогнозуванням, ML at the edge тощо. Йому подобається грати з проектами обладнання та автоматизації у вільний час, і він особливо цікавиться робототехнікою.

• Coinsmart. Найкраща в Європі біржа біткойн та криптовалют.
• Платоблокчейн. Web3 Metaverse Intelligence. Розширені знання. БЕЗКОШТОВНИЙ ДОСТУП.
• CryptoHawk. Альткойн Радар. Безкоштовне випробування.
• Джерело: https://aws.amazon.com/blogs/machine-learning/demystifying-machine-learning-at-the-edge-through-real-use-cases/