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

2023-03-21
浙江
本文字数：2635 字
阅读完需：约 9 分钟

阿里云联合英特尔举办的“创新大师杯”全球 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 的性能优化。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. 其他底层优化选项

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

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

总结

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

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