CN114528186A

CN114528186A - 一种模型管理方法、装置及模型管理服务器

Info

Publication number: CN114528186A
Application number: CN202210157136.8A
Authority: CN
Inventors: 黄绿君; 高峰斌; 石雷雷; 龚君泰; 李�杰; 时金贵; 杨静; 刘欢; 王林芳
Original assignee: Jingdong Technology Information Technology Co Ltd
Current assignee: Jingdong Technology Information Technology Co Ltd
Priority date: 2022-02-21
Filing date: 2022-02-21
Publication date: 2022-05-24

Abstract

本申请公开了一种模型管理方法、装置及电子设备。该方法适用于模型管理服务器，模型管理服务器包括可视化前端和数据处理端，包括：可视化前端获取针对任一模型的模型管理请求，并发送至数据处理端；数据处理端接收模型管理请求，并根据模型管理请求对任一模型进行模型管理，以生成针对任一模型的模型管理结果；可视化前端接收任一模型的模型管理结果，并展示模型管理结果，使得用户可以通过模型管理服务器的可视化前端输入针对任一模型的模型管理请求，进而由数据处理端对模型进行管理，并最终由可视化前端将模型管理过程所涉及的必要信息进行可视化展示，提高了模型管理过程中的效率，降低了用户需要付出的学习成本，提升了用户体验。

Description

一种模型管理方法、装置及模型管理服务器

技术领域

本申请涉及数据处理技术领域，尤其涉及一种模型管理方法、装置及模型管理服务器。

背景技术

近年来，随着人工智能(Artificial Intelligence，简称AI)技术的广泛应用，AI产品的智能化程度也受到了更多的关注。其中，模型是AI产品的核心。然而，由于，模型的构建、训练与部署上线及监督等模型管理过程往往较为复杂、且其涉及的流程长、环节多、环境复杂、各环节关联紧密，这样一来，模型管理过程中面临着诸多困难。

然而，相关技术中，尚未存在高效、可靠的的模型管理方法。因此，如何提高模型管理过程中的效率和可靠性，已成为了重要的研究方向之一。

发明内容

本申请旨在至少在一定程度上解决相关技术中的技术问题之一。

为此，本申请的第一个目的在于提出一种模型管理方法，用于解决相关模型管理方法过程中存在的效率低和可靠性差的技术问题。

本发明的第二个目的在于提出另一种模型管理装置。

本发明的第三个目的在于提出一种模型管理服务器。

本发明的第四个目的在于提出一种电子设备。

本发明的第五个目的在于提出一种计算机可读存储介质。

为了实现上述目的，本申请第一方面实施例提供了一种模型管理方法，适用于模型管理服务器，所述模型管理服务器包括可视化前端和数据处理端，所述方法包括以下步骤：所述可视化前端获取针对任一模型的模型管理请求，并发送至所述数据处理端；所述数据处理端接收所述模型管理请求，并根据所述模型管理请求对所述任一模型进行模型管理，以生成针对所述任一模型的模型管理结果；所述可视化前端接收所述任一模型的所述模型管理结果，并展示所述模型管理结果。

另外，根据本申请上述实施例的模型管理方法还可以具有如下附加的技术特征：

根据本申请的一个实施例，所述可视化前端获取针对任一模型的模型管理请求，并发送至所述数据处理端之后，还包括：所述可视化前端获取针对所述任一模型的管理方式选取请求，并发送至所述数据处理端；所述数据处理端接收所述管理方式选取请求，并根据所述管理方式选取请求，生成针对目标展示页面的调用指令发送至所述可视化前端；所述可视化前端接收所述调用指令，并从当前展示页面转至所述目标展示页面，以于所述目标展示页面上执行模型管理操作。

根据本申请的一个实施例，针对所述任一模型的管理方式包括非自动学习式模型管理方式、半自动学习式模型管理方式以及全自动学习式模型管理方式中的任意一种。

根据本申请的一个实施例，所述根据所述模型管理请求对所述任一模型进行模型管理，包括：获取所述模型管理请求的请求类型，并根据所述请求类型对所述任一模型进行模型管理。

根据本申请的一个实施例，所述模型管理请求为模型开发请求，所述根据所述请求类型对所述任一模型进行模型管理，包括：根据所述模型开发请求，确定所述任一模型的目标集成开发环境IDE；基于所述目标IDE，确定所述模型的目标建模环境和目标数据管理方式；根据所述目标建模环境和所述目标数据管理方式，构建所述模型。

根据本申请的一个实施例，所述模型管理请求为模型训练请求，所述根据所述请求类型对所述任一模型进行模型管理，包括：根据所述模型训练请求，确定所述任一模型的目标训练方式；针对所述目标训练方式，获取所述任一模型的目标组件和目标训练配置参数；获取所述任一模型的训练任务，并基于所述目标组件和所述目标训练配置参数，执行针对所述任一模型的所述训练任务。

根据本申请的一个实施例，所述模型管理请求为模型部署请求，所述根据所述请求类型对所述任一模型进行模型管理，包括：根据所述模型部署请求，确定目标部署方式；针对所述目标部署方式，获取所述任一模型的目标部署配置参数；基于所述目标部署配置参数，对所述任一模型进行部署。

根据本申请的一个实施例，所述模型管理请求为模型监控请求，所述根据所述请求类型对所述任一模型进行模型管理，包括：根据所述模型监控请求，获取针对所述任一模型的目标监控策略，其中，所述目标监控策略包括目标监控配置参数以及模型服务实例部署方式；根据所述目标监控配置参数以及所述模型服务实例调整策略，对所述模型进行监控。

根据本申请的一个实施例，所述根据所述目标监控配置参数以及所述模型服务实例调整策略，对所述模型进行监控之后，还包括：响应于检测到所述任一模型的资源配置参数大于所述目标监控配置参数，则根据所述模型服务实例调整策略调整模型服务实例的部署方式。

根据本申请的一个实施例，所述根据所述模型管理请求对所述任一模型进行模型管理，以生成针对所述任一模型的模型管理结果之后，还包括：响应于检测到所述任一模型满足数据更新条件，则获取所述任一模型的模型数据以及元数据；根据所述模型数据以及所述元数据，对所述模型管理服务器中的镜像仓库的数据进行更新。

本申请第一方面实施例提供了模型管理方法，可以通过可视化前端获取针对任一模型的模型管理请求，并发送至数据处理端，进一步地数据处理端接收模型管理请求，并根据模型管理请求对任一模型进行模型管理，以生成针对任一模型的模型管理结果，进而使可视化前端接收任一模型的模型管理结果，并展示模型管理结果，使得用户可以通过模型管理服务器的可视化前端输入针对任一模型的模型管理请求，进而由数据处理端对模型进行管理，并最终由可视化前端将模型管理过程所涉及的必要信息进行可视化展示，提高了模型管理过程中的效率、灵活度及可靠性，降低了用户对于模型管理需要付出的学习成本，提升了用户体验。

为了实现上述目的，本申请第二方面实施例提供了一种模型管理装置，所述装置包括：发送模块，用于获取针对任一模型的模型管理请求，并发送至所述数据处理端；接收模块，用于接收所述模型管理请求，并根据所述模型管理请求对所述任一模型进行模型管理，以生成针对所述任一模型的模型管理结果；展示模块，用于接收所述任一模型的所述模型管理结果，并展示所述模型管理结果。

根据本申请的一个实施例，所述发送模块，还用于：所述可视化前端获取针对所述任一模型的管理方式选取请求，并发送至所述数据处理端；所述数据处理端接收所述管理方式选取请求，并根据所述管理方式选取请求，生成针对目标展示页面的调用指令发送至所述可视化前端；所述可视化前端接收所述调用指令，并从当前展示页面转至所述目标展示页面，以于所述目标展示页面上执行模型管理操作。

根据本申请的一个实施例，所述发送模块，还用于：获取所述模型管理请求的请求类型，并根据所述请求类型对所述任一模型进行模型管理。

根据本申请的一个实施例，所述模型管理请求为模型开发请求，所述发送模块，还用于：根据所述模型开发请求，确定所述任一模型的目标集成开发环境IDE；基于所述目标IDE，确定所述模型的目标建模环境和目标数据管理方式；根据所述目标建模环境和所述目标数据管理方式，构建所述模型。

