Press "Enter" to skip to content

沙龙干货|58同城-深度学习平台资源使用率优化实践

本站内容均来自兴趣收集,如不慎侵害的您的相关权益,请留言告知,我们将尽快删除.谢谢.

主题: 58同城 深度学习平台资源使用率优化实践

 

主办: GDG(Google Develope r Groups,谷歌开发者社区)

 

出品: 58同城 AI Lab 负责人,58技术委员会AI分会主席 詹坤林

 

58同城技术委员会AI分会联合谷歌开发者社区于2020年9月12日14:00-16:25举办了一期线上技术沙龙,58同城AI Lab后端高级工程师陈泽龙分享了《 58同城深度学习平台资源使用率优化实践》,以下是分享内容!

 

本期摘要

58同城深度学习平台是集开发实验、模型训练和在线预测为一体的一站式算法研发平台,旨在为集团各业务部门赋能AI算法研发能力,支撑了58同城搜索、推荐、图像、NLP、语音、风控等AI应用。

本次议题将主要介绍58同城深度学习平台如何实现资源使用率的优化,介绍如何利用Intel开源库MKL和开源推理引擎OpenVINO提升模型推理性能,并分享通过TensorFlow模型混合部署、GPU虚拟化技术、模型推理资源监控告警等提升平台资源使用率。

 

分享嘉宾

 

 

陈泽龙

 

58同城 | 后端高级工程师

 

58 同城AI Lab后端高级工程师,2019年加入58同城,目前主要负责深度学习平台和向量检索平台后台开发相关工作。

 

视频回顾

 

分享内容

 

一、深度学习平台介绍

 

58同城深度学习平台是集开发实验、模型训练和在线预测为一体的一站式算法研发平台,旨在为集团各业务部门赋能AI算法研发能力,支撑了58同城搜索、推荐、图像、NLP、语音、风控等AI应用。

 

1. 整体架构

 

深度学习平台总体架构如下图所示:最底层为资源层和存储层,资源层包含GPU、CPU等基础算力资源,为深度学习模型训练及推理提供计算能力,存储层由WFS(58自研的多用户共享高性能分布式文件系统)、HDFS、MySQL等组成,负责模型数据及相关任务配置的存储。

 

在资源层与存储层之上是集群管理层,基于Kubernetes、Docker、Nvidia-Docker等组件实现,负责任务POD和CPU/GPU资源的统一调度管理。集群管理层之上是算法层,集成了当下主流的深度学习框架TensorFlow、PyTorch和Caffe,同时还支持用户自定义的模型需求。最上层是用户接入层,主要包括开发实验、模型训练和模型推理三大功能,我们提供一整套的Web平台实现任务管理、模型部署、资源监控等功能,基于TensorFlow-Serving、gRPC和58自研的RPC框架SCF实现在线推理服务,向用户提供通用的模型推理接口调用。

 

 

2. 在线推理

 

深度学习平台通过一套通用的在线推理框架,实现不同种类和数据类型的模型的统一推理调用。在线推理框架包括SCF服务、推理实例、Kubernetes集群和Web管理系统,SCF服务通过热加载用户上传的协议解析jar包,对外提供通用的RPC调用接口,并通过负载均衡算法,将推理请求均匀地发送到后端推理实例进行模型推理。

 

 

二、资源使用率优化背景

 

随着接入业务模型的增多,发现以下几个问题:

 

1)部分模型CPU上推理性能较低,必须使用GPU才能满足业务需求,导致GPU使用量上升;

 

2)小流量模型GPU使用率普遍较低;

 

3)部分模型GPU占用有限,不能打满整张GPU卡;

 

4)Kubernetes只能按照整卡进行GPU调度分配,无法按需分配GPU算力资源;

 

5)线上部分模型推理资源设置不合理,长期未进行调整。

 

而在生产应用中,GPU资源十分昂贵且有限。优化CPU/GPU上的推理性能,提高资源的使用率,使算力资源得到充分利用便十分的有意义。

 

三、提升CPU上模型推理性能

 

1. Intel MKL库应用

 

