MLOps在网络智能化领域落地实践

导读 本次分享的题目是MLOps在网络智能化领域落地实践。

主要介绍：

1. 九天网络智能化平台

2. AI工程化落地探索

3. MLOps 技术选型4. MLOps 思考
5. 问答环节

分享嘉宾｜梁晓扬 中国移动通信集团有限公司 九天网络智能化平台产品线 产品线CEO

编辑整理｜徐建峰

内容校对｜李瑶

出品社区｜DataFun

---

01

九天网络智能化平台

1.体系化人工智能的核心引擎：九天

中国移动成立专门的人工智能团队，建设了全面的九天人工智能产品体系，发布了8个平台性产品，包括九天深度学习平台、九天 AI 能力平台等等。其中，九天深度学习平台封装了一些深度学习框架提供建模的能力，九天 AI 能力平台用于通用AI能力的发布，其它的产品，如“九天网络智能化平台”等都是基于上述两个基础平台，面向细分领域的产品落地。比如“九天·毕昇教育平台”用于教育行业，“九天智能交互平台”为互联网电视做推荐。。

基于这8个平台性产品，“九天团队”总共发布了300多项核心能力，通过接口调用等多种形式为多个领域提供服务，如个人领域中“10086”机器人客服、家庭领域中电视内容推荐等。“九天”产品已服务超过10亿用户，规模化应用达40余个，赋能价值逾40亿。

2.网络智能化

在中国移动研究网络智能化有以下背景：

• 全球最大的移动网络运营商：中国移动已经是全球最大的移动网络运营商；

• 运维人员10万+：中国移动运维人员总数已达到10万以上，运维成本相当高；

• 网络场景专业化、个性化：5G 网络切片技术带来的网络服务专业化、个性化需求；

•  1+31天然的云-边需求：不同省份基站的网络基础设施建设程度不一样，对网络业务指标的要求也不一样，再加上数据安全的要求，对采用分布式架构构建的网络智能化平台提出了“云-边”差异化推理的需求。

3.九天网络智能化平台

为解决上述需求问题，我们开始探索网络智能化。2017年，在某省级移动公司开展了智能定位定界研究。2018年至2019年，我们将智能化能力和应用拓展到无线网络故障处理、无线智能优化、智能调度以及运维知识图谱等应用，研发了20余个AI能力。在应用不断增加过程中，遇到了“1+31”式的场景问题，如为某省开发的应用，要满足在其他省份部署应用的需求，要考虑产品通用性、可移植性等。为此，我们搭建了网络智能化平台，将能力放在能力商店里面，使得某地开发的AI能力，其他地方的用户也可在商店中订阅使用。2020年，该平台在浙江开始部署试点，2021年开始商用。目前作为中国移动自智网络的智能引擎，实现了全网集中建设，支撑了全国31个省份的生产调用。在解决了AI能力的全网使用问题后，我们又面临场景化、本地化的问题，即不同的地区其应用场景或环境是不一样的，包括人员密集度、用户习惯等等，那么如何使得通用的应用能快速适配使用地区的环境，并保证有好的推理效果呢？

此外，还有研发管理的相关问题，AI应用开发相关人员有算法工程师、后端工程师、前端工程师、需求分析师、运维工程师等等。日常工作流程中，用户提出需求，算法工程师对数据开展特征处理、算法选择和模型训练等，然后后端工程师再做进一步工程化处理，最后由运维人员去部署实施，这通常会带来开发部署周期长的问题，以及由于不同角色人员各自工作的割裂，导致缺少一个角色对整体的工作负责的问题等。

4.九天网络智能化平台-功能架构

为此，我们参考DevOps的概念，探索通过MLOps来解决上述问题。上图是我们平台的总体功能架构，可分为网络智能化平台底座和平台服务两个逻辑层次。整个平台的底座是九天基础平台，包括模型训练、模型推理和数据标注等基础功能。网络智能化平台基于这三大基础功能，向上层提供统一的基础服务：

• 数据工厂，提供数据安全、数据治理、数据集管理服务；
•  能力工厂，提供能力研发、能力推理、能力管理等服务；
• AI综合应用，提供应用开发、能力编排等服务；
• 支撑服务，提供数据运营、用户中心等支撑类服务。

