CN111638953A - 一种实现gpu虚拟化的方法、装置和存储介质 - Google Patents

Abstract

本申请公开了一种实现GPU虚拟化的方法、装置和存储介质，具体包括：为应用服务请求分配工作节点下的GPU，利用创建的容器运行应用服务请求对应的应用服务实例，并在分配的GPU上运行应用服务进程。获取工作节点监控的GPU运行信息和容器运行信息，并确定应用服务实例和应用服务进程之间的关联关系，基于所述关联关系，在GPU内存实际占用量超出GPU内存申请量时，利用预设的软隔离机制对所述应用服务请求进行隔离处理。应用本申请方法实施例可以充分利用GPU资源，且在超出GPU内存申请量时，采用软隔离机制对应用服务请求进行隔离处理，保护同一个GPU上其他应用服务请求的正常运行。

Description

一种实现GPU虚拟化的方法、装置和存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种实现GPU虚拟化的方法、一种实现GPU虚拟化的系统、一种计算机可读存储介质以及一种电子设备。

背景技术

图形处理单元(GPU，Graphics Processing Unit)是一种价格昂贵但计算能力超强的芯片处理器。为了更好地利用GPU资源，对于算力要求不太高的比如模型研发或者推理预测场景的服务，可以将一个物理GPU虚拟化，视为多个虚拟GPU，提供给多个服务使用。现有的GPU虚拟化方案(比如阿里GPUShare)目前虽然可以通过资源调度让多个服务同时运行在同一个物理GPU上，但对多个服务运行时使用的GPU内存资源却没有隔离。如果不对服务运行时所需的GPU内存资源进行隔离，那么在某个服务使用GPU内存资源泛滥时，可能无法保证同一个GPU上其他应用服务正常运行的需求。

发明内容

针对上述现有技术，本申请实施例公开一种实现GPU虚拟化的方法，可以对应用服务请求在GPU上的内存资源进行隔离，达到保护同一GPU上其他应用服务正常运行的目的。

本申请实施例提供的一种实现GPU虚拟化的方法，该方法具体包括：

为应用服务请求分配工作节点下的GPU，所述应用服务请求携带有GPU内存申请量；所述工作节点利用创建的容器运行所述应用服务请求对应的应用服务实例，并在分配的GPU上运行应用服务进程；

获取所述工作节点监控的GPU运行信息和容器运行信息，并根据所述GPU运行信息和容器运行信息确定所述应用服务实例和所述应用服务进程之间的关联关系，所述GPU运行信息表示在分配的GPU上运行所述应用服务进程状况的信息，所述容器运行信息表示在创建的容器上运行所述应用服务实例状况的信息；

基于所述应用服务实例和所述应用服务进程之间的关联关系，在所述应用服务进程对应的GPU内存实际占用量超出所述应用服务实例对应的所述GPU内存申请量时，利用预设的软隔离机制对所述应用服务请求进行隔离处理。

进一步地，

所述获取工作节点监控的GPU运行信息的步骤包括：

接收所述工作节点采集到的GPU运行信息，其中所述工作节点按照设置的采集时间间隔调用所述分配的GPU的驱动接口，获取所述应用服务进程的GPU运行信息，所述GPU运行信息包括当前线程ID和对应的GPU内存实际占用量，所述当前线程ID为所述应用服务进程在分配的GPU上当前运行线程的标识；且所述工作节点上报采集到的所述GPU运行信息。

进一步地，

所述获取工作节点监控的容器运行信息的步骤包括：

接收所述工作节点采集到的容器运行信息，其中所述工作节点获取运行所述应用服务实例的容器对应的容器标识；所述工作节点获取所述应用服务实例对应的所述GPU内存申请量；所述工作节点将所述容器标识和所述GPU内存申请量作为所述容器运行信息并上报。

进一步地，

所述根据GPU运行信息和容器运行信息确定所述应用服务实例和所述应用服务进程之间的关联关系的步骤包括：

将所述容器运行信息中容器标识作为参数调用容器引擎获得所述容器标识所属容器运行的应用服务实例，作为待关联应用服务实例；

确定所述待关联应用服务实例中线程的线程ID，作为待关联线程ID；

将所述待关联线程ID与所述GPU运行信息中的当前线程ID进行匹配；

匹配成功时，在所述待关联线程ID所属的应用服务实例和所述当前线程ID所属的应用服务进程之间建立关联关系。

进一步地，

所述基于应用服务实例和所述应用服务进程之间的关联关系，在所述应用服务进程对应的GPU内存实际占用量超出所述应用服务实例对应的所述GPU内存申请量时，利用预设的软隔离机制对所述应用服务请求进行隔离处理的步骤包括：

判断所述应用服务进程对应的GPU内存实际占用量是否超出所述应用服务实例对应的所述GPU内存申请量，所述应用服务进程和所述应用服务实例有关联关系；如果超出，则继续执行；否则，结束所述利用预设的软隔离机制对所述应用服务请求进行隔离处理的步骤；

在预设的时间窗口内查询上报的GPU内存实际占用量；

计算所述预设的时间窗口内上报的所述GPU内存实际占用量与所述GPU内存申请量的差值；

判断计算出的所述差值与所述GPU内存申请量的比值是否持续超出预设的第一阈值，如果超出所述预设的第一阈值，则继续执行；否则，结束所述利用预设的软隔离机制对所述应用服务请求进行隔离处理的步骤；

计算历史时间内所述GPU内存实际占用量的平均值；

判断计算出的所述平均值与所述GPU内存申请量的比值是否超出预设的第二阈值，如果超出预设的第二阈值，则继续执行；否则，结束所述利用预设的软隔离机制对所述应用服务请求进行隔离处理的步骤；

向所述应用服务实例发送停止指令，以取消所述创建的容器继续运行所述应用服务实例，并取消在分配的GPU上继续运行所述应用服务进程。

本申请实施例公开一种实现GPU虚拟化的系统，可以对应用服务请求在GPU上的内存资源进行隔离，达到保护同一GPU上其他应用服务正常运行的目的。

本申请实施例的一种实现GPU虚拟化的系统，该系统包括控制节点和工作节点；

