使用模型工件在边缘进行机器学习计算

在资源受限且依赖电池的设备（如手机、个人计算机、嵌入式处理器）上执行计算密集型任务是一项具有挑战性的任务，尤其是当人们打算运行机器学习模型时，因为这些模型占用了大量内存和 GPU，而这些模型无法满足这些需求.对于这些计算密集型任务，企业和开发人员在很大程度上依赖于各种云提供商，例如亚马逊网络服务、微软 Azure、谷歌云等等，因为他们将从现场生成的数据重定向到位于云内部的模型，从而被过滤，处理并将结果再次传送回设备。但这是以面临具有挑战性的问题为代价的，例如：

• 潜伏
• 冗余
• 间歇性网络连接

潜伏
它被定义为数据到达云端、处理然后返回到之前生成的位置所需的时间。延迟是一个关键问题，需要快速做出决定并做出相应的响应。防御设备监控、联网车辆、旋风监控等场景容易出现延迟问题。
冗余
到 2025 年，估计将有超过 750 亿台设备连接到互联网，冗余发挥着毁灭性的作用，如果不直接在边缘过滤，就会在云中留下不必要的数据，从而增加互联网成本。
间歇性网络连接
在偏远的地方，互联网几乎不可用，或者如果可用，它是断断续续的，因此使设备无法正常运行。这三个因素的存在为引入“边缘计算”或“边缘计算”的概念铺平了道路。这让我们要问两个问题：

1) 如何在边缘执行 ML 计算？
2）是否有任何云提供商提供此服务来尝试和做项目？

为了回答第一个问题，可以使用“模型工件”来执行 ML 计算，我们将通过一个真实世界的例子来探索它。对于第二个问题，目前有 3 家云提供商提供此服务，即 AWS IoT Greengrass、Google Cloud IoT 和 Microsoft Azure Edge IoT。人们可以尝试任何这些可用的服务来弄脏自己的手！现在，让我们通过考虑使用 AWS IoT Greengrass 和 Amazon Sagemaker 的“监控防御设备”这个涉及延迟、冗余和间歇性连接问题的现实生活场景来了解边缘和模型工件的 ML 计算的概念。

AWS Greengrass IoT 需要两台设备
1) Greengrass Core，在 rasbian OS、Ubuntu 上运行，还支持 arm x86 处理器。
2) Greengrass 感知设备，例如在 AWS FreeRTOS SDK 上运行的微控制器。

流程图

• 该图显示了实施 AWS IoT Greengrass 的一般架构，其中节点“A”和“B”充当监控设备（Greengrass Aware 设备），节点“C”作为 Greengrass 核心。
• 监控站点的硬件是一个微控制器/微处理器，带有传感器，用于监控有关设备状态的实时数据。微控制器/微处理器必须需要与Greengrass核心形成本地网络的通信设备，从而将测量信息与核心进行通信。
• 除了硬件实现之外，在 greengrass 核心设备上，必须运行预先训练的模型工件和本地 lambda 函数，以在来自监控设备的数据到达时在边缘做出决策，而不依赖于云，如下图所示.

  拟议模型的架构

  

• 模型工件是通过在 amazon sagemaker notebook 实例中将数据集训练为所选算法而生成的。一般来说，模型工件由给定数据集上训练模型的权重组成，大小为几兆字节到千兆字节。因此，一旦将这些工件部署到 greengrass 核心（资源受限设备），就好像它们正在处理云内部的信息一样。
• 下图展示了整个系统的架构。

  

该架构概述了从一个服务到另一个服务的后台流程。

• 在防御环境中，本地设备充当greengrass 感知设备，与greengrass 核心设备组成本地网络，该设备由本地lambda 和模型工件组成。
• 在图片的右侧面板上，我们可以看到所有涉及的 AWS 服务。数据集存储在 S3 存储桶中，然后传输到 sagemaker 以训练模型，一旦完成，模型工件就会存储在 S3 存储桶中。
• 这些工件与 lambda 一起附加到 greengrass 核心，并使其部署在防御环境中。来自环境的数据会定期存储在 dynamodb 中，国防用户/技术人员可以访问这些数据以通过 Web 应用程序检查任何错误。
• 通过提供凭据访问此 Web 应用程序，并将这些凭据重定向到 amazon cognito。 Amazon congnito 检查凭证并决定是否从 dynamodb 访问数据。防御环境和 AWS IoT 核心之间的通信可以通过带有适当 x.509 证书的 MQTT 协议完成，如图所示。

总而言之，当打算在边缘进行计算时，应用程序不受限制。本文概述了通过将防御架构与您的预期工作相关联来品尝边缘计算风味的基本要求。