一、背景
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模型推理的终极状态:低延时+高吞吐。
推理过程:
模型并发http/gRPC请求到达Triton后进入模型队列,根据请求到达时间动态组成batch,其实现效率远高于手动组batch,能使请求更加均衡。
batch请求通过模型编排脚本bls的方式,异步分发到各个子模型上,使用InferX推理框架的子模型通过推理加速,在最短的时间内完成推理请求。
对于多模型并联的场景,同样的输入tensor,多个模型实现完美的并行操作,并在内部异步回收结果,对外整体仍是同步接口。
对于多模型串联的场景,通过流水线复用覆盖了多个请求的网络传输及队列等待时间,使得GPU能够尽量少的处于idle状态。
同步返回推理结果,并且统一上报监控指标。
性能收益:
AI目前已经大量部署了Triton模型服务,相比于手写的python服务框架,平均单实例的吞吐都有3-8倍的提高,节省了50%的GPU卡数,压力测试下实现GPU利用率>90%。
结合InferX推理框架4-7倍的推理加速,基本上把显卡的性能压榨到极致,在不增加GPU采购的情况下支持业务流量增长。
八、总结
通过自研InferX推理框架+Triton模型服务部署,显著提升了计算资源使用效率,降低资源成本,保证服务响应时间和稳定,同时降低了ai服务开发部署成本,更快捷地支持各类型业务落地。
-End-
如果大家想了解更多关于大模型、架构演进的相关案例,不妨来参加由msup和高可用架构社区联合主办的GIAC全球互联网架构大会(6月30日-7月1日,深圳),除上述案例外,大会还涉及AIGC、研发效能、Web3等多个前沿且热门的技术领域。同时,组委会携手了84位来自阿里、百度、华为、快手、腾讯云等一线互联网资深架构师及技术型CTO为主的大咖讲师,进行深入的技术解读与探讨交流。如下是部分精彩议题:
大会正在火热报名中 ,点击“阅读原文”,即可查看官网的其他议题。