一种在线模型推理系统的制作方法

本申请涉及分布式存储技术领域，尤其涉及一种在线模型推理系统。

背景技术：

随着大数据技术和人工智能技术的发展，越来越多的业务场景，如金融风控、在线广告、商品推荐、智能城市等，采用大量的机器学习技术来提升服务质量和智能决策水平。针对具体的任务，在模型指定的训练环境中训练得到模型后，需要将其封装，再将模型部署为在线推理服务，当用户使用与训练环境相同的运行环境时，即可使用该推理服务。

但是在实现本发明过程中，发明人发现随着推理服务需求量增加，需要部署的推理模型种类增多，容易出现推理模型的训练环境与用户的运行环境不同，造成部署推理模型上线后进行在线推理服务运行错误的问题。

技术实现要素：

为了解决上述技术问题或者至少部分地解决上述技术问题，本申请实施例提供了一种在线模型推理系统。

第一方面，本申请实施例提供了一种在线模型推理系统，所述系统包括：模型仓库、容器镜像仓库、服务设计器以及模型微服务引擎；

所述模型仓库，用于存储推理模型和所述推理模型的元数据；

所述容器镜像仓库，用于存储所述推理模型运行所需的容器镜像；

所述服务设计器，用于接收用户对待对外提供在线推理服务的推理模型的配置信息；

所述模型微服务引擎，用于按照述配置信息在容器镜像仓库中拉取容器镜像、从所述模型仓库中拉取推理模型及元数据；以及，将所述推理模型、元数据和容器镜像进行封装，得到为可容器化运行的模型推理服务，以对外提供在线推理服务。

可选地，所述系统还包括：服务状态监控装置；

所述服务状态监控模块用于确定所述模型微服务引擎中的各个用于搭载推理服务的容器实例的cpu使用率、gpu使用率、内存使用率、响应时延以及容器实例数量；以及，计算所述模型微服务引擎中的所述推理服务的准确性指标。

可选地，所述系统还包括：容器编排器；

所述容器编排器用于根据所述cpu使用率、gpu使用率、内存使用率、响应时延以及推理服务数量计算期望容器实例数量，并依据所述期望容器实例数量对所述模型微服务引擎中的容器实例进行增加/删减。

可选地，根据所述cpu使用率、gpu使用率、内存使用率、响应时延以及推理服务数量计算期望容器实例数量的公式如下：

其中，α、β、γ、δ分别为cpu使用率、gpu使用率、内存使用率、响应时延4个衡量维度的权重因子，取值范围为[0,1],总和为1，ceil表示向下取整。

可选地，所述模型微服务引擎中包括：模型筛选器；

所述模型筛选器用于根据配置信息确定筛选策略，并按照所述筛选策略从所述模型仓库中拉取符合所述筛选策略的推理模型。

可选地，所述配置信息包含下列五种模型筛选策略中的任一种；

第一筛选策略：根据所述配置信息确定用户所需的目标数据信息，根据所述目标数据信息确定目标推理模型；

第二筛选策略：从服务状态监控模块获取多个所述推理模型的准确性指标，从多个所述推理模型选取准确性指标最高的推理模型，得到目标推理模型；

第三筛选策略：获取相同类型不同版本的多个所述推理模型的性能评估指标，从多个所述推理模型中选取性能评估指标最高的推理模型，得到目标推理模型；

第四筛选策略：获取相同类型不同版本的多个所述推理模型的性能评估指标，利用所述性能评估指标高于阈值的推理模型更新迭代出目标推理模型；

第五筛选策略：根据所述配置信息确定用户指定的推理模型标识，根据所述推理模型标识确定目标推理模型。

可选地，所述服务设计器中包括：压力测试/在线服务模块；

所述压力测试/在线服务模块用于对所述模型微服务引擎中的推理服务进行压力测试，生成测试结果；以及，接收用户的推理服务请用请求。

可选地，所述在线模型推理系统还包括：负载均衡器；

所述负载均衡器用于将所述用户的推理服务应用请求分配至所述模型微服务引擎的容器实例中，以使所述容器实例中部署的推理服务响应所述用户的推理服务应用请求。

可选地，所述设计器中包括：监控面板；

