CN117519972A

CN117519972A - Gpu资源管理方法及装置

Info

Publication number: CN117519972A
Application number: CN202311472773.5A
Authority: CN
Inventors: 房秋生; 朱永春; 朱哲; 高经梁; 付亮
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2023-11-06
Filing date: 2023-11-06
Publication date: 2024-02-06

Abstract

本说明书实施例提供GPU资源管理方法及装置，该方法应用于云侧节点，包括：接收用户发送的处理请求，对处理请求进行分析，确定处理请求对应的对象标识和GPU资源需求信息；在根据对象标识确定由容器响应处理请求的情况下，基于边缘节点群组中每个边缘节点的空闲容器GPU资源信息，根据GPU资源需求信息从边缘节点集群中确定目标边缘节点，以及在根据对象标识确定由虚拟机响应处理请求的情况下，基于每个边缘节点的空闲虚拟机GPU资源信息，根据GPU资源需求信息从边缘节点群组中确定目标边缘节点，其中，边缘节点群组中包含至少两个边缘节点，每个边缘节点配置有至少两个GPU；将对象标识和GPU资源需求信息，发送至目标边缘节点。

Description

GPU资源管理方法及装置

技术领域

本说明书实施例涉及计算机技术领域，特别涉及一种GPU资源管理方法。

背景技术

随着云原生的普及与推广，考虑到边缘节点CPU的使用成本偏高，边缘节点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资源管理节点，包括：

根据本说明书实施例的第七方面，提供了一种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是本说明书一个实施例提供的一种GPU资源管理系统的结构示意图；

图6是本说明书一个实施例提供的一种GPU资源管理系统的云原生虚拟化示意图；

图7是本说明书一个实施例提供的一种GPU资源管理系统的虚拟机直连GPU架构示意图；

图8是本说明书一个实施例提供的一种GPU资源管理系统的显存隔离的示意图；

图9是本说明书一个实施例提供的一种GPU资源管理系统的模块与硬件交互的示意图；

图10是本说明书一个实施例提供的一种GPU资源管理系统的GPU设备双插件技术及容器虚拟机共池调度流程的示意图；

图11是本说明书一个实施例提供的一种GPU资源管理系统的处理过程流程图；

图12是本说明书一个实施例提供的一种计算设备的结构框图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本说明书。但是本说明书能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本说明书内涵的情况下做类似推广，因此本说明书不受下面公开的具体实施的限制。

在本说明书一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本说明书一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

需要说明的是，本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。

首先，对本说明书一个或多个实施例涉及的名词术语进行解释。

GPU：是Graphics processing unit的英文缩写，即：图像处理单元。

I0T：是Internet of Things的英文缩写，即：物联网。

Kubernetes：简称K8s，是一个开源的，用于管理云平台中多个主机上的容器化的应用。

device plugin：设备插件，可以使设备厂商无需修改Kubernetes核心代码就可以将自已生产的设备的资源(Kubernetes可管理的资源包括CPU、内存和存储资源)让kubelet使用。

KubeVirt：是一个Kubernetes插件，它为Kubernetes提供了在与容器相同的基础结构上提供、管理和控制虚拟机的能力。KubeVirt使Kubernetes能够使用与容器化工作负载相同的工具来调度、部署和管理虚拟机，从而消除了使用不同监视和管理工具的单独环境的必要性。为虚拟机和Kubernetes一起工作提供了可能。使用KubeVirt，您可以声明：创建虚拟机、在Kubernetes群集上调度虚拟机、启动虚拟机、停止虚拟机、删除虚拟机。虚拟机运行在Kubernetes pod中，并利用标准的Kubernetes网络和存储。

Pod：是可以在Kubernetes中创建和管理的最小可部署单元。

eGPU：外置显卡。

CUDA(Compute Unified Device Architecture)，是一种并行计算框架。

Runtime：容器运行时，是容器运行的地方和环境，runtime需要和操作系统kernel紧密协作，为容器提供运行环境。

NVML库：一个基于C语言的程序接口，用于监控和管理GPU中的各种状态。

yaml：一种格式文件。

Annotation：注解。

PCI设备：PCI设备就是指插在这些PCI插槽上的设备。PCI插槽，是基于PCI局部总线(PeripheralComponentlnterconnection，周边元件扩展接口)的扩展插d槽。显卡、声卡、网卡等可以插在PCI插槽上的设备都属于PCI设备。

Linux：一种操作系统

IOMMU：是Input/Output Memory Management Unit的英文简写，是指一个内存管理单元。

vendorID：厂商识别码。

Device ID：设备识别码。

KVM的全称是Kernel-based Virtual Machine，其是一种基于linux内核的采用硬件辅助虚拟化技术的全虚拟化技术。

随着计算机技术的不断发展，相对于高度平台化、高度集中化的数字经济(例如互联网行业)或非实体经济(例如，金融行业)，实体经济和工业生产的大底座能源电力行业不可避免地设立大量地理分散的实体分支机构。例如，无论是风电场站、油田物探还是煤炭矿井，作业现场都会产生大量数据并基于边缘IOT设备进行现场监控与作业管理。现场作业的复杂性，安全生产的重要性都要求边缘节点具有足够自主算力保障自治能力。同时，企业的云侧节点需要与边缘进行密切协同，在场站自治的同时保障企业管控的落实。基于此，云边协同的方案被提出并设计出来。该方案是融合广域网络、大量算力、数据存储及应用服务的分布式开放平台，相对于中心站点(即云侧节点)的全局性、长周期、高时延、大数据的计算特点，边缘侧各站点的短周期、低时延本地数据、快速响应与决策的特性可以更好地支持本地计算任务。边缘侧与云侧并不是简单的替代关系，而是互补协同的合作关系。

在实际应用中，由于图像处理需要消耗大量算力，而传统的CPU(中央处理单元)并非基于密集计算而设计，使用成本偏高。因此，GPU被设计出来提供相对低成本的大量算力，协助CPU进行计算。随着人工智能和大模型的兴起，GPU通常在服务器中用于人工智能模型训练。在云边协同的方案中，通常模型在中心站点(即云侧节点)基于海量算力进行训练，随后部署在边缘站点(即边缘节点)基于本地算力与数据进行现场分析与决策。而为了进一步降低计算成本，边缘站点GPU虚拟化的需求被提出来，通过将边缘站点GPU虚拟化在尽可能的应用服务间复用，可以较大限度的发挥GPU的作用，起到降本增效的作用。

边缘站点GPU虚拟化的方案虽然在一定程度上提供了GPU虚拟化复用的支持，但是随着云原生的普及与推广，面对异构的云环境以及边缘节点中配置的软件程序较为复杂的问题，一台物理机(边缘节点)的GPU虚拟化无法同时支持虚拟机和容器，即配有多块GPU卡的一台物理服务器上，如果使用虚拟机管理GPU，则必须将所有GPU交由虚拟机管理；如果使用容器管理GPU，则必须将所有GPU交由容器管理。例如，本说明书提供的一方案中，该GPU调度方案的维度是节点(服务器)，即需要提前规划好某个节点上的GPU是用于容器还是虚拟机。另一方面，GPU供应商提供了一种vGPU的方案，用于实现GPU的共享调度，但vGPU方案只是解决了GPU虚拟化的问题，vGPU方案在某台服务器上只能给虚拟机或容器使用，因此也没有解决容器和虚拟机在一台物理机上共享GPU调度的问题。因此，由于在同一台机器上无法兼顾虚拟机和容器虚拟化，难以满足最新的客户需求，从而增加了云原生的普及与推广的难度。

基于此，在本说明书中，提供了一种GPU资源管理方法，本说明书同时涉及另一种GPU资源管理方法，一种GPU资源管理装置，另一种GPU资源管理装置，一种GPU资源管理系统，两种GPU资源管理节点，一种计算设备，一种计算机可读存储介质以及一种计算机程序，在下面的实施例中逐一进行详细说明。

图1示出了根据本说明书一个实施例提供的一种GPU资源管理方法的应用场景示意图，该GPU资源管理方法应用于云侧节点。该本说明书提供的GPU资源管理方法中的云侧节点102，能够对至少两个边缘节点104进行管理。并且，每个边缘节点104中配置有至少两个GPU。参见图1可知，服务器集群中包含一个云侧节点102(也即是云端或中心节点)和多个边缘节点104(也即是边缘侧)，每个边缘节点104上配置有多个GPU。并且，边缘节点104上配置的多个GPU设备被划分为容器GPU分组和虚拟机GPU分组。其中，容器GPU分组可以理解为边缘节点中划分为被容器使用的CPU集合。该容器GPU分组中可以包含一个GPU设备，也可以包含至少两个GPU设备。虚拟机GPU分组可以理解为边缘节点中划分为被虚拟机使用的CPU集合。该虚拟机GPU分组中可以包含一个GPU设备，也可以包含至少两个GPU设备。需要说明的是，本说明书提供的GPU资源管理方法能够应用于多种场景，以本方法在发电场站场景下为例，本方法中的服务器集群架构可以应用于发电场站场景。其中，云侧节点102可以对多个边缘节点104进行管理。边缘节点104可以是部署在各地的数百个发电场站中的服务器，通过一个云侧节点102统一对多个边缘节点104进行管理。