四大类平台服务：

• 数据服务：平台的设计目标和核心价值就是让数据的使用更加便捷，面对全国各地的数据资源和服务需求时，无需上层能力每次都要做对接。
•  训练服务，通过“线下训练+线上完善”的方式，加速推进能力研发。
• 推理服务，解决两大需求，一个是调用的高效稳定，另一个是资源的最大化利用。
•  管理服务，主要是解决能力在不同地区的建设发布和推广应用以及能力运营的问题。

5.九天网络智能化平台-技术架构

整个平台的技术架构是“云原生+SpringCloud”，自底向上可分为云平台、资源管理层、基础设施层、平台服务层、业务服务层、微服务管理及用户接口层：

• 云平台：最底层是云平台，然后基于云平台创建了虚拟机、本地存储和共享存储，实现了平台内部设备间的高速网络连接，以及 CPU、GPU 的虚拟化；
• 资源管理层：基于云平台基础资源搭建了 Kubernetes（K8S）原生集群、磐基平台和九天能力平台。资源管理层基于通用 SPI 接口向上提供 AI 服务，并实现跟上层应用的隔离；
•  基础设施层：基础设施层主要包括 MySQL、MongoDB、Redis、ES 等各类数据资源管理应用组件；
• 平台服务：主要包括鉴权、工单等基础服务，以及支持 MLOps 的 Web IDE、Web terminal、在线测试、在线试用等功能模块；
• 业务服务层：主要是向上层应用提供全生命周期管理服务，包括能力中心、部署管理、模型管理、数据管理、漂移检测、推理反馈等。
•  微服务管理及用户接口层：核心业务服务由微服务注册和发现中间件Nacos提供注册管理服务，并通过微服务网关响应用户侧的请求访问。

平台基于 DDD（领域驱动设计）思想，划分为两大核心领域服务：能力中心和部署管理，构建了与底层隔离的能力域和实例域。能力域中时模型是静态的，它定义了平台无关的行为，如支持 AI 能力在能力商店发布，实例域中则定义了能力的运行态行为。的行为。

6.九天网络智能化平台部署架构

基于云边协同的部署架构中，中心节点负责能力服务的注册管理，各省的能力服务部署在边缘业务集群上。用户要访问能力服务时，通过边缘网关向中心节点申请获得访问令牌，经能力服务所在边缘网关的校验后，即可访问所需的能力服务。相关能力服务的运营数据，会向中心节点汇聚，进行统一展示。

02

AI 工程化落地探索

行业内有句话道出了 AI 工程化落地的问题：发布一个机器学习模型看似简单，但在生产环境中部署应用却是众所周知的困难。为解决 AI 工程化落地问题，我们进行了如下探索。

1.AI工程化过程中问题&解决方案

AI 工程化过程中的主要问题包括：

• 能力研发周期长，经过需求分析、数据准备、线下训练、能力封装、发布测试等项目流程后，研发周期往往会超过3个月，研发周期过长通常导致产品因未及时响应市场的变化而失去价值。
• 各角色人员知识不共享，相较于传统行业，AI项目中，前端、后端、算法等各类工程师一般只关注各自份内工作，缺乏知识共享，致使开发的产品上线用于实际生产环境后，出现一些啼笑皆非的问题。
• 能力上线后模型不通用，模型训练完成后，不是一劳永逸的，在一个省份效果良好的模型在其它省份上线运行效果会变差，需要不断在线更新。
• 能力上线后模型优化不及时，模型效果变差的另一个原因是优化不及时，现实中模型能力的劣化，一般难以及时发现，往往都是在用户投诉后才知道。
• 云-边模型不一致，最初为某个省研发的能力，如果在全国30多个省份部署使用，就需要考虑模型版本的统一管理，如果没有良好的版本控制，就会导致版本混乱，不利于问题定位以及模型优化，也造成故障处理时的人力资源浪费。

在解决上述问题时，我们充分吸收借鉴了业界一些好的做法，如我们试用了支持模型一键发布的英伟达 Triton 框架，并基于该框架思想自研了模型发布框架，部分解决了研发周期长的问题。通过研发团队人员的培训考试，解决各角色人员知识不共享的问题。通过模型的在线更新，解决上线后模型不通用的问题。通过制定实施能力运营规范，解决云-边模型不一致的问题。