所述监控面板用于采集服务状态监控模块中的存储数据，并依据预设的计算方式对所述存储数据进行计算得到监控指标，以供用户查看。

可选地，所述系统还包括：模型服务发布管理模块；

所述模型服务发布管理模块用于将管理所述模型微服务引擎中的推理服务的上线、下线、注册、发现、发布、重启以及管理功能。

本申请实施例提供的上述技术方案与现有技术相比具有如下优点：本申请实施例通过建立模型仓库和存储有推理模型所需的容器镜像的容器镜像仓库，当接收用户的在线推理请求时，根据用户的配置信息使模型微服务引擎从模型仓库调取用户需要的推理模型，并从容器镜像仓库容器镜像，避免训练模型所需容器镜像与实际容器镜像不一致的情况，进而能够将推理模型封装为可容器化运行的推理服务，提供在线推理服务。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种在线模型推理系统结构示意图；

图2为本申请实施例提供的另一种在线模型推理系统结构示意图；

图3为本申请实施例提供的另一种在线模型推理系统结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请的一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

目前，随着大数据技术和人工智能技术的发展，业务场景的增加，采用大量的机器学习技术来提升服务质量和智能决策水平。针对于机器学习模型运行环境，发明人在研究过程中发现以下问题：由于机器学习模型运行的软件环境、依赖基础库及版本多样，不同模型之间存在差异，部署不同的模型都需要搭建一次基础环境，存在重复工作，且可能与模型训练时的环境不一样，导致运行异常。

目前现有技术主要是通过直接在物理机器上部署多个机器学习模型服务时，虽然可以通过conda等工具创建虚拟软件环境的方式隔离多个服务的基础环境，但多个服务之间会存在资源冲突，影响服务的稳定性。另外，服务均为单实例部署，不能保证模型服务的高可用性。总而言之，随着用户需求的推理服务需求量增加，需要部署的推理模型种类增多，容易出现推理模型的训练环境与用户的运行环境不同，造成部署推理模型上线后进行在线推理服务运行错误的问题。基于此，本发明实施例首先提供了一种在线模型推理系统，如图1所示，所述系统包括：模型仓库01、容器镜像仓库02、服务设计器03和模型微服务引擎04；

所述模型仓库01，用于存储推理模型和所述推理模型的元数据；

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

其中，推理模型是指机器学习模型，推理模型的元数据是指推理模型的配置参数，例如元数据中可以包含推理模型指定的容器镜像，或者包含推理模型输出的数据类型等等与推理相关的参数信息，具体包含内容可以根据实际情况而定，本发明实施仅为示例，不作具体限定。

所述容器镜像仓库02，用于存储所述推理模型运行所需的容器镜像；

在本发明实施例中，容器镜像仓库02是指用于提供模型训练、模型推理任务等的容器镜像及镜像管理的数据库，在容器镜像仓库02中包含不同硬件平台(cpu/gpu服务器等)上算法模型运行所需的基础算法库、依赖包等容器镜像(即推理模型运行所需的环境)。

所述服务设计器03，用于接收用户对待对外提供在线推理服务的推理模型的配置信息；

在本发明实施例中，服务器设计器是用于接收用户输入的配置信息，其中，配置信息是指用户在该系统中选择上线服务的推理服务时输入的信息，在实际应用中配置信息可以直接指定选用的推理模型，或者用户只输入需要计算的数据。

所述模型微服务引擎04，用于按照述配置信息在容器镜像仓库02中拉取容器镜像、从所述模型仓库01中拉取推理模型及元数据；以及，将所述推理模型、元数据和容器镜像进行封装，得到为可容器化运行的模型推理服务，以对外提供在线推理服务。

在本发明实施例中，模型微服务引擎04可以通过用户输入的配置信息从容器镜像仓库02中拉取容器镜像、从所述模型仓库01中拉取推理模型及元数据，具体的，若配置信息中包含有推理模型的标识，即可直接根据配置信息从模型仓库01中拉取推理模型及元数据，在依据元数据确定推理模型所依赖的容器镜像，然后从从容器镜像仓库02中拉取容器镜像；若配置信息中只包含用户需要计算的数据信息，则先通过元数据确定能够输出该数据信息的推理模型，然后从模型仓库01中拉取推理模型及元数据，在依据元数据确定推理模型所依赖的容器镜像，然后从从容器镜像仓库02中拉取容器镜像，具体情况可以根据实际情况而定，本发明实施例对此不作具体限定。

