CN110401700A

CN110401700A - 模型加载方法及系统、控制节点及执行节点

Info

Publication number: CN110401700A
Application number: CN201910596970.5A
Authority: CN
Inventors: 王跃铭; 李继良
Original assignee: Alibaba Group Holding Ltd
Current assignee: Advanced New Technologies Co Ltd; Advantageous New Technologies Co Ltd
Priority date: 2019-07-03
Filing date: 2019-07-03
Publication date: 2019-11-01
Anticipated expiration: 2039-07-03
Also published as: CN110401700B; WO2021000570A1

Abstract

本发明提供了一种模型加载方法及系统、控制节点及执行节点，其中，该模型加载方法，包括：根据预设的执行脚本和若干执行节点的资源信息，确定各个所述执行节点对应的加载任务；其中，不同的执行节点部署在不同的集群节点上；分别向所述若干执行节点发送加载请求，以使所述执行节点根据对应的加载请求启动若干执行进程，并使所述若干执行进程启动若干模型服务框架、每个所述模型服务框架加载若干模型；其中，所述加载请求中包括：所述执行节点对应的加载任务；所述执行进程与所述模型服务框架一一对应。

Description

模型加载方法及系统、控制节点及执行节点

技术领域

本发明涉及计算机技术领域，特别涉及一种模型加载方法及系统、控制节点及执行节点。

背景技术

随着机器学习技术的快速发展，模型预测已经成为一种重要的线上服务。为了提供模型预测服务，在提供模型预测服务之前，需要先在集群节点中加载相应的模型。

目前，在一个集群节点中仅启动一个模型服务框架，通过该模型服务框架加载若干模型。但是，当该模型服务框架发生异常时，需要重启该模型服务框架所在的集群节点，待集群节点重启成功后重新启动模型服务框架并重新加载已经部署过在该集群节点上的模型。

因此，现有的模型加载方法使得系统的可用性较低。

发明内容

鉴于此，本发明实施例提供了一种模型加载方法及系统、控制节点及执行节点，能够提高系统的可用性。

第一方面，本发明实施例提供了一种模型加载方法，包括：

根据预设的执行脚本和若干执行节点的资源信息，确定各个所述执行节点对应的加载任务；其中，不同的执行节点部署在不同的集群节点上；

分别向所述若干执行节点发送加载请求，以使所述执行节点根据对应的加载请求启动若干执行进程，并使所述若干执行进程启动若干模型服务框架、每个所述模型服务框架加载若干模型；其中，所述加载请求中包括：所述执行节点对应的加载任务；所述执行进程与所述模型服务框架一一对应。

第二方面，本发明实施例提供了一种模型加载方法，包括：

接收控制节点发送的加载请求；所述加载请求中包括：执行节点对应的加载任务；所述执行节点对应的加载任务由所述控制节点根据预设的执行脚本和若干执行节点的资源信息确定；其中，不同的执行节点部署在不同的集群节点上；

根据所述加载请求启动若干执行进程，以使所述若干执行进程启动若干模型服务框架、每个所述模型服务框架加载若干模型；其中，所述执行进程与所述模型服务框架一一对应。

第三方面，本发明实施例提供了一种控制节点，包括：

确定单元，用于根据预设的执行脚本和若干执行节点的资源信息，确定各个所述执行节点对应的加载任务；其中，不同的执行节点部署在不同的集群节点上；

发送单元，用于分别向所述若干执行节点发送加载请求，以使所述执行节点根据对应的加载请求启动若干执行进程，并使所述若干执行进程启动若干模型服务框架、每个所述模型服务框架加载若干模型；其中，所述加载请求中包括：所述执行节点对应的加载任务；所述执行进程与所述模型服务框架一一对应。

第四方面，本发明实施例提供了一种执行节点，包括：

接收单元，用于接收控制节点发送的加载请求；所述加载请求中包括：执行节点对应的加载任务；所述执行节点对应的加载任务由所述控制节点根据预设的执行脚本和若干执行节点的资源信息确定；其中，不同的执行节点部署在不同的集群节点上；

