Desmitificando el aprendizaje automático en el borde a través de casos de uso reales

Southern Implants es un término que hace referencia a una ubicación, lejos de la nube o de un gran centro de datos, donde tiene un dispositivo informático (dispositivo de borde) capaz de ejecutar aplicaciones (de borde). Edge computing es el acto de ejecutar cargas de trabajo en estos dispositivos de borde. El aprendizaje automático en el perímetro (ML@Edge) es un concepto que brinda la capacidad de ejecutar modelos de ML localmente en los dispositivos del perímetro. Estos modelos ML luego pueden ser invocados por la aplicación perimetral. ML@Edge es importante para muchos escenarios en los que se recopilan datos sin procesar de fuentes alejadas de la nube. Estos escenarios también pueden tener requisitos o restricciones específicas:

• Predicciones en tiempo real de baja latencia
• Conectividad pobre o inexistente a la nube
• Restricciones legales que no permiten enviar datos a servicios externos
• Grandes conjuntos de datos que deben preprocesarse localmente antes de enviar respuestas a la nube

Los siguientes son algunos de los muchos casos de uso que pueden beneficiarse de los modelos de ML que se ejecutan cerca del equipo que genera los datos utilizados para las predicciones:

• Seguridad y protección – Un área restringida donde operan máquinas pesadas en un puerto automatizado es monitoreada por una cámara. Si una persona ingresa por error a esta área, se activa un mecanismo de seguridad para detener las máquinas y proteger al humano.
• Mantenimiento predictivo – Los sensores de vibración y audio recopilan datos de una caja de cambios de una turbina eólica. Un modelo de detección de anomalías procesa los datos del sensor e identifica si hay anomalías en el equipo. Si se detecta una anomalía, el dispositivo de borde puede iniciar una medición de contingencia en tiempo real para evitar dañar el equipo, como activar los frenos o desconectar el generador de la red.
• Detección de defectos en líneas de producción – Una cámara captura imágenes de productos en una cinta transportadora y procesa los fotogramas con un modelo de clasificación de imágenes. Si se detecta un defecto, el producto se puede desechar automáticamente sin intervención manual.

Si bien ML@Edge puede abordar muchos casos de uso, existen desafíos arquitectónicos complejos que deben resolverse para tener un diseño seguro, sólido y confiable. En esta publicación, aprenderá algunos detalles sobre ML@Edge, temas relacionados y cómo usar los servicios de AWS para superar estos desafíos e implementar una solución completa para su carga de trabajo de ML en el perímetro.

Descripción general de ML@Edge

Existe una confusión común cuando se trata de ML@Edge e Internet de las cosas (IoT), por lo que es importante aclarar en qué se diferencia ML@Edge de IoT y cómo ambos podrían unirse para brindar una solución poderosa en ciertos casos.

Una solución perimetral que usa ML@Edge tiene dos componentes principales: una aplicación perimetral y un modelo ML (invocado por la aplicación) que se ejecuta en el dispositivo perimetral. ML@Edge se trata de controlar el ciclo de vida de uno o más modelos de ML implementados en una flota de dispositivos de borde. El ciclo de vida del modelo ML puede comenzar en el lado de la nube (en Amazon SageMaker, por ejemplo), pero normalmente termina con una implementación independiente del modelo en el dispositivo perimetral. Cada escenario exige diferentes ciclos de vida del modelo de ML que pueden estar compuestos por muchas etapas, como la recopilación de datos; preparación de datos; creación, compilación e implementación de modelos en el dispositivo perimetral; carga y funcionamiento del modelo; y repetir el ciclo de vida.

El mecanismo ML@Edge no es responsable del ciclo de vida de la aplicación. Se debe adoptar un enfoque diferente para ese propósito. Desvincular el ciclo de vida del modelo de ML y el ciclo de vida de la aplicación le brinda la libertad y la flexibilidad para seguir evolucionando a diferentes ritmos. Imagine una aplicación móvil que incrusta un modelo ML como recurso, como una imagen o un archivo XML. En este caso, cada vez que entrena un nuevo modelo y desea implementarlo en los teléfonos móviles, debe volver a implementar toda la aplicación. Esto consume tiempo y dinero y puede introducir errores en su aplicación. Al desacoplar el ciclo de vida del modelo de ML, publica la aplicación móvil una vez e implementa tantas versiones del modelo de ML como necesite.

