CN115686805A - Gpu资源共享的方法和装置、调度gpu资源共享的方法和装置 - Google Patents

Abstract

本申请提出了一种GPU资源共享的方法和装置、调度GPU资源共享的方法和装置、计算设备以及计算机存储介质。所述GPU资源共享的方法包括：接收创建容器的请求；调用运行于操作***的内核态的内核模块创建虚拟子GPU，使得所述虚拟子GPU占用真实GPU的部分资源；将虚拟子GPU适配到所述操作***，使得虚拟子GPU对于所述容器可用；将所述虚拟子GPU挂载到所述容器，使得在所述容器被创建后所述虚拟子GPU利用所占用的真实GPU的部分资源处理所述容器的计算请求。

Description

GPU资源共享的方法和装置、调度GPU资源共享的方法和装置

技术领域

本公开涉及计算机技术的领域，尤其涉及GPU（graphics processing unit，图形处理单元）资源共享的方法和装置、调度GPU资源共享的方法和装置、计算设备以及计算机存储介质。

背景技术

随着计算机技术的发展，对GPU资源共享的需求日益增加，例如云计算领域，GPU集群的规模正急速扩张。作为示例，在需要根据多个进程的需求分别规划布局大量的GPU资源的情形下，可以通过GPU资源共享提高GPU的使用效率。目前，在常规的GPU资源共享的方法中，通常通过创建并配置容器实现GPU资源共享。

然而，在常规的GPU资源共享的方法中，有的方法不支持创建容器，特别是可限制资源的容器；有的方法支持创建这样的容器，但仅支持通过在用户态来实现资源共享，而用户有机会绕过用户态的限制，最终导致GPU资源共享的安全性不高。现有GPU资源共享方法大多在用户态实现，然而由于用户态的环境相对复杂且更新频繁，因此GPU资源共享方法也需要随环境而更新，这大大增加了GPU资源共享的复杂度。

发明内容

有鉴于此，本公开提供了GPU资源共享的方法和装置、调度GPU资源共享的方法和装置、计算设备以及计算机存储介质，期望克服上面提到的部分或全部缺陷以及其它可能的缺陷。

根据本公开的第一方面，提供了一种GPU资源共享的方法，包括：接收创建容器的请求；调用运行于操作***的内核态的内核模块创建虚拟子GPU，使得所述虚拟子GPU占用真实GPU的部分资源；将虚拟子GPU适配到所述操作***，使得虚拟子GPU对于所述容器可用；将所述虚拟子GPU挂载到所述容器，使得在所述容器被创建后所述虚拟子GPU利用所占用的真实GPU的部分资源处理所述容器的计算请求。

在一些实施例中，调用运行于操作***的内核态的内核模块创建虚拟子GPU，使得所述虚拟子GPU占用真实GPU的部分资源包括：响应于待创建的容器请求GPU资源，调用运行于操作***的内核态的内核模块创建虚拟子GPU，使得所述虚拟子GPU占用真实GPU的部分资源。

在一些实施例中，还包括：接收资源参数，所述资源参数指示待创建的容器请求的真实GPU的部分资源的量，以及其中，调用运行于操作***的内核态的内核模块创建虚拟子GPU，使得所述虚拟子GPU占用真实GPU的部分资源，包括：调用运行于操作***的内核态的内核模块创建虚拟子GPU；向所述内核模块发送资源参数，使得所述内核模块响应于确定所述请求的部分资源的量不超过真实GPU的未被占用的资源的量，基于所述资源参数配置所述虚拟子GPU占用真实GPU的所述部分资源的量。

在一些实施例中，将所述虚拟子GPU挂载到所述容器包括：将所述虚拟子GPU的设备名称设定为具有真实GPU的设备名称的形式；将所述虚拟子GPU挂载到所述容器，以便所述容器可以通过所述虚拟子GPU的设备名称识别所述虚拟子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资源共享方法被执行，以便使待创建的容器占用当前节点的真实GPU的资源的一部分。

在一些实施例中，当前节点包括已创建的容器，以及其中，确定当前节点的节点信息包括：确定当前节点的真实GPU的资源的总量和已创建容器所占用的真实GPU的资源的量。

在一些实施例中，当前节点的真实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示出了根据本公开的实施例的技术方案可以实施在其中的示例性应用场景；

图2图示了根据本公开的一个实施例的一种GPU资源共享的方法的示意性流程图；

图3图示了根据本公开的一个实施例的创建虚拟子GPU的方法的示意性流程图；

图4图示了根据本公开的一个实施例的将虚拟子GPU挂载到容器的方法的示意性流程图；

图5图示了一种调度GPU资源共享的方法的示意性流程图；

图6图示了根据本公开的一个实施例的GPU资源共享的方法的示例性的具体原理架构图；

图7图示了根据本公开的一个实施例的GPU资源共享的方法的运行于操作***的内核态的内核模块的示例性的具体原理框架图；

图8图示了根据本公开的一个实施例的限制虚拟子GPU的显存的方法的示例性的具体原理架构图；

图9图示了根据本公开的一个实施例的限制虚拟子GPU的显存的方法的实验效果图；

图10图示了根据本公开的一个实施例的配置所述虚拟子GPU占用真实GPU的算力的具体原理架构图；

图11图示了根据本公开的一个实施例的调度GPU资源共享的方法的示例性的具体原理架构图；

图12图示了根据本公开的一个实施例的GPU资源共享方法中GPU资源利用率的实验效果图；

图13A图示了根据本公开的一个实施例的GPU资源共享方法中大任务独占GPU资源的性能对比实验效果图；

图13B图示了根据本公开的一个实施例的GPU资源共享方法中大任务共享GPU资源的性能对比实验效果图；

图14图示了根据本公开的一个实施例的GPU资源共享方法中小任务独占GPU资源和共享GPU资源时的实验效果图；

图15图示了根据本公开的一个实施例的一种GPU资源共享装置的示例性结构框图；

图16图示了根据本公开的一个实施例的一种调度GPU资源共享的装置的示例性结构框图；

图17图示了一个示例***，其包括代表可以实现本文描述的各种技术的一个或多个***和/或设备的示例计算设备。

具体实施方式

下面的描述提供了本公开的各种实施例的特定细节，以便本领域的技术人员能够充分理解和实施本公开的各种实施例。应当理解，本公开的技术方案可以在没有这些细节中的一些细节的情况下被实施。在某些情况下，本公开并没有示出或详细描述一些熟知的结构或功能，以避免这些不必要的描述使对本公开的实施例的描述模糊不清。在本公开中使用的术语应当以其最宽泛的合理方式来理解，即使其是结合本公开的特定实施例被使用的。

首先，对本申请实施例中涉及的部分用语进行说明，以便于本领域技术人员理解。

