具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

如图1所示，本实施例提供一种电子设备1，包括：至少一个处理器11和存储器12，图1中以一个处理器为例。处理器11和存储器12通过总线10连接。存储器12存储有可被处理器11执行的指令，指令被处理器11执行，以使电子设备1可执行下述的实施例中方法的全部或部分流程，以提高模型部署时服务器系统资源的利用率，提高模型部署的效率。

于一实施例中，电子设备1可以是手机、平板电脑、笔记本电脑、台式计算机或者多个计算机组成的大型计算系统等设备。

请参看图2，其为本申请一实施例的模型部署方法，该方法可由图1所示的电子设备1来执行，并可以应用于在服务器集群中部署算法模型的场景中，提高模型部署时服务器系统资源的利用率，提高模型部署的效率。

该方法包括如下步骤：

步骤201：获取算法模型库的历史访问信息和算法模型库中每个算法模型的性能信息。

在本步骤中，算法模型可以是基于神经网络或者深度学习的预测模型，算法模型库中包括多个待部署的算法模型。历史访问信息中至少包括模型库中每个算法模型的历史被访问的记录，比如访问次数、访问时间、访问事件等信息。每个算法模型都具备自身的性能信息，性能信息中可以包括模型占用的内存大小、部署模型需要的时长等信息。这些性能信息可以保存在模型库中，也可以单独保存在一个性能信息数据库中。可以分别从对应的数据库中读取到历史访问信息和性能信息。

于一实施例中，可以在服务器集群系统中增加模型流量统计模块，记录每个模型的一定时间内的访问次数统计，一定时间可以是一小时内、一天内、一周内等，具体的时间粒度可配置，根据实际业务需求更改。以此统计出每个算法模型的历史访问信息。

步骤202：根据历史访问信息和每个算法模型的性能信息，确定需要部署的目标模型种类和每种目标模型的副本数量。

在本步骤中，可以根据步骤201中获取到的历史访问信息和每个算法模型的性能信息，以及预设的筛选规则，确定需要部署的目标模型机及其副本数。比如筛选规则可以是：访问率达到特定阈值的算法模型才可以部署，如此，通过筛选的目标模型可以更加符合实际场景中模型的使用率，避免一些使用较少的模型也被盲目的部署在服务器集群上，浪费服务器资源。并且综合考虑每个模型的实际性能信息，来确定最终要部署的副本数量，可以进一步提高服务器资源利用率。

于一实施例中，步骤202可以包括：根据历史访问信息，从算法模型库中筛选出在预设时长内被访问次数大于或等于预设次数的至少一种类别的目标模型，并获取每种类别的目标模型的负载承受量。根据历史访问信息，统计服务器集群针对每种类别的目标模型需要提供的实际负载量。根据实际负载量和负载承受量，确定需要部署每种目标模型的副本数量。

在本步骤中，预设时长可以是一个小时、一天或者一周，预设次数可以是3次、10次等等，视情况而定，或者基于大数据对模型使用的分析结果，设定上述预设时长和预设次数。可以根据历史访问信息，将算法模型库中的算法模型分类，比如可以分类为：必须部署、可以部署和不需要部署的模型三种类型(或者还有第四类可部署也可不部署的)，其中必须部署的模型就是目标模型。分类时，依据历史访问信息，比如一小时内有访问或者一天内多于特定次访问的模型被归类为必须部署的目标模型，三天内没有访问的模型被归类为不需要部署的模型。基于上述规则，可以从算法模型库中筛选出目标模型。并可以从目标模型的性能信息中获取每种类别的目标模型的负载承受量。其中负载承受量可以是单个目标模型的最大可承受负载量，可以通过现有的模型压测方式测量出来，并保存在性能信息中。