Pero, ¿cómo se correlaciona IoT con ML@Edge? IoT se relaciona con objetos físicos integrados con tecnologías como sensores, capacidad de procesamiento y software. Estos objetos están conectados a otros dispositivos y sistemas a través de Internet u otras redes de comunicación, con el fin de intercambiar datos. La siguiente figura ilustra esta arquitectura. El concepto se creó inicialmente al pensar en dispositivos simples que solo recopilan datos desde el borde, realizan un procesamiento local simple y envían el resultado a una unidad informática más poderosa que ejecuta procesos analíticos que ayudan a las personas y empresas en su toma de decisiones. La solución IoT es responsable de controlar el ciclo de vida de la aplicación perimetral. Para obtener más información sobre IoT, consulte Internet de las cosas.

Si ya tiene una aplicación de IoT, puede agregar capacidades de ML@Edge para que el producto sea más eficiente, como se muestra en la siguiente figura. Tenga en cuenta que ML@Edge no depende de IoT, pero puede combinarlos para crear una solución más poderosa. Cuando hace eso, mejora el potencial de su dispositivo simple para generar información en tiempo real para su negocio más rápido que simplemente enviar datos a la nube para su posterior procesamiento.

Si está creando una nueva solución de borde desde cero con capacidades de ML@Edge, es importante diseñar una arquitectura flexible que admita los ciclos de vida de la aplicación y del modelo de ML. Proporcionamos algunas arquitecturas de referencia para aplicaciones perimetrales con ML@Edge más adelante en esta publicación. Pero primero, profundicemos en la informática perimetral y aprendamos a elegir el dispositivo perimetral correcto para su solución, en función de las restricciones del entorno.

Computación de borde

Dependiendo de qué tan lejos esté el dispositivo de la nube o de un gran centro de datos (base), se deben considerar tres características principales de los dispositivos perimetrales para maximizar el rendimiento y la longevidad del sistema: capacidad informática y de almacenamiento, conectividad y consumo de energía. El siguiente diagrama muestra tres grupos de dispositivos de borde que combinan diferentes especificaciones de estas características, dependiendo de qué tan lejos estén de la base.

Los grupos son los siguientes:

• MEC (Computación perimetral de acceso múltiple) – Los MEC o pequeños centros de datos, caracterizados por una latencia baja o ultrabaja y un ancho de banda alto, son entornos comunes donde ML@Edge puede brindar beneficios sin grandes restricciones en comparación con las cargas de trabajo en la nube. Las antenas y servidores 5G en fábricas, almacenes, laboratorios, etc., con restricciones energéticas mínimas y con buena conectividad a Internet, ofrecen diferentes formas de ejecutar modelos ML en GPU y CPU, máquinas virtuales, contenedores y servidores bare-metal.
• Cerca del borde – Esto es cuando la movilidad o la agregación de datos son requisitos y los dispositivos tienen algunas limitaciones con respecto al consumo de energía y la potencia de procesamiento, pero aún tienen una conectividad confiable, aunque con una latencia más alta, con un rendimiento limitado y más costoso que “cerca del borde”. En este grupo se incluyen aplicaciones móviles, placas específicas para acelerar modelos ML o dispositivos simples con capacidad para ejecutar modelos ML, cubiertos por redes inalámbricas.
• Borde lejano – En este escenario extremo, los dispositivos de borde tienen severas restricciones de conectividad o consumo de energía. En consecuencia, la potencia de procesamiento también está restringida en muchos escenarios de extremo extremo. La agricultura, la minería, la vigilancia y la seguridad, y el transporte marítimo son algunas de las áreas en las que los dispositivos de última generación juegan un papel importante. Las placas simples, normalmente sin GPU u otros aceleradores de IA, son comunes. Están diseñados para cargar y ejecutar modelos ML simples, guardar las predicciones en una base de datos local y dormir hasta el próximo ciclo de predicción. Los dispositivos que necesitan procesar datos en tiempo real pueden tener grandes almacenamientos locales para evitar la pérdida de datos.