基于此，参见图1，当云侧节点接收到用户发送的处理请求的情况下，会对该处理请求进行分析，从而确定响应该处理请求所需要的对象标识和GPU需求资源信息；该响应该处理请求可以通过创建虚拟机或容器来响应该处理请求。然后云侧节点在根据对象标识确定由容器响应该处理请求的情况下，基于边缘节点群组中每个边缘节点的空闲容器GPU资源信息以及所述GPU资源需求信息，从边缘节点集群中确定用于创建容器的目标边缘节点；在根据对象标识确定由虚拟机响应该处理请求的情况下，基于每个边缘节点的空闲虚拟机GPU资源信息以及所述GPU资源需求信息，从边缘节点群组中确定用于创建虚拟机的目标边缘节点。需要说明的是，用于创建容器的目标边缘节点和用于创建虚拟机的目标边缘节点可以是同一个节点。之后将对象标识和GPU资源需求信息发送至该目标边缘节点。以使该边缘节点104能够利用虚拟机GPU分组创建响应该处理请求的虚拟机，以及利用容器GPU分组创建响应该处理请求的容器。从而实现了在同一边缘节点中创建虚拟机和容器，避免了软件程序无法进行虚拟机或容器虚拟化改造的问题，满足了客户需求，有助于云原生的进一步普及与推广。

图2示出了根据本说明书一个实施例提供的一种GPU资源管理方法的流程图，该GPU资源管理方法应用于云侧节点，具体包括以下步骤。

步骤202：接收用户发送的处理请求，对所述处理请求进行分析，确定所述处理请求对应的对象标识和GPU资源需求信息。

需要说明的是，本说明书一个或多个实施例中，该GPU资源管理方法所应用的云侧节点，可以为GPU资源管理系统中的云侧节点。该GPU资源管理系统中还包括至少两个边缘节点，每个边缘节点上配置有至少两个GPU。

其中，该云侧节点可以理解为对边缘节点进行管控的节点，该云侧节点可以是一台或多台服务器。该边缘节点可以理解为被云侧节点进行管控的节点，该边缘节点可以为服务器、物理机或者10T设备，在此不作具体限制。例如，在风电场站、油田物探、煤炭矿井等应用场景中，该边缘节点可以为部署在作业现场中的服务器或者边缘IOT设备。

处理请求可以理解为需要云侧节点控制边缘节点生成容器或虚拟机，进行计算处理的请求。例如，用户通过向云侧节点发送处理请求，指示该云侧节点控制该边缘节点创建响应该处理请求容器或虚拟机，并利用该容器或虚拟机完成特定的计算工作，在创建容器或虚拟机的过程中，边缘节点需要为容器或者虚拟机分配对应的GPU资源。对象标识可以理解为用于表示容器或者虚拟机的标识，后续云侧节点或者边缘节点能够基于该对象标识确定由容器或虚拟机响应该处理请求。例如，对象标识可以为类型信息，标签信息，编号、ID、名称等，在此不作具体限制。该GPU资源需求信息可以理解为用于表示创建容器或虚拟机所需要的GPU资源的信息。通过该GPU资源需求信息，边缘节点可以为容器和虚拟机分配对应的GPU资源。

具体的，本说明书提供的GPU资源管理方法，能够接收用户发送的处理请求。该处理请求可以是用户通过终端发送至云侧节点。或者用户通过云侧节点向用户提供的交互页面，向云侧节点发送处理请求。

步骤204：在根据所述对象标识确定由容器响应所述处理请求的情况下，基于边缘节点群组中每个边缘节点的空闲容器GPU资源信息，根据所述GPU资源需求信息从所述边缘节点集群中确定目标边缘节点，以及在根据所述对象标识确定由虚拟机响应所述处理请求的情况下，基于所述每个边缘节点的空闲虚拟机GPU资源信息，根据所述GPU资源需求信息从所述边缘节点群组中确定目标边缘节点，其中，所述边缘节点群组中包含至少两个边缘节点，所述每个边缘节点配置有至少两个GPU。

其中，空闲容器GPU资源信息可以理解为表示该边缘节点中容器GPU分组当前GPU资源使用情况的信息，例如，通过标签、参数、数值等信息可以标识容器可用的GPU资源。空闲虚拟机GPU资源信息可以理解为表示该虚拟机GPU分组当前GPU资源使用情况的信息，例如，通过标签、参数、数值等信息可以标识虚拟机可用的GPU资源。

边缘节点群组可以理解为由云侧节点所管理的所有边缘节点构成的群组。其中，边缘节点群组中的每个边缘节点，会向云侧节点上报自身CPU、内存、GPU数量、GPU资源使用信息等数据。目标边缘节点可以理解为边缘节点群组中用于创建虚拟机的边缘节点；或者目标边缘节点可以理解为边缘节点群组中用于创建容器的边缘节点。

在本说明书提供的一个或多个实施例中，所述基于边缘节点群组中每个边缘节点的空闲容器GPU资源信息，根据所述GPU资源需求信息从所述边缘节点集群中确定目标边缘节点，包括：

确定边缘节点群组中每个边缘节点的空闲容器GPU资源信息；

根据所述空闲容器GPU资源信息，从边缘节点群组中确定满足所述GPU资源需求信息的至少两个空闲边缘节点；

对每个空闲边缘节点进行评估，获得所述每个空闲边缘节点的第一评估结果；

基于所述第一评估结果，从所述至少两个空闲边缘节点中确定目标边缘节点。

其中，第一评估结果可以理解为云侧节点对边缘节点能否进行容器创建的评估结果，该第一评估结果可以是[0，1]或[0，100]区间内的任意数值。或者该第一评估结果可以是用于表示边缘节点性能的标签，例如非常空闲、空闲等标签。

例如，当云侧节点确定由容器响应该处理请求的情况下，会利用调度器根据创建该容器所需要的GPU资源需求信息，以及该边缘节点的CPU状态、内存状态、用于容器的GPU数量、用于容器的GPU的使用情况等信息，依次筛选每个边缘节点是否满足容器的创造条件，从而获得能够创建该容器的空闲边缘节点，也即是说，筛选剩下的边缘节点，才是可以被调度的边缘节点。当确定边缘节点群组中有多个可以被调度的边缘节点之后。通过算法计算多个可以被调度的边缘节点的分数，并选择分数最高的边缘节点作为能够调度容器的边缘节点，从而能够根据不同边缘节点的实际运行状态，选择性能较优的边缘节点进行容器调度，从而顺利的进行容器创建。其中，计算边缘节点分数的算法是一种可以根据GPU资源需求信息、边缘节点上传的CPU状态、内存状态、用于容器的GPU数量、用于容器的GPU的使用情况等信息，计算出边缘节点性能的算法。该算法可以根据实际应用场景进行设置，在此不作具体限制。

需要说明的是，在根据所述空闲容器GPU资源信息，从边缘节点群组中确定空闲边缘节点，且所述空闲边缘节点为一个的情况下，将所述空闲边缘节点确定为目标边缘节点。

在本说明书提供的一个或多个实施例中，所述基于所述每个边缘节点的空闲虚拟机GPU资源信息，根据所述GPU资源需求信息从所述边缘节点群组中确定目标边缘节点，包括：

确定边缘节点群组中每个边缘节点的空闲虚拟机GPU资源信息；

根据所述空闲虚拟机GPU资源信息，从边缘节点群组中确定满足所述GPU资源需求信息的至少两个空闲边缘节点；

对每个空闲边缘节点进行评估，获得所述每个空闲边缘节点的第二评估结果；

基于所述第二评估结果，从所述至少两个空闲边缘节点中确定目标边缘节点。

其中，第二评估结果可以理解为云侧节点对边缘节点能否进行虚拟机创建的评估结果，该第二评估结果可以是[0，1]或[0，100]区间内的任意数值。或者该第二评估结果可以是用于表示边缘节点性能的标签，例如非常空闲、空闲等标签。

例如，当云侧节点确定由虚拟机响应该处理请求的情况下，会利用调度器根据创建该虚拟机所需要的GPU资源需求信息，以及该边缘节点上传的CPU状态、内存状态、用于虚拟机的GPU数量、用于虚拟机的GPU的使用情况等信息，依次筛选每个边缘节点是否满足虚拟机的创造条件，从而获得能够创建该虚拟机的空闲边缘节点，也即是说，筛选剩下的边缘节点，才是可以被调度的边缘节点。当确定边缘节点群组中有多个可以被调度的边缘节点之后。通过算法计算多个可以被调度的边缘节点的分数，并选择分数最高的边缘节点作为能够调度虚拟机的边缘节点，从而能够根据不同边缘节点的实际运行状态，选择性能较优的边缘节点进行虚拟机调度，从而顺利的进行虚拟机创建。其中，计算边缘节点分数的算法是一种可以根据GPU资源需求信息、边缘节点上传的CPU状态、内存状态、用于虚拟机的GPU数量、用于虚拟机的GPU的使用情况等信息，计算出边缘节点性能的算法。该算法可以根据实际应用场景进行设置，在此不作具体限制。

