Демистификация машинного обучения на периферии с помощью реальных сценариев использования

Edge — это термин, который относится к расположению вдали от облака или большого центра обработки данных, где у вас есть компьютерное устройство (пограничное устройство), способное запускать (пограничные) приложения. Пограничные вычисления — это выполнение рабочих нагрузок на этих пограничных устройствах. Машинное обучение на периферии (ML@Edge) — это концепция, которая позволяет запускать модели машинного обучения локально на периферийных устройствах. Затем эти модели машинного обучения могут вызываться пограничным приложением. ML@Edge важен для многих сценариев, когда необработанные данные собираются из источников, удаленных от облака. Эти сценарии также могут иметь особые требования или ограничения:

• Прогнозы в реальном времени с малой задержкой
• Плохое или отсутствующее подключение к облаку
• Правовые ограничения, не позволяющие отправлять данные во внешние сервисы
• Большие наборы данных, которые необходимо предварительно обработать локально перед отправкой ответов в облако.

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

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

Хотя ML@Edge может использоваться во многих случаях, существуют сложные архитектурные проблемы, которые необходимо решить, чтобы иметь безопасную, надежную и надежную конструкцию. В этом посте вы узнаете некоторые подробности о ML@Edge, связанных темах и о том, как использовать сервисы AWS для преодоления этих проблем и внедрения комплексного решения для вашей рабочей нагрузки ML на периферии.

Обзор ML@Edge

Когда дело доходит до ML@Edge и Интернета вещей (IoT), часто возникает путаница, поэтому важно уточнить, чем ML@Edge отличается от IoT и как они оба могут объединиться, чтобы в определенных случаях предоставить мощное решение.

Пограничное решение, использующее ML@Edge, состоит из двух основных компонентов: пограничного приложения и модели машинного обучения (вызываемой приложением), работающей на пограничном устройстве. ML@Edge — это управление жизненным циклом одной или нескольких моделей машинного обучения, развернутых на множестве пограничных устройств. Жизненный цикл модели машинного обучения может начаться на стороне облака (на Создатель мудреца Амазонки), но обычно заканчивается автономным развертыванием модели на пограничном устройстве. Для каждого сценария требуются разные жизненные циклы моделей машинного обучения, которые могут состоять из множества этапов, таких как сбор данных; подготовка данных; построение модели, компиляция и развертывание на пограничном устройстве; загрузка и запуск модели; и повторение жизненного цикла.

Механизм ML@Edge не отвечает за жизненный цикл приложения. Для этой цели следует использовать другой подход. Разделение жизненного цикла модели машинного обучения и жизненного цикла приложения дает вам свободу и гибкость для их дальнейшего развития с разной скоростью. Представьте себе мобильное приложение, которое встраивает модель машинного обучения в качестве ресурса, такого как изображение или XML-файл. В этом случае каждый раз, когда вы обучаете новую модель и хотите развернуть ее на мобильных телефонах, вам необходимо повторно развернуть все приложение. Это отнимает время и деньги и может привести к ошибкам в вашем приложении. Разделяя жизненный цикл модели машинного обучения, вы публикуете мобильное приложение один раз и развертываете столько версий модели машинного обучения, сколько вам нужно.

Но как IoT соотносится с ML@Edge? Интернет вещей относится к физическим объектам, в которые встроены такие технологии, как датчики, возможности обработки и программное обеспечение. Эти объекты подключаются к другим устройствам и системам через Интернет или другие сети связи для обмена данными. На следующем рисунке показана эта архитектура. Первоначально эта концепция была создана при мысли о простых устройствах, которые просто собирают данные с периферии, выполняют простую локальную обработку и отправляют результат в более мощное вычислительное устройство, которое запускает аналитические процессы, помогающие людям и компаниям в принятии решений. Решение IoT отвечает за управление жизненным циклом пограничных приложений. Для получения дополнительной информации об IoT см. Интернет вещей.

Если у вас уже есть приложение IoT, вы можете добавить возможности ML@Edge, чтобы сделать продукт более эффективным, как показано на следующем рисунке. Имейте в виду, что ML@Edge не зависит от Интернета вещей, но вы можете комбинировать их для создания более мощного решения. Когда вы это сделаете, вы улучшите потенциал своего простого устройства, чтобы генерировать информацию для вашего бизнеса в режиме реального времени быстрее, чем просто отправлять данные в облако для последующей обработки.

