关于人工智能:阿里云PAIDeepRec-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 个方面：

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