好快省--移动端AI算法部署技术栈

转自我的知乎专栏： https://zhuanlan.zhihu.com/p/143510419 

 

很多团队都在做移动端AI的某个具体的技术点，但部署AI算法的时候和产品线交流，产品一线其实对具体用什么技术并不关心，产品线就希望某个算法能跑得又好又快又省。所以，不局限于某个具体的技术点，本文整理了移动端AI算法部署技术栈。要满足产品苛刻的性能要求，部署时一定是多种技术的综合利用。

 

指标体系

产品要求的又好又快又省，指标化其实就是几类：

1. 效果（好）：

1.1 准：Accuracy

AI算法效果一般用accuracy表示，当然具体的任务还有一些具体的量化指标，但核心理念都是准确率。

效果（accuracy）是算法团队需要解决的核心问题，移动端工程化部署的时候，accuracy不会提高，甚至某些技术还会牺牲一些accuracy，以换取更好的执行效率。

2. 效率（快、省）：

2.1 快：latency

也就是单次AI算法模型运行（inference）的时间。

参见业界推崇的MLperf评测体系，不同任务有不同的指标：Single stream任务，主要用latency，也有用fps（frame per second）的，latency和fps可以直接换算；Offline任务，可以用throughput。

2.2 省（功耗）：energy efficiency

移动端必须要考虑功耗问题。功耗的评测体系有点乱，以前看MLperf，功耗的评测也还是open question。看国内几个有名的AI跑分软件，都没有功耗的跑分。当然，可以理解，功耗是不好测试的。

参考国外的一些评测，功耗可以用 fps/w 或 mah / inference 来衡量。

2.3 省（存储）：memory

现在移动设备（比如，手机）存储越来越大，memory一般来说够用。当然，我们还是应该监控存储的使用情况。

 

除开产品直接的要求外，工程化部署的成本也需要被考虑，比如软件和硬件的成本：

3. 成本（低）

3.1 软件成本：flexibility

移动端已有大量可选的软件框架和算子实现库。低成本的技术需要尽量复用已有的软件框架和库。

3.2 硬件成本

选择新的芯片/计算设备，在性能/能效上肯定会更好，但新计算单元的成本肯定会更高。不过对软件团队来说，一般芯片或能用的计算设备是确定的，硬件资源上没太多选择/决策空间。

 

综上，“好、快、省”的具体要求就是软件平台“高accuracy，低latency，高energy efficiency，低memory size，高flexibility”。当然，没有一个技术能对所有的指标友好，很多技术都是在几个指标间进行平衡。

 

技术栈

对AI算法应用的部署，涉及的模块和其间的关系可如下图：

所以，对支撑AI算法应用“好快省”的“计算软件平台”，在技术上通常可分为自下而上和自上而下两条路径。其中，自下而上的路径，类似传统的高性能计算技术，又可分为单计算单元高性能，和多计算单元协同高性能。所以，“好、快、省”的“计算软件平台”可以有三条路径，每条路径下又有若干相关技术：

自上而下，简化算法，减低计算需求：

1. 算法模型小型化

• 轻量架构
• 通道剪枝（channel pruning）
• 权重稀疏（weight pruning）

自下而上，挖掘硬件能力，提供高性能：

2. 单计算单元高性能

• 选用专用加速芯片
• 编译优化技术
• 低精度运算

3. 多计算单元协同高性能

• 端边云
• 端内多芯
• 芯内多核

我们这里倒叙，从最后一个路径聊起。

多计算单元协同高性能

首先，如何定义多计算单元？ 可以有三层粒度：

1. 端边云计算

这个是随5G/IOT的到来炒得比较火的，不过业界比较头疼的主要是场景问题，现在好像就端云结合的云游戏相对实在些。

2. 端内多芯计算

SOC内有多个芯片，可以有效联动起来。

3. 芯内多核计算

CPU/GPU内多核的并行化，这个是业界比较成熟的技术领域了。不过在更精细化利用多核上，学界还有一些研究，比如，DNN的各个layer对多核的占用率是不同的，有论文也在研究把低并行度layer执行时未有效利用的核心更有效利用起来。

端边云，和端内多芯是新机会较多的多计算单元利用层次。在关键技术上，有共性，但也有不少区别。共性的技术都是利用多单元进行并行化加速，并行化的模式也类似如下图。同时，并行化的关键技术也相同，都是更好的负载均衡以提高并行度，以及，减小并行计算间同步的成本。

来源“2020 IEEE International Solid-State Circuits Conference ”

