简介： 用阿里云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-GraphCUDA 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云服务器。原文链接：https://click.aliyun.com/m/10...本文为阿里云原创内容，未经容许不得转载。