在实际场景中，一种目标模型的副本数量由单个该目标模型副本的负载承受量和服务器集群针对该种类别的目标模型需要提供的CPU的实际负载量来决定。实际负载量可以通过上述流量统计模块记录的历史访问信息来确定，比如可以通过统计历史访问信息中针对该种目标模型服务器提供的最大负载量、平均负载量、99％负载量(是指在一段时间内有99％时间小于或等于且1％时间大于的负载量。)等数据，按一定策略(比如计算上述各种负载量的平均值或者调和平均值等策略)得出服务器集群对该种目标模型需要提供的实际负载量，然后针对每一种目标模型通过公式(2)：副本数量＝实际负载量/负载承受量，可以得到相应的副本数量。

步骤203：确定每个目标模型的内存占用量。

在本步骤中，内存占用量是指一个目标模型被部署到服务器上时，占用服务器的内存量。在得到了需要部署的目标模型及其副本数之后，还要考虑服务器集群的内存资源可不可以承担这些需要部署的目标模型，因此，首先需要确定每个目标模型的内存占用量。

于一实施例中，步骤203可以包括：获取每个目标模型的磁盘占用量和预设的内存膨胀率。根据磁盘占用量和内存膨胀率，确定每个目标模型的内存占用量。

在实际场景中，通常计算算法模型的内存占用量是困难的，此处可以采用估算的方式。由于实际场景中，算法模型持久化(保存)到文件后的大小比较容易获取(比如可以直接从保存的模型文件属性中获取)，假设对每种算法而言，模型持久化到磁盘的大小和模型在内存中的大小比例是不变的，而通常模型在内存中占得更大，因此可以称这个比例为膨胀率，也就是说一种算法对应一个膨胀率。即可得到公式(1)：内存占用量＝磁盘占用量*膨胀率。因此，获取到每个目标模型的磁盘占用量和预设的内存膨胀率后，即可采用上述公式(1)得到每个目标模型的内存占用量。

于一实施例中，预设内存膨胀率的步骤可以包括：获取算法模型库中每种算法的至少一个样本算法模型。在预设服务器上启动模型部署服务，记录没有部署算法模型时预设服务器的第一内存占用量。在预设服务器上加载每种算法的样本算法模型，记录部署有样本算法模型时预设服务器的第二内存占用量。确定第二内存占用量减去第一内存占用量的差值，并将差值除以样本算法模型的磁盘占用量，得到样本算法模型的内存膨胀率。

在本实施例中，算法模型库中包括每种算法的一个或多个模型，合理利用资源考虑，样本算法模型可以直接从算法模型库中拉去每种算法对应的至少一个样本算法模型。若实际场景中，认为算法模型库中的模型无法满足要求时，也可以预先针对每种算法，训练一个或多个样本算法模型(样本算法模型越多估算越准确)，通过单独训练的方式得到样本算法模型可控性强，容易满足膨胀率准确度的要求。在确定了样本算法模型后，启动部署模型的服务，记录没有部署任何模型时的服务器的第一内存占用量，比如独立部署在一台预设服务器上，记录整台预设服务器的内存占用信息即可。然后，针对每种算法，分别在预设服务器上加载多个样本算法模型后再次记录预设服务器的第二内存占用量，第二内存占用量减去第一内存占用量的差值即是加载前后的内存占用增加值，再将差值除以样本算法模型的磁盘占用量即可得到该中算法对应的膨胀率。

步骤204：根据每个目标模型的内存占用量、每种目标模型的副本数量和服务器集群的总内存资源，在服务器集群上的部署目标模型。

在本步骤中，依据需要部署的目标模型及其副本数量，可以得到部署所有目标模型时的内存占用量，结合服务器集群中各个节点的内存资源，把目标模型均衡的部署到服务器集群的内存中。

上述模型部署方法，通过统计算法模型库的历史访问信息，和每个算法模型的性能信息来确定必须要在服务器集群中部署的目标模型及其副本数，然后确定每个目标模型占用内存大小，结合服务器集群系统内存和CPU负载情况，把部分模型部署到服务器集群的内存中。如此，充分考虑每个模型的实际使用情况，结合服务器自身的内存资源，合理运用有限的资源，实现了提高模型部署时服务器系统资源的利用率，提高模型部署的效率。