根据本申请的一个实施例，所述模型管理请求为模型训练请求，所述发送模块，还用于：根据所述模型训练请求，确定所述任一模型的目标训练方式；针对所述目标训练方式，获取所述任一模型的目标组件和目标训练配置参数；获取所述任一模型的训练任务，并基于所述目标组件和所述目标训练配置参数，执行针对所述任一模型的所述训练任务。

根据本申请的一个实施例，所述模型管理请求为模型部署请求，所述发送模块，还用于：根据所述模型部署请求，确定目标部署方式；针对所述目标部署方式，获取所述任一模型的目标部署配置参数；基于所述目标部署配置参数，对所述任一模型进行部署。

根据本申请的一个实施例，所述模型管理请求为模型监控请求，所述发送模块，还用于：根据所述模型监控请求，获取针对所述任一模型的目标监控策略，其中，所述目标监控策略包括目标监控配置参数以及模型服务实例部署方式；根据所述目标监控配置参数以及所述模型服务实例调整策略，对所述模型进行监控。

根据本申请的一个实施例，所述发送模块，还用于：响应于检测到所述任一模型的资源配置参数大于所述目标监控配置参数，则根据所述模型服务实例调整策略调整模型服务实例的部署方式。

根据本申请的一个实施例，所述展示模块，还用于：响应于检测到所述任一模型满足数据更新条件，则获取所述任一模型的模型数据以及元数据；根据所述模型数据以及所述元数据，对所述模型管理服务器中的镜像仓库的数据进行更新。

本申请第二方面实施例提供了模型管理装置，可以通过可视化前端获取针对任一模型的模型管理请求，并发送至数据处理端，进一步地数据处理端接收模型管理请求，并根据模型管理请求对任一模型进行模型管理，以生成针对任一模型的模型管理结果，进而使可视化前端接收任一模型的模型管理结果，并展示模型管理结果，使得用户可以通过模型管理服务器的可视化前端输入针对任一模型的模型管理请求，进而由数据处理端对模型进行管理，并最终由可视化前端将模型管理过程所涉及的必要信息进行可视化展示，提高了模型管理过程中的效率、灵活度及可靠性，降低了用户对于模型管理需要付出的学习成本，提升了用户体验。

为了实现上述目的，本申请第三方面实施例提供了一种模型管理服务器，所述服务器包括：可视化前端和数据处理端，其中，所述可视化前端，用于获取针对任一模型的模型管理请求，并发送至所述数据处理端；接收所述任一模型的模型管理结果，并展示所述模型管理结果；所述数据处理端，用于接收所述模型管理请求，并根据所述模型管理请求对所述任一模型进行模型管理，以生成针对所述任一模型的所述模型管理结果。

根据本申请的一个实施例，所述可视化前端包括用户交互层，所述数据处理端包括数据层、基础设施层和引擎框架层。

本申请第三方面实施例提供了模型管理服务器，可以通过可视化前端获取针对任一模型的模型管理请求，并发送至数据处理端，进一步地数据处理端接收模型管理请求，并根据模型管理请求对任一模型进行模型管理，以生成针对任一模型的模型管理结果，进而使可视化前端接收任一模型的模型管理结果，并展示模型管理结果，使得用户可以通过模型管理服务器的可视化前端输入针对任一模型的模型管理请求，进而由数据处理端对模型进行管理，并最终由可视化前端将模型管理过程所涉及的必要信息进行可视化展示，提高了模型管理过程中的效率、灵活度及可靠性，降低了用户对于模型管理需要付出的学习成本，提升了用户体验。

为了实现上述目的，本申请第四方面实施例提供了一种电子设备，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序时，实现如本申请第一方面实施例中任一项所述的模型管理方法。

为了实现上述目的，本申请第五方面实施例提供了一种计算机可读存储介质，该程序被处理器执行时实现如本申请第一方面实施例中任一项所述的模型管理方法。

附图说明

图1为本申请一个实施例公开的模型管理方法的流程示意图；

图2为本申请一个实施例公开的模型管理服务器的结构示意图；

图3为本申请一个实施例公开的展示页面的示意图；

图4为本申请另一个实施例公开的模型管理方法的流程示意图；

图5为本申请另一个实施例公开的展示页面的示意图；

图6为本申请另一个实施例公开的展示页面的示意图；

图7为本申请另一个实施例公开的模型管理方法的流程示意图；

图8为本申请另一个实施例公开的模型管理方法的流程示意图；

图9为本申请另一个实施例公开的模型管理方法的流程示意图；

图10为本申请另一个实施例公开的模型管理方法的流程示意图；

图11为本申请另一个实施例公开的模型管理方法的流程示意图；

图12为本申请另一个实施例公开的模型管理服务器的结构示意图；

图13为本申请一个实施例公开的模型管理服务器模块分化的示意图；

图14为本申请一个实施例公开的微服务构架的示意图；

图15为本申请一个实施例公开的单机式模型训练任务管理的示意图；

图16为本申请一个实施例公开的分布式模型训练任务管理的示意图；

图17为本申请一个实施例公开的半自动式模型训练方式的建模流程的示意图；

图18为本申请一个实施例公开的自动式模型训练方式的建模流程示意图；

图19为本申请一个实施例公开的模型部署阶段的示意图；

图20为本申请一个实施例公开的模型管理装置的结构示意图；

图21为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

为了更好的理解上述技术方案，下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

应当理解，本申请实施例中涉及的“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。

下面参照附图描述根据本申请实施例提出的一种模型管理方法、装置及服务器。

图1为本申请一个实施例公开的一种模型管理方法的流程示意图。

如图1所示，本申请实施例提出的模型管理方法，适用于模型管理服务器，模型管理服务器包括可视化前端和数据处理端，具体包括以下步骤：

S101、可视化前端获取针对任一模型的模型管理请求，并发送至数据处理端。

需要说明的是，相关技术中，模型的构建、训练与部署上线及监督等模型管理过程，一般通过在物理服务器或虚拟机上搭建conda环境、安装相应的软件包，然后在模型的训练过程中下载或者通过网络传输至模型推理服务器，相关人员根据模型运行要求准备适配的硬件资源和软件环境，以将其部署上线。进一步地，当模型批量推理服务需要周期性调度时，往往通过crontab定时任务进行触发；当模型在线推理服务用于高并发量场景时，再开发流量控制、负载均衡和高可用等模块。

其中，conda，指的是一个开源的软件包管理系统和环境管理系统，用于安装多个版本的软件包及其依赖关系，并在它们之间进行切换；crontab，用于定期执行程序的命令。

这样一来，往往导致相关技术中的模型管理过程存在模型开发训练效率低、模型开发训练使用门槛较高、模型部署难、无管理且资源利用率低的技术问题。

由此，本申请提出的模型管理方法，基于包括可视化前端和数据处理端的模型管理服务器，通过提供海量数据预处理、模型训练和可扩展的离线/在线按需部署能力，实现端到端(End-to-End)的全生命周期管理，帮助用户高效、可靠地管理模型。

其中，如图2所示，模型管理服务器100，包括可视化前端10和数据处理端20，用户可以通过于可视化前端10的展示页面发送针对任一模型的模型管理请求。

需要说明的是，本申请中，在用户试图进行针对任一模型的模型管理时，可以通过多种方式发送模型管理请求。可选地，用户可以通过点击可视化前端第一展示界面上的第一目标控件发送模型管理请求。

举例而言，如图3所示，用户可以通过点击可视化前端10第一展示界面上3-1的第一目标控件3-2发送模型管理请求。

相应地，可视化前端可以对第一目标控件进行监控，响应于检测到第一目标控件被触发，可视化前端可以获取针对任一模型的模型管理请求，并发送至数据处理端。

S102、数据处理端接收模型管理请求，并根据模型管理请求对任一模型进行模型管理，以生成针对任一模型的模型管理结果。

本申请实施例中，在可视化前端将模型管理请求发送至数据处理端后，相应地，数据处理端可以接收模型管理请求。进一步地，可以根据模型管理请求获取针对任一模型的模型管理策略，进而根据匹配的模型管理策略对任一模型进行模型管理。

进一步地，在对任一模型进行模型管理后，可以生成针对任一模型的模型管理结果，并发送至可视化前端。

S103、可视化前端接收任一模型的模型管理结果，并展示模型管理结果。

本申请实施例中，在数据处理端将针对任一模型的模型管理结果发送至可视化前端后，可视化前端可以接收任一模型的模型管理结果，并展示模型管理结果，以使用户可以实时查看模型管理结果。