所述控制节点，用于为应用服务请求分配工作节点下的GPU，所述应用服务请求携带有GPU内存申请量；获取所述工作节点监控的GPU运行信息和容器运行信息，并根据所述GPU运行信息和容器运行信息确定所述应用服务实例和所述应用服务进程之间的关联关系，所述GPU运行信息表示在分配的GPU上运行所述应用服务进程状况的信息，所述容器运行信息表示在创建的容器上运行所述应用服务实例状况的信息；基于所述应用服务实例和所述应用服务进程之间的关联关系，在所述应用服务进程对应的GPU内存实际占用量超出所述应用服务实例对应的所述GPU内存申请量时，利用预设的软隔离机制对所述应用服务请求进行隔离处理；

所述工作节点，用于利用创建的容器运行所述应用服务请求对应的应用服务实例，并在分配的GPU上运行应用服务进程；监控GPU运行信息和容器运行信息并上报给所述控制节点。

进一步地，

所述控制节点包括资源调度系统、管理模块、时序数据库；

所述资源调度系统，用于为应用服务请求分配工作节点下的GPU，所述应用服务请求携带有GPU内存申请量；

所述管理模块，用于获取所述工作节点监控的GPU运行信息和容器运行信息，并根据所述GPU运行信息和容器运行信息确定所述应用服务实例和所述应用服务进程之间的关联关系，所述GPU运行信息表示在分配的GPU上运行所述应用服务进程状况的信息，所述容器运行信息表示在创建的容器上运行所述应用服务实例状况的信息；基于所述应用服务实例和所述应用服务进程之间的关联关系，在所述应用服务进程对应的GPU内存实际占用量超出所述应用服务实例对应的所述GPU内存申请量时，利用预设的软隔离机制对所述应用服务请求进行隔离处理；

所述时序数据库，用于保存所述工作节点监控的GPU运行信息。

进一步地，

所述工作节点包括GPU监控模块、容器监控模块、容器引擎；

所述GPU监控模块，用于监控GPU运行信息并上报给所述控制节点，所述GPU运行所述应用服务进程；

所述容器监控模块，用于监控容器运行信息并上报给所述控制节点；

所述容器引擎，用于创建容器运行所述应用服务请求对应的应用服务实例。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机指令，所述指令被处理器执行时可实现上述任一项所述实现GPU虚拟化的方法。

本申请实施例还提供一种电子设备，该电子设备至少包括上述计算机可读存储介质，还包括处理器；

所述处理器，用于从所述计算机可读存储介质中读取所述可执行指令，并执行所述指令以实现上述任一项所述实现GPU虚拟化的方法。

综上，本申请实施例公开了一种实现GPU虚拟化的方法、装置和存储介质。在本申请实施例在采用GPU虚拟化的方式实现应用服务请求的过程中，监控GPU运行信息和容器运行信息，根据GPU运行信息和容器运行信息建立了应用服务实例和应用服务进程之间的关联关系。正是建立了应用服务实例和应用服务进程之间的关联关系，后续才能够将GPU内存实际占用量和GPU内存申请量进行比较，并在超出GPU内存申请量时利用预设的软隔离机制对应用服务进行隔离处理，从而保护了同一个GPU上其他应用服务的正常运行。

附图说明

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

图1是本申请实现GPU虚拟化的系统实施例一的示意图。

图2是本申请实现GPU虚拟化的方法实施例一的流程图。

图3是本申请实现GPU虚拟化的系统实施例二的示意图。

图4是本申请实现GPU虚拟化的方法实施例二的流程图。

图5是本申请方法实施例中利用预设的软隔离机制对应用服务请求进行隔离处理的方法流程图。

图6是本申请实施例实现GPU虚拟化的电子设备结构示意图。

具体实施方式

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

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含。例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其他步骤或单元。

下面以具体实施例对本发明的技术方案进行详细说明。下面几个具体实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

在有应用服务请求的情况下，本申请实施例先为应用服务请求分配GPU，采用GPU虚拟化的技术实现该应用服务请求。在应用服务请求的实现过程中，利用对应用服务进程实时监控得到的GPU内存实际占用量判断是否超出该应用服务请求的GPU内存申请量，并在超出的情况下采用软隔离机制对该应用服务请求进行隔离处理，从而保护同一个GPU上其他应用服务请求的正常运行。

图1是本申请实现GPU虚拟化的系统示意图。如图1所示，该系统包括控制节点(master-node)101和工作节点(work-node)102。其中，工作节点102的宿主机上有GPU以及GPU内存资源，是真正实现应用服务请求的场所。控制节点101是对应用服务请求以及工作节点102进行控制和管理的场所。实际应用中，一个控制节点101可以与多个工作节点102相连，每个工作节点102上可以有多个GPU，每个GPU可以实现多个应用服务请求。

图2是本申请实现GPU虚拟化的方法实施例一的流程图。如图2所示，该方法包括：

步骤201：为应用服务请求分配工作节点下的GPU，所述应用服务请求携带有GPU内存申请量。

实际应用中，某个应用服务需要工作在GPU上时，会向控制节点101发起应用服务请求，并根据自身需求提出GPU内存申请量。相应地，控制节点101为该应用服务请求分配工作节点102下的某个GPU。如上所述，系统中可能包含多个工作节点102，每个工作节点102中可能有多个GPU，一个GPU上可以运行多个应用服务。控制节点101中可以布置资源调度系统来管理GPU，并为应用服务请求分配合适的GPU。控制节点101中的资源调度系统如何管理和分配GPU可以利用现有技术实现(比如K8S等)，此处不再赘述。

步骤202：工作节点利用创建的容器运行所述应用服务请求对应的应用服务实例，并在分配的GPU上运行应用服务进程。

当控制节点101将某个应用服务请求分配给某个工作节点102下的某个GPU时，该工作节点102会创建容器，创建的容器用于运行该应用服务请求对应的应用服务实例。这里所述容器可以由工作节点102中的容器引擎(比如docker)创建，为应用服务请求构造运行环境。所述应用服务实例本质上是基于容器所定制环境下运行的进程。同时，真正实现该应用服务的是工作节点102中宿主机上的GPU，即：在分配的GPU上运行应用服务进程。应用服务实例和应用服务进程都可以理解为实现应用服务请求的进程，本申请实施例中的应用服务实例可视为虚拟进程，应用服务进程则是在GPU上运行的实际进程。