需要说明的是，在根据所述空闲虚拟机GPU资源信息，从边缘节点群组中确定空闲边缘节点，且所述空闲边缘节点为一个的情况下，将所述空闲边缘节点确定为目标边缘节点。

步骤206：将所述对象标识和所述GPU资源需求信息，发送至所述目标边缘节点。

在本说明书提供的一个或多个实施例中，所述对象标识和所述GPU资源需求信息，发送至目标边缘节点，包括：

基于所述对象标识和所述GPU资源需求信息生成对象配置文件，并将所述对象配置文件发送至目标边缘节点。

其中，所述对象配置文件可以理解为用于配置虚拟机或者容器的配置信息文件。在采用虚拟机响应该处理请求的情况下，该对象配置文件中可以包含配置该虚拟机所需要的虚拟机镜像名称、虚拟机接口信息、虚拟机数量等配置参数。或者，在采用容器响应该处理请求的情况下，该对象配置文件中可以包含配置该容器所需要的容器镜像名称、容器接口信息、容器数量等配置参数。在本说明书提供一个或多个实施例中，该对象配置文件可以为pod的配置文件，可以通过该pod配置文件在边缘节点中创建pod，并在pod中配置虚拟机或容器。在本说明书提供的一实施例中，该pod配置文件可以是指pod模板。Kubernetes中的Pod模板可以是一种创建pod的文档，该pod模板中包含可以用来创建pod的配置、pod的容器镜像、pod的资源需求、pod的端口信息等信息。基于此，本说明书实施例中，可以通过对用户发送的处理请求进行分析，从而获得执行该处理请求所需要的pod配置。利用该pod配置对pod模板中的配置进行调整，例如，pod的资源需求等，从而获得能够执行该处理请求的pod模板。通过该pod模板，为了后续在边缘节点创建pod准备好所需要的环境资源。

具体的，云侧节点基于对象标识和GPU资源需求信息生成对象配置文件，并将对象配置文件发送至目标边缘节点，从而将虚拟机和容器调度至目标边缘节点，并且通过对象配置文件便于目标边缘节点完成对虚拟机和容器的创建。

在本说明书提供的一个或多个实施例中，所述基于所述对象标识和所述GPU资源需求信息生成对象配置文件，包括：

在根据所述对象标识确定由容器响应所述处理请求的情况下，基于所述对象标识和所述GPU资源需求信息生成容器配置文件；以及

在根据所述对象标识确定由虚拟机响应所述处理请求的情况下，基于所述对象标识和所述GPU资源需求信息生成虚拟机配置文件，并将所述虚拟机配置文件转换为所述云侧节点和所述边缘节点识别的容器化虚拟机配置文件。

其中，该容器配置文件用于配置容器的配置信息文件，例如，该容器配置文件可以为pod模板；该虚拟机配置文件用于配置虚拟机的配置信息文件，但是该虚拟机配置文件无法被云侧节点和边缘节点识别，因此无法基于该虚拟机配置文件生成虚拟机。该容器化虚拟机配置文件可以理解为用于配置虚拟机的配置信息文件，但是该容器化虚拟机配置文件能够被云侧节点和边缘节点识别，因此可以基于该虚拟机配置文件生成虚拟机，例如，该容器化虚拟机配置文件可以为转化后的能够被Kubernetes集群识别的pod模板。

沿用上例，该处理请求可以为云侧节点接收的用户发送的计算指令。本说明书提供的个或多个实施例中，在接收到计算指令之后对其进行格式的转换者封装，从而将计算指令变成一个云侧节点中的API server它能够识别到的处理请求。通过对处理请求进行分析，确定执行该处理请求所需要的pod模板。

在本说明书提供的一个或多个实施例中，在确定pod模板之后，通过调度器根据pod模板中的pod配置情况、pod需要的资源，以及每个边缘节点上传的资源信息，确定容器的调度策略。同时，需要确定容器运行的pod需要创建几个pod副本。pod副本是pod的复制，k8s可以在多个边缘节点上调度同一个pod的多个pod副本，从而将pod部署到边缘节点。

由于调度策略中已设定每个pod副本的调度路径，也就是设定好每个pod副本会被调度到哪个边缘节点。因此，云侧节点会记录每个pod副本的调度信息，确定每个pod副本被调度到哪个边缘节点。比如，pod副本1会被调度到边缘节点1。

在完成调度信息的记录之后，会基于这个调度信息确定pod副本需要调度的边缘节点，并将pod模板发送至边缘节点，控制边缘节点基于pod模板拉起容器。后续该边缘节点基于pod模板中记载的容器名称，从容器镜像仓库或者本地缓存中找到对应的容器镜像，并通过容器引擎把相应的容器拉起来。

需要说明的是，本说明书一个或多个实施例中，容器引擎的作用可以为：1、创建容器镜像。该容器镜像可以理解为一种用于创建容器的模板，在运行容器之前需要预先创建多个容器镜像，这些容器镜像会存储在容器镜像仓库或者本地缓存中。当基于pod拉起每一个容器前，根据Pod中指定的容器镜像名称，从容器镜像仓库里面获得对应的容器镜像。在一些情况下，容器镜像可能存储在本地缓存中，因此可以从缓存中获得对应的容器镜像。2、容器引擎是容器的一个运行时。容器在运行过程中由容器引擎提供了运行环境，也就是说，容器引擎设定了如何运行该容器。3、容器引擎能够管理容器，容器引擎不需要Kubernetes，也能够独立地去管理容器。

本说明书提供的一个或多个实施例中，在接收到计算指令之后对其进行格式的转换和封装，从而将计算指令变成一个云侧节点中的API server它能够识别到的处理请求。通过对处理请求进行分析，确定执行该处理请求所需要的虚拟机模板。在本说明书提供的一其他实施例中，在用户创建向云侧节点发送处理请求的情况下，可以同时下发一个用于创建虚拟机的虚拟机模板。该虚拟机模板中可以包含虚拟机的配置和规格。在虚拟机模板中，可以包含需要设置虚拟机的名称、虚拟机镜像名称、资源要求(如CPU、内存、存储等要求)、网络设置等。

在本说明书提供的一个或多个实施例中，当云侧节点在确定虚拟机模板之后，会通过云侧节点中的kubevirt组件把虚拟机模板转换成一个Kubernetes集群识别的Pod模板，也称为虚拟机pod模板。Pod模板指定的GPU资源需求会转换成虚拟机Pod模板的资源需求。需要说明的是，该虚拟机pod模板中包含有虚拟机镜像，该虚拟机镜像用于创建虚拟机。因此，通过pod可以对pod中的虚拟机进行管理，从而做到如同容器一般去管理虚拟机。虚拟机镜像采用容器镜像形式存放在镜像仓库中。通过将虚拟机镜像制作成镜像文件，然后分别推送到不同的镜像仓库中。在创建虚拟机时，可以拉取镜像仓库中的虚拟机镜像，从而快速的创建虚拟机。

云侧节点在确定虚拟机pod模板之后，通过调度器根据虚拟机pod模板中的pod配置情况、pod需要的资源，以及各个边缘节点上报的资源信息，确定调度策略。并且，同时确定这个pod需要创建几个pod副本。

由于调度策略中已设定每个pod副本的调度路径，云侧节点会记录每个pod副本的调度信息，因此，基于调度信息确定pod副本需要调度的边缘节点，并将虚拟机pod模板发送至边缘节点，控制边缘节点基于虚拟机pod模板拉起虚拟机。

在本说明书提供的一实施例中，云侧节点会在下发的Pod模板里添加GPU资源需求，并采用容器GPU资源对应的标识。在下发的虚拟机Pod模板里添加GPU资源需求，并采用虚拟机GPU资源对应的标识。因此，虽然容器和虚拟机GPU资源请求最终都会转换为针对Kubernetes识别的Pod的GPU扩展资源的调度，但容器和虚拟机GPU资源请求分别对应资源标识不同，且调度最终都基于Kubernetes的调度器统一调度，由于容器和虚拟机有不同的资源标识，因此在调度层面不会混淆物理机层面的容器和虚拟机GPU划分。

在本说明书提供的一个或多个实施例中，所述基于边缘节点群组中每个边缘节点的空闲容器GPU资源信息，根据所述GPU资源需求信息从所述边缘节点集群中确定目标边缘节点之前，还包括：

接收所述每个边缘节点发送的空闲容器GPU资源信息和空闲虚拟机GPU资源信息；

基于所述空闲容器GPU资源信息对历史容器GPU资源信息进行更新，并基于所述空闲虚拟机GPU资源信息对历史虚拟机GPU资源信息进行更新。

历史容器GPU资源信息可以理解为云侧节点本地存储的、该边缘节点历史上传的空闲容器GPU资源信息。历史虚拟机GPU资源信息可以理解为云侧节点本地存储的、该边缘节点历史上传的空闲虚拟机GPU资源信息。