GPU：图形处理器（英语：graphics processing unit，缩写：GPU），又称显示核心、视觉处理器、显示芯片，是一种专门在个人电脑、工作站、游戏机和一些移动设备（如平板电脑、智能手机等）上做图像和图形相关运算工作的微处理器。GPU使显卡减少了对CPU的依赖，并进行部分原本CPU的工作，尤其是在3D图形处理时GPU所采用的核心技术有硬件T&L（几何转换和光照处理）、立方环境材质贴图和顶点混合、纹理压缩和凹凸映射贴图、双重纹理四像素256位渲染引擎等，而硬件T&L技术可以说是GPU的标志。GPU的生产商主要有NVIDIA和ATI。

操作***：操作***（operating system，简称OS）是管理计算机硬件与软件资源的计算机程序。操作***需要处理如管理与配置内存、决定***资源供需的优先次序、控制输入设备与输出设备、操作网络与管理文件***等基本事务。操作***也提供一个让用户与***交互的操作界面。目前，常见的操作***主要有：Microsoft Windows、MacOS X、Linux、Unix等。

CUDA：CUDA（Compute Unified Device Architecture），是显卡厂商NVIDIA推出的运算平台。 CUDA™是一种由NVIDIA推出的通用并行计算架构，该架构使GPU能够解决复杂的计算问题。它包含了CUDA指令集架构（ISA）以及GPU内部的并行计算引擎。开发人员可以使用C语言来为CUDA™架构编写程序，所编写出的程序可以在支持CUDA™的处理器上以超高性能运行。CUDA3.0已经开始支持C++和FORTRAN。

容器：是一种对应用层代码和依赖关系的一种抽象，多个容器运行在同一个物理机(也称宿主机)上，共享着同一个操作***(Operating System，OS)内核。容器不同于虚拟机，虚拟机是一种对物理设备的一种抽象，虚拟机将一台宿主机抽象成多个机器，每个虚拟机提供一个完整的操作***。容器内的所有应用App，不需要经过虚拟化的过程，而虚拟机的应用都要经历各种虚拟化过程，需要多次的上下文切换，性能会比容器内的App差。

docker：docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux或Windows 机器上，以实现虚拟化。

用户设备：可以安装各类应用程序，并且能够将已安装的应用程序中提供的对象进行显示的电子设备，该电子设备可以是移动的，也可以是固定的。例如，手机、平板电脑、各类可穿戴设备、车载设备、个人数字助理(personal digital assistant，PDA)、销售终端(point of sales，POS)、地铁站内的监控设备或其它能够实现上述功能的电子设备等。

人工智能(Artificial Intelligence，AI)是利用数字计算机或者数字计算机控制的机器模拟、延伸和扩展人的智能，感知环境、获取知识并使用知识获得最佳结果的理论、方法、技术及应用***。人工智能软件技术主要包括计算机视觉技术、语音处理技术、自然语言处理技术以及机器学习/深度学习等几大方向。

kubernetes：简称为k8s，是自动化容器操作的开源平台，这些操作包括部署、调度和节点集群间扩展等，kubernetes集群表示一组节点(node)，这些节点可以是物理服务器或者虚拟机，之上安装了kubernetes平台。

Pod：是kubernetes项目中最小的API对象，由多个容器和相关配置信息构成，在kubernetes中，最基本的管理单位是Pod，而不是容器(container)，Pod是kubernetes在容器上的一层封装，由一组运行在同一主机的一个或者多个容器组成，通过Pod封装这是因为容器推荐的用法是里面只运行一个进程，而一般情况下某个应用都是由多个组件构成的。容器的本质是进程，就是未来云计算***中的进程，容器镜像就是这个***里的".exe"安装包，相应地kubernetes可以理解为操作***。

Kubelet：kubernetes是一个分布式的集群管理***，在执行具体的业务容器的节点上都要运行一个运行者(worker)对容器进行生命周期的管理，这个worker程序就是Kubelet，Kubelet是运行在每个节点上的主要的“节点代理”，每个节点都会启动Kubelet进程，用来处理主(master)节点下发到本节点的任务，按照PodSpec描述来管理Pod和其中的容器(其中，PodSpec是用来描述一个Pod的YAML或者JSON对象)，通常情况下Kubelet的主要工作是创建、销毁Pod，Kubelet需要对Pod资源进行监听，Kubelet会监听想要监听的Pod，即那些已经分配到本节点的Pod。

调度器(Scheduler)：调度器根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将***中的资源分配给各个正在运行的应用程序。调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位是容器，从而限定每个任务使用的资源量。调度器不负责监控或者跟踪应用程序的状态，也不负责任务因为各种原因而需要的重启（由ApplicationMaster负责）。总之，调度器根据应用程序的资源要求，以及集群机器的资源情况，为用程序分配封装在容器中的资源。云技术(Cloudtechnology)：基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络***的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台***进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的***后盾支撑，只能通过云计算来实现。

云计算(cloud computing)：指IT基础设施的交付和使用模式，指通过网络以按需、易扩展的方式获得所需资源；广义云计算指服务的交付和使用模式，指通过网络以按需、易扩展的方式获得所需服务。这种服务可以是IT和软件、互联网相关，也可是其他服务。云计算是网格计算(Grid Computing)、分布式计算(DistributedComputing)、并行计算(Parallel Computing)、效用计算(Utility Computing)、网络存储(NetworkStorageTechnologies)、虚拟化(Virtualization)、负载均衡(Load Balance)等传统计算机和网络技术发展融合的产物。

在本申请提供的技术方案中，涉及云计算中虚拟化技术，并且主要涉及GPU资源共享的技术。

根据本公开的实施例的技术方案可以实施在其中的示例性应用场景100。如图1所示，所示应用场景包括包含GPU 110和与GPU 110通信耦合的设备120，GPU 110上运行着多个共享GPU资源的容器，GPU 110可以被配置在设备120中也可以被配置在设备120外。

作为示例，当设备120产生计算需求时，会将计算请求发送到设备中的GPU 110，并等待GPU 110返回计算结果。为了提高GPU的运算效率，需要根据多个进程的需求分别规划布局大量的GPU资源，因此可以通过GPU资源共享提高GPU的使用效率。在常规的GPU资源共享的方法中，通常通过创建并配置容器实现GPU资源共享。如图1中所示，通过在设备120的操作***的用户态中创建一个或多个容器实现对GPU 110资源的共享，提升GPU 110的工作效率，最终改善用户对设备120的使用体验。