启动单元，用于根据所述加载请求启动若干执行进程，以使所述若干执行进程启动若干模型服务框架、每个所述模型服务框架加载若干模型；其中，所述执行进程与所述模型服务框架一一对应。

第五方面，本发明实施例提供了一种模型加载系统，包括：上述任一实施例所述的控制节点和上述任一实施例所述的执行节点。

本发明实施例采用的上述至少一个技术方案能够达到以下有益效果：该方法通过部署在不同集群节点中的执行节点在每个集群节点中启动若干模型服务框架，并通过每个模型服务框架加载若干模型。该方法能够在一个集群节点中部署若干模型服务框架，一个模型服务框架发生异常时，不需要重启集群节点，集群节点中的其他模型服务框架仍然可以正常工作，能够提高系统的可用性。

附图说明

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

图1是本发明一个实施例提供的一种模型加载方法的流程图；

图2是本发明另一个实施例提供的一种模型加载方法的流程图；

图3是本发明一个实施例提供的一种控制节点的结构示意图；

图4是本发明一个实施例提供的一种执行节点的结构示意图；

图5是本发明另一个实施例提供的一种执行节点的结构示意图；

图6是本发明一个实施例提供的一种模型加载系统的结构示意图；

图7是本发明又一个实施例提供的一种模型加载方法的流程图；

图8是本发明一个实施例提供的一种集群的结构示意图；

图9是本发明一个实施例提供的一种基于Ray的集群的结构示意图。

具体实施方式

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

传统的模型加载方法中，在一个集群节点中仅启动一个模型服务框架，通过该模型服务框架加载若干模型。对于不同的模型，其部署的方式是在同一个模型服务框架上，加载不同的模型。

但是，当该模型服务框架发生异常时，需要重启该模型服务框架所在的集群节点，待集群节点重启成功后重新启动模型服务框架并重新加载已经部署过在该集群节点上的模型，而重启集群节点的成本较高。并且，该方法的部署方式是按照机器粒度切分，即在一个集群节点中仅能启动一个模型服务框架，容易造成集群节点资源的浪费。另外，同一个模型服务框架上加载多个计算密集的模型，会形成资源抢占，影响服务性能。

鉴于此，本发明实施例提供了一种模型加载方法，该方法应用于控制节点，如图1所示，该方法可以包括以下步骤：

步骤101：根据预设的执行脚本和若干执行节点的资源信息，确定各个执行节点对应的加载任务；其中，不同的执行节点部署在不同的集群节点上。

集群节点是集群中的一个单元，具备相对独立的运行环境，可以是物理机、虚拟机和容器中任意一种或多种。

执行节点，是一个独立的进程，负责本节点的任务调度。

控制节点：是一个独立的进程，负责全局协调不同执行节点之间的任务调度。

执行进程：用户级别的进程，负责启动模型服务框架和管理其生命周期。

模型服务框架可以包括：HTTP框架和Tensorflow框架等，其中，Tensorflow框架是一种开源的机器学习框架。以下实施例将以Tensorflow框架为例进行说明。

模型服务框架由执行进程启动，负责执行具体的预测计算请求，例如接收请求中的特征数据进行计算得到预测分数后返回。

执行节点的资源信息包括：执行节点所在的集群节点的CPU核数，和/或，执行节点所在的集群节点的内存剩余容量。

对于集群中的各个节点，可以通过在节点中运行部署脚本，在集群节点中部署服务。通过运行部署脚本部署控制节点，并分别在各个集群节点中部署执行节点，并将其挂靠到控制节点中，各个执行节点将其资源信息上报给控制节点，则服务部署完成。

根据预设的执行脚本和若干执行节点的资源信息，确定各个执行节点对应的加载任务，包括：

根据执行脚本中声明的模型的总数、各个模型对应的资源信息和若干执行节点的资源信息，确定各个执行节点对应的模型的数量。即执行节点对应的加载任务包括：执行节点对应的模型的数量，当然，执行节点对应的加载任务中还可以包括执行脚本中针对模型及模型服务框架的声明。