Desafios

Es común tener escenarios de ML@Edge en los que tiene cientos o miles (quizás incluso millones) de dispositivos que ejecutan los mismos modelos y aplicaciones de borde. Cuando escala su sistema, es importante contar con una solución robusta que pueda administrar la cantidad de dispositivos que necesita admitir. Esta es una tarea compleja y para estos escenarios, necesita hacer muchas preguntas:

• ¿Cómo opero modelos ML en una flota de dispositivos en el perímetro?
• ¿Cómo construyo, optimizo e implemento modelos ML en múltiples dispositivos perimetrales?
• ¿Cómo aseguro mi modelo mientras lo implemento y lo ejecuto en el perímetro?
• ¿Cómo superviso el rendimiento de mi modelo y lo vuelvo a entrenar, si es necesario?
• ¿Cómo elimino la necesidad de instalar un marco grande como TensorFlow o PyTorch en mi dispositivo restringido?
• ¿Cómo expongo uno o varios modelos con mi aplicación perimetral como una API simple?
• ¿Cómo creo un nuevo conjunto de datos con las cargas útiles y las predicciones capturadas por los dispositivos perimetrales?
• ¿Cómo realizo todas estas tareas automáticamente (MLOps más ML@Edge)?

En la siguiente sección, brindamos respuestas a todas estas preguntas a través de ejemplos de casos de uso y arquitecturas de referencia. También analizamos qué servicios de AWS puede combinar para crear soluciones completas para cada uno de los escenarios explorados. Sin embargo, si desea comenzar con un flujo muy simple que describe cómo usar algunos de los servicios proporcionados por AWS para crear su solución ML@Edge, este es un ejemplo:

Con SageMaker, puede preparar fácilmente un conjunto de datos y crear los modelos de ML que se implementan en los dispositivos perimetrales. Con Amazon SageMaker Neo, puede compilar y optimizar el modelo que entrenó para el dispositivo perimetral específico que eligió. Después de compilar el modelo, solo necesita un tiempo de ejecución ligero para ejecutarlo (proporcionado por el servicio). Administrador de borde de Amazon SageMaker es responsable de administrar el ciclo de vida de todos los modelos de ML implementados en su flota de dispositivos perimetrales. Edge Manager puede administrar flotas de hasta millones de dispositivos. Un agente, instalado en cada uno de los dispositivos perimetrales, expone los modelos de ML implementados como una API para la aplicación. El agente también es responsable de recopilar métricas, cargas útiles y predicciones que puede usar para monitorear o crear un nuevo conjunto de datos para volver a entrenar el modelo si es necesario. Finalmente, con Canalizaciones de Amazon SageMaker, puede crear una canalización automatizada con todos los pasos necesarios para crear, optimizar e implementar modelos ML en su flota de dispositivos. Esta canalización automatizada se puede activar mediante eventos simples que defina, sin intervención humana.

Caso de uso 1

Supongamos que un fabricante de aviones quiere detectar y rastrear piezas y herramientas en el hangar de producción. Para mejorar la productividad, todas las piezas necesarias y las herramientas correctas deben estar disponibles para los ingenieros en cada etapa de la producción. Queremos poder responder preguntas como: ¿Dónde está la parte A? o ¿Dónde está la herramienta B? Tenemos varias cámaras IP ya instaladas y conectadas a una red local. Las cámaras cubren todo el hangar y pueden transmitir video HD en tiempo real a través de la red.

Panorama de AWS encaja muy bien en este caso. AWS Panorama proporciona un dispositivo ML y un servicio administrado que le permite agregar visión artificial (CV) a su flota existente de cámaras IP y automatizar. AWS Panorama le brinda la capacidad de agregar CV a sus cámaras de Protocolo de Internet (IP) existentes y automatizar tareas que tradicionalmente requieren inspección y monitoreo humanos.

