KuAI 平台 | 模型在线推理系统的高可用设计

摘要

随着大数据技术和人工智能技术的发展，越来越多的业务场景，如金融风控、在线广告、商品推荐、智能城市等，采用大量的机器学习技术来提升服务质量和智能决策水平。针对具体的任务，训练得到模型后，需要将其封装、部署上线，提供在线推理服务，解决实际业务问题。

本文提出一种分布式机器学习模型在线推理系统的完整技术方案，该系统主要采用 CPU/GPU 计算节点来提供推理任务的基础算力，通过 Docker 容器技术封装、打包模型推理任务，将不同服务的运行环境完全隔离，并借助 Kubernetes 进行服务编排，提供服务的分布式容灾和资源的弹性伸缩功能，同时结合模型仓库、容器镜像仓库、系统/服务状态监控、服务注册/订阅、可视化面板等功能模块使算法模型与服务架构解耦，使模型的部署上线、更新和管理流程变得简单，上线效率高、风险低，同时提高预测服务的稳定性、灵活性和服务能力。

模型在线推理服务部署的技术回顾

1. 现有的技术方法

将模型部署为在线推理服务，当前存在一下几种技术方法：

① 直接在物理机器上部署。将训练好的模型文件及对应的推理代码借助 Flask、Tensorflow Serving 等封装为 Web 服务包，拷贝至物理机器，启动部署。一个物理机器上可能部署一个或多个模型服务。然后将服务接口和调用方式通过文档的形式提供给模型服务调用方法。

② 在虚拟机上部署。先将物理机器通过 vmware、virtual box 等虚拟化技术划分为多个虚拟机，然后将训练好的模型文件及对应的推理代码借助 Flask、Tensorflow Serving 等封装为 Web 服务包部署至一个或多个虚拟机上。每个虚拟机上一般只部署一个模型服务，以避免资源冲突。为解决大规模并发请求，会启用多个虚拟机和模型服务，通过负载均衡技术将请求流量分转发至多个机器。最后将统一的对外服务接口和调用方式通过文档的形式提供给模型服务调用方法。

2. 现有技术存在的问题

① 由于机器学习模型运行的软件环境、依赖基础库及版本多样，不同模型之间存在差异，部署不同的模型都需要搭建一次基础环境，存在重复工作，且可能与模型训练时的环境不一样，导致运行异常。

② 直接在物理机器上部署多个机器学习模型服务时，虽然可以通过 Conda 等工具创建虚拟软件环境的方式隔离多个服务的基础环境，但多个服务之间会存在资源冲突，影响服务的稳定性。另外，服务均为单实例部署，不能保证模型服务的高可用性。

③ 在虚拟机上部署同样存在基础环境重复搭建问题。另外，为应对大规模服务请求情况，往往配置较高的虚拟机数量和硬件规格，而大多数服务的调用量往往会随着业务的涨落而涨落，经常出现类似白天高、夜间低的现象，导致硬件资源在调用量较低期间使用率低，造成资源浪费。

④ 模型推理的准确性由于数据分布的漂移在一定时间后需要重新训练模型，更新线上服务，当前的部署方式需要人工选择某个版本的模型文件、上传，替换线上的模型文件，根据模型服务封装方式的不同，可能还需要重启服务，导致线上服务中断。另外，该更新过程需要人工操作、无法自动化，且过程繁琐、缺乏统一管理和追踪，容易出错。

高可用模型在线推理系统的设计

1. 总体设计思路

① 基于容器技术，通过预置模型服务的执行环境和容器镜像，支持 Scikit-learn、Tensorflow、PyTorch、Keras、Caffe、MXNet 等多种模型框架和基础环境，无需重复搭建机器学习模型运行的软件环境。

② 基于开源 Kubernetes 技术和自研插件，构建 Kubernetes 集群，对 CPU 异构集群、GPU 异构集群、Ceph/HDFS 存储服务等基础资源进行隔离和合理的分配、调度，为模型服务提供高可用的运行时环境，将计算节点集群化，提供全系统容灾保障，无需担心单点故障。

③ 基于模型在线推理服务资源的弹性扩缩容方法，基于模型服务的资源使用率实时监控指标和期望资源计算公式进行动态的扩展或回缩调整，既保证模型推理服务的资源需求，又减少资源的闲置浪费。

④ 基于模型自动化的模型筛选方法和策略模板，对线上模型服务的更新升级方式进行可视化的配置，使过程变得灵活简单，且减少人工操作。

2. 系统架构设计

高可用模型在线推理系统的架构图如下：

图 1 机器学习模型在线推理系统架构图

该系统包含的各功能模块的设计以及模块之间相互协作关系如下文所述：

