关于人工智能:阿里云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

【腾讯云】轻量 2核2G4M,首年65元

阿里云限时活动-云数据库 RDS MySQL  1核2G配置 1.88/月 速抢

本文由乐趣区整理发布,转载请注明出处,谢谢。

您可能还喜欢...

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据