Desmistificando o aprendizado de máquina na borda por meio de casos de uso reais

borda é um termo que se refere a um local, longe da nuvem ou de um grande data center, onde você tem um dispositivo de computador (dispositivo de borda) capaz de executar aplicativos (de borda). A computação de borda é o ato de executar cargas de trabalho nesses dispositivos de borda. O aprendizado de máquina na borda (ML@Edge) é um conceito que traz a capacidade de executar modelos de ML localmente para dispositivos de borda. Esses modelos de ML podem ser invocados pelo aplicativo de borda. O ML@Edge é importante para muitos cenários em que os dados brutos são coletados de fontes distantes da nuvem. Esses cenários também podem ter requisitos ou restrições específicos:

• Previsões de baixa latência e em tempo real
• Conectividade ruim ou inexistente com a nuvem
• Restrições legais que não permitem o envio de dados para serviços externos
• Grandes conjuntos de dados que precisam ser pré-processados ​​localmente antes de enviar respostas para a nuvem

A seguir estão alguns dos muitos casos de uso que podem se beneficiar de modelos de ML executados próximos ao equipamento que gera os dados usados ​​para as previsões:

• Segurança e proteção – Uma área restrita onde máquinas pesadas operam em um porto automatizado é monitorada por uma câmera. Se uma pessoa entrar nesta área por engano, um mecanismo de segurança é ativado para parar as máquinas e proteger o humano.
• Manutenção preditiva – Sensores de vibração e áudio coletam dados de uma caixa de engrenagens de uma turbina eólica. Um modelo de detecção de anomalias processa os dados do sensor e identifica se há anomalias no equipamento. Caso seja detectada alguma anomalia, o dispositivo de borda pode iniciar uma medição de contingência em tempo real para evitar danos ao equipamento, como acionar os freios ou desconectar o gerador da rede.
• Detecção de defeitos em linhas de produção – Uma câmera captura imagens de produtos em uma esteira transportadora e processa os quadros com um modelo de classificação de imagens. Se for detectado um defeito, o produto pode ser descartado automaticamente sem intervenção manual.

Embora o ML@Edge possa atender a muitos casos de uso, existem desafios arquitetônicos complexos que precisam ser resolvidos para se ter um design seguro, robusto e confiável. Nesta postagem, você aprenderá alguns detalhes sobre ML@Edge, tópicos relacionados e como usar os serviços da AWS para superar esses desafios e implementar uma solução completa para sua carga de trabalho de ML na borda.

Visão geral do ML@Edge

Há uma confusão comum quando se trata de ML@Edge e Internet das Coisas (IoT), portanto, é importante esclarecer como ML@Edge é diferente de IoT e como ambos podem se unir para fornecer uma solução poderosa em determinados casos.

Uma solução de borda que usa ML@Edge tem dois componentes principais: um aplicativo de borda e um modelo de ML (chamado pelo aplicativo) em execução no dispositivo de borda. O ML@Edge trata do controle do ciclo de vida de um ou mais modelos de ML implantados em uma frota de dispositivos de borda. O ciclo de vida do modelo de ML pode começar no lado da nuvem (no Amazon Sage Maker, por exemplo), mas normalmente termina em uma implantação autônoma do modelo no dispositivo de borda. Cada cenário exige diferentes ciclos de vida do modelo de ML que podem ser compostos por vários estágios, como coleta de dados; preparação de dados; construção, compilação e implantação de modelos no dispositivo de borda; carregamento e execução do modelo; e repetir o ciclo de vida.

O mecanismo ML@Edge não é responsável pelo ciclo de vida do aplicativo. Uma abordagem diferente deve ser adotada para esse fim. A dissociação do ciclo de vida do modelo de ML e do ciclo de vida do aplicativo oferece liberdade e flexibilidade para continuar evoluindo em ritmos diferentes. Imagine um aplicativo móvel que incorpora um modelo de ML como um recurso como uma imagem ou arquivo XML. Nesse caso, cada vez que você treina um novo modelo e deseja implantá-lo nos telefones celulares, é necessário reimplantar todo o aplicativo. Isso consome tempo e dinheiro e pode introduzir bugs em seu aplicativo. Ao desacoplar o ciclo de vida do modelo de ML, você publica o aplicativo móvel uma vez e implanta quantas versões do modelo de ML forem necessárias.