请参看图3，其为本申请一实施例的模型部署方法，该方法可由图1所示的电子设备1来执行，并可以应用于在服务器集群中部署算法模型的场景中，提高模型部署时服务器系统资源的利用率，提高模型部署的效率。

该方法包括如下步骤：

步骤301：获取算法模型库的历史访问信息和算法模型库中每个算法模型的性能信息。详细参见上述实施例中对步骤201的描述。

步骤302：根据历史访问信息和每个算法模型的性能信息，确定需要部署的目标模型种类和每种目标模型的副本数量。详细参见上述实施例中对步骤202的描述。

步骤303：确定每个目标模型的内存占用量。详细参见上述实施例中对步骤203的描述。

步骤304：根据每个目标模型的内存占用量和每种目标模型的副本数量，确定部署全部目标模型时的内存占用总量。

在本步骤中，在部署目标模型时，需要考虑服务器的内存承载能力，因此，首先需要确定部署全部目标模型时的内存占用总量。针对一种目标模型，单个目标模型的内存占用量与该种目标模型的副本数量的乘积，就是该种目标模型总的内存占用量，每种目标模型的总的内存占用量之和就是部署全部目标模型时的内存占用总量。

比如，假设算法模型库中有A1，A2，A3三种算法，模型性能信息如下：

1、算法A1有模型3个，分别为模型M1-1到模型M1-3，每个内存占用量为1G。

2、算法A2有模型3个，分别为模型M2-1到模型M2-3，每个模型内存占用量为2G。

3、算法A3有模型3个，分别为模型M3-1到模型M3-3，每个模型内存占用量为3G。

其中，假设内存占用量越大的模型部署时间越长，编号越小的模型部署时间越长。

而通过步骤302，筛选规则是一天之内有访问的模型必须部署，一周之内没有访问的不用部署，假设最终筛选出在过去一天之内有访问的需要部署的目标模型为：模型M1-1、模型M1-2、模型M2-1和模型M3-1。则可以计算出内存占用总量＝7G。

步骤305：判断内存占用总量是否大于或等于服务器集群的总负载阈值。若是进入步骤307，否则进入步骤306。

在本步骤中，负载阈值是服务器保持良好工作状态时允许的负载，可以预先基于服务器的实际情况设定。服务器集群中可以包括多个服务器节点，每个节点可以由一台或者多台计算机设备实现。比如，假设一个3台服务器组成的集群，包括：节点S1、节点S2、节点S3。其中每台服务器节点的可用内存是5G，内存的负载阈值是3G，不平衡阈值是2G(是指每两个节点的可用内存之差达到此阈值时，认为这两个节点不平衡，在此情况下，就需要调整模型的部署节点，该阈值可以基于实际场景适应性配置)。则服务器集群的总负载阈值为9G。以步骤304中目标模型为：模型M1-1、模型M1-2、模型M2-1和模型M3-1时为例，内存占用总量7G小于总负载阈值为9G，则进入步骤306，否则进入步骤307。

步骤306：根据服务器集群中每个节点的内存资源信息，将全部目标模型部署到服务器集群中。

在本步骤中，每个节点的内存资源信息至少包括该节点总的可用内存大小，以及该节点被配置的内存的负载阈值等信息，还可以包括被配置的每两个节点之间的不平衡阈值信息。比如，上述步骤305的例子，服务器集群中包括3个节点：节点S1、节点S2、节点S3。其中每台服务器节点的可用内存是5G，内存的负载阈值是3G，不平衡阈值是2G。当内存占用总量小于服务器集群的总负载阈值时，则说明步骤302中筛选出的全部目标模型都可以部署，可以将全部目标模型部署到服务器集群中。比如被选中的模型M1-1、模型M1-2、模型M2-1和模型M3-1，内存占用总量7G小于总负载阈值9G，可以全部部署，为了平衡每个节点的内存资源信息的利用率，可以考虑每两个节点之间的不平衡阈值2G，即每两个节点之间的可用内存之差尽量小于2G，则可以得到第一种部署方式如下：

