阿里云GPU云办事器的AIACC助力UC搜刮营业性能提效380%，每年节省数万万成本

简介： 用阿里云GPU计算实例来称心UC极致性价比需求

文丨阿里云神龙计算平台AI加速团队 UC搜刮架构部推理引擎团队

导语：做为国产行列里占有率排名第一的挪动阅读器，UC阅读器本身承载着数以亿计的用户量，当前UC阅读器每天的办事恳求对办事器的算力及带宽要求极高，因而也带来了巨额的运营成本。因为营业是动态改变的，UC对计算资本也有动态扩缩容的需求。阿里云GPU云办事器是供给GPU算力的弹性计算办事，具有超强的计算才能，办事于深度进修、科学计算、图形可视化、视频处置多种应用场景，能为客户供给软件与硬件连系的完好办事系统，助力客户在现实营业中实现资本的灵敏分配、弹性扩展、算力的提拔以及成本的掌握。而基于阿里云GPU云办事器的神龙AI加速引擎（AIACC）是为了极致性能而生，旨在打造世界级无与伦比的AI性能体验，同时为了客户降本增效，实现共赢。据悉，刚公布的最新世界MLPerfTM推理榜单中，基于阿里云GPU云办事器的AIACC初次打破封锁式场景世界第一。

本篇文章将带各人领会阿里云AIACC若何基于阿里云GPU云办事器助力UC阅读器的搜刮营业平衡计算性能与运营成本之间的矛盾，使其大幅实现降本增效，胜利在阿里云的GPU云办事器落地。

背 景

1. 营业布景

UC搜刮承载着UC次要营业入口，场景包罗：大搜、各类垂搜营业、夸克app等。搜刮流程一般颠末几个阶段：召回 – 粗排 - 精排(L2-L4) - 混排等。架构如下：

展开全文

在营业中，L3/L4排序部门都利用了QTC核心模子。跟着营业流量的增长，目前精排打分阶段面对庞大挑战，延迟和吞吐都要兼得。

2. QTC模子

下图是用TF-summary对QTC模子做可视化，

QTC模子属于排序核心模子，模子构造分为3个BERT+ 多层Conv + 多层MLP等，此中Bert输入seq length更大长度是512。模子总共有大约4500个算子，计算量庞大。

3. 原始性能

最后接纳了NV供给的Faster-Transformer那一套软件来优化QTC模子的推理，但因为Faster-Transformer只能加速BERT收集，招致推理时需要做多个子图割裂运行，加上其余收集部门也未做优化，从而整体性能其实不好。针对A100机型，做了基于那套计划的性能评估，延迟掌握在30ms下，QTC模子只能跑到350QPS。

4. 挑战与目的

跟着模子效果带来的营业收益，促使营业流量不竭增加，在算法预算前提下，扩量面对比力大的挑战。一方面资本不敷，一方面资本也没有完全操纵起来招致的吞吐不敷，同时察看阐发在GPU利用率到达90%以上时延迟会呈现飙升的情状，那种情状关于不变性带来了不小的影响。若何在本来预算的根底上进步吞吐、降低延迟、提拔性价比最末规模化上线为营业赋能成为更大的挑战。

连系搜刮营业的特点，针对QTC模子在GPU上推理提出了几个方面的需求：

1. 为了包管算法的效果，推理时模子输出的误差掌握在千分位；

2. 为了包管末端用户在搜刮时的体验，精排部门的推理耗时在30ms以内；

3. 在有限的预算下称心营业的需求，即QPS需要远高于原有处理计划；

综合营业方各个方面的需求，UC造定如下的目的：

在A100机型上，包管精度的前提下，QTC模子耗时在30ms以内，QPS到达1120以上。

优 化

1. 优化道路

TensorRT是Nvidia开发的针对模子推理的高性能软件库，但QTC模子复杂度高，无法整体间接用TensorRT load。此外，间接用TensorRT load时部门层会被拆成细粒度的op，性能较差。对QTC模子做深度的阐发之后，结论是用TensorRT以及其plugin撑持的op能够笼盖QTC模子的op，但是现有的parser无法根据需要的粒度去解析QTC模子并映射到TensorRT上。

针对上述问题，AIACC从模子定义层，间接解析QTC模子并映射到TensorRT上，制止转PB后大的operator被拆分红细粒度的operator，以到达更佳性能。此外，那么做也便于以差别的粒度停止模子精度的阐发，以差别的粒度实现op的合成与替代，方面集成AIACC的高性能Kernel进来。

2. Enable TensorRT 精度对齐

2.1 映射准确性验证

解析QTC模子并映射到TensorRT上的过程中，起首要处理的问题是映射的准确性验证。对准确性验证，起首要处理基准是什么那个问题。我们拿到的信息为一份模子构造的代码与一个训练中的checkpoint。基于营业方给的有限的信息，完成了从训练框架侧load checkpoint的逻辑，并根据需求，留下了能够获取肆意中间成果的接口。在验证映射准确性的过程中，我们以训练框架侧运行推理的成果为比照的baseline，和我们构建的TensorRT侧的Engine的运行成果做比照，来判断能否准确的把QTC模子映射到TensorRT上。

下面以一个self-attention层为例，展开怎么做QTC模子到TensorRT的映射并包管运算成果的一致。

在TensorRT侧，为了校验映射的准确性，需要有推理的脚原来验证build好的engine的准确性。同在训练框架侧构建准确性的baseline类似，我们基于TensorRT开发了一套load build好的engine并做推理的脚本，来获取engine的推理成果，用于和训练框架侧的baseline做比照。