由此，本申请提出的模型管理方法，可以通过可视化前端获取针对任一模型的模型管理请求，并发送至数据处理端，进一步地数据处理端接收模型管理请求，并根据模型管理请求对任一模型进行模型管理，以生成针对任一模型的模型管理结果，进而使可视化前端接收任一模型的模型管理结果，并展示模型管理结果，使得用户可以通过模型管理服务器的可视化前端输入针对任一模型的模型管理请求，进而由数据处理端对模型进行管理，并最终由可视化前端将模型管理过程所涉及的必要信息进行可视化展示，提高了模型管理过程中的效率、灵活度及可靠性，降低了用户对于模型管理需要付出的学习成本，提升了用户体验。

需要说明的是，本申请中，在可视化前端获取针对任一模型的模型管理请求，并发送至数据处理端之后，可以获取用户选择的管理方式，进而针对不同的管理方式执行后续的模型管理过程。

作为一种可能的实现方式，如图4所示，在上述实施例的基础上，具体包括以下步骤：

S401、可视化前端获取针对任一模型的管理方式选取请求，并发送至数据处理端。

需要说明的是，本申请中对于可供选择的管理方式的具体选择不作限定，可以根据实际情况进行设定。

可选地，可以设定管理方式包括：非自动学习式模型管理方式、半自动学习式模型管理方式，以及全自动学习式模型管理方式。

其中，非自动学习式模型管理方式，指的是代码式模型管理方式，更加适用于倾向于通过自己编写实现算法模型逻辑的算法人员。本申请提供的非自动学习式模型管理方式，能够帮助用户(算法人员)解决算法代码开发之外的其它基础性工作，并提供标准化流程进行标准化统一管理，让算法人员专注于算法代码的开发，提高了效率。

其中，半自动学习式模型管理方式，指的是拖拽式模型管理方式，更加适用于不具备算法代码开发能力或者不愿意开发代码但有需要快速构建算法模型解决业务智能化需求的用户群体。本申请提供的半自动学习式模型管理方式能够通过拖拽模型管理服务器提供的数据获取、数据预处理、特征工程、机器学习、深度学习、流式算法等件，并人工输入模型训练相关参数的方式，实现模型的管理。

其中，全自动学习式模型管理方式，指的是自动学习式模型管理方式，在半自动学习式模型管理方式的基础上，进一步降低了对相关人员所具备的知识及经验的要求。

需要说明的是，全自动学习式模型管理方式，能够减少机器学习模型构建过程中对专业技术人才专业知识和超参数调优经验的依赖，模型构建人员无需开发代码，通过自动学习任务设计器配置模型学习任务的具体目标(如分类或回归等)、相关约束条件以及模型训练集和验证集，借助自动学习引擎进行模型的构建和超参数的搜索，并将最优的N个模型保存至模型仓库。其中，模型仓库，是一种数据仓库，用于存储模型。

需要说明的是，本申请中，在用户试图选取管理方式时，可以通过多种方式发送管理方式选取请求。可选地，用户可以通过点击可视化前端第二展示界面上的第二目标控件发送管理方式选取请求，其中，管理方式选取请求中携带用户选取的模型管理方式。

举例而言，如图5所示，用户可以通过点击可视化前端10第二展示界面上5-1的第二目标控件5-2发送管理方式选取请求，此种情况下，用户选取的管理方式为半自动学习式模型管理方式。

相应地，可视化前端可以对第二目标控件进行监控，响应于检测到第二目标控件被触发，并将可视化前端可以获取针针对任一模型的管理方式选取请求，并发送至数据处理端。

S402、数据处理端接收管理方式选取请求，并根据管理方式选取请求，生成针对目标展示页面的调用指令发送至可视化前端。

本申请实施例中，在可视化前端将管理方式选取请求发送至数据处理端后，数据处理端可以接收管理方式选取请求，并根据管理方式选取请求，获取管理方式选取请求对应的管理方式，并生成针对目标展示页面(例如第三展示页面)的调用指令发送至可视化前端。

S403、可视化前端接收调用指令，并从当前展示页面转至目标展示页面，以于目标展示页面上执行模型管理操作。

本申请实施例中，在数据处理端将针对目标展示页面的调用指令发送至可视化前端后，可视化前端可以接收调用指令，并从当前展示页面转至目标展示页面，以于目标展示页面上执行模型管理操作。

举例而言，如图6所示，针对管理方式选取请求为选择半自动学习式模型管理方式的请求，可视化前端可以接收调用指令，从当前页面(第二展示页面)6-1转至目标展示页面(第三展示页面)6-2，以于第三展示页面6-2上执行模型管理操作。

由此，本申请提出的模型管理方法，可以通过可视化前端获取针对任一模型的管理方式选取请求，并发送至数据处理端，然后数据处理端接收管理方式选取请求，并根据管理方式选取请求，生成针对目标展示页面的调用指令发送至可视化前端，进而可视化前端接收调用指令，并从当前展示页面转至目标展示页面，以于目标展示页面上执行模型管理操作，从而通过提供多种管理方式，实现了在确保模型管理效率及可靠性的基础上，更加全面地满足用户的不同实际需求，进一步提升了用户体验。

本申请实施例中，在试图根据模型管理请求对任一模型进行模型管理时，可选地，可以获取模型管理请求的请求类型，并根据请求类型对任一模型进行模型管理。

其中，模型管理请求的请求类型，可以为模型开发请求、模型训练请求、模型部署请求、模型监控请求等。

下面分别针对模型管理请求为模型开发请求、模型训练请求、模型部署请求、模型监控请求，对根据请求类型对任一模型进行模型管理的过程进行解释说明。

针对模型管理请求为模型开发请求，作为一种可能的实现方式，如图7所示，在上述实施例的基础上，上述步骤中根据请求类型对任一模型进行模型管理的具体过程，包括以下步骤：

S701、根据模型开发请求，确定任一模型的目标集成开发环境IDE。

其中，集成开发环境(Integrated Development Environment，简称IDE)，指的是用于提供程序开发环境的应用程序，一般包括代码编辑器、编译器、调试器和图形用户界面等工具。

其中，目标IDE可以为JupyterLab(Jupyter的开源项目)、RStudio(R语言的集成开发环境)以及其他IDE中的任意一种。

其中，模型开发请求中携带用户选取的目标IDE。这样一来，在获取到模型开发请求后，数据处理端可以根据模型开发请求，确定任一模型的目标IDE。

S702、基于目标IDE，确定模型的目标建模环境和目标数据管理方式。

以非自动学习式模型管理方式为例，用户可以根据具体建模需要，定义模型开发软件依赖的环境和硬件资源，从而启动云端建模环境。

针对软件环境，可以在镜像仓库中预置丰富主流机器学习、深度学习框架和开发语言基础镜像，通过Harbor进行镜像和标签信息管理，用户直接选用即可，无需重复搭建建模软件环境，同时也方便团队成员之间镜像共享，保障团队协作时软件环境的一致性。进一步地，当基础镜像无法满足用户个性化需求时，还可以通过自定义方式定义镜像环境，具体地，用户可从镜像仓库中拉取与需求最为相近的基础镜像，更新镜像，从而使用更新后的镜像。

针对硬件资源，可以基于框架(例如Kubernetes，简称K8S)对物理硬件资源进行统一调度管理。具体地，基于K8S中的命名空间namespace技术，将物理资源划分为逻辑上的物理资源池，资源池的大小可由管理员进行配置。用户在申请建模环境时可直接配置所需的硬件规格，如CPU(中央处理器，Central Processing Unit)核数、内存大小、GPU(图形处理器，Graphics Processing Unit)加速卡数量，并进入审批流程。其中，可根据服务器资源管理策略定义流程审批策略，例如，可以设定在资源规格未达到设定阈值时自动通过审批，以加快审批效率。建模环境申请流程通过后，服务器自动从资源池中分配相应的硬件资源，为用户启动云端建模环境。

进一步地，用户可以根据具体数据管理需要，选择结构化、半结构化以及非结构化数据管理方式中的任意一种。

S703、根据目标建模环境和目标数据管理方式，构建模型。

综上所述，本申请中，模型管理服务器可以向用户提供交互式建模服务，通过conda、pip(Python包管理工具)安装的软件包等环境配置信息确保环境的可复用性。可选地，针对用户的不同需求，提供了Jupyterlab、RStudio等多种类型的建模环境，用户可以根据实际项目需求；可选地，提供了组合配置CPU、GPU等硬件资源需求以及从模型管理服务器内置镜像仓库中选择软件镜像。同时，提供了通过CephFS等持久化用户数据的数据管理方式。