但考虑到多计算单元通信的延迟/带宽/链路稳定性，端云、端边和端内多芯协同还是区别的。如“Deep Learning With Edge Computing: A Review”，考虑到不可忽视的通信成本，端边协同（端云协同也类似），计算任务的分配（task offloading）可以采用计算完全在edge进行和计算跨端边进行两种模式。而端内多芯间的通信成本很小，端内多芯通常可以跨多个计算单元以充分并行化加速。

另外，还是通信成本的问题， 即便如“MoDNN: Local Distributed Mobile Computing System for Deep Neural Network”能提高跨设备间计算的并行度，但跨设备通信延迟一般在50~100ms，算法模型自身的执行时间至少要在秒级，通信的overhead才能被忽略。然而，秒级运行速度的算法模型在工业界基本没有实用的意义。

所以，个人认为，总体上讲，端内多芯可以充分利用多计算单元并行，而端边/端云的协同，计算任务完全offload到edge/cloud上可能更为合适。

评估“多计算单元协同高性能”对各指标的影响：

• accuracy：设计良好的协同计算对算法模型的准确率没有影响。
• latency：毕竟利用了多个计算单元，协同计算对latency的改进是显著的。但如阿姆达尔定律，latency的改进受算法模型并行度的影响，“堆”计算单元不会使计算速度线性增加。

• energy efficiency： 协同方式的综合能效介于最好的计算单元和最坏的计算单元之间。对端边/端云协同，energy efficiency特别有优势，因为edge/cloud基本可认为是没有energy限制的，在监控好task offloading的通信能耗的情况下，计算基本都在edge/cloud进行了，端（mobile）的能效可以大大提高。
• memory：多计算单元的通信会占用额外的存储，但总体影响不大。
• flexibility：协同方式没有修改算法/算子，所以对计算框架和算子库的兼容性很好。

单计算单元高性能

充分利用各计算资源的特点，也可以让算法得到充分的加速。如下技术，可充分利用（单）计算单元的能力：

• 选用专用加速芯片
• 编译优化技术
• 低精度运算

选用专用加速芯片

现代移动端SOC上集成了异构芯片，比如CPU，GPU，DSP，NPU，将AI算法部署于专用芯片是当前常见的做法，并且各种计算框架也都支持算法的异构部署执行。各种芯片的特点和计算库不同，技术指标评估如下：

参考“AI Benchmark: All About Deep Learning on Smartphones in 2019”。

综上，考虑性能和能效，AI算法通常不会在CPU上进行部署，如果可能，通常会选择DSP/NPU。 各种计算框架也基本都提供了功能上的兼容机制：当算法的某算子在NPU上不支持时，可以回退（fallback）到其他芯片（如CPU）上执行。但当发生fallback时，性能会损失较大。

编译优化技术

如著名的TVM，“TVM An Automated End-to-End Optimizing Compiler for Deep Learning”。TVM提供了Computational Graphs和code generation两个层级的优化。Computational Graphs在计算执行和数据存储方面提供了Operator Fusion和Data Layout Transformation。Operator Fusion合并几个算子为融合算子，有利于减少算子调度和各算子存储访问的成本。

Code generation，定义computing rule，抽象计算规则以能支持广泛的硬件后端，同时利用硬件特性以提升数据局部性或计算的并行度。

为更好“探索”硬件性能，TVM提供了Automating Optimization机制，以提供hardware awareness machine learning based autotune 能力。

• hardware awareness：将各种算子可能的实现组合在真实硬件上执行，以获取真实性能；
• machine learning：为解决组合过多而导致调优速度过慢问题，TVM训练一个simulator出来，以预测某些算子实现的性能；同时，通过退火算法，以尽可能找到最优解。

这种autotune能力，在新的计算框架中都或多或少进行了应用或扩展，工业界的MACE、MNN的某些特性都有类似的思想。同时，因为比较方便对问题进行数学建模和算法创新，自动优化在学界上也是个研究的热点。
回到我们的指标体系，给一些我们的看法：

• accuracy：因为主要挖掘硬件的计算并行化和提升数据存储的局部性，这些技术对算法来说是无损的，所以编译技术对accuracy无影响。
• latency：编译技术是可以提供更低latency的。 不过这个要看和什么比。 对常用算法和常见的硬件芯片，各硬件厂商已提供了高度优化的计算库。 通用的编译框架在性能上不一定比经过专家深度优化的计算库有优势。
• energy efficiency：编译技术减少了算法运行的指令数和访存数，对能效应该是有帮助的。
• memory：编译技术对memory size的影响应该不大，因为他主要优化的存储布局。
• flexibility：类似TVM的编译技术，可能融合出新的算子，这些新算子通常不会被常用的计算框架支持，所以需要自己实现。当然，TVM提供了实现和优化算法的一整套方法。

