沙龙干货|58同城-深度学习平台资源使用率优化实践
主题：58同城深度学习平台资源使用率优化实践
主办：GDG（Google Developer Groups，谷歌开发者社区）
出品：58同城 AI Lab 负责人，58技术委员会AI分会主席 詹坤林
58同城技术委员会AI分会联合谷歌开发者社区于2020年9月12日14:00-16:25举办了一期线上技术沙龙，58同城AI Lab后端高级工程师陈泽龙分享了《 58同城深度学习平台资源使用率优化实践》，以下是分享内容！
陈泽龙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实现在线推理服务，向用户提供通用的模型推理接口调用。
随着接入业务模型的增多，发现以下几个问题：
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使用率有效提升。
四、提升平台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进行集成。
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%。
关注“58技术”公众号——关于我们——添加小秘书微信（jishu-58）备注“58同城深度学习平台资源使用率优化实践”即可获取。