阿里云PAI-DeepRec CTR 模型性能优化天池大赛——获奖队伍技术分享

原创
03/21 11:40
阅读数 581

阿里云联合英特尔举办的“创新大师杯”全球AI极客挑战赛——PAI-DeepRec CTR模型性能优化挑战赛已结束 ,此次大赛旨在DeepRec中沉淀CTR模型新的优化思路和优化方向。为了和大家共享经验成果,邀请获奖队伍分享解题思路,共同推动实际工业实际场景中点击率预估模型的训练效率的提升。

大家好,我们是MetaSpore团队,三位成员孙凯、苏程成、朱亚东均来自北京数元灵科技有限公司,其中苏程成就读于西安交大,曾为数元灵科技实习生。

今年7月中旬,阿里云联合 Intel 启动了“创新大师杯”全球AI极客挑战赛——PAI-DeepRec CTR模型性能优化,全球一共有超过3800支队伍报名参加比赛。经过近 5 个月的努力,我们在保障 6 个经典的 CTR 模型AUC 基本不损失的前提下,将训练效率提升了 3 倍以上,减少了接近 70% 的训练时间。团队在全球初赛和全球复赛都获得了排名第一的成绩,本文将就比赛中的整体思路和具体方案进行阐述。

解题思路

首先必须承认,这是一道比较难的题目。因为 DeepRec 已经集成了来自 Alibaba、Intel、Google等众多优秀工程师的智慧,在这个基础上再进行性能优化,不得不说是一个非常具有挑战性的问题。经过长时间的迭代,团队优化思路如下图所示,主要可以概括为一下 3 个方面:

image.png

  1. CTR稀疏模型训练优化:6个模型均为经典的 CTR 稀疏模型,在特征处理、算子等方面可能具有一定的优化空间。
  2. DeepRec训练加速参数调优:DeepRec 本身已经具有有来自 Alibaba 和 Intel 团队的很多优秀的技术沉淀,对模型训练有很多参数都可以进行调优。
  3. DeepRec框架性能优化:这个方面我们觉得可能在编译选项、优化器等方面有一定的空间,以便更好的发挥硬件潜能。

稀疏模型训练优化

1. 选择更快的 GRUCell

对于DIEN模型,我们注意到其使用了GRU,而GRU是串行执行,必然会耗费大量时间,因此我们先把矛头对准了GRU。

阶段一:DIEN使用的是tf.nn.rnn_cell.GRUCell接口,在查阅 tensorflow 官方文档时我们注意到tf.contrib.rnn.GRUBlockCellV2能够有更好的性能。

图片

因此我们将 tensorflow 中的tf.nn.rnn_cell.GRUCell改为了 tf.contrib.rnn.GRUBlockCellV2。tf.nn.rnn_cell.GRUCell是使用 python写的 GRU,因此其反向传播需要计算图层层传递。而tf.contrib.rnn.GRUBlockCellV2用 C++ 编写的,并且实现了 forward 和 backward,因此速度会相对快一点。

阶段二:在 GRU 的优化获得初步收益之后,我们在想能否有替代 GRU的网络结构。之后我们调研了替换 GRU 的方法,发现 SRU 可以在不损失 AUC 的情况下加快模型的训练,相比原始版本速度提升约80s。SRU 论文链接:

https://arxiv.org/pdf/1709.02755.pdf

图片

为什么 SRU 会比较快呢?我们来看GRU与SRU的实现公式:

图片

相比于GRU,SRU 对时序依赖更弱一些,SRU有 3 个步骤依赖于前面的状态,并且依赖 C(t-1) 的操作使用的是 Hadamard 积,计算量更小;论文最后还通过消融实验发现,与C(t-1)相关的 2 个操作可以省略,因此代码实现中并没有粉色部分。

阶段三(未采用):既然 GRU 能改成 SRU,那 SRU 能否继续优化呢,我们带着这个疑问开始尝试优化SRU,最终我们得到了一个保持 AUC 不变的简化版 SRU,其速度又能够提升 50s 左右。由于并没有严格的理论分析,最终我们并未把这个版本提交上去,不过在代码记录了这个版本。