Mas como a IoT se correlaciona com o ML@Edge? A IoT está relacionada a objetos físicos incorporados a tecnologias como sensores, capacidade de processamento e software. Esses objetos são conectados a outros dispositivos e sistemas pela internet ou outras redes de comunicação, a fim de trocar dados. A figura a seguir ilustra essa arquitetura. O conceito foi criado inicialmente pensando em dispositivos simples que apenas coletam dados da borda, realizam processamento local simples e enviam o resultado para uma unidade computacional mais poderosa que executa processos analíticos que auxiliam pessoas e empresas na tomada de decisões. A solução IoT é responsável por controlar o ciclo de vida do aplicativo de borda. Para obter mais informações sobre IoT, consulte Internet das coisas.

Se você já tiver um aplicativo IoT, poderá adicionar recursos ML@Edge para tornar o produto mais eficiente, conforme mostrado na figura a seguir. Lembre-se de que o ML@Edge não depende da IoT, mas você pode combiná-los para criar uma solução mais poderosa. Ao fazer isso, você melhora o potencial de seu dispositivo simples para gerar insights em tempo real para seus negócios mais rapidamente do que apenas enviar dados para a nuvem para processamento posterior.

Se você estiver criando uma nova solução de borda do zero com recursos de ML@Edge, é importante projetar uma arquitetura flexível que dê suporte aos ciclos de vida do aplicativo e do modelo de ML. Fornecemos algumas arquiteturas de referência para aplicativos de borda com ML@Edge posteriormente neste post. Mas primeiro, vamos nos aprofundar na computação de borda e aprender a escolher o dispositivo de borda correto para sua solução, com base nas restrições do ambiente.

Computação de borda

Dependendo de quão longe o dispositivo está da nuvem ou de um grande data center (base), três características principais dos dispositivos de borda precisam ser consideradas para maximizar o desempenho e a longevidade do sistema: capacidade de computação e armazenamento, conectividade e consumo de energia. O diagrama a seguir mostra três grupos de dispositivos de borda que combinam diferentes especificações dessas características, dependendo da distância em que estão da base.

Os grupos são os seguintes:

• MECs (computação de borda multiacesso) – MECs ou pequenos data centers, caracterizados por latência baixa ou ultrabaixa e alta largura de banda, são ambientes comuns onde o ML@Edge pode trazer benefícios sem grandes restrições quando comparado às cargas de trabalho na nuvem. Antenas e servidores 5G em fábricas, armazéns, laboratórios e assim por diante com restrições mínimas de energia e boa conectividade com a Internet oferecem diferentes maneiras de executar modelos de ML em GPUs e CPUs, máquinas virtuais, contêineres e servidores bare-metal.
• Perto da borda – É quando mobilidade ou agregação de dados são requisitos e os dispositivos têm algumas restrições em relação ao consumo de energia e poder de processamento, mas ainda têm alguma conectividade confiável, embora com maior latência, com throughput limitado e mais caro do que “perto da borda”. Estão incluídos neste grupo aplicativos móveis, placas específicas para acelerar modelos de ML ou dispositivos simples com capacidade para executar modelos de ML, cobertos por redes sem fio.
• Borda distante – Nesse cenário extremo, os dispositivos de borda têm restrições severas de consumo de energia ou conectividade. Consequentemente, o poder de processamento também é restrito em muitos cenários de borda distante. Agricultura, mineração, vigilância e segurança e transporte marítimo são algumas áreas onde os dispositivos de ponta desempenham um papel importante. Placas simples, normalmente sem GPUs ou outros aceleradores de IA, são comuns. Eles são projetados para carregar e executar modelos de ML simples, salvar as previsões em um banco de dados local e dormir até o próximo ciclo de previsão. Os dispositivos que precisam processar dados em tempo real podem ter grandes armazenamentos locais para evitar a perda de dados.