由此，本申请提出的模型管理方法，针对模型开发请求，能够通过向用户提供多种交互式建模服务、保障环境的可复用。同时，在资源分配方面采用弹性模式，即根据用户环境资源的实际利用率，动态调配资源，以提升资源利用率，进一步提高了模型管理过程中的效率，提高了用户体验。

针对模型管理请求为模型训练请求，作为一种可能的实现方式，如图8所示，在上述实施例的基础上，上述步骤中根据请求类型对任一模型进行模型管理的具体过程，包括以下步骤：

S801、根据模型训练请求，确定任一模型的目标训练方式。

其中，目标IDE可以为单机训练、分布式训练等训练方式中的任意一种。

S802、针对目标训练方式，获取任一模型的目标组件和目标训练配置参数。

以半自动学习式模型管理方式为例，在确定任一模型的目标训练方式之后，可以针对目标训练方式，获取任一模型的目标组件和目标训练配置参数。

本申请实施例中，由于模型管理服务器已经预先将数据获取、数据预处理、特征工程、机器学习、深度学习、流式算法等技术算子进行了组件化，形成组件库，并通过页面配置化的方式展示出对应的参数，因此，针对半自动学习式模型管理方式，可以从组件库中选取并拖拽对应的组件，并输入或修改其对应的参数，从而获取任一模型的目标组件和目标训练配置参数。

作为一种可能的实现方式，用户可以基于对业务的理解，于可视化前端10的展示页面上，从组件库从拖拽对应的组件至建模画布，组织成有向无环图，并配置组件对应的参数，即可实现建模流程的构建。

进一步地，数据处理端可以将流程图上的组件、组件对应的参数、组件的衔接关系以及该版本实验ID(Identity Document)记录至数据库，并初始化组件类，构建一个具体的模型训练流程。

S803、获取任一模型的训练任务，并基于目标组件和目标训练配置参数，执行针对任一模型的训练任务。

其中，模型的训练任务可以为提交、停止、删除、修改、任务清单查看、任务日志查看、任务资源占用率查看等命令和对应的Python、Java语言SDK(Software DevelopmentKit)软件开发工具包，实现试验参数追踪、版本对比和模型资产管理等任务中的至少一种。

本申请实施例中，在获取任一模型的目标组件和目标训练配置参数后，可以获取任一模型的训练任务，并基于目标组件和目标训练配置参数，执行针对任一模型的训练任务。

作为一种可能的实现方式，本申请中，模型管理服务器统一调度模型训练流程中的各个目标组件和目标训练配置参数，按照预设资源调度策略调度硬件资源，进而按照流程图顺序启动目标组件的运行。其中，目标组件之间的数据通过磁盘缓存或者分布式内存技术进行传输共享。

由此，本申请提出的模型管理方法，针对模型训练请求，能够通过将提交的训练任务提交到训练引擎，然后通过训练引擎提交到相应的训练资源池进行统一调度、运行。进一步地，基于operator(关键字)机制，支持单机和分布式的模型训练，可挂载本地卷、云盘等多种类型的存储至训练任务所在节点，解决了模型训练过程中数据开销较大问题，进一步提高了模型管理过程中的效率，提高了用户体验。

针对模型管理请求为模型部署请求，作为一种可能的实现方式，如图9所示，在上述实施例的基础上，上述步骤中根据请求类型对任一模型进行模型管理的具体过程，包括以下步骤：

S901、根据模型部署请求，确定目标部署方式。

其中，目标部署方式可以为在线部署方式以及离线部署方式中的任意一种。

离线部署方式，是指将训练好的模型部署为批量推理服务，然后通过标准接口与数据处理任务对接，触发推理任务的周期性运行。

在线部署方式，是指将用户模型部署成在线API(Application ProgrammingInterface，应用程序接口)服务，对外提供接口服务，并支持以下3种类型的在线服务：python function(函数)、TF(Tensor Flow)-Serving(服务)、PMML(Predictive ModelMarkup Language，预言模型标记预言)。同时，提供了负载均衡、灰度发布、A/B test(A、B两个版本测试)等常用组件，避免了常用工程性代码的重复开发。

S902、针对目标部署方式，获取任一模型的目标部署配置参数。

其中，目标部署配置参数，指的是部署模型涉及的基本信息、模型运行的软件环境和所需的硬件资源规格、模型名称及版本、模型的输入/输出格式、对于批量推理服务而言的模型的调度策略或对于在线推理服务而言的服务超时时长、分布式实例数量等参数。

S903、基于目标部署配置参数，对任一模型进行部署。

需要说明的是，本申请提出的模型管理方法中提出了一种模型仓库管理方案，以通过模型仓库管理方案，对模型及其元数据信息进行统一管理。

作为一种可能的实现方式，响应于模型满足业务部署上线条件，则可按照业务场景需要，在同一模型管理服务器上，将模型部署为批量作业，进行模型批量推理或者在线服务，对业务系统的请求及时响应模型推理结果。

由此，本申请提出的模型管理方法，针对模型部署请求，能够通过支持多种部署方式，包括离线部署方式和在线部署方式。可选地，离线部署方式能够触发推理任务的周期性运行；可选地，在线部署方式能够避免了常用工程性代码的重复开发，进一步提高了模型管理过程中的效率，提高了用户体验。进一步地，通过统一的模型部署流程，对线上模型服务进行标准化管理，能够降低运维成本。

针对模型管理请求为模型监控请求，作为一种可能的实现方式，如图10所示，在上述实施例的基础上，上述步骤中根据请求类型对任一模型进行模型管理的具体过程，包括以下步骤：

S1001、根据模型监控请求，获取针对任一模型的目标监控策略，其中，目标监控策略包括目标监控配置参数以及模型服务实例部署方式。

其中，目标监控配置参数，指的是常用的模型评估指标，例如，CPU使用率、GPU使用率、内存使用率、响应时延等各容器实例的资源使用率参数。

其中，目标监控配置参数，用于对模型推理的准确性和/或稳定性进行监控，以探测模型效果是否退化或数据分布出现漂移。

S1002、根据目标监控配置参数以及模型服务实例调整策略，对模型进行监控。

需要说明的是，本申请中，在根据目标监控配置参数以及模型服务实例调整策略，对模型进行监控之后，可以对模型在线推理服务资源进行动态调整。

作为一种可能的实现方式，响应于检测到任一模型的资源配置参数大于目标监控配置参数，则根据模型服务实例调整策略调整模型服务实例的部署方式。

可选地，在获取到目标监控配置参数以及模型服务实例调整策略后，可以根据目标监控配置参数，进行不同时间粒度的汇总计算，并根据模型服务实例调整策略计算下一个时间窗口内期望的容器实例数量。进一步地，通过Kubernetes中的横向自动扩缩容的功能(Horizontal Pod Autoscaling，简称HPA)，自动化地调整容器实例数量，从而实现模型在线推理服务资源的动态调整。

由此，本申请提出的模型管理方法，针对模型监控请求，能够通过开发用户自定义接口，进行模型推理的准确性和/或稳定性进行监控，以探测模型效果是否退化或数据分布出现漂移。可选地，对于用户配置的监控指标，用户可在预警规则中设定相应的阈值，以触发个性化定制的模型异常预警通知，进一步提高了模型管理过程中的效率，提高了用户体验。

进一步地，本申请中，在根据模型管理请求对任一模型进行模型管理，以生成针对任一模型的模型管理结果之后，可以进行线上模型的更新升级。

作为一种可能的实现方式，如图11所示，在上述实施例的基础上，具体包括以下步骤：

S1101、响应于检测到任一模型满足数据更新条件，则获取任一模型的模型数据以及元数据。

其中，数据更新条件可以根据实际情况进行设定，例如，可以设定数据更新条件为探测到存在异常。

其中，元数据(Metadata)，又称中介数据、中继数据，指的是描述数据的数据(dataabout data)，主要用于描述数据的属性(property)信息。

S1102、根据模型数据以及元数据，对模型管理服务器中的镜像仓库的数据进行更新。

作为一种可能的实现方式，本申请中，在检测到任一模型出现异常时，可以根据模型数据以及元数据，对模型的多版本进行验证评估，通过策略配置自动筛选等方式筛选出满足业务部署上线标准的模型，进行线上模型的更新升级。