具体的，在本说明书提供的GPU资源管理方法中，部署在云侧节点的Kubernetes负责容器的管理和调度，通过Kubernetes能够对服务器集群中的边缘节点进行管理。而边缘节点会上报本地用于容器的GPU数量和用于容器的GPU资源使用信息等空闲容器GPU资源信息，以及上报本地用于虚拟机的GPU数量和用于虚拟机的GPU资源使用信息等空闲虚拟机GPU资源信息，便于云侧节点进行虚拟机和容器的调度。

沿用上例，边缘节点中的kubelet组件根据device-plugin机制识别边缘节点的空闲容器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资源需求信息这些用于创建虚拟机和容器的信息，发送至目标边缘节点，使得该目标边缘节点能够完成虚拟机和容器的创建。从而实现了在同一边缘节点中创建虚拟机和容器，避免了软件程序无法进行虚拟机或容器虚拟化改造的问题，满足了客户需求，有助于云原生的进一步普及与推广。

图3示出了根据本说明书一个实施例提供的另一种GPU资源管理方法的流程图，该另一种GPU资源管理方法应用于边缘节点，具体包括以下步骤。

步骤302：接收云侧节点发送的对象标识和GPU资源需求信息，其中，所述对象标识和所述GPU资源需求信息为所述云侧节点通过对处理请求进行分析获得。

本说明书提供的一个或多个实施例中，所述接收云侧节点发送的对象标识和GPU资源需求信息，包括：

接收所述云侧节点发送的对象配置文件，其中，所述对象配置文件为所述云侧节点通过对用户发送的处理请求进行分析获得的对象标识和GPU资源需求信息生成。

其中，针对该对象配置文件、处理请求等内容的解释，可以参见上述一种GPU资源管理方法中对应或相应的内容，在此不过多赘述。

例如，边缘节点接收到云侧节点下发的对象配置文件之后，会从该对象配置文件中确定对象标识和GPU资源需求信息。该对象标识用于确定响应该处理请求的是容器还是虚拟机，该GPU资源需求信息用于分配该容器或虚拟机的GPU资源。并且后续能基于该对象配置文件快速的创建虚拟机或容器，提高容器或虚拟机的创建效率。

步骤304：在根据所述对象标识确定由容器响应所述处理请求的情况下，从容器GPU分组中分配与所述GPU资源需求信息对应的容器GPU资源，并基于所述容器GPU资源创建响应所述处理请求的容器，以及在根据所述对象标识确定由虚拟机响应所述处理请求的情况下，从虚拟机GPU分组中分配与所述GPU资源需求信息对应的虚拟机GPU资源，并基于所述虚拟机GPU资源创建响应所述处理请求的虚拟机。

其中，容器GPU分组可以理解为边缘节点中划分为被容器使用的CPU集合。该容器GPU分组中可以包含一个GPU设备，也可以包含至少两个GPU设备。虚拟机GPU分组可以理解为边缘节点中划分为被虚拟机使用的CPU集合。该容器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的分配结果通过记录到pod上，便于后续容器设备插件按照分配结果为容器申请GPU内存。

在本说明书提供的一个或多个实施例中，边缘节点选择虚拟机GPU分组中的空闲GPU作为虚拟机GPU资源，从而支持该虚拟机的正常运行。所述从虚拟机GPU分组中分配与所述GPU资源需求信息对应的虚拟机GPU资源，包括：

确定虚拟机GPU分组中的空闲虚拟机GPU；

将所述空闲虚拟机GPU确定为与所述GPU资源需求信息对应的虚拟机GPU资源。

沿用上例，边缘节点在确定待处理对象为虚拟机之后，会从虚拟机GPU分组中选择一个空闲GPU设备，并将该空闲GPU设备作为与GPU资源需求信息对应的虚拟机GPU资源，便于后续基于该虚拟机GPU资源创建虚拟机。

在本说明书提供的一个或多个实施例中，所述对象配置文件为容器配置文件；

相应的，所述基于所述容器GPU资源创建响应所述处理请求的容器，包括：

从所述容器配置文件中获取容器镜像标识，并从容器镜像库中获取与所述容器镜像标识对应的容器镜像；

运行所述容器镜像，获得响应所述处理请求的容器，并将所述容器GPU资源与所述容器绑定。

其中，该容器镜像标识可以理解为唯一标识一个容器镜像的信息，例如，该容器镜像的名称、编号等。该容器镜像库可以理解为用于存储该容器镜像的存储单元。该容器镜像库可以是缓存、内存、外存等存储设备中用于存储该容器镜像的区域。

沿用上例，云侧节点将pod模板发送至边缘节点之后，边缘节点，会基于pod模板中记载的容器名称，从容器镜像仓库或者本地缓存中找到对应的容器镜像，并通过容器引擎把相应的容器拉起来，从而快速的完成对响应该处理请求的容器进行创建。该容器云侧在pod中。该容器可以为一个或至少两个。

在本说明书提供的一个或多个实施例中，所述对象配置文件为容器化虚拟机配置文件；

相应的，所述基于所述虚拟机GPU资源创建响应所述处理请求的虚拟机，包括：

从所述容器化虚拟机配置文件中获取虚拟机镜像标识，并从容器镜像库中获取与所述虚拟机镜像标识对应的虚拟机镜像：

根据虚拟机配置参数运行所述虚拟机镜像，获得响应所述处理请求的容器化虚拟机，将所述虚拟机GPU资源与所述容器化虚拟机绑定。

其中，该虚拟机镜像标识可以理解为唯一标识一个虚拟机镜像的信息，例如，该虚拟机镜像的名称、编号等。

该虚拟机配置参数可以理解为该虚拟机运行所需要的硬件配置参数，例如，硬盘参数、CPU参数、内存参数、端口参数等等。该硬件配置参数是通过各种虚拟机模拟组件模拟生成的。需要说明的是，由于虚拟机在运行过程中，需要通过虚拟机模拟组件模拟该虚拟机运行的各种硬件参数，因此，边缘节点在创建该虚拟机的过程中，需要配置对应的组件来模拟该虚拟机的运行环境。该虚拟机模拟组件可以为kvm和/或qemu。

沿用上例，云侧节点将虚拟机pod模板发送至边缘节点之后，该边缘节点会基于虚拟机pod模板中记载的虚拟机镜像名称，从容器镜像仓库或者本地缓存中找到对应的虚拟机镜像，并通过kvm和/或qemu为虚拟机运行模拟对应的硬件配置，从而将容器化虚拟机运行起来。需要说明的是，该容器化虚拟机可以为一个或至少两个。该容器化虚拟机可以运行在pod中，被pod管理。实现像管理容器一样管理虚拟机，进一步实现在一台物理机上同时配置容器和虚拟机。

需要说明的是，当需要在虚拟机中部署应用的情况下，需要在云侧节点登录到虚拟机，再利用云侧节点向虚拟机中部署应用。

在本说明书提供的一个或多个实施例中，本说明书提供的GPU资源管理方法，为了提高管理效率，可以一个云侧节点管理多个边缘节点的虚拟机和容器。而通过云侧节点统一管理多个边缘节点算力资源的架构，可以为“云边虚拟化超融合架构”。

此外，将虚拟机和容器在边缘节点中运行，是由于边缘节点中的计算任务可能有时效性要求，如果将虚拟机和容器运行在云侧节点运行，会导致延迟较高，无法及时处理边缘节点中的计算任务。

在本说明书提供的一个或多个实施例中，由于容器GPU分组采用了eGPU共享调度方案，可以实现多个容器对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配置为虚拟机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资源的使用情况时，可以调用该查询组件通过NVML库来查询当前容器使用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资源创建响应所述处理请求的虚拟机。从而实现了在同一边缘节点中创建虚拟机和容器，避免了软件程序无法进行虚拟机或容器虚拟化改造的问题，满足了客户需求，有助于云原生的进一步普及与推广。

图4示出了根据本说明书一个实施例提供的一种GPU资源管理系统的应用场景示意图。根据图4可知，本说明书提供了一种云边场景下边缘侧容器虚拟机GPU共池调度整体架构，在云边虚拟化超融合架构下，本系统分为云侧管控侧和边缘侧，并实行云端管控、边缘适度自治的策略。其中，云侧节点402基于云原生虚拟化实现虚拟机的管理和运维。容器和虚拟机共用Kubernetes集群计算、网络、存储等资源，并通过Kubernetes实现容器和虚拟化资源的全局统一调度。云侧节点402部署管控侧组件，包含Kubernetes管控组件、云边协同控制面组件和云原生虚拟化控制面组件。本说明书提供的GPU资源管理系统，支持边缘节点404一键加入边缘集群，并通过边缘节点404池统一管理边缘节点404。而云边场景下边缘节点404数量少，资源短缺，每个边缘节点404(即服务器节点)可以配置多张GPU卡，支持同时服务调度到此节点上的虚拟机和容器的AI应用使用GPU的需求。