作为示例，当在用户态实施本公开的GPU资源共享的方法时，首先，接收创建容器的请求；然后，调用运行于操作***的内核态的内核模块创建虚拟子GPU，使得所述虚拟子GPU占用真实GPU的部分资源；接着，将虚拟子GPU适配到所述操作***，使得虚拟子GPU对于所述容器可用；最后，将所述虚拟子GPU挂载到所述容器，使得在所述容器被创建后所述虚拟子GPU利用所占用的真实GPU的部分资源处理所述容器的计算请求。

上面描述的场景仅仅是本公开的实施例可以被实施在其中的一个示例，并不是限制性的。例如，GPU 110可以是常见的图形处理器，如NVIDIA和ATI旗下的多种型号的GPU。设备120可以是终端或者服务器等能与GPU通信耦合的设备。当设备120是终端时，其可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，此处不做限制。当设备120是服务器时，其可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式***，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。

图2图示了根据本公开的一个实施例的一种GPU资源共享的方法200的示意性流程图。所述GPU资源共享的方法例如可以在如图1所示的设备120上实施。如图2所示，所述方法200包括如下步骤。

在步骤210，接收创建容器的请求。作为示例，可以接收来自docker引擎的创建容器的请求，也可以接收来自其他组件的创建容器的请求。

在步骤220，调用运行于操作***的内核态的内核模块创建虚拟子GPU，使得所述虚拟子GPU占用真实GPU的部分资源。作为示例，所述操作***可以是Linux、也可以是Unix等其他操作***，此处不做限制。当所述操作***是Linux时，其内核态用于控制计算机的硬件资源，并提供上层应用程序运行的环境。依托于内核提供的资源（包括CPU资源、存储资源、I/O资源等），位于用户态中的进程才能得到执行。

在一些实施例中，在调用运行于操作***的内核态的内核模块创建虚拟子GPU，使得所述虚拟子GPU占用真实GPU的部分资源时，可以响应于待创建的容器请求GPU资源，来调用运行于操作***的内核态的内核模块创建虚拟子GPU，使得所述虚拟子GPU占用真实GPU的部分资源。作为示例，当发现待创建的容器请求GPU资源时，即调用运行于Linux操作***内核态的内核模块创建虚拟子GPU。

在步骤230，将虚拟子GPU适配到所述操作***，使得虚拟子GPU对于所述容器可用。在一些实施例中，当将虚拟子GPU适配到所述操作***使得虚拟子GPU对于所述容器可用时，通过将虚拟子GPU添加到操作***的资源控制组中，使得虚拟子GPU对于所述容器可用，其中所述操作***的资源控制组用于限制、控制与分离进程占用的资源。作为示例，当所述操作***是Linux时，可以将所述虚拟子GPU添加到Linux cgroup 的白名单中。LinuxCGroup全称Linux控制组（Linux Control Group）， 是Linux内核的一个功能，用来限制，控制与分离一个进程组群的资源（如CPU、内存、磁盘输入输出等）。

在步骤240，将所述虚拟子GPU挂载到所述容器，使得在所述容器被创建后所述虚拟子GPU利用所占用的真实GPU的部分资源处理所述容器的计算请求。作为示例，当所述虚拟子GPU挂载到所述容器后，所述容器中进程的计算请求将不再发送给真实GPU，而是发送给虚拟子GPU，所述虚拟子GPU在接收容器的计算请求后，利用所占用的真实GPU的部分资源处理所述容器的计算请求。

所述方法200通过调用运行于操作***的内核态的内核模块创建虚拟子GPU，实现了对GPU资源的共享。然后，通过将虚拟子GPU挂载到待创建的容器上，使得容器上的进程的计算需求被发送到虚拟子GPU，内核模块可以再调用真实GPU资源处理虚拟子GPU接收到的进程的计算需求。由于执行核心功能（即，创建虚拟子GPU）的内核模块运行的内核态，致使用户无法绕过内核模块的限制，提升了GPU资源共享的安全性。而且，本公开的GPU资源共享方案支持容器，并且由于内核态通常更新较少，避免了用户环境的频繁更新所带来的不便，减少了使用本方法的复杂度。

在一些实施例中，如图2图示出的根据本公开的一个实施例的一种GPU资源共享的方法200还包括：接收资源参数，所述资源参数指示待创建的容器请求的真实GPU的部分资源的量。在这种情况下，调用运行于操作***的内核态的内核模块创建虚拟子GPU，使得所述虚拟子GPU占用真实GPU的部分资源的示意性流程可以如图3所示。作为示例，所述资源参数可以包括待创建的容器请求的真实GPU的显存和算力的量，例如请求100MiB的显存和真实GPU总算力的1/4的算力。图3图示了根据本公开的一个实施例的创建虚拟子GPU的方法300的示意性流程图，其包括：在步骤310，调用运行于操作***的内核态的内核模块创建虚拟子GPU；在步骤320，向所述内核模块发送资源参数，使得所述内核模块响应于确定所述请求的部分资源的量不超过真实GPU的未被占用的资源的量，基于所述资源参数配置所述虚拟子GPU占用真实GPU的所述部分资源的量。

在一些实施例中，所述资源参数包括待创建的容器请求的真实GPU的显存量，当向所述内核模块发送资源参数使得所述内核模块响应于确定所述请求的部分资源的量不超过真实GPU的未被占用的资源的量以基于所述资源参数配置所述虚拟子GPU占用真实GPU的所述部分资源的量时，向所述内核模块发送资源参数使得所述内核模块响应于确定所述请求的显存量不超过真实GPU的未被占用的显存的量，基于所述请求的显存量配置所述虚拟子GPU占用真实GPU的显存的量。

作为示例，若所述请求的部分资源的量超过真实GPU的未被占用的资源的量，例如所述请求的部分资源的量是400MiB而真实GPU的未被占用的资源的量是200MiB，则将拒绝为所述虚拟子GPU配置400MiB的显存。若所述请求的部分资源的量不超过真实GPU的未被占用的资源的量，例如所述请求的部分资源的量是50MiB而真实GPU的未被占用的资源的量是100MiB，则将基于所述资源参数为所述虚拟子GPU配置50MiB的显存。

在一些实施例中，所述资源参数包括所述资源参数包括待创建的容器请求的真实GPU的算力，当向所述内核模块发送资源参数使得所述内核模块响应于确定所述请求的部分资源的量不超过真实GPU的未被占用的资源的量，基于所述资源参数配置所述虚拟子GPU占用真实GPU的所述部分资源的量时，向所述内核模块发送资源参数，使得所述内核模块响应于确定所述请求的算力不超过真实GPU的未被占用的算力，基于所述请求的算力通过为所述虚拟子GPU分配的真实GPU的时间片的数量来配置所述虚拟子GPU占用真实GPU的算力。