由此，本申请提出的模型管理方法，能够通过响应于检测到任一模型满足数据更新条件，则获取任一模型的模型数据以及元数据，进而根据模型数据以及元数据，对模型管理服务器中的镜像仓库的数据进行更新，从而实现便捷地试验任务版本管理、版本对比，同时也保障了试验结果的可复现性，进一步提高了模型管理过程中的效率及用户体验。

图12为本申请一个实施例公开的一种模型管理服务器的示意图。

需要说明的是，相关技术中的模型管理服务器，往往具有模型开发训练效率低、模型开发训练使用门槛较高、部署难、无管理以及资源利用率低等技术问题。

针对模型开发训练效率低，指的是软件环境搭建麻烦，且重复建设、难团队共享；训练机器多为单机，无法高效进行大规模模型的分布式训练；缺少规范的开发训练管理流程，数据、代码、模型依靠各个开发者按自己的方式管理，缺少统一的参照规范，后续维护成本极大。

针对模型开发训练使用门槛较高，指的是要求相关人员必须具备机器学习、深度学习专业知识背景以及较强的代码开发能力；同时，对于模型训练过程中的超参数调优，只能依赖算法人员凭借经验反复调试，费时耗力。

针对部署难、无管理，指的是无统一部署环境，开发环境与部署环境不一致；线上模型无版本管理，修改、回滚麻烦；线上模型运行情况靠人工跟踪，操作复杂易出错；模型运行结果无监控和预警，发生问题后知后觉；模型批量预测使用crontab定时任务，缺乏数据任务依赖调度管理；模型在线服务部署门槛高，往往依赖软件研发工程师。

针对资源利用率低，指的是硬件资源缺少统一管理和调度；各部门自建模型开发机器集群；一机多用，部分机器资源竞争严重，部分机器资源空置；团队多人共用GPU服务器时，存在资源冲突问题尤为突出。

由此，本申请实施例提出一种模型管理服务器，能够为机器学习与深度学习提供海量数据预处理、模型训练和可扩展的离线和/或在线按需部署能力，实现端到端机器学习流程的全生命周期管理，帮助用户快速创建和部署模型，提升算法工程师的建模效率和底层资源的利用率；同时，支持将常用数据集、算法、模型进行统一沉淀和管理，以便在公司内部共享、复用，加速算法产品的开发与落地。

如图12所示，模型管理服务器100，包括：可视化前端10和数据处理端20，其中，

可视化前端10，用于获取针对任一模型的模型管理请求，并发送至数据处理端；接收任一模型的模型管理结果，并展示模型管理结果。

数据处理端20，用于接收模型管理请求，并根据模型管理请求对任一模型进行模型管理，以生成针对任一模型的模型管理结果。

本申请实施例中，可视化前端10包括用户交互层10-1；数据处理端20包括数据层20-1、基础设施层20-2和引擎框架层20-3。

下面分别针对用户交互层10-1、数据层20-1、基础设施层20-2和引擎框架层20-3进行解释说明。

针对数据层20-1，数据是算法模型训练的原料，数据层为算法开发提供数据支撑，包括数据采集、分发、分析及特征处理，为模型开发准备好加工好的数据。数据来源包括内部业务数据、生态合作数据、和商业采购数据等。

针对基础设施层20-2，为服务器提供算力、网络、存储基础设施，包含服务器、加速卡、系统运行环境以及本地存储、分布式块存储、分布式文件存储等存储管理方式，保障算法开发及服务运行的负载性能、稳定性和强健性；同时，对算法开发、模型训练、部署、服务运行依赖的镜像基于镜像仓库进行统一管理。

针对引擎框架层20-3，为服务器各类模型训练任务、模型服务提供引擎框架，以提高模型构建、训练和部署服务发布效率，包括大数据引擎(Spark、Hive、Presto、Flink)、机器学习引擎(Spark、Alink)、模型训练引擎、自动学习引擎、图计算引擎、批量推理引擎、在线推理引擎、流水线引擎、格式转换/模型压缩框架、作业调度引擎、机器学习框架、深度学习框架等。同时基于统一资源调度引擎，对服务器运行的各类任务进行统一资源分配、调度，实现任务运行资源隔离和弹性扩缩容，提高资源利用效率。

针对用户交互层，为服务器用户提供从数据管理、模型开发训练、模型管理到模型部署、服务发布全流程标准化管理界面和工具，通过提供Notebook交互式建模、单机/分布式训练任务管理、组件拖拽式建模、自动学习等模型构建方式，满足算法和非算法工程师不同使用习惯、偏好的用户群体需求。

由此，本申请提出的模型管理服务器，可以提供前、后端分离的模型管理思路，并通过数据层、基础设施层、引擎框架层、用户交互层4层模块化设计，实现高灵活性和可扩展性的模型管理。同时，能够支持不同规模企业对模型管理服务器的需求，为机器学习与深度学习提供海量数据预处理、模型训练和可扩展的离线和/或在线按需部署能力。

进一步地，本申请提出的模型管理服务器，针对不同层，分别设置有多个模块，例如图13所示的模块设置方式。在具体应用场景中，可根据实际情况选用一个或多个模块以及某个模块中的一种或多种方式。

以将模型管理服务器提供的技术支持投射到一个典型的端到端机器学习上为例，从业务需求开始，用户可以根据对业务的理解，对数据源进行数据处理、特征工程、模型训练、模型部署等。

其中，数据源，包括但不限于数据集市、实时数仓、特征中心及数据集等；数据处理，包括但不限于数据清洗、特征工程及数据标注等；模型训练，包括但不限于交互式建模、任务式建模、可视化建模及自动化建模等；模型管理，包括但不限于模型仓库、格式转换、模型压缩、模型验证及模型更新等；模型部署，包括但不限于在线服务、批量服务及边缘服务等。

在数据管理环节，服务器实现多元异构数据源接入，并进行数据管理，如提供数据集市、实时数仓、特征中心、数据集管理等，支持数据快速访问、探索分析等工作。

在数据处理环节，通过配置化方式实现数据清洗、特征工程、数据标注等任务所需的软件环境和硬件资源，根据建模需要，从数据源获取对应数据进行处理，为下一步模型训练做准备。

在模型训练环节，提供Notebook交互式建模、单机/分布式训练任务管理、组件拖拽式建模、自动学习等建模方式，加载上一步处理好的数据，实现算法模型的灵活构建和训练。其中，训练好的模型是人工智能时代的重要资产，在模型管理环节通过模型仓库对模型及其元信息进行统一管理，同时提供格式转换、模型压缩、模型验证等工具，以满足不同场景下对模型压缩转换以及部署前的评估验证需求、

对于模型仓库中满足业务要求的模型，服务器提供引导式流程，便捷地将模型部署为在线推理服务、批量推理服务或边缘服务，并对外提供访问接口，以支撑业务中AI应用；对于线上部署的模型服务，由于数据异常、数据漂移等原因，可能导致模型效果变差，可在模型监控环节配置、定义响应的模型监控任务、预警规则和模型迭代控制策略，从而形成模型更新升级闭环。

进一步地，以采用基于K8S的微服务架构构成的模型管理服务器为例，对提供的前、后端分离的模型管理思路进行解释说明。

如图14所示，总体构架包括接入访问层、后台服务层以及底层资源层。下面分别针对接入访问层、后台服务层以及底层资源层进行解释说明。

针对接入访问层，主要包括以下三种方式：Web(World Wide Web，全球广域网)方式、命令行方式以及SDK/API方式。

其中，Web方式，是接入服务器的主要方式，服务器提供的所有功能都能通过Web页面使用，基于统一权限管理模块对菜单、按钮等功能进行权限控制。其中，Web方式，包括用户端和管理员端。

其中，命令行方式，指的是用户使用命令行工具进行训练任务提交、管理等的方式。该方式可在交互式开发环境的终端中使用。

其中，SDK/API方式，指的是服务器将面向用户的核心模块常用功能以SDK和API接口的方式开放，以便服务器外部系统直接调用服务器能力的方式。

针对后台服务层，基于高内聚、低耦合的理念，将服务器服务划分为服务聚合模块、模型开发模块、模型训练模块、模型部署模块、模型监控模块、自动学习模块、任务状态管理模块、存储管理模块、镜像服务模块。

