专栏名称: AINLP

关注AI、NLP相关技术，关注算法研发职位和课程；回复"文章"获取历史信息；双语聊天机器人"无名"；中英翻译请输入：翻译翻译内容；自动对联，请输入：上联上联内容；调戏夸夸聊天机器人，请求夸、求赞；查询相似词，请输入: 相似词词条

新一代CTR预测服务的GPU优化实践

AINLP · 公众号 · · 2021-10-07 22:45

正文

undefined

CTR模型在互联网的搜索、推荐、广告等场景有着广泛的应用。近年来，随着深度神经网络的引入，CTR模型的推理对硬件算力的要求逐渐增加。本文介绍了美团在CTR模型优化的实践。通过分析模型结构特点，结合GPU硬件架构，我们设计了一系列流程对模型进行定制优化，达到了降低延迟、提高吞吐、节省成本的目标。

1 背景
2 CTR模型GPU推理的挑战

2.1 应用层的挑战
2.2 框架层的挑战
2.3 硬件层的挑战

3 优化手段

3.1 算子融合
3.2 CPU-GPU数据传输优化
3.3 高频子图手工优化
3.4 CPU-GPU分流

4 压测性能分析
5 整体架构
6 不足之处与未来规划

1 背景

CTR（ Click-Through-Rate ）即点击通过率，是指网络广告的点击到达率，即该广告的实际点击次数除以广告的展现量。为CTR指标服务的打分模型，一般称为CTR模型。我们可以将此概念进一步扩展到互联网应用中各种预估转化率的模型。CTR模型在推荐、搜索、广告等场景被广泛应用。相对于CV（计算机视觉）、NLP（自然语音处理）场景的模型，CTR模型的历史结构比较简单，计算量较小。美团的CTR模型一直沿用CPU推理的方式。随着近几年深度神经网络的引入，CTR模型结构逐渐趋于复杂，计算量也越来越大，CPU开始不能满足模型对于算力的需求。

而GPU拥有几千个计算核心，可以在单机内提供密集的并行计算能力，在CV、NLP等领域展示了强大的能力。通过CUDA[1]及相关API，英伟达建立了完整的GPU生态。基于此，美团基础研发平台通过一套方案将CTR模型部署到GPU上。单从模型预测阶段看，我们提供的基于英伟达T4的GPU深度优化方案，在相同成本约束下，对比CPU，提升了10倍的吞吐能力。同时，在典型的搜索精排场景中，从端到端的维度来看，整体吞吐能力提升了一倍以上。

除了提高吞吐、降低成本外，GPU方案还为CTR模型的应用带来了额外的可能。例如，在某搜索框自动补全的场景，由于天然的交互属性，时延要求非常苛刻，一般来说无法使用复杂的模型。而在GPU能力的加持下，某复杂模型的平均响应时间从15毫秒降低至6~7毫秒，已经达到了上线要求。

接下来，本文将与大家探讨美团机器学习平台提供的新一代CTR预测服务的GPU优化思路、效果、优势与不足，希望对从事相关工作的同学有所帮助或者启发。

2 CTR模型GPU推理的挑战

2.1 应用层的挑战

CTR模型结构多变，包含大量业务相关的结构，同时新的SOTA模型也层出不穷，硬件供应商由于人力受限，会重点优化常用的经典结构，如ResNet。对于没有收敛的结构，官方没有端到端的优化工具可以支持。
CTR模型中通常包含较大的Embedding表结构，要考虑到Embedding表存在显存放不下的情况。
在典型的推荐场景中，为了达到更快的POI曝光的目的，模型的时效性要求很高，在线模型服务需要提供增量更新模型的能力。

2.2 框架层的挑战

算子层面 ：目前主流的深度学习框架，如TensorFlow和PyTorch，可以说是深度学习第二代框架，它们首先要解决第一代框架Caffe的问题，Caffe有一个明显问题就是Layer的粒度过粗，导致那个时代的算法开发者都必须有“自己写自定义层”的能力。TensorFlow和PyTorch都把模型表达能力放在较高的优先级，导致算子粒度比较小，无论是对CPU还是GPU架构，都会带来很大的额外开销。
框架层面 ：TensorFlow和PyTorch本质都是训练框架，对算法开发者比较友好，但非部署友好。其中隐含了很多为了方便分布式训练做的设计，比如TensorFlow为了方便将Variable拆到不同的PS上，内置了Partitioned_Variable的设计。在基于GPU单机预测的场景下，这些结构也会带来额外的开销。

2.3 硬件层的挑战

第一，TensorFlow的算子粒度划分较细，导致一个模型通常由几千个算子构成，这些算子在GPU上的执行转变为对应的GPU kernel的执行。kernel是GPU上并行执行的函数。

GPU kernel大体上可以划分为传输数据、kernel启动、kernel计算等几个阶段，其中每个kernel的启动需要约10𝞵𝘀左右。大量的小算子导致每个kernel的执行时间很短，kernel启动的耗时占了大部分。相邻的kernel之间需要通过读写显存进行数据的传输，产生大量的访存开销。而GPU的访存吞吐远远低于计算吞吐，导致性能低下，GPU利用率并不高。

第二，GPU卡上包含多个计算单元，理论上，不同计算单元是可以跑不同kernel的，但实际上为了编程简单，CUDA默认假设在同一时刻一个Stream里跑同一个kernel。虽然可以通过多Stream的方式跑，但是多Steam之间又缺少细粒度的协同机制。