作为示例，若所述请求的部分资源的量超过真实GPU的未被占用的资源的量，例如所述请求的部分资源的量是的真实GPU的算力的总量的1/4，未被占用的资源是真实GPU的算力的总量的1/8，则将拒绝按真实GPU的算力的总量的1/4配置虚拟子GPU。若所述请求的部分资源的量不超过真实GPU的未被占用的资源的量，例如所述请求的部分资源的量是真实GPU的算力的总量的1/16而真实GPU的未被占用的资源的量是真实GPU的算力的总量的1/4，则将按真实GPU的算力的总量的1/16配置虚拟子GPU。

由此可以看出，图3示出的方法300可以对容器占用GPU资源进行有效限制，避免了因容器申请的GPU资源总量超出真实的GPU资源量而导致的过载，减少了进程因GPU资源过载而报错的风险，提升了进程运行的安全性和稳定性。

图4图示了根据本公开的一个实施例的将虚拟子GPU挂载到容器的方法400的示意性流程图。如图4所示，在一些实施例中，将所述虚拟子GPU挂载到所述容器包括：在步骤410，将所述虚拟子GPU的设备名称设定为具有真实GPU的设备名称的形式；在步骤420，将所述虚拟子GPU挂载到所述容器，以便所述容器可以通过所述虚拟子GPU的设备名称识别所述虚拟子GPU。作为示例，若真实GPU的设备名称是/dev/nvidia，创建的虚拟子GPU是/dev/fgpu_nv，则可以将虚拟子GPU的设备名称修改或设定为/dev/nvidiaX（X取自然数），以便所述容器可以通过所述虚拟子GPU的设备名称将所述虚拟子GPU 识别为真实的GPU。作为示例，在步骤420中，若所述操作***是Linux，则可以通过调用libfgpu-container库将所述虚拟子GPU挂载到所述容器。其中，fgpu-container-runtime-hook是我们开发的一个容器runtime，它对runc进行了二次修改(runc是一个根据OCI标准来创建和运行容器的轻量级工具)，对所有指定fgpu runtime的容器注入一个自定义的pre-start hook，使容器支持虚拟GPU操作。由此可以看出，图4示出的方法400可以实现将虚拟子GPU挂载到容器，使得容器的计算请求将被发送给虚拟子GPU而不是直接发送给真实GPU，为实现GPU资源的共享提供了基础。

图5图示了一种调度GPU资源共享的方法500的示意性流程图。所述调度GPU资源共享的方法例如可以在如图1所示的设备120上实施。如图5所示，所述方法500包括如下步骤。

在步骤510，确定当前节点的节点信息，所述节点信息指示当前节点的真实GPU的资源。作为示例，当前节点的真实GPU的资源包括当前节点的真实GPU的显存和算力，例如，当前节点有2个真实GPU，且每个真实GPU均有600MiB的显存，则当前节点的真实GPU的显存的量是1200MiB。

在一些实施例中，当前节点包括已创建的容器。在这种情况下，在确定当前节点的节点信息时，可以确定当前节点的真实GPU的资源的总量和已创建容器所占用的真实GPU的资源的量。作为示例，确定当前节点的真实GPU的资源中显存的总量为1000MiB，已创建容器所占用的真实GPU中的资源中显存的量为600MiB。

在步骤520，将当前节点的节点信息发送给调度器，所述调度器用于基于所述节点信息调度容器到当前节点上创建及运行。在一些实施例中，所述调度器可以是例如Kubernetes调度器、GPUAdmission调度器等。

在步骤530，接收调度器下发到当前节点的与创建容器相关的调度请求。在一些实施例中，调度器下发到当前节点的与创建容器相关的调度请求包括要创建的容器将占用的显存的量。

在步骤540，响应于待创建的容器请求GPU的资源，则使得前面所述的GPU资源共享方法（例如，方法200）被执行，以便使待创建的容器占用当前节点的真实GPU的资源的一部分。

在一些实施例中，当前节点的真实GPU的资源包括当前节点的真实GPU的显存。作为示例，若当前节点的真实GPU的显存为600MiB，则该信息将包含在当前节点的节点信息中。由于当前节点的真实GPU的资源包括当前节点的真实GPU的显存，使得当前面所述的GPU资源共享方法（例如，方法200）被执行时，待创建的容器将占用当前节点的真实GPU的显存的一部分。

通过本公开的实施例的调度GPU资源共享的方法，容易且高效率地实现了调度共享GPU资源中的显存的目的。

图6图示了根据本公开的一个实施例的GPU资源共享的方法的示例性的具体原理架构图。在图6所示的实施例中，GPU采用Nvidia系列，操作***选用Linux。

如图6所示，通过docker工具包及根据docker工具包开发的组件，实现了GPU资源共享。所述根据docker工具包开发的组件包括：在实现GPU资源共享的过程中，用于调用prestart hook的组件fgpu-container-runtime-hook和用于将fGPU挂载到容器上的组件libfgpu-container。fgpu-container-runtime-hook是发明人开发的一个容器runtime，它对runc进行了二次修改(runc是一个根据OCI标准来创建和运行容器的轻量级工具)，对所有指定fgpu runtime的容器注入一个自定义的pre-start hook，使容器支持虚拟GPU操作。libfgpu-container提供一个库和一个简单的CLI程序，使用这个库可以使fGPU使用 Linux容器。具体步骤如下，首先，调用容器镜像dockerd，随后经过docker-containerd+shim发出创建容器的请求。runc在接收到创建容器的请求后，在步骤601中调用fgpu-container-runtime-hook；然后，在步骤602中，fgpu-container-runtime-hook的prestart hook调用libfgpu-container。然后，在步骤603中，libfgpu-container请求fGPU内核模块（fGPU内核模块是运行于Linux操作***的内核态的内核模块）创建虚拟子GPU，并设置该虚拟子GPU的参数，比如显存大小，时间片个数等。此时，若设置的虚拟子GPU的参数超出真实GPU的未被占用的资源的量，则会被拒绝。然后，在步骤604中，libfgpu-container在Linux cgroup中添加该虚拟子GPU的设备为白名单。然后，在步骤605中，libfgpu-container将所述虚拟子GPU的设备名称设定为具有真实GPU的设备名称的形式，并将虚拟子GPU的设备作为真实GPU设备挂载到容器中，使得在所述容器被创建后所述虚拟子GPU利用所占用的真实GPU的部分资源处理所述容器的计算请求。最后，在步骤606中，runc完成创建该挂载虚拟子GPU的容器。所述挂载虚拟子GPU的容器可以按照设置占用真实GPU的资源，实现真实GPU资源的共享化。

图7图示了根据本公开的一个实施例的GPU资源共享的方法的运行于操作***的内核态的内核模块的示例性的具体原理框架图。在图7所示的实施例中，GPU采用Nvidia系列，操作***选用Linux，内核模块是fgpu内核模块。