En la siguiente arquitectura de referencia, mostramos los principales componentes de la aplicación que se ejecutan en un dispositivo AWS Panorama. El SDK de la aplicación Panorama facilita la captura de video de transmisiones de cámara, realiza inferencias con una canalización de múltiples modelos ML y procesa los resultados utilizando el código Python que se ejecuta dentro de un contenedor. Puede ejecutar modelos desde cualquier biblioteca de aprendizaje automático popular, como TensorFlow, PyTorch o TensorRT. Los resultados del modelo se pueden integrar con los sistemas comerciales en su red de área local, lo que le permite responder a los eventos en tiempo real.

La solución consta de los siguientes pasos:

1. Conecte y configure un dispositivo de AWS Panorama a la misma red local.
2. Entrene un modelo ML (detección de objetos) para identificar piezas y herramientas en cada cuadro.
3. Cree una aplicación de AWS Panorama que obtenga las predicciones del modelo de ML, aplique un mecanismo de seguimiento a cada objeto y envíe los resultados a una base de datos en tiempo real.
4. Los operadores pueden enviar consultas a la base de datos para localizar las piezas y herramientas.

Caso de uso 2

Para nuestro próximo caso de uso, imagina que estamos creando una dashcam para vehículos capaz de ayudar al conductor en muchas situaciones, como evitar a los peatones, en función de una Tablero CV25 de Ambaralla. Alojar modelos ML en un dispositivo con recursos de sistema limitados puede ser difícil. En este caso, supongamos que ya contamos con un mecanismo de entrega por aire (OTA) bien establecido para implementar los componentes de la aplicación necesarios en el dispositivo perimetral. Sin embargo, aún nos beneficiaríamos de la capacidad de realizar la implementación OTA del modelo en sí, aislando así el ciclo de vida de la aplicación y el ciclo de vida del modelo.

Administrador de borde de Amazon SageMaker y Amazon SageMaker Neo encaja bien para este caso de uso.

Edge Manager facilita a los desarrolladores de borde de ML el uso de las mismas herramientas familiares en la nube o en dispositivos de borde. Reduce el tiempo y el esfuerzo necesarios para llevar los modelos a la producción, al tiempo que le permite monitorear y mejorar continuamente la calidad del modelo en toda su flota de dispositivos. SageMaker Edge incluye un mecanismo de implementación OTA que lo ayuda a implementar modelos en la flota independientemente de la aplicación o el firmware del dispositivo. los Agente de Edge Manager le permite ejecutar varios modelos en el mismo dispositivo. El agente recopila datos de predicción en función de la lógica que usted controla, como intervalos, y los carga en la nube para que pueda volver a entrenar periódicamente sus modelos a lo largo del tiempo. SageMaker Edge firma criptográficamente sus modelos para que pueda verificar que no haya sido manipulado mientras se mueve de la nube al dispositivo perimetral.

Neo es un compilador como servicio y encaja especialmente bien en este caso de uso. Neo optimiza automáticamente los modelos ML para la inferencia en instancias en la nube y dispositivos de borde para ejecutarse más rápido sin pérdida de precisión. Comienzas con un modelo de ML construido con uno de marcos compatibles y entrenado en SageMaker o en cualquier otro lugar. Luego, elige la plataforma de hardware de destino (consulte la lista de dispositivos soportados). Con un solo clic, Neo optimiza el modelo entrenado y lo compila en un paquete que se puede ejecutar con el tiempo de ejecución ligero de SageMaker Edge. El compilador usa un modelo de ML para aplicar las optimizaciones de rendimiento que extraen el mejor rendimiento disponible para su modelo en la instancia de la nube o el dispositivo perimetral. A continuación, implementa el modelo como punto final de SageMaker o en dispositivos perimetrales compatibles y comienza a realizar predicciones.