其中，服务聚合模块，主要利用WebSocket和Web端进行交互，并提供了对外的SDK和API，开放服务器常用功能，以便服务器外部系统直接调用服务器能力。

其中，模型开发模块，向用户提供交互式建模服务，针对不同用户提供了Jupyterlab和RStudio两种类型的建模环境。用户可以根据实际项目需求，组合配置CPU、GPU等硬件资源需求以及从服务器内置镜像仓库中选择软件镜像。通过CephFS持久化用户数据和通过conda、pip安装的软件包等环境配置信息，保障环境的可复用；同时在资源分配方面采用弹性模式，即根据用户环境资源的实际利用率，动态调配资源，以提升资源利用率。

其中，模型训练模块，通过界面、CLI或SDK/API提交的训练任务都会提交到训练引擎，然后通过训练引擎提交到相应的训练资源池进行统一调度、运行。该模块使用operator机制，支持单机和分布式的模型训练。可挂载本地卷、云SSD盘等多种类型的存储至训练任务所在节点，为解决模型训练过程中数据I/O(Input/Output)开销较大问题。

其中，模型部署模块，包括离线部署和在线部署。离线部署是指训练好的模型部署为批量推理服务，通过标准接口与数据处理任务对接，触发推理任务的周期性运行；在线部署是指将用户模型部署成在线API服务，对外提供接口服务，支持3种类型的在线服务，python function、TF-Serving、PMML，同时提供负载均衡、灰度发布、A/B test等常用组件，避免了常用工程性代码的重复开发。

其中，模型监控模块，内置常用模型评估指标，并开发用户自定义接口，进行模型推理的准确性和/或稳定性进行监控，以探测模型效果是否退化或数据分布出现漂移。可选的，对于用户配置的监控指标，用户可在预警规则中设定相应的阈值，以触发模型异常预警通知。

其中，自动学习模块，以减少机器学习模型构建过程中对专业技术人才专业知识和超参数调优经验的依赖，模型构建人员无需开发代码，通过自动学习任务设计器配置模型学习任务的具体目标、相关约束条件以及模型训练集和验证集，借助自动学习引擎进行模型的构建和超参数的搜索，并将最优的N个模型保存至模型仓库。

其中，任务状态管理模块，利用K8S list-watch机制对提交给集群的所有服务、作业进行状态实时监控更新，最新状态存储至Redis(Remote Dictionary Server，远程字典服务)数据库，当web页面、CLI(客户端)、SDK/API请求时，即时返回服务最新状态。

其中，存储管理模块，实现用户在服务器上所拥有存储空间的统一查看、管理等，为所有用户默认提供1T的CephFS存储空间，供用户在模型开发、训练等环节使用。当存储空间不足时，用户提供提取扩容申请，该模块更新数据库中用户存储空间配额。

其中，镜像服务模块，利用docker(开源的应用容器引擎)in docker技术向用户提供了一个docker环境，便于构建个性化开发部署环境，以增加软件环境配置的灵活性，同时通过镜像仓库的统一管理实现镜像团队之间共享复用。

其中，API网关，服务器所有面向用户的服务均使用Ambassador(开源微服务网关)，通过在annotations(注解)里添加上相应的配置，利用http(Hyper Text TransferProtocol，超文本传输协议)path(路径)代理机制直接将服务代理给了用户。

针对底层资源层，负责服务器算力、网络、存储资源的统一管理、调度，保障算法开发及服务运行的负载性能、稳定性和强健性；为兼容不同业务场景基础设施的差异化配置，服务器基于K8S多集群管理机制，通过配置化方式实现开发、测试、预生产、不同业务生产环境的切换。服务器底层基于统一资源调度引擎，对服务器运行的各类任务进行统一资源分配、调度，实现任务运行资源隔离和弹性扩缩容，提高资源利用效率。

综上所述，本申请提出的模型管理服务器可以由多个模块组成，并可以在模型管理服务器的可视化前端供用户查看和选择。

需要说明的是，本申请提出的模型管理服务器提供了多种模型训练方式：包括非自动式模型训练方式(代码式模型训练方式)、半自动式模型训练方式(拖拽式模型训练方式)以及全自动式模型训练方式，并设计了对应的详细技术实现方案，全面满足了相关人员的多种需求。

下面分别针对非自动式模型训练方式(代码式模型训练方式)、半自动式模型训练方式(拖拽式模型训练方式)以及全自动式模型训练方式进行解释说明。

针对非自动式模型训练方式(代码式模型训练方式)，可选地，用户可以根据具体场景建模需要，通过配置化方式定义模型开发软件依赖环境和硬件资源，灵活申请创建云端建模环境。

需要说明的是，为能够及时释放闲置资源、提供资源使用率，针对非自动式模型训练方式，本申请提出以下优化策略，可选择性组合使用：

可选地，启动云端建模环境时，用户可自定义自动关闭时长，达到指定时长后，服务器将为用户自动关闭建模环境，及时释放硬件资源。

可选地，基于用户建模环境资源使用率和用户操作行为监控，当探测到建模环境用户建模环境资源使用率低于指定阈值，且用户无操作行为时间超过指定阈值时，服务器将为用户自动关闭建模环境，及时释放硬件资源。

可选地，基于用户建模环境资源使用率监控数据弹性扩缩容，当探测到建模环境用户建模环境资源使用率低于指定阈值，按照预设比率自动缩小硬件资源配额，当探测到建模环境用户建模环境资源使用率超过指定阈值，按照预设比率自动扩大硬件资源配额，但不超过用户申请硬件资源配额。

进一步地，可以管理建模所需数据管理。

需要说明的是，针对非自动式模型训练方式，本申请提出以下方案实现结构化、半结构化、非结构化数据的管理，以简化模型训练时数据获取流程，实现数据获取、模型训练的无缝衔接：

可选地，配置化方式接入异构数据源。服务器预置MySQL(关系型数据库管理系统)、Postgres、Redis、MangoDB、Hive、HBase、HDFS、CephFS等主流数据存储连接器，并提供模板以便用户自定义连接器，然后配置对应的连接、授权认证等相关参数，即可实现数据源的接入。可选的，服务器通过虚拟用户群组管理，实现用户数据权限的批量授权管理。

可选地，灵活获取数据。完成异构数据源接入的配置，服务器将在用户建模环境中初始化数据源访问配置，自动安装对应的客户端以及常用的数据读取工具。训练模块时，可通过原生命令行命令或工具包中的SDK读取训练所需数据。SDK读取数据底层，通过缓存技术实现近期数据缓存，以减少模型训练时反复读取同一份数据的网络I/O开销。

进一步地，可以进行模型训练任务管理。

需要说明的是，为满足不用场景不用用户群体使用偏好，针对非自动式模型训练方式，本申请提出Notebook、命令行终端、IDE三种方式实现算法模型的开发、调试与训练。服务器提供单机和分布式训练任务提交、停止、删除、修改、任务清单查看、任务日志查看、任务资源占用率查看等命令和对应的Python、Java语言SDK，实现试验参数追踪、版本对比和模型资产管理。

下面分别针对单机式、分布式模型训练方式进行解释说明。

作为一种可能的实现方式，单机式、分布式模型训练任务管理流程示意图如图15～16所示。进一步地，针对单机式训练任务配置和分布式训练任务配置，具有不同的实现方式。

针对单机式训练任务配置，代码来源，包括但不限于个人云盘及代码仓库等，此种情况下，通过设定代码路径(对应代码来源)、数据路径(对应数据来源)、模型路径(对应输出路径)及运行参数等，可以实现单机式训练任务配置。

针对分布式训练任务配置，通过设定包括AI引擎、镜像设置选项的软件环境、包括分布式策略(包括但不限于worker节点数量、ps节点数量及、chief节点数量等)、资源池及资源规格设置选项的硬件资源、包括超时时长、通知时机及通知方式的预警通知等，可以实现分布式训练任务配置。其中，可以将通知时机设置为训练成功、训练失败、训练超时等，可以将通知方式设置为邮件、咚咚声音、微信等方式进行通知。

可选地，用户通过配置化化界面填写训练任务相关参数，如训练任务的名称、版本号、描述等基本信息，训练任务代码来源、输入、输出以及运行参数、软件环境、硬件资源规格、预警通知等；或者直接通过上述服务器提供的命令行工具或者Python、Java语言SDK传入相应任务配置参数，进行训练任务提交。