如图7所示，fGPU内核模块对容器提供虚拟GPU设备（fGPU设备），即图中的/dev/fgpu_ctl和/dev/fgpu_nv，并通过procfs配置接口配置fGPU设备的参数。作为示例，此处并不限制fGPU设备的个数，fGPU设备的数量上限通常由fGPU内核模块限定。然后，fGPU设备会被改名为真实GPU的设备名称：/dev/nvidia_ctl和/dev/nvidia_nvX（X取决于由fGPU内核模块限定的fGPU设备的数量上限，例如当数量上限被限定为10，则X取0-9之间的自然数），使得用户态的容器可以将fGPU设备识别为真实GPU设备，并向其发送计算请求。fGPU设备占用的真实GPU的显存和算力的量，可以由fGPU内核模块基于fGPU设备的参数进行限制，实现控制虚拟子GPU占用真实GPU的一部分资源的量的目的，从而实现真实GPU资源的共享化。

在此实施例中，通过fGPU内核模块限制fGPU设备占用的真实GPU的显存的过程可以如图8示出的方法进行。图8图示了根据本公开的一个实施例的限制虚拟子GPU的显存的方法的示例性的具体原理架构图。如图8所示，当容器中的进程向挂载在该容器上的fGPU设备请求显存时，请求显存的申请将被发送到fGPU内核模块，fGPU内核模块在收到用户进程请求显存后，会判断是否超出当前真实GPU未被占用的显存（例如，已用显存加请求显存是否超出设置的容器的显存上限），若超出则拒绝该请求显存的申请，若未超出，则允许申请显存，并通过Nvidia驱动与真实GPU进行通信。

作为示例，图9图示了根据本公开的一个实施例的限制虚拟子GPU的显存的效果图。如图9所示，通过TENCENT_GPU_MEM_CONTAINER设置挂载在容器上的fGPU设备的可用显存的大小。此处设置fGPU设备的可用显存大小为10000000000个字节。设置完成后，显示fGPU设备实际占用真实GPU的显存的量是9536MiB，与所设置的fGPU设备的可用显存大小（10000000000个字节）一致。实验证明，通过本公开的实施例中的方法，可用有效实现对虚拟子GPU占用真实GPU的显存的量的限制。

在此实施例中，通过fGPU内核模块限制fGPU设备占用的真实GPU的算力的过程可以如图10示出的方法进行。图10图示了根据本公开的一个实施例的配置所述虚拟子GPU占用真实GPU的算力的具体原理架构图。如图10示出的方法，可以使用时间片的模式隔离算力资源，其中容器时间片的份数可用通过TENCENT_GPU_WEIGHT_CONTAINER设置。如图10中所示，容器A占用的时间片设置为2，容器B和C的时间片设置为1。当容器A和C在运行CUDA进程而容器B没有运行CUDA进程时，仅容器A和C的时间片参与调度，容器B的时间片将会被跳过。此时，容器A与容器C占用真实GPU时间片的比例为2:1，此时它们占用的真实GPU的算力资源的比例也是2:1。之后，若容器B运行CUDA进程，则容器B的时间片也会参与调度。因此，限制挂载到容器上的虚拟子GPU占用真实GPU的时间片，可以有效限制各虚拟子GPU占用的真实GPU的算力，进而有效协调和满足各容器上的进程的计算需求。

图11图示了根据本公开的一个实施例的调度GPU资源共享的方法的示例性的具体原理架构图。如图11所示，在实施例中可以采用tkestack开源的GPU Admission作为调度器，其中GPU Admission是支持调度框架（Scheduler Framework）的Kubernetes调度器的GPU共享扩展调度器（scheduler extender）。

图11所示的调度GPU资源共享的方法中，Kubernetes（简称K8s）调度器通过GPU共享扩展调度器调度GPU共享仓库（GPU Share Registry）下的多个包含虚拟子GPU的节点（如图中的N1、N2、N3等），每个节点包含一个或多个真实GPU并可使用这些真实GPU的GPU资源。同时，每个节点中包含已创建的虚拟子GPU（如N1中的GPU 0、GPU 1等为已占用部分真实GPU的资源的虚拟子GPU）及这些虚拟子GPU挂载的Pod（在Kubernetes集群中，Pod是所有业务类型的基础，也是K8s管理的最小单位级，它是一个或多个容器的组合，在本实施例中每个Pod包含一个容器）。每个节点中的fGPU设备插件（fGPU-device-plugin）会向所在节点的Kubelet上报本节点的fGPU资源，例如本节点上所有GPU的显存的总量。Kubelet然后，节点的Kubelet会向API Server（API 服务器）上报节点信息，使得所有调度器都可以通过APIServer的查看（watch）接口 得知每个节点的节点信息，包括每个节点下fGPU的资源的量。其中，API Server提供了k8s各类资源对象（pod,RC,Service等）的增、删、改、查及watch等接口，是整个***的数据总线和数据中心。当用户向API Server下发创建Pod的请求（也即创建容器的请求）时，K8s调度器通过API Server的查看接口将得知有一个新的Pod创建请求，K8s调度器开始为这个Pod调度节点。K8s调度器会先检查Pod是否请求fGPU资源，若Pod请求fGPU资源，则将请求GPU共享扩展调度器来调度该Pod。GPU 共享扩展调度器在接收到调度任务后，会首先确定每个节点上的真实GPU的未被占用的资源的量，通过一系列调度算法，决定将所述新的Pod调度到某个节点的某个真实GPU上。当然，如果所有节点上的资源都不满足请求，将进入下个调度周期，一直到能够调度为止。当调度成功，GPU 共享扩展调度器会在Pod的Annotation（K8s中的注解，用于记录Docker镜像信息等）中增加一个条目，用于描述将这个Pod绑定在节点的哪个GPU上。然后，GPU共享扩展调度器会将调度结果返回给K8s调度器，K8s调度器将所述调度结果上报给API Server。当Kubelet通过watch APIServer发现有Pod调度到本节点上来时，Kubelet将开始创建Pod。若Kubelet发现该Pod请求了fGPU资源，则会发请求到fGPU-device-plugin。fGPU-device-plugin收到请求后将检查Pod的Annotation，从而确定这个Pod的容器需要绑定在哪个GPU上。fGPU-device-plugin还将根据Pod的Annotation和Pod的请求资源的量，设置容器的环境变量。然后，Kubelet会开始创建挂载有fGPU设备的容器，创建挂载有fGPU设备的容器的流程可以采用如图6所示的实施例的方法。