2.我们的探索

接下来，分别介绍一下我们的探索历程，首先我们基于英伟达 Triton 推理框架自研的前端，Triton 推理框架包括流程编排（推理队列调度器）、模型定义（模型管理）、优化处理和后端管理等，它定义了统一的数据模型，通过定义一套数据接口实现跟各类机器学习框架数据模型的转换，用户在使用过程中屏蔽 Pytorch、Tensorflow 等框架数据模型的差异，我们基于此开发了一个前端界面，用图形化的方式实现数据模型的转换，减少接口方式调用时的开发难度和工作量。

由于英伟达 Triton 推理框架较重，占用存储较多，不利于商用部署，且我们仅使用了该框架的部分功能，所以我们选择基于英伟达 Triton 推理框架，自研更适合我们自己的模型封装管理的轻量级工具，以实现AI模型的定义、训练、发布以及数据模型的转换。但自研框架的推广应用并不顺利，平台团队以外的用户（模型开发工程师）学习掌握这套框架，需要额外的培训学习成本，工作效率并未得到显著提升，用户认可度不高。于是，我们换个思路，从解决用户（模型开发工程师）的痛点出发，研究提供用户需要的在线 Web IDE、函数模块及辅助支持工具等。。

这部分是关于模型调度的探索研究，目前我们平台的算力资源虽然 CPU 达到了1万多核，以及大量的 GPU，但在实际应用中仍然非常紧张。基于K8S或网关调度时，资源分配是基于用户请求的，没有按照算法对 CPU、GPU 等资源的实际需求来分配资源，调度策略比较粗放，导致资源利用率不高。为此，我们从支持个性化调度出发，首先会同算法工程师对 LSTM、XGBoost 等算法进行逐个分析，对算法需要的 CPU/GPU、内存等资源进行评估，确定模型中资源分配权重。同时，我们定义了一套元数据描述平台各个节点支持的算法和负载等，并在启动时上报到 Nacos 的 metadata 中。当用户请求到达时，我们通过资源调度服务中心将请求服务对应的算法及其资源需求与节点元数据进行匹配，实现了资源的最大化利用。             

关于模型在线更新的探索，不同省份模型的推理框架可能是一样的，但使用环境通常是不同的，在做模型管理时要支持模型经训练后在其他省份使用，更新时不影响模型在其他地方的使用等等。要考虑的因素很多，解决此类问题比较简单，我们只需要将推理代码管理和模型挂载分开（位于共享存储上）即可。

最后是关于人的问题，前端、后端、算法工程师知识不共享的现象在很多的系统平台项目建设中存在，不是项目成员不愿共享，更多是由于对彼此工作内容及要求的认知差异、工程师自身专业素养和能力的不同等因素造成，算法工程师要开发好的模型，需要了解应用部署时的性能需求和业务需求，后端工程师要想做好平台，对算法的特性也要了解。为此，我们通过算法和后端开发定期交流、对算法人员进行编程规范等培训、性能优化培训，后端开发人员加强算法知识学习等，以解决平台工程师间的知识共享问题。

3.AI 落地生产的必由之路

近年来，MLOps 概念兴起，提出以标准化过程推进高性能模型的持续交付，这也正是我们想解决的问题，于是我们开启了 MLOps 的实践之路。上图是信通院发布的一个标准的 MLOps 管理流程，包括需求管理、数据工程、模型开发、模型交付、模型运营等，这也是迄今为止 AI 模型工程化落地实施的唯一可行路径。

03

MLOps 技术选型

下面介绍 MLOps 相关的技术选型。

1、技术选型决策点

技术选型通常要考虑，商用还是开源；从零开始开发还是选择已有平台，选特定工具还是选择一整套平台等等：

• 开源 vs 闭源
• 平台 vs 特定工具
•  模型和生产环境监控
• 模型模板和编排
•  模型训练、调试和漂移管理
• 流程管理工具

2.模型封装技术选型