模型对应的资源信息指的是模型对应的内存容量，即加载模型需要的内存容量。

需要说明的是，执行脚本中针对模型服务框架的声明可以仅有一种类型，也可以有不同的类型。与之类似的是，执行脚本中声明的模型也可以属于不同的类型。

例如，当声明的模型服务框架属于不同的类型时，则根据执行脚本中声明的不同类型模型的总数、各个模型对应的资源信息和若干执行节点的资源信息，确定各个执行节点对应的模型及该模型的数量。

步骤102：分别向若干执行节点发送加载请求，以使执行节点根据对应的加载请求启动若干执行进程，并使若干执行进程启动若干模型服务框架、每个模型服务框架加载若干模型；其中，加载请求中包括：执行节点对应的加载任务，执行进程与模型服务框架一一对应。

该方法通过部署在不同集群节点中的执行节点在每个集群节点中启动若干模型服务框架，并通过每个模型服务框架加载若干模型。该方法能够在一个集群节点中部署至少两个模型服务框架，一个模型服务框架发生异常时，不需要重启集群节点，集群节点中的其他模型服务框架仍然可以正常工作，能够提高系统的可用性。

在本发明的一个实施例中，为了降低资源消耗，每个模型服务框架加载一个模型。

如图2所示，本发明实施例提供了一种模型加载方法，该方法应用于执行节点，包括：

步骤201：接收控制节点发送的加载请求；加载请求中包括：执行节点对应的加载任务；执行节点对应的加载任务由控制节点根据预设的执行脚本和若干执行节点的资源信息确定；其中，不同的执行节点部署在不同的集群节点上。

步骤202：根据加载请求启动若干执行进程，以使若干执行进程启动若干模型服务框架、每个模型服务框架加载若干模型；其中，执行进程与模型服务框架一一对应。

在本发明的一个实施例中，加载请求中还包括：执行脚本中针对执行进程的声明；

根据加载请求启动若干执行进程，包括：根据执行脚本中针对执行进程的声明启动若干执行进程。

在本发明的一个实施例中，加载请求中还包括：执行脚本中针对模型服务框架的声明；

若干执行进程启动若干模型服务框架，包括：若干执行进程根据执行脚本中针对模型服务框架的声明启动若干模型服务框架。

在本发明的一个实施例中，为了进一步提高系统的可用性，该方法还包括：当监测到若干执行进程中目标执行进程失联时，重建目标执行进程。

如图3所示，本发明实施例提供了一种控制节点，包括：

确定单元301，用于根据预设的执行脚本和若干执行节点的资源信息，确定各个执行节点对应的加载任务；其中，不同的执行节点部署在不同的集群节点上；

发送单元302，用于分别向若干执行节点发送加载请求，以使执行节点根据对应的加载请求启动若干执行进程，并使若干执行进程启动若干模型服务框架、每个模型服务框架加载若干模型；其中，加载请求中包括：执行节点对应的加载任务，执行进程与模型服务框架一一对应。

在本发明的一个实施例中，确定单元301，用于根据执行脚本中声明的模型的总数、各个模型对应的资源信息和若干执行节点的资源信息，确定各个执行节点对应的模型的数量。

在本发明的一个实施例中，集群节点，包括：物理机、虚拟机和容器中任意一种或多种。

在本发明的一个实施例中，执行节点的资源信息，包括：执行节点所在的集群节点的CPU核数，和/或，执行节点所在的集群节点的内存剩余容量。

如图4所示，本发明实施例提供了一种执行节点，包括：

接收单元401，用于接收控制节点发送的加载请求；加载请求中包括：执行节点对应的加载任务；执行节点对应的加载任务由控制节点根据预设的执行脚本和若干执行节点的资源信息确定；其中，不同的执行节点部署在不同的集群节点上；

启动单元402，用于根据加载请求启动若干执行进程，以使若干执行进程启动若干模型服务框架、每个模型服务框架加载若干模型；其中，执行进程与模型服务框架一一对应。

在本发明的一个实施例中，如图5所示，该执行节点还包括：监测单元403；