TVM是很热的一个技术，不过工业界在应用上有一些争议。个人看法，对在常用硬件上部署常用算法，TVM不一定是好的选择；不过对在新芯片上部署打造新算法，TVM可以提供一个很好的开始。

低精度运算

其实也就是大家说熟知的“量化”。“量化”的big idea是，利用DNN中参数的分布较为集中的特点，将用float32表示的算法模型参数“转化”为int8来“近似”表示，计算也用int8来“近似”运算。这样，计算所需的存储访问更少，计算效率也更高。“量化”已经有大量文章介绍，并且也是各计算框架的“标配”，这里就不过多陈述。

回到我们的指标体系：

• accuracy：量化是有损的近似计算，依赖于不同的量化技术和算法模型，accuracy可能有1%~10%的损失；
• latency：量化后，latency一般能改善2~3倍
• energy efficiency：量化后，能效通常更高
• memory：量化后，size缩小4倍
• flexibility：量化需要支持int8计算的算子库支持，各计算框架对int8算子库的支持通常都较好

量化的部分指标，可参考Google官网数据（https://www.tensorflow.org/lite/performance/model_optimization）

另外，个人理解，近年来挺火的“二值网络”其实也是一种类似的低精度运算思路，待我们有更多理解后补充。

算法模型小型化

前述“自下而上”的计算平台技术，对算法模型本身的架构是无影响的，掌握计算机体系结构知识的工程师就可以实施，并且一般无需对算法模型进行重新训练（训练后量化技术除外）。

而后面陈述的“自上而下”的算法模型小型化技术，基本都要修改算法模型本身的结构，通常都需要有AI算法背景知识的工程师参与或主导。并且，因为修改了算法模型结构，算法模型一般都需要利用数据进行重新训练。

轻量架构

这是AI算法研究的重要领域之一，有效减小某算子（operator）或层（layer）的计算量，就可以把算法的层数做深，以提升算法模型的预测效果。 从移动端算法部署的视角来看，轻量架构能提高算法模型运行的效率和性能。

以MobileNet中的核心算子为例，MobileNet将标准卷积（Conv）转换为深度可分离卷积（Depthwise Separable Conv），对3X3卷积核，参数量和计算量会下降到原来的九分之一到八分之一。具体原理可参考https://zhuanlan.zhihu.com/p/70703846。

回到我们的指标体系，以MobileNet和VGG16的对比为例：

• accuracy：损失1%；
• latency：计算量减少27倍；
• energy efficiency：能效和计算量能同比例改善；
• memory：参数量减少30倍；
• flexibility： Depthwise Separable Conv 需要算子库的支持。各计算平台对常用的轻量化算子已进行了支持。如果有新发明的轻量化算子，需要自行在算子库中支持。

因为轻量化修改了算法模型自身的架构，性能的改善是巨大的。在算法移动端部署的方案阶段，需要评估并选择适合的算法架构，其他技术其实都是对性能的改进和优化，而算法模型本身的架构才对移动端AI应用的技术指标起决定性作用。

通道剪枝（channel pruning）

减少卷积核的通道数量，并约束新老卷积核产生特征的误差尽量小，来简化算法模型的架构。如“Channel pruning for Accelerating Very Deep Neural Networks”，评估技术指标（以论文中的VGG-16网络为例）：

• accuracy & latency：2X speed-up，accuracy无损； 4X speed-up，accuracy损失1%。

• energy efficiency：基本正比于加速效果；
• memory：基本正比于加速效果；
• flexibility：通道剪枝没有引入新算子，对计算框架和算子库无影响。

权重稀疏（weight pruning）

将卷积核中最小的weight屏蔽为0，提供稀疏性（Sparsity）。通过training，weight pruning迭代的过程，在提升稀疏性的同时尽量保持模型准确率。

• accuracy：略有损失
• latency：需要支持稀疏性的底层算子库实现，才能提供加速。
• energy efficiency：需要支持稀疏性的底层算子库实现，才能提供高能效。
• memory：weight高稀疏性，在高压缩存储格式的支持下，能有效减少memory size。
• flexibility：需要支持稀疏性的底层算子库实现，才能提供性能改进。主流计算平台的算子库很少提供稀疏性支持。

另外，知识蒸馏、NAS等技术也能将算法模型轻量化，待我们有更多理解后补充。

 

最后，移动端AI算法部署技术族在快速发展，如有理解不准确，欢迎各位大佬指正。