在该步骤中，模型微服务引擎04还可以将所述推理模型、元数据和容器镜像进行封装，得到为可容器化运行的模型推理服务以对外提供在线推理服务，在实际应用中，往往一个系统可以对外提供多个推理服务，但现有技术中并没有考虑推理模型与容器镜像的匹配问题，因此推理服务时常运行出错，之后再通过人工检修，配置与推理模型对应的容器镜像，不仅过程繁琐、缺乏统一管理和追踪，容易出错。

但本发明实施例通过设置模型仓库01和容器镜像仓库02，用户就可以通过在服务设计器03中设计具体模型在线推理任务时选择相应的容器镜像即可，无需运维重新搭建运行环境，保证了推理服务的运行稳定，及时系统中部署的推理服务数量庞大，也可以针对性的保证每个推理服务能够部署上线，为用户提供稳定的服务。

在本发明的又一实施例中，如图2所示，所述系统还包括：服务状态监控装置05；

所述服务状态监控模块用于确定所述模型微服务引擎中的各个用于搭载推理服务的容器实例的cpu使用率、gpu使用率、内存使用率、响应时延以及容器实例数量；以及，计算所述模型微服务引擎中的所述推理服务的准确性指标。

在本发明实施例中，服务状态监控装置05与模型微引擎服务连接，用于确定模型微引擎服务中的若干个容器的cpu使用率、gpu使用率、内存使用率、响应时延以及容器实例数量，以反映容器搭载的推理服务性能。

另一方面，发明人在研究过程中发现在推理系统的实际应用中，为应对大规模服务请求情况，往往配置较高的虚拟机数量和硬件规格，而大多数服务的调用量往往会随着业务的涨落而涨落，经常出现类似白天高、夜间低的现象，导致硬件资源在调用量较低期间使用率低，造成资源浪费，所以基于此本发明还提出了能够实现推理服务的弹性扩缩容方法，具体地，在本发明的又一实施例中，所述系统还包括：容器编排器06；

所述容器编排器06用于根据所述cpu使用率、gpu使用率、内存使用率、响应时延以及推理服务数量计算期望容器实例数量，并依据所述期望容器实例数量对所述模型微服务引擎中的容器实例进行增加/删减。

在本发明实施例中，通过对模块微服务引擎中容器的cpu使用率、gpu使用率、内存使用率、响应时延以及推理服务数量计算期望容器实例数量的监控，实现对资源使用情况的监控，然后再根据预先预计的计算方式调节资源配置，以达到资源优化的效果。

进一步地，在本发明的又一实施例中提供了实现推理服务的弹性扩缩容的具体计算方式：根据所述cpu使用率、gpu使用率、内存使用率、响应时延以及推理服务数量计算期望容器实例数量的公式如下：

其中，α、β、γ、δ分别为cpu使用率、gpu使用率、内存使用率、响应时延4个衡量维度的权重因子，取值范围为[0,1],总和为1，ceil表示向下取整。

在本发明实施例中，通过对上一个时间窗口内容器资源使用率指标，采用本发明提出的容器实例数量计算公式，得到下一个时间窗口内期望的容器实例数量，然后借助kubernetes中的横向自动扩缩容的功能(horizontalpodautoscaling，简称hpa)，自动化地调整容器实例数量，然后服务状态监控模块继续实时监控更新后各容器实例的资源使用率等指标，以此循环，实现模型在线推理服务资源的动态调整，实现基于推理模型服务的资源使用率实时监控指标和期望资源计算公式进行动态调整的目的，在保证了模型推理服务的资源需求同时，还减少了资源的闲置浪费。

另外，发明人在研究过程中还发现，模型推理的准确性由于数据分布的漂移在一定时间后需要重新训练推理模型，更新线上服务，当前的部署方式需要人工选择某个版本的模型文件、上传，替换线上的模型文件，根据模型服务封装方式的不同，可能还需要重启服务，导致线上服务中断，并且该更新过程需要人工操作、无法自动化，且过程繁琐、缺乏统一管理和追踪，容易出错。基于此，在本发明的又一实施例中，如图3所示，所述模型微服务引擎中包括：模型筛选器07；

