阿里云PAI-DeepRec CTR 模型性能优化天池大赛——获奖队伍技术分享
阿里云联合英特尔举办的“创新大师杯”全球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 个方面：
- CTR稀疏模型训练优化：6个模型均为经典的 CTR 稀疏模型，在特征处理、算子等方面可能具有一定的优化空间。
- DeepRec训练加速参数调优：DeepRec 本身已经具有有来自 Alibaba 和 Intel 团队的很多优秀的技术沉淀，对模型训练有很多参数都可以进行调优。
- 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 的性能优化。
- 我们最初对所有模型都设置了相同的 micro_batch_num，经过我们实验，当micro_batch_num = 2时，所有模型都可达到 AUC 要求，相对原始版本速度可以提升900s左右。
- 当 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. 其他底层优化选项
下面是我们对于其他底层优化的想法与探索：
- 使用微软开源的 mimalloc 作为内存分配器可以进一步优化性能，实测可以节省 4% 的时间，但由于时间关系我们并未打包提交。
- MKL 库有比较多算子可供使用，可以针对不同的算子选择性地调用 MKL，这一方向也由于时间的关系没有来得及完成。
总结
在 DeepCTR 比赛中，我们从稀疏模型、训练加速调优、底层框架调优等 3 个方面出发，主要做了以上 5 点的优化，其中 GRU 算子和稀疏特征的优化灵感来自于团队之前在 MetaSpore 的开发中的技术沉淀。决赛阶段遇到了各路好手，很多问题的切入点独到而新颖，非常有启发性，值得我们学习和借鉴。
最后，将以上所有优化点进行叠加，我们得到如下总运行时间对比图，可以清晰的看到，经过我们的优化，模型训练效率得到 3 倍以上提升，训练时间减少了 70%。
注：以上测试都是在我们本地机器（8核16G）上进行的测试，因此与线上成绩有一定差异。
Github 链接：
https://github.com/meta-soul/DeepRec/tree/tianchi
DeepRec开源地址：
