小叽导读：在 AI 领域，芯片如果没有足够的计算能力，就无法支撑无人驾驶、可穿戴设备的实际落地。本文介绍了ACE（AILabs Compute Engine），一个边缘端的异构计算引擎。它支持端云一体的模型管理，支持 GPU、DSP 和 VPU 等异构加速芯片，引入了 Google UINT8量化方案、FaceBook QNNPACK 加速库等最新的技术。在自研硬件上，和芯片厂商深度合作针对中低端芯片做出了特例优化，落地了手势识别、宠物检测和笔尖检测等业务。
一、背景
1.1 无芯片不 AI
人工智能产业得以快速发展，无论是算法的实现、海量数据的获取和存储还是计算能力的体现都离不开目前唯一的物理基础——芯片，是否有符合市场业务需求的 AI 芯片是至关重要的。
针对目标应用是“训练”还是“推断”，是在“云端”还是“终端”，可以把 AI 芯片分为四个象限，如上图所示。
云端训练：深度神经网络大多在云端完成训练，针对这一市场，NVIDIA 系列GPU芯片是使用最广泛的。
云端推理：与模型训练不同，很多公司都针对云端推理这一场景推出了专用芯片，包括 google 的 TPU 芯片、英特尔的 Nervana 系列芯片和寒武纪的MLU100 芯片等，平头哥准备今年推出的第一款 AI 芯片 Ali-NPU 就是用于云端推理的。
边缘端推理：与云端相比，边缘端目前主要以推理为主，将 AI 算力注入边缘，赋能边缘智能是大势所趋，越来越多的 AI 应用开始在边缘设备上开发和部署。
边缘端训练：同时，随着 google 提出 Federated Learning (FL) 和推出首个商用级边缘端分布式机器学习系统，在边缘和嵌入式设备上进行学习训练也变得越来越重要。与云端的训练相比，在边缘设备上进行训练有着保护用户隐私和提供更加个性化服务的巨大优势，让模型更聪明，让用户最快速地体验到更新后的模型。
1.2 为什么一定要边缘计算？
因为边缘计算（Edge computing）有延迟低、节省带宽、离线可用和保护隐私等特点，有很多应用更适合在边缘设备上进行推理，智能将会下沉到终端设备，智能边缘计算将会崛起。比如，视频监控任务，几百万高清摄像头的数据完全由云端来处理会对网络造成巨大的压力，再比如无人驾驶的推理则更不能由云端来运行，否则如果网络出现问题，很可能会出现灾难性的后果。
1.3 为什么自研算法引擎？
边缘设备也远远不止是摄像头和手机，从对计算力有极大需求的无人驾驶到多传感器融合的送餐机器人，再到对功耗和成本比较敏感的可穿戴设备等，其应用场景五花八门。在目前的 AI 应用场景中，边缘设备主要执行推理计算，这就要求边缘设备的芯片有足够的计算能力。但是，目前边缘处理器芯片的计算能力比较有限，更好的利用这有限的计算能力，屏蔽底层的硬件细节，快速把业务落地就是作为引擎的责任。
ACE(AI Labs Compute Engine) 就是我们端云一体化中，在边缘设备端的支持CPU、GPU、DSP 和专用 AI 芯片等异构计算方式的计算引擎。我们针对自研硬件，从主芯片和数据处理芯片的选型开始，与芯片厂商深度合作，从驱动层到 HAL 层到系统层，进行深度定制优化，打造针对专有自研硬件的算法引擎，支撑上层业务更好的运行。
以天猫精灵为例子，我们和算法同学深度合作，针对我们采用的某款低端芯片结合实际业务进行了定制化优化，通过 ACE 成功落地了像手势识别这一类对实时计算力要求比较高的算法。
二、架构总览
计算引擎 ：
计算层：采用了模型量化、异构计算、内存友好和汇编优化等手段进行算法加速；
接入层：以计算图的方式编排算法业务，并提供常用的算子，缩短开发周期。
模型管理：
云端：对接 AutoAI 平台，生成移动端模型；
边缘端：接收云端的指令、主动推送信息。
三、计算引擎
3.1 计算层
人工智能不是只能存在于昂贵的企业服务中，我们还要把 AI 的快乐带到千家万户，注入到像智能电视、物联网和智能音箱等众多智能设备当中，让更多用户体验到 AI 所带来的改变。因为这些终端智能设备的计算能力普遍有限，所以我们采用了模型量化、异构计算、内存友好和汇编优化等手段对算法进行加速。
■ 模型量化
在我们最初把手势算法落地到采用某低端算力芯片的产品上时，用于云端的检测模型是 float32 的模型，有几百毫秒的耗时，经过算法同学的裁剪优化，该模型 CPU 单核心耗时降低到了130ms，但距离20帧/S的理想速度还有一定的差距。
我们采取模型量化的方式进行进一步的加速，量化后的定点计算比浮点计算要节省计算资源和内存，然后我们对量化后的推理过程做了深度的优化。
量化后，单核心耗时降低为59ms，检测帧率能够达到17帧/S，其速度已经超过4核心 float32 的模型了。
为了取得更好的量化加速效果，我们采用了内存友好和汇编优化等常规手段进行加速，并引入了 QNNPACK 加速库。该库是专门为模型量化加速设计的，采用和 TFLite 相同的量化原理。最终，我们将手势模型单核心耗时缩短到了41ms，总计取得了3.17倍的加速效果，节省了74%的模型内存。
以标准 mobilenet_v2_1.0_224 模型为例，单核心量化加速效果能达到2.2倍。
针对多线程场景，我们还提高了 kernel 的并行程度，两核心加速效果在3倍左右。
■ 异构加速
因为 CPU 上还运行着很多其他业务，所以能用来计算的 CPU 资源相对空缺，而且通用处理器 CPU 性能再无法按照摩尔定律进行增长。与此相对，数据增长对计算性能的要求却超过了按“摩尔定律”增长的速度，算力需求和实际性能之间出现了巨大的缺口，一种主流的解决方案就是异构计算。
与追求普适性的通用计算不同，专用计算，就是对一些特定场合进行优化，性能/功耗等指标通常比通用 CPU 有数量级的提高，但是应用场景有限。通用和专用的关系就如同什么都懂一些但是基本上什么都不精的“通才”，和在个别领域钻研极深但是其他领域几乎一无所知的“偏才”。而异构计算一般就是 CPU+专用设备（GPU、DSP、VPU和FPGA等）这些使用不同类型指令集、不同的体系架构的计算单元，组成的一个混合的系统，进行协同计算。
以某款芯片上的业务为例，大量的业务在使用 CPU 而 GPU 相对空闲。这个时候，在 CPU 上运行笔尖检测算法时，4线程耗时260ms，CPU 消耗超过240%，对其它业务造成了较大的影响。而采用 CPU+GPU 异构计算的方式，耗时为150ms，CPU的消耗从245%降低到了50%，更好的使用了整体资源。
在该芯片上，异构计算资源除了 GPU 之外，还有定点运算加速器 VPU，把笔尖检测模型量化之后就可以使用 VPU 进行加速。量化版的笔尖检测模型使用4个 CPU 线程进行计算时，耗时约76ms，比起 float32的260ms有着极大的提升，但是吃掉了所有的 CPU 的计算资源，导致其它业务不能正常运行。而使用 CPU+VPU 异构计算的方式，耗时仅为51ms，且节省了大部分 CPU 资源，并降低了整体的功耗。
3.2 接入层
接入层的作用是简化算法开发流程，提高调试和维护的效率，最终实现业务的快速落地，我们主要通过以下几种手段来达到这个目的：
对接 AutoAI 一站式解决方案，打通模型训练、计算图构建、模型管理整个流程；
联合算法团队开发常用的 High Level & Low Level 算子，打造模块化的算子库；
API/UI 简化计算图的构建，支持将计算图、模型、配置等资源打包为单个文件，降低管理难度；
支持深度学习、传统算法混合的图计算，减少工程代码开发量，并提供性能分析、问题定位、算法评估等功能，降低调试难度，加快业务落地速度 。
四、模型管理
模型管理是 ACE 的一个重要功能，它由云端和边缘端两部分组成，能够灵活地对模型和业务两个维度进行管理。原来，边缘端必须通过系统软件升级的方式来更新模型，这就意味着新模型的上线发布和灰度测试都需要随着软件升级的节奏走。但有时候我们想小范围快速地灰度测试新模型，这个时候就需要模型管理系统来支持这个功能。
4.1 云端模型管理
模型管理系统准确地说是一个管理边缘端上各个算法模型的云端后台系统，其核心在云端。云端模型管理系统结构如上图所示，后台界面上可以操作服务端对端上进行控制，目前支持对端上的操作有：
查询（Query）：查询某台设备上的模型详细信息；
下载（Download）：将某个模型下载到端上；
重载（Reload）：切换端上的某个模型/业务；
重置（Reset）：将端上模型重置为初始状态（仅在紧急情况下使用）。
4.2 边缘端模型管理
一般来说，模型管理是仅基于模型维度的管理，即模型与模型之间没有耦合。但在某些情况下，这是不合理的，我们以视频内的宠物检测和手势为例来说明模型耦合的情况。
如上图所示，为了节省端上的存储空间以及计算量，宠物和手势两个业务共用了一个模型，因此，仅仅依靠基于模型的单纬度的管理已经不能满足需求。
为了解决这个问题，我们在模型维度的基础上增加了业务维度。业务是在模型之上的一个抽象，业务与模型是多对多的关系，且业务之间可能会共享同一个模型，这样就很好地解决了耦合问题。
五、展望未来
ACE 的使命是使算法能快速准确地落地到天猫精灵和机器人等自研边缘设备上，良好的支撑相关的上层业务。虽然目前还有很多的不足，但是我们会在后续的开发过程中继续完善其易用性，做好底层的优化加速，并与厂商更加深度的合作，做到软硬件结合，合理的利用端上有限的计算资源。
参考文献：
[1]https://arxiv.org/abs/1712.05877 [2]http://speak.clsp.jhu.edu/uploads/publications/papers/1048_pdf.pdf
[3]https://code.fb.com/ml-applications/qnnpack/ [4]https://arxiv.org/pdf/1902.01046.pdf [5]https://arxiv.org/abs/1603.05279 [6]https://cloud.tsinghua.edu.cn/f/a0785cec353a4cd18d7d/ [7]https://www.leiphone.com/news/201809/ICs9ETzP7gPDEAkJ.html
