想找个人做网站,wordpress wdlog主题,英雄联盟世界排名,网站风格变化1、前言
推荐领域算法模型的在线推理是一个对高并发、高实时有较强要求的场景。算法最初是基于Wide Deep相对简单的网络结构进行建模#xff0c;容易满足高实时、高并发的推理性能要求。但随着广告模型效果优化进入深水区#xff0c;基于Transformer用户行为序列和Att…1、前言
推荐领域算法模型的在线推理是一个对高并发、高实时有较强要求的场景。算法最初是基于Wide Deep相对简单的网络结构进行建模容易满足高实时、高并发的推理性能要求。但随着广告模型效果优化进入深水区基于Transformer用户行为序列和Attention的建模逐渐成为主流这个阶段模型的特点是参数的体量、网络结构复杂度呈指数级增长算法建模的创新工作往往由于吞吐和耗时的性能算力问题导致无法落地于在线推理获得效果收益。传统通过扩容资源的方式其边际效应也在减弱算力优化存在诸多挑战
1、高算力需求下的资源成本边际效应问题集群资源扩容是提升算力的一种传统方案但算力需求的增加往往需要成倍数的资源增长才能抹平带来了极强的边际递减效应。
2、复杂算法模型的在线推理算力扩展问题推理引擎要求低延迟和高吞吐而随着模型算法复杂度提升突破计算资源算力上限存储、计算推理耗时显著增加无法满足实时推荐系统的性能要求。
针对上述挑战和问题广告算法架构在迭代演变的过程中构建了一系列的优化体系主要集中在两个方面
1、架构层面设计分布式分图异构计算框架通过模型分图分布式推理实现算力的向外扩展CPUGPU异构硬件差异化部署算法结构与计算硬件资源相得益彰最大化硬件适配性实现算力的指数级增长。算力扩展的架构使得后续垂向优化成为可能可以针对特定业务需求进行深度定制和调整。
2、高算力推理引擎层面从底层架构出发GPU算子调度和计算逻辑精细化优化深入挖掘GPU专用计算设备的潜力实现对推理性能的显著提升。
2、分布式分图异构计算框架
分布式分图异构计算框架是我们针对算力扩展问题提出的解决方案通过模型结构化拆分分布式分图计算CPUGPU异构硬件差异化部署使算法结构与计算硬件资源高度适配充分发挥各自优势。基于CPU计算集群构建大规模稀疏模型建模利用内存资源易扩展等优势支撑千亿规模参数的高性能推理。基于GPU计算集群构建稠密模型建模利用高算力优势支撑超长用户行为序列建模为算法建模的创新提供了坚实的架构基础。我们基于该框架进一步研发并落地了京东零售首个Online Learning建模场景使得模型可以感知人、货、场的实时变化。同时GPU服务集群作为独立于整体服务体系的组成部分便于针对GPU推理引擎进行专项优化从而便捷地进行性能提升措施的实施。 图1 分布式分图异构计算框架
3、高算力推理引擎
为了打造高算力推理引擎开始深入调研基于GPU推理引擎优化推理性能的可行性GPU作为一种高度并行的多核处理器具备极强的并行计算能力由于GPU高度并行化的结构先天适合以稠密矩阵计算为主的NLP、CV领域。但直接应用于推荐领域会存在TP99耗时上涨资源利用率不高等问题。这主要与推荐领域模型的自身特点相关
1、建模过程复杂为建模用户与商品关系推荐领域模型建模不仅包含DNN等稠密计算部分还存在大量针对稀疏特征的Embedding建模方式以及特征预处理等模块集合了IO密集与计算密集两大特性造成计算过程与GPU亲和性不高难以充分发挥GPU的硬件优势。
2、模型规模大推荐领域模型以稀疏参数为主百G规模参数无法完全加载至GPU显存稀疏参数交换导致带宽需求高造成GPU无法充分利用。
3、模型结构复杂用户行为序列建模成为模型建模的主流方法而用户特征的多样性浏览行为、购买行为、加购行为需要单独建模以提升模型对用户的感知能力因此造成模型分支结构多结构复杂。TensorFlow推理框架虽然提供了算子级别的建模方案通过堆叠细粒度算子完成各种复杂的模型建模灵活的支撑了多种行为序列建模方式。但也因此造成了算子粒度过细单算子计算量小不易于GPU充分调度的问题尤其是对于在线推理本身计算量就相对较小的场景问题更为致命。
得益于分布式分图异构计算框架有效解决了上述12问题并且可以让我们针对GPU算子调度和计算逻辑精细化优化深入挖掘GPU专用计算设备的潜力实现对推理性能的显著提升。具体工作体现在以下三个方面aTensorBatch通过聚合计算请求提升GPU计算吞吐b深度学习编译器通过自动化的算子融合、图优化等方式优化模型推理性能c多流计算通过打造GPU多计算通道构建真正的并行计算推理引擎。
3.1、TensorBatch
广告精排模型推理主要表现是单个请求耗时较短(毫秒级)同时每个请求中gpu kernel调用次数较多每次gpu kernel的调度都会伴随相应的kernel launch琐碎繁多的kernel launch会严重制约GPU模型的吞吐能力同时会导致模型系统耗时较高通过Nsight性能分析性能数据如下。 图2 大批量KernelLaunch操作
kernel launch 本质上是从host端核函数调用到GPU开始计算之间的这段时间主要包括准备计算需要数据的传输和执行需要warp线程束的获取无论是数据的传输还是选取执行所需要的warp线程束多个请求之间是可以实现共享的因此我们核心解决问题的思路是将多个模型推理请求合并成一个请求完成模型推理后在对结果再进行合理的分割减少请求级别 kernel launch 的数量极大的提升kernel launch的效率从而进一步提升GPU模型的吞吐能力架构方案如 图3 例如 1个模型请求经过tensorflow推理需要进行 1000 次 kernel launch3个请求需要3000次kernel launch如果将3个请求合并成1个请求那么kernel launch数量会从3000 降至1000。 图3 Tensor Batch架构图
请求级别算子融合在广告精排模型进行全量上线在GPU利用率不变的情况下GPU模型吞吐能力提升2倍。请求级别融合本质是优化GPU kernel launch 效率但是优化GPU kernel launch 效率方案不止一种下面详细介绍一下基于深度学习编译器的算子融合。
3.2、深度学习编译器
KernelLaunch效率问题优化方面我们首先采用了TensorBatch方案在广告算法场景调试聚合数量在5-8左右较为合适聚合后广告数200-1000。虽然对请求进行了聚合但算子执行的TimeLine仍较稀疏如图5所示该现象解释了GPU无法得到充分利用的原因。针对这一现象我们进一步研发了基于深度学习编译器的算子融合方案通过算子融合n次 KernelLaunch至1次大大降低整体KernelLaunch耗时同时通过图优化等策略进一步提升模型的推理性能。 图4 GPU Kernel计算稀疏
3.2.1 深度学习编译器分桶预编译技术
XLAAccelerated Linear Algebra是google开源的深度学习编译器将高级别的模型描述转换成高效的可执行代码自动化的解决算子融合、内存管理、数据布局转换等问题。该框架已融合进Tensorflow开源框架中并提供较友好的编程接口。但原生深度学习编译器在推荐领域模型应用方面存在一系列问题
a同一个XLA Graph针对不同的Tensor输入属性数量、维度、类型会触发不同的编译流程形成多个XLA Runtime编译结果导致开源方案只适用于CV领域定长输入图像维度不变的场景。推荐领域模型变长特征用户行为序列的存在使得在推理过程构建万级别数量的XLA Runtime编译结果在显存消耗上不可接受。
bTensorflow-XLA为运行时编译JIT编译过程缓慢通常完成一个XLA Runtime的编译耗时长达1秒且对CPU、GPU资源占用较大在广告高实时场景下耗时不可接受。
针对上述问题我们研发了深度学习编译器分桶预编译技术。为避免不同特征维度导致的多次编译问题首先对算法结构进行XLA子图划分形成多个XLA子图。其次针对XLA子图的输入特征变长情况实现分桶Padding能力降低XLA Runtime编译数量解决了编译中遇到的显存问题。最后通过模型XLA子图分桶标记算法在模型加载阶段进行预编译解决运行时编译耗时问题。
在深度学习编译器技术加持下我们将广告推荐精排模型的算子调度次数从553次优化至190次XLA子图模块的算子执行的TimeLine得到极大改善单次推理耗时从14ms优化至9ms。 图5 XLA Runtime
3.2.2 深度学习编译器异步编译技术
通过深度学习编译器分桶预编译技术我们解决了99.9%的问题但仍有异常流量导致特征维度超出预设的分桶范围导致触发运行时编译的可能。作为一个高稳定的在线系统我们进一步实现了异步编译技术解决异常流量带来的耗时问题
a模型构图方面同时保留XLA子图与模型原图。
b推理过程动态选择命中分桶情况则选择XLA Runtime执行未命中则选择原图执行同时服务后台触发异步XLA编译供下次请求使用。 图6 深度学习编译器异步编译
3.3、多流计算 图7 GPU多流计算背景
Tensorflow深度学习框架虽然提供了GPU计算能力但其CPU到GPU的交互通道仅为单通道模式。在线并发推理的场景下存在算子调度互斥、算子计算阻塞排队等问题。针对上述痛点我们设计了GPU多通道模式-多流计算架构真正实现了GPU的并发计算能力。
我们对Tensorflow框架中的底层GPU通道的创建和分配机制进行了深入的改造与升级赋予了其在面对同一模型时针对不同的在线请求动态选择GPU通道进行运算的能力。每个GPU通道独立持有一份CUDA Stream和CUDA Context既消除了算子并发调度导致的GPU资源争抢问题也使得不同请求拥有独立的计算通道提升GPU并行粒度。 图8 多GPU通道
多GPU通道多CudaStream 多CudaContext解决了KernelLaunch调度问题算子调度可以并行执行减少了执行的GAP。但在GPU硬件层面CudaContext采用分时复用原则即此某一时刻只有一个CudaContext被调度执行没有完全达到算子计算间的并行。 图9 GPU Kernel交错计算
MPS 多流计算框架实现真正意义的并行计算
MPS局限性MPS(Multi-Process Service)是英伟达为充分利用GPU资源的一种解决方案。MPS多进程服务每个进程有自己的上下文管理机制MPS使用合并共享的并行模式即将多个任务合并成一个上下文因此可以同时跑多个任务是真正意义上的并行。但MPS方案需要多进程服务的场景下才能生效这种情况下单卡显存无法承载多进程任务显存成为瓶颈MPS机制失效无法充分利用GPU算力。 图10 Multi-Process Service局限性
因此我们升级了多流计算架构将MPS与自研的多CudaStream 多CudaContext的多流计算架构相结合解决了显存瓶颈的问题最终通过单进程模型部署实现真正的并行计算。 图11 GPU Kernel并行计算
综上我们实现了完整的GPU多流计算框架创建多组通信渠道打通软件和硬件通道融合调度Context实现真正的计算并行化。 图12 GPU多流计算架构图
4、总结
综上通过设计高性能的计算方案打造新一代算法架构推理体系在架构层面通过分布式分图异构方案很好的解决了高算力需求下的资源成本边际效应问题在高算力推理引擎层面通过一系列的专项优化让GPU的算力得到充分的释放实现复杂算法模型算力的扩展。目前新一代的高性能计算方案已经在广告多个业务线进行了落地实践推荐首页CTR模型、推荐通用信息CTR模型、推荐商详CTR的规模扩展至千亿助力推荐、搜索等核心业务取得显著的效果收益。
高性能算法推理系统是算法架构体系的重要组成部分为算法建模的创新提供了算力基础算力优化是一个极富挑战性的领域它需要我们在技术层面上不断进行探索、学习和创新。目前我们正在着手规划下一代推理算法架构体系其最显著的特点将是算法、计算能力和架构的深度融合以及在线和离线一体化的设计方案。
作者京东零售-平台运营与营销中心-广告研发部-系统技术部-算法应用组
来源京东云开发者社区 转载请注明来源
