文丨阿里云神龙计算平台 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 云服务器。