上述步骤201～步骤202是采用GPU虚拟化技术实现应用服务请求的过程。实际应用中，如果存在多个应用服务请求，控制节点101的资源调度系统根据实际情况可以将其分配在同一个GPU运行。

需要理解的是，本申请实施例这里先直接为应用服务请求分配了某个GPU运行，暂时不考虑在分配的GPU上运行应用服务进程时的GPU内存实际占用量的问题。其原因在于，同一个GPU实施多个应用服务时，各应用服务进程并不一定同时占用GPU内存资源。即使某个应用服务进程的GPU内存实际占用量在短时间内超出GPU内存申请量，也可能不会对其他应用服务造成影响。因此，为了充分利用GPU，本申请实施例在满足GPU内存申请量的情况下，可以先为应用服务请求分配合适的GPU运行。

在实现应用服务请求的过程中，本申请实施例后续步骤203～步骤204再采用软隔离机制对该应用服务请求对应的应用服务进行隔离处理，以避免某个应用服务进程的GPU内存实际占用量超出GPU内存申请量时，影响同一个GPU上其他应用服务请求的正常运行。

步骤203：获取工作节点监控的GPU运行信息和容器运行信息，并根据GPU运行信息和容器运行信息确定应用服务实例和应用服务进程之间的关联关系，所述GPU运行信息表示在分配的GPU上运行应用服务进程状况的信息，所述容器运行信息表示在创建的容器上运行应用服务实例状况的信息。

实际应用中，GPU运行应用服务进程时的状况可以用GPU运行信息表示，容器运行应用服务实例的状况可以用容器运行信息表示。其中，GPU运行应用服务进程时的GPU内存实际占用量是动态变化的，有可能少于应用服务请求的GPU内存申请量，也有可能会超出应用服务请求的GPU内存申请量，影响同一个GPU上其他应用服务进程的正常运行。为了避免此缺陷，本申请实施例由工作节点102实时监控GPU运行信息，控制节点101利用GPU运行信息来了解GPU运行应用服务进程的状况。

但实际应用中，控制节点101中对于容器运行的应用服务实例和GPU运行的应用服务进程之间并没有建立关联关系，即使某个应用服务进程占用了大量的GPU内存资源，控制节点101无法获知其对应的应用服务。比如：某个应用服务A的GPU内存申请量为5000M，对应应用服务实例A；应用服务B的GPU内存申请量为3000M，对应应用服务实例B。而工作节点102中某个应用服务进程的GPU内存实际占用量为4000M。此时，控制节点101无法获知该应用服务进程是属于应用服务A的进程，还是属于应用服务B的进程。如果属于应用服务A的进程，那么其GPU内存实际占用量小于其GPU内存申请量，处于正常运行的状态。如果属于应用服务B的进程，那么其GPU内存实际占用量超出其GPU内存申请量，则可能会影响其他应用服务的正常运行。因此，为了有效利用GPU运行信息，本申请需要建立应用服务实例和应用服务进程之间的关联关系。发明人发现，对于同一应用服务，GPU运行信息和容器运行信息之间存在一定的关联关系，那么根据监控的GPU运行信息和容器运行信息就可以建立应用服务实例和应用服务进程之间的关联关系。

步骤204：基于应用服务实例和应用服务进程之间的关联关系，在应用服务进程对应的GPU内存实际占用量超出所述应用服务实例对应的所述GPU内存申请量时，利用预设的软隔离机制对所述应用服务请求进行隔离处理。

至此，控制节点101已经获得了应用服务实例和应用服务进程之间的关联关系，可以将应用服务进程在GPU内存实际占用量和应用服务实例的GPU内存申请量进行比较，并在超出时采用本申请实施例中的软隔离机制进行隔离处理，具体的软隔离机制将在后续实施例进行详细介绍。这里所述的软隔离机制是一种对应用服务请求进行隔离的方式，但并不限于本申请实施例提供的隔离方式，只要能够对GPU内存实际占用量超出GPU内存申请量的应用服务进行限制即可。

应用本申请方法实施例，由于先为应用服务请求分配GPU，采用GPU虚拟化的技术实现该应用服务请求，可以充分利用GPU资源。同时，在应用服务请求的实现过程中，由于建立了应用服务实例和应用服务进程之间的关联关系，可以利用GPU内存实际占用量，并在GPU内存实际占用量超出GPU内存申请量时，采用软隔离机制对该应用服务进行隔离处理，从而保护了同一个GPU上其他应用服务请求的正常运行。

为了更好地说明本申请方案，下面用其他较佳实施例进行详细描述。图3是本申请实现GPU虚拟化实施例的系统示意图。如图3所示，该系统仍然包括控制节点101和工作节点102。为了方便描述，以一个工作节点102为例进行说明，其他工作节点102与控制节点101的关系与其相同。其中，控制节点101包括资源调度系统103、管理模块(VGPU Manager)104、时序数据库105，工作节点102包括GPU监控模块(node-agent)106、容器监控模块(container-agent)107、容器引擎(docker)108。资源调度系统103负责GPU及其GPU内存资源的管理和分配；管理模块104负责应用服务运行监控的管理和隔离；时序数据库105责任保存GPU运行信息；GPU监控模块106负责对节点上GPU运行状况的监控，并将GPU运行信息上报给管理节点101；容器监控模块107负责对容器运行状况进行监控，并将容器运行信息上报给管理节点101；容器引擎108负责创建容器。当然，工作节点102中还应该包括GPU和GPU内存资源，图中未示出。

图4是本申请GPU虚拟化实现的方法实施例二的流程图。如图4所示，该方法包括：

步骤401：为应用服务请求分配工作节点下的GPU，所述应用服务请求携带有GPU内存申请量。

步骤402：工作节点利用创建的容器运行应用服务请求对应的应用服务实例，并在分配的GPU上运行应用服务进程。