所述模型筛选器用于根据配置信息确定筛选策略，并按照所述筛选策略从所述模型仓库中拉取符合所述筛选策略的推理模型。

在本发明实施例中，模型筛选器用于根据配置信息确定筛选策略，其中配置信息中包含的筛选策略可以是系统预先提供的策略模板，用户从策略模板中选择目标策略后，系统会将策略写入配置信息，所以通过配置信息可以确定筛选策略。

其中，所述配置信息包含下列五种模型筛选策略中的任一种；

第一筛选策略：根据所述配置信息确定用户所需的目标数据信息，根据所述目标数据信息确定目标推理模型；

在实际应用中，针对用户不知道选用何种推理模型的情况，用户可以只输入自己所需得到的数据即可，而模型筛选器可以遍历模型仓库中每个推理模型的元数据，以从多个推理模型中确定用户需要的目标推理模型。

第二筛选策略：从服务状态监控模块获取多个所述推理模型的准确性指标，从多个所述推理模型选取准确性指标最高的推理模型，得到目标推理模型。

在实际应用中，由于功能相同的推理模型可能存在多个迭代版本，所以针对每个推理模型，系统可以在推理模型输出结果后，对推理模型的输出结果的精确度进行计算，进而实现择优选择准确率最高的推理模型。

第三筛选策略：获取相同类型不同版本的多个所述推理模型的性能评估指标，从多个所述推理模型中选取性能评估指标最高的推理模型，得到目标推理模型。

在实际应用中，由于功能相同的推理模型可能存在多个迭代版本，所以系统根据预设的性能评估指标会对每个类型相同的推理模型的性能进行评估，其中性能评估指标的具体的准确性指标计算方式可以根据推理模型的类型而定，任何用户自定义的加权指标均可使用，本发明对此不作具体限定。

第四筛选策略：获取相同类型不同版本的多个所述推理模型的性能评估指标，利用所述性能评估指标高于阈值的推理模型更新迭代出目标推理模型。

在实际应用中，由于功能相同的推理模型可能存在多个迭代版本，所以还可以利用相同推理模型的元数据重新迭代出新的版本以部署上线，供用户使用。

第五筛选策略：根据所述配置信息确定用户指定的推理模型标识，根据所述推理模型标识确定目标推理模型。

在实际应用中，用户可以直接指定推理模型计算用户所需数据，具体的，推理模型可以通过面板展示给用户选取，根据用户选取的推理模型标识即可定目标推理模型。

本发明实施例通过设计自动化的模型筛选方法和策略，达到减少人工操作的目的，并且适用于机器学习模型往往会随着时间的推移进行迭代更新的应用场景，更好的保障推理模型在线推理服务的准确性。

在本发明的又一实施例中，所述服务设计器中包括：压力测试/在线服务模块；

所述压力测试/在线服务模块用于对所述模型微服务引擎中的推理服务进行压力测试，生成测试结果；以及，接收用户的推理服务请用请求。

在本发明实施例中，压力测试/在线服务模块是指将部署上线的模型推理服务进行压力测试或开发给需求方提供模型推理服务的功能模块。在实际应用红，压力测试提供json、数据文件、并发请求三种方式对部署的模型推理服务进行长时间或满负荷的运行测试，并生成服务的性能、可靠性、稳定性报告；在线服务是指将模型推理服务的api接口、调用方式及反馈状态相关说明暴露出来，供内、外网请求服务。另外，压力测试/在线服务模块还可以接收用户输入的用于使用在线的推理服务的服务器请求。

在本发明的又一实施例中，所述在线模型推理系统还包括：负载均衡器；

所述负载均衡器用于将所述用户的推理服务应用请求分配至所述模型微服务引擎的容器实例中，以使所述容器实例中部署的推理服务响应所述用户的推理服务应用请求。

在本发明实施例中，为每个模型推理在线服务提供自动负载均衡能力，即将压力测试/在线服务模块中产生大规模请求流量通过负载均衡算法将请求分配到各个计算节点的容器实例中，达到均衡资源配置的目的，其中负载均衡算法采用随机法、轮询法、原地址哈希法、加权轮询法、最小连接数法等，具体设置可以根据实际情况认定。