MKL是Intel开源的高性能数学算法库,包含线性代数工具、矢量数学库、矢量统计库等工具,支持C和Fortran编程接口;在CPU处理器上提供了性能优化,兼容全部Intel处理器;支持主流的操作系统和主流的开发工具;内置并行处理机制,在多核和多处理器上自动获取出色的扩充性能。

 

我们通过对原生的TensorFlow Serving加入MKL-DNN库进行重新编译,打造了TensorFlow Serving(MKL)版。用户进行TensorFlow CPU模型部署时,可以选择TensorFlow-MKL环境进行部署,而无需对模型进行修改,平台将加载MKL版镜像对模型进行服务部署,TensorFlow Serving (MKL)将自动对模型进行分块排布、层融合等优化操作,提升模型推理性能。OCR图像模型上的测试结果显示,模型推理耗时有明显的降低,CPU使用率有效提升。

 

 

2. Intel OpenVINO推理引擎集成

 

OpenVINO ToolKit是英特尔发布的一套深度学习推理引擎,支持各种网络框架,实现了模型的推理优化部署,提供通用的API接口,支持CPU、GPU、FPGA等多种设备上运行。

 

OpenVINO由模型优化器和推理引擎组成,模型优化器将用户训练训练产生的TF、Caffe等网络模型进行优化,可协助去除已训练好的模型中的冗余参数,并可实现浮点数的参数降阶,优化结果转换成中间表示文件,得到IR文件(xml文件和bin文件)。xml文件中包含优化以后的网络拓扑结构,bin文件包含优化之后的模型参数和模型变 量。OpenVINO推理引擎可以加载IR文件,将模型在多种设备上进行优化部署,提升推理性能。

 

深度学习平台通过增加初始化容器的方式,可以直接将已有的PyTorch/TensorFlow线上模型进行OpenVINO优化部署。进行部署时,首先启动一个InitContainer加载OpenVINO预处理镜像,使用Openvino Model Optimizer将原始的PyTorch/TensorFlow模型优化转换为OpenVINO的IR文件,并将优化后的模型保存在Kubernetes挂载的emptyDir下, InitContainer运行结束后启动主Container,加载OpenVINO推理镜像,通过Openvino Model Server将emptyDir下优化后的模型进行服务部署。

 

 

四、提升平台GPU卡使用率

 

1. TensorFlow小流量模型混合部署

 

当前线上部分TensorFlow模型存在以下两个问题:模型线上流量较小;模型本身无法充分利用GPU资源。两个问题均会导致 GPU使用率较低, GPU卡的算力资源无法得到充分利用。

 

基于此深度学习平台使用TensorFlow Serving的多模型部署特性,实现多模型单节点部署。我们将多个模型的名称、模型部署路径等信息写入统一的模型配置文件。TensorFlow Serving启动时,通过解析模型配置文件,加载多个模型对外提供推理服务。在进行线上推理时,TensorFlow Serving通过模型名称参数映射到对应的模型,并进行相应的模型推理。

 

 

模型首先进行单卡独立部署,根据线上业务流量压测获取GPU使用情况,切换混合部署时,根据压测情况进行相应资源的申请。平台通过Kubernetes实现混合部署资源的统一调度,每个混合部署节点都对应一个独立的部署编号,对于新接入混合部署的模型,需要先进行资源调度计算,从现有的混合部署编号中分配部署编号,当现有部署资源不满足分配时,创建新编号的部署节点进行分配。然后更新线上节点的Deployment配置,写入模型信息,完成模型的混合部署。

 

 

2. GPU虚拟化技术应用

 

当GPU使用率低时,TensorFlow模型可以进行混合部署来实现GPU资源的共享,但是PyTorch、Caffe及用户自定义模型无法进行混合部署。而GPU模型是部署在GPU容器中,通过在部署的yaml文件中写入GPU卡数,采用英伟达的调度器,只能进行整卡部署。

 

 