本申请实施例步骤401～402与方法实施例一的步骤201～步骤202相同。本申请实施例二中的资源调度系统103可以为K8S调度系统，实际应用中还可以为yarn、slurm等其他调度系统。以K8S调度系统为例，其负责整个集群的调度功能，能够根据一定的调度算法和策略，为应用服务请求分配最优的GPU，从而更加合理地利用集群的资源。实际应用中，本申请实施例方案并不限于K8S调度系统，只要能够负责管理和调度GPU及其GPU内存资源的管理和分配即可。

本申请实施例为了实现GPU虚拟化，需要为不同的应用服务请求创建不同的容器，每个容器封装了各自的运行环境，但都能够在同一个GPU上实现真正的应用服务进程。因此，在控制节点101中的资源调度系统103为应用服务请求分配了合适的GPU之后，该GPU所在工作节点102上的容器引擎108可以创建容器(container)来运行应用服务实例，并启动在分配的GPU上运行应用服务进程。

步骤403：工作节点按照设置的采集时间间隔调用所述分配的GPU的驱动接口，获取应用服务进程的GPU运行信息，所述GPU运行信息包括当前线程ID和对应的GPU内存实际占用量，所述当前线程ID为所述应用服务进程在分配的GPU上当前运行线程的标识。

步骤404：工作节点上报采集到的所述GPU运行信息。

上述步骤403～步骤404是管理模块104获取工作节点102监控的GPU运行信息。在工作节点102中可以设置GPU监控模块106用于对GPU运行状况的监控，比如按照采集时间间隔(比如3秒)调用GPU的驱动接口即可达到监控的目的。假设GPU为英伟达(NVIDIA)GPU，利用nvidia-smi指令调用GPU驱动接口，可以接收到返回的应用服务进程的GPU运行信息。GPU运行信息的格式可如表一所示：

GPU卡号	当前线程ID(PID)	GPU内存实际占用量
			0	2	6372M
0	3	2749M
			0	4	4834M
1	5	4983M
			…	…	…

表一

其中，“GPU卡号”表示工作节点102上的GPU标识；“当前线程ID”指示应用服务进程中某个正在GPU中运行的线程，通常也称为“PID”。这里表示工作节点101上有两个GPU卡(GPU0和GPU1)，其中，GPU0当前运行了两个线程，其PID分别为2和3，PID为2的线程占用GPU的内存为6372M，PID为3的线程占用GPU的内存为2749M。而另一个GPU1上当前运行了一个线程，其PID为5，占用GPU的内存为4983M。

由此，GPU监控模块106可以获取GPU运行信息并上报给控制节点101。实际应用中，GPU监控模块106可以上报给管理模块104，还可以同时上报给时序数据库105进行保存。在上报时，还可以进一步为GPU运行信息添加采集时间的时间戳，以便后续的查询使用。

步骤405：工作节点获取运行所述应用服务实例的容器对应的容器标识。

步骤406：工作节点获取所述应用服务实例对应的所述GPU内存申请量。

步骤407：工作节点将所述容器标识和所述GPU内存申请量作为所述容器运行信息并上报。

上述步骤405～步骤407是控制节点101获取工作节点102监控的容器运行信息。在工作节点102中可以设置容器监控模块107用于对容器运行状况的监控，得知有哪些容器正在运行。实际应用中，容器引擎108会创建容器并为每个容器生成容器标识(containerID)，这些容器标识组成容器目录保存，那么容器监控模块107通过查询容器目录就可以获取容器标识。另外，容器监控模块107还可以获取容器运行应用服务实例对应的GPU内存申请量，从而得到这些容器运行的应用服务实例对应的GPU内存申请量，并将容器标识和GPU内存申请量一并作为容器运行信息。容器运行信息的格式可如表二所示：

容器标识(container ID)	GPU内存申请量
		10	5000M
11	4000M
		…	…

表二

其中，“容器标识”表示容器引擎108创建容器的标识，通常可以称为“containerID”。这里表示容器引擎108创建了两个容器(container 10和container11)，其中container 10运行的应用服务实例对应的GPU内存申请量为5000M，container 11运行的应用服务实例对应的GPU内存申请量为4000M。实际应用中，由于资源调度系统103需要为应用服务请求调度资源，可以将应用服务请求对应的GPU内存申请量记录下来，因此容器监控模块107可以从控制节点101中的资源调度系统103中获取该GPU内存申请量。在另一个实施例中，容器运行信息还可以直接保存在资源调度系统103，管理模块104从资源调度系统103获取容器运行信息即可。

至此，控制节点101中的管理模块104已经获取了工作节点102中的GPU运行信息和容器运行信息。如前所述，管理模块104虽然获取了GPU运行信息和容器运行信息，但是GPU运行的应用服务进程和容器运行的应用服务实例之间并未建立关联关系，无法利用GPU内存实际占用量对需要隔离的应用服务进行操作。因此，本申请实施例下面步骤408～步骤411将建立GPU运行的应用服务进程和容器运行的应用服务实例之间的关联关系。

步骤408：将容器运行信息中容器标识作为参数调用容器引擎获得所述容器标识所属容器运行的应用服务实例，作为待关联应用服务实例。

步骤409：确定待关联应用服务实例中线程的线程ID，作为待关联线程ID。

步骤410：将待关联线程ID与GPU运行信息中的当前线程ID进行匹配。

步骤411：匹配成功时，在待关联线程ID所属的应用服务实例和当前线程ID所属的应用服务进程之间建立关联关系。

上述步骤408～步骤411本质上是先寻求GPU运行信息和容器运行信息的关联关系，再由此确定GPU运行的应用服务进程和容器运行的应用服务实例之间的关联关系。GPU运行信息包括当前线程ID(PID)和对应的GPU内存实际占用量。容器运行信息包括容器标识和GPU内存申请量。其中，步骤408将容器标识作为参数调用容器引擎就可以确定对应的应用服务实例。比如，利用docker inspect container ID指令可以获知对应的应用服务实例。由于应用服务实例在本质上是基于容器所定制环境下运行的进程，包含若干线程，这些线程与运行在GPU上的线程采用了相同的线程ID(PID)进行标识。因此，只要应用服务实例中的线程ID和应用服务进程中的线程ID匹配，就可以确定应用服务实例和应用服务进程之间具有关联关系。