节点S1：部署模型M1-1和模型M1-2，占用内存2G。

节点S2：部署模型M2-1，占用内存2G。

节点S3：部署模型M3-1，占用内存3G。

于一实施例中，当内存占用总量小于服务器集群的总负载阈值时，为了可以充分利用服务器资源，可以从没被选中的算法模型中挑选历史访问流量较高的模型一同部署。

步骤307：依次从全部的目标模型中剔除历史访问频率最低的算法模型，直至剩余的目标模型的内存占用总量小于总负载阈值时，根据服务器集群中每个节点的内存资源信息，将剩余的目标模型部署到服务器集群中，并将剔除掉的算法模型标记为高优先级部署。

在本步骤中，当内存占用总量大于或等于服务器集群的总负载阈值时，则可以按历史访问频率大小或者一段时间内访问流量高低，将一些历史访问频率最低或者一段时间内访问流量最低的目标模型剔除掉，然后，将剩余的目标模型部署到服务器集群中。为了保证被剔除掉的目标模型可以在有资源时及时部署，可以将被剔除掉的目标模型标记为高优先级部署，一旦系统空闲就把这些模型部署到服务器内存。

于一实施例中，可以在分布式服务器集群的各节点之间平衡模型加载，使得内存和CPU利用率达到最佳，当节点调整时迅速做出变化。比如经过上述步骤，已经选择了部分目标模型进行部署，此时可以配置一个定时任务，重新计算必须部署、可以部署和不需要部署模型，调整部署策略，或应对集群中新增节点、删除节点，此过程称之为自平衡。因此，在步骤307或者步骤306之后，还可以包括：

步骤308：获取对服务器集群的模型访问请求、服务器集群的当前总负载量和服务器集群中每个节点的当前负载量。

在本步骤中，自平衡可以通过监控服务器集群系统的实时负载获得需要的数据，也可以从模型流量统计模块获取最新的访问数据。

步骤309：当访问请求中指定的待访问模型未部署在服务器集群中，并且当前总负载量小于服务器集群的总负载阈值时，将待访问模型部署在服务器集群中当前内存占用率最少的节点上。

在本步骤中，当访问请求中指定的待访问模型未部署在服务器集群中，为了满足访问请求，需要将待访问模型进行部署，在部署时不仅要考虑总负载阈值，还要考虑每个节点当前的内存占用率，如果当前总负载量小于服务器集群的总负载阈值，则选取当前内存占用率最少的节点来部署待访问模型，否则进入步骤311。

基于步骤306的实施例，假设此时检测到一个对模型M2-2的访问请求到来了，模型M2-2在步骤306中没有被部署，因此为了满足该访问请求，需要部署此模型，选取当前占用最少的节点S1、或节点S2进行部署，假设选择了节点S1，得到第二种部署方式如下：

节点S1：部署模型M1-1、模型M1-2、模型M2-2，占用内存4G。

节点S2：部署模型M2-1，占用内存2G。

节点S3：部署模型M3-1，占用内存3G。

从上述部署结果可以看出，节点S1超过了自身的负载阈值3G，但仍在可用内存范围内，可以接受，为了合理利用服务器资源，可以通过自平衡任务调整部署情况，因此，于一实施例中，在步骤308之后，还可以包括：

步骤310：当在服务器集群中存在第一节点的当前负载量大于或等于了第一节点的负载阈值，并且当前总负载量小于服务器集群的总负载阈值时，将部署在第一节点上的占用内存最小的算法模型调整部署至第二节点，第二节点的当前负载量小于第二节点的负载阈值。

在本步骤中，基于上述实施例，节点S1就是第一节点，节点S2就是第二节点，可以把1G的内存占用从节点S1调整到节点S2来做自平衡调整。

于一实施例中，步骤310可以包括：当存在多个占用内存最小的算法模型时，将耗费部署时间最小的占用内存最小的算法模型调整部署至第二节点。

在本步骤中，比如第二种部署方式中，占用内存最小的算法模型有两个，分别为模型M1-1和模型M1-2，假设模型M1-2的部署速度更快，选取模型M1-2调整到节点S2，得到第三种部署方式如下：