（A）模型在线服务设计器 ：用户需要将训练好的机器学习模型部署为在线服务、对用户请求服务传递的数据进行推理时，通过该系统可视化界面进行相关配置。

配置内容包括：1）服务名称、服务类型(无状态服务、有状态服务)、服务升级策略等；2）从（B）模型仓库中选择需要部署为在线推理服务的模型及对应的版本；3）从（C）容器镜像仓库中选择模型在线推理服务运行的容器镜像，例如安装好Scikit-learn、Tensorflow、PyTorch、Keras、Caffe、MXNet等基础算法库、依赖包；4）配置服务运行所需的硬件资源(CPU/GPU/内存/存储等)的需求范围和分布式实例的数量范围；5）模型在线推理服务的输入/输出参数等等。

（B）模型仓库 ：指模型构建人员基于不同的框架针对具体机器学习任务训练好的模型文件及模型元数据信息的管理仓库，提供模型的版本管理、模型元数据信息的预览对比、模型的多维度分类、排序、搜索等功能。可将模型仓库的任意版本模型部署为批量离线服务或实时在线服务或发布到模型交易市场。

（C）容器镜像仓库 ：主要提供模型训练、模型推理任务等的容器镜像及镜像管理，包括不同硬件平台(CPU/GPU服务器等)上算法模型运行所需的基础算法库、依赖包等软件环境。在（A）模型在线服务设计器中设计具体模型在线推理任务时选择相应的容器镜像即可，无需运维重新搭建运行环境。

（D）模型微服务引擎 ：根据用户在（A）模型在线服务设计器中的具体配置，（E）Kubernetes集群调度器依据服务的计算规格配置，利用节点选择器将模型服务调度到指定的目标计算节点上，然后从（B）模型仓库中拉取用户配置模型文件和对应的模型元数据信息以及从（C）容器镜像仓库中拉取用户配置的模型推理服务运行的容器镜像到目标节点，通过Service Wrapper模块将模型算法自动封装为可容器化运行的模型推理服务，最后启动引擎对外提供服务。（D）模型微服务引擎与（E）Kubernetes集群协同配合。

（E）Kubernetes集群 ：指基于开源的Kubernetes和自研适用于机器学习场景的调度插件搭建的生产级别的容器编排系统，用于对（D）模型微服务引擎中的模型推理服务及其配套的资源进行管理。

基于容器技术、自研调度编排技术对（F）基础设施中CPU异构集群、GPU异构集群、Ceph/HDFS存储服务等基础资源进行合理的分配和调度，为模型服务提供高可用的运行时环境。通过标签的方式来管理CPU/GPU异构集群中的计算节点，即将不同的计算节点划分为不同的可用区或组。

在部署模型在线服务时，使用节点选择器将模型在线服务部署至带有指定标签的目标计算节点上。为了保证高可用，每个标签组合的目标计算节点数大于1。从而避免一台目标节点宕机后，调度器还能找到满足条件的计算节点将宕机节点上的在线服务对应的容器迁移到其它计算节点上，从而保证模型在线服务的高可用性。

（F）基础设施 ：包括CPU异构集群、GPU异构集群、Ceph/HDFS存储服务等，为模型推理服务提供基础的硬件资源。

（G）模型服务管理 ：包括模型在线推理服务的服务发布、服务注册、服务发现、服务上下线、服务重启、服务版本管理等。

（H）压力测试/在线服务 ：指将部署上线的模型推理服务进行压力测试或开发给需求方提供模型推理服务的功能模块。压力测试提供json、数据文件、并发请求三种方式对部署的模型推理服务进行长时间或满负荷的运行测试，并生成服务的性能、可靠性、稳定性报告；在线服务是指将模型推理服务的API接口、调用方式及反馈状态相关说明暴露出来，供内、外网请求服务。服务请求经由（I）负载均衡器分发到（D）模型微服务引擎中的各个模型服务实例中。

（I）负载均衡器 ：为每个模型推理在线服务提供自动负载均衡能力，即将（H）压力测试/在线服务中产生大规模请求流量通过负载均衡算法将请求分配到各个计算节点的容器实例中。负载均衡算法采用随机法、轮询法、原地址哈希法、加权轮询法、最小连接数法等。

（J）系统/服务状态监控模块 ：对每个模型服务推理的准确性指标(如面向分类模型的精确率、召回率、F1值、AUC等和面向回归模型的MSE、RMSE、MAE等)、模型推理服务的使用情况以及资源的使用状态进行全方位的采集、存储，并进行不同时间粒度的汇总计算，主要的监控指标包括CPU使用率、GPU使用率、内存使用率、占用存储空间、上下行流量、服务请求数量、服务调用失败/成功数量、服务响应时延等，并计算反应模型服务性能稳定性和可靠性的衍生指标，如TP99、TP9999等。该部分信息一方面是（K）监控面板上进行可视化的基础，另一方面也会反馈给（E）Kubernetes集群，用于指导资源的分配调度和服务的编排。