Desafios

É comum ter cenários ML@Edge em que você tem centenas ou milhares (talvez até milhões) de dispositivos executando os mesmos modelos e aplicativos de borda. Ao dimensionar seu sistema, é importante ter uma solução robusta que possa gerenciar o número de dispositivos aos quais você precisa dar suporte. Essa é uma tarefa complexa e, para esses cenários, você precisa fazer muitas perguntas:

• Como opero modelos de ML em uma frota de dispositivos na borda?
• Como crio, otimizo e implemento modelos de ML em vários dispositivos de borda?
• Como faço para proteger meu modelo ao implantá-lo e executá-lo na borda?
• Como monitoro o desempenho do meu modelo e o treino novamente, se necessário?
• Como elimino a necessidade de instalar um grande framework como TensorFlow ou PyTorch no meu dispositivo restrito?
• Como exponho um ou vários modelos com meu aplicativo de borda como uma API simples?
• Como crio um novo conjunto de dados com as cargas úteis e previsões capturadas pelos dispositivos de borda?
• Como faço todas essas tarefas automaticamente (MLOps mais ML@Edge)?

Na próxima seção, fornecemos respostas para todas essas perguntas por meio de exemplos de casos de uso e arquiteturas de referência. Também discutimos quais serviços da AWS você pode combinar para criar soluções completas para cada um dos cenários explorados. No entanto, se você deseja começar com um fluxo muito simples que descreve como usar alguns dos serviços fornecidos pela AWS para criar sua solução ML@Edge, este é um exemplo:

Com o SageMaker, você pode preparar facilmente um conjunto de dados e criar os modelos de ML que são implantados nos dispositivos de borda. Com Amazon Sage Maker Neo, você pode compilar e otimizar o modelo que treinou para o dispositivo de borda específico escolhido. Depois de compilar o modelo, você só precisa de um tempo de execução leve para executá-lo (fornecido pelo serviço). Gerenciador de borda do Amazon SageMaker é responsável por gerenciar o ciclo de vida de todos os modelos de ML implantados em sua frota de dispositivos de borda. O Edge Manager pode gerenciar frotas de até milhões de dispositivos. Um agente, instalado em cada um dos dispositivos de borda, expõe os modelos de ML implantados como uma API para o aplicativo. O agente também é responsável por coletar métricas, cargas úteis e previsões que você pode usar para monitorar ou construir um novo conjunto de dados para treinar novamente o modelo, se necessário. Finalmente, com Pipelines Amazon SageMaker, você pode criar um pipeline automatizado com todas as etapas necessárias para criar, otimizar e implantar modelos de ML em sua frota de dispositivos. Esse pipeline automatizado pode ser acionado por eventos simples que você define, sem intervenção humana.

Caso de uso 1

Digamos que um fabricante de aviões deseja detectar e rastrear peças e ferramentas no hangar de produção. Para melhorar a produtividade, todas as peças necessárias e as ferramentas corretas precisam estar disponíveis para os engenheiros em cada etapa da produção. Queremos ser capazes de responder a perguntas como: Onde está a parte A? ou Onde está a ferramenta B? Temos várias câmeras IP já instaladas e conectadas a uma rede local. As câmeras cobrem todo o hangar e podem transmitir vídeo HD em tempo real pela rede.

Panorama AWS se encaixa bem neste caso. O AWS Panorama fornece um dispositivo de ML e um serviço gerenciado que permite adicionar visão computacional (CV) à sua frota existente de câmeras IP e automatizar. O AWS Panorama oferece a capacidade de adicionar CV às suas câmeras IP (Internet Protocol) existentes e automatizar tarefas que tradicionalmente exigem inspeção e monitoramento humanos.