节点S1：部署模型M1-1、模型M2-2，占用内存3G。

节点S2：部署模型M2-1、模型M1-2，占用内存3G。

节点S3：部署模型M3-1，占用内存3G。

也就是说，当已部署模型的流量分配不均，会造成服务器CPU资源使用的不平衡，此时不调整部署模型及副本数量，而是通过调整部署模型所在的节点，来尽量使得模型流量平衡。

于一实施例中，在步骤308之后，还可以包括：

步骤311：当访问请求中指定的待访问模型未部署在服务器集群中，并且当前总负载量已大于或等于服务器集群的总负载阈值时，卸载已部署在服务器集群中的访问频率最小的算法模型，将待访问模型部署到相应的节点上。

在本步骤中，如果待访问模型未部署在服务器集群中，当前总负载量已大于或等于服务器集群的总负载阈值，说明服务器集群的负载上升，需要动态将已部署模型当中流量最小(即访问频率最小)的一些算法模型卸载，减少系统负载，然后将待访问模型部署到相应的节点上。

比如，在基于步骤309的第三种部署方式下，检测到了对模型M3-2的访问请求，模型M3-2没有被部署，而且服务器集群中也没有任何一个节点可以容纳下模型M3-2占用3G的内存，所以需要卸载一个已经部署的模型来腾出资源位置。假设模型M2-1此时已经超过1天没有访问(属于访问频率最小的算法模型)，那么可以从节点S2卸载模型M2-1，并部署模型M3-2到节点S2，得到第四种部署方式如下：

节点S1：部署模型M1-1、模型M2-2，占用内存3G。

节点S2：部署模型M1-2、模型M3-2，占用内存4G。

节点S3：部署模型M3-1，占用内存3G。

于一实施例中，自平衡任务发现节点S2超过了自身的负载阈值3G，而且其他节点也已经满负载，这时需要卸载已部署的算法模型，来均衡模型流量，因此，在步骤308之后，还可以包括：

步骤312：在当前总负载量已大于或等于服务器集群的总负载阈值，并且服务器集群中每个节点当前负载量都大于或等于所属节点的负载阈值时，卸载已部署在服务器集群中的访问频率最小的算法模型，并标记访问频率最小的算法模型为高优先级部署。

在本步骤中，比如基于步骤311中的第四种部署方式下，节点S2超过了自身的负载阈值3G，而且其他节点也已经满负载，假设最久没有被访问(即访问频率最小)的是模型M3-1，可以把模型M3-1从节点S3上卸载，并将节点S2上的一个模型转移至节点S3，此时候选的可以移动的由模型M1-2和模型M3-2，由于模型M3-2的部署时间大于模型M1-2，所以有限选择转移模型M1-2到节点S3上，得到第五种部署方式如下：

节点S1：部署模型M1-1、模型M2-2，占用内存3G。

节点S2：部署模型M3-2，占用内存3G。

节点S3：部署模型M1-2，占用内存1G。

另外，被卸载的模型M3-1出于必须要部署的原因，被标记为高优先级部署。

于一实施例中，当集群中有节点增加，说明有新的服务器资源加入，则把其他节点上的模型或者被标记为高优先级部署的模型移动一部分到此节点上来均衡模型流量。因此，在步骤308之后，还可以包括：

步骤313：当服务器集群中有新节点加入时，将标记为高优先级部署的算法模型部署到新节点中。

在本步骤中，如果有新节点加入服务器集群，说明有新的资源可以使用，此时系统当前负载下降到中负载阈值之下，可以查看是否存在为未加载的目标模型，如有则立即加载。而为了提高模型服务效率，可以优先将标记为高优先级部署的算法模型部署到新节点中。比如，此时服务器集群中增加了一个新节点S4，内存也是5G，负载阈值3G，此时节点S4被占用内存为0G。自平衡任务发现有新节点加入，并且内存占用为0G，可以把在步骤312中第五种部署方式下被标记为高优先级部署的模型M3-1重新拉入服务器内存，得到第六种部署方式如下：