在本发明的又一实施例中，所述设计器中包括：监控面板；

所述监控面板用于采集服务状态监控模块中的存储数据，并依据预设的计算方式对所述存储数据进行计算得到监控指标，以供用户查看。

在本发明的又一实施例中，所述系统还包括：模型服务发布管理模块；

所述模型服务发布管理模块用于将管理所述模型微服务引擎中的推理服务的上线、下线、注册、发现、发布、重启以及管理功能，以供用户能够了解在线的推理服务并进行选择。

在本发明的又一实施例中，还提供了在线模型推理系统在实际应用中的完整实施例，如图3所示，1)首先，服务设计器可以是webui设计界面，是用于提供给用户选择在线推理服务的平台，用户可以在平台上选择自己所需的推理模型或者输入自己所需得到的推理数据，然后由系统根据推理数据为用户确定推理模型，具体情况可以根据实际情况而定。

另一方面，用户在webui设计自己所需的推理服务后，可以由webui设计界面中的压力测试/在线服务模块产生大规模请求流量通过负载均衡算法将请求分配到各个计算节点的容器实例中，进一步地，为了每个在线推理服务自动负载能力的均衡，在线推理系统中还包括负载均衡器，用于将所述用户的推理服务应用请求分配至所述模型微服务引擎的容器实例中，以使所述容器实例中部署的推理服务响应所述用户的推理服务应用请求。

2)模型微服务引擎根据用户在服务设计器中的选取的设计内容，从模型仓库和容器镜像仓库中拉取推理模型，模型仓库中推理模型是构建人员基于不同的框架针对具体机器学习任务训练好的模型文件及模型元数据信息的管理仓库，推理模型的需要成功部署在容器上线后才能够为用户提供在线推理服务，所以还需要从容器镜像仓库中拉取推理模型运行的容器镜像，例如：安装好scikit-learn、tensorflow、pytorch、keras、caffe、mxnet等基础算法库、依赖包等等。

但是，在实际应用中，模型推理的准确性由于数据分布的漂移在一定时间后需要重新训练推理模型，更新线上服务，当前的部署方式需要人工选择某个版本的模型文件、上传，替换线上的模型文件，根据模型服务封装方式的不同，可能还需要重启服务，导致线上服务中断，并且该更新过程需要人工操作、无法自动化，且过程繁琐、缺乏统一管理和追踪，容易出错。所以为了应对推理模型迭代速度快，高频更新服务以及人工操作繁琐等问题，发明人在模型微服务引擎中添加了模型筛选器，用于根据配置信息确定筛选策略，并按照所述筛选策略从所述模型仓库中拉取符合所述筛选策略的推理模型，其中，筛选策略可以显示在webui设计界面中，以供用户选择，具体的本发明实施例还提供了五种筛选策略的模板，包括：第一筛选策略，根据所述配置信息确定用户所需的目标数据信息，根据所述目标数据信息确定目标推理模型，以针对用户不知道选用何种推理模型的情况，用户可以只输入自己所需得到的数据即可；第二筛选策略：从服务状态监控模块获取多个所述推理模型的准确性指标，从多个所述推理模型选取准确性指标最高的推理模型，得到目标推理模型，以针对由于功能相同的推理模型可能存在多个迭代版本的情况，对此，系统可以在推理模型输出结果后，对推理模型的输出结果的精确度进行计算并存储，以供用户参考选择；第三筛选策略：获取相同类型不同版本的多个所述推理模型的性能评估指标，从多个所述推理模型中选取性能评估指标最高的推理模型，得到目标推理模型，针对由于功能相同的推理模型可能存在多个迭代版本的情况，系统还可以根据预设的性能评估指标会对每个类型相同的推理模型的性能进行评估，例如：回归模型的常规性能指标有mse、rmse、mae等，分类模型的常规性能指标有精确率、召回率、f1值、auc等，具体可以根据实际情况而定；第四筛选策略：获取相同类型不同版本的多个所述推理模型的性能评估指标，利用所述性能评估指标高于阈值的推理模型更新迭代出目标推理模型，针对由于功能相同的推理模型可能存在多个迭代版本的情况，还可以利用相同推理模型的元数据重新迭代出新的版本以部署上线，供用户使用；第五筛选策略：根据所述配置信息确定用户指定的推理模型标识，根据所述推理模型标识确定目标推理模型，该策略是直接根据用户所需数据选取的推理模型。本发明实施例通过上述设计自动化的模型筛选方法和策略，达到减少人工操作的目的，适用于机器学习模型往往会随着时间的推移进行迭代更新的应用场景，更好的保障推理模型在线推理服务的准确性。