对于集群管理者来说，可以设置节点的算力模式，例如设置为公平（fair）/效率（best-effort）模式。当节点被设置为公平模式时，时间片设置得较长，使得容器的计算性能更稳定，不会受其他容器计算任务的影响。此时占有两个时间片的容器，同等条件下性能将是1个时间片容器的两倍。独占真实GPU资源时公平模式与效率模式的性能区别较小。但共享真实GPU资源时，公平模式性能较效率模式差。当节点被设置为效率模式时，时间片设置得较短，共享真实GPU资源时其性能较公平模式更高，将会接近于在裸机（即将真实的GPU挂载到容器）上的性能。但在效率模式下，容器任务的性能会受到占用同一真实GPU的资源的其他容器的计算任务的影响。

为了验证本公开所示出的GPU资源共享方法的效率，我们进行了一系列实验。实验用的GPU均使用NVIDIA Tesla V100，进程均使用tensorflow-benchmarks。在实验中，我们将选择不同的数据集和模型，调节批量大小（batch_size）和XLA（Accelerated LinearAlgebra，即加速线性代数），以实现综合评价本公开的技术效果的目的。实验程序如下：python3 ./scripts/tf_cnn_benchmarks/tf_cnn_benchmarks.py --data_name=A --model=B --num_batches=x --batch_size=y --display_every=z –xla。

图12图示了根据本公开的一个实施例的GPU资源共享方法中GPU资源利用率的实验效果图。如图12所示，在节点处于效率模式下时，单独任务独占真实GPU资源对真实GPU资源的利用率仅40%左右，而此时两个任务共享真实GPU资源，则利用率升为80%左右，这表明使用本公开的GPU资源共享方法后，GPU资源的利用率基本变为了之前的两倍。

为了进一步验证本公开所示出的方法的有益效果，我们采用了一些业内知名开发组开发的典型GPU资源共享方案作为对照组，这些典型GPU资源共享方案包括cGPU/vGPUsoft/vGPU hard/vCUDA soft。为了测试本公开所提出的方法对于不同任务的有效性，我们分别对大任务和小任务进行了实验。大任务指独占时对GPU资源的利用率均90%的任务，小任务指独占时对GPU资源的利用率小于50%的任务。

图13A和图13B分别示出了本公开的一个实施例的技术方案与对照组在大任务独占GPU资源和大任务共享GPU资源时的性能对比图。图中，bs代表批量大小（batch_size，用于表征每一批次数据的量的大小），xla代表加速线性代数（XLA，Accelerated LinearAlgebra，用于加速神经网络模型的训练）。从图13A和图13B可以看出，当运行大任务时，无论是大任务独占GPU资源时和大任务共享GPU资源时，本公开所提出的GPU资源共享方法（fGPU）均明显优于对照组，甚至已经接近了裸机的运行效率。

图14图示了本公开的一个实施例的技术方案与对照组在小任务独占GPU资源和共享GPU资源时的性能对比图。我们选择tensorflow-benchmarks的resnet20模型、cifar10数据集，通过调整batch size和xla，进行了多组试验。从图14中可以看出，当运行小任务时，无论是小任务独占GPU资源时和小任务共享GPU资源时，本公开所提出的GPU资源共享方法（fGPU）已经接近了裸机的运行效率，明显优于对照组。

图15图示了根据本公开的一个实施例的一种GPU资源共享的装置1500的示例性结构框图。如图15所示，所述GPU资源共享的装置1500包括接收模块1510、创建模块1520、适配模块1530和挂载模块1540。

所述接收模块1510，其被配置成接收创建容器的请求。

所述创建模块1520，其被配置成调用运行于操作***的内核态的内核模块创建虚拟子GPU，使得所述虚拟子GPU占用真实GPU的部分资源。

所述适配模块1530，其被配置成将虚拟子GPU适配到所述操作***，使得虚拟子GPU对于所述容器可用。

所述挂载模块1540，其被配置成将所述虚拟子GPU挂载到所述容器，使得在所述容器被创建后所述虚拟子GPU利用所占用的真实GPU的部分资源处理所述容器的计算请求。

图16图示了根据本公开的一个实施例的一种调度GPU资源共享的装置1600的示例性结构框图。如图16所示，所述调度GPU资源共享的装置1600包括信息确定模块1610、信息发送模块1620、调度请求模块1630和调度模块1640。

所述信息确定模块1610，其被配置成确定当前节点的节点信息，所述节点信息指示当前节点的真实GPU的资源。

所述信息发送模块1620，其配置成将当前节点的节点信息发送给调度器，所述调度器用于基于所述节点信息调度容器到当前节点上创建及运行。

所述调度请求模块1630，其配置成接收调度器下发到当前节点的与创建容器相关的调度请求。

所述调度模块1640，其被配置成响应于待创建的容器请求GPU的资源，则使得如图2所示的GPU资源共享方法200被执行，以便使待创建的容器占用当前节点的真实GPU的资源的一部分。

图17图示了示例***1700，其包括代表可以实现本文描述的各种技术的一个或多个***和/或设备的示例计算设备1710。计算设备1710可以是例如服务提供商的服务器、与服务器相关联的设备、片上***、和/或任何其它合适的计算设备或计算***。上面参照图15描述的GPU资源共享的装置1500和参照图16描述的调度GPU资源共享的装置1600均可以采取计算设备1710的形式。替换地，GPU资源共享的装置1500可以以应用1716的形式被实现为计算机程序。

如图示的示例计算设备1710包括彼此通信耦合的处理***1711、一个或多个计算机可读介质1712以及一个或多个I/O接口1713。尽管未示出，但是计算设备1710还可以包括***总线或其他数据和命令传送***，其将各种组件彼此耦合。***总线可以包括不同总线结构的任何一个或组合，所述总线结构诸如存储器总线或存储器控制器、***总线、通用串行总线、和/或利用各种总线架构中的任何一种的处理器或局部总线。还构思了各种其他示例，诸如控制和数据线。

处理***1711代表使用硬件执行一个或多个操作的功能。因此，处理***1711被图示为包括可被配置为处理器、功能块等的硬件元件1714。这可以包括在硬件中实现为专用集成电路或使用一个或多个半导体形成的其它逻辑器件。硬件元件1714不受其形成的材料或其中采用的处理机构的限制。例如，处理器可以由（多个）半导体和/或晶体管（例如，电子集成电路（IC））组成。在这样的上下文中，处理器可执行指令可以是电子可执行指令。

计算机可读介质1712被图示为包括存储器/存储装置1715。存储器/存储装置1715表示与一个或多个计算机可读介质相关联的存储器/存储容量。存储器/存储装置1715可以包括易失性介质（诸如随机存取存储器（RAM））和/或非易失性介质（诸如只读存储器（ROM）、闪存、光盘、磁盘等）。存储器/存储装置1715可以包括固定介质（例如，RAM、ROM、固定硬盘驱动器等）以及可移动介质（例如，闪存、可移动硬盘驱动器、光盘等）。计算机可读介质1712可以以下面进一步描述的各种其他方式进行配置。

