哔哩哔哩大规模AI模型推理实践

本期作者

戴彦

哔哩哔哩资深算法工程师

杨典

哔哩哔哩资深开发工程师

一、背景

AI算法复杂度逐年上升，需要高效的方式支持AI模型的推理和部署。
随着应用规模的扩大，算力资源消耗也在快速增长，对线上资源产生极大的压力。
B站AI涉及计算机视觉（CV）、自然语言处理（NLP）、语音等多个场景，服务于内容安全审核、内容理解和创作的上百个应用场景。

二、挑战和目标

挑战

线上资源随着流量线性增长，在降本增效的背景下，希望控制线上资源的增长。
随着大语言模型在工业界的推广和落地，NLP场景部署了BERT，GPT，T5-Large模型，模型复杂度明显提升。
帧级别的视频处理。例如，在OCR(Optical character recognition) 场景下，24小时内累计处理超过10亿张720p图片。这给模型推理和模型服务带来了极大的压力。

流量的增长和算法复杂度的提升给线上服务的Response Time和QPS带来了巨大的挑战。
大量长尾场景需要有统一的方式接入。

目标

提高推理的吞吐，降低资源增长速度。
改进Response Time，提升服务的质量。
扩展新业务，落地更多场景。

三、InferX推理框架介绍

针对上述的问题，我们自研了推理框架，内部研发代号InferX。架构图如下所示。

通用推理框架可以拆分为Interpreter, Graph Optimizer和Backend等组件。除了上述组件之外，InferX支持若干模型计算前链路优化，例如稀疏化和量化。

近期InferX迭代主要包括了如下几个方面。

支持ONNX链路，通过ONNX链路支持Tensorflow和paddle模型。提高模型的部署效率。
改进InferX运行时，优化资源获取方式，减少了CPU占用
模型前链路优化的能力：支持int8和sparsity
扩展了图像算子的能力。

四、InferX推理框架计算前链路

InferX计算前链路指模型在上线前进行的若干离线处理，当前主要包括量化和稀疏化。

模型量化：

相比于FP16， INT8 TensorCore的性能翻倍。
InferX实现了量化SDK，能够较为方便地进行模型量化。
PTQ量化已经在OCR和版权场景落地。
上图展示了InferX量化的流程。需要注意的是，InferX实现了TensorRT Lowering Graph Optimizer。如果跳过上述的Graph Optimizer，量化的模型将会没有任何加速。
下图显示了量化在版权模型推理场景的收益。量化模型精度近乎无损，同时实现了2x的加速比。

模型结构化稀疏：

NVidia从Ampere架构开始支持2:4稀疏方案，2:4 Sparsity能够利用Sparsity TensorCore的性能。
训练后pruning，与算法协同完成sparsity模型的链路
支持稀疏化构建
相比于dense的TensorCore，稀疏化TensorCore加速比为2x。但是由于稀疏化tensor-core只能作用于卷积，linear算子，因此，模型总体的加速比低于2x。例如，下图中，长尾kernel无法使用sparsity-tensorcore进行优化。

FP16 sparsity tensor-core在部分模型上有精度的问题，工程上可以通过混合精度计算解决。

五、使用InferX优化重点场景

—— 以OCR为例

项目背景：

OCR是审核能力的重要组成部分。
OCR需要进行逐帧的处理，需要消耗大量的计算资源。

需要注意的是，本章节讨论了如何优化一个重点场景，涉及到的技术不限于InferX。

模型适配：

由于OCR中存在第三方的算子，无法直接导出，针对这一缺陷，InferX支持了ONNX作为模型的交换格式，实现了ONNX Parser将ONNX模型转换为图中间表示。同时由于OCR中有第三方的算子可变形卷积（deformable convolution），需要在后端中添加算子的实现。后续deformable convolution这一技术在多个检测场景中都得到了复用。

基于CUDA的可变形卷积的实现

通过优化cuda算子提高性能
实现了NHWC 版本 deformable convolution，改进了im2col 操作的访存效率。
实现内存对齐，将矩阵乘法的m/n/k补齐到8的倍数，确保使用tensor-core进行计算（需要注意的是，这是CUDA11之前的约束，CUDA11之后，TensorCore的使用已经没有了上述限制）。
下图中展示NCHW和NHWC Layout在进行im2col时的差别，相比于原始的NCHW内存布局，NHWC是更加内存和Cache友好的内存布局，能够进行合并的内存访问（Memory Coalescing）。

基于结构化稀疏的模型加速

InferX支持稀疏化模型的构建并且支持显式定义层精度，解决精度问题。
识别模型加速大约为25%。

基于CUDA的JPEG Decoder优化

libjpeg的decode是CPU密集型任务, 过高的CPU占用会影响服务的稳定性并且由于libjpeg已经非常成熟，很难优化。
实现了inferx_cv 解码库，封装了nvjpeg，支持硬件解码，CUDA解码和CPU解码。
使用CUDA进行jpeg解码， cuda以非常低的GPU利用率解码jpeg，耗时仅为CPU的1/4。

视频/直播OCR资源复用和同步化改造

旧的架构中，视频/直播OCR是不同的模型服务。
旧的架构为异步执行的GRPC，但是视频/直播OCR的协议不同。
通过模型服务的同步改造，统一了协议，视频和直播共享模型服务，Response Time和服务的稳定性都得到了提升。
模型服务增加优先级的支持，直播请求有更高的优先级。
通过利用视频和直播服务的流量趋势的差异，大幅提高了线上机器的GPU利用率。

基于上述优化的OCR服务，能够以80%的GPU利用率稳定运行，并且保证服务具有较低的response Time。与未优化前相比，总资源数节省了63%。

六、Triton模型服务介绍

相比于推理框架，模型服务的关注点是不同的，更加侧重于提高吞吐和并行，提升整体资源利用率。

挑战：

对于不同业务使用的不用类型的模型，提供统一的工程链路帮助模型快速上线。
部门自研的推理加速框架InferX能缩短推理时间，但同样需要提高吞吐以增加GPU资源利用率。
很多业务使用了多个模型，模型间会有逻辑及依赖关系，需要对模型串联/并联提供编排能力。

针对上述问题，我们调研了常用的开源框架（Triton, TF-Serving等），最终选择了基于Nvidia Triton Inference Server的模型推理服务，它提供了以下功能：

支持多种深度学习框架，包括Pytorch，Tensorflow，ONNX，Python，DALI，TensorRT等框架生成的模型均可部署。并支持自定义的模型框架。
支持模型编排BLS。对于多模型串联/并联场景可以使用Python编写模型编排代码来完成(1)前处理，(2)分发tensor到各个模型推理并回收结果，(3)后处理的整个流程。
支持动态batch。即向模型服务发送请求不需要提前组batch，Triton可以根据需要自动完成组batch操作，并且可以配置batch的参数，如prefered batch size，queue size，default timeout等。
提供HTTP/gRPC client，可以方便推理服务上游分发侧接入。
支持Metrics，自动采集服务实时QPS，错误数，耗时，GPU利用率等参数。

七、Triton模型服务

+InferX推理框架

我们将InferX推理框架集成进Triton模型服务，则构成了AI模型推理的终极状态：低延时+高吞吐。

推理过程：