其中，在云边虚拟化超融合架构下，边缘节点404会基于云侧节点402的指令，对本地GPU进行分组。以图4为例，如果一台边缘节点404(裸金属服务器)有四张GPU卡，其中两张GPU卡GPU-1，GPU-2直通虚拟机，作为部署在虚拟机上的AI(人工智能)应用算力供应；另外两张GPU卡GPU-3，GPU-4通过GPU共享调度的方式，同时提供给本台边缘节点404上的所有容器共享使用。

此外，需要说明的是，本说明书提供的GPU资源管理系统采用容器虚拟机GPU共池调度核心技术；该技术在实现容器与虚拟机GPU共池调度过程中，核心技术基础有四点：1、云原生虚拟化技术：实现容器和虚拟机统一管理。2、GPU驱动隔离技术：内核层面为容器和虚拟机分配GPU资源，粒度更细。3、容器GPU共享调度技术：通过提供的容器GPU共享调度方案，实现容器GPU共享调度和高密度部署，增加本方案实际落地价值。4、GPU设备双插件技术：虚拟机和容器可以用两个插件分别管理对应的GPU资源，每个插件各司其职，非常简洁。

而本说明书提供的GPU资源管理系统进行GPU资源管理的过程为：首先，云侧节点402在边缘节点404进行GPU资源预先分组之后，按需配置用于容器的容器GPU驱动和用于虚拟机的虚拟机GPU驱动。其次，云侧节点402在边缘节点404配置用于容器的容器设备插件和用于虚拟机的虚拟机设备插件。该设备插件能够分别识别对应的驱动，用于容器的容器设备插件能够识别容器GPU驱动，用于虚拟机的虚拟机设备插件能够识别虚拟机GPU驱动。并且，设备插件利用对应的GPU驱动管理边缘节点404中的GPU资源以及向云侧节点402上报GPU资源使用情况。最后，云侧节点402接收到用户发送的处理请求的情况下，会向边缘节点404下发对象配置文件。边缘节点404中的容器设备插件或者虚拟机设备插件会分别基于云侧节点402下发的对象配置文件，调用容器GPU驱动或虚拟机GPU驱动，从而为虚拟机或容器分配对应的GPU资源，并创建虚拟机或容器。从而实现在同一边缘节点404中有效兼顾了虚拟机和容器虚拟化，避免了软件程序无法进行虚拟机或容器虚拟化改造的问题。

本图5示出了根据本说明书一个实施例提供的一种GPU资源管理系统的结构示意图，所述系统包括云侧节点以及至少两个边缘节点，每个边缘节点504配置有至少两个GPU，其中，

所述边缘节点，被配置为接收云侧节点发送的对象标识和GPU资源需求信息，其中，所述对象标识和所述GPU资源需求信息为所述云侧节点通过对处理请求进行分析获得；在根据所述对象标识确定由容器响应所述处理请求的情况下，从容器GPU分组中分配与所述GPU资源需求信息对应的容器GPU资源，并基于所述容器GPU资源创建响应所述处理请求的容器，其中，所述容器运行在容器管理单元中，以及在根据所述对象标识确定由虚拟机响应所述处理请求的情况下，从虚拟机GPU分组中划分与所述GPU资源需求信息对应的虚拟机GPU资源，并基于所述虚拟机GPU资源创建响应所述处理请求的虚拟机，其中，所述虚拟机运行在容器管理单元中。

在本说明书提供的一实施例中，本说明书提供的GPU资源管理系统采用云原生虚拟化技术，该云原生虚拟化技术通过Kubernetes和kubevirt实现了容器和虚拟机共池管理，即同时在边缘节点(即物理机、服务器，该物理机、服务器包含对应的操作系统)上单层编排和调度容器和虚拟机。具体参见图6，图6是本说明书一个实施例提供的一种GPU资源管理系统的云原生虚拟化示意图。从而使得容器和虚拟机可以实现统一的资源调度，而不是传统虚拟机和容器分开管理的模式。云原生虚拟化是容器虚拟机GPU共池调度的基石，这使得容器和虚拟机GPU共池调度成为可能。

其中，该云侧节点可以理解为GPU资源管理系统中对边缘节点进行管控的节点，该云侧节点可以是一台或多台服务器。该边缘节点可以理解为GPU资源管理系统中被云侧节点进行管控的节点，该边缘节点可以为服务器、物理机或者IOT设备，在此不作具体限制。例如，在风电场站、油田物探、煤炭矿井等应用场景中，该边缘节点可以为部署在作业现场中的服务器或者边缘I0T设备。需要说明的是，该GPU资源管理系统中包含多个边缘节点。处理请求可以理解为指示该边缘节点创建虚拟机或容器执行特定计算任务的请求。

容器管理模块可以理解为边缘节点中部署的、用于对容器进行管理的设备插件；虚拟机管理模块可以理解为边缘节点中部署的、用于对虚拟机进行管理的设备插件。在本说明书提供的一个或多个实施例中，为了实现利用同一台物理机(边缘节点)中的GPU资源，在该物理机中同时创建虚拟机和容器，本说明书提供的GPU资源处理方法通过容器管理模块对容器GPU驱动模块进行管理，从而利用容器管理模块，通过容器GPU驱动模块使用该边缘节点的GPU资源，从而达到利用边缘节点的GPU资源进行容器创建的目的。同理，本说明书提供的GPU资源处理方法通过虚拟机管理模块对虚拟机GPU驱动模块进行管理，从而利用虚拟机管理模块，通过虚拟机GPU驱动模块使用该边缘节点的GPU资源，从而达到利用边缘节点的GPU资源进行虚拟机创建的目的。在本说明书提供的一实施例中，本说明书提供的GPU资源管理系统，为了能够利用边缘节点中GPU资源在该边缘节点中同时创建虚拟机和容器，因此采用Kubernetes和kubevirt实现了在同一台边缘节点中创建容器和虚拟机。但是，由于Kubernetes和kubevirt在运行过程中无法利用到边缘节点中的GPU资源。所以在边缘节点中配置容器管理模块和容器GPU驱动模块，该Kubernetes通过该容器管理模块和容器GPU驱动模块能够识别到GPU资源，从而利用该边缘节点中的GPU资源创建容器。同时，在边缘节点中配置虚拟机管理模块和虚拟机GPU驱动模块，该Kubernetes和kubevirt通过该虚拟机管理模块和虚拟机GPU驱动模块能够识别到GPU资源，从而利用该边缘节点中的GPU资源创建虚拟机。也即是说，本说明书提供的GPU资源管理系统采用GPU设备双插件技术，该技术考虑到每个边缘节点只会为每个同类型的设备安装一个设备插件的问题，为了实现容器和虚拟机共池调度，会在GPU驱动隔离技术的基础上采用双插件机制，从而解决了容器和虚拟机资源分配的问题。其中，针对虚拟机采用虚拟机设备插件(可以理解为上述虚拟机管理模块)与GPU直连的方案，使得该虚拟机设备插件能感知虚拟机GPU驱动模块绑定的GPU，并可以通过直连的方式，使得虚拟机绑定该GPU。该虚拟机GPU驱动模块可以理解为针对虚拟机GPU分组中的GPU设备进行管理的驱动程序。图7是本说明书一个实施例提供的一种GPU资源管理系统的虚拟机直连GPU架构示意图。基于图7可知，在边缘节点中，虚拟机设备插件能够识别虚拟机GPU驱动绑定的GPU，并通过Kubernetes对虚拟机GPU分组中的GPU进行管理，从而利用该虚拟机GPU分组中的GPU创建虚拟机。需要说明的是，本说明书实施例中提供的虚拟机，可以是一种容器化虚拟机，基于图7可知，该虚拟机所运行的pod中包含KVM和Qemu容。该KVM和Qemu可以为虚拟机的运行，模拟对应的硬件配置参数。

其中，容器管理单元可以理解为边缘节点中对容器和容器化虚拟机进行管理的单元。例如，该容器管理单元可以为pod。

其中，针对容器创建采用容器设备插件(可以理解为上述容器管理模块)实现，可以做到单个节点多GPU场景下容器对于GPU的共享调度。该容器设备插件能感知容器GPU驱动模块绑定的GPU，使得容器绑定该GPU。该容器GPU驱动模块可以理解为针对容器GPU分组中的GPU设备进行管理的驱动程序。需要注意的是，本说明书提供的GPU资源管理系统，在利用容器设备插件实现容器对于GPU的共享调度的过程中，提出了一种容器GPU共享调度技术。该容器GPU共享调度技术中的容器识别插件，主要利用device plugin的机制。在节点上通过kubelet(一种部署在边缘节点的组件)调用，负责实现Pod的GPU共享调度，通过兼容较多GPU驱动的版本，适配主流的显卡。并且，通过eGPU(CUDA劫持)提供算力和显存隔离的能力。

