嵌入式AI简报 (2020-05-15)

关注模型压缩、低比特量化、移动端推理加速优化、部署

导读:本次15条。「新闻」高通发布中端Soc 768G,骁龙875性能规格曝光,联发科方面跟进,发布天玑1000+,中高端的天玑800系列。CUDA11特性曝光。「论文」部分,一篇关于深度学习编译器架构的综述论文,详细剖析常用的设计思想,对现有的深度学习编译器进行全面总结。「开源」MNN PR一年来的总结回顾及armv8.2等新特性、PaddleLite PR对瑞芯微AI芯片的支持、OpenCL3.0发布、NervanaSystem当年关于GPU上的优化项目分析、TF新的Runtime。「博文」解析MegEngine的显存优化技术分析,Tengine和PaddleLite算子选择策略浅析。

手机SOC方面较多,单独一段总结:三星Exynos992曝光6nm制程可能超越骁龙865,Imagination新闻频频,Imagination已经将IMG A系列GPU在多个市场中授权给了客户,首批搭载该IP的SoC器件将在今年供货,高通与Imagination同时宣布支持Google的Android GPU Inspector在各家的Adreno或PowerVR GPU上的负载分析小米迎来高通Adreno GPU驱动更新 | Qualcomm中国荣耀发布Play 4T新机,搭载中芯国际14nm代工的麒麟710A,且已成功量产

业界新闻

  • Redmi K30 5G首发高通全新SoC 768G | 迷你手机网
    摘要:从命名上看,骁龙768G是骁龙765G的升级版,应该类似于骁龙855和骁龙855+的关系。
    根据爆料,骁龙768G处理器采用了1+1+4(2.8GHz+2.4GHz+1.8GHz)组合,GPU为Adreno 620,骁龙768G的2颗大核A76都提升了主频,GPU主频提升到了750MHz,整体性能提升在10%~15%。据测试安兔兔跑分达到了36万分。
    并且骁龙768G采用7nm EUV工艺制程,是一款集成式双模5G SoC,CPU部分拥有两颗A76架构性能大核,相较骁龙765G,其主频部分提升到了2.8GHz,同时,骁龙768G的GPU频率也提升到了750MHz。
  • 高通骁龙875性能规格曝光!或集成X60 5G基带,台积电5nm工艺 | 智东西
    摘要:高通即将推出的骁龙875,将采用台积电5nm工艺预计2021年发布。此外,该芯片组规格代号为SM8350,其上一代骁龙865代号为SM8250。目前不清楚骁龙875芯片的5G调制解调器是否采用集成式方案。
    性能方面,骁龙875采用Armv8 Cortex架构的Kryo 685 CPU,Adreno 660 GPU、Adreno 665 VPU和Adreno 1095 DPU,以及一颗Spectra 580图像处理引擎,支持3G/4G/5G调制解调器mmWave(毫米波)和低于6GHz频段。
  • 联发科天玑1000+升级亮相,中高端800系列发布 | 三易生活
    摘要:GPU性能方面,天玑1000+在天玑1000的基础上增强,将屏幕高帧率显示的上限从120Hz提升到144Hz,新的“MiraVision 画质引擎”可实现独立AI处理单元(联发科叫APU)和专用画质处理电路的联动计算,支持4K分辨率视频的AI实时处理。无论是从5G、AI、GPU设计这些“底子”上的技术水准,还是从游戏与视频优化这些“面子”上锦上添花的功能来说,联发科的天玑1000+这次都算是更上了一层楼。
    此外,作为联发科中高端系列的代表,也是天玑800系列的升级款,但命名上并不是天玑800+,很有可能会改名为天玑820。听说天玑800系列一共有三种工程方案,主频分别是中杯2.0GHz、大杯2.2GHz左右和超大杯2.6GHz左右。
  • CUDA 11 Features Revealed | NVIDIA Developer
    摘要:The A100 GPU has revolutionary hardware capabilities and we’re excited to announce CUDA 11 in conjunction with A100.
    1. Support for the NVIDIA Ampere GPU architecture, including the new NVIDIA A100 GPU for accelerated scale-up and scale-out of AI and HPC data centers; multi-GPU systems with the NVSwitch fabric such as the DGX A100 and HGX A100.
    2. Multi-Instance GPU (MIG) partitioning capability that is particularly beneficial to cloud service providers (CSPs) for improved GPU utilization.
    3. New third-generation Tensor Cores to accelerate mixed-precision, matrix operations on different data types, including TF32 and Bfloat16.
    4. Programming and APIs for task graphs, asynchronous data movement, fine-grained synchronization, and L2 cache residency control.
    5. Performance optimizations in CUDA libraries for linear algebra, FFTs, and matrix multiplication.
    6. Updates to the Nsight product family of tools for tracing, profiling, and debugging of CUDA applications.
    7. Full support on all major CPU architectures, across x86_64, Arm64 server and POWER architectures.