在经过充分调研与讨论后，我们决定第一期重点关注TensorFlow框架下如何解决常见CTR模型结构在英伟达GPU上执行效率不高的问题，我们先将问题收敛为以下两个子问题：

算子粒度过细，GPU执行效率低下。
模型结构多变，手工优化投入大，通用性差。

3 优化手段

为了解决上面的问题，我们对业界深度学习加速器进行了一些调研。业界比较成熟的推理优化方案主要是TensorRT/XLA/TVM。TensorRT采用手工优化，对一些定制的模型结构进行算子融合，并对计算密集型算子（如卷积）进行了高效调优。XLA是TensorFlow内置的编译优化工具，主要针对访存密集型结构，通过编译手段，实现算子的融合。TVM[2]具备较全面的优化能力，使用编译手段进行算子的融合，同时可以通过机器学习的方式实现计算密集型算子的自动调优。

经过广泛的调研和对比，我们最终选择了TVM作为优化工具。TVM通过编译手段，可以较好地应对多变的模型结构，解决了手工优化通用性差的问题。但TVM应用在业务模型也存在一系列问题：支持的算子数较少，而且目前对动态Shape的支持还不够好。针对这两个问题，我们将TVM和TensorFlow结合起来，结合CTR模型的结构特点与GPU的硬件特性，开发一系列流程，实现了对CTR模型的优化。

3.1 算子融合

通过将多个小算子融合为一个语义等价的大算子，可以有效减少GPU上的kernel数量。一方面，kernel数量减少直接降低了kernel发射的开销；另一方面，融合后的大kernel执行的计算量增加，避免了多个kernel间数据传输导致的频繁访存，提高了计算的访存比。

可以看到，上图中的左右等价结构，左侧的21个算子执行的运算，可以在1个等价算子中完成。反映到GPU的活动上，左侧至少有21个GPU kernel以及21次显存的读写，而右侧只需要执行1个kernel以及1次显存读写。对于每个融合后的算子，需要有对应的kernel实现。然而，模型的算子组合是无穷的，对每种融合后算子手工实现kernel是不现实的。TVM通过编译手段，可以自动进行算子的融合以及设备代码生成，避免了逐一手写kernel的负担。

3.1.1 TF-TVM自动切图优化

TensorFlow模型中，如果包含TVM不支持的算子，会导致无法执行TVM转换。我们的思路是将可以用TVM优化的部分切出来，转为TVM的engine，其他部分依然使用TensorFlow的算子。在XLA和TRT转换的时候也有类似问题，我们分析了TF-XLA和TF-TRT二者的实现：

TF-XLA的实现方案，在Grappler[4]优化图之后，有一个POST_REWRITE_FOR_EXEC（通过这个关键字可以在源码中搜索到）阶段，在这个阶段，会执行三个针对Graph的Pass，分别是用来标记算子，封装子图，改写子图并构建LaunchOp。
TF-TRT的实现方案，TF-TRT在Grappler中注册了一个优化器，在这个优化器中，找到连通子图，并将其替换为TRT Engine。

在最终方案实现上，我们参考了TF-TRT的设计。这个设计对比XLA的优势在于XLA切图方案与TensorFlow源码紧耦合，直接将XLA的三个Pass嵌入到了启动Session的主流程中。而切图策略，优化策略后续会有非常频繁的迭代，我们不希望与TensorFlow的源码太过耦合。我们扩展了TF-TVM的方案，在实际使用中我们把这个切图过程为一个独立流程。在模型部署或更新时，自动触发。

在推理阶段，优化过的子图使用TVM执行，其余的计算图使用TensorFlow原生实现执行，将两者结合共同完成模型的推理。由于TVM和TensorFlow的Runtime各自使用独立的内存管理，数据在不同框架间传输会导致额外的性能开销。为了降低这部分开销，我们打通了两个框架的底层数据结构，尽可能避免额外的数据拷贝。

3.1.2 计算图等价替换

TensorFlow模型中过多的不被TVM支持的算子会导致TF-TVM切图零碎，影响最终的优化效果。为了让TF-TVM切图尽量大且完整，以及让TVM优化过程中的融合力度更大，我们对模型中的一些复杂结构进行检测，替换为执行更高效或更易于融合的等价结构。

例如，TensorFlow原生EmbeddingLookup结构，为了支持分布式训练，会对Embedding表进行切分，产生DynamicPartition和ParallelDynamicStitch等动态算子。这些动态算子不被TVM支持，导致TF-TVM图切分过于细碎。为了让TF-TVM切图更完整，我们通过图替换，对这种结构进行修改，通过将Embedding分表提前合并，得到简化的EmbeddingLookup结构。

3.2 CPU-GPU数据传输优化

TVM优化后的子图被替换为一个节点，该节点在GPU上执行，通常有几十甚至几百个输入，该节点的前置输入（如Placeholder ）通常是在CPU上执行，会涉及多次的CPU-GPU传输。频繁的小数据量传输，无法充分利用带宽。为了解决这个问题，我们对模型结构进行修改，在计算图中添加合并与拆分节点，控制切图的位置，减少数据传输的次数。

一种可能的合并方式是，对这些输入按相同的Shape和Dtype进行合并，后续进行拆分，将拆分节点切入TVM的子图一起优化。这种方式会导致一些问题，如部分子图的算子融合效果不佳；另一方面，GPU kernel函数的参数传递内存限制在4KB，对于TVM节点输入非常多的情况（如超过512个