通过真实用例揭开边缘机器学习的神秘面纱

边缘 是一个术语，指的是远离云或大数据中心的位置，您拥有能够运行（边缘）应用程序的计算机设备（边缘设备）。 边缘计算是在这些边缘设备上运行工作负载的行为。 边缘机器学习 (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 模型生命周期可以从云端开始（在 亚马逊SageMaker，例如），但通常以模型在边缘设备上的独立部署结束。 每个场景都需要不同的 ML 模型生命周期，这些生命周期可以由多个阶段组成，例如数据收集； 数据准备； 模型构建、编译和部署到边缘设备； 模型加载和运行； 并重复生命周期。

ML@Edge 机制不对应用程序生命周期负责。 为此应采用不同的方法。 将 ML 模型生命周期和应用程序生命周期解耦，让您可以自由和灵活地以不同的速度不断发展它们。 想象一个将 ML 模型嵌入为图像或 XML 文件等资源的移动应用程序。 在这种情况下，每次你训练一个新模型并想将它部署到手机上时，你都需要重新部署整个应用程序。 这会耗费时间和金钱，并且会给您的应用程序带来错误。 通过解耦 ML 模型生命周期，您可以一次性发布移动应用程序并根据需要部署尽可能多的 ML 模型版本。

但物联网与 ML@Edge 有何关联？ 物联网涉及嵌入传感器、处理能力和软件等技术的物理对象。 这些对象通过互联网或其他通信网络连接到其他设备和系统，以交换数据。 下图说明了这种架构。 这个概念最初是在考虑从边缘收集数据、执行简单本地处理并将结果发送到更强大的计算统一体的简单设备时创建的，该计算统一体运行分析流程，帮助人们和公司做出决策。 物联网解决方案负责控制边缘应用程序生命周期。 有关物联网的更多信息，请参阅 物联网.

如果你已经有物联网应用，可以添加ML@Edge能力，让产品更高效，如下图所示。 请记住，ML@Edge 不依赖于 IoT，但您可以将它们组合起来以创建更强大的解决方案。 当您这样做时，您可以提高简单设备的潜力，从而更快地为您的业务生成实时洞察，而不仅仅是将数据发送到云以供以后处理。

如果您要使用 ML@Edge 功能从头开始创建新的边缘解决方案，那么设计一个支持应用程序和 ML 模型生命周期的灵活架构非常重要。 我们将在本文后面使用 ML@Edge 为边缘应用程序提供一些参考架构。 但首先，让我们更深入地研究边缘计算，并了解如何根据环境的限制为您的解决方案选择正确的边缘设备。

边缘计算

根据设备与云或大数据中心（基础）的距离，需要考虑边缘设备的三个主要特性以最大限度地提高系统的性能和寿命：计算和存储容量、连接性和功耗。 下图显示了三组边缘设备，它们结合了这些特性的不同规格，具体取决于它们与基地的距离。

各组如下：

• MEC（多接入边缘计算） – 以低或超低延迟和高带宽为特征的 MEC 或小型数据中心是常见的环境，与云工作负载相比，ML@Edge 可以在没有太大限制的情况下带来好处。 工厂、仓库、实验室等的 5G 天线和服务器具有最小的能量限制和良好的互联网连接，提供了在 GPU 和 CPU、虚拟机、容器和裸机服务器上运行 ML 模型的不同方式。
• 近边缘 – 这是当移动性或数据聚合成为要求时，设备在功耗和处理能力方面有一些限制，但仍具有一些可靠的连接，尽管延迟更高，吞吐量有限并且比“靠近边缘”更昂贵。 该组包括移动应用程序、加速 ML 模型的特定板或能够运行 ML 模型的简单设备，由无线网络覆盖。
• 远缘 – 在这种极端情况下，边缘设备具有严重的功耗或连接限制。 因此，在许多远边缘场景中，处理能力也受到限制。 农业、采矿、监控和安全以及海上运输是远边缘设备发挥重要作用的一些领域。 通常没有 GPU 或其他 AI 加速器的简单电路板很常见。 它们旨在加载和运行简单的 ML 模型，将预测保存在本地数据库中，并休眠到下一个预测周期。 需要处理实时数据的设备可以有大的本地存储，以避免丢失数据。

挑战

ML@Edge 场景很常见，您有数百或数千（甚至数百万）设备运行相同的模型和边缘应用程序。 当您扩展系统时，拥有一个能够管理您需要支持的设备数量的强大解决方案非常重要。 这是一项复杂的任务，对于这些场景，您需要提出许多问题：

• 如何在边缘设备上运行 ML 模型？
• 如何构建、优化机器学习模型并将其部署到多个边缘设备？
• 在边缘部署和运行模型时如何保护模型？
• 如果需要，我如何监控模型的性能并重新训练它？
• 如何消除在受限设备上安装 TensorFlow 或 PyTorch 等大型框架的需要？
• 如何将一个或多个模型与我的边缘应用程序公开为一个简单的 API？
• 如何使用边缘设备捕获的有效负载和预测创建新数据集？
• 我如何自动完成所有这些任务（MLOps 加上 ML@Edge）？

在下一节中，我们将通过示例用例和参考架构为所有这些问题提供答案。 我们还讨论了您可以结合哪些 AWS 服务来为每个探索的场景构建完整的解决方案。 但是，如果您想从一个非常简单的流程开始，描述如何使用 AWS 提供的一些服务来创建您的 ML@Edge 解决方案，这是一个示例：

使用 SageMaker，您可以轻松准备数据集并构建部署到边缘设备的 ML 模型。 和 亚马逊SageMaker Neo，您可以针对您选择的特定边缘设备编译和优化您训练的模型。 编译模型后，您只需要一个轻量级的运行时即可运行它（由服务提供）。 亚马逊SageMaker Edge Manager 负责管理部署到边缘设备队列的所有 ML 模型的生命周期。 Edge Manager 可以管理多达数百万台设备的队列。 安装在每个边缘设备上的代理将部署的 ML 模型作为 API 公开给应用程序。 该代理还负责收集指标、有效负载和预测，您可以使用它们来监控或构建新数据集，以便在需要时重新训练模型。 最后，与 Amazon SageMaker管道，您可以创建一个自动化管道，其中包含构建、优化和部署 ML 模型到您的设备组所需的所有步骤。 然后可以通过您定义的简单事件触发此自动化管道，无需人工干预。

用例1

假设一家飞机制造商想要检测和跟踪生产机库中的零件和工具。 为了提高生产力，所有必需的零件和正确的工具都需要在生产的每个阶段供工程师使用。 我们希望能够回答以下问题：A 部分在哪里？ 或工具 B 在哪里？ 我们已经安装了多个 IP 摄像机并连接到本地网络。 这些摄像机覆盖了整个机库，可以通过网络传输实时高清视频。

AWS全景图 非常适合这种情况。 AWS Panorama 提供 ML 设备和托管服务，使您能够将计算机视觉 (CV) 添加到现有的 IP 摄像头队列并实现自动化。 AWS Panorama 使您能够将 CV 添加到现有的 Internet 协议 (IP) 摄像头，并自动执行传统上需要人工检查和监控的任务。

在以下参考架构中，我们展示了在 AWS Panorama 设备上运行的应用程序的主要组件。 Panorama 应用程序 SDK 可以轻松地从摄像头流中捕获视频，使用多个 ML 模型的管道执行推理，并使用在容器内运行的 Python 代码处理结果。 您可以从任何流行的 ML 库（例如 TensorFlow、PyTorch 或 TensorRT）运行模型。 模型的结果可以与局域网上的业务系统集成，让您能够实时响应事件。

该解决方案包括以下步骤：

1. 将 AWS Panorama 设备连接并配置到同一本地网络。
2. 训练 ML 模型（对象检测）以识别每一帧中的部件和工具。
3. 构建一个 AWS 全景应用程序，该应用程序从 ML 模型中获取预测，将跟踪机制应用于每个对象，并将结果发送到实时数据库。
4. 操作员可以向数据库发送查询以定位零件和工具。

用例2

对于我们的下一个用例，假设我们正在为能够在许多情况下支持驾驶员的车辆创建一个行车记录仪，例如避开行人，基于 Ambaralla的CV25板. 在系统资源有限的设备上托管 ML 模型可能很困难。 在这种情况下，假设我们已经拥有完善的无线 (OTA) 交付机制，可以将所需的应用程序组件部署到边缘设备上。 但是，我们仍然可以从模型本身的 OTA 部署中受益，从而隔离应用程序生命周期和模型生命周期。

亚马逊SageMaker Edge Manager 和 亚马逊SageMaker Neo 非常适合这个用例。

Edge Manager 使 ML 边缘开发人员可以轻松地在云端或边缘设备上使用相同的熟悉工具。 它减少了将模型投入生产所需的时间和精力，同时允许您持续监控和改进整个设备组的模型质量。 SageMaker Edge 包含一个 OTA 部署机制，可帮助您在队列上部署模型，独立于应用程序或设备固件。 这 边缘管理器代理 允许您在同一设备上运行多个模型。 该代理根据您控制的逻辑（例如间隔）收集预测数据，并将其上传到云中，以便您可以随着时间的推移定期重新训练您的模型。 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 物联网 Greengrass V2 与 Edge Manager 一起非常适合此用例。 AWS IoT Greengrass 是一种开源 IoT 边缘运行时和云服务，可帮助您在设备上构建、部署和管理 IoT 应用程序。 您可以使用 AWS IoT Greengrass 使用预构建的软件模块构建边缘应用程序，称为 组件，可以将您的边缘设备连接到 AWS 服务或第三方服务。 AWS IoT Greengrass 的这种能力可以轻松地将资产部署到设备，包括 SageMaker Edge 代理。 AWS IoT Greengrass 负责管理应用程序生命周期，而 Edge Manager 将 ML 模型生命周期解耦。 这使您可以灵活地通过独立部署新版本的边缘应用程序和 ML 模型来不断发展整个解决方案。 下图说明了这种架构。

该解决方案包括以下步骤：

1. 开发人员构建、训练、验证和创建需要部署到风力涡轮机的最终模型工件。
2. 调用 Neo 来编译训练好的模型。
3. 使用带有 AWS IoT Greengrass V2 集成的 Edge Manager 创建模型组件。
4. 设置 AWS IoT Greengrass V2。
5. 使用 AWS IoT Greengrass V2 创建推理组件。
6. 边缘应用程序与 SageMaker Edge 代理交互以进行推理。
7. 可以配置代理（如果需要）从应用程序发送实时样本输入数据，以用于模型监控和优化目的。

用例4

对于我们的最终用例，让我们看看一艘运输集装箱的船只，其中每个集装箱都有几个传感器，并将信号传输到本地部署的计算和存储基础设施。 挑战在于我们想知道每个容器的内容物，以及基于每个容器内的温度、湿度和气体的货物状况。 我们还想跟踪每个集装箱中的所有货物。 整个航程没有互联网连接，航程可能需要数月时间。 在这个基础设施上运行的机器学习模型应该预处理数据并生成信息来回答我们所有的问题。 生成的数据需要在本地存储数月。 边缘应用程序将所有推论存储在本地数据库中，然后在船只接近港口时将结果与云端同步。

AWS 雪锥 和 AWS 雪球 来自 AWS 雪系列 非常适合这个用例。

AWS Snowcone 是一款小巧、坚固且安全的边缘计算和数据迁移设备。 Snowcone 是按照 OSHA 标准设计的单人可升降设备。 Snowcone 使您能够使用以下方式运行边缘工作负载 亚马逊弹性计算云 (Amazon EC2) 计算和本地存储在恶劣的、断开连接的现场环境中，例如石油钻井平台、搜索和救援车辆、军事场所或工厂车间，以及远程办公室、医院和电影院。

与 Snowcone 相比，Snowball 增加了更多计算，因此可能非常适合要求更高的应用程序。 计算优化功能提供可选的 NVIDIA Tesla V100 GPU 以及 EC2 实例，以加速应用程序在断开连接的环境中的性能。 借助 GPU 选项，您可以在连接很少或没有连接的环境中运行高级 ML 和全动态视频分析等应用程序。

在 EC2 实例之上，您可以自由构建和部署任何类型的边缘解决方案。 例如：您可以使用 亚马逊ECS 或其他容器管理器将边缘应用程序、边缘管理器代理和 ML 模型部署为单独的容器。 该架构类似于用例 2（除了它大部分时间将离线工作），并添加了一个容器管理器工具。

下图说明了此解决方案架构。

要实施此解决方案，只需从 AWS管理控制台 并启动您的资源。

结论

在这篇文章中，我们讨论了您可以根据您的用例选择使用的边缘的不同方面。 我们还讨论了围绕 ML@Edge 的一些关键概念，以及如何将应用程序生命周期和 ML 模型生命周期解耦，让您可以自由地发展它们，而无需相互依赖。 我们强调了如何为您的工作负载选择正确的边缘设备并在解决方案过程中提出正确的问题可以帮助您向后工作并缩小正确的 AWS 服务范围。 我们还展示了不同的用例以及参考架构，以激发您创建适合您工作负载的自己的解决方案。

---

作者简介

迪内什·库马尔·苏布拉马尼 是位于苏格兰爱丁堡的 UKIR SMB 团队的高级解决方案架构师。 他专攻人工智能和机器学习。 Dinesh 喜欢与各行各业的客户合作，帮助他们解决使用 AWS 服务的问题。 工作之余，他喜欢与家人共度时光、下棋和欣赏各种流派的音乐。

萨米尔·阿劳霍（SamirAraújo） 是AWS的AI / ML解决方案架构师。 他帮助客户创建AI / ML解决方案，以使用AWS解决其业务挑战。 他一直从事与计算机视觉，自然语言处理，预测，边缘ML等有关的多个AI / ML项目。 他喜欢在业余时间玩硬件和自动化项目，并且对机器人技术特别感兴趣。

• 硬币聪明。 欧洲最好的比特币和加密货币交易所。
• 柏拉图区块链。 Web3 元宇宙智能。 知识放大。 自由登入。
• 加密鹰。 山寨币雷达。 免费试用。
• 资料来源：https://aws.amazon.com/blogs/machine-learning/demystifying-machine-learning-at-the-edge-through-real-use-cases/