（K）监控面板 ：将（J）系统/服务状态监控模块中采集、计算的指标进行可视化，方便用户了解模型在线推理服务的状态。

3. 模型自动筛选与更新流程

机器学习模型往往会随着时间的推移进行迭代更新，为保障模型在线推理服务的准确性，需对其进行即时的升级。本文提出一种模型自动化的模型筛选方法和策略，以减少人工操作。具体流程如图2所示。

图2 模型自动筛选、更新流程示意图

用户根据系统提供的多种筛选策略模板，进行策略配置以初始化模型筛选器，模型筛选器对（B）模型仓库中的每个模型及其不同版本的元信息进行检测，筛选出符合策略所定义要求的模型文件，然后由（D）模型微服务引擎对模型在线推理服务在合适的时段(如（J）系统/服务状态监控模块监测到的服务调用量较低的时段或用户自定义的时段)进行更新。

具体地，本文提出以下5种模型筛选策略模板：

① 由上游数据驱动的模型更新，即筛选出该驱动事件对应的模型；

② 模型推理准确性指标下降或低于一定阈值事件驱动的模型更新，即筛选出该驱动事件对应的模型，模型推理准确性指标由（J）系统/服务状态监控模块监测模块反馈，见图1；

③ 定期从当前众多版本中筛选出模型性能评估指标(可以是用户定义的加权指标，下同)最优的一个模型；

④ 定期从当前众多版本中筛选出模型性能评估指标在一定阈值之上的最新迭代的一个模型；

⑤ 人工手动指定的模型版本。

4 . 资源弹性扩缩容方法

大多数模型在线推理服务的调用量往往会随着业务的涨落而涨落，经常出现类似白天高、夜间低的服务请求量波动现象，一方面导致硬件资源在调用量较低期间使用率低，造成资源浪费，另一方面当用量过大时可能影响服务的稳定性和可用性。本文提出一种模型服务资源的弹性扩缩容方法，既保证模型推理服务的资源需求，又减少资源的闲置浪费。具体流程如图3所示。

图3 模型服务资源弹性扩缩容流程示意图

当模型在线推理服务成功部署上线后，（J）系统/服务状态监控模块实时监测、计算该服务各容器实例的资源使用率等指标，如CPU使用率、GPU使用率、内存使用率、响应时延等，并进行不同时间粒度的汇总计算。

对上一个时间窗口内资源使用率指标，采用本文提出的容器实例数量计算公式或用户定义自定义的公式进行计算，得到下一个时间窗口内期望的容器实例数量，然后借助Kubernetes中的横向自动扩缩容的功能（HorizontalPod Autoscaling，简称 HPA），自动化地调整容器实例数量，然后（J）系统/服务状态监控模块继续实时监控更新后各容器实例的资源使用率等指标，以此循环，实现模型在线推理服务资源的动态调整。

期望的容器实例数量计算公式如下所示：

式中，分别为CPU使用率、GPU使用率、内存使用率、响应时延4各衡量维度的权重因子，取值范围为[0,1],总和为1，用户可自行调整，也可以调整时间窗口的大小。ceil表示向下取整。另一方面，用户也可以基于（J）系统/服务状态监控模块提供的其他指标完全自定义期望的容器实例数量计算公式。

总结

（1）本文提出了一种分布式机器学习模型在线推理系统的完整技术方案，通过Docker容器技术封装、打包模型推理任务，将不同服务的运行环境完全隔离，并借助Kubernetes进行服务编排，提供服务的分布式容灾和资源的弹性伸缩功能，同时结合模型仓库、容器镜像仓库、系统/服务状态监控、服务注册/订阅、可视化面板等功能模块使算法模型与服务架构解耦，使模型的部署上线、更新和管理流程变得简单，上线效率高、风险低，同时提高预测服务的稳定性、灵活性和服务能力。

（2）本文提出了一种模型自动化的模型筛选方法和策略，提出了5种模型筛选策略模板，使线上模型服务的更新升级变得灵活简单，且减少了人工操作。

（3）本文提出了一种模型在线推理服务资源的弹性扩缩容方法，基于模型服务的资源使用率实时监控指标和期望资源计算公式进行动态调整，既保证了模型推理服务的资源需求，又减少了资源的闲置浪费。

本文转载自公众号京东数科技术说（ID：JDDTechTalk）。

原文链接：

KuAI平台 | 模型在线推理系统的高可用设计