3)在实际应用中，在线模型推理系统还有与模型微服务引擎连接的kubernetes集群，kubernetes集群用于对模型微服务引擎中的部署的推理服务及其配套的资源进行管理，基于容器技术、自研调度编排技术对基础设施中cpu异构集群、gpu异构集群、ceph/hdfs存储服务等基础资源进行合理的分配和调度，为模型服务提供高可用的运行时环境。通过标签的方式来管理cpu/gpu异构集群中的计算节点，即将不同的计算节点划分为不同的可用区或组。在部署模型在线服务时，使用节点选择器将模型在线服务部署至带有指定标签的目标计算节点上。为了保证高可用，每个标签组合的目标计算节点数大于1。从而避免一台目标节点宕机后，调度器还能找到满足条件的计算节点将宕机节点上的在线服务对应的容器迁移到其它计算节点上，从而保证模型在线服务的高可用性。

但是，基于现有的kubernetes集群(kubernetes是google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理，能够让部署容器化的应用简单并且高效，kubernetes提供了应用部署、规划、更新、维护的一种机制。)功能无法解决现有技术中存在的应对大规模服务请求情况，在大规模服务请求发生时往往需要配置较高的虚拟机数量和硬件规格，而大多数服务的调用量往往会随着业务的涨落而涨落，经常出现类似白天高、夜间低的现象，导致硬件资源在调用量较低期间使用率低，造成资源浪费，所以基于此本发明还提出了能够实现推理服务的弹性扩缩容方法，并在kubernetes集群中增加容器编排器，用于根据模型微服务引擎中容器的cpu使用率、gpu使用率、内存使用率、响应时延以及推理服务数量计算期望容器实例数量，并依据所述期望容器实例数量对所述模型微服务引擎中的容器实例进行增加/删减。

在上述步骤中，模型微服务引擎中容器的cpu使用率、gpu使用率、内存使用率、响应时延以及推理服务数量的参数信息是由服务状态监控装置采集得到的，所以通过设计采集容器配置资源的服务状态监控装置，然后由kubernetes集群中的容器编排器采用上述实施例中提出的容器实例数量计算公式，得到下一个时间窗口内期望的容器实例数量，然后借助kubernetes中的横向自动扩缩容的功能(horizontalpodautoscaling，简称hpa)，自动化地调整容器实例数量，然后服务状态监控模块继续实时监控更新后各容器实例的资源使用率等指标，以此循环，实现模型在线推理服务资源的动态调整，实现基于推理模型服务的资源使用率实时监控指标和期望资源计算公式进行动态调整的目的，具体容器实例数量计算公式可参照上述实施例内容，此处便不再赘述，另外，在线推理系统还包括监控面板，该监控面板用于采集服务状态监控模块中的存储数据，并依据预设的计算方式对所述存储数据进行计算得到监控指标，以供用户查看。

本发明实施例通过容器技术封装技术(例如docker封装技术)、打包模型推理任务，将不同服务的容器镜像完全隔离，并借助kubernetes进行服务编排，提供服务的分布式容灾和资源的弹性伸缩功能，同时结合模型仓库、容器镜像仓库、服务状态监控器、模型服务发布管理模块、监控面板等功能模块使算法模型与服务架构解耦，使推理模型的部署上线、更新和管理流程变得简单，上线效率高、风险低，同时提高预测服务的稳定性、灵活性和服务能力。

4)在线推理系统为了提升用户体验还设计了模型服务发布管理模块用于将管理所述模型微服务引擎中的推理服务的上线、下线、注册、发现、发布、重启以及管理功能，当推理服务更新时，能够第一时间推送给用户消息，以供用户能够了解在线的推理服务并进行选择。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本发明的具体实施方式，使本领域技术人员能够理解或实现本发明。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。