一个或多个I/O接口1713代表允许用户使用各种输入设备向计算设备1710输入命令和信息并且可选地还允许使用各种输出设备将信息呈现给用户和/或其他组件或设备的功能。输入设备的示例包括键盘、光标控制设备（例如，鼠标）、麦克风（例如，用于语音输入）、扫描仪、触摸功能（例如，被配置为检测物理触摸的容性或其他传感器）、相机（例如，可以采用可见或不可见的波长（诸如红外频率）将不涉及触摸的运动检测为手势）等等。输出设备的示例包括显示设备（例如，监视器或投影仪）、扬声器、打印机、网卡、触觉响应设备等。因此，计算设备1710可以以下面进一步描述的各种方式进行配置以支持用户交互。

计算设备1710还包括应用1716。应用1716可以例如是GPU资源共享的装置1500或调度GPU资源共享的装置1600的软件实例，并且与计算设备1710中的其他元件相组合地实现本文描述的技术。

本文可以在软件硬件元件或程序模块的一般上下文中描述各种技术。一般地，这些模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、元素、组件、数据结构等。本文所使用的术语“模块”，“功能”和“组件”一般表示软件、固件、硬件或其组合。本文描述的技术的特征是与平台无关的，意味着这些技术可以在具有各种处理器的各种计算平台上实现。

所描述的模块和技术的实现可以存储在某种形式的计算机可读介质上或者跨某种形式的计算机可读介质传输。计算机可读介质可以包括可由计算设备1710访问的各种介质。作为示例而非限制，计算机可读介质可以包括“计算机可读存储介质”和“计算机可读信号介质”。

与单纯的信号传输、载波或信号本身相反，“计算机可读存储介质”是指能够持久存储信息的介质和/或设备，和/或有形的存储装置。因此，计算机可读存储介质是指非信号承载介质。计算机可读存储介质包括诸如易失性和非易失性、可移动和不可移动介质和/或以适用于存储信息（诸如计算机可读指令、数据结构、程序模块、逻辑元件/电路或其他数据）的方法或技术实现的存储设备之类的硬件。计算机可读存储介质的示例可以包括但不限于RAM、ROM、EEPROM、闪存或其它存储器技术、CD-ROM、数字通用盘（DVD）或其他光学存储装置、硬盘、盒式磁带、磁带，磁盘存储装置或其他磁存储设备，或其他存储设备、有形介质或适于存储期望信息并可以由计算机访问的制品。

“计算机可读信号介质”是指被配置为诸如经由网络将指令发送到计算设备1710的硬件的信号承载介质。信号介质典型地可以将计算机可读指令、数据结构、程序模块或其他数据体现在诸如载波、数据信号或其它传输机制的调制数据信号中。信号介质还包括任何信息传递介质。术语“调制数据信号”是指这样的信号，该信号的特征中的一个或多个被设置或改变，从而将信息编码到该信号中。作为示例而非限制，通信介质包括诸如有线网络或直接连线的有线介质以及诸如声、RF、红外和其它无线介质的无线介质。

如前所述，硬件元件1714和计算机可读介质1712代表以硬件形式实现的指令、模块、可编程器件逻辑和/或固定器件逻辑，其在一些实施例中可以用于实现本文描述的技术的至少一些方面。硬件元件可以包括集成电路或片上***、专用集成电路（ASIC）、现场可编程门阵列（FPGA）、复杂可编程逻辑器件（CPLD）以及硅中的其它实现或其他硬件设备的组件。在这种上下文中，硬件元件可以作为执行由硬件元件所体现的指令、模块和/或逻辑所定义的程序任务的处理设备，以及用于存储用于执行的指令的硬件设备，例如，先前描述的计算机可读存储介质。

前述的组合也可以用于实现本文所述的各种技术和模块。因此，可以将软件、硬件或程序模块和其它程序模块实现为在某种形式的计算机可读存储介质上和/或由一个或多个硬件元件1714体现的一个或多个指令和/或逻辑。计算设备1710可以被配置为实现与软件和/或硬件模块相对应的特定指令和/或功能。因此，例如通过使用处理***的计算机可读存储介质和/或硬件元件1714，可以至少部分地以硬件来实现将模块实现为可由计算设备1710作为软件执行的模块。指令和/或功能可以由一个或多个制品（例如，一个或多个计算设备1710和/或处理***1711）可执行/可操作以实现本文所述的技术、模块和示例。

在各种实施方式中，计算设备1710可以采用各种不同的配置。例如，计算设备1710可以被实现为包括个人计算机、台式计算机、多屏幕计算机、膝上型计算机、上网本等的计算机类设备。计算设备1710还可以被实现为包括诸如移动电话、便携式音乐播放器、便携式游戏设备、平板计算机、多屏幕计算机等移动设备的移动装置类设备。计算设备1710还可以实现为电视类设备，其包括具有或连接到休闲观看环境中的一般地较大屏幕的设备。这些设备包括电视、机顶盒、游戏机等。

本文描述的技术可以由计算设备1710的这些各种配置来支持，并且不限于本文所描述的技术的具体示例。功能还可以通过使用分布式***、诸如通过如下所述的平台1722而在“云”1720上全部或部分地实现。

云1720包括和/或代表用于资源1724的平台1722。平台1722抽象云1720的硬件（例如，服务器）和软件资源的底层功能。资源1724可以包括在远离计算设备1710的服务器上执行计算机处理时可以使用的应用和/或数据。资源1724还可以包括通过因特网和/或通过诸如蜂窝或Wi-Fi网络的订户网络提供的服务。

平台1722可以抽象资源和功能以将计算设备1710与其他计算设备连接。平台1722还可以用于抽象资源的分级以提供遇到的对于经由平台1722实现的资源1724的需求的相应水平的分级。因此，在互连设备实施例中，本文描述的功能的实现可以分布在整个***1700内。例如，功能可以部分地在计算设备1710上以及通过抽象云1720的功能的平台1722来实现。

本申请提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算设备执行上述各种可选实现方式中提供的GPU资源共享方法。

应当理解，为清楚起见，参考不同的功能单元对本公开的实施例进行了描述。然而，将明显的是，在不偏离本公开的情况下，每个功能单元的功能性可以被实施在单个单元中、实施在多个单元中或作为其它功能单元的一部分被实施。例如，被说明成由单个单元执行的功能性可以由多个不同的单元来执行。因此，对特定功能单元的参考仅被视为对用于提供所描述的功能性的适当单元的参考，而不是表明严格的逻辑或物理结构或组织。因此，本公开可以被实施在单个单元中，或者可以在物理上和功能上被分布在不同的单元和电路之间。