以表一和表二为例，假设GPU0上运行3个线程，当前线程ID包括2、3、4，其中2和3属于应用服务进程X1,4属于应用服务进程X2，而容器标识为10的容器上运行的应用服务实例Y包括5个线程，其线程ID为2、3、6、7、8(即步骤409中所述待关联线程ID)，将GPU上的当前线程ID和待关联线程ID进行匹配，匹配成功的线程ID为2和3，那么可以确定应用服务进程X1和应用服务实例Y之间存在关联关系。

步骤412：基于应用服务实例和应用服务进程之间的关联关系，在所述应用服务进程对应的GPU内存实际占用量超出所述应用服务实例对应的所述GPU内存申请量时，利用预设的软隔离机制对所述应用服务请求进行隔离处理。

本步骤与方法实施例一的步骤204相同，在建立了应用服务实例和应用服务进程之间的关联关系后，就可以利用应用服务进程在GPU内存实际占用量判断是否启动软隔离机制。

实际应用中，不管采用哪种方式实现GPU虚拟化的方法，都可以利用本申请提出的软隔离机制进行隔离处理。图5是利用预设的软隔离机制对应用服务请求进行隔离处理的方法流程图，即步骤412的具体实施方式。如图5所示，该方法实现步骤包括：

步骤501：判断应用服务进程对应的GPU内存实际占用量是否超出应用服务实例对应的GPU内存申请量，所述应用服务进程和应用服务实例有关联关系；如果超出，则继续执行步骤502；否则，结束利用预设的软隔离机制对应用服务请求进行隔离处理的流程。

如上所述，本申请实施例步骤404中工作节点会上报采集到的GPU运行信息和容器运行信息，比如由GPU监控模块106和容器监控模块107上报给管理模块104。管理模块104获取到应用服务进程对应的GPU内存实际占用量以及应用服务实例对应的GPU内存申请量，并将两者进行比较。如果GPU内存实际占用量超出GPU内存申请量，则说明该应用服务在运行时占用了高于预期的GPU内存资源，此信息相当于预警信号，需要防止其进一步占用更多的GPU内存资源。

需要理解的是，本申请实施例在确定GPU内存实际占用量超出GPU内存申请量时，并不是采用“硬隔离”方式立即停止该应用服务，而是利用以下步骤继续判断，只有完全满足本申请实施例设置的条件，才停止该应用服务。因此，本申请实施例的隔离措施属于“软隔离机制”，本步骤在GPU内存实际占用量超出GPU内存申请量时继续执行后续步骤是“软隔离机制”的体现之一。

步骤502：在预设的时间窗口内查询上报的GPU内存实际占用量。

如果管理模块104确定某个时间点采集的GPU内存实际占用量已经超出GPU内存申请量，可以从该时间点开始的某个时间窗口(比如30秒)内从时序数据库105中查询上报的GPU内存实际占用量。

本申请实施例的GPU监控模块106在上报GPU运行信息时，不但上报给时序数据库105进行保存，还同时上报给了管理模块104。因此，管理模块104可以从时序数据库105查询上报的GPU内存实际占用量。此外，由于管理模块104也同时获得GPU监控模块106在上报的GPU运行信息，因此只需要在GPU内存实际占用量超出GPU内存申请量的情况下，才发起对时序数据库105的访问，而无需高频率地访问时序数据库105，从而减少访问数据库的次数，提高工作效率。

步骤503：计算预设的时间窗口内上报的GPU内存实际占用量与GPU内存申请量的差值。

步骤504：判断计算出的差值与GPU内存申请量的比值是否持续超出预设的第一阈值，如果超出所述预设的第一阈值，则继续执行步骤505；否则，结束所述利用预设的软隔离机制对所述应用服务请求进行隔离处理的流程。

上述步骤502～步骤504是利用预设的第一阈值对时间窗口内的GPU内存实际占用量超出GPU内存申请量的程度，即超出比例。假设将第一阈值设置为20％，则可以表示本申请实施例允许GPU内存实际占用量超出GPU内存申请量的20％。虽然同一个GPU运行若干不同的应用服务，且各应用服务均有各自的GPU内存申请量，但各应用服务在同一时刻都运行且同时占满各自GPU内存申请量的几率比较小。因此，为了更加充分地利用昂贵的GPU，本申请实施例允许应用服务进程的GPU内存实际占用量在一定范围内超出GPU内存申请量，也是本申请实施例所述“软隔离机制”的体现之二。

步骤505：计算历史时间内GPU内存实际占用量的平均值。

步骤506：判断计算出的所述平均值与所述GPU内存申请量的比值是否超出预设的第二阈值，如果超出预设的第二阈值，则继续执行步骤507；否则，结束所述利用预设的软隔离机制对所述应用服务请求进行隔离处理的流程。

上述步骤505～步骤506是利用预设的第二阈值对历史时间内的占用GPU内存申请量的情况，即占用比例。假设将第二阈值设置为50％，则表示本申请实施例即使在时间窗口内GPU内存实际占用量超出GPU内存申请量的超出比例已经达到甚至超过第一阈值，但只要其历史时间内总体上占用GPU内存申请量的占用比例未超出第二阈值，可以认为该应用服务进程只是短时间临时占用较多的内存，其总体运行基本上是正常的，并不会影响同一GPU上其他应用服务进程的正常运行。即，本申请实施例不但允许在一定范围内超出GPU内存申请量，而且允许其在短时间超出比例大于第一阈值，是本申请实施例所述“软隔离机制”的体现之三。

步骤507：向所述应用服务实例发送停止指令，以取消所述创建的容器继续运行所述应用服务实例，并取消在分配的GPU上继续运行所述应用服务进程。

如果应用服务进程在时间窗口内GPU内存实际占用量超出GPU内存申请量的超出比例超出第一阈值，且历史时间内总体上占用GPU内存申请量的占用比例也超出第二阈值，那么本申请实施例可以认为运行该应用服务进程时，GPU内存实际占用量超出GPU内存申请量的可能性比较大，影响同一GPU上其他应用服务进程正常运行的概率比较高。此时，本步骤可以由管理模块104向容器引擎108发送针对该应用服务实例的停止指令(比如killcontainer)，从而停止GPU继续运行相应的应用服务进程。