节点S1：部署模型M1-1、模型M2-2，占用内存3G。

节点S2：部署模型M3-2，占用内存3G。

节点S3：部署模型M1-2，占用内存1G。

节点S4：部署模型M3-1，占用内存3G。

同理，当服务器集群中有节点删除，需要把此被删除节点上的模型移动到其他节点上，移动原理也要综合考虑每个节点的资源利用率，可参阅上述实施例，此处不再赘述。

需要说明的是，步骤309至步骤313均可以在步骤308之后执行的，可以不区分先后次序，本实施例所示的流程顺序仅仅是给出一种可选的执行顺序作为示例，本实施例对步骤309至步骤313的执行次序不做限定。

于一实施例中，为了最大限度减少模型部署时间，在服务器集群上的部署目标模型以及进行自平衡任务调整部署方式时，当本地存在目标模型的文件时，可以优先读取本地存储的目标模型的文件进行部署。比如上述实施例中提到大量模型部署和转移的操作，此时不仅要考虑如何减少模型部署时间，还可以利用本地磁盘做缓存，加快模型的部署速度。

假设通常模型部署过程可以如下：

a.从模型服务器上拉取模型文件到本地。

b.程序读取模型文件，部署到服务器内存。

c.删除模型文件

其中当模型较大时，a步骤耗时不容轻视。

所以可以把本地磁盘的文件系统作为一层缓存，调整后的模型部署过程如下：

a.检查本地磁盘是否有模型文件缓存，如果有则跳到步骤c，否则进入步骤b。

b.从模型服务器上拉取模型文件到本地。

c.程序读取本地磁盘的模型文件，部署到服务器内存。

d.确定是否需要删除文件(该步骤可参阅现有技术通用的方式)。

请参看图4，其为本申请一实施例的模型部署装置400，该装置可应用于图1所示的电子设备1，并可以应用于在服务器集群中部署算法模型的场景中，提高模型部署时服务器系统资源的利用率，提高模型部署的效率。该装置包括：第一获取模块401、确定模块402、计算模块403和部署模块404，各个模块的原理关系如下：

第一获取模块401，用于获取算法模型库的历史访问信息和算法模型库中每个算法模型的性能信息。确定模块402，用于根据历史访问信息和每个算法模型的性能信息，确定需要部署的目标模型种类和每种目标模型的副本数量。计算模块403，用于确定每个目标模型的内存占用量。部署模块404，用于根据每个目标模型的内存占用量、每种目标模型的副本数量和服务器集群的总内存资源，在服务器集群上的部署目标模型。

于一实施例中，确定模块402用于：根据历史访问信息，从算法模型库中筛选出在预设时长内被访问次数大于或等于预设次数的至少一种类别的目标模型，并获取每种类别的目标模型的负载承受量。根据历史访问信息，统计服务器集群针对每种类别的目标模型需要提供的实际负载量。根据实际负载量和负载承受量，确定需要部署每种目标模型的副本数量。

于一实施例中，计算模块403用于：获取每个目标模型的磁盘占用量和预设的内存膨胀率。根据磁盘占用量和内存膨胀率，确定每个目标模型的内存占用量。

于一实施例中，还包括预设模块405用于：获取算法模型库中每种算法的至少一个样本算法模型。在预设服务器上启动模型部署服务，记录没有部署算法模型时预设服务器的第一内存占用量。在预设服务器上加载每种算法的样本算法模型，记录部署有样本算法模型时预设服务器的第二内存占用量。确定第二内存占用量减去第一内存占用量的差值，并将差值除以样本算法模型的磁盘占用量，得到样本算法模型的内存膨胀率。

于一实施例中，获取算法模型库中每种算法的至少一个样本算法模型，包括：针对算法模型库中的每种算法，训练至少一个样本算法模型。

于一实施例中，所述获取所述算法模型库中每种算法的至少一个样本算法模型，包括：从所述算法模型库中的获取所述每种算法对应的至少一个样本算法模型。