而本说明书提供的GPU资源管理系统所采用一种应用容器引擎，该应用容器引擎可以打包应用以及依赖包到一个可移植的镜像中，然后发布到操作系统的机器(例如边缘节点)，也可以实现虚拟化。该应用容器引擎可以通过修改Runtime实现，当该应用容器运行时，会默认对容器的启动参数进行修改，从而达到对runtime进行修改的目的。该应用容器引擎中包含信息收集组件，该信息收集组件可以将容器中的信息收集并处理，以及调用一种容器挂载组件。该容器挂载组件用于将GPU驱动和一些需要进行依赖的组件和库文件挂载到容器中，该容器挂载组件主要以Host挂载的形式存在。例如，该信息收集组件会根据环境变量判断是否会分配GPU设备以及挂载的设备iD。如果是未指定或者是无效(void)，则认为是非GPU容器，不做任何处理。否则调用该容器挂载组件，并将GPU设备作为参数传入。容器挂载组件会将驱动库的so文件和GPU设备信息，通过文件挂载的方式映射到容器中，这样容器就能访问到GPU。具体实现过程可以参见图8，图8是本说明书一个实施例提供的一种GPU资源管理系统中显存隔离的示意图。其中，本说明书中提供的容器设备插件的eGPU，能够通过劫持CUDA的方式做到GPU共享调度。参见图8，eGPU在CUDA调用库之上封装了一层显存控制组件做到显存控制。同时还实现了一个显存使用情况查询组件来查询GPU显存使用情况。用户程序在调用CUDA API时会首先进入显存控制组件中，显存控制组件会触发查询动作和显存使用情况查询组件进行通讯，在显存使用情况查询组件中通过NVML库来查询当前容器使用GPU存储的情况。显存控制组件会根据返回的查询结果来决定内存分配相关的调用操作(API)执行成功与否。同时，通过另一个算力分配组件进行算力的分配。在Pod的yaml里面申请了GPU资源以后，算力分配组件在调度阶段判断节点上单个GPU卡是否能够提供足够的GPU存储资源，并且在分配的阶段将GPU的分配结果通过annotation记录到pod上，以便插件设备按照分配结果为容器申请GPU内存。

其中，容器GPU分组可以理解为边缘节点中划分为被容器使用的CPU集合。该容器GPU分组中可以包含一个GPU设备，也可以包含至少两个GPU设备。例如图4中边缘节点的GPU-3、GPU-4。虚拟机GPU分组可以理解为边缘节点中划分为被虚拟机使用的CPU集合。该容器GPU分组中可以包含一个GPU设备，也可以包含至少两个GPU设备。例如图4中边缘节点的GPU-1、GPU-2。

在本说明书提供的一实施例中，为了进一步降低计算成本，边缘站点GPU虚拟化的需求被提出来。同时，本说明书提供的GPU资源管理系统为了实现一台物理机上GPU虚拟化同时支持虚拟机和容器，会将该物理机上的GPU划分为两个部分，分别供虚拟机或容器使用。而所述边缘节点上部署的虚拟机GPU驱动模块和容器GPU驱动模块都支持绑定和解绑PCI设备，这为本方案从底层去分割不同的GPU资源打下了基础。在开启对应的模块，通过调用虚拟机GPU驱动模块和容器驱动GPU模块将不同的PCI设备绑定不同的驱动，可以实现不同模块纳管不同的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分组信息可以理解为GPU数量，而边缘节点根据该GPU数量随机将指定数量的GPU设备划分为虚拟机GPU分组。

下面对边缘节点基于分组信息对GPU设备进行分组为例，本说明书提供的GPU资源管理模块进行说明。具体地，在开启虚拟机GPU驱动程序(可以理解为上述虚拟机GPU驱动模块)之后，根据PCI设备的vendorID与DeviceID写入对应的配置文件以后，虚拟机GPU驱动程序会根据PCI设备的ID，将对应的PCI设备注册为虚拟机GPU驱动程序的设备。当基于GPU分组信息将GPU进行分组的过程中，要根据容器GPU分组信息以及虚拟机GPU分组信息识别出本地GPU中，哪些GPU被划分为容器GPU分组以及哪些GPU被划分为虚拟机GPU分组。容器GPU驱动模块安装运行以后，会检测PCI设备，并加载对应的组件管理被划分为容器GPU分组的PCI设备。如果一个设备被虚拟机GPU驱动程序绑定，那么该设备不能同时被容器GPU驱动模块管理。此时，如果需要指定该特定设备(即容器GPU分组信息中记录的、需要被划分至容器GPU分组的GPU设备)被容器GPU驱动模块绑定，可以通过虚拟机GPU驱动程序提供的用户态函数将该PCI设备解绑，此时设备处于无人认领状态。可以通过函数根据PCI设备的ID，将容器GPU驱动程序(可以理解为上述容器GPU驱动模块)绑定对应的PCI设备。通过此种PCI设备的动态绑定和解绑配置，可以做到在一个系统下，同时存在PCI设备被虚拟机GPU驱动程序纳管和容器GPU驱动程序纳管。

其中，虚拟机GPU驱动模块与容器GPU驱动模块各自的具体原理参见图9，图9是本说明书一个实施例提供的一种GPU资源管理系统的模块与硬件交互的示意图。虚拟机GPU驱动模块采用的是一种将物理设备直接分配给虚拟机的技术。虚拟机GPU驱动模块在硬件开启虚拟化能力的情况下，可以将设备I/0、DMA等能力暴露给用户态，从而使用户在虚拟机中可以直接访问其绑定的设备。虚拟机GPU驱动模块通过设备文件向用户态提供统一的访问接口(虚拟机GPU驱动模块的接口)，其与物理设备交互如图所示。虚拟机GPU驱动模块的接口封装了内存管理单元驱动和内存管理单元组件进行交互，通过PCI总线驱动和PCI总线组件进行交互。前者向用户态暴露了DMA等操作，后者向用户态提供了设备配置模拟等功能。用户可以通过调用虚拟机GPU驱动程序的接口绑定对应的PCI设备，在此处是GPU。虚拟机GPU驱动程序将会把绑定的设备映射成dev0、dev1等设备标识文件。在虚拟机GPU驱动程序绑定其他设备之前，需要将设备从其他驱动解绑。虚拟机GPU驱动模块的设备管理有Container、Group、Device的概念。一个container(容器)对应多个group(组)，一个group对应多个device(GPU设备)。整个容器可以看作一个物理设备域，划分取决于硬件的IOMMU拓扑。

在容器GPU驱动模块以后，其会自动绑定PCI设备(GPU)。CUDA驱动可以在用户态被调用，通过CUDA驱动可以调用容器GPU驱动模块，最终使用GPU的能力。

在本说明书提供的一实施例中，所述边缘节点，还被配置为接收所述云侧节点发送的待安装的容器管理模块以及待安装的虚拟机管理模块；

将所述待安装的容器管理模块以及所述待安装的虚拟机管理模块进行安装；

识别所述容器管理模块对应的所述容器GPU驱动模块，并将所述容器管理模块与所述容器GPU驱动模块绑定；

识别所述虚拟机管理模块对应的所述虚拟机GPU驱动模块，并将所述虚拟机管理模块与所述虚拟机GPU驱动模块绑定。

沿用上例，容器和云原生虚拟机GPU共池调度方案基于Kubernetes设备插件机制实现。基于Kubernetes实现虚拟机和容器的GPU资源的统一调度，通过边缘节点的kubeletdevice Plugin机制实现与节点GPU资源的分配和释放等。基于此，边缘节点能够接收云侧节点发送的虚拟机设备插件和容器设备插件，并将其安装在本地。其中，该两种设备插件仅能够识别到与之对应的GPU驱动。虚拟机设备插件与虚拟机GPU驱动模块中的PCI总线驱动对应，并基于PCI总线驱动管理虚拟机GPU资源；容器设备插件与容器GPU驱动模块对应，并基于容器GPU驱动模块管理容器GPU资源，从而便于后续通过两个设备插件实现在同一台边缘节点中创建虚拟机和容器，并对其进行管理。

在本说明书提供的一实施例中，为了便于云侧节点对边缘节点中GPU资源的使用情况进行监测，边缘节点中的GPU资源管理模块会向云侧节点上报该GPU资源使用情况，从而使云侧节点能够根据边缘节点的GPU资源使用情况，对其进行管理。具体的，所述边缘节点，还被配置为通过所述容器管理模块以及所述容器GPU驱动模块，确定空闲容器GPU资源信息；

通过所述虚拟机管理模块以及所述虚拟机GPU驱动模块，确定空闲虚拟机GPU资源信息；

通过GPU资源管理模块将所述空闲容器GPU资源信息以及所述空闲虚拟机GPU资源信息，发送至所述云侧节点。

其中，该GPU资源管理模块可以理解为边缘节点中部署的、对边缘节点的工作情况运行情况进行监测的模块。例如，该GPU资源管理模块可以是Kubelet，该Kubelet是一种组件，可以定期从云侧节点接收新的或修改的Pod规范，并确保Pod及其容器在期望规范下运行。同时该组件作为向云侧节点汇报边缘节点的运行状况。