本申请方法实施例二的方案中，利用GPU运行信息和容器运行信息的关联关系，在应用服务实例和应用服务进程之间建立了关联关系，后续可以利用GPU内存实际占用量作为启动“软隔离机制”的条件。另外，本申请实施例中的“软隔离机制”利用多个应用服务在GPU上运行的实际状况，为应用服务的运行提供更加宽容的条件，既充分利用GPU资源，又同时保证多个应用服务在同一GPU上的正常运行。

本申请实施例还提供一种实现GPU虚拟化的系统。图1是本申请实现GPU虚拟化的系统实施例一的示意图。如图1所示，该系统包括控制节点(master-node)101和工作节点(work-node)102。其中：

控制节点101，用于为应用服务请求分配工作节点下的GPU，所述应用服务请求携带有GPU内存申请量；获取所述工作节点102监控的GPU运行信息和容器运行信息，并根据所述GPU运行信息和容器运行信息确定应用服务实例和应用服务进程之间的关联关系，所述GPU运行信息表示在分配的GPU上运行所述应用服务进程状况的信息，所述容器运行信息表示在创建的容器上运行所述应用服务实例状况的信息；基于应用服务实例和应用服务进程之间的关联关系，在应用服务进程对应的GPU内存实际占用量超出应用服务实例对应的所述GPU内存申请量时，利用预设的软隔离机制对应用服务请求进行隔离处理。

工作节点102，用于利用创建的容器运行应用服务请求对应的应用服务实例，并在分配的GPU上运行应用服务进程；监控GPU运行信息和容器运行信息并上报给所述控制节点。

也就是说，在有应用服务请求时，控制节点101为应用服务请求分配工作节点下的GPU；工作节点102利用创建的容器运行应用服务请求对应的应用服务实例，并在分配的GPU上运行应用服务进程。此后，工作节点102监控GPU运行信息和容器运行信息并上报给控制节点101；控制节点101获取所述工作节点102监控的GPU运行信息和容器运行信息，并根据所述GPU运行信息和容器运行信息确定应用服务实例和应用服务进程之间的关联关系；基于应用服务实例和应用服务进程之间的关联关系，在应用服务进程对应的GPU内存实际占用量超出应用服务实例对应的所述GPU内存申请量时，利用预设的软隔离机制对应用服务请求进行隔离处理。

应用本申请系统实施例一，在有应用服务请求时控制节点101为应用服务请求分配GPU，采用GPU虚拟化的技术实现该应用服务请求，可以充分利用GPU资源。同时，在应用服务请求的实现过程中，工作节点102实时监控GPU运行信息和容器运行信息并上报控制节点101。如果GPU内存实际占用量超出该应用服务请求的GPU内存申请量，控制节点101则采用了软隔离机制对该应用服务请求进行隔离处理，从而保护了同一个GPU上其他应用服务请求的正常运行。

图3是本申请实现GPU虚拟化系统实施例二的示意图。如图3所示，该系统仍然包括控制节点101和工作节点102。在一个实施例中，控制节点101可以包括资源调度系统103、管理模块104、时序数据库105。在另一个实施例中，工作节点102可以包括GPU监控模块106、容器监控模块107、容器引擎108。其中：

资源调度系统103，用于为应用服务请求分配工作节点102下的GPU，所述应用服务请求携带有GPU内存申请量；

管理模块104，用于获取工作节点102监控的GPU运行信息和容器运行信息，并根据所述GPU运行信息和容器运行信息确定应用服务实例和应用服务进程之间的关联关系，所述GPU运行信息表示在分配的GPU上运行应用服务进程状况的信息，所述容器运行信息表示在创建的容器上运行应用服务实例状况的信息；基于应用服务实例和所述应用服务进程之间的关联关系，在应用服务进程对应的GPU内存实际占用量超出所述应用服务实例对应的GPU内存申请量时，利用预设的软隔离机制对所述应用服务请求进行隔离处理；

时序数据库105，用于保存工作节点102监控的GPU运行信息。

GPU监控模块106，用于监控GPU运行信息并上报给所述控制节点101，所述GPU运行所述应用服务进程；

容器监控模块107，用于监控容器运行信息并上报给控制节点101；

容器引擎108，用于创建容器运行所述应用服务请求对应的应用服务实例。

也就是说，在有应用服务请求时，资源调度系统103为应用服务请求分配工作节点102下的GPU，由分配的GPU运行应用服务进程，由容器引擎108创建容器运行应用服务请求对应的应用服务实例。此后，GPU监控模块106监控GPU运行信息并上报给所述控制节点101，容器监控模块107监控容器运行信息并上报给控制节点101。管理模块104获取工作节点102监控的GPU运行信息和容器运行信息，并根据GPU运行信息和容器运行信息确定应用服务实例和应用服务进程之间的关联关系。管理模块104基于应用服务实例和应用服务进程之间的关联关系，在应用服务进程对应的GPU内存实际占用量超出应用服务实例对应的GPU内存申请量时，利用预设的软隔离机制对应用服务请求进行隔离处理。

进一步地，工作节点102中GPU监控模块106在监控GPU运行信息时，可以按照设置的采集时间间隔调用所述分配的GPU的驱动接口，获取所述应用服务进程的GPU运行信息，所述GPU运行信息包括当前线程ID和对应的GPU内存实际占用量，所述当前线程ID为所述应用服务进程在分配的GPU上当前运行线程的标识；然后GPU监控模块106将采集到的所述GPU运行信息上报给管理模块104，管理模块104由此获取到工作节点102中GPU监控模块106监控的GPU运行信息。

进一步地，工作节点102中容器监控模块107在监控容器运行信息时，可以获取运行所述应用服务实例的容器对应的容器标识，获取所述应用服务实例对应的所述GPU内存申请量，然后将所述容器标识和所述GPU内存申请量作为所述容器运行信息并上报给管理模块104，管理模块104由此获取到工作节点102中容器监控模块107监控的容器运行信息。