Если вы создаете новое граничное решение с нуля с возможностями ML@Edge, важно разработать гибкую архитектуру, поддерживающую жизненные циклы как приложения, так и модели машинного обучения. Далее в этом посте мы предоставим несколько эталонных архитектур для пограничных приложений с ML@Edge. Но сначала давайте углубимся в периферийные вычисления и узнаем, как выбрать правильное периферийное устройство для вашего решения с учетом ограничений среды.

Граничные вычисления

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

Группы следующие:

• MEC (пограничные вычисления с множественным доступом) – MEC или небольшие центры обработки данных, характеризующиеся низкой или сверхмалой задержкой и высокой пропускной способностью, являются распространенными средами, в которых ML@Edge может принести преимущества без больших ограничений по сравнению с облачными рабочими нагрузками. Антенны и серверы 5G на фабриках, складах, лабораториях и т. д. с минимальными ограничениями по энергопотреблению и хорошим подключением к Интернету предлагают различные способы запуска моделей машинного обучения на графических и центральных процессорах, виртуальных машинах, контейнерах и серверах без операционной системы.
• Ближний край – Это когда требуется мобильность или агрегация данных, а устройства имеют некоторые ограничения в отношении энергопотребления и вычислительной мощности, но все же имеют некоторую надежную связь, хотя и с более высокой задержкой, с ограниченной пропускной способностью и дороже, чем «близко к периферии». В эту группу входят мобильные приложения, специальные платы для ускорения моделей машинного обучения или простые устройства с возможностью запуска моделей машинного обучения, охваченные беспроводными сетями.
• Дальний край – В этом экстремальном сценарии пограничные устройства имеют серьезные ограничения по энергопотреблению или возможности подключения. Следовательно, вычислительная мощность также ограничена во многих дальних сценариях. Сельское хозяйство, горнодобывающая промышленность, наблюдение и безопасность, а также морской транспорт — вот некоторые области, в которых удаленные устройства играют важную роль. Распространены простые платы, обычно без графических процессоров или других ускорителей ИИ. Они предназначены для загрузки и запуска простых моделей машинного обучения, сохранения прогнозов в локальной базе данных и бездействия до следующего цикла прогнозирования. Устройства, которым необходимо обрабатывать данные в реальном времени, могут иметь большие локальные хранилища, чтобы избежать потери данных.

Вызовы

Часто встречаются сценарии ML@Edge, в которых у вас есть сотни или тысячи (возможно, даже миллионы) устройств с одинаковыми моделями и пограничными приложениями. При масштабировании системы важно иметь надежное решение, способное управлять количеством устройств, которое необходимо поддерживать. Это сложная задача, и для этих сценариев вам нужно задать много вопросов:

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

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

С помощью SageMaker вы можете легко подготовить набор данных и построить модели машинного обучения, которые будут развернуты на периферийных устройствах. С Amazon SageMaker Neo, вы можете скомпилировать и оптимизировать модель, которую вы обучили, для конкретного выбранного вами периферийного устройства. После компиляции модели вам потребуется только легкая среда выполнения для ее запуска (предоставляется сервисом). Диспетчер Amazon SageMaker Edge отвечает за управление жизненным циклом всех моделей машинного обучения, развернутых на вашем парке периферийных устройств. Edge Manager может управлять парком устройств, состоящим из миллионов устройств. Агент, установленный на каждом из пограничных устройств, предоставляет приложению развернутые модели машинного обучения в виде API. Агент также отвечает за сбор метрик, полезной нагрузки и прогнозов, которые можно использовать для мониторинга или создания нового набора данных для переобучения модели при необходимости. Наконец, с Конвейеры Amazon SageMaker, вы можете создать автоматизированный конвейер со всеми шагами, необходимыми для создания, оптимизации и развертывания моделей машинного обучения на вашем парке устройств. Затем этот автоматизированный конвейер может запускаться простыми определяемыми вами событиями без вмешательства человека.

Вариант использования 1