可选地，后台服务以该版本任务唯一ID为key，记录配置参数至MySQL等数据库；同时基于K8S将任务调度至指定的资源池进行统一调度管理。

可选地，对于用户希望关注的训练任务运行过程中的其它超参数、模型评估指标以及学习率、损失函数等，直接通过API记录对应的变量名称，后台服务实时记录其值以及该版本任务对应的唯一ID至数据库。

可选地，对于某一版本训练任务训练出的模型，既可保存至服务器为用户提供的默认Ceph存储空间，后续通过可视化向导导入模型仓库，也可直接调用SDK注册至模型仓库。模型仓库采用高可用分布式存储，并记录模型文件对应的ID等元信息至数据库，以便后续通过ID与对应的训练任务配置参数、模型评估指标、学习率以及损失函数等关联。

可选地，由于本方案将每一版本训练任务的全流程配置参数全部自动采集至数据库，当需要对某些配置参数进行修改尝试新的试验时，可从历史版本任务创建新版本，修改对应配置参数即可。同上述步骤，后台服务自动采集新版本训练任务的全流程配置参数至数据库，从而实现便捷的试验任务版本管理、版本对比等，同时也保障了试验结果的可复现性。

针对半自动式模型训练方式(拖拽式模型训练方式)，可选地，用户可以基于对业务的理解，从组件库从拖拽对应的组件至建模画布，组织成有向无环图，并配置组件对应的参数，即可实现建模流程的构建。

进一步地，后台服务将流程图上的组件、组件对应的参数、组件的衔接关系以及该版本实验ID记录至数据库，并初始化组件类，构建一个具体的模型训练流程。

可选地，服务器统一调度模块根据模型训练流程中的各个组件及其配置，按照预设资源调度策略调度硬件资源，按照流程图顺序启动组件的运行。组件之间的数据通过磁盘缓存或者分布式内存技术进行传输共享。

可选地，对于某一版本训练任务训练出的模型直接存储至模型仓库。模型仓库采用高可用分布式存储，并记录模型文件对应的ID等元信息至数据库，以便后续通过ID与对应的训练任务配置参数、模型评估指标、学习率以及损失函数等关联。

其中，半自动式模型训练方式的建模流程如图17所示。

可选地，半自动式模型训练的具体实现形式可以为图像分类数据导入，基于图像分类训练算法，进行图像分类数据分割，并进行图像分类训练，最后进行图像分类验证控制。

针对自动式模型训练方式，如图18所示，由于构建一个满足业务要求的算法模型，设计数据清洗、特征工程、算法模型选择与神经网络架构设计、超参数调优等复杂过程，往往需要多次调参、尝试，费时耗力，同时也需要较丰富的算法专业知识，由此，为加速算法模型的落地速度，本申请支持自动式模型训练方式。

可选地，模型构建人员在无需编写代码，只需在自动机器学习任务设计器中主要配置以下三方面的参数：自动学习任务的目标类型(如分类、回归、目标检测、语义分割等)；硬件资源类型(CPU/GPU)和数量、并发执行数、运行终止条件(迭代次数、运行时长阈值、模型精度阈值等)、期望保存的性能最优模型文件以及超参数组合结果的数量等等；从元数据管理模块中选择模型训练需要的加工好的训练集和验证集，包括特征变量和目标变量的配置。以结构化数据集上二分类模型的自动学习任务设计为例，用户可以选择数据来源为数据仓库工具(Hlive)表、训练集占比为0.8、测试集占比为0.2、设置训练失败为通知时机以及设置以邮件方式进行通知。

可选地，后台服务将模型构建人员在自动机器学习任务设计器中配置的参数以及该版本自动学习任务唯一ID记录至数据库，并初始化出一个具体的自动学习任务。

可选地，服务器统一调度模块根据配置的硬件资源规格，将任务分发至预设的资源池中，基于任务排队机制，启动AutoML引擎，进行算法模型选择或神经网络架构搜索以及超参数调优等，并将搜索出的模型在预留的测试集上进行评估，按照模型类型输出对应的模型评估指标。

可选地，对于某一版本自动学习任务训练出的模型直接存储至模型仓库。模型仓库采用高可用分布式存储，并记录模型文件对应的ID、模型结构、模型大小等元信息至数据库，以便后续通过ID与对应的训练任务配置参数、模型评估指标、学习率以及损失函数等关联。

可选地，为使业务任务对自动学习训练出的模型有进一步的了解，为下一步的模型选择、部署提供参考依据，本方案设计了模型报告，直观展示自动学习任务的参数配置、模型在测试集上的推理结果和评估指标、特征重要性、模型的结构(如基础算法、神经网络结构、最终采用的超参数)、模型大小等。以结构化数据集上二分类模型的自动学习任务设计为例，还可以生成对应的模型报告，其中，模型报告可以包括训练参数、预测结果、评估指标以及模型结构等内容。

由此，本申请提出的模型管理服务器，通过支持代码式模型训练、拖拽式模型训练、自动学习模型训练三种模型训练方式，并设计了对应的详细技术实现方案，全面满足了算法和算法人员构建算法模型的需求。进一步地，通过数据源的无缝衔接、软件环境和硬件资源的灵活配置、训练任务的版本管理以及建模流程的统一标准化管理，极大简化了建模流程和提升模型开发效率。

进一步地，如图19所示，针对模型部署阶段，可选地，对于解决统一业务问题算法模型的多个版本，如上文所述，服务器均采集记录了模型评估指标的元数据信息，通过从数据库中查询所关注模型版本的元数据信息，可视化渲染、对比，通过人工手动或策略配置自动筛选出待部署的模型。

可选地，通过引导式界面，配置部署模型的基本信息、模型运行的软件环境和所需的硬件资源规格、上一步模型仓库中筛选的模型名称及版本、模型的输入/输出格式、对于批量推理服务而言的模型的调度策略或对于在线推理服务而言的服务超时时长、分布式实例数量等，模型服务发布引擎根据用户的配置，从模型仓库中拉取对应的模型、从镜像仓库中拉取软件环境对应的基础镜像，初始化出模型推理服务实例。

可选地，服务器统一调度模块根据配置的硬件资源规格，在对应的资源池中启动推理服务。

可选地，模型监控模块进行实时监测、计算该服务各容器实例的资源使用率等指标，如CPU使用率、GPU使用率、内存使用率、响应时延等，并进行不同时间粒度的汇总计算，根据模型服务实例扩缩容策略计算下一个时间窗口内期望的容器实例数量，然后借助Kubernetes中的横向自动扩缩容的功能(HPA)，自动化地调整容器实例数量，实现模型在线推理服务资源的动态调整。另一方面；模型监控模块根据预设监控指标，对模型推理的准确性和/或稳定性进行监控，以探测模型效果是否退化或数据分布出现漂移。但探测到异常时，触发模型验证模块，对模型的多版本进行验证评估，通过人工判断或策略配置自动筛选的方式筛选出满足业务部署上线标准的模型，进行线上模型的更新升级。

由此，本申请提出的模型管理服务器，能够通过对服务器训练的模型及其元数据信息进行自动采集和统一管理，并与模型部署环节无缝衔接。同时，对模型推理服务的模型稳定性和准确性进行报表展示和监控，配置预警策略，在触发预警策略时及时通知用户；对批量预测作业和模型在线服务提供统一管理和溯源追踪，实现端到端机器学习、深度学习流程的全生命周期管理。进一步地，通过容器化技术为每个用户提供了隔离的计算环境，按需分配，互不干扰，对模型开发、训练、部署环节所需的硬件资源基于统一资源调度引擎，进行统一资源分配、调度，实现任务运行资源隔离和弹性扩缩容，显著提高了资源利用效率。

基于同一申请构思，本申请实施例还提供了一种模型管理方法对应的装置。

图20为本申请实施例提供的模型管理装置的结构示意图。

如图20所示，该模型管理装置1000，包括：发送模块110、接收模块120和展示模块130。其中，发送模块110，用于获取针对任一模型的模型管理请求，并发送至所述数据处理端；

接收模块120，用于接收所述模型管理请求，并根据所述模型管理请求对所述任一模型进行模型管理，以生成针对所述任一模型的模型管理结果；

展示模块130，用于接收所述任一模型的所述模型管理结果，并展示所述模型管理结果。