论文

  • 一篇关于深度学习编译器架构的综述论文 | 知乎
    标题:The Deep Learning Compiler: A Comprehensive Survey
    链接:https://arxiv.org/abs/2002.03794
    摘要:目前还都没有全面分析深度学习编译器这种独特设计架构。本文详细剖析常用的设计思想,对现有的深度学习编译器进行全面总结,重点是面向深度学习的多级中间表示(IR)以及前后端的优化。具体来说,作者从各个方面对现有编译器做全面比较,对多级IR的设计进行了详细分析,并介绍了常用的优化技术。最后,文章强调对今后编译器潜在研究方向的一些见解。基本上这是深度学习编译器设计体系结构(不是硬件方面)的第一个综述。
  • Facebook发布提高设备AI工作能效的AutoScale | 将门创投
    摘要:Facebook和亚利桑那州立大学建立了一个支持AI减轻设备负荷的模型——AutoScale。AutoScale通过观察当前AI执行效率,包括算法架构特征和运行时间。协同处理器等硬件之间选择,找到能最大限度提高能效的硬件。
    AutoScale基于强化学习算法,计算累计奖励(R值),来选择AI工具的最佳运行方式。例如:对于给定的处理器,系统使用基于AI能效利用率的模型计算奖励,假设处理器内核消耗的功率是可变的,内核在繁忙和空闲状态下花费的时间不同,能源使用情况也不同。此外,当推理扩展到连接的数据中心时,AutoScale可以借助基于信号强度的模型来计算奖励,预测传输延迟度和网络消耗的能量。

开源项目

注:每条内容前缀为github地址的仓库拥有者和仓库名,补全地址后为github.com/<repo_owner>/<repo_name>

  • alibaba/MNN: 开源一年,阿里轻量级AI推理引擎MNN 1.0.0正式发布 | AI科技大本营
    摘要:MNN在阿里巴巴集团内部得到广泛推广,覆盖了如手机淘宝、天猫、优酷、钉钉、闲鱼等20多个App。在这次release中,包括且不限于以下特点:
    1. 新增模型训练的支持,从此MNN不再是单纯的推理引擎,可Quantization Aware Training (QAT);
    2. 利用ARMv8.2指令集,获得了两倍的性能提升;
    3. 进一步完善Python工具链,累计新增超过150个接口;
    4. 开源了应用层开箱即用的解决方案MNNKit,包含了人脸跟踪与检测、人像分割、手势识别等。
  • PaddlePaddle/Paddle-Lite:百度PaddleLite适配瑞芯微AI芯片,携手加速AI应用落地 | 飞桨PaddlePaddle
    摘要:百度PaddleLite与瑞芯微Rockchip旗下AI芯片RK1808、RK1806正式完成适配,充分兼容飞桨轻量化推理引擎Paddle Lite。
    瑞芯微AI芯片RK1808及RK1806,内置独立NPU神经计算单元,INT8 算力高达3.0TOPs;采用22nm FD-SOI工艺,相同性能下的功耗相比主流28nm工艺产品降低约30%,在算力、性能、功耗等指标上均有优异的表现。经实测,瑞芯微AI芯片在Paddle Lite中运行MobileNet V1耗时仅为6.5 ms,帧率高达153.8 FPS,二者充分兼容并高效稳定运行。
  • OpenCL 3.0 release发布:更灵活、异步DMA扩展支持 | khronos.org
    摘要:OpenCL 3.0 integrates subgroup functionality into the core specification, ships with a new OpenCL C 3.0 language specification, uses a new unified specification format, and introduces extensions for asynchronous data copies to enable a new class of embedded processors. The provisional OpenCL 3.0 specifications enable the developer community to provide feedback before the specifications and conformance tests are finalized.
    更多,见如何评价 OpenCL 3.0 | 知乎
  • NervanaSystems/maxas:矩阵相乘在GPU上的终极优化:深度解析Maxas汇编器工作原理 | 机器之心
    摘要:Nervana汇编代码生成器项目Maxas,可生成性能超过nVidia官方版本的矩阵相乘的GPU机器码,其作者 Scott Gray 在代码外提供了详细的文档NervanaSystems/maxas/wiki/SGEMM,本文可以看作按作者对该文档的理解进行的重写。
  • tensorflow/runtime:全新的 TensorFlow 运行时 | TensorFlow
    摘要:TensorFlow RunTime (TFRT) 旨在提供一个统一、可扩展的基础架构层,在各种领域特定硬件上实现一流性能。高效利用多线程主机的 CPU,支持完全异步的编程模型,同时专注于底层效率。
    现有 TensorFlow 的设计初衷是针对图执行和训练工作负载搭建,而新运行时则首要关注即时执行和推理,同时注重架构可扩展性和模块化。更具体地说,TFRT 已实现以下设计亮点:
    1. 为提升性能,TFRT 配备无锁计算图执行器,支持并行操作执行,且同步开销较低。此外,其还配备一个轻量的即时算子分发栈,便于异步即时 API 调用和提高效率;
    2. 为了更加轻松地扩展 TF 技术栈,我们已将设备运行时与主机运行时(即驱动主机 CPU 和 I/O 工作的核心 TFRT 组件)解耦;
    3. 为确保行为一致,TFRT 在即时和图执行模式中均使用通用抽象,例如形状函数和内核。
      TFRT 还与 MLIR 紧密集成。例如:
    4. TFRT 利用 MLIR 的编译器基础架构,为特定目标的运行时执行计算图生成优化表征;
    5. TFRT 使用 MLIR 的可扩展类型系统支持运行时中的任意 C++ 类型,消除了仅支持特定张量的限制。
      如何评价TensorFlow开源的新运行时TFRT | 知乎