监测单元403，用于当监测到若干执行进程中目标执行进程失联时，重建目标执行进程。

启动单元402，用于根据执行脚本中针对执行进程的声明启动若干执行进程。

启动单元402，用于以使若干执行进程根据执行脚本中针对模型服务框架的声明启动若干模型服务框架。

如图6所示，本发明实施例提供了一种模型加载系统，包括：上述任一实施例的控制节点601和上述任一实施例的执行节点602。

模型加载系统中的执行节点的数量可以根据实际需求进行设置，例如，模型加载系统中包括控制节点601和2个执行节点602。

如图7所示，本发明实施例以图8所示的集群为例，对模型加载方法进行详细的说明，该方法包括：

步骤701：控制节点根据预设的执行脚本和3个执行节点的资源信息，确定各个执行节点对应的加载任务；其中，不同的执行节点部署在不同的物理机上。

图8所示的集群包括物理机1、物理机2、物理机3和物理机4。其中，控制节点部署在物理机1中，3个执行节点分别部署在物理机2、物理机3和物理机4上。

执行脚本中声明模型服务框架、模型服务框架的数量、执行进程、模型、模型的总数、各个模型对应的资源信息。

在本发明实施例中，模型服务框架皆为Tensorflow框架，Tensorflow框架的数量为9个，每个Tensorflow框架加载2个相同的模型，模型的总数为18个。

根据各个执行节点所在的集群节点的内存剩余容量、各个模型对应的内存容量和模型的总数，确定各个执行节点对应的模型的数量。在本发明实施例中，执行节点对应的加载任务包括：执行节点对应的模型的数量。

假设加载任务被分配至3个执行节点，每个执行节点对应的模型的数量均为6个。

步骤702：控制节点分别向3个执行节点发送加载请求，加载请求中包括：执行节点对应的模型的声明、执行节点对应的加载任务、执行脚本中针对执行进程的声明、执行节点对应的Tensorflow框架的声明和执行节点对应的Tensorflow框架的数量。

在实际应用场景中，执行节点对应的模型的声明、执行脚本中针对执行进程的声明、执行节点对应的Tensorflow框架的声明和执行节点对应的Tensorflow框架的数量还可以包含在执行节点对应的加载任务中。

在本发明实施例中，各个执行节点接收到的加载请求中的内容相同，现仅以一个执行节点的加载请求为例进行说明。加载请求中包括：执行节点对应的Tensorflow框架的声明、执行节点对应的Tensorflow框架的数量为3个、执行脚本中针对执行进程的声明、执行节点对应的模型的声明、执行节点对应的模型的数量为6个。

步骤703：执行节点接收控制节点发送的加载请求。

步骤704：执行节点根据执行脚本中针对执行进程的声明、执行节点对应的Tensorflow框架的数量启动若干执行进程。

执行节点对应的Tensorflow框架的数量等于执行进程的数量

步骤705：若干执行进程根据执行节点对应的Tensorflow框架的声明启动若干Tensorflow框架，执行进程与Tensorflow框架一一对应。

执行进程根据执行节点对应的Tensorflow框架的声明启动Tensorflow框架。

步骤706：每个Tensorflow框架根据执行节点对应的模型的声明、执行节点对应的加载任务加载若干模型。

Tensorflow框架根据执行节点对应的模型、执行节点对应的加载任务(即执行节点对应的模型的数量)加载若干模型。

在本发明实施例中，每个Tensorflow框架加载2个模型。

步骤707：执行节点当监测到若干执行进程中目标执行进程失联时，重建目标执行进程。

各个执行节点可以对执行进程的运行情况进行监测，当目标执行进程失联时，及时重建目标执行进程，能够降低目标执行进程失联对模型预测过程的影响。

当模型服务框架存在多种类型、加载的模型也存在多种类型时，执行脚本中声明各种模型服务框架、每种模型服务框架的数量、每种模型服务框架对应的执行进程、各种模型、模型的总数、各个模型对应的资源信息。执行脚本中还可以声明每种模型的数量等信息。