Na arquitetura de referência a seguir, mostramos os principais componentes do aplicativo em execução em um AWS Panorama Appliance. O Panorama Application SDK facilita a captura de vídeo de fluxos de câmera, realiza inferência com um pipeline de vários modelos de ML e processa os resultados usando código Python executado dentro de um contêiner. Você pode executar modelos de qualquer biblioteca de ML popular, como TensorFlow, PyTorch ou TensorRT. Os resultados do modelo podem ser integrados aos sistemas de negócios em sua rede local, permitindo que você responda a eventos em tempo real.

A solução consiste nas seguintes etapas:

1. Conecte e configure um dispositivo AWS Panorama à mesma rede local.
2. Treine um modelo de ML (detecção de objetos) para identificar peças e ferramentas em cada quadro.
3. Crie um aplicativo do AWS Panorama que obtenha as previsões do modelo de ML, aplique um mecanismo de rastreamento a cada objeto e envie os resultados para um banco de dados em tempo real.
4. Os operadores podem enviar consultas ao banco de dados para localizar as peças e ferramentas.

Caso de uso 2

Para nosso próximo caso de uso, imagine que estamos criando uma dashcam para veículos capaz de auxiliar o motorista em diversas situações, como evitar pedestres, com base em uma Placa CV25 da Ambaralla. Hospedar modelos de ML em um dispositivo com recursos de sistema limitados pode ser difícil. Nesse caso, vamos supor que já tenhamos um mecanismo de entrega OTA (over-the-air) bem estabelecido para implantar os componentes do aplicativo necessários no dispositivo de borda. No entanto, ainda nos beneficiaríamos da capacidade de fazer a implantação OTA do próprio modelo, isolando assim o ciclo de vida do aplicativo e o ciclo de vida do modelo.

Gerenciador de borda do Amazon SageMaker e Amazon Sage Maker Neo se encaixam bem para este caso de uso.

O Edge Manager facilita para os desenvolvedores de ML de borda usar as mesmas ferramentas familiares na nuvem ou em dispositivos de borda. Ele reduz o tempo e o esforço necessários para colocar os modelos em produção, ao mesmo tempo em que permite monitorar e melhorar continuamente a qualidade do modelo em toda a frota de dispositivos. O SageMaker Edge inclui um mecanismo de implantação OTA que ajuda você a implantar modelos na frota independentemente do firmware do aplicativo ou do dispositivo. o Agente Edge Manager permite que você execute vários modelos no mesmo dispositivo. O agente coleta dados de previsão com base na lógica que você controla, como intervalos, e os carrega na nuvem para que você possa treinar seus modelos periodicamente ao longo do tempo. O SageMaker Edge assina criptograficamente seus modelos para que você possa verificar se ele não foi adulterado ao passar da nuvem para o dispositivo de borda.

Neo é um compilador como serviço e um ajuste especialmente bom neste caso de uso. O Neo otimiza automaticamente os modelos de ML para inferência em instâncias de nuvem e dispositivos de borda para execução mais rápida sem perda de precisão. Você começa com um modelo de ML criado com um dos estruturas suportadas e treinado no SageMaker ou em qualquer outro lugar. Em seguida, você escolhe sua plataforma de hardware de destino (consulte a lista de dispositivos suportados). Com um único clique, o Neo otimiza o modelo treinado e o compila em um pacote que pode ser executado usando o tempo de execução leve do SageMaker Edge. O compilador usa um modelo de ML para aplicar as otimizações de desempenho que extraem o melhor desempenho disponível para seu modelo na instância de nuvem ou dispositivo de borda. Em seguida, você implanta o modelo como um endpoint do SageMaker ou em dispositivos de borda compatíveis e começa a fazer previsões.

O diagrama a seguir ilustra essa arquitetura.

O fluxo de trabalho da solução consiste nas seguintes etapas:

1. O desenvolvedor constrói, treina, valida e cria o artefato do modelo final que precisa ser implantado na dashcam.
2. Invoque o Neo para compilar o modelo treinado.
3. O agente SageMaker Edge é instalado e configurado no dispositivo Edge, neste caso a dashcam.
4. Crie um pacote de implantação com um modelo assinado e o tempo de execução usado pelo agente SageMaker Edge para carregar e invocar o modelo otimizado.
5. Implante o pacote usando o mecanismo de implantação OTA existente.
6. O aplicativo de borda interage com o agente SageMaker Edge para fazer inferência.
7. O agente pode ser configurado (se necessário) para enviar dados de entrada de amostra em tempo real do aplicativo para fins de monitoramento e refinamento do modelo.

Caso de uso 3

Suponha que seu cliente esteja desenvolvendo um aplicativo que detecta anomalias nos mecanismos de uma turbina eólica (como caixa de engrenagens, gerador ou rotor). O objetivo é minimizar os danos no equipamento executando procedimentos de proteção local em tempo real. Essas turbinas são muito caras e localizadas em locais de difícil acesso. Cada turbina pode ser equipada com um dispositivo NVIDIA Jetson para monitorar os dados do sensor da turbina. Em seguida, precisamos de uma solução para capturar os dados e usar um algoritmo de ML para detectar anomalias. Também precisamos de um mecanismo OTA para manter o software e os modelos de ML no dispositivo atualizados.

AWS IoT Greengrass V2 junto com o Edge Manager se encaixam bem neste caso de uso. O AWS IoT Greengrass é um serviço de nuvem e tempo de execução de borda de IoT de código aberto que ajuda você a criar, implantar e gerenciar aplicativos de IoT em seus dispositivos. Você pode usar o AWS IoT Greengrass para criar aplicativos de borda usando módulos de software pré-criados, chamados componentes, que pode conectar seus dispositivos de borda a serviços da AWS ou serviços de terceiros. Essa capacidade do AWS IoT Greengrass facilita a implantação de ativos em dispositivos, incluindo um agente SageMaker Edge. O AWS IoT Greengrass é responsável por gerenciar o ciclo de vida do aplicativo, enquanto o Edge Manager dissocia o ciclo de vida do modelo de ML. Isso oferece a flexibilidade de continuar evoluindo toda a solução implantando novas versões do aplicativo de borda e modelos de ML de forma independente. O diagrama a seguir ilustra essa arquitetura.

A solução consiste nas seguintes etapas:

1. O desenvolvedor constrói, treina, valida e cria o artefato do modelo final que precisa ser implantado na turbina eólica.
2. Invoque o Neo para compilar o modelo treinado.
3. Crie um componente de modelo usando o Edge Manager com integração AWS IoT Greengrass V2.
4. Configure o AWS IoT Greengrass V2.
5. Crie um componente de inferência usando o AWS IoT Greengrass V2.
6. O aplicativo de borda interage com o agente SageMaker Edge para fazer inferência.
7. O agente pode ser configurado (se necessário) para enviar dados de entrada de amostra em tempo real do aplicativo para fins de monitoramento e refinamento do modelo.

Caso de uso 4

Para nosso caso de uso final, vejamos uma embarcação transportando contêineres, em que cada contêiner tem alguns sensores e transmite um sinal para a infraestrutura de computação e armazenamento implantada localmente. O desafio é que queremos saber o conteúdo de cada contêiner e a condição das mercadorias com base na temperatura, umidade e gases dentro de cada contêiner. Também queremos rastrear todas as mercadorias em cada um dos contêineres. Não há conectividade com a Internet durante toda a viagem, e a viagem pode levar meses. Os modelos de ML executados nessa infraestrutura devem pré-processar os dados e gerar informações para responder a todas as nossas perguntas. Os dados gerados precisam ser armazenados localmente por meses. O aplicativo de borda armazena todas as inferências em um banco de dados local e depois sincroniza os resultados com a nuvem quando a embarcação se aproxima do porto.

