方阳：贝壳找房推理服务 MLOPS 实践
分享嘉宾：方阳 贝壳 架构师
编辑整理：袁文鑫 趋动科技
出品平台：DataFunTalk
导读： 随着AI应用普及，大量AI算法开始在企业各类业务场景中落地。如何在高效利用GPU资源同时，结合企业内部业务流程构建完善工具链来保障企业各类AI应用从模型开发、训练到上线部署，成为企业IT基础架构部门面临的一项重大挑战。MLOps作为DevOps在机器学习以及数据工程这些特定领域的拓展，它贯穿开发、实验与部署的整个过程，是机器学习规模应用及算法工程化的重要实践手段。贝壳机器学习平台从2019年下半年开始进行系统化建设，目标成为AI应用敏捷构建一站式平台，服务于公司内部多个算法团队，2021年底我们紧跟行业发展趋势，结合实际业务需要尝试落地MLOps。
今天的介绍会聚焦在MLOps在贝壳推理平台上的实践，围绕下面三个方面展开：
- 贝壳机器学习平台概况
- 推理服务MLOps实践
- 推理服务未来规划
01 贝壳机器学习平台概况
贝壳机器学习平台从2019年下半年开始进行系统化建设，整个机器学习平台的目标定位为AI应用的敏捷构建一站式平台。整个平台建设发展路径如果类比到自动驾驶技术的发展分级，希望平台能力可以从L2级（部分自动化）逐步进化到L4级（全流程自动化）。我们认为机器学习平台算力是第一生产力，因此围绕算力，平台建设从以下三个方面开展：
- 数据平台（算得准）
- 训练平台（算得快）
算法研究员希望在训练平台上更快产出模型，缩短训练周期，提升平台整体浮点运算吞吐，降低多卡之间延迟等是关键。
- 推理平台（算得省）
降低平台整体TCO，因为推理服务往往对于资源消耗是大头。
1. 贝壳推理服务平台简介
目前贝壳推理服务平台已经有近2000个推理实例，服务于OCR、人脸识别、ASR、NLP、推荐等算法团队，推理资源池有近250台服务器，分为GPU推理服务资源池和CPU推理服务资源池，其中GPU推理服务资源池有200块GPU卡（主力为T4）用于推理，CPU推理服务资源池有约10000核CPU，相比2021年中，推理服务平台资源整体增速达50%以上。
机器学习平台整体架构如下：
① 物理基础设施层
- 平台整体计算能力由GPU、CPU等异构算力组成。
- 数据传输网络使用RDMA/RoCE技术降低网络延时，提高吞吐。
- 数据存储使用高性能网络文件存储及Cache加速提高整体IOPS。
② 资源调度层
平台架构已经全面转向K8S，结合容器技术实现平台对资源的管理和调度的优化。
③ 深度学习业务支撑层
包括参数服务器，弹性推理服务。推理服务也实现了高可用和弹性伸缩能力。
④ 业务场景
目前平台已实现对开发实验、离线任务及在线服务多业务场景支撑，其中离线任务包括训练任务和离线批预测任务。
具体到推理服务平台，平台架构包含模型仓库，容器镜像仓库，模型微服务引擎，负载均衡等组件，整体架构如下所示：
2. 推理服务平台技术演进
① 降低TCO
推理服务平台在建设实践上聚焦“算得省”，主要从如下三个方面着手降低TCO：
- GPU虚拟化及单卡多任务调度
单个推理实例往往用不满单卡提供的算力或者显存，以显存资源为例，典型推理实例资源需求为2G，而如今单张A30卡可提供显存资源最大可达24G，如果使用MIG进行切分，资源浪费情况严重。贝壳在阿里gpushare和腾讯qGPU技术的基础上实现GPU卡虚拟化及其调度。
- 模型优化
对模型进行优化提高吞吐，再结合虚拟化技术可降低整体GPU卡数量需求。
我们对比了不同产品，openvino在cv类模型有优势，与intel 6系及以上CPU配合效果更佳，但其通用性一般；tensorRT个别模型性能提升达2倍以上，但通用性差；某云厂商，80%以上模型可优化使用性能提升60%以上，且通用性好，不足是黑盒。
- 推理卡及推理CPU
适配推理卡和推理CPU，我们尝试通过使用Intel 6系及百度昆仑、华为昇腾等推理卡降低资源池内GPU的使用比例，降低整体TCO。
② 云原生演进
推理服务平台技术架构20年上半年完成了Hadoop向k8s的转型，通过三个阶段的迭代实现了平台整体云原生改造：
- 引入Docker解决软件环境标准化
- 引入K8s解决服务高可用及编排
- 引入istio进行微服务改造及流量管理、追踪
③ CI/CD工作流建立
通过开发推理服务客户端工具，实现了和贝壳云的打通，解决了平台在域名申请、日志接入和基础监控接入方面的一些问题。
3. 推理服务平台建设总结与反思
贝壳推理服务平台的建设总体围绕算得省，结合团队自身技术专长在系统平台建设本身上做了不少工作，但是在日常运维和客户走访的过程中，我们也意识到了另外一些问题，比如缺少整体业务流程的打通、自动化程度不高等，这也引发了我们要不要以及如何开展MLOps工作的思考。
02 推理服务Mlops实践
1. MLOps理解认知
讲到MLOps，不得不提DevOps的关系与区别。DevOps是面向IT运维的工作流，以持续集成（CI）、持续部署（CD）为基础，来优化开发、测试、运维等环节。它的好处与价值在于，开发流程高效自动化，问题定位与调试简单，交付周期短且质量有保障。有一点容易被忽视的是，DevOps是一种组织文化与制度。我们首次接触MLOps是2021年7月份外部嘉宾的一个关于AI测试主题分享会，听完之后一个理解是各种ops本质是一系列的op加上触发器与流程跳转。
相比于DevOps，随着时间推移导致的模型衰减，机器学习天生具备迭代性，而且MLOps内容更多更复杂，实现也会更加困难。MLOps广义上涵盖整个机器学习应用开发全生命周期，狭义上类似DevOps聚焦在较短的交付周期内对推理服务部署的效率和质量进行保证。
以上图为例算法研究员在开发、实验之后产出模型，模型经过评测合格后通过CI/CD工具链完成部署上线，随后平台对模型持续监控，当模型发生衰减后，根据之前积累的元数据（数据集、模型方法、超参等）重新进行训练，称之为持续训练，产出模型经过评测合格后重新部署上线。
2. MLOps@贝壳
贝壳从推理切入落地MLOps，最终实现全周期广义MLOps。MLOps在推理服务落地一方面解决当前推理平台接入成本高，日志、运维等工具自动化程度低等问题，另一方面，可以帮助算法团队提高模型算法部署效率，缩短模型服务部署迭代周期。
面向算法团队工程团队、工程人员及算法QA的平台产品DevOps版AiStudio于2021年底开始研发并于2022年1月完成产品原型和用户case落地。同时，面向算法研究员以及算法工程师的平台产品是全周期版本AiStudio，可以满足从开发实验、数据准备、训练、评测到推理部署等机器学习开发各个环节的需求。
在推理服务端，我们围绕模型流转，对模型仓库进行迭代升级，增加版本管理、权限管理等能力，同时打通算法QA评测平台，结合公司业务流程建设一个模型部署的持续集成和持续部署的自动化工具链，制定与推进贝壳推理服务开发，测试，发布流程的标准化和规范化。
上图是我们语音团队的模型服务构建部署流程，如图所示，解码封装模型文件，测试部署，触发模型评测，产生测试报告，模型评测是一个QA介入的强管控环节，不合格不能进行后续部署。
03 推理服务未来规划
回顾贝壳推理服务平台的发展过程，推理服务平台建设一直是被业务发展驱动，专注于平台能力本身，以满足各业务方相关需求。未来贝壳推理服务的规划将从以下四个方面展开：
- CI/CD
持续完善CI/CD，在前处理、后处理及推理服务DAG等方面实现功能更新迭代。
- 微服务治理
完善模型流量控制和路由机制。
- 模型优化
围绕业务和成本控制展开持续优化相关模型。
- 模型监控
模型监控作为服务部署完成后比较容易忽视的环节，但却是模型发生衰减后触发整个MLOps流程进行持续训练，持续交付的起点与关键，会投入更多的精力。
04 问答环节
Q：GPU虚拟化如何解决资源碎片化问题的？
A：我们GPU虚拟化只在两种场景下应用，一个是虚拟开发机，一个是小尺寸推理任务的部署应用。
Q：GPUshare是如何做到资源隔离的，是几个Pod共用一个GPU资源么？
A：其实我们不认为这个是GPU虚拟化，GPUshare并没有做到GPU资源的隔离，我的理解它更像一个单卡多任务的调度功能，今天真正能做到隔离的是MIG，但是最小切分尺寸还是太大。
Q：模型引擎是自研的还是引入的框架？
A：模型引擎使用的是tfserving或者Triton server等。但我们会结合内部业务需求做一些Pipline的构建和自定义开发，包括模型文件拉取、模型文件版本管理、服务拉起及流量控制等。
Q：可以分享一下在推理服务实践过程中遇到的一些经典问题么？
A：我们针对去年多次故障复盘总结发现，整个推理服务的流程化和标准化是在技术实践背后更加需要解决的问题。例如在业务先行的大背景下，各项业务能力在版本迭代过程中，如何和各团队进行技术架构拉齐，统一部署流程，需要从全局上做一些约束与规范。
Q：MLOps有无好的开源框架推荐？
A：目前没有看到好的全周期开源框架解决方案，已开源的MLOps工具往往会关注MLOps中的某一个或者某几个点，比如数据版本管理、推理服务发布CI/CD等。
Q：采用k8s替换Hadoop的原因是什么？
A：一方面很多机器学习相关系统选择k8s作为底座，我们会看到很多工作是围绕k8s以及云原生展开的，另一方面我们也在做K8S和Hadoop的架构融合，没有放弃Hadoop生态。
Q：使用kubeflow了么？
A：没有，kubeflow一方面资源使用太重，另一方面由于项目太多，质量不太可控。
分享嘉宾：