空闲容器GPU资源信息可以理解为表示该容器GPU分组当前GPU资源使用情况的信息，例如，标识容器可用的GPU资源的参数、数值等信息。空闲虚拟机GPU资源信息可以理解为表示该虚拟机GPU分组当前GPU资源使用情况的信息，例如，标识虚拟机可用的GPU资源的参数、数值等信息。

沿用上例，kubelet根据设备插件机制识别边缘节点的GPU资源。kubelet将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资源管理模块。

沿用上例，容器设备插件的eGPU在CUDA调用库之上封装了一层显存控制组件做到显存控制。同时还实现了一个显存使用情况查询组件来查询GPU显存使用情况。当容器设备插件需要查询容器GPU显存的使用情况时，调用该显存使用情况查询组件通过NVML库来查询当前容器使用GPU资源的情况。并将该当前容器使用GPU资源的情况上报至kubelet组件。

在本说明书提供的一实施例中，云侧节点为了保证容器或虚拟机的顺利创建，会根据边缘节点的容器GPU和虚拟机GPU的使用情况，选择较优的边缘节点(即空闲GPU资源能够满足待创建的容器或虚拟机使用的边缘节点)，并向其发送容器或虚拟机创建请求。具体的，所述云侧节点，还被配置为接收用户发送的处理请求；

需要说明的是，针对生成该容器配置文件、容器化虚拟机配置文件的描述，可以参见上述实施例中对应或相应的解释，在此不过多赘述。

在确定容器配置文件、容器化虚拟机配置文件之后，在根据所述对象标识确定由容器响应所述处理请求的情况下，基于边缘节点群组中每个边缘节点的空闲容器GPU资源信息，根据所述GPU资源需求信息从所述边缘节点集群中确定目标边缘节点，并将容器配置文件发送至目标边缘节点。

在根据所述对象标识确定由虚拟机响应所述处理请求的情况下，基于所述每个边缘节点的空闲虚拟机GPU资源信息，根据所述GPU资源需求信息从所述边缘节点群组中确定目标边缘节点，并将容器化虚拟机配置文件发送至目标边缘节点。

沿用上例，传统方案针对一种设备，只会使用一种设备插件实现资源的感知和管理分配。本说明书提供的GPU资源管理系统，通过双插件技术实现了对GPU资源的共池管理，上述实施例已经介绍通过驱动隔离技术实现了单台边缘节点的GPU资源对虚拟机和容器的划分，双插件分别通过双驱动管理其对应的GPU资源，并通过不同的资源标识来保证虚拟机和容器对GPU资源的使用不会冲突。

基于此，图10是本说明书一个实施例提供的一种GPU资源管理系统的GPU设备双插件技术及容器虚拟机共池调度流程的示意图，其中，容器和虚拟机共享调度的流程，具体如图10所示。本说明书针对虚拟机的管理基于云原生虚拟化实现，在用户创建虚拟机的情况下，会下发一个虚拟机模板，云侧节点中kubevirt组件会把虚拟机模板转换成一个Kubernetes集群识别的虚拟机Pod模板，虚拟机模板指定的GPU资源需求会转换成虚拟机Pod模板的资源需求。

当用户创建容器时，会默认在下发的Pod模板里添加GPU资源的需求。即容器和虚拟机的gpu资源请求最终都会转换为Kubernetes识别的Pod的gpu扩展资源的调度，分别对应的资源标识不同，且调度最终都基于Kubernetes的调度器统一调度，由于容器和虚拟机有不同的资源标识，因此在调度层面不会混淆物理机层面的容器和虚拟机GPU划分。值得一提的是调度器在Kubernetes原生调度的基础上，针对容器gpu共享调度添加了共享GPU调度扩展，实现了容器共享gpu的调度，虚拟机调度则基于原生调度实现，不受共享GPU调度扩展的限制，二者和平共存。

其中，针对GPU设备双插件技术，基于图10可知，虚拟机设备插件通过虚拟机GPU驱动程序管理分配给虚拟机GPU资源，并将虚拟机要使用的GPU资源上报到node信息中，并可以查看虚拟机的GPU资源总量和可分配GPU资源数。

而容器设备插件通过容器GPU驱动程序管理分配容器GPU资源，并将容器要使用的GPU资源上报到node信息中，并可以通过查看容器的GPU资源总量和分配的GPU资源数。通过这种方式实现了容器和虚拟机GPU资源的统一管理。

在本说明书提供的一实施例中，该边缘节点能够通过容器设备插件调用容器GPU驱动，从共享容器GPU中划分GPU资源，从而支持该容器的正常运行。具体的，所述容器管理模块，还被配置为向所述容器GPU驱动模块发送容器GPU分配指令，其中，所述容器GPU分配指令中包含所述GPU资源需求信息；

所述容器GPU驱动模块，被配置为响应于所述容器GPU分配指令，从所述容器GPU分组包含的容器共享GPU中确定空闲容器GPU资源；

从所述空闲容器GPU资源中，分配与所述GPU资源需求信息对应的容器GPU资源。

沿用上例，容器设备插件，通过算力分配组件进行算力的分配。在Pod的yaml里面申请了GPU资源以后，算力分配组件在调度阶段判断边缘节点的容器GPU分组中的单个GPU卡是否能够提供足够的GPU内存，并且从当前空闲的GPU资源中，划分出与用户创建容器所需的GPU资源为一致的空闲GPU资源。最后在分配的阶段将GPU的分配结果通过记录到pod上，以供容器设备插件后续按照分配结果为容器继续申请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资源与所述容器化虚拟机绑定。

其中，基于对象配置文件创建容器化虚拟机可以理解为从所述容器化虚拟机配置文件中获取虚拟机镜像标识，并从容器镜像库中获取与所述虚拟机镜像标识对应的虚拟机镜像；根据虚拟机配置参数运行所述虚拟机镜像，获得响应所述处理请求的容器化虚拟机，

其中，该容器和容器化虚拟机创建过程可以参见上述实施例中对应或相应的内容。在此不过多赘述。

沿用上例，当边缘节点识别到虚拟机被调度到当前节点后，通过虚拟机pod模板拉起虚拟机。之后通过虚拟机设备插件分配对应的虚拟机GPU资源，并将该CPU设备(即虚拟机GPU资源)挂载到虚拟机。

当边缘节点识别到容器被调度到当前节点，通过pod模板拉起容器，并通过容器设备插件分配对应的容器GPU资源。将GPU设备(即容器GPU资源对应的GPU设备)挂载到容器，并根据GPU资源请求限制容器对容器GPU资源的使用。

在本说明书提供的一实施例中，本方案采用了eGPU共享调度方案，可以在虚拟机GPU直通方案的基础上，实现多个容器对GPU共享调度。但是，为了保证多个容器对GPU共享调度的正常执行，避免调用错误导致的故障，需要管理容器对GPU资源的使用。具体的，所述边缘节点，还被配置为在所述容器针对所述容器GPU资源执行调用操作的情况下，基于所述容器管理模块确定所述容器GPU资源的当前使用状态；

沿用上例，用户程序在调用CUDA API时会首先进入显存控制组件中，在需要时显存控制组件会触发查询动作显存使用情况查询组件通讯，在显存使用情况查询组件中通过NVML库来查询当前容器使用GPU资源的情况。显存控制组件会根据返回的查询结果来决定相关的调用操作执行成功与否。

基于上述实施例可知，本说明书一实施例提供的GPU资源管理系统，通过在边缘节点部署容器管理模块和虚拟机管理模块，从而当云侧节点将对象标识和GPU资源需求信息发送至边缘节点的情况下，边缘节点能够基于容器管理模块从容器GPU分组中分配与GPU资源需求信息对应的容器GPU资源，并基于所述容器GPU资源创建响应所述处理请求的容器；或者基于虚拟机管理模块从虚拟机GPU分组中分配与GPU资源需求信息对应的虚拟机GPU资源，并基于所述虚拟机GPU资源创建响应所述处理请求的虚拟机。从而实现了在同一边缘节点中创建虚拟机和容器虚拟化，避免了软件程序无法进行虚拟机或容器虚拟化改造的问题，满足了客户需求，有助于云原生的进一步普及与推广。

下述结合附图11，以本说明书提供的GPU资源管理系统在针对GPU资源调度场景下的应用为例，对所述GPU资源管理系统进行进一步说明。其中，图11示出了本说明书一个实施例提供的一种GPU资源管理系统的处理过程流程图，本说明书提供的GPU资源管理系统采用了容器和云原生虚拟机GPU共池调度方案，基于Kubernetes设备插件机制实现虚拟机和容器的GPU资源的统一调度，并通过边缘节点设备插件机制实现与节点GPU资源的分配和释放等。具体包括以下步骤。

步骤1102：边缘节点，按照云端控制面(云端节点)下发的GPU分组需求，将物理机GPU资源预先分组并按需配置驱动。如GPU-1，GPU-2用于虚拟机，并配置虚拟机GPU驱动程序；GPU-3，GPU-4用于容器，配置容器GPU驱动程序。

步骤1104：边缘节点，安装虚拟机设备插件，并基于虚拟机驱动程序管理虚拟机GPU资源。以及安装容器设备插件，并基于容器GPU驱动程序管理容器GPU资源。