AWS Snowcone e Bola de neve da AWS do Família de neve da AWS poderia se encaixar muito bem neste caso de uso.

O AWS Snowcone é um dispositivo de migração de dados e computação de borda pequeno, robusto e seguro. O Snowcone foi projetado de acordo com o padrão OSHA para um dispositivo elevável de uma pessoa. O Snowcone permite que você execute cargas de trabalho de borda usando Amazon Elastic Compute Nuvem (Amazon EC2) e armazenamento local em ambientes de campo difíceis e desconectados, como plataformas de petróleo, veículos de busca e salvamento, instalações militares ou fábricas, bem como escritórios remotos, hospitais e cinemas.

O Snowball adiciona mais computação quando comparado ao Snowcone e, portanto, pode ser uma ótima opção para aplicativos mais exigentes. O recurso Compute Optimized fornece uma GPU NVIDIA Tesla V100 opcional junto com instâncias EC2 para acelerar o desempenho de um aplicativo em ambientes desconectados. Com a opção de GPU, você pode executar aplicativos como ML avançado e análise de vídeo em movimento total em ambientes com pouca ou nenhuma conectividade.

Além da instância do EC2, você tem a liberdade de criar e implantar qualquer tipo de solução de borda. Por exemplo: você pode usar Amazon ECS ou outro gerenciador de contêineres para implantar o aplicativo de borda, o Agente do Gerenciador de Borda e o modelo de ML como contêineres individuais. Essa arquitetura seria semelhante ao Caso de Uso 2 (exceto que funcionará offline na maioria das vezes), com a adição de uma ferramenta gerenciadora de contêineres.

O diagrama a seguir ilustra essa arquitetura de solução.

Para implementar esta solução, basta encomendar o seu dispositivo Snow ao Console de gerenciamento da AWS e lançar seus recursos.

Conclusão

Neste post, discutimos os diferentes aspectos da borda com os quais você pode optar por trabalhar com base no seu caso de uso. Também discutimos alguns dos principais conceitos em torno do ML@Edge e como dissociar o ciclo de vida do aplicativo e o ciclo de vida do modelo de ML oferece a liberdade de evoluí-los sem qualquer dependência um do outro. Enfatizamos como escolher o dispositivo de borda certo para sua carga de trabalho e fazer as perguntas certas durante o processo de solução pode ajudá-lo a trabalhar para trás e restringir os serviços certos da AWS. Também apresentamos diferentes casos de uso junto com arquiteturas de referência para inspirá-lo a criar suas próprias soluções que funcionarão para sua carga de trabalho.

---

Sobre os autores

Dinesh Kumar Subramani é Arquiteto de Soluções Sênior da equipe UKIR SMB, com sede em Edimburgo, Escócia. Ele é especialista em inteligência artificial e aprendizado de máquina. Dinesh gosta de trabalhar com clientes de todos os setores para ajudá-los a resolver seus problemas com os serviços da AWS. Fora do trabalho, ele adora passar tempo com sua família, jogar xadrez e curtir música em todos os gêneros.

Samir Araújo é arquiteto de soluções de AI / ML na AWS. Ele ajuda os clientes a criar soluções de AI / ML que resolvem seus desafios de negócios usando AWS. Ele tem trabalhado em vários projetos de AI / ML relacionados à visão computacional, processamento de linguagem natural, previsão, ML na borda e muito mais. Ele gosta de brincar com projetos de hardware e automação em seu tempo livre e tem um interesse particular por robótica.

• Coinsmart. A melhor troca de Bitcoin e criptografia da Europa.
• Platoblockchain. Inteligência Metaverso Web3. Conhecimento Ampliado. ACESSO LIVRE.
• CryptoHawk. Radar Altcoin. Teste grátis.
• Fonte: https://aws.amazon.com/blogs/machine-learning/demystifying-machine-learning-at-the-edge-through-real-use-cases/