2. 优化稀疏特征表示

在查看DeepFM 模型的 Timeline 图(下图所示),我们发现其中有大量的 OneHot 算子异常耗时。

图片

我们注意到官方文档中描述embedding_column 速度会更快,而且更适合高维稀疏的类别特征,于是我们将Indicator_column替换为了embedding_column。

图片

对比结果如下:

图片

训练加速参数调优

开启流水线在阅读 DeepRec 文档时,我们注意到了 AutoMicroBatch,它的本质是一个模型训练的流水线,多个MicroBatch 对梯度进行累加后更新至 variable,DeepRec 文档中给出的实测效果下图所示。

图片

我们首先对这五个模型开启 micro_batch 进行了实验,发现Wide & Deep 模型不能使。我们首先对这五个模型开启micro_batch 进行了实验,发现Wide & Deep 模型不能使用 micro_batch,其使用的tf.feature_column.linear_model 接口与 micro_batch 冲突,导致运行crash,如下左图示。因此我们将 Wide & Deep 模型使用的 tf.feature_column.linear_model 进行了重写,如下右图所示。

图片

经过了以上的准备,我们开启了micro_batch 的性能优化。

  1. 我们最初对所有模型都设置了相同的 micro_batch_num,经过我们实验,当micro_batch_num = 2时,所有模型都可达到 AUC 要求,相对原始版本速度可以提升900s左右。
  2. 当 micro_batch_num 再大一点,DIEN 模型的 AUC 会低于赛题标准,其他几个模型AUC基本没有变化。因此,我们对DIEN 模型进行了特殊处理,也就是给它单独设置一个 micro_batch_num ,最终经过我们实验,我们给DIEN模型 micro_batch_num 设置为 2,其他几个模型采用默认值 8。

对比结果如下:

图片

底层框架性能调优

1. 优化编译选项

在DeepRec比赛教程中给出的编译选项如下

bazel build  -c opt --config=opt  --config=mkl_threadpool --define build_with_mkl_dnn_v1_only=true

该编译选项使用了针对intel处理器进行优化的 mkl_threadpool。tensorflow有很多可配置的编译选项,不同的编译选项会编译出不同性能的框架,经过我们尝试,在本次比赛中,经过优化编译选项,相较原始版本速度提升130s左右。

编译选项如下:

bazel build -c opt --config=opt //tensorflow/tools/pip_package:build_pip_package

对比结果如下:

图片

2. 其他底层优化选项

下面是我们对于其他底层优化的想法与探索:

  1. 使用微软开源的 mimalloc 作为内存分配器可以进一步优化性能,实测可以节省 4% 的时间,但由于时间关系我们并未打包提交。
  2. MKL 库有比较多算子可供使用,可以针对不同的算子选择性地调用 MKL,这一方向也由于时间的关系没有来得及完成。

总结

在 DeepCTR 比赛中,我们从稀疏模型、训练加速调优、底层框架调优等 3 个方面出发,主要做了以上 5 点的优化,其中 GRU 算子和稀疏特征的优化灵感来自于团队之前在 MetaSpore 的开发中的技术沉淀。决赛阶段遇到了各路好手,很多问题的切入点独到而新颖,非常有启发性,值得我们学习和借鉴。

最后,将以上所有优化点进行叠加,我们得到如下总运行时间对比图,可以清晰的看到,经过我们的优化,模型训练效率得到 3 倍以上提升,训练时间减少了 70%。

图片

注:以上测试都是在我们本地机器(8核16G)上进行的测试,因此与线上成绩有一定差异。

Github 链接:

https://github.com/meta-soul/DeepRec/tree/tianchi

DeepRec开源地址:

https://github.com/alibaba/DeepRec

展开阅读全文
加载中

作者的其它热门文章

0
0 收藏
分享
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部