进一步地，管理模块104根据所述GPU运行信息和容器运行信息确定应用服务实例和应用服务进程之间的关联关系时，可以将所述容器运行信息中容器标识作为参数调用容器引擎获得所述容器标识所属容器运行的应用服务实例，作为待关联应用服务实例；确定所述待关联应用服务实例中线程的线程ID，作为待关联线程ID；将所述待关联线程ID与所述GPU运行信息中的当前线程ID进行匹配；匹配成功时，在所述待关联线程ID所属的应用服务实例和所述当前线程ID所属的应用服务进程之间建立关联关系。

按照上述方案，由工作节点102中GPU监控模块106监控GPU运行信息，工作节点102中容器监控模块107监控容器运行信息，并一同上报给控制节点101中的管理模块104。工作节点102内部无需考虑是否隔离，对原有的工作节点102的改动较小，使得本申请方案更加容易实施，已于推广。

在另一系统实施例中，管理模块104利用预设的软隔离机制对应用服务请求进行隔离处理的方法具体可以参见上述方法实施例二的流程图5。具体地，管理模块104可以按照如下方式实现“软隔离机制”：

判断所述应用服务进程对应的GPU内存实际占用量是否超出所述应用服务实例对应的所述GPU内存申请量，所述应用服务进程和所述应用服务实例有关联关系；如果超出，则继续执行；否则，结束所述利用预设的软隔离机制对所述应用服务请求进行隔离处理的步骤；

在预设的时间窗口内查询上报的GPU内存实际占用量；

计算所述预设的时间窗口内上报的所述GPU内存实际占用量与所述GPU内存申请量的差值；

判断计算出的所述差值与所述GPU内存申请量的比值是否持续超出预设的第一阈值，如果超出所述预设的第一阈值，则继续执行；否则，结束所述利用预设的软隔离机制对所述应用服务请求进行隔离处理的步骤；

计算历史时间内所述GPU内存实际占用量的平均值；

判断计算出的所述平均值与所述GPU内存申请量的比值是否超出预设的第二阈值，如果超出预设的第二阈值，则继续执行；否则，结束所述利用预设的软隔离机制对所述应用服务请求进行隔离处理的步骤；

向所述应用服务实例发送停止指令，以取消所述创建的容器继续运行所述应用服务实例，并取消在分配的GPU上继续运行所述应用服务进程。

在这种“软隔离机制”中，如果应用服务进程在时间窗口内GPU内存实际占用量超出GPU内存申请量的超出比例超出第一阈值，且历史时间内总体上占用GPU内存申请量的占用比例也超出第二阈值，认为运行该应用服务进程时GPU内存实际占用量超出GPU内存申请量的可能性比较大，影响同一GPU上其他应用服务进程正常运行的概率比较高。此时，管理模块104向容器引擎108发送针对该应用服务实例的停止指令(比如kill container)，从而停止GPU继续运行相应的应用服务进程。

本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储指令，所述指令在由处理器执行时可执行如上所述实现GPU虚拟化的方法中的步骤。实际应用中，所述的计算机可读介质可以是上述实施例各设备/装置/系统所包含的，也可以是单独存在，而未装配入该设备/装置/系统中。其中，在计算机可读存储介质中存储指令，其存储的指令在由处理器执行时可执行如上所述实现GPU虚拟化的方法中的步骤。

根据本申请公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件，或者上述的任意合适的组合，但不用于限制本申请保护的范围。在本申请公开的实施例中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

如图6所示，本发明实施例还提供一种电子设备。如图6所示，其示出了本发明实施例所涉及的电子设备的结构示意图，具体来讲：

该电子设备可以包括一个或一个以上处理核心的处理器601、一个或一个以上计算机可读存储介质的存储器602以及存储在存储器上并可在处理器上运行的计算机程序。在执行所述存储器602的程序时，可以实现GPU虚拟化的方法。

具体的，实际应用中，该电子设备还可以包括电源603、输入输出单元604等部件。本领域技术人员可以理解，图6中示出的电子设备的结构并不构成对该电子设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：

处理器601是该电子设备的控制中心，利用各种接口和线路连接整个电子设备的各个部分，通过运行或执行存储在存储器602内的软件程序和/或模块，以及调用存储在存储器602内的数据，执行服务器的各种功能和处理数据，从而对该电子设备进行整体监控。

存储器602可用于存储软件程序以及模块，即上述计算机可读存储介质。处理器601通过运行存储在存储器602的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器602可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据服务器的使用所创建的数据等。此外，存储器602可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器602还可以包括存储器控制器，以提供处理器601对存储器602的访问。

该电子设备还包括给各个部件供电的电源603，可以通过电源管理系统与处理器601逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源603还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。

该电子设备还可包括输入输出单元604，该输入单元输出604可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。该输入单元输出604还可以用于显示由用户输入的信息或提供给用户的信息以及各种图像用户接口，这些图形用户接口可以由图形、文本、图标、视频和其任意组合来构成。

本申请附图中的流程图和框图，示出了按照本申请公开的各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或者代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应该注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同附图中所标准的顺序发生。例如，两个连接地表示的方框实际上可以基本并行地执行，它们有时也可以按照相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或者流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本申请中。特别地，在不脱离本申请精神和教导的情况下，本申请的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，所有这些组合和/或结合均落入本申请公开的范围。

本文中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思路，并不用于限制本申请。对于本领域的技术人员来说，可以依据本发明的思路、精神和原则，在具体实施方式及应用范围上进行改变，其所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (10)

1.一种实现GPU虚拟化的方法，其特征在于，该方法包括：

为应用服务请求分配工作节点下的GPU，所述应用服务请求携带有GPU内存申请量；所述工作节点利用创建的容器运行所述应用服务请求对应的应用服务实例，并在分配的GPU上运行应用服务进程；

获取所述工作节点监控的GPU运行信息和容器运行信息，并根据所述GPU运行信息和容器运行信息确定所述应用服务实例和所述应用服务进程之间的关联关系，所述GPU运行信息表示在分配的GPU上运行所述应用服务进程状况的信息，所述容器运行信息表示在创建的容器上运行所述应用服务实例状况的信息；