Допустим, производитель самолетов хочет обнаруживать и отслеживать детали и инструменты в производственном ангаре. Для повышения производительности все необходимые детали и правильные инструменты должны быть доступны для инженеров на каждом этапе производства. Мы хотим иметь возможность отвечать на такие вопросы, как: Где находится часть А? или Где находится инструмент B? У нас уже установлено несколько IP-камер, подключенных к локальной сети. Камеры охватывают весь ангар и могут транслировать HD-видео в реальном времени по сети.

Панорама АВС прекрасно вписывается в этот случай. AWS Panorama предоставляет устройство машинного обучения и управляемый сервис, который позволяет добавить компьютерное зрение (CV) к существующему парку IP-камер и автоматизировать их. AWS Panorama дает вам возможность добавлять CV к существующим IP-камерам и автоматизировать задачи, которые традиционно требуют проверки и мониторинга человеком.

В следующей эталонной архитектуре показаны основные компоненты приложения, работающего на устройстве AWS Panorama. Пакет SDK для приложений Panorama упрощает захват видео с камер, выполнение логических выводов с помощью конвейера из нескольких моделей машинного обучения и обработку результатов с помощью кода Python, работающего внутри контейнера. Вы можете запускать модели из любой популярной библиотеки машинного обучения, такой как TensorFlow, PyTorch или TensorRT. Результаты модели могут быть интегрированы с бизнес-системами в вашей локальной сети, что позволит вам реагировать на события в режиме реального времени.

Решение состоит из следующих шагов:

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

Вариант использования 2

Для нашего следующего варианта использования представьте, что мы создаем видеорегистратор для транспортных средств, способный поддерживать водителя во многих ситуациях, например, объезжая пешеходов, на основе видеорегистратора. Плата CV25 от Ambaralla. Размещение моделей машинного обучения на устройстве с ограниченными системными ресурсами может быть затруднено. В этом случае предположим, что у нас уже есть хорошо зарекомендовавший себя механизм доставки по беспроводной сети (OTA) для развертывания необходимых компонентов приложения на пограничном устройстве. Тем не менее, мы все равно выиграем от возможности выполнять OTA-развертывание самой модели, тем самым изолируя жизненный цикл приложения и жизненный цикл модели.

Диспетчер Amazon SageMaker Edge и Amazon SageMaker Neo хорошо подходит для этого варианта использования.

Edge Manager упрощает периферийным разработчикам машинного обучения использование одних и тех же знакомых инструментов в облаке или на периферийных устройствах. Это сокращает время и усилия, необходимые для запуска моделей в производство, и в то же время позволяет постоянно отслеживать и улучшать качество моделей всего парка устройств. SageMaker Edge включает механизм развертывания OTA, который помогает развертывать модели в парке независимо от приложения или прошивки устройства. Агент Edge Manager позволяет запускать несколько моделей на одном устройстве. Агент собирает прогнозные данные на основе управляемой вами логики, например интервалов, и загружает их в облако, чтобы вы могли периодически переобучать свои модели с течением времени. SageMaker Edge криптографически подписывает ваши модели, чтобы вы могли убедиться, что они не были подделаны при перемещении из облака на периферийное устройство.

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

Следующая диаграмма иллюстрирует эту архитектуру.

Рабочий процесс решения состоит из следующих шагов:

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

Вариант использования 3

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

AWS IoT Гринграсс V2 вместе с Edge Manager хорошо подходят для этого варианта использования. AWS IoT Greengrass — это среда выполнения IoT Edge с открытым исходным кодом и облачный сервис, который помогает создавать, развертывать и управлять приложениями IoT на ваших устройствах. Вы можете использовать AWS IoT Greengrass для создания периферийных приложений с использованием готовых программных модулей, называемых компоненты, который может подключать ваши периферийные устройства к сервисам AWS или сторонним сервисам. Эта возможность AWS IoT Greengrass упрощает развертывание ресурсов на устройствах, включая агент SageMaker Edge. AWS IoT Greengrass отвечает за управление жизненным циклом приложения, а Edge Manager разделяет жизненный цикл модели машинного обучения. Это дает вам возможность продолжать развивать все решение путем независимого развертывания новых версий пограничного приложения и моделей машинного обучения. Следующая диаграмма иллюстрирует эту архитектуру.

Решение состоит из следующих шагов:

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

