• 设为首页
  • 点击收藏
  • 手机版
    手机扫一扫访问
    迪恩网络手机版
  • 关注官方公众号
    微信扫一扫关注
    迪恩网络公众号

17 倍加速:PyTorch 模型的 GPU 优化剖析

原作者: [db:作者] 来自: [db:来源] 收藏 邀请

17 倍加速:PyTorch 模型的 GPU 优化剖析

背景

IFX 是滴滴自研的 AI 推理引擎框架,针对云、端、边提供 AI 部署解决方案。目前,滴滴内部有很多 PyTorch 模型已经接入到 IFX 云端框架,并且通过 Serving 方式上线。

在模型从接入到上线的整个流程中,有一个必需的环节:在相同环境下评测 IFX 相比 PyTorch(1.3.1) 带来的性能收益。

这些模型大概分为两类:resnet 和 mobilenet。从上面结果可以看到 resnet 系列的(A、B、C、D)模型在适配到 IFX 框架之后性能提升大概在3-4倍,mobilenet 系列的(E、F)模型大概是17倍。

针对用户接入的E、F模型,IFX 相比 PyTorch 提升了 17 倍左右,为什么有这么大的优化空间呢,本文就来一步一步分析下。

基础分析

E、F模型网络结构是 mobilenet-v3,这里是 mobilenet-v3模型介绍,可以看下模型主要的结构以及用途。从 PyTorch 导出的 onnx 模型中粗略估算了下,mobilenet-v3 包含约460个算子;

首先我们先分析一下 PyTorch 的实现,利用 nvprof 看到 PyTorch 的模型执行过程中调用了500+的算子,比460多的原因是 PyTorch 的 conv 算子实现中会额外调用一个数据处理算子。

然后我们具体分析下模型结构,下面这个是 mobilenet-v3 网络中最常见结构。mobilenet-v3 网络中用到了特殊的激活函数 hswish、hsigmoid,上面的四个黑色算子实现的是 hswish。在整个 mobilenet-v3 网络中,hswish 调用了31次,hsigmoid 调用了13次,这样相关的算子总数是31*4+13*3=163个,在模型中占比还是比较大的,而 PyTorch 的计算中没有对这部分做单独的优化实现,只是依次进行基础运算。

这个图里面包含了 PyTorch 针对 hswish 的实现流程,4个红色箭头指向的计算单元分别实现了 hswish 的 add、clip、mul、div 操作,4个算子总耗时为 10.88us

下面说一下 IFX 针对此模型的一个优化方法,由于 hswish、hsigmoid 这两个算子具有通用性,所以 IFX 将 hswish、hsigmoid 两个函数整合成了2个单独的算子,这样的融合操作降低了算子个数,同时优化过的算子相比原来性能更好。

可以看到 IFX 单独实现的 hswish 算子计算耗时为2.14us,仅计算部分性能是 PyTorch 的5倍左右。

其实这个 hswish 的融合操作只是 IFX fusion 策略中的一个,像 conv+elementwise、conv+bn+relu 这种常见的结构是可以 fusion 成一个 conv 的。

在所有 fusion 策略应用到 mobilenet-v3 之后,模型算子个数由原来的460降低为160,数量降低的同时算子性能还有提升。

可以看到在只做了两个算子的融合+基础算子(Conv、Bn、Fc等)优化之后模型性能已经提升8倍左右,当把所有优化策略应用到模型之后,又有1倍+的性能提升。

算子数量优化掉这么多,为什么会产生这么大影响呢,需要理解的是所有的算子调用都需要从cpu 上 launch 到 GPU 上计算,这部分开销在 PyTorch 的实现里是很大的。

可以看到完成17个算子的计算,GPU 上的耗时大概1.39ms,而其中真正计算占比很小(大约104us),空白区域是 PyTorch 调用到 GPU 其他的一些 Runtime API,这样看GPU 计算资源没有被充分利用。所以说针对 PyTorch 框架:operations more,waste more.

可以看到实现相同的子网络,IFX 5个算子大概的耗时是80us,其中计算的耗时在53ms,相比 PyTorch 计算效率更高。

这样测下来,针对典型子网络结构,IFX 快了 17 倍左右,和整体性能提升保持一致。测试过程和结果表明,PyTorch 慢是有道理的。

拓展分析

接下来我们继续研究下 PyTorch 为什么在 kernel 执行之间调用那么多的 Cuda Runtime API,首先先看下调用的 API 究竟有哪些:放大之后,看到是CudaSetDevice(),

CudaGetDevice() 这两个 API。基于这个信息,我们可以查看下 PyTorch 源码中这两个 API 的调用点,最终定位到c10/cuda目录。

c10 目录是 PyTorch 最重要的源代码文件夹,也就是几乎所有的源代码都与这里的代码有关系,比如我们的类型定义,PyTorch Tensor 的内存分配方式等等,都在这个文件夹中。

cuda 子目录里面则实现了 GPU 相关的 Device、Stream、Tensor 的调度和管理。

通过查看该目录下的源码,看到 CudaSetDevice(),CudaGetDevice()这两个 api 在这些类中有调用:

PyTorch 的实现里确实是有一些 cuda 调用机制会直接或间接的带来很大开销。

除了这点之外,我们还可以从 nvprof 中看到在模型推理过程中 PyTorch 除了算子计算耗时、额外的 Runtime API 耗时之外还有很多空白的地方,这些其实是在执行 cpu 上的指令那这个地方有没有优化空间呢?有的,大家可以分析下这部分耗时的原因。

欢迎大家使用滴滴云 GPU 云主机来进行深度学习模型的训练和推理,性能非常好。

输入AI大师码【1122】,滴滴云GPU全线产品享9折优惠。



鲜花

握手

雷人

路过

鸡蛋
专题导读
热门推荐
阅读排行榜

扫描微信二维码

查看手机版网站

随时了解更新最新资讯

139-2527-9053

在线客服(服务时间 9:00~18:00)

在线QQ客服
地址:深圳市南山区西丽大学城创智工业园
电邮:jeky_zhao#qq.com
移动电话:139-2527-9053

Powered by 互联科技 X3.4© 2001-2213 极客世界.|Sitemap