将理解的是，尽管第一、第二、第三等术语在本文中可以用来描述各种设备、元件、部件或部分，但是这些设备、元件、部件或部分不应当由这些术语限制。这些术语仅用来将一个设备、元件、部件或部分与另一个设备、元件、部件或部分相区分。

尽管已经结合一些实施例描述了本公开，但是其不旨在被限于在本文中所阐述的特定形式。相反，本公开的范围仅由所附权利要求来限制。附加地，尽管单独的特征可以被包括在不同的权利要求中，但是这些可以可能地被有利地组合，并且包括在不同权利要求中不暗示特征的组合不是可行的和/或有利的。特征在权利要求中的次序不暗示特征必须以其工作的任何特定次序。此外，在权利要求中，词“包括”不排除其它元件，并且术语“一”或“一个”不排除多个。权利要求中的附图标记仅作为明确的例子被提供，不应该被解释为以任何方式限制权利要求的范围。

Claims (14)

1.一种GPU资源共享的方法，包括：

接收创建容器的请求；

调用运行于操作***的内核态的内核模块创建虚拟子GPU，使得所述虚拟子GPU占用真实GPU的部分资源；

将虚拟子GPU适配到所述操作***，使得虚拟子GPU对于所述容器可用；

将所述虚拟子GPU挂载到所述容器，使得在所述容器被创建后所述虚拟子GPU利用所占用的真实GPU的部分资源处理所述容器的计算请求。

2.根据权利要求1所述的方法，其中调用运行于操作***的内核态的内核模块创建虚拟子GPU，使得所述虚拟子GPU占用真实GPU的部分资源包括：

响应于待创建的容器请求GPU资源，调用运行于操作***的内核态的内核模块创建虚拟子GPU，使得所述虚拟子GPU占用真实GPU的部分资源。

3.根据权利要求1或者2所述的方法，还包括：

接收资源参数，所述资源参数指示待创建的容器请求的真实GPU的部分资源的量，以及

其中，调用运行于操作***的内核态的内核模块创建虚拟子GPU，使得所述虚拟子GPU占用真实GPU的部分资源，包括：

调用运行于操作***的内核态的内核模块创建虚拟子GPU；

向所述内核模块发送资源参数，使得所述内核模块响应于确定所述请求的部分资源的量不超过真实GPU的未被占用的资源的量，基于所述资源参数配置所述虚拟子GPU占用真实GPU的所述部分资源的量。

4.根据权利要求1所述的方法，其中，将所述虚拟子GPU挂载到所述容器包括：

将所述虚拟子GPU的设备名称设定为具有真实GPU的设备名称的形式；

将所述虚拟子GPU挂载到所述容器，以便所述容器可以通过所述虚拟子GPU的设备名称识别所述虚拟子GPU。

5.根据权利要求3所述的方法，其中，所述资源参数包括待创建的容器请求的真实GPU的显存量，以及

其中，向所述内核模块发送资源参数，使得所述内核模块响应于确定所述请求的部分资源的量不超过真实GPU的未被占用的资源的量，基于所述资源参数配置所述虚拟子GPU占用真实GPU的所述部分资源的量，包括：

向所述内核模块发送资源参数，使得所述内核模块响应于确定所述请求的显存量不超过真实GPU的未被占用的显存的量，基于所述请求的显存量配置所述虚拟子GPU占用真实GPU的显存的量。

6.根据权利要求3所述的方法，其中，所述资源参数包括所述资源参数包括待创建的容器请求的真实GPU的算力，以及

其中，向所述内核模块发送资源参数，使得所述内核模块响应于确定所述请求的部分资源的量不超过真实GPU的未被占用的资源的量，基于所述资源参数配置所述虚拟子GPU占用真实GPU的所述部分资源的量，包括：

向所述内核模块发送资源参数，使得所述内核模块响应于确定所述请求的算力不超过真实GPU的未被占用的算力，基于所述请求的算力通过为所述虚拟子GPU分配的真实GPU的时间片的数量来配置所述虚拟子GPU占用真实GPU的算力。

7.根据权利要求1所述的方法，其中，将虚拟子GPU适配到所述操作***，使得虚拟子GPU对于所述容器可用，包括：

将虚拟子GPU添加到操作***的资源控制组中，使得虚拟子GPU对于所述容器可用，其中所述操作***的资源控制组用于限制、控制与分离进程占用的资源。

8.一种调度GPU资源共享的方法，包括：

确定当前节点的节点信息，所述节点信息指示当前节点的真实GPU的资源；

将当前节点的节点信息发送给调度器，所述调度器用于基于所述节点信息调度容器到当前节点上创建及运行；

接收调度器下发到当前节点的与创建容器相关的调度请求；

响应于待创建的容器请求GPU的资源，则使得根据权利要求1所述的GPU资源共享方法被执行，以便使待创建的容器占用当前节点的真实GPU的资源的一部分。

9.根据权利要求8所述的方法，其中当前节点包括已创建的容器，以及其中，确定当前节点的节点信息包括：

确定当前节点的真实GPU的资源的总量和已创建容器所占用的真实GPU的资源的量。

10.根据权利要求8所述的方法，其中，当前节点的真实GPU的资源包括当前节点的真实GPU的显存。

11.一种GPU资源共享的装置，包括：

接收模块，其被配置成接收创建容器的请求；

创建模块，其被配置成调用运行于操作***的内核态的内核模块创建虚拟子GPU，使得所述虚拟子GPU占用真实GPU的部分资源；

适配模块，其被配置成将虚拟子GPU适配到所述操作***，使得虚拟子GPU对于所述容器可用；

挂载模块，其被配置成将所述虚拟子GPU挂载到所述容器，使得在所述容器被创建后所述虚拟子GPU利用所占用的真实GPU的部分资源处理所述容器的计算请求。

12.一种调度GPU资源共享的装置，包括：

信息确定模块，其被配置成确定当前节点的节点信息，所述节点信息指示当前节点的真实GPU的资源；

信息发送模块，其配置成将当前节点的节点信息发送给调度器，所述调度器用于基于所述节点信息调度容器到当前节点上创建及运行；

调度请求模块，其配置成接收调度器下发到当前节点的与创建容器相关的调度请求；

调度模块，其被配置成响应于待创建的容器请求GPU的资源，则使得根据权利要求1所述的GPU资源共享方法被执行，以便使待创建的容器占用当前节点的真实GPU的资源的一部分。

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

存储器，其被配置成存储计算机可执行指令；

处理器，其被配置成当所述计算机可执行指令被处理器执行时执行如权利要求1-10中的任一项所述的方法。

14.一种计算机可读存储介质，其存储有计算机可执行指令，当所述计算机可执行指令被执行时，执行如权利要求1-10中的任一项所述的方法。

Images