El siguiente diagrama ilustra esta arquitectura.

El flujo de trabajo de la solución consta de los siguientes pasos:

1. El desarrollador construye, entrena, valida y crea el artefacto del modelo final que debe implementarse en la dashcam.
2. Invoque Neo para compilar el modelo entrenado.
3. El agente de SageMaker Edge está instalado y configurado en el dispositivo Edge, en este caso, la dashcam.
4. Cree un paquete de implementación con un modelo firmado y el tiempo de ejecución utilizado por el agente de SageMaker Edge para cargar e invocar el modelo optimizado.
5. Implemente el paquete utilizando el mecanismo de implementación OTA existente.
6. La aplicación perimetral interactúa con el agente de SageMaker Edge para realizar inferencias.
7. El agente se puede configurar (si es necesario) para enviar datos de entrada de muestra en tiempo real desde la aplicación con fines de monitoreo y refinamiento del modelo.

Caso de uso 3

Suponga que su cliente está desarrollando una aplicación que detecta anomalías en los mecanismos de una turbina eólica (como la caja de cambios, el generador o el rotor). El objetivo es minimizar el daño en el equipo mediante la ejecución de procedimientos de protección locales sobre la marcha. Estas turbinas son muy costosas y están ubicadas en lugares que no son de fácil acceso. Cada turbina se puede equipar con un dispositivo NVIDIA Jetson para monitorear los datos del sensor de la turbina. Luego necesitamos una solución para capturar los datos y usar un algoritmo ML para detectar anomalías. También necesitamos un mecanismo OTA para mantener actualizados el software y los modelos ML en el dispositivo.

AWS IOT Greengrass V2 junto con Edge Manager encajan bien en este caso de uso. AWS IoT Greengrass es un servicio en la nube y en tiempo de ejecución perimetral de IoT de código abierto que lo ayuda a crear, implementar y administrar aplicaciones de IoT en sus dispositivos. Puede utilizar AWS IoT Greengrass para crear aplicaciones perimetrales mediante módulos de software prediseñados, denominados componentes, que puede conectar sus dispositivos perimetrales a servicios de AWS o servicios de terceros. Esta capacidad de AWS IoT Greengrass facilita la implementación de activos en dispositivos, incluido un agente de SageMaker Edge. AWS IoT Greengrass es responsable de administrar el ciclo de vida de la aplicación, mientras que Edge Manager desacopla el ciclo de vida del modelo ML. Esto le brinda la flexibilidad de seguir evolucionando toda la solución al implementar nuevas versiones de la aplicación perimetral y los modelos ML de forma independiente. El siguiente diagrama ilustra esta arquitectura.

La solución consta de los siguientes pasos:

1. El desarrollador construye, entrena, valida y crea el artefacto del modelo final que debe implementarse en la turbina eólica.
2. Invoque Neo para compilar el modelo entrenado.
3. Cree un componente de modelo utilizando Edge Manager con la integración de AWS IoT Greengrass V2.
4. Configure AWS IoT Greengrass V2.
5. Cree un componente de inferencia con AWS IoT Greengrass V2.
6. La aplicación perimetral interactúa con el agente de SageMaker Edge para realizar inferencias.
7. El agente se puede configurar (si es necesario) para enviar datos de entrada de muestra en tiempo real desde la aplicación con fines de monitoreo y refinamiento del modelo.

Caso de uso 4

Para nuestro caso de uso final, echemos un vistazo a un barco que transporta contenedores, donde cada contenedor tiene un par de sensores y transmite una señal a la infraestructura informática y de almacenamiento implementada localmente. El desafío es que queremos saber el contenido de cada contenedor y el estado de los productos en función de la temperatura, la humedad y los gases dentro de cada contenedor. También queremos rastrear toda la mercancía en cada uno de los contenedores. No hay conectividad a Internet durante todo el viaje, y el viaje puede llevar meses. Los modelos de ML que se ejecutan en esta infraestructura deben preprocesar los datos y generar información para responder a todas nuestras preguntas. Los datos generados deben almacenarse localmente durante meses. La aplicación perimetral almacena todas las inferencias en una base de datos local y luego sincroniza los resultados con la nube cuando el barco se acerca al puerto.