相应的，执行节点接收到的加载请求中包括：执行节点对应的模型服务框架的声明、执行节点对应的每种模型服务框架的数量、执行节点对应的执行进程的声明、执行节点对应的模型的声明、执行节点对应的每种模型的数量。

在实际应用场景中，技术人员可以通过改变执行脚本来实现模型服务框架的扩容、缩容、上线、下线等，实现对模型服务框架的动态调整。该方法通过执行进程提供一个轻量级的资源隔离，可以保证资源的独占性，避免一个集群节点上的模型全部加载到一个模型服务框架上导致的资源抢占问题。该方法可以通过执行节点监测执行进程，并在执行进程失联时进行重建，可以轻量级地自动实现模型服务框架的失败重启，无需重启模型服务框架所在的集群节点。

在实际应用场景中，上述实施例提供的方法及装置，可以基于一种开源的分布式执行引擎Ray实现，此时，服务为Ray服务，执行脚本为Driver脚本，控制节点为Ray head节点，执行节点为Ray节点，执行进程为ray-actor。图9所示的集群与图8所示的集群相对应，是一种基于Ray的集群。

Ray head节点为Ray服务的头节点，ray-actor为Ray服务定义的资源封装，Driver脚本是用户自定义的基于Ray API和Tensorflow API的执行脚本，Driver脚本中按照RayAPI声明模型的总数、各个模型对应的资源信息。Driver脚本中还可以按照Ray API声明ray-actor、模型服务框架等。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device，PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application SpecificIntegrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC625D、Atmel AT91SAM、MicrochipPIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

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

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

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

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

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个......”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims

1.一种模型加载方法，包括：

2.如权利要求1所述的模型加载方法，

所述根据预设的执行脚本和若干执行节点的资源信息，确定各个所述执行节点对应的加载任务，包括：

根据所述执行脚本中声明的所述模型的总数、各个所述模型对应的资源信息和所述若干执行节点的资源信息，确定各个所述执行节点对应的所述模型的数量。

3.如权利要求1或2所述的模型加载方法，

所述集群节点，包括：物理机、虚拟机和容器中任意一种或多种；

和/或，

所述执行节点的资源信息，包括：所述执行节点所在的集群节点的CPU核数，和/或，所述执行节点所在的集群节点的内存剩余容量。

4.一种模型加载方法，包括：

5.如权利要求4所述的模型加载方法，进一步包括：

当监测到所述若干执行进程中目标执行进程失联时，重建所述目标执行进程。

6.如权利要求4所述的模型加载方法，

所述加载请求中还包括：所述执行脚本针对执行进程的声明；

所述根据所述加载请求启动若干执行进程，包括：

根据所述执行脚本针对执行进程的声明启动所述若干执行进程；

和/或，

所述加载请求中还包括：所述执行脚本针对模型服务框架的声明；

所述若干执行进程启动若干模型服务框架，包括：

所述若干执行进程根据所述执行脚本针对模型服务框架的声明启动若干模型服务框架。

7.如权利要求4-6中任一所述的模型加载方法，

和/或，

8.一种控制节点，包括：

9.如权利要求8所述的控制节点，

所述确定单元，用于根据所述执行脚本中声明的所述模型的总数、各个所述模型对应的资源信息和所述若干执行节点的资源信息，确定各个所述执行节点对应的所述模型的数量。

10.如权利要求8或9所述的控制节点，

和/或，

11.一种执行节点，包括：

12.如权利要求11所述的执行节点，进一步包括：监测单元；

所述监测单元，用于当监测到所述若干执行进程中目标执行进程失联时，重建所述目标执行进程。

13.如权利要求11所述的执行节点，

所述启动单元，用于根据所述执行脚本针对执行进程的声明启动所述若干执行进程；

和/或，

所述启动单元，用于以使所述若干执行进程根据所述执行脚本针对模型服务框架的声明启动若干模型服务框架。

14.如权利要求11-13中任一所述的执行节点，

和/或，

15.一种模型加载系统，包括：权利要求8-10任一所述的控制节点和权利要求11-14任一所述的执行节点。