Astraea:以优雅的方式在EDGE部署AI服务
一、引言
近年来,边缘计算已成为信息与通信技术领域最热门的研究方向之一。随着5G时代的到来,越来越多的设备连接到互联网,并伴随着带宽消耗大、延迟敏感的应用,如直播视频、云游戏、VR/AR、自动驾驶等,这给中心云数据中心带来了巨大挑战。与云计算不同,边缘计算实现了将计算和数据资源卸载到靠近终端用户的边缘节点的分布式计算范式,从而为这一新时代的创新应用提供了广覆盖、低连接延迟和带宽效率的能力。
从各省/市的本地互联网数据中心(IDC)等大型网络节点,到网关等微型网络节点,除中心云数据中心以外的所有节点,广义上均可定义为边缘节点。多接入边缘计算(MEC)使云计算的部分能力延伸至蜂窝网络边缘,在5G网络技术中发挥着关键作用。许多应用将通过边缘计算受益于通信技术演进。
内容分发网络(CDN)是边缘计算最典型的应用,利用边缘节点实现互联网内容的快速分发。近年来,越来越多的云计算供应商利用边缘节点提供更广泛的通用计算服务。2017年,亚马逊网络服务(AWS)推出了 Lambda@edge[1],作为其CloudFront产品的一项功能,使应用程序能够在靠近用户的地方运行,以提升性能并降低延迟。同年,阿里云推出了边缘节点服务(ENS)[2],旨在提供弹性且安全的虚拟机和容器,满足应用对边缘计算资源的需求。
随着机器学习(ML)和深度学习(DL)的发展,人工智能(AI)已成功应用于计算机视觉(CV)、自然语言处理(NLP)、机器人学等多个领域。神经网络正变得越来越深且复杂,因此需要巨大的计算资源,导致在移动设备上进行大多数AI训练甚至推理都十分困难。传统解决方法是将计算任务迁移到云上。然而,将数据从终端设备传输到中心化云数据中心所带来的长传播延迟和高带宽消耗限制了其大规模部署。新兴的边缘计算范式提供了一种更好的解决方案,通过将AI服务的部分计算迁移到EDGE,缓解延迟和带宽瓶颈。
此外,AI模型的开发者和数据科学家通常不了解或不太关心他们的模型在生产环境中如何被服务部署。本文中,我们提出了Astraea,一种面向边缘计算场景的新型AI服务部署平台,该平台简化了部署过程,同时充分利用了边缘计算的优势。AI服务开发者只需提交其模型、相关调用脚本以及边缘资源需求,Astraea将接管镜像构建、资源分配、模型服务和监控的整个流程,并最终为终端设备提供标准的RESTful API以供使用。
本文做出了以下贡献。首先,我们分析了边缘计算中的计算卸载问题。其次,我们提出了一种名为 Astraea的平台,用于以简单而优雅的方式在EDGE部署AI服务。最后,我们使用Astraea实现了一个实时物体识别服务,并评估了边缘计算范式带来的性能提升。
II. 动机
A. 计算卸载与协作
在边缘计算中,计算任务可以从终端设备迁移到边缘服务器以利用其强大的处理能力,或从远程中心云数据中心迁移到边缘节点以降低网络延迟。通常需要决策是否迁移、迁移什么以及如何迁移计算任务。设Pd为终端设备的处理能力,Pe为边缘服务器的处理能力,Pc为云服务器的处理能力,C为计算任务量,D为需要传输的数据,Be为终端设备与边缘节点之间的带宽,Bc为中心云数据中心与终端设备之间的带宽。
当公式(1)存在时,将计算从终端设备迁移到边缘服务器可以减少响应时间,从而提高性能。
$$
\frac{C}{P_d} > \frac{C}{P_e} + \frac{D}{B_e}
$$
当公式(2)成立时,将计算迁移到边缘服务器比迁移到中心云数据中心更具优势,因为即使云数据中心的计算能力是无限的,数据从终端设备传输到远程中心云数据中心的时间 $\frac{D}{B_c}$ 也通常长于传输到边缘节点的时间 $\frac{D}{B_e}$。
$$
\frac{C}{P_c} + \frac{D}{B_c} > \frac{C}{P_e} + \frac{D}{B_e}
$$
对于机器学习任务,随着模型变得越来越复杂,计算量C也越来越大。同时,边缘计算由于在靠近数据源的位置进行处理,相比远程云数据中心减少了数据传输时间 $\frac{D}{B}$。因此,如果一个AI服务满足公式(1)和公式(2),则可以将其卸载到边缘节点,在响应时间和带宽效率方面获得性能提升。类似地,通过将计算迁移到边缘,也可以节省计算能耗。
B. 机器学习模型服务
目前,许多模型开发者或数据科学家更倾向于专注于模型构建,而忽略模型服务、数据注入、监控、运维、维护等其他环节。另一方面,边缘计算平台为应用所有者提供了虚拟机、容器或无服务器框架等通用计算资源,以部署其服务。因此,存在一个鸿沟:模型开发者通常缺乏便捷的方法将其模型部署到边缘计算平台。
有多种传统方式可将机器学习模型作为应用程序编程接口(API)在生产环境中。一种方法是使用一些Web框架来封装模型,例如Python中的Flask、Django,Java中的Spring、Tomcat,以及其他编程语言的许多其他框架。这里的问题在于模型开发者在利用和优化AI服务的计算卸载方面面临模型服务的困难。在边缘计算范式下,我们需要一个新型的AI服务部署平台,使模型开发者能够方便且优雅地进行模型的服务部署、监控、测试和维护。
III. 设计与架构
A. 概述
为了帮助模型开发者在边缘端部署其模型,我们提出了Astraea,一个边缘AI部署平台,可自动将原始模型转换为边缘计算容器镜像,并通过API提供 RESTful服务。图1展示了Astraea的总体架构。模型开发者只需提交预训练AI模型及一些依赖文件,Astraea便会将AI服务部署在边缘基础设施上,并为终端用户提供RESTful API。
Astraea的工作流程如图2所示。第一个必需的文件是模型,无论其依赖于哪种机器学习框架。第二个必需的文件(e.g. inference.py)是一个Python脚本,用于说明如何调用模型以及返回的输出数据格式。第三个必需的文件(e.g. deploy.yaml)包含AI服务的元信息(名称、版本、API端口等)以及对边缘计算资源的需求,包括中央处理器、GPU、内存大小以及AI服务希望覆盖的地理区域。此外,如果模板缺少某些运维操作(例如从远程服务器下载必要文件),还可以向Astraea提交一些可选脚本。更多细节将在第三节-B小节、第三节-C和第三节-D中进行说明。
B. AI模型封装器
Astraea 支持多种机器学习框架,包括 TensorFlow、PyTorch、ONNX、scikit-learn 以及其他框架。模型的调用方法定义在一个 Python 脚本中,该脚本必须包含一个 Python 类和两个方法:init 和 predict。init 方法用于指定模型如何加载,并声明在模型推理过程中将使用的局部变量。predict 方法决定模型如何根据输入数据生成输出结果。下面的示例I展示了一个使用 ONNX 实现的花卉分类的 Python 推理脚本。
示例I. 一个使用ONNX推理示例对花卉进行分类
class FlowerClassifier(object):
def __init__(self):
self.labels = ["setosa", "versicolor", "virginica"]
filename = 'xgboost.onnx'
self.sess = rt.InferenceSession(filename)
def predict(self, x_array, features_names):
name = self.sess.get_inputs()[0].name
data = np.array(x_array, dtype=np.float32)
label_id = self.sess.run([], {name: data})[0][0]
return self.labels[label_id]
C. 自动RESTful化与容器化
Astraea 的另一个重要部分是使封装的模型暴露一个 RESTful API,并将所有组件构建成可部署的容器镜像。Astraea 的一个模块称为 astraea-core,这是一个负责模型自动RESTful化和容器化的 Python 包。以第三节-B小节中的花卉分类为例,步骤如下:
步骤 1 :astraea-core生成一个 Dockerfile,该文件将在 docker 构建阶段安装所有依赖的 Python 和 Linux 包。这些依赖项会从 Python 脚本和可选脚本中自动扫描得出。
步骤2 :在Dockerfile末尾,astraea-core将基于Flask启动一个 Web服务,读取推理Python脚本,并首先运行init方法以加载模型。然后,astraea-core通过重定向Flask的推理请求来提供predict方法的服务,并返回JSON格式的响应。此外,astraea-core还会记录包括总次数、每秒查询数、平均响应时间等在内的预测监控数据,如总次数、每秒查询数、平均响应时间,等等。
步骤 3 :astraea-core将 Dockerfile 中的所有组件构建成一个 Docker 镜像,然后将其上传到边缘容器镜像仓库。该边缘容器镜像仓库采用点对点技术,以加速镜像在各个边缘节点之间的分发。
D. 在边缘部署
下一步是在边缘节点上部署已封装、RESTful化并容器化的 AI 模型。Astraea-edge 是 Astraea 的另一个组件,它解析demand.yaml文件并相应地分配边缘资源,然后通过边缘容器平台管理每个边缘节点上容器的整个生命周期。在示例II中,astraea-edge 将在中国上海的边缘节点上创建并运行三个服务实例,在中国成都的边缘节点上创建并运行两个服务实例。花卉分类模型由 Astraea 提供服务,RESTful AI 服务的 URL 或 IP地址 将被返回。监控API 也在端口5050提供,用于显示服务调用数量、平均响应时间等信息。终端设备可通过端口5000调用这些 Web 服务以获取推理结果。
示例II. 边缘资源需求示例文件
-name: onnx-flower-classifier
predictor:
path: FlowerClassifier.py
model_name: FlowerClassifier
predict_port: 5000
monitor_port: 5050
tags:
- "onnx-flower-classifier:0.0.1"
resources:
compute:
requests:
cpu: "1"
memory: "128Mi"
region:
- region: cn-chengdu
number: 2
- region: cn-shanghai
number: 3
IV. 评估
A. 实验设置
我们通过在低端设备上实现一个实时物体识别服务来评估Astraea。在实验中,我们选择树莓派4作为终端设备,并使用YOLOv3模型来识别图像或视频中的物体。该模型的权重在云上进行预训练,因为与边缘节点或终端设备相比,中心云数据中心具有更强的模型训练能力。我们的评估选择了一个位于中国杭州并配备特斯拉 V100 GPU的邻近边缘节点。
B. 部署时间
该实验性物体识别服务的部署包含两个主要的耗时步骤:(1)容器镜像构建与上传,以及(2)边缘端镜像分发。在第一步中,Astraea将解析模板文件并相应地构建REST化容器镜像,然后将其上传到边缘容器仓库。接下来,Astraea将拉取该容器镜像,在指定的边缘节点上创建并启动 Web服务。总计部署时间如图3所示。我们可以看到,Astraea能够在不到两分钟的时间内自动将一个AI模型转换为可部署的镜像,并使其在边缘节点上运行。需要注意的是,部署时间与模型和镜像大小相关。如果模型更小或更简单,预计总计部署时间将少于一分钟。
C. 性能提升
为了评估在边缘部署的物体识别服务,我们比较了设备-边缘协同方案与终端设备独立方案之间的识别性能。在第一种方案中,终端设备(树莓派)捕获图像,调用Astraea提供的Web服务API以获取识别结果,最后将结果显示在原始图像上。图4展示了该方案的架构。作为对比,在第二种方案中,终端设备独立完成所有物体识别任务。
在实验中,测试了七张不同分辨率和大小的图像,结果如表I所示。我们可以看到,树莓派上的平均目标识别时间约为20秒,这对于实时目标识别来说非常糟糕且不可行。如果我们使用Astraea在边缘节点上部署目标识别服务,平均推理时间将小于0.1秒。即使加上往返边缘节点的网络传输时间,设备-边缘协同方案也能平均节省98.5%的时间。当目标识别任务中的AI推理部分被卸载到邻近的边缘节点时,终端用户感知到的识别速度比终端设备独立方案快 25×到 110×倍。我们还使用设备-边缘协同方案评估了视频中的实时目标识别,得出结论:与树莓派自身相比,处理帧率达到了50×提升。
| id | 分辨率 | 图像大小 | 方案识别时间(秒) | 提升速度 | 时间节省 | |||
|---|---|---|---|---|---|---|---|---|
| 终端设备独立运行 | 网络传输 | 边缘推理 | 总计 | |||||
| 1 | 768×576 | 164 KB | 20.320 | 0.195 | 0.055 | 0.250 | 81.280 | 98.77% |
| 2 | 773×512 | 142 KB | 20.430 | 0.159 | 0.054 | 0.213 | 95.915 | 98.96% |
| 3 | 500×500 | 383 KB | 20.940 | 0.188 | 0.055 | 0.243 | 86.173 | 98.84% |
| 4 | 773×512 | 133 KB | 20.720 | 0.155 | 0.047 | 0.202 | 102.574 | 99.03% |
| 5 | 640×424 | 114 KB | 21.200 | 0.142 | 0.049 | 0.191 | 110.995 | 99.10% |
| 6 | 352×448 | 175 KB | 20.060 | 0.171 | 0.048 | 0.219 | 91.598 | 98.91% |
| 7 | 1920×1080 | 3.9 MB | 20.630 | 0.669 | 0.131 | 0.800 | 25.788 | 96.12% |
表I:Astraea实现的终端设备独立方案与设备-边缘协同方案的实验结果
V. 相关工作
边缘计算和计算卸载已引起众多研究人员的关注。Shi et al. 提出了边缘计算的愿景与挑战 [3][4]。Li et al. 提出了一种轻量级编程语言以最大化边缘计算中应用的性能[5]。一些研究专注于资源管理与调度[6][7][8][9][10],还有相当数量的论文研究了边缘计算应用,包括视频/云游戏[11][12][13]、车辆[14]和区块链[15][16]。Kang et al 提出了Neurosurgeon,一种云与移动边缘之间的协同智能[17]。Li et al 在设备与边缘之间自适应地划分深度神经网络,以实现低延迟的边缘智能[18]。
已提出多种机器学习模型服务部署方法。Kubeflow [19]是一个开源项目,最初旨在在 Kubernetes上运行TensorFlow任务。随后它扩展为支持整个机器学习管道,包括训练、调优、服务部署,etc。然而,它严重依赖Kubernetes。Cortex [20]是另一个支持自动扩展、竞价实例、日志流和滚动更新的机器学习服务部署平台,但它与AWS OpenAPI深度集成。其他服务部署项目如SageMaker、TensorFlow Serving、TorchServe则要求用户自行构建模型部署平台或仅专注于特定的机器学习框架。与这些工作相比,Astraea支持多种机器学习框架,并专注于边缘计算中的模型服务部署。
VI. 结论
机器学习技术正成为当今智能应用的重要组成部分。随着模型变得越来越深和复杂,终端设备几乎无法支持训练甚至推理阶段,而仅依赖云处理则不可避免地会遇到延迟和带宽瓶颈。边缘计算通过高效的计算卸载和设备-边缘-云协同为这一问题带来了新的解决方案。在本研究中,我们首先分析了边缘计算中的计算卸载与机器学习模型服务,然后提出了Astraea——一个以简单优雅的方式在边缘部署AI服务的平台。最后,我们评估了Astraea的性能,并得出结论:Astraea能够在两分钟内从一个原始AI模型部署出具备RESTful API的通用AI服务。在我们论文中的时间对象识别服务中,与仅使用终端设备的方案相比,性能提升了 25×到 110×。
5085

被折叠的 条评论
为什么被折叠?