В нашем последнем случае использования давайте рассмотрим судно, перевозящее контейнеры, где каждый контейнер имеет пару датчиков и передает сигнал в инфраструктуру вычислений и хранения, развернутую локально. Задача состоит в том, что мы хотим знать содержимое каждого контейнера и состояние товаров в зависимости от температуры, влажности и газов внутри каждого контейнера. Мы также хотим отслеживать все товары в каждом из контейнеров. На протяжении всего рейса нет подключения к Интернету, и путешествие может занять месяцы. Модели машинного обучения, работающие в этой инфраструктуре, должны предварительно обрабатывать данные и генерировать информацию, чтобы ответить на все наши вопросы. Сгенерированные данные должны храниться локально в течение нескольких месяцев. Краевое приложение сохраняет все выводы в локальной базе данных, а затем синхронизирует результаты с облаком, когда судно подходит к порту.

Снежный конус AWS и AWS Снежок из Семейство AWS Snow может очень хорошо вписаться в этот вариант использования.

AWS Snowcone — это небольшое, прочное и безопасное устройство для периферийных вычислений и переноса данных. Snowcone разработан в соответствии со стандартом OSHA для устройства, которое может поднимать один человек. Snowcone позволяет запускать периферийные рабочие нагрузки, используя Эластичное вычислительное облако Amazon (Amazon EC2) и локальное хранилище в суровых, изолированных полевых условиях, таких как нефтяные вышки, поисково-спасательные машины, военные объекты или заводские цеха, а также в удаленных офисах, больницах и кинотеатрах.

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

Помимо инстанса EC2, у вас есть свобода создавать и развертывать периферийные решения любого типа. Например: вы можете использовать Амазон ЭКС или другой менеджер контейнеров для развертывания пограничного приложения, агента Edge Manager и модели машинного обучения в виде отдельных контейнеров. Эта архитектура будет аналогична варианту использования 2 (за исключением того, что большую часть времени она будет работать в автономном режиме) с добавлением инструмента управления контейнерами.

Следующая диаграмма иллюстрирует эту архитектуру решения.

Чтобы реализовать это решение, просто закажите свое устройство Snow в Консоль управления AWS и запускайте свои ресурсы.

Заключение

В этом посте мы обсудили различные аспекты Edge, с которыми вы можете работать в зависимости от вашего варианта использования. Мы также обсудили некоторые ключевые концепции, связанные с ML@Edge, и то, как разделение жизненного цикла приложения и жизненного цикла модели ML дает вам свободу их развития без какой-либо зависимости друг от друга. Мы подчеркнули, как выбор правильного периферийного устройства для вашей рабочей нагрузки и задавание правильных вопросов в процессе решения могут помочь вам работать в обратном направлении и сузить круг нужных сервисов AWS. Мы также представили различные варианты использования вместе с эталонными архитектурами, чтобы вдохновить вас на создание собственных решений, которые будут работать для вашей рабочей нагрузки.

---

Об авторах

Динеш Кумар Субрамани является старшим архитектором решений в команде UKIR SMB, базирующейся в Эдинбурге, Шотландия. Он специализируется на искусственном интеллекте и машинном обучении. Динешу нравится работать с клиентами из разных отраслей, помогая им решать проблемы с сервисами AWS. Вне работы он любит проводить время со своей семьей, играть в шахматы и наслаждаться музыкой разных жанров.

Самир Араужо является архитектором решений AI / ML в AWS. Он помогает клиентам создавать решения AI / ML, которые решают их бизнес-задачи с помощью AWS. Он работал над несколькими проектами AI / ML, связанными с компьютерным зрением, обработкой естественного языка, прогнозированием, машинным обучением на периферии и многим другим. В свободное время ему нравится играть с аппаратными средствами и проектами автоматизации, и он особенно интересуется робототехникой.

• Коинсмарт. Лучшая в Европе биржа биткойнов и криптовалют.
• Платоблокчейн. Интеллект метавселенной Web3. Расширение знаний. БЕСПЛАТНЫЙ ДОСТУП.
• КриптоХок. Альткоин Радар. Бесплатная пробная версия.
• Источник: https://aws.amazon.com/blogs/machine-learning/demystifying-machine-learning-at-the-edge-through-real-use-cases/