TensorRT为了逃求更高的性能，对self-attention层的运算做了等价改变，把部门转换提早到模子build阶段，进而削减模子推理需要的operation。其他的一些细节，包罗mask处置、数据类型、hidden size等，根据类似逻辑，逐个对齐后，我们即可在TensorRT侧构建出运行成果与训练框架侧运行成果一致的engine。

比照TensorRT间接load checkpoint的形式，在我们的映射中，把self-attention映射为1个op，制止了拆成多个细碎op而招致的性能问题。那种形式下self-attention的信息在一个节点上，也便利我们后续做kernel的优化，例如合成self-attention内部的GEMM等多个操做，以到达更好的新能。

2.2 数值问题处理

数值问题是AI使命中很难定位处理的一类问题，因为没有编译器或者其他的报错提醒来搀扶帮助我们定位问题。在把QTC模子映射到TensorRT的时候，碰到了数值问题，现象为多个不异的根底模块叠加招致中间的feature map中有NAN的异常值，进而招致最末的成果误差远远超出营业团队要求的千分位。

第一时间把那个问题定为数值问题，是因为在QTC模子到TensorRT映射过程中，每一个子模块我们都做了单位测试来验证映射的准确性，不存在映射错误招致的异常。此外，为了推理的性能，我们开启了FP16，部门中间的运算是用FP16停止，FP16的表达才能比拟FP32差良多，那是引入数值问题的一个风险点。多个不异的根底模块叠加招致最末的输出中有NAN的异常值，可能率是因为计算中呈现了极大or极小的数值，招致某些操做，例如做exp/除法的时候，呈现的异常的行为。

阐发清晰问题后，处理问题的办法也很简单，完美TensorRT中那部门exp计算逻辑，制止exp计算中呈现大的负值即可。

2.3 其他的N个问题的概述

在把QTC模子映射到TensorRT并对齐精度的过程中，我们还碰到了其他一系列大大小小的其他问题，那里纷歧一展开，只在简单列举一下，包罗用shuffle替代reduce来进步实现reshape的运算的效率，用identity层来实现data type cast的逻辑，conv层的参数转换，pooling的padding处置，reshape后接FC层参数排布等问题。

3. 关键Kernel优化

seq_length=35/512时，TensorRT未对Multi-Head Attention做针对性优化。seq_length为512的Bert耗时占比力大，若是对那部门做针对性优化，会获取较大幅度的性能提拔。对那部门的优化我们分两步停止，第一步优化了seq_length=512的Multi-Head Attention中的softmax的实现，第二步则是针对seq_length为35/512的case做了类似TensorRT针对seq_length=64的情形下做的合成。

下图是seq_length为512的情状下，未优化前的一个Transformer层挪用的Kernel，此中绿框中的kernel为第一步优化的Kernel，红框中的部门则是第二步优化中合成为一个。

4. Enable CUDA-Graph

CUDA Graph是一个把所有kernel算子连系（capture）成Graph，然后整体launch那个Graph，削减频繁的kernel launch来带的开销以及kernel中间的gap。下图是通俗的kernel施行和Graph施行的区别。能够看出，在kernel施行时因为需要CPU和GPU切换，形成小算子间会有比力大的GPU idle时间（gap引起），同时若是小算子施行的时间比力短，那么launch的时间占比就成了大头，形成GPU操纵率低下。

在CUDA11版本和Ampere架构下，CUDA Graph自己做了很大的改良，在CUDA内部做了并行化处置。

从机造图能够看到，CUDA内部在施行Graph时，查找依赖关系，若是发现无间接依赖且目前资本称默算子施行（好比：stream processor/share memory/register等）则并行施行，进步GPU操纵率。同时我们也对CUDA Graph下做了一些优化（好比增加memory cache机造、graph min update、multi-stream处置等）更好地提拔了性能。

Enable CUDA Graph有两种体例，此中流捕捉供给了一种从现有的基于流的 API 创建图的机造。在QTC模子中，通过流捕捉的体例来加速基于TensorRT构建的图。Enable CUDA Graph后，在A100上延迟有3%下降，吞吐进步了4%，在GPU利用率高时latency也更不变。

业 务 结 果

下图中，Faster-Transformer是指UC原有的基于Faster-Transformer的在GPU上的处理计划；AIACC-Optimization是我们优化后的性能数据：

在UC的消费情况中，A100机型上QPS到达了1330，为最后Faster-Transformer版本的3.8倍，超出了预设的目的。

目前，接纳AIACC那一系列优化的QTC模子已经在部门搜刮营业上线利用，后续即将大规模线上利用。按更低的预期利用量来计算，每年能节省达数万万的成本。

在此次协做中，UC搜刮精排应用在阿里云GPU云办事器上运行的性价比得到了显著提拔，能够把营业批量摆设在生态成熟的阿里云GPU云办事器上。云平台弹性扩缩容的长处让UC能够根据营业需求，按需从阿里云上获取GPU云办事器资本。此外，推理用的机型和训练用的机型同一，让消费链路上从算法到优化再到摆设的工程师协做更便利，也便利后续在线上实现训练与推理使命的混合摆设，更大化GPU资本的操纵。

阿里云AIACC针对阿里云GPU云办事器硬件做了深切的优化，达成了在不额外引入新硬件平台的情状下，用阿里云GPU计算实例来称心UC极致性价比需求的目的。此外，用UC实在应用打磨的优化性能工做都沉淀到AIACC中，后续能够规模化办事更多的阿里云GPU云办事器的客户。

点击那里，领会阿里云GPU云办事器。

原文链接：/

本文为阿里云原创内容，未经允许不得转载。