MNN技术推理引擎的最新实测结果分享!
署名2020-12-23

MNN技术推理引擎的最新实测结果分享!端侧AI在这两三年里,可谓高速发展,新应用、新算法、新硬件推陈出新,也不断有新推理引擎涌现。但对引擎的评价方式定格在了三年前,比较的总是ARMv7/ARM64下MobileNet、SqueezeNet、ResNet不同版本的性能比较。但这几个模型的性能真的是推理引擎们的终极目标吗?当然不是!如果我们的目标是真正去降低社区AI应用的门槛,就不能只停留在这些指标上。  

一、MNN技术推理引擎应至少具有三个基本特性:  

测评报告的原初目的,应该是便于用户针对自身的业务,做出选择,而不是秀肌肉。一个好的推理引擎应至少具有三个基本特性:  

(1)通用性,模型支持是一切应用的前提。  

(2)高性能,但快慢若脱离业务价值,也会缺失实际意义。  

(3)易用性,能少搬几块砖,岂不美哉?  

因此,行业评价推理引擎的方式亟需升级——性能上,除了基准的数据,也应包含对新后端、新特性的支持情况;算子上,用户可能更关心除了CNN以外,能不能支持RNN、GAN、Transformer;易用性上,是不是有提供可视化工具、测评工具、量化工具,编程界面是不是足够友好。  

二、MNN技术推理引擎的性能指标:  

(1)高性能:  

虽然说不能只看性能,但点名了,还是要回应一下的。做完数据验证,虽然数据和TNN的测评稍有出入,但毕竟也为我们的工程师刷新了一个小目标。于是,我们把之前搁置的优化拎上了日程。一周不到的时间,835/845上跑小网络,CPU上,略胜一筹。GPU上,则是5~15%的领先。但这再也不是当年从2000ms降低到700ms那样的飞跃了。而如果我们放眼大一些的模型,比如InceptionV3,又或是打开ARMv8.2的情况下,不论是fp16还是quant,性能都可以有一段跃迁。可以为业务带来质变优化的点依然存在。而这些,正是我们暂时按下ARM优化的原因。  

(2)通用性:  

除了性能,用户最为关心的指标就是通用性。性能再好,业务模型跑不起来都白搭。而MNN背靠阿里巴巴的众多智能场景,久经各方业务的磨炼,在支持算子的数量、算子实现的质量上,都可谓久经考验。模型转换上,我们没有将Caffe、TensorFlow、TensorFlowLite的转换转嫁给三方的工具,尽量避免模型格式间转换导致的失败。从开源到现在,在支持的转换算子总量上,MNN翻了一番还多。算子实现上,我们在计算后端的支持上,应该也是业界最广的。除了前文所述的ARMv8.2,我们在GPU算子的支持上,也不遑多让。计算算子数量时,对Binary、Unary、Reduce算子,统一到友商口径,采用拆分成多种的方式计算。  

(3)易用性:  

易用性方面,在过去的一年,我们也着墨颇多。可视化上,我们在跨平台可视化工具Netron上增加了对MNN模型的支持。模型压缩上,我们的工具同时支持了KL和ADMM两种量化方式,即可以采用Post-trainingQuantization降低量化门槛,也可以采用QuantizationAwareTraining来提升量化的精度。模型测评上,我们提供的校验工具和Profiler工具,可以帮助开发者快速定位模型中的问题所在。  

前端语言上,我们还打通了MNN和Python的桥接,方便算法工程师们,在自己熟悉的平台、熟悉的语言上,完成开发、校验。以上就是关于MNN技术推理引擎的最新实测结果分享!