模型封装方面的技术选型，首先靠参考的是亚马逊，作为国际领先的云平台厂商，它的SageMaker在漂移检测、模型训练与调试、源代码和版本控制等方面有比较成熟的经验。其次是开源的Kubeflow工作流，它提供了一种方式将用于机器学习的同类最佳开源系统部署到各种基础设施上，使机器学习工作流在 K8S上的部署变得简单。另外一个比较火的框架时Seldon Core，它为不同框架下训练出来的模型（Tensorflow，Pytorch，SKLearn，XGBoost）提供一套相对统一的部署方式，但是该框架比较重，将其嵌入到已有平台中比较难。

3.模型封装/调度技术选型-KServe

还有个做模型封装调度的框架 KServer，它通过为常见的 ML 框架（如：Tensorflow、XGBoost、Scikit-Learn、PyTorch）提供高性能、高度抽象的接口来解决生产模型服务场景，该框架比较适用于采用服务网格（Service Mesh）架构的平台，非服务网格类平台的嵌入该框架代价较大。

4.数据漂移概念

下面是数据漂移检测方面的选型，数据漂移是指模型在生产环境中的数据输入与训练期间提供的训练数据分布不对应。从上图可以看出，当数据发生漂移后，模型也许还能做出一定的分类，但已不是最优结果，数据可能已呈现新的分类特征。

5.模型监控/漂移检测技术选型

模型监控/漂移检测方面的工具中，Alibi Detect 功能强大，支持模型的实时监控，技术成熟且相对容易设置，但如果要使用它，必须在模型封装时使用 Seldon Core 框架。另一个工具是 Evidently，它致力于简化模型监控，是一个开源、与平台无关且友好的 Python 库，能将监控到的数据进行前端界面展示，适用于任何模型服务设置和任何机器学习框架。

6.whylogs

类似的产品还有 Whylogs，它通过 KS 检测、卡方检测等进行数据特征提取，统计分析数据漂移情况，相较于 Evidently 更轻量，它也是我们 AI 工程化的选择。

7.最终技术选型-业务流程

上图是我们最终技术选型的业务流程，首先通过自研的 Web IDE 完成模型的在线开发和训练，然后基于自研的能力管理服务，将 AI 模型封装成服务发布后，用户就可通过平台网关申请调用。平台提供了用于服务封装的 SDK，它支持服务运行时的日志采集，主要采集能力推理的输入、输出和有价值的过程数据。采集的日志数据汇入数据中转站，最终作为历史数据存入安全性更高的数据共享平台。用户对模型推理结果的反馈，也会汇聚进数据共享平台，跟模型服务运行时的日志数据进行融合。平台标注服务定时拉取相关数据，进行模型推理效果分析，将推理效果较好的模型服务通过开放创新平台发布出去，效果不好的进一步完善并重新训练。

8.最终技术选型

我们最终的技术选型是：基于九天平台服务自研的模型封装+自研的能力开发框架+自研的流水线（流程管理）服务+数据标注+whylogs，实现模型封装发布、运行监控及可视化展示，数据标注时的数据解析规则由能力研发方上报。

04

MLOps 思考

最后，是关于 MLOps 的一些思考。

首先，我们要思考的是从流水线输出的能力从测试环境到服务生产的距离，如果通过 MLOps 流水线发布的能力不能直接发布到生产环境，那么 MLOps 也就失去了意义。其次，在做 MLOps 之前，先理顺线下的非自动化的流程，对 MLOps 的成功实施大有裨益。

05

问答环节

Q：针对流量洪峰问题，通过 MLOps 研发的能力，在平台建设时是如何考虑的？

A：平台实现的监控包括了模型推理效果的监控和平台整体能力的监控等，在应对流量洪峰时，我们的网关会首先进行拦截，触发服务限流并产生告警。接到告警后，平台工程师会进一步分析，如果流量来源正常，就会进一步启动服务的弹性伸缩。通过 MLOps 研发的能力只需要做到无状态，支持弹性伸缩即可。

以上就是本次分享的内容，谢谢大家。

分享嘉宾

INTRODUCTION

梁晓扬

中国移动通信集团有限公司

九天网络智能化平台产品线 产品线 CEO

2010年硕士毕业于中南大学计算机科学与技术专业，十余年软件开发、架构和团队管理经验

前中兴通讯研发团队负责人、敏捷技术教练

前 thoughtworks 高级咨询师

现在就职于中国移动通信有限公司研究院，负责九天网络智能化平台产品研发