为了实现PyTorch、Caffe、用户自定义等模型的GPU资源共享,平台应用了GPU虚拟化技术。GPU虚拟化将一块GPU卡的计算能力进行切片,分成多个逻辑上虚拟的GPU,即vGPU,以vGPU为单位分配GPU的计算能力。以vGPU为单位可以将单块GPU卡分配给多台虚拟机使用,大大降低用户的使用成本以及提高数据的处理效率和数据安全性。

 

GPU虚拟化方式主要有API转发、设备仿真、显卡透传,全虚拟化四种。其中API转发和设备仿真具有实现简单的特点,但存在兼容性差及效率低的问题;显卡透传性能良好,但是缺少中间层来跟踪维护GPU状态,同时GPU透传只能将GPU分配给一台虚拟机使用,无法在多台虚拟机间共享;全虚拟化方式将显卡时间片分配给多个虚拟机使用,实现GPU资源的共享,且可以获得接近非虚拟化情况下的性能,使用较为广泛。

 

当前市场上比较常见的GPU虚拟化方案包括基于nvidia grid和nvidia-mps技术的Nvidia vComputeServer和VMware vSphere、驱动科技的OrionX、阿里开源的GPU-Sharing和腾讯开源的GPU Manager等。英伟达及VMware的产品按照显卡收费,价格较高且使用较为复杂;GPU-Sharing开源,但主要是基于显存进行vGPU划分,不满足平台使用需求;OrionX和GPU Manager都可以基于算力及显存进行vGPU划分,且使用简便。综合考虑成本及功能需求,选取OrionX和GPU Manager为备选方案,并在部分常用模型上进行了测试。经过测试,GPU Manager的性能要优于OrionX,最终选取GPU Manager进行集成。

 

 

平台将GPU Manager以插件的形式集成到Kubernetes中,将整张卡虚拟化为多个vGPU卡,供多个模型使用。Master节点上启动kube-scheduler,负责管理整体的Resource和请求url。同时以Daemonset的方式,在每个集群节点上启动一个gpu-manager的POD节点,进行当前机器的GPU拓扑感知,负责GPU资源的分配调度。GPU Manager将一整张GPU卡算力划分为100份,显存按照256MB为一块进行划分,通过yaml配置vcuda-core和vcuda-memory参数来指定资源份额,进行POD资源分配。在进行GPU容器部署时,通过替换容器中原有的cuda库,对cuda调用进行劫持,按照vcuda-core的配置情况,分配相应的核心线程数进行GPU算力资源的限制。(具体请参考GPU Manager 开源地址 及 相关论文 )。

 

 

3. 模型推理资源监控告警

 

在实际工作中,还存在以下问题:任务资源配置后,用户不再进行关注,线上业务流量减小,CPU/GPU等资源的使用率会持续降低,但没有自动扩缩容和模型部署方式自动切换,产生资源浪费,需要业务方进行相应的资源及部署调整。

 

基于Prometheus和Grafana,我们搭建了一套Kubernetes监控系统,提供POD、Container级别的监控数据。从Prometheus中可以获取到Kubernetes中每天每个任务部署节点的CPU/GPU使用数据,通过计算得到任务的CPU/GPU使用率,经过白名单过滤,剔除部分不需要进行监控告警的模型任务,再经过统计,获取任务、部门、集群三个层面的资源使用情况。对于任务信息,通过短信、微信、邮件三种方式,将告警信息发送给任务负责人,提示进行任务资源的重新配置。对于部门信息和集群信息,采用邮件的方式发送资源使用日报,由专人负责查看,推动存在资源浪费的部门进行资源分配及部署方式的调整。

 

 

五、总结

 

通过MKL及OpenVINO的使用,提高了单节点CPU推理能力,减少任务节点部署,同时使原先部分GPU模型迁移至CPU部署,节省了GPU资源。TensorFlow混合部署实现了单Pod多模型部署,GPU虚拟化实现了GPU细粒度调用,可以实现一张卡部署多个Pod。同时采用模型资源监控及时发现不合理的资源配置,为重新配置提供合理的建议。通过以上资源优化,平台模型推理占用GPU卡减少37%, 在用GPU卡平均使用率提升146%。

 

Be First to Comment

发表评论

电子邮件地址不会被公开。 必填项已用*标注