Cono de nieve de AWS y Bola de nieve de AWS del desplegable Familia de nieve AWS podría encajar muy bien en este caso de uso.

AWS Snowcone es un dispositivo de migración de datos y computación perimetral pequeño, resistente y seguro. Snowcone está diseñado según el estándar OSHA para un dispositivo levantable por una sola persona. Snowcone le permite ejecutar cargas de trabajo perimetrales mediante Nube informática elástica de Amazon (Amazon EC2) y almacenamiento local en entornos de campo duros y desconectados, como plataformas petroleras, vehículos de búsqueda y rescate, sitios militares o plantas de fábrica, así como oficinas remotas, hospitales y cines.

Snowball agrega más computación en comparación con Snowcone y, por lo tanto, puede ser ideal para aplicaciones más exigentes. La función Compute Optimized proporciona una GPU NVIDIA Tesla V100 opcional junto con instancias EC2 para acelerar el rendimiento de una aplicación en entornos desconectados. Con la opción de GPU, puede ejecutar aplicaciones como ML avanzado y análisis de video de movimiento completo en entornos con poca o ninguna conectividad.

Además de la instancia EC2, tiene la libertad de crear e implementar cualquier tipo de solución perimetral. Por ejemplo: puedes usar Amazon ECS u otro administrador de contenedores para implementar la aplicación perimetral, el Agente de administración perimetral y el modelo ML como contenedores individuales. Esta arquitectura sería similar al caso de uso 2 (excepto que funcionará sin conexión la mayor parte del tiempo), con la adición de una herramienta de administración de contenedores.

El siguiente diagrama ilustra la arquitectura de esta solución.

Para implementar esta solución, simplemente pida su dispositivo Snow al Consola de administración de AWS y lanza tus recursos.

Conclusión

En esta publicación, discutimos los diferentes aspectos de Edge con los que puede elegir trabajar según su caso de uso. También discutimos algunos de los conceptos clave en torno a ML@Edge y cómo desacoplar el ciclo de vida de la aplicación y el ciclo de vida del modelo ML le brinda la libertad de evolucionarlos sin ninguna dependencia entre sí. Hicimos hincapié en cómo elegir el dispositivo de borde correcto para su carga de trabajo y hacer las preguntas correctas durante el proceso de solución puede ayudarlo a trabajar hacia atrás y reducir los servicios de AWS correctos. También presentamos diferentes casos de uso junto con arquitecturas de referencia para inspirarlo a crear sus propias soluciones que funcionarán para su carga de trabajo.

---

Acerca de los autores

Dinesh Kumar Subramani es Arquitecto de Soluciones Sénior en el equipo SMB de UKIR, con sede en Edimburgo, Escocia. Se especializa en inteligencia artificial y aprendizaje automático. Dinesh disfruta trabajar con clientes de todas las industrias para ayudarlos a resolver sus problemas con los servicios de AWS. Fuera del trabajo, le encanta pasar tiempo con su familia, jugar al ajedrez y disfrutar de la música de todos los géneros.

Samir Araújo es un arquitecto de soluciones de AI / ML en AWS. Ayuda a los clientes a crear soluciones de IA / ML que resuelven sus desafíos comerciales mediante AWS. Ha estado trabajando en varios proyectos de IA / ML relacionados con la visión por computadora, el procesamiento del lenguaje natural, el pronóstico, el aprendizaje automático en el borde y más. Le gusta jugar con proyectos de hardware y automatización en su tiempo libre, y tiene un interés particular por la robótica.

• Coinsmart. El mejor intercambio de Bitcoin y criptografía de Europa.
• Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. ACCESO LIBRE.
• CriptoHawk. Radar de altcoins. Prueba gratis.
• Fuente: https://aws.amazon.com/blogs/machine-learning/demystifying-machine-learning-at-the-edge-through-real-use-cases/