博文

  • 深度解析MegEngine亚线性显存优化技术 | 旷视研究院
    摘要:深度学习框架有几种降低显存占用的常用方法,其示例如下:
    1. 通过合适的梯度定义,让算子的梯度计算不再依赖于前向计算作为输入,从而in-place地完成算子的前向计算,比如Sigmoid、Relu等;
    2. 在生命周期没有重叠的算子之间共享显存;
    3. 通过额外的计算减少显存占用,比如利用梯度检查点重新计算中间结果的亚线性显存优化方法[1];
    4. 通过额外的数据传输减少显存占用,比如把暂时不用的数据从GPU交换到CPU,需要时再从CPU交换回来。
      上述显存优化技术在MegEngine中皆有不同程度的实现,这里重点讨论基于梯度检查点的亚线性显存优化技术。
      此外,亚线性优化方法采用简单的网格搜索(grid search)选择检查点,MegEngine在此基础上增加遗传算法,采用边界移动、块合并、块分裂等策略,实现更细粒度的优化,进一步降低了显存占用。
  • FLOPs与模型推理速度 | 知乎
    摘要:两个layer的FLOPs和参数量完全相同。但是推理速度方面,depthwise卷积要远远慢于普通卷积。其原因就是访存数据量的不同:
    由于卷积计算本身已经是flatten的,不需要考虑重复读取问题,那么总共读取的数据量就是feature的大小加上卷积核weight的大小,对于普通卷积来说,总读取数据量为:100*56*56 + 3*3*100*100 = 4.0e+05。类似的,depthwise卷积读取的数据总量为:56*56*10000 + 3*3*10000 = 3.1e+07
    可以看到,在同等FLOPs的情况下,depthwise卷积对应的feature size比普通卷积大的多,受制于GPU访存带宽,过高的数据读取与写入量就成为了限制推理速度的瓶颈。
  • Tengine多平台的算子调度与选择分析 | 知乎
    摘要:Tengine目前已开源部分的算子对不同平台有各自的实现和优化,包括不限于arm32、arm64、x86等。对于其余的算子则是通过加载reference算子实现。那么当模型执行时,对于多平台下的同一算子,Tengine是如何选择的呢,本文将会进行介绍与分析。
  • Paddle Lite底层backend的kernel选择策略 | NeuralTalk
    摘要:Paddle Lite是Paddle Mobile和Anakin的推理框架继任者。定位安卓/iOS移动端,以及X86端在内的多场景高性能预测,兼容支持ONNX、TensorFlow、Caffe等模型的部署。本文将描述Paddle Lite在模型转换过程(模型转换opt工具)中,静态kernel选择的策略以及一些思考。

往期回顾

2 0 2 0
2020-05-15 2020-04-26
2020-04-04 2020-03-19 2020-03-02 2020-02-16
2020-01-27 2020-01-06 2019-12-17 2019-12-02
2 0 1 9
2019-11-30 2019-11-18 2019-10-31 2019-10-17
2019-10-03 2019-09-16 2019-08-30 2019-08-15
2019-07-30 2019-07-15 2019-06-29 2019-06-17
2019-05-30 2019-05-15 2019-04-27 2019-04-13
2019-03-31

wechat_qrcode

往期回顾:见公众号主菜单【历史消息】


知识共享许可协议
本作品采用知识共享署名-相同方式共享 4.0 通用许可协议进行许可。


本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!

2020-06-03@Bi-weekly 上一篇
2020-04-26@Bi-weekly 下一篇