于一实施例中，部署模块404用于：根据每个目标模型的内存占用量和每种目标模型的副本数量，确定部署全部目标模型时的内存占用总量。判断内存占用总量是否大于或等于服务器集群的总负载阈值。当内存占用总量小于服务器集群的总负载阈值时，根据服务器集群中每个节点的内存资源信息，将全部目标模型部署到服务器集群中。

于一实施例中，部署模块404用于：当内存占用总量大于或等于服务器集群的总负载阈值时，依次从全部的目标模型中剔除历史访问频率最低的算法模型，直至剩余的目标模型的内存占用总量小于总负载阈值时，根据服务器集群中每个节点的内存资源信息，将剩余的目标模型部署到服务器集群中，并将剔除掉的算法模型标记为高优先级部署。

于一实施例中，还包括：第二获取模块406，用于在根据每个目标模型的内存占用量、每种目标模型的副本数量和服务器集群的总内存资源，在服务器集群上的部署目标模型之后，获取对服务器集群的模型访问请求、服务器集群的当前总负载量和服务器集群中每个节点的当前负载量。部署模块404还用于：当访问请求中指定的待访问模型未部署在服务器集群中，并且当前总负载量小于服务器集群的总负载阈值时，将待访问模型部署在服务器集群中当前内存占用率最少的节点上。

于一实施例中，在根据每个目标模型的内存占用量、每种目标模型的副本数量和服务器集群的总内存资源，在服务器集群上的部署目标模型之后，部署模块404还用于：当访问请求中指定的待访问模型未部署在服务器集群中，并且当前总负载量已大于或等于服务器集群的总负载阈值时，卸载已部署在服务器集群中的访问频率最小的算法模型，将待访问模型部署到相应的节点上。

于一实施例中，在根据每个目标模型的内存占用量、每种目标模型的副本数量和服务器集群的总内存资源，在服务器集群上的部署目标模型之后，部署模块404还用于：当在服务器集群中存在第一节点的当前负载量大于或等于了第一节点的负载阈值，并且当前总负载量小于服务器集群的总负载阈值时，将部署在第一节点上的占用内存最小的算法模型调整部署至第二节点，第二节点的当前负载量小于第二节点的负载阈值。

于一实施例中，在根据每个目标模型的内存占用量、每种目标模型的副本数量和服务器集群的总内存资源，在服务器集群上的部署目标模型之后，部署模块404还用于：当当前总负载量已大于或等于服务器集群的总负载阈值，并且服务器集群中每个节点当前负载量都大于或等于所属节点的负载阈值时，卸载已部署在服务器集群中的访问频率最小的算法模型，并标记访问频率最小的算法模型为高优先级部署。

于一实施例中，部署模块404还用于：当服务器集群中有新节点加入时，将标记为高优先级部署的算法模型部署到新节点中。

于一实施例中，将部署在第一节点上的占用内存最小的算法模型调整部署至第二节点，包括：当存在多个占用内存最小的算法模型时，将耗费部署时间最小的占用内存最小的算法模型调整部署至第二节点。

于一实施例中，部署模块404还用于：当本地存在目标模型的文件时，读取本地存储的目标模型的文件进行部署。

上述模型部署装置400的详细描述，请参见上述实施例中相关方法步骤的描述。

本发明实施例还提供了一种非暂态电子设备可读存储介质，包括：程序，当其在电子设备上运行时，使得电子设备可执行上述实施例中方法的全部或部分流程。其中，存储介质可为磁盘、光盘、只读存储记忆体(Read-Only Memory，ROM)、随机存储记忆体(RandomAccess Memory，RAM)、快闪存储器(Flash Memory)、硬盘(Hard Disk Drive，缩写：HDD)或固态硬盘(Solid-State Drive，SSD)等。存储介质还可以包括上述种类的存储器的组合。

虽然结合附图描述了本发明的实施例，但是本领域技术人员可以在不脱离本发明的精神和范围的情况下作出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。