【阅读笔记】【端侧AI】A Comprehensive Benchmark of Deep Learning Libraries on Mobile Devices

系列文章目录

---

---

【阅读笔记】【端侧AI】A Comprehensive Benchmark of Deep Learning Libraries on Mobile Devices

阅读笔记，非全文翻译

---

问题

摘要

• 首次构建了一个全面的涵盖了6个代表性的DL库和15个不同DL模型的benchmark
• 然后在10个移动设备上进行了实验
• 发现：DL库的影响甚至超过了算法和硬件（模型量化、基于GPU/DSP的异构计算）带来的优化
• 总结了DLL（Libraries）

1 引言

• 嵌入DL的App数量激增
• 运行时推理（预测）是端侧DL的基本要求，工业界和学术界都在关注推理性能
• 目前文献都关注在硬件和模型，缺少了对软件（DL执行引擎或DL库）
• 构建MDLBench，6个DLL（TFLite，Pytorchmobile，ncnn，MNN，Mace，SNPE），共15个模型，10个移动设备
• 有以下发现
  1. 6个DLL的表现在不同模型和硬件上表现差距非常巨大
  2. DLL的影响超过了算法设计和硬件优化
  3. 集成不同DLL在算子级别（Operator Level）的最优实现，有潜力提高DLL的性能
  4. cold-start inference比warm inference慢很多，因为内存准备阶段的影响
  5. 实验中性能BUG出现很多次，1-16周才能修复
• 有以下总结
  1. For DL app 开发者：①选择DLL很重要；②更轻量化的模型不一定运行得更快
  2. for DLL 工程师和研究者：①考虑结合不同DLL库的优点；②关注冷启动问题；③动态、静态分析都需要，来定位性能bug

2 Benchmark和Methodology

MDLBench的优点如下：

• 丰富的支持
  

• 指标
  推理时间和operator-level的信息：pre-operator延迟、耗费时间、输入输出维度

• 流程
  

• 设备
  

3 性能分析

3.1 性能碎片化

1. 不存在one size fit all的DLL，指出两个事实
   • 端侧硬件生态因为他们不同的内部架构很碎片化（很有不同）
   • 模型架构的异构也会导致不同的结果

2. DLL性能差异很大，Table5
   

3. GPU后端的选择（Vulkan，OpenGL，OpenCL）也扩大了碎片化

4. 因为软件的差异，模型架构不再是决定模型相对性能的唯一因素

3.2 量化的影响

• 实验了INT-8类型的量化

• INT8量化带来的好处是在预期内的

• 不如理论上的快

• 但量化后速度有的还不如FP32快，原因

  1. 现代SoCs对FP运算有优化
  2. FP32张量的运算是有优化过的，通过查看源码提交记录发现
  3. FP32和INT8转换也是有开销的，这一步通常发生在最后的softmax层

• Implications：不是所有的量化都能加速，软件层面还有改进的空间

3.3 硬件的影响

同见图4

• 新移动设备SoCs可以加速推理，但也不是所有情况都这样。 图5展示了晓龙430-888在3个库上的表现，性能都有改善的趋势。
• 870不如855，可能因为DL库在855上优化更多。
  
• GPU也不总是能加速推理。 大多数情况带来1.4到1.9倍提升，少数例子GPU更慢（2.3倍）。
• INT8模型，GPU几乎没有带来提升
• 原因可能是
  1. 移动端GPU设计用于渲染，而不是通常的计算，其计算能力受限
  2. DLL对GPU的优化不如对CPU的优化，实验中发现GPU中算术处理单元使用率不高
  3. 移动GPU不支持对INT8格式的计算，实际上计算还是FP32
  4. 一些运算不支持GPU上调用，CPU和GPU来回拷贝数据也有开销
• Implication ：DLL开发者要注意GPU端的优化
• 多数场景下DSP能够显著加速INT8模型。 同见图4。高通DSP有AI兼容性，作者的测量表示，其实DSP对功耗的改善更好。小米11骁龙888例外，它太新了（有趣）。

3.4 DL库的算子级别的集成

• 从表现最好的DLL中挑出算子operator来组合成一个新的DLLOracle Lib。

• 推理时间可以获得0-29.9%的提升。

• We find Mace has best support for convolution with 3x3 kernels, while ncnn performs best for convolution with 1x7 and 1x3 kernels. For some activation and software layers, TFLite performs best. （缝合）

• Implication DLL开发者要把不同DLL中最优的部分找出来再组合起来，虽然实现比较困难，比如张量对齐和内存池。

3.5 冷启动推理（Cold-start Inference）

• 冷启动推理比warm inference慢太多。
• 冷启动推理中，内存准备是最大的开销。
  
• 在源码发现，内存准备的部分是单线程的
• 为GPU的显存准备更耗时因为，在进入GPU之前，代码要先编译成shader
  
• implication 改进方法：多线程

3.6 纵向分析

分析了DLL的性能随着时间（开发版本）的变化，从Mar/Jul 2018 到 Jul 2021。

• 早年性能上升，2020年后基本稳定，可能是因为开发人员开始把优化中心转移到更多operator的适配上。
• 也出现了只针对一个架构如Mobile netV2有提升，其他架构都没有提升的现象。
• 在某些提交，观察到了明显的性能退化。For instance, a convolution kernel may perform well with 3x3 kernel size and stride size 2, but not with 3x3 kernel size and stride size. Among the 34 detected performance bugs, it takes around 1–16 weeks to fix so that the performance can be recovered.
  
• Implication 作者提出两个可能解决办法。①构建一个有不同模型的环境，（每天）都运行一次综合的检测（比如本文的MDLBench），从而发现performance bug。 ②构建一个静态分析工具，根据历史可以定位存在潜在bug的提交。

4 相关工作

Mobile DL

• 近年，数据不上云是趋势，DL模型移到本地，性能优化成了学术和工业界的研究方向。
• 有 offloading，模型量化和sparsity（剪枝？）等方法，但都是在实验室用收集来的手机数据，本文直接使用真机

AI Benchmarks

• 相比于其他相近的关注DLL的benchmark，MDLBench支持的DLL和模型更多。

移动DL的经验研究

• 关注DL apps / 系统 / 模型
• Xu分析了安卓App
• Wang研究了移动app的进化
• Andrey研究了移动设备上对DL的硬件加速
• 但都没有综合的分析

DL编译器

• pre-define primitives of operators and rules to find an optimal implementation.
• 本文没有用，因为①SOTA DL编译器是给服务器端用的；②移动设备太多太杂，为每个设备指定执行方案不现实

5 结论

• 构建了DL库的第一个综合性的benchmark。