步骤1106：边缘节点，通过kubelet根据d设备插件识别边缘节点GPU资源。

步骤1108：边缘节点，通过kubelet将GPU资源上报到云端控制面，这时云侧节点可以获取到虚拟机和容器可用的GPU资源，该GPU资源可以用于云端容器和虚拟机的资源调度。

步骤1110：云端控制面，接收用户的处理请求，对该处理请求进行分析，获得创建容器或虚拟机的GPU资源需求。

其中，该云端控制面可以理解为云侧节点；用户可以在处理请求中声明GPU需求。

需要说明的是，云端控制面还部署有Kubernetes管控组件、云原生虚拟化控制面组件。通过该组件对边缘节点池统一管理。

步骤1112：云端控制面，利用云端控制面调度器将容器或虚拟机调度到满足用户声明的GPU资源的边缘节点上。

步骤1114：边缘节点，识别到虚拟机被调度到当前节点，拉起虚拟机，通过虚拟机设备插件分配对应的GPU资源，并将设备挂载到虚拟机。

步骤1116：边缘节点识别到容器被调度到当前节点，拉起容器，通过容器设备插件分配对应的GPU资源，并将GPU挂载到容器，并根据GPU资源请求限制容器对GPU资源的使用。

基于此，本说明书中GPU资源管理系统所采用的支持虚拟机和容器GPU共池调度的云边协同方案，其核心在于支持虚拟机和容器GPU共池调度，即配有多块GPU卡的一台物理服务器上，一部分物理GPU卡使用虚拟机管理的同时，另一部分物理GPU卡使用容器管理。其主要特征在于：1、不同于传统虚拟化方案，本说明书提供的方案基于云原生虚拟化，可以实现容器与虚拟机共享Kubernetes调度、网络、存储和计算资源。通过Kubernetes设备插件机制可以实现物理服务器节点上的GPU资源的统一上报、调度和管理等，这是容器和虚拟机GPU共池调度的核心基础。2、本方案通过内核驱动隔离了容器和虚拟机使用的GPU。容器GPU设备插件能感知容器GPU驱动程序，虚拟机设备插件只能感知虚拟机GPU驱动程序，从而实现了容器和虚拟机使用的GPU卡的隔离。在此基础上，容器和虚拟机可以基于各自的设备插件实现GPU卡的调度、分配和资源管理等。3本方案采用了eGPU共享调度方案，可以在虚拟机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资源创建响应所述处理请求的容器；或者从虚拟机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资源管理方法的技术方案的描述。

图12示出了根据本说明书一个实施例提供的一种计算设备1200的结构框图。该计算设备1200的部件包括但不限于存储器1210和处理器1220。处理器1220与存储器1210通过总线1230相连接，数据库1250用于保存数据。

计算设备1200还包括接入设备1240，接入设备1240使得计算设备1200能够经由一个或多个网络1260通信。这些网络的示例包括公用交换电话网(PSTN，Public SwitchedTelephone Network)、局域网(LAN，Local Area Network)、广域网(WAN，Wide AreaNetwork)、个域网(PAN，Personal Area Network)或诸如因特网的通信网络的组合。接入设备1240可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC，networkinterface controller))中的一个或多个，诸如IEEE802.11无线局域网(WLAN，WirelessLocal Area Network)无线接口、全球微波互联接入(Wi-MAX，WorldwideInteroperability for Microwave Access)接口、以太网接口、通用串行总线(USB，Universal Serial Bus)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC，Near FieldCommunication)。

在本说明书的一个实施例中，计算设备1200的上述部件以及图12中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图12所示的计算设备结构框图仅仅是出于示例的目的，而不是对本说明书范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。

计算设备1200可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或个人计算机(PC，Personal Computer)的静止计算设备。计算设备1200还可以是移动式或静止式的服务器。

其中，处理器1220用于执行如下计算机可执行指令，该计算机可执行指令被处理器执行时实现上述GPU资源管理方法的步骤。

上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的GPU资源管理方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述GPU资源管理方法的技术方案的描述。

本说明书一实施例还提供一种计算机可读存储介质，其存储有计算机可执行指令，该计算机可执行指令被处理器执行时实现上述GPU资源管理方法的步骤。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的GPU资源管理方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述GPU资源管理方法的技术方案的描述。

本说明书一实施例还提供一种计算机程序，其中，当所述计算机程序在计算机中执行时，令计算机执行上述GPU资源管理方法的步骤。

上述为本实施例的一种计算机程序的示意性方案。需要说明的是，该计算机程序的技术方案与上述的GPU资源管理方法的技术方案属于同一构思，计算机程序的技术方案未详细描述的细节内容，均可以参见上述GPU资源管理方法的技术方案的描述。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本说明书实施例并不受所描述的动作顺序的限制，因为依据本说明书实施例，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本说明书实施例所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上公开的本说明书优选实施例只是用于帮助阐述本说明书。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本说明书实施例的内容，可作很多的修改和变化。本说明书选取并具体描述这些实施例，是为了更好地解释本说明书实施例的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本说明书。本说明书仅受权利要求书及其全部范围和等效物的限制。

Claims

1.一种GPU资源管理方法，应用于云侧节点，包括：

2.根据权利要求1所述的GPU资源管理方法，所述基于边缘节点群组中每个边缘节点的空闲容器GPU资源信息，根据所述GPU资源需求信息从所述边缘节点集群中确定目标边缘节点，包括：

确定边缘节点群组中每个边缘节点的空闲容器GPU资源信息；

3.根据权利要求1所述的GPU资源管理方法，所述基于所述每个边缘节点的空闲虚拟机GPU资源信息，根据所述GPU资源需求信息从所述边缘节点群组中确定目标边缘节点，包括：

4.根据权利要求1所述的GPU资源管理方法，所述基于边缘节点群组中每个边缘节点的空闲容器GPU资源信息，根据所述GPU资源需求信息从所述边缘节点集群中确定目标边缘节点之前，还包括：

5.根据权利要求1所述的GPU资源管理方法，所述将所述对象标识和所述GPU资源需求信息，发送至目标边缘节点，包括：

6.根据权利要求5所述的GPU资源管理方法，所述基于所述对象标识和所述GPU资源需求信息生成对象配置文件，包括：

7.根据权利要求1所述的GPU资源管理方法，所述基于边缘节点群组中每个边缘节点的空闲容器GPU资源信息，根据所述GPU资源需求信息从所述边缘节点集群中确定目标边缘节点之前，还包括：

8.一种GPU资源管理方法，应用于边缘节点，包括：

9.根据权利要求8所述的GPU资源管理方法，所述接收云侧节点发送的对象标识和GPU资源需求信息之前，还包括：

10.根据权利要求9所述的GPU资源管理方法，所述将所述待分配虚拟机GPU配置为虚拟机GPU分组，将所述待分配容器GPU配置为容器GPU分组之后，还包括：

11.根据权利要求10所述的GPU资源管理方法，所述确定所述容器GPU分组对应的空闲容器GPU资源信息，包括：

识别所述容器GPU分组包含的容器共享GPU的运行状态信息；

12.根据权利要求10所述的GPU资源管理方法，所述确定所述虚拟机GPU分组对应的空闲虚拟机GPU资源信息，包括：

识别所述虚拟机GPU分组中的空闲虚拟机GPU；

13.根据权利要求8所述的GPU资源管理方法，所述接收云侧节点发送的对象标识和GPU资源需求信息，包括：

14.根据权利要求13所述的GPU资源管理方法，所述对象配置文件为容器配置文件；

15.根据权利要求13所述的GPU资源管理方法，所述对象配置文件为容器化虚拟机配置文件；

16.根据权利要求8所述的GPU资源管理方法，所述从容器GPU分组中分配与所述GPU资源需求信息对应的容器GPU资源，包括：

17.根据权利要求8所述的GPU资源管理方法，所述从虚拟机GPU分组中分配与所述GPU资源需求信息对应的虚拟机GPU资源，包括：

确定虚拟机GPU分组中的空闲虚拟机GPU；

18.根据权利要求8所述的GPU资源管理方法，所述基于所述容器GPU资源创建响应所述处理请求的容器之后，还包括：

19.一种GPU资源管理节点，包括：

20.一种GPU资源管理节点，包括：

21.一种GPU资源管理系统，所述系统包括云侧节点以及至少两个边缘节点，每个边缘节点配置有至少两个GPU，其中，

22.一种GPU资源管理装置，应用于云侧节点，包括：

23.一种GPU资源管理装置，应用于边缘节点，包括：

24.一种计算设备，包括：

存储器和处理器；

所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令，该计算机可执行指令被处理器执行时实现权利要求1至7中任意一项所述GPU资源管理方法，以及权利要求8至18中任意一项所述GPU资源管理方法的步骤。

25.一种计算机可读存储介质，其存储有计算机可执行指令，该计算机可执行指令被处理器执行时实现权利要求1至7中任意一项所述GPU资源管理方法，以及权利要求8至18中任意一项所述GPU资源管理方法的步骤。