根据本申请的一个实施例，发送模块120，还用于：所述可视化前端获取针对所述任一模型的管理方式选取请求，并发送至所述数据处理端；所述数据处理端接收所述管理方式选取请求，并根据所述管理方式选取请求，生成针对目标展示页面的调用指令发送至所述可视化前端；所述可视化前端接收所述调用指令，并从当前展示页面转至所述目标展示页面，以于所述目标展示页面上执行模型管理操作。

根据本申请的一个实施例，发送模块120，还用于：获取所述模型管理请求的请求类型，并根据所述请求类型对所述任一模型进行模型管理。

根据本申请的一个实施例，所述模型管理请求为模型开发请求，发送模块120，还用于：根据所述模型开发请求，确定所述任一模型的目标集成开发环境IDE；基于所述目标IDE，确定所述模型的目标建模环境和目标数据管理方式；根据所述目标建模环境和所述目标数据管理方式，构建所述模型。

根据本申请的一个实施例，所述模型管理请求为模型训练请求，发送模块120，还用于：根据所述模型训练请求，确定所述任一模型的目标训练方式；针对所述目标训练方式，获取所述任一模型的目标组件和目标训练配置参数；获取所述任一模型的训练任务，并基于所述目标组件和所述目标训练配置参数，执行针对所述任一模型的所述训练任务。

根据本申请的一个实施例，所述模型管理请求为模型部署请求，发送模块120，还用于：根据所述模型部署请求，确定目标部署方式；针对所述目标部署方式，获取所述任一模型的目标部署配置参数；基于所述目标部署配置参数，对所述任一模型进行部署。

根据本申请的一个实施例，所述模型管理请求为模型监控请求，发送模块120，还用于：根据所述模型监控请求，获取针对所述任一模型的目标监控策略，其中，所述目标监控策略包括目标监控配置参数以及模型服务实例部署方式；根据所述目标监控配置参数以及所述模型服务实例调整策略，对所述模型进行监控。

根据本申请的一个实施例，发送模块120，还用于：响应于检测到所述任一模型的资源配置参数大于所述目标监控配置参数，则根据所述模型服务实例调整策略调整模型服务实例的部署方式。

根据本申请的一个实施例，展示模块130，还用于：响应于检测到所述任一模型满足数据更新条件，则获取所述任一模型的模型数据以及元数据；根据所述模型数据以及所述元数据，对所述模型管理服务器中的镜像仓库的数据进行更新。

由此，本申请提供的模型管理装置，可以通过可视化前端获取针对任一模型的模型管理请求，并发送至数据处理端，进一步地数据处理端接收模型管理请求，并根据模型管理请求对任一模型进行模型管理，以生成针对任一模型的模型管理结果，进而使可视化前端接收任一模型的模型管理结果，并展示模型管理结果，使得用户可以通过模型管理服务器的可视化前端输入针对任一模型的模型管理请求，进而由数据处理端对模型进行管理，并最终由可视化前端将模型管理过程所涉及的必要信息进行可视化展示，提高了模型管理过程中的效率、灵活度及可靠性，降低了用户对于模型管理需要付出的学习成本，提升了用户体验。

基于同一申请构思，本申请实施例还提供了一种电子设备。

图21为本申请实施例提供的电子设备的结构示意图。如图21所示，该电子设备3000，包括存储器310、处理器320及存储在存储器310上并可在处理器320上运行的计算机程序，处理器执行程序时，实现前述的模型管理方法。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

应当注意的是，在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的部件或步骤。位于部件之前的单词“一”或“一个”不排除存在多个这样的部件。本申请可以借助于包括有若干不同部件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims

1.一种模型管理方法，其特征在于，适用于模型管理服务器，所述模型管理服务器包括可视化前端和数据处理端，所述方法包括以下步骤：

所述可视化前端获取针对任一模型的模型管理请求，并发送至所述数据处理端；

所述数据处理端接收所述模型管理请求，并根据所述模型管理请求对所述任一模型进行模型管理，以生成针对所述任一模型的模型管理结果；

所述可视化前端接收所述任一模型的所述模型管理结果，并展示所述模型管理结果。

2.根据权利要求1所述的方法，其特征在于，所述可视化前端获取针对任一模型的模型管理请求，并发送至所述数据处理端之后，还包括：

所述可视化前端获取针对所述任一模型的管理方式选取请求，并发送至所述数据处理端；

所述数据处理端接收所述管理方式选取请求，并根据所述管理方式选取请求，生成针对目标展示页面的调用指令发送至所述可视化前端；

所述可视化前端接收所述调用指令，并从当前展示页面转至所述目标展示页面，以于所述目标展示页面上执行模型管理操作。

3.根据权利要求2所述的方法，其特征在于，针对所述任一模型的管理方式包括非自动学习式模型管理方式、半自动学习式模型管理方式以及全自动学习式模型管理方式中的任意一种。

4.根据权利要求1所述的方法，其特征在于，所述根据所述模型管理请求对所述任一模型进行模型管理，包括：

获取所述模型管理请求的请求类型，并根据所述请求类型对所述任一模型进行模型管理。

5.根据权利要求4所述的方法，其特征在于，所述模型管理请求为模型开发请求，所述根据所述请求类型对所述任一模型进行模型管理，包括：

根据所述模型开发请求，确定所述任一模型的目标集成开发环境IDE；

基于所述目标集成开发环境IDE，确定所述模型的目标建模环境和目标数据管理方式；

根据所述目标建模环境和所述目标数据管理方式，构建所述模型。

6.根据权利要求4所述的方法，其特征在于，所述模型管理请求为模型训练请求，所述根据所述请求类型对所述任一模型进行模型管理，包括：

根据所述模型训练请求，确定所述任一模型的目标训练方式；

针对所述目标训练方式，获取所述任一模型的目标组件和目标训练配置参数；

获取所述任一模型的训练任务，并基于所述目标组件和所述目标训练配置参数，执行针对所述任一模型的所述训练任务。

7.根据权利要求4所述的方法，其特征在于，所述模型管理请求为模型部署请求，所述根据所述请求类型对所述任一模型进行模型管理，包括：

根据所述模型部署请求，确定目标部署方式；

针对所述目标部署方式，获取所述任一模型的目标部署配置参数；

基于所述目标部署配置参数，对所述任一模型进行部署。

8.根据权利要求4所述的方法，其特征在于，所述模型管理请求为模型监控请求，所述根据所述请求类型对所述任一模型进行模型管理，包括：

根据所述模型监控请求，获取针对所述任一模型的目标监控策略，其中，所述目标监控策略包括目标监控配置参数以及模型服务实例部署方式；

根据所述目标监控配置参数以及所述模型服务实例调整策略，对所述模型进行监控。

9.根据权利要求8所述的方法，其特征在于，所述根据所述目标监控配置参数以及所述模型服务实例调整策略，对所述模型进行监控之后，还包括：

响应于检测到所述任一模型的资源配置参数大于所述目标监控配置参数，则根据所述模型服务实例调整策略调整模型服务实例的部署方式。

10.根据权利要求1所述的方法，其特征在于，所述根据所述模型管理请求对所述任一模型进行模型管理，以生成针对所述任一模型的模型管理结果之后，还包括：

响应于检测到所述任一模型满足数据更新条件，则获取所述任一模型的模型数据以及元数据；

根据所述模型数据以及所述元数据，对所述模型管理服务器中的镜像仓库的数据进行更新。

11.一种模型管理装置，其特征在于，所述装置包括：

发送模块，用于获取针对任一模型的模型管理请求，并发送至所述数据处理端；

接收模块，用于接收所述模型管理请求，并根据所述模型管理请求对所述任一模型进行模型管理，以生成针对所述任一模型的模型管理结果；

展示模块，用于接收所述任一模型的所述模型管理结果，并展示所述模型管理结果。

12.一种模型管理服务器，其特征在于，所述模型管理服务器包括：可视化前端和数据处理端，其中，

所述可视化前端，用于获取针对任一模型的模型管理请求，并发送至所述数据处理端；接收所述任一模型的模型管理结果，并展示所述模型管理结果；

所述数据处理端，用于接收所述模型管理请求，并根据所述模型管理请求对所述任一模型进行模型管理，以生成针对所述任一模型的所述模型管理结果。

13.根据权利要求12所述的服务器，其特征在于，所述可视化前端包括用户交互层，所述数据处理端包括数据层、基础设施层和引擎框架层。

14.一种电子设备，其特征在于，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序时，实现如权利要求1-10中任一项所述的模型管理方法。

15.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-10中任一项所述的模型管理方法。