1.本技术涉及计算机技术领域，尤其涉及一种多框架学习模型部署装置和方法。
背景技术：2.随着人工智能的发展，工程开发人员会使用各种不同的机器学习框架进行学习模型的开发，如tensorflow、pytorch、xgboost、scikitlearn等，这些框架更多的是考虑内部的使用，无法适用其他框架的模型。
3.目前，模型工业化落地过程中不仅部署过程繁琐且复杂，而且往往会有不同框架的模型共存的情况。例如银行、公安等大型的工业化应用领域中，通常会使用各种框架的一批模型来解决各个方面的问题。
4.而多个框架的学习模型不仅部署困难，而且还会出现后续管理和调试困难的问题。
技术实现要素：5.本技术提供了一种多框架学习模型部署装置和方法，能够部署多个框架的学习模型，并且支持任何框架下的模型部署，该多框架学习模型部署装置具有易维护、易扩展、轻量级的特点。
6.第一方面，本技术提供了一种多框架学习模型部署装置，其特征在于，包括服务模块和一个或多个模型加载介质；
7.该服务模块包括模型加载单元、主服务单元和服务访问页面渲染引擎单元；
8.该一个或多个模型加载介质中的各个模型加载介质用于存储加载对应模型所需的相关文件；
9.该模型加载单元用于编译该各个模型加载介质存储的相关文件并加载对应模型的服务进程，以及获取该各个模型加载介质存储的相关文件中的模型信息，该主服务单元用于提供该各个模型加载介质对应模型的服务进程的接口，该服务访问页面渲染引擎单元用于调用各个接口，并根据该各个模型加载介质存储的相关文件中的模型信息渲染用于查看模型信息或者调试模型的页面。
10.在一个示例中，该模型加载介质包括模型文件单元、加载配置单元和外置环境单元，该各个模型加载介质用于存储加载对应模型所需的相关文件，包括：
11.该各个模型加载介质的模型文件单元用于存储模型文件和与模型文件对应的参数配置文件，该各个模型加载介质的加载配置单元用于存储模型输入数据处理的逻辑脚本文件和/或模型输出数据处理的逻辑脚本文件，该各个模型加载介质的外置环境单元用于存储该模型文件的环境依赖或应用依赖。
12.在一个示例中，该模型加载单元用于编译该各个模型加载介质存储的相关文件并加载对应模型的服务进程，包括：
13.该模型加载单元用于编译该各个模型加载介质的加载配置单元中的文件，以根据
该各个模型加载介质的模型文件和与模型文件对应的参数配置文件基于该模型文件的环境依赖或应用依赖加载该各个模型加载介质对应模型的服务进程。
14.在一个示例中，该服务模块还包括模型状态检查单元，该模型状态检查单元用于触发该模型加载单元编译该各个模型加载介质存储的相关文件并加载对应模型的服务进程。
15.在一个示例中，该模型状态检查单元用于触发该模型加载单元编译该各个模型加载介质存储的相关文件并加载对应模型的服务进程，包括：
16.该模型状态检查单元用于每隔固定时间确定该各个模型加载介质是否更新；
17.若该各个模型加载介质中至少一个模型加载介质更新，则该模型状态检查单元用于向该模型加载单元发送第一指令，该第一指令用于触发该模型加载单元重新编译该至少一个模型加载介质存储的相关文件并加载对应模型的服务进程。
18.在一个示例中，该模型状态检查单元用于根据该各个模型加载介质存储的相关文件确定状态记录表，该状态记录表用于记载该各个模型加载介质存储的相关文件的md5码，该模型状态检查单元用于每隔固定时间确定该各个模型加载介质是否更新，还包括：
19.该模型状态检查单元用于每隔固定时间计算该各个模型加载介质中相关文件的最新的md5码；
20.该模型状态检查单元用于根据该最新的md5码和该状态记录表记载的相对应的md5码，确定该各个模型加载介质是否更新。
21.在一个示例中，该模型加载单元用于编译该各个模型加载介质存储的相关文件并加载对应模型的服务进程，包括：
22.该模型加载单元用于获取来自该模型状态检查单元的第二指令，该第二指令包括该各个模型加载介质中待加载的模型加载介质的地址，该第二指令用于指示该模型加载单元加载该待加载的模型加载介质；
23.该模型加载单元用于根据该第二指令确定该待加载的模型加载介质；
24.该模型加载单元用于编译该待加载的模型加载介质中的相关文件并加载对应模型的服务进程。
25.在一个示例中，该主服务单元包括管理进程和多个工作进程，每一工作进程用于调用该各个模型加载介质中的一个模型加载介质对应模型的服务进程，该管理进程用于触发该模型状态检查单元确定该各个模型加载介质是否更新；
26.若该各个模型加载介质中至少一个模型加载介质更新，该模型状态检查单元用于重新确定该状态记录表，并触发该模型加载单元重新编译该至少一个模型加载介质存储的相关文件并加载对应模型的服务进程；
27.该管理进程用于确定该状态记录表的多个副本，并将该多个副本分发给该多个工作进程；
28.该多个工作进程中每个工作进程基于该多个副本中的一个副本重新调用对应的模型的服务进程。
29.第二方面，本技术提供了一种多框架学习模型部署方法，利用上述多框架学习模型部署装置以及任意实现方式的装置，该方法包括：
30.获取该一个或多个模型加载介质；
31.该模型加载单元确定该各个模型加载介质存储的加载对应模型所需的相关文件；
32.该模型加载单元编译该各个模型加载介质存储的相关文件并加载对应模型的服务进程，以及获取该各个模型加载介质存储的相关文件中的模型信息；
33.该模型加载单元发送该各个模型加载介质存储的模型信息；
34.该主服务单元接收该各个模型加载介质存储的模型信息，并提供该各个模型加载介质对应模型的服务进程的接口；
35.该服务访问页面渲染引擎单元接收该各个模型加载介质存储的模型信息，并根据该各个模型加载介质存储的模型信息渲染用于查看模型信息或者调试模型的页面。
36.在一个示例中，该服务模块还包括模型状态检查单元，该方法还包括：
37.该模型状态检查单元触发该模型加载单元编译所述各个模型加载介质存储的相关文件并加载对应模型的服务进程。
38.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现以上任一实施例所提供方法的步骤。
39.一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以上任一实施例所提供方法的步骤。
40.在部署多个框架的学习模型时，将每个模型的相关文件存储到一个模型加载介质中，然后将各个模型加载介质放在指定的文件目录下。由于每个模型加载介质对应一个模型，各个模型加载介质之间是独立的，互不干扰。因此，实现了将各个模型的加载编译的空间解耦。同时一个模型加载介质中包括了一个模型编译加载所需的所有文件，因此保证了该模型在落地前和落地后的运行和效果的一致性。该装置的模型加载单元编译各个模型加载介质存储的相关文件并加载对应模型的服务进程，主服务单元管理各个模型加载介质对应的模型服务进程，为服务访问页面渲染引擎单元提供各个模型服务进程的接口，以使得所述服务访问页面渲染引擎单元能够调用各个模型服务进程的接口。服务访问页面渲染引擎单元能够提供给用户查看各个模型信息或者调试各个模型的页面。本技术方案实现了各个模型及其运行环境的相互独立，对于后续的管理维护调试都极为方便，具有易维护的特点。另外本技术方案对不同深度学习框架的模型的数量不作限定，无论多少个不同框架的模型，只需将每个模型所需文件存储到模型加载介质中，很容易就能集成到该部署装置中，具有易扩展的特点。由于封装好的模型加载介质除最基本的语言环境之外可以无任何外在依赖的用在各种各样的项目中，因此该模型加载介质具备轻量级的特点；另一方面，主服务单元的整体存在形式为一个单纯的docker镜像时，可以即装即用，无需复杂配置，该主服务单元也具备轻量级的特点。
附图说明
41.为了更清楚地说明本技术的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
42.图1是本技术一些实施例提供的一例多框架学习模型部署装置示意图；
43.图2是本技术一些实施例提供的一例模型加载介质更新方法示意性流程图；
44.图3是本技术一些实施例提供的又一例模型加载介质更新方法示意性流程图；
45.图4是本技术一些实施例提供的一例多框架学习模型部署方法示意性流程图。
具体实施方式
46.下面详细描述本技术的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本技术，而不能解释为对本技术的限制。需要说明的是，在不冲突的情况下，本技术中的实施例及实施例中的特征可以相互组合。
47.本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本技术的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。
48.学习模型在工业化落地过程中部署过程繁琐且复杂，而在多数的工业化场景下，往往会有不同框架模型共存的情况。由于不同的深度学习框架往往有各自的服务化组件，并且现有的深度学习模型服务化组件往往需要将模型处理为特定格式才能在其他的工业场景下落地实施，转化过程中会出现由于转化的某些操作导致本地调试和服务器使用效果不一致的风险。而且不同的模型有不同的服务化组件转成的特定格式，会造成后续模型管理困难、调试困难、维护成本高等一系列问题。
49.而针对上述问题，具备深度学习模型部署需求的场景也会采用web框架直接通过代码开发的方式进行模型部署的方案，但是这种方案也存在代码耦合和复用性低的问题，并且还存在后续优化成本高，模型集成成本高等问题。
50.为了解决上述问题，本技术实施例提供了一种多框架学习模型部署装置和方法，图1是本技术一些实施例提供的一例多框架学习模型部署装置示意图，下面结合图1对该装置进行说明。
51.该装置包括服务模块和一个或多个模型加载介质，下面以该装置包括一个模型加载介质为例进行说明。其中，该服务模块包括模型加载单元、主服务单元和服务访问页面渲染引擎单元，该模型加载介质用于存储加载模型所需的相关文件。
52.该模型加载单元用于编译该相关文件并加载该模型的服务进程，以及获取该相关文件中的模型信息，该主服务单元用于提供该模型的服务进程的接口，该服务访问页面渲染引擎单元用于调用该接口，并根据该模型信息渲染用于查看模型信息或者调试模型的页面。
53.其中，模型加载介质可理解为用于存储特定格式文件的磁盘上的存储空间。
54.加载模型所需的相关文件包括一个深度学习框架训练出的模型的输入数据输出数据，以及编译记载该模型的相关文件所需的文件。
55.主服务单元除了提供模型服务进程的接口以外，还管理模型服务进程的生命状态。另外，接收到外接的服务请求后，主服务单元还负责解析该服务请求，并转发给相应的模型服务进程。
56.在部署多个框架的学习模型时，将每个模型的相关文件存储到一个模型加载介质中，然后将各个模型加载介质放在指定的文件目录下。由于每个模型加载介质对应一个模型，各个模型加载介质之间是独立的，互不干扰，参见图1。因此，实现了将各个模型的加载编译的空间解耦。同时一个模型加载介质中包括了一个模型运行所需的所有文件，因此保证了该模型在落地前和落地后的运行和效果的一致性。由于没有对模型加载介质中有关模型的文件进行改动，因此该模型加载介质能够在其他应用中使用，具有极高的可复用性。该装置的服务模块中模型加载单元编译所述相关文件并加载所述模型的服务进程，主服务单元管理所述模型的服务进程，为服务访问页面渲染引擎单元提供所述模型的服务进程的接口，以使得所述服务访问页面渲染引擎单元能够调用所述模型服务进程的接口。服务访问页面渲染引擎单元能够提供给用户查看模型信息或者调试模型的页面。本技术方案实现了各个模型及其运行环境之间的相互独立，并且，通过将模型调用所需的所有物理依赖和逻辑依赖进行封箱的设计，用户只需接触服务模块来管理模型，而无需关注模型本身，最大程度上减少了模型和服务之间的耦合性，从而能够更加方便的对模型进行管理调试维护等操作。进一步地，本技术方案对不同深度学习框架的模型的数量不作限定，无论多少个不同框架的模型，只需将每个模型所需文件和环境存储到模型加载介质中，很容易就能集成到该部署装置中，并接入到服务模块中使得用户能够管理该模型。
57.在目前的模型部署方案中，均需在原始模型上经过处理才能与本地的模型服务对接，从而向用户提供服务访问。例如在使用特定框架提供的模型部署中，需要将原始模型进行模型处理以生成特定格式模型文件，然后再修改配置文件才能与本地的模型服务对接；又例如，在不限制框架的模型部署中，需要根据原始模型进行定制化开发，以生成模型接口，然后将该模型对应的服务逻辑文件打包才能与本地的模型服务对接。而本技术中只需将根据模型文件确定的模型加载介质放在指定的文件目录下，不需要任何配置文件和适应性代码的开发即可完成模型服务的对接和访问。并且由于模型加载介质和服务是解耦的，因此，对于模型服务的新增或更改都非常方便，不需要对本地服务逻辑进行更改。
58.在一个实施例中，该模型加载介质包括模型文件单元、加载配置单元和外置环境单元。
59.该模型文件单元用于存储模型文件和与模型文件对应的参数配置文件，该加载配置单元用于存储模型输入数据处理的逻辑脚本文件和/或模型输出数据处理的逻辑脚本文件，外置环境单元用于存储该模型文件的环境依赖或应用依赖。
60.即相关文件包括模型文件和与模型文件对应的参数配置文件、模型输入数据处理的逻辑脚本文件和/或模型输出数据处理的逻辑脚本文件以及该模型文件的环境依赖或应用依赖文件。
61.该模型加载单元用于编译该加载配置单元中的文件，以根据该模型文件和与模型文件对应的参数配置文件基于模型文件的环境依赖或应用依赖加载所述模型的服务进程。
62.模型文件中的内容包括了该模型算法用到的各种输入、输出数据的值。与该模型文件对应的参数配置文件用于辅助模型文件的运行。例如，在自然语言处理领域中，参数配置文件可将文字映射成数字被模型所识别，从而使得模型能够运行模型文件。
63.模型输入数据处理的逻辑脚本文件用于对模型的输入数据进行前置处理，模型输出数据处理的逻辑脚本文件用于对模型的输出数据进行后置处理。例如，在自然语言处理
领域中，输入的文本根据需要被前置处理后才能输入模型中。
64.模型文件的训练和运行需要特定的系统配置、环境等条件，这些条件统称为环境依赖或应用依赖。
65.上述方式中，由于一个模型加载介质中包括了一个模型编译加载所需的所有文件和环境依赖或应用依赖，加强了各个模型之间运行空间的解耦性和独立性。
66.在一个实施例中，该服务模块还包括模型状态检查单元，该模型状态检查单元用于触发该模型加载单元编译各个模型加载介质存储的相关文件并加载对应模型的服务进程。
67.上述方式中，模型状态检查单元触发该模型加载单元进行各个模型的服务进程的加载，避免了模型加载单元在没有模型需要加载时一直处于工作状态的问题。
68.在一个实施例中，该模型状态检查单元每隔固定时间确定该各个模型加载介质是否更新，若各个模型加载介质中存在至少一个模型加载介质更新，则该模型状态检查单元向该模型加载单元发送第一指令，该第一指令用于触发该模型加载单元重新编译要更新的至少一个模型加载介质中加载配置单元中的文件以加载需要更新的模型文件中的模型服务进程。模型加载单元接收到第一指令后，停止加载需要更新的模型对应的更新前的模型服务进程，然后再重新编译需要更新的模型所对应的模型加载介质中加载配置单元中的文件以加载该模型文件中的模型服务进程。
69.进一步地，该模型状态检查单元每隔固定时间确定是否有新的模型加载介质接入该装置。若有，则该模型状态检查单元确定第二指令，该第二指令包括该新的模型加载介质的地址，该第二指令指示模型加载单元加载新的模型加载介质。该模型状态检查单元向该模型加载单元发送该第二指令。该模型加载单元接收该第二指令后，根据第二指令确定待加载的该新的模型加载介质，并编译该新的模型加载介质的加载配置单元中的文件以加载新的模型服务进程。
70.其中，固定时间可根据需要设置，本技术对此不作限定。
71.该模型加载介质更新包括：模型文件更新、参数配置文件更新、逻辑文件更新等。
72.上述方式中，该模型状态检查单元每隔固定时间检查是否新增了模型加载介质，以及已接入该装置的模型加载介质的内部是否更新，能够及时触发模型加载单元重新加载模型服务进程。
73.示例性地，模型状态检查单元根据该模型加载介质中的文件确定状态记录表，该状态记录表用于记载该模型加载介质中文件的md5码，该模型状态检查单元确定该模型加载介质是否更新的方式包括：
74.该模型状态检查单元每隔固定时间计算该各个模型加载介质中相关文件的最新的md5码，然后根据该最新的md5码和该状态记录表记载的相对应的md5码，确定该各个模型加载介质是否更新。若更新，除了发送第一指令外，还根据最新的md5码更新该状态记录表。
75.例如，状态记录表中记载了模型的名称和该名称对应的md5码，该模型状态检查单元将最新的md5码根据其对应的模型名称，在状态记录表中查找原来的md5码，并将新的md5码和旧的md5码进行比较，确定md5码是否改变。若改变，则表示模型加载介质发生了更新。
76.示例性地，若模型状态检查单元确定了新接入该装置的模型加载介质，则将该新的模型加载介质的相关信息存入状态记录表。
77.同理，该模型状态检查单元每隔固定时间还能确定是否有模型加载介质被删除。若有，则删除状态记录表中有关被删除的模型加载介质的信息，并向模型加载单元发送第四指令，该第四指令用于指示模型加载单元停止并删除该被删除的模型加载介质对应的模型服务进程。模型加载单元接收该第四指令后，停止并删除该被删除的模型加载介质对应的模型服务进程。
78.其中，该状态记录表记载的信息是最近一次检查模型加载介质后确定的信息，状态记录表记载的信息包括：各个模型加载介质的相关信息和各个模型服务进程的相关信息。
79.模型加载介质的相关信息包括以下信息的一种或多种：该模型加载介质所在的位置(例如文件夹目录地址)、该模型加载介质的标识和该模型加载介质对应的md5码。
80.模型服务进程的相关信息包括以下信息的一种或多种：该模型服务进程对应的模型加载介质标识、模型信息和模型服务进程的接口。
81.其中，模型信息包括以下信息的至少一种：模型标识、模型调用方式、模型参数结构说明。
82.上述方式中，模型状态检查单元基于状态记录表记载的旧的模型加载介质的信息，和每隔固定时间确定的新的模型加载介质的信息做对比，能够准确地确定模型加载介质是否更新，以及是否有新的模型加载介质接入该装置。同时，若发生更新，则更新状态记录表能够保证状态记录表的及时性和准确性。由于本技术方案中，模型加载介质和服务模块是分离的，无论模型加载介质的新增、删除或更新，由于模型状态检查单元能够及时获取模型加载介质的状态，并指示模型加载单元进行相应地操作，因此，模型加载介质状态的改变都可以在不停机不重启的情况下进行。可以说本技术提供的多框架学习模型部署装置具有支持热部署的特点。
83.在一个实施例中，考虑到刚接入该装置的模型加载介质需要立刻被加载的需求，或者修改了已接入装置的模型加载介质需要立刻更新，若只是等着模型状态检查单元间隔固定时间后检查到更新，未免过于死板。因此，本技术还设计了如下方案：
84.主服务单元包括工作进程，该工作进程用于调用一个模型的服务进程。该装置提供的服务页面(即服务访问页面渲染引擎单元渲染的页面)接收到手动触发的检查模型加载介质的命令后，将该命令发送给主服务单元。主服务单元接收到该命令后确定第三指令，该第三指令用于指示所述模型状态检查单元确定各个模型加载介质是否有模型加载介质更新或确定是否有新增的模型加载介质接入该装置。主服务单元向工作进程发送该第三指令，该工作进程触发该模型状态检查单元确定已接入的模型加载介质是否更新，或者是否有新增的模型加载介质接入该装置。
85.上述方式中，通过手动触发模型状态检查单元检查已接入的模型加载介质是否更新，或者是否有新增的模型加载介质接入该装置，能够使得该装置加载模型加载介质更加灵活，更加人性化。
86.考虑到为了提升服务单元的资源利用率，本技术在主服务单元中使用了管理多工作进程的设计方式，每个请求(例如用于模型加载介质更新的请求)进入主服务单元后都会被管理进程分发至不同的工作进程中，每个工作进程单独享有自己的运行资源。但是也正是因为每个工作进程单独享有了自己的运行资源，其内存不共通，所以如果只是单纯的启
用多个工作进程去提升主运行进程的负载能力，因其具备的完全独立性会造成内存数据的独立性，就有可能造成数据的不一致性。例如图2所示(可结合上述手动更新模型加载介质的方式理解)，在该流程中，用户向管理进程发送模型加载介质更新的请求，管理进程将模型加载介质更新的请求随机分发给工作进程1，工作进程1根据该请求调用模型状态检查单元重新检查其负责的模型加载介质，若更新，则触发该模型加载单元重新编译该相关文件并加载该模型的服务进程，并且工作进程重新调用模型的服务进程。而其他工作进程由于没有收到更新请求，导致各个工作进程之间的数据不一致，当需要协同处理时，会出现问题。
87.为了使主运行进程在多进程的状态下能保证数据一致性，本技术将模型状态检查单元的加载及更新流程放在了主运行进程的管理进程中，管理进程在负责管理工作进程之余，同样也负责管理模型状态检查单元的状态，本技术将这种方式称为模型状态检查单元的预加载。
88.下面结合图3对模型状态检查单元的预加载方法进行说明：
89.该主服务单元包括管理进程和多个工作进程，每一工作进程用于调用一个模型的服务进程，该管理进程用于触发该模型状态检查单元确定多个模型加载介质是否更新，该多个模型加载介质用于加载该多个工作进程各自调用的模型的服务进程；
90.若该多个模型加载介质中至少一个模型加载介质更新，该模型状态检查单元用于重新确定该状态记录表，并触发该模型加载单元重新编译该相关文件并加载该模型的服务进程；
91.该管理进程用于确定该状态记录表的多个副本，并将该多个副本分发给该多个工作进程；
92.该多个工作进程中每个工作进程基于该多个副本中的一个副本重新调用模型的服务进程。
93.上述方式中，将模型状态检查单元的加载及更新状态检查表的流程放在了主运行进程的管理进程中，这样就能在保持数据一致性的同时尽可能多的提高服务器的资源利用率。
94.在一个实施例中，该多框架学习模型部署装置还包括环境介质，该环境介质用于存储一个或多个深度学习框架相关的环境依赖和/或用依赖。同时，模型加载单元在加载模型加载介质中的模型时，会根据依赖指示信息确定该模型所需的环境依赖和/或应用依赖。其中，该依赖指示信息用于指示该模型所需的环境依赖和/或应用依赖在环境介质中的地址。相对应地，模型加载介质中就不需要用户提供外置环境单元所需的环境依赖了。
95.具体地，首先根据提供服务的本地的系统类型、系统版本及语言版本确定并封装一个基础服务镜像。然后基于基础服务镜像中的信息构建各个深度学习框架相关的依赖内容，然后将这些依赖内容整个封装为一个环境介质，一个环境介质对应一个深度学习框架。最后将该基础服务镜像整合为服务模块的时候，会在模型加载单元配置上述指示信息。使得模型加载单元在加载模型加载介质中的模型时能够根据指示信息找到该模型所需的环境依赖和/或应用依赖。
96.上述方式中，在该多框架学习模型部署装置中设置环境介质，不需要用户提供外置环境单元所需的环境依赖，使得用户封装模型所需文件更加方便快捷。
97.这些环境介质中如果没有模型运行所需的依赖内容，则可根据用户需求自定义合适的环境介质。算法开发人员可以根据规定的环境介质封装方法，将模型加载所需的所有依赖打包为一个“黑箱”，这样在集成该模型的时候，该部署装置不需要关心这个模型用的是哪个框架，需要什么依赖，只需调用这个“黑箱”即可，而这个黑箱也和模型一起由算法开发人员提供。进一步实现了将深度学习框架依赖和程序主运行环境完全解耦，更好地支持多深度学习框架模型的部署。
98.基于上面的模型部署装置，本技术实施例还提供了模型部署方法，下面结合图4进行说明。
99.s110，获取一个或多个模型加载介质。
100.s120，该模型加载单元确定该各个模型加载介质存储的加载对应模型所需的相关文件。
101.s130，该模型加载单元编译该各个模型加载介质存储的相关文件并加载对应模型的服务进程，以及获取该各个模型加载介质存储的相关文件中的模型信息。
102.s140，该模型加载单元发送该各个模型加载介质存储的模型信息。
103.s150，该主服务单元接收该各个模型加载介质存储的模型信息，并提供该各个模型加载介质对应模型的服务进程的接口。
104.s160，该服务访问页面渲染引擎单元接收该各个模型加载介质存储的模型信息，并根据该各个模型加载介质存储的模型信息渲染用于查看模型信息或者调试模型的页面。
105.在一个示例中，该服务模块还包括模型状态检查单元，在确定该模型加载介质存储的加载模型所需的相关文件之前，该方法还包括：
106.s101，该模型状态检查单元确定该各个模型加载介质中待加载的模型加载介质。
107.s102，该模型状态检查单元触发该模型加载单元加载该待加载的模型加载介质。
108.在一个示例中，该模型加载单元发送该各个模型加载介质中的模型信息包括：
109.s131，该模型加载单元向该模型状态检查单元发送该各个模型加载介质中的模型信息。
110.s132，该模型状态检查单元接收该各个模型加载介质中的模型信息并向该主服务单元发送。
111.其他实现方式和效果参见上述有关模型部署装置中的描述，在此不再赘述。
112.以上结合具体实施例描述了本技术的基本原理，但是，需要指出的是，在本技术中提及的优点、优势、效果等仅是示例而非限制，不能认为这些优点、优势、效果等是本技术的各个实施例必须具备的。另外，上述公开的具体细节仅是为了示例的作用和便于理解的作用，而非限制，上述细节并不限制本技术为必须采用上述具体的细节来实现。
113.应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
114.本技术中涉及的器件、装置、设备、系统的方框图仅作为例示性的例子并且不意图
要求或暗示必须按照方框图示出的方式进行连接、布置、配置。如本领域技术人员将认识到的，可以按任意方式连接、布置、配置这些器件、装置、设备、系统。诸如“包括”、“包含”、“具有”等等的词语是开放性词汇，指“包括但不限于”，且可与其互换使用。这里所使用的词汇“或”和“和”指词汇“和/或”，且可与其互换使用，除非上下文明确指示不是如此。这里所使用的词汇“诸如”指词组“诸如但不限于”，且可与其互换使用。
115.还需要指出的是，在本技术的装置、设备和方法中，各部件或各步骤是可以分解和/或重新组合的。这些分解和/或重新组合应视为本技术的等效方案。
116.提供所公开的方面的以上描述以使本领域的任何技术人员能够做出或者使用本技术。对这些方面的各种修改对于本领域技术人员而言是非常显而易见的，并且在此定义的一般原理可以应用于其他方面而不脱离本技术的范围。因此，本技术不意图被限制到在此示出的方面，而是按照与在此公开的原理和新颖的特征一致的最宽范围。
117.为了例示和描述的目的已经给出了以上描述。此外，此描述不意图将本技术的实施例限制到在此公开的形式。尽管以上已经讨论了多个示例方面和实施例，但是本领域技术人员将认识到其某些变型、修改、改变、添加和子组合。
技术特征：1.一种多框架学习模型部署装置，其特征在于，包括服务模块和一个或多个模型加载介质；所述服务模块包括模型加载单元、主服务单元和服务访问页面渲染引擎单元；所述一个或多个模型加载介质中的各个模型加载介质用于存储加载对应模型所需的相关文件；所述模型加载单元用于编译所述各个模型加载介质存储的相关文件并加载对应模型的服务进程，以及获取所述各个模型加载介质存储的相关文件中的模型信息，所述主服务单元用于提供所述各个模型加载介质对应模型的服务进程的接口，所述服务访问页面渲染引擎单元用于调用各个接口，并根据所述各个模型加载介质存储的相关文件中的模型信息渲染用于查看模型信息或者调试模型的页面。2.根据权利要求1所述的装置，其特征在于，所述模型加载介质包括模型文件单元、加载配置单元和外置环境单元，所述各个模型加载介质用于存储加载对应模型所需的相关文件，包括：所述各个模型加载介质的模型文件单元用于存储模型文件和与模型文件对应的参数配置文件，所述各个模型加载介质的加载配置单元用于存储模型输入数据处理的逻辑脚本文件和/或模型输出数据处理的逻辑脚本文件，所述各个模型加载介质的外置环境单元用于存储所述模型文件的环境依赖或应用依赖。3.根据权利要求2所述的装置，其特征在于，所述模型加载单元用于编译所述各个模型加载介质存储的相关文件并加载对应模型的服务进程，包括：所述模型加载单元用于编译所述各个模型加载介质的加载配置单元中的文件，以根据所述各个模型加载介质的模型文件和与模型文件对应的参数配置文件基于该模型文件的环境依赖或应用依赖加载所述各个模型加载介质对应模型的服务进程。4.根据权利要求1所述的装置，其特征在于，所述服务模块还包括模型状态检查单元，所述模型状态检查单元用于触发所述模型加载单元编译所述各个模型加载介质存储的相关文件并加载对应模型的服务进程。5.根据权利要求4所述的装置，其特征在于，所述模型状态检查单元用于触发所述模型加载单元编译所述各个模型加载介质存储的相关文件并加载对应模型的服务进程，包括：所述模型状态检查单元用于每隔固定时间确定所述各个模型加载介质是否更新；若所述各个模型加载介质中至少一个模型加载介质更新，则所述模型状态检查单元用于向所述模型加载单元发送第一指令，所述第一指令用于触发所述模型加载单元重新编译所述至少一个模型加载介质存储的相关文件并加载对应模型的服务进程。6.根据权利要求5所述的装置，其特征在于，所述模型状态检查单元用于根据所述各个模型加载介质存储的相关文件确定状态记录表，所述状态记录表用于记载所述各个模型加载介质存储的相关文件的md5码，所述模型状态检查单元用于每隔固定时间确定所述各个模型加载介质是否更新，还包括：所述模型状态检查单元用于每隔固定时间计算所述各个模型加载介质中相关文件的最新的md5码；所述模型状态检查单元用于根据所述最新的md5码和所述状态记录表记载的相对应的md5码，确定所述各个模型加载介质是否更新。
7.根据权利要求4所述的装置，其特征在于，所述模型加载单元用于编译所述各个模型加载介质存储的相关文件并加载对应模型的服务进程，包括：所述模型加载单元用于获取来自所述模型状态检查单元的第二指令，所述第二指令包括所述各个模型加载介质中待加载的模型加载介质的地址，所述第二指令用于指示所述模型加载单元加载所述待加载的模型加载介质；所述模型加载单元用于根据所述第二指令确定所述待加载的模型加载介质；所述模型加载单元用于编译所述待加载的模型加载介质中的相关文件并加载对应模型的服务进程。8.根据权利要求6所述的装置，其特征在于，所述主服务单元包括管理进程和多个工作进程，每一工作进程用于调用所述各个模型加载介质中的一个模型加载介质对应模型的服务进程，所述管理进程用于触发所述模型状态检查单元确定所述各个模型加载介质是否更新；若所述各个模型加载介质中至少一个模型加载介质更新，所述模型状态检查单元用于重新确定所述状态记录表，并触发所述模型加载单元重新编译所述至少一个模型加载介质存储的相关文件并加载对应模型的服务进程；所述管理进程用于确定所述状态记录表的多个副本，并将所述多个副本分发给所述多个工作进程；所述多个工作进程中每个工作进程基于所述多个副本中的一个副本重新调用对应的模型的服务进程。9.一种多框架学习模型部署方法，其特征在于，利用权利要求1-8中任一项所述的装置，所述方法包括：获取所述一个或多个模型加载介质；所述模型加载单元确定所述各个模型加载介质存储的加载对应模型所需的相关文件；所述模型加载单元编译所述各个模型加载介质存储的相关文件并加载对应模型的服务进程，以及获取所述各个模型加载介质存储的相关文件中的模型信息；所述模型加载单元发送所述各个模型加载介质存储的模型信息；所述主服务单元接收所述各个模型加载介质存储的模型信息，并提供所述各个模型加载介质对应模型的服务进程的接口；所述服务访问页面渲染引擎单元接收所述各个模型加载介质存储的模型信息，并根据所述各个模型加载介质存储的模型信息渲染用于查看模型信息或者调试模型的页面。10.根据权利要求9所述的方法，其特征在于，所述服务模块还包括模型状态检查单元，所述方法还包括：所述模型状态检查单元触发所述模型加载单元编译所述各个模型加载介质存储的相关文件并加载对应模型的服务进程。
技术总结本申请提供了一种多框架学习模型部署装置和方法，该装置包括服务模块和一个或多个模型加载介质，该服务模块包括模型加载单元、主服务单元和服务访问页面渲染引擎单元；各个模型加载介质用于存储加载对应模型所需的相关文件。该服务模块用于根据各个模型所需的相关文件提供管理调试维护的服务访问。每个模型加载介质对应一个模型，各个模型加载介质之间相互独立，实现了将各个模型的加载编译的空间解耦。对于后续的管理维护调试都极为方便，具有易维护的特点。另外对不同深度学习框架的模型的数量不作限定，具有易扩展的特点。封装好的模型加载介质除最基本的语言环境之外可无任何外在依赖的用在各种各样的项目中，模型加载介质具备轻量级的特点。介质具备轻量级的特点。介质具备轻量级的特点。
技术研发人员：吴相博 李健铨 胡加明
受保护的技术使用者：鼎富智能科技有限公司
技术研发日：2022.07.20
技术公布日：2022/11/1