基于所述应用服务实例和所述应用服务进程之间的关联关系，在所述应用服务进程对应的GPU内存实际占用量超出所述应用服务实例对应的所述GPU内存申请量时，利用预设的软隔离机制对所述应用服务进行隔离处理。

2.根据权利要求1所述的方法，其特征在于，所述获取工作节点监控的GPU运行信息的步骤包括：

接收所述工作节点采集到的GPU运行信息，其中所述工作节点按照设置的采集时间间隔调用所述分配的GPU的驱动接口，获取所述应用服务进程的GPU运行信息，所述GPU运行信息包括当前线程ID和对应的GPU内存实际占用量，所述当前线程ID为所述应用服务进程在分配的GPU上当前运行线程的标识；且所述工作节点上报采集到的所述GPU运行信息。

3.根据权利要求2所述的方法，其特征在于，所述获取工作节点监控的容器运行信息的步骤包括：

接收所述工作节点采集到的容器运行信息，其中所述工作节点获取运行所述应用服务实例的容器对应的容器标识；所述工作节点获取所述应用服务实例对应的所述GPU内存申请量；所述工作节点将所述容器标识和所述GPU内存申请量作为所述容器运行信息并上报。

4.根据权利要求3所述的方法，其特征在于，所述根据GPU运行信息和容器运行信息确定所述应用服务实例和所述应用服务进程之间的关联关系的步骤包括：

将所述容器运行信息中容器标识作为参数调用容器引擎获得所述容器标识所属容器运行的应用服务实例，作为待关联应用服务实例；

确定所述待关联应用服务实例中线程的线程ID，作为待关联线程ID；

将所述待关联线程ID与所述GPU运行信息中的当前线程ID进行匹配；

匹配成功时，在所述待关联线程ID所属的应用服务实例和所述当前线程ID所属的应用服务进程之间建立关联关系。

5.根据权利要求1～4任一项所述的方法，其特征在于，所述基于应用服务实例和所述应用服务进程之间的关联关系，在所述应用服务进程对应的GPU内存实际占用量超出所述应用服务实例对应的所述GPU内存申请量时，利用预设的软隔离机制对所述应用服务进行隔离处理的步骤包括：

判断所述应用服务进程对应的GPU内存实际占用量是否超出所述应用服务实例对应的所述GPU内存申请量，所述应用服务进程和所述应用服务实例有关联关系；如果超出，则继续执行；否则，结束所述利用预设的软隔离机制对所述应用服务请求进行隔离处理的步骤；

在预设的时间窗口内查询上报的GPU内存实际占用量；

计算所述预设的时间窗口内上报的所述GPU内存实际占用量与所述GPU内存申请量的差值；

判断计算出的所述差值与所述GPU内存申请量的比值是否持续超出预设的第一阈值，如果超出所述预设的第一阈值，则继续执行；否则，结束所述利用预设的软隔离机制对所述应用服务请求进行隔离处理的步骤；

计算历史时间内所述GPU内存实际占用量的平均值；

判断计算出的所述平均值与所述GPU内存申请量的比值是否超出预设的第二阈值，如果超出预设的第二阈值，则继续执行；否则，结束所述利用预设的软隔离机制对所述应用服务请求进行隔离处理的步骤；

向所述应用服务实例发送停止指令，以取消所述创建的容器继续运行所述应用服务实例，并取消在分配的GPU上继续运行所述应用服务进程。

6.一种实现GPU虚拟化的系统，其特征在于，该系统包括控制节点和工作节点；

所述控制节点，用于为应用服务请求分配工作节点下的GPU，所述应用服务请求携带有GPU内存申请量；获取所述工作节点监控的GPU运行信息和容器运行信息，并根据所述GPU运行信息和容器运行信息确定所述应用服务实例和所述应用服务进程之间的关联关系，所述GPU运行信息表示在分配的GPU上运行所述应用服务进程状况的信息，所述容器运行信息表示在创建的容器上运行所述应用服务实例状况的信息；基于所述应用服务实例和所述应用服务进程之间的关联关系，在所述应用服务进程对应的GPU内存实际占用量超出所述应用服务实例对应的所述GPU内存申请量时，利用预设的软隔离机制对所述应用服务进行隔离处理；

所述工作节点，用于利用创建的容器运行所述应用服务请求对应的应用服务实例，并在分配的GPU上运行应用服务进程；监控GPU运行信息和容器运行信息并上报给所述控制节点。

7.根据权利要求6所述的系统，其特征在于，所述控制节点包括资源调度系统、管理模块、时序数据库；

所述资源调度系统，用于为应用服务请求分配工作节点下的GPU，所述应用服务请求携带有GPU内存申请量；

所述管理模块，用于获取所述工作节点监控的GPU运行信息和容器运行信息，并根据所述GPU运行信息和容器运行信息确定所述应用服务实例和所述应用服务进程之间的关联关系，所述GPU运行信息表示在分配的GPU上运行所述应用服务进程状况的信息，所述容器运行信息表示在创建的容器上运行所述应用服务实例状况的信息；基于所述应用服务实例和所述应用服务进程之间的关联关系，在所述应用服务进程对应的GPU内存实际占用量超出所述应用服务实例对应的所述GPU内存申请量时，利用预设的软隔离机制对所述应用服务进行隔离处理；

所述时序数据库，用于保存所述工作节点监控的GPU运行信息。

8.根据权利要求6所述的系统，其特征在于，所述工作节点包括GPU监控模块、容器监控模块、容器引擎；

所述GPU监控模块，用于监控GPU运行信息并上报给所述控制节点，所述GPU运行所述应用服务进程；

所述容器监控模块，用于监控容器运行信息并上报给所述控制节点；

所述容器引擎，用于创建容器运行所述应用服务请求对应的应用服务实例。

9.一种计算机可读存储介质，其上存储有计算机指令，其特征在于，所述指令被处理器执行时可实现权利要求1～5任一项所述实现GPU虚拟化的方法。

10.一种电子设备，其特征在于，该电子设备至少包括如权利要求9所述的计算机可读存储介质，还包括处理器；

所述处理器，用于从所述计算机可读存储介质中读取所述可执行指令，并执行所述指令以实现上述权利要求1～5任一项所述实现GPU虚拟化的方法。

Images