基于GPU资源的数据处理方法、电子设备及系统
技术领域
本说明书实施例涉及计算机领域,尤其涉及一种基于GPU资源的数据处理方法、电子设备及系统。
背景技术
AI(Artificial Intelligence,人工智能)特别是DL(Deep Learning,深度学习)目前已经广泛用于支付(人脸)、定损(图片识别)、交互与客服(语音识别、文本内容抽取过滤)等多种场景,取得了显著效果。典型DL任务需要强大的算力支撑,因此当前绝大多数任务运行在GPU(Graphics Processing Unit,图形处理器)等加速设备之上,GPU是一种高性能计算加速设备,目前广泛用于AI、深度学习的训练和在线服务,物理GPU的硬件在GPU驱动程序的驱动下,实现AI任务的训练、在线服务等等。
但是,并非所有任务、在所有时刻都需要超强的算力支持,例如占用GPU资源长周期的开发-测试、在线推理、培训、演示以及一些最新涌现的轻量级模型(例如MobileNet,ShuffleNet)等无法(或不需要)全部的单卡算力。而典型的独占使用GPU导致无法充分利用资源。比如,基于容器环境下的GPU资源调度和管理,在对利用硬件GPU等加速设备的算力实现AI学习应用的过程中,为了实现对GPU资源的共享,就是把多个AI学习应用跑在同一个容器里面,在多个AI学习应用在同一容器里内实现共享GPU资源。但是,无法实现AI学习应用的隔离,不同AI学习应用之间存在资源抢占和互相干扰的现象。且无法调度计算任务到不同的节点上,因此,无法支持迁移,导致调度不灵活。比如,基于远程系统调用的方案:在动态运行时刻,截获GPU资源请求,然后转发到目标端来获取绑定的GPU资源,由于已经进行资源绑定,导致无法支持热迁移(即无法动态、及时的把应用进行同机不同物理GPU或不同机器的物理GPU之间的迁移),进而导致调度不灵活。
发明内容
本说明书实施例提供一种基于GPU资源的数据处理方法、电子设备及系统,实现GPU资源使用的高度灵活性和可迁移性,进而更灵活调度GPU资源。
第一方面,本说明书实施例提供一种基于GPU资源的数据处理方法,包括:获取物理GPU资源以及所述物理GPU资源的资源配置策略;根据所述资源配置策略和所述物理GPU资源,创建N个虚拟GPU资源,以及生成所述物理GPU资源和所述N个虚拟GPU资源之间的资源映射关系,N为正整数;根据所述资源映射关系,获得所述N个虚拟GPU资源中的目标虚拟GPU资源,并使用所述目标虚拟资源完成目标应用的计算任务,所述目标应用属于使用所述N个虚拟GPU资源的多个应用程序中的任意一个。
第二方面,本说明书实施例提供一种基于GPU资源的数据处理系统,包括:获取单元,用于获取物理GPU资源以及所述物理GPU资源的资源配置策略;资源创建单元,用于根据所述资源配置策略和所述物理GPU资源,创建N个虚拟GPU资源,以及生成所述物理GPU资源和所述N个虚拟GPU资源之间的资源映射关系,N为正整数;资源获得单元,用于根据所述资源映射关系,获得所述N个虚拟GPU资源中的目标虚拟GPU资源,并使用所述目标虚拟资源完成目标应用的计算任务,所述目标应用属于使用所述N个虚拟GPU资源的多个应用程序中的任意一个。
第三方面,本说明书实施例提供一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时实现上述第一方面中任一可能的实现方式的方法。
第四方面,本说明书实施例提供一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现上述第一方面中任一可能的实现方式的方法。
本说明书实施例提供的技术方案,至少具有如下技术效果或者优点:
本说明书实施例通过创建N个虚拟GPU资源,以及生成物理GPU资源和N个虚拟GPU资源之间的资源映射关系;从而多个需要使用GPU资源的应用中任意一个应用,就能够根据资源映射关系申请N个虚拟GPU资源中的目标虚拟GPU资源,并使用目标虚拟资源完成目标应用的计算任务。从而解耦了上层访问和底层实现,可以利用资源映射关系使得应用不用关心底层的具体物理实现,即使底层的物理GPU发生改变,而应用从上层所见的虚拟GPU资源可以始终保持不变,由此能够将GPU资源进行更好的抽象、封装和隔离管理,进而更好的实现了GPU资源虚拟化,有利于提高GPU资源使用的高度灵活性和可迁移性,从而实现对GPU资源的调度更灵活。
附图说明
图1为本说明书实施例中基于GPU资源的数据处理方法的流程图;
图2A、图2B为本说明书实施例中物理GPU资源与虚拟GPU资源之间的资源映射关系示意图;
图3为本说明书实施例中基于GPU资源的数据处理方法的系统架构图;
图4A为本说明书实施例中基于GPU资源的数据处理方法部署在裸机环境的示意图;
图4B为本说明书实施例中基于GPU资源的数据处理方法部署在容器中的示意图;
图4C为本说明书实施例中基于GPU资源的数据处理方法部署在虚拟机环境的示意图;
图5为本说明书实施例中基于GPU资源的数据处理方法应用于如图3所示的系统架构的流程图;
图6为本说明书实施例中基于GPU资源的数据处理装置的结构示意图;
图7为本说明实施例中电子设备的结构示意图。
具体实施方式
为使本说明书实施例的目的、技术方案和优点更加清楚,下面将结合本说明书实施例中的附图,对本说明书实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本说明书实施例一部分实施例,而不是全部的实施例。基于本说明书实施例中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本说明书实施例保护的范围。
本说明书实施例提供的基于GPU资源的数据处理方法,可以应用于如下场景:存在多个应用程序需要使用同一网络节点上的GPU资源完成各自的计算任务。在该网络节点上存在针对该物理GPU资源的资源策略,根据物理GPU资源以及针对物理GPU资源的资源策略创建出N个虚拟GPU资源,每个应用程序使用创建出的虚拟GPU资源中处理该应用程序的计算任务。
第一方面,本说明书实施例提供的基于GPU资源的数据处理方法,参考图1所示,对基于GPU资源的数据处理方法进行更详细的描述:
S201、获取物理GPU资源以及物理GPU资源的资源配置策略。
在本说明书实施例中的物理GPU资源通过如下方式获取:扫描本地GPU资源信息,根据本地物理GPU资源信息的扫描结果确定出物理GPU资源;初始化物理GPU资源的运行环境。
具体的,本说明书实施例中的物理GPU资源包括一个或者多个物理GPU设备的资源。每个物理GPU设备包括内核和硬件结构。
在本说明书实施例中,物理GPU设备可以是:nvidia企业级P100,V100,T4或消费型GTX 1080等中的一种。当然,物理GPU设备并不限于上述举例。具体的,物理GPU设备中包含:显存、计算队列、计算任务句柄等等资源。通过初始化物理GPU资源的运行环境,使得每个物理GPU设备能够运行并被使用。
在本说明书实施例中,资源配置策略具体可以是:根据每个物理GPU设备的第一环境变量或配置文件确定。基于此,步骤S301:获取每个物理GPU设备的第一环境变量和/或配置文件,从每个物理GPU设备的第一环境变量和/或配置文件中,获得物理GPU资源的资源配置策略。
更具体来讲,资源配置策略具体可以是:基于第一环境变量中资源配额信息(Resource Quota)或者配置文件中的资源配额信息(Resource Quota)确定。其中,资源配额信息对每个给定命名空间下的GPU资源需求量进行了限制。在本说明书实施中,基于资源配额信息限制非终止状态下的每个应用程序对GPU需求总量不能超过某个设定值。S202、根据资源配置策略和物理GPU资源,创建N个虚拟GPU资源,以及生成物理GPU资源和N个虚拟GPU资源之间的资源映射关系,N为正整数。
在本说明书实施中,根据资源配置策略和物理GPU资源,创建N个虚拟GPU资源,可以是动态创建目标应用所需的一个以上虚拟GPU资源,或者预先针对多个应用程序批量创建多个虚拟GPU资源。
具体来讲,无论是批量创建或者动态创建虚拟GPU资源,都可以通过如下步骤S2021~S2023创建出虚拟GPU资源:
步骤S2021、根据资源配置策略对物理GPU资源进行资源划分;
具体的,根据资源配置策略将物理GPU资源中每个物理GPU设备,按照1:M的使用比例进行划分为一个以上的虚拟GPU资源块,M为正整数。从而,能够将使物理GPU资源中每个物理GPU设备的资源被一个应用程序独占使用或者被多个应用程序共享使用。
需要说明的是,若物理GPU资源中包含多个物理GPU设备的资源,根据资源配置策略对物理GPU资源进行划分的结果,可能是:一些物理GPU设备的资源被独占使用,另一些物理GPU设备的资源被共享使用。也可以每个物理GPU设备的资源都被独占使用,或者每个物理GPU设备的资源都被多个应用程序共享使用。
步骤S2022、针对每个划分出的虚拟GPU资源块预分配物理GPU资源中预定量的GPU资源,得到所述N个虚拟GPU资源。
举例来讲,某个虚拟GPU资源块X是物理GPU4划分出的一个虚拟GPU资源块。例如,针对虚拟GPU资源块X预分配物理GPU4中预设量的GPU资源。预设量的GPU资源具体包括:根据资源配额信息所限定的物理GPU4中显存、计算队列(stream)、计算任务句柄(DNN,Blas等)、同步事件(event)等中的一种资源类型。需要说明的是,预定量的GPU资源可以少于或者等于资源配额信息所限定的设定值。
下面参考图2A和图2B,以物理GPU资源包括物理GPU0和物理GPU1这两个物理GPU设备的资源为例,对物理GPU资源进行划分出虚拟GPU资源块,并针对每个划分出的虚拟GPU资源块预分配预定量的GPU资源的过程进行举例说明:
其中,参考图2A所示:
根据资源配置策略中对于GPU0的配置策略,确定物理GPU0的资源被1:1使用,将物理GPU0划分出多个虚拟GPU资源块,对每个虚拟GPU资源块预分配GPU0中同类型的全部GPU资源,比如,一个虚拟GPU资源块预分配GPU0中全部的显存、另一个虚拟GPU资源块预分配GPU0中全部的计算队列。
其中,如图2B所示:
根据资源配置策略中对于GPU1的配置策略,确定GPU1的资源被1:2使用,将GPU1划分出两组虚拟GPU资源块X1、X2,一组虚拟GPU资源块中包括多个虚拟GPU资源块,一组虚拟GPU资源块X1中包括GPU1的一部分GPU资源,另一组虚拟GPU资源块X3中包括GPU1的剩余GPU资源。
步骤S2023、对N个虚拟GPU资源中每个虚拟GPU资源进行资源编号,以及将N个虚拟GPU资源中每个虚拟GPU资源绑定虚拟GPU设备(后续将虚拟设备简称为vDev),虚拟设备标识和资源编号用于唯一标识N个虚拟GPU资源中对应的虚拟GPU资源。同一vDev绑定一个以上的虚拟GPU资源。同一vDev所绑定的全部虚拟GPU资源提供给同一应用程序使用。
在本说明书实施例中,如果物理GPU设备被1:1使用,则该物理GPU设备的全部GPU资源所创建出的多个虚拟GPU资源绑定在同一个vDev上。举例来讲:物理GPU0的全部GPU资源有:16GB显存,8个vStream,32个vHandler,则创建出针对物理GPU0的3个虚拟GPU资源绑定在同一vDev上。如果同一物理GPU设备被共享使用,则将同一物理GPU设备的不同虚拟GPU资源,绑定在不同的vDev上。在具体实施过程中,每个vDev上绑定的每个虚拟GPU资源中记录有预先分配的GPU资源的起止范围。
在本说明书实施例中,将N个虚拟GPU资源的资源编号保存在数组里。所有虚拟GPU资源的资源编号可以保存在同一数组。
需要说明的是,vDev与应用程序一一对应,每个vDev上绑定一个以上的虚拟GPU资源。以3个应用程序为例,需要配置3个vDev(具体为:vDev1、vDev2、vDev3),vDev1、vDev2、vDev3绑定不同的虚拟GPU资源。需要说明的是,同一vDev上绑定的一个以上虚拟GPU资源来源于一个或者多个物理GPU设备中包含的资源。
在本说明书实施例中,记录有每个vDev设备信息,设备信息包括:虚拟GPU设备的编号(ID)、内存大小、core数目(即内核数)以及其他属性信息。虚拟设备标识可以是UUID(Universally Unique Identifier,全局标识符),通过全局标识符UUID唯一确定各个vDev。同时,每个vDev的设备信息中记录对应物理GPU设备所在的网络节点的节点ID,vDev的ID,以及所依赖的驱动程序的驱动版本等。
下面,以某一网络节点的物理GPU资源包括物理GPU0和物理GPU1这两个物理GPU设备的资源为例:假设一个虚拟GPU设备(vDev1)独占使用GPU0的GPU资源,则参考图2A和下表1所示,表1为虚拟GPU资源与物理GPU资源的映射示意表,体现了vDev以及vDev绑定不同类型虚拟GPU资源(vCtx、vDMem、vHMem、vStream、vHandler、vEvent)与物理GPU资源之间的映射说明。但是,虚拟GPU资源的类型并不限于表1所示。
表1虚拟GPU资源与物理GPU资源的映射示意表
如图2A所示,vDev1为一个虚拟GPU设备,对应一个物理GPU设备:GPU0。vCtx为vDev1绑定的动态运行环境,需要在运行vDev1前进行初始化动态运行环境vCtx。vDMem对应GPU0的设备内存。每段vDMem包含起始地址和长度。vHMem对应GPU0的主机内存。如图2A所示,vDev1绑定GPU0的显存,其中:vMem1、vMem2、vMem3对应为GPU0的显存。vStream对应GPU0的计算队列(比如vStream1、vStream2对应为GPU0的计算队列等等),多个计算队列并发执行。vHandler对应GPU0的计算任务句柄,具体的计算任务句柄包括多种,比如:vDNNHandler、vBlasHandler、vFFTHandler。
可预先批量创建计算任务句柄,并将预先批量创建的计算任务句柄关联vCtx和vStream。预先创建的计算任务句柄预先按范围授予给同一应用程序,避免临时动态创建计算任务句柄,进而避免了计算延迟。
假设两个虚拟GPU设备(vDev2和vDev3)共享使用物理GPU1的GPU资源,则参考图2B和下表1所示:
vDev3和vDev2共享同一动态运行环境vCtx,在运行vDev3和vDev2之前,初始化动态运行环境vCtx。vDev2、vDev3对应绑定GPU1中不同段的显存,比如,如图2B所示:vMem4、vMem5、vMem6对应为GPU1的三段显存。每段vMem包含起始地址和长度确定的起止范围。vDev2、vDev3分别绑定多个先进先出的计算队列(比如vDev2下的vStream3、vStream4对应GPU1的两个计算队列;vDev3下的vStream5、vStream6对应GPU1的另外两个计算队列),所有计算队列并发执行。vDev2、vDev3分别对应有多段主机内存(比如,vDev2下的vHMem4、vHMem5、vHMem6对应GPU1占用的三段主机内存)。vHandler对应GPU1的计算任务句柄,具体的,GPU1下的计算任务句柄包括多种,比如:vDNNHandler、vBlasHandler、vFFTHandler。可预先创建各种计算任务句柄,并将创建的各种计算任务句柄关联vDev1、vDev2和同一vCtx。将预先创建计算任务句柄预先按范围授予两个应用程序,避免临时动态创建计算任务句柄。
需要说明的是,按范围授予具体是:批量授予多个计算任务句柄且不重复。具体来讲,即:同一计算任务句柄不重复授予给不同的应用程序。比如,应用程序1授予预先创建的vHandler 0-7;应用程序2授予预先创建的计算任务句柄vHandler 8-15,而不会同时将计算任务句柄vHandler 0-18授予给应用程序1和程序2。
进一步的,经过上述步骤实现了对GPU资源的虚拟化抽象,进一步的,还对每个虚拟GPU资源进行封装,封装的目的在于提高接口抽象层次,解耦上层访问和底层的具体实现。经抽象和封装之后的每个虚拟GPU资源体现为一个不透明指针(即:opaque指针,实现为一个结构体,opaque指针关联并管理对应的物理GPU资源),换言之,应用程序所需的资源基本是不变的,但通过虚拟化层解析opaque指针所管理的虚拟GPU资源,可以访问到真实的物理GPU设备。
S203、根据资源映射关系,申请N个虚拟GPU资源中的目标虚拟GPU资源,并使用目标虚拟资源完成目标应用的计算任务,目标应用属于使用N个虚拟GPU资源的多个应用中的任意一个。
需要说明的是,使用目标虚拟GPU资源完成的计算任务,具体可以是:用于完成AI深度学习的训练场景或者在线服务的场景下的计算任务。目标虚拟GPU资源中包括一个以上类型的虚拟G资源。
在本说明书实施例中,对于显存而言,资源映射关系具体是一段显存的虚拟地址与物理地址之间的对应关系。例如,根据配置文件中的资源配额信息,将GPU的某段显存(起始地址和长度指定)分配给vDev1,并建立其该段显存的虚拟地址与该段显存的物理地址之间的映射关系,使得应用程序所见是该段显存的虚拟地址,该段显存的虚拟地址不会发生变化,能够对应用程序保持透明。而该段显存的物理地址可以根据实际情况动态变化,但是不会被应用程序所感知。比如,应用程序始终访问vDev1的显存,vDev1的显存来源的物理GPU设备可以从一个设备ID1更新为另一设备ID1’。并更新为设备ID1’上对应资源描述符,达到对上屏蔽底层状态变化的目标。
对于计算队列、计算任务句柄等等的资源映射关系,是虚拟资源编号与真实资源编号之间的映射关系,比如虚拟资源编号vStream=1,对应stream8-15中的第二个,即映射物理stream9。
S203中,包括如下步骤S2031~S2033:
步骤S2031、针对N个虚拟GPU资源导出GPU服务接口。
具体的,可通过IPC方式(比如,可以为UNIX socket、Pipe、shmem中的一种)或网络方式(比如,可以为TCP、Socket、RDMA中的一种)针对每个虚拟GPU设备导出GPU服务接口,以实现向每个应用程序导出GPU服务接口。导出的GPU服务接口中包含记录有虚拟GPU设备的虚拟设备标识的字段。具体的,可以通过预先约定共享内存位置(比如,约定好shmem位置/dev/shm/xgp-admin)或预先预定服务端口(比如:服务端口7788),来实现预先约定导出的GPU服务接口中的目标GPU服务接口。
需要说明的是,目标虚拟GPU资源所来源的物理GPU设备决定了目标应用预先约定的目标GPU服务接口。比如,同一物理GPU设备ID1包含创建出的虚拟GPU资源01、02。虚拟GPU资源01绑定vDev1,应用程序A使用vDev1的虚拟GPU资源,虚拟GPU资源02绑定vDev2,应用程序B使用vDev2的虚拟GPU资源,向目标应用A、B导出的GPU服务接口相同,即都是物理GPU设备ID1的API接口。
在本说明书实施例中,GPU服务接口为目标虚拟GPU资源来源的物理GPU设备原始配置的API接口,本说明书实施例并不需要对API接口进行更改,能够通过调用现有接口获得虚拟、封装后的虚拟GPU资源。
步骤S2032、根据资源映射关系,以及导出的GPU服务接口中,目标应用预先约定的目标GPU服务接口,申请N个虚拟GPU资源中的目标虚拟GPU资源。
具体来讲,步骤S2032具体包括:发现目标虚拟GPU资源的过程,以及在发现目标虚拟GPU资源之后,申请使用目标虚拟GPU资源的过程。
具体来讲,发现目标虚拟GPU资源的过程,包括如下细化步骤A~B:
步骤A:基于目标GPU服务接口,获得目标应用上报的资源标识信息,资源标识信息包括目标虚拟GPU资源的资源编号和/或目标虚拟GPU资源所绑定的虚拟GPU设备的虚拟设备标识。虚拟设备标识具体可以为vDev编号或者vDev的UUID。
上述步骤A具体包括如下步骤A1~A3:
步骤A1:查询目标应用预先约定的目标GPU服务接口,目标GPU服务接口是为目标虚拟GPU资源对应的物理GPU配置的原始访问接口。举例来讲,GPU1所配置的原始访问接口是API接口“0078”,目标应用对应的vDev绑定的目标虚拟GPU资源属于GPU1,通过查询确定向目标应用导出的GPU服务接口是GPU1的API接口“0078”。
具体来讲,可以通过如下具体实现方式查询到目标GPU服务接口:
基于目标应用发起的GPU接口访问申请启动目标对象;向启动后的目标对象传入目标环境变量,目标环境变量包含用于访问目标虚拟GPU资源的信息;调用目标对象,解析出目标环境变量对应的GPU服务接口,作为目标GPU服务接口。其中,目标环境变量包含该目标应用对应虚拟GPU设备的虚拟设备标识(即:UUID或者vDev编号),根据UUID或者vDev编号确定目标GPU设备。举例来讲,对于K8S环境下,目标对象可以是目标应用上的pod(pod是一个容器或者一组容器)。由Pod解析目标环境变量,以解析出目标GPU服务接口。建立有虚拟GPU设备的设备标识与GPU服务接口之间的映射关系。根据虚拟GPU设备的设备标识与GPU服务接口之间的映射关系,查询目标环境变量对应的预GPU服务接口,即得到预先约定的目标GPU服务接口。
需要说明的是,本说明书实施例中所指的K8S(kubernetes,简称K8s,是用8代替8个字符“ubernete”而成的缩写。是一个开源的,用于管理云平台中多个主机上的容器化应用,Kubernetes的目标是让部署容器化的应用简单并且高效。K8S环境下,集群调度的最小单元就是一个pod,一个pod可以是一个容器或者一组容器,例如运行一个应用程序,其中使用了nginx,使用mysql了,还使用了jetty,那么可以将这三个使用在同一个pod中,对这三个提供统一的调配能力,一个pod只能运行在一个主机上,而一个主机上可以有多个pod。Pod是一个可以被创建、销毁、调度、管理的最小的部署单元。
具体来讲,GPU接口访问申请包含目标虚拟GPU资源对应的物理GPU所在节点的节点标识,根据接口访问申请启动目标对象,具体是:启动GPU接口访问申请中节点标识所指示的网络节点上的目标对象。
步骤A2:向目标GPU服务接口发起链接。在具体实施过程中,通过链接约定好的共享内存位置(attach shemem)或者向指定的服务端口,以向目标GPU服务接口发起链接。
步骤A3:基于与目标GPU服务接口之间的链接,获得目标应用上报的资源标识信息。
每个应用程序各自执行上述步骤A1~A3,能够从创建好的N个虚拟GPU资源中,发现预先授权给该应用程序使用的目标虚拟GPU资源。
在目标应用发现目标虚拟GPU资源之后,若是目标需要使用目标虚拟GPU资源,则通过如下步骤申请并使用目标虚拟GPU资源:
具体的,预先加载目标应用的静态数据库文件(即:lib文件)或者目标应用位于优先加载位置。具体的,对目标应用的静态数据库文件(lib文件,打包得到的docker image文件)进行优先加载处理,可以是:预先加载lib文件或者将lib文件设置在优先加载位置,比如,通过LD_PRELOAD预先加载lib文件。通过LD_LIBRARY_PATH设置在优先加载位置。
通过上述对GPU运行环境和资源进行封装、抽象,目标是解耦底层实现,使用应用模型层访问时GPU资源时不用关心底层实现和变化,始终可以访问到真实的物理GPU资源。
并且,还可以还可管理物理GPU资源的动态变更(这些动态变更包括内存换入、换出;或GPU应用的跨卡热迁移等),进而实现调度时动态迁移。
步骤B、根据资源标识信息查询资源映射关系,确定预先为目标应用分配的虚拟GPU资源,将预先为目标应用分配的虚拟GPU资源作为目标虚拟GPU资源。
具体的,可以是动态申请或者批量申请N个虚拟GPU资源中供目标应用使用的目标虚拟GPU资源。
就动态申请的方式而言,在目标应用当前需要处理计算任务中的当前子计算任务时,动态申请目标虚拟GPU资源中用于完成当前子计算任务的虚拟GPU资源。
下面,以显存、计算队列、同步事件为例,对动态申请虚拟GPU资源的实现过程进行详细说明:
由于大多数的虚拟GPU资源(例如vStream,vEvent等)可以作为一个opaque指针,直接返回给对目标应用,其中,opaque指针包含了所管理的设备信息,而设备信息又记录了物理GPU设备的设备ID、驱动版本等。
在本实施方式下,在目标应用当前需要处理计算任务中的当前子计算任务时,目标应用发起本次资源申请,则根据本次资源申请的资源申请信息动态创建本次资源申请所需的虚拟GPU资源。
动态申请的目标虚拟GPU资源具体是:根据单次资源使用量,向申请显存、计算队列、同步事件等GPU资源中的一种或者多种类型。
通过本实施方式实现每个应用程序在需要完成某个计算任务时,才由该应用程序申请用于该应用程序完成该计算任务所需的虚拟GPU资源,更加灵活。
为了减少交互,避免在动态运行时申请虚拟GPU资源,则可以采用实施方式二:批量申请目标虚拟GPU资源,批量申请的目标虚拟资源用于目标应用在不同时间点完成计算任务中的多个子计算任务。
在具体实施过程中,可以是在目标应用启动时,一次性批量申请目标虚拟GPU资源。对批量申请的目标虚拟GPU资源进行缓存。在目标应用需要完成子计算任务进行时,从缓存中获取目标虚拟GPU资源中一定量虚拟GPU资源,用以完成该子计算任务。通过批量申请虚拟GPU资源,不必每次需要使用GPU资源时才进行申请,例如:批量申请的目标虚拟GPU资源包含最多25%显存(即使目标应用当前未必实际需要这么多),16个队列(vStream)、32个事件(vEvent)等,这样大幅减少交互,继而减少了延迟,提高了计算性能。
在申请目标虚拟GPU资源之后,在开始计算任务时,目标应用调用目标GPU服务接口上报所对应的虚拟GPU设备的vDev编号和目标虚拟GPU资源的资源编号,而不需上报完整的资源描述或句柄,则在资源映射关系中查询上报的资源编号、vDev编号,确定出与该目标虚拟GPU资源所映射的物理GPU资源,这样减少IPC、网络的传输开销。
举例来讲,预先为每个vDev预分配资源,并记录每个vDev分配的资源的起止范围,应用程序所见是每个vDev分配的资源。
同一网络节点上有两个物理GPU设备:物理GPU0和物理GPU1,物理GPU0的资源被2个虚拟GPU设备使用:vDev0,vDev1,在虚拟的vDev1上创建2个stream:stream0、stream1。stream8-15预先授予目标应用,若根据资源映射关系确定要使用预先授予给该目标应用的stream8-15中的哪个,则目标应用只需上报vDev=1,vStream=1。根据上报的vDev=1,vStream=1查询资源映射关系,即vDev=1属于物理GPU0,vStream=1属于预分授予给目标应用的stream8-15中的第二个,即物理stream9。
进一步的技术方案中,在目标应用启动时,获取目标虚拟GPU资源的设备信息并缓存。由于,设备信息往往是只读的,可以获取一次并缓存本地,之后查询时可以通过getDevUUID/getDevProperities在直接本地查询,无需交互。
为了适应物理GPU资源的变化,还包括:检测物理GPU资源是否发生变化;若物理GPU资源发生变化,则动态更新资源映射关系。实时或者按照预设检测周期,检测物理GPU资源是否发生变化,从而实现了真实的物理GPU资源变化与重映射:当底层物理资源发生变化时,会更新资源映射关系来动态适配底层资源变化,通过维护动态的资源映射关系,能够对上(应用程序)保持接口一致,对下(物理层)则屏蔽物理硬件和驱动的实现差异,以到达GPU资源的动态平衡。
具体的,物理GPU资源发生的变化包括热迁移、驱动变更中的一种或者多种变化。通过更新资源映射关系实现了动态适配底层的物理GPU资源的变化。
具体的,本说明书实施例中基于GPU资源的数据处理方法可以应用在如图3所示的系统架构中。但是,本说明书实施例的第一方面所述的基于GPU资源的数据处理方法并不仅仅应用于如图3所示的系统架构。参考图3所示,对该系统架构进行详细说明:
在系统后台长时间运行的资源服务模块20,资源管理模块20。在本说明书实施例中,资源管理模块20上部署有一个服务实例,该服务实例可封装运行在docker容器里。资源管理模块20通过运行该服务实例,实现对每个物理GPU设备40的管理。
资源管理模块20获取本地的物理GPU资源,以及针对该物理GPU资源的资源配置策略;根据资源配置策略和物理GPU资源创建N个虚拟GPU资源;根据资源配置策略,生成物理GPU资源和N个虚拟GPU资源之间的资源映射关系。获取的物理GPU资源来源于物理GPU设备40包含的资源。
多个应用程序30,每个应用程序30根据资源影射关系,申请并使用N个虚拟GPU资源中相应的虚拟GPU资源,来完成该应用程序30上的计算任务。
在本说明书实施例中,可以是资源管理模块20对应多个应用程序30,或者在同一个物理GPU对应多个应用程序30。
具体的,每个应用程序30包括:资源申请模块31、模型应用层32以及AI框架层33。例如:AI框架层33可以是:TensorFlow,PyTorch,Caffe2等框架,所有已知的AI框架层33都支持在GPU下运行。
资源申请模块31与需要使用虚拟GPU资源的模型应用层32一一对应。资源申请模块31向对应的应用模型层32导出用于访问虚拟GPU资源的GPU服务接口。具体的,该GPU服务接口是API(Application Programming Interface,应用程序编程接口)接口,资源申请模块31向对应应用模型层32导出的API接口需要使用的虚拟GPU资源所在的物理GPU的原始API接口保持一致,使得每个模型应用层32能够基于导出的GPU服务接口,使用虚拟GPU资源。
每个资源申请模块31通过IPC(Inter-Process Communication,进程间通信)或者网络方式与资源管理模块20通信。每个资源申请模块31与资源管理模块20均保存并维护有相同的资源映射关系。每个资源申请模块31根据资源映射关系,向资源管理模块20申请N个虚拟GPU资源中的目标虚拟GPU资源,每个模型应用层32基于对应的AI框架层33,以及对应资源申请模块31申请到的目标虚拟GPU资源,完成需要该模型应用层32完成的计算任务。
应用模型层32的用户模型可以为如下任何一种,但是不限于以下举例:
CNN(Convolutional Neural Networks,卷积神经网络)、RNN(Recurrent NeuralNetwork,循环神经网络)、LSTM(Longshort term memory,长短期记忆网络)、GAN(Generative Adversarial Networks,生成式对抗网络)等模型,资源申请模块31向资源管理模块20申请目标虚拟GPU资源,进行用户模型的训练或者基于用户模型的在线服务。
具体的,该系统架构可以部署在裸机环境、容器环境或者VM虚拟机环境下。部署方式可以参考图4A~图4C所示。
如果该系统架构部署在裸机环境中,如图4A所示,资源管理模块20和每个应用程序30都运行在主操作系统(host OS)上(例如,都运行在linux上),资源管理模块20通过GPU驱动接管所有对物理GPU设备(如图4A所示的物理GPU0、物理GPU1)40的访问。其中,若资源申请模块31与资源管理模块20在同一物理机器,则可以采用IPC方式(例如UNIX socket,管道或者共享内存等)通信;若资源申请模块31与资源管理模块20不在同一物理机,则采用TCP(Transmission Control Protocol,传输控制协议)通信协议、IP通信协议、或者RDMA(Remote Direct Memory Access,直接内存访问)通信协议等通信。
如果该系统架构部署在容器环境中,如图4B所示,资源管理模块20以容器化方式运行并接管物理GPU 40(如图4B所示的GPU0、GPU1),导出虚拟GPU资源。资源申请模块31与资源管理模块20运行在同一物理机上,资源申请模块20链接资源管理模块20,资源申请模块31与资源管理模块20之间的通信可以采用IPC(Inter-Process Communication,进程间通信),例如UNIX socket,Pipe或者shmem或者网络方式。
如果该系统架构部署在虚拟机环境中。如图4C所示,物理GPU资源给特定的物理机,然后在虚拟机管理系统(VM guest OS)里启动资源管理模块20或资源申请模块31,从而等同于裸机环境。
经上所述,该系统架构可同时支持部署在裸机、容器和虚拟机,因此,部署非常灵活,可以实现在裸机环境、容器化环境或者虚拟机环境下实现基于GPU资源的数据处理。
该系统架构还包括集群调度器50,集群调度器50通过网络方式或者IPC方式与资源申请模块31通信。集群调度器50负责集群范围内的物理GPU资源的调度。资源管理模块20向集群调度器50上报物理GPU资源、针对物理GPU资源创建的N个虚拟GPU资源、以及物理GPU资源与N个虚拟GPU资源之间的资源映射关系。例如:可以通过设备插件“nvidia deviceplugin”进行物理GPU资源、N个虚拟GPU资源、以及资源映射关系的上报。使得集群调度器50根据资源映射关系调度集群范围内的N个虚拟GPU资源的分配。每个应用程序30通过集群调度器50发现并申请使用N个虚拟GPU资源中相应虚拟GPU资源。
具体的,集群调度器50可以但不限于K8S(Kubernetes)调度器(kube-scheduler)或者Kubemaker调度器。
下面,参考图5所示,对基于上述系统架构实现第一方面所述的基于GPU资源的数据处理方法的过程进行详细描述:
步骤S501、资源管理模块获取物理GPU资源以及物理GPU资源的资源配置策略。
在本说明书实施例中,资源管理模块获取的物理GPU资源包括设备信息、运行环境、计算任务管理、内存、计算任务句柄(例如卷积操作、矩阵操作、FFT以及推理任务等)和相应的异步事件等等中的一种或者多种。
在具体实施过程中,资源管理模块启动,并在资源管理模块启动时扫描资源管理模块所在网络节点本地的GPU资源信息,根据物理GPU资源信息的扫描结果获取物理GPU资源。具体来讲,物理GPU资源信息包括:物理GPU的数量、每个物理GPU的型号、每个物理GPU的属性信息。在具体实施时,物理GPU资源可以是资源管理模块所在节点本地的一个或者多个物理GPU所包含的资源。
在本说明书实施例中,获取的资源配置策略来源于每个物理GPU的第一环境变量或配置文件。基于此,步骤S301:获取资源管理模块20所在本地的所有物理GPU的第一环境变量和/或配置文件,根据所有物理GPU的第一环境变量和/或配置文件,确定针对物理GPU资源的资源配置策略。
步骤S502、资源管理模块根据资源配置策略和物理GPU资源创建N个虚拟GPU资源。
步骤S503:资源管理模块根据资源配置策略,生成物理GPU资源和N个虚拟GPU资源之间的资源映射关系。在一可选的实施方式下,在资源管理模块和每个资源申请模块保存并维护相同的资源映射关系。资源申请模块查询资源映射关系无需与资源管理模块交互,减少了网络传输开销。
具体的,在资源管理模块的保存位置是在资源管理模块的内存或持久化的磁盘上,在每个资源申请模块上的保存位置是在该资源申请模块的内存或持久化的磁盘上。
在本说明书实施例中,资源申请模块上保存的资源映射关系可以是资源管理模块向每个资源申请模块传递,使得在每个资源申请模块与资源管理模块上保存并维护有相同的资源映射关系。或者是由资源管理模块将生成的资源映射关系上报至集群调度器,每个资源申请模块通过集群调度器获得资源映射关系。
步骤S504:资源管理模块针对每个虚拟GPU设备导出GPU服务接口,每个资源申请模块根据资源映射关系,调用导出GPU服务接口中预先与约定的目标GPU服务接口,获得N个虚拟GPU资源中的目标虚拟GPU资源。
具体的,可通过IPC(比如,可以为UNIX socket、Pipe、shmem中的一种)或网络方式(比如,可以为TCP、Socket、RDMA中的一种)导出GPU服务接口。资源管理模块与每个资源申请模块预先约定GPU服务接口。具体的,可以通过预先约定共享内存位置(比如,约定好shmem位置/dev/shm/xgp-admin)或预先预定资源管理模块口(比如预定好资源管理模块口7788),预先约定目标GPU服务接口。
导出的GPU服务接口供相应的资源申请模块调用。如果是与虚拟GPU设备一一对应的导出GPU服务接口,则资源申请模块一一对应的调用GPU服务接口。如果是与物理GPU设备一一对应的导出GPU服务接口,则不同应用程序的资源申请模块,可能会调用同一GPU服务接口(绑定同一物理GPU设备中资源的多个虚拟GPU设备,是导出相同的GPU服务接口)。
进一步的,在针对N个虚拟GPU资源导出GPU服务接口之后,还包括如下步骤:
步骤1、资源管理模块获得目标资源申请模块上报的目标资源编号以及目标虚拟设备标识,目标资源申请模块是与资源管理模块通信连接的一个以上资源申请模块中的任意一个,目标虚拟设备标识是与目标资源编号指代的虚拟GPU资源绑定的虚拟GPU设备的标识;目标资源编号属于所有创建的虚拟GPU资源的资源编号中一个或者多个。
步骤2、资源管理模块根据目标资源申请模块上报的目标资源编号以及目标虚拟设备标识,查询在资源管理模块中的资源映射关系,目标资源编号和目标虚拟设备标识共同确定的虚拟GPU资源,即:目标虚拟GPU资源。
进一步的,本说明书实施例还提供对资源映射关系的维护包括:若检测到物理GPU资源发生变化,则更新资源映射关系,并触发更新资源管理模块和每个资源申请模块上的资源映射关系,其中,资源管理模块上更新后的资源映射关系和每个资源申请模块上更新后的资源映射关系相同,且均与变化后的物理GPU资源匹配。
从而实现了真实的物理GPU资源变化与重映射:当底层物理资源发生变化时,会协调资源申请模块和资源管理模块的配置,即通过同步更新资源申请模块和资源管理模块上的资源映射关系来动态适配底层GPU资源的变化,通过维护动态的资源映射关系,能够对上(AI框架、模型等)保持接口一致,对下则屏蔽物理硬件和驱动的实现差异,以到达资源的动态平衡。
在资源管理模块预先创建虚拟GPU资源之后,由每个资源申请模块各自发现资源管理模块创建的N虚拟GPU资源中相应的虚拟GPU资源。每个资源申请模块获得虚拟GPU资源的过程基本相同。下面以任一资源申请模块(目标资源申请模块)获得虚拟GPU资源的过程进行描述:
S505、目标虚拟GPU资源属于目标资源管理模块根据资源配置策略和物理GPU资源创建的N个虚拟GPU资源中的一个或者多个,资源映射关系由资源管理模块根据资源配置策略生成,资源映射关系表征物理GPU资源与N个虚拟GPU资源之间的映射关系,从而根据虚拟GPU资源能够找到真实的物理GPU资源。
在目标资源申请模块启动时,查询目标资源申请模块预先与资源管理模块约定的目标GPU服务接口;目标资源申请模块向目标GPU服务接口发起链接,基于与目标GPU服务接口的链接发现目标虚拟GPU资源。
如果有集群调度器,则发现目标虚拟GPU资源的过程包括如下步骤:
步骤A:资源申请模块向集群调度器发起申请GPU服务接口的GPU接口访问申请,GPU接口访问申请中携带有节点IP,资源申请模块所在节点的节点标识,使得集群调度器根据节点标识启动资源申请模块的目标对象,并向目标对象传入目标环境变量,其中,目标环境变量用于访问目标目标虚拟GPU资源。
步骤B:基于目标对象解析目标环境变量,确定出目标GPU服务接口;
步骤C:向目标GPU服务接口发起链接。
S506、目标资源申请模块向资源管理模块申请目标虚拟GPU资源,目标模型应用层使用目标资源申请模块申请到的目标虚拟GPU资源,完成计算任务。
可选的,目标资源申请模块动态申请目标虚拟GPU资源。具体而言,在目标资源申请模块启动之后,在目标资源申请模块每次需要处理当前子计算任务时,动态向资源管理模块申请目标虚拟GPU资源中用于对应模型应用程完成当前子计算任务的虚拟GPU资源。可选的,在目标资源申请模块启动时,一次性批量申请目标虚拟GPU资源。目标虚拟GPU资源可以用于对应模型应用层完成不同时间点下的多个子计算任务。
无论是采取动态申请还是批量申请目标虚拟GPU资源,由模型应用层调用资源申请模块向该应用模型层导出的GPU服务接口,发起GPU资源申请,例如:GPU服务接口可以为CUDA(CUDA是GPU厂商nvidia所推出的SDK统称。有相对应的开源接口例如OpenCL),
具体的,目标资源申请模块向资源管理模块发送目标虚拟GPU资源的资源编号,以及目标虚拟GPU资源所绑定虚拟GPU设备的虚拟设备标识,由资源管理模块获得该目标资源申请模块上报的资源编号以及虚拟设备标识,根据该目标资源申请模块上报的目标资源编号以及虚拟设备标识,资源管理模块查询资源管理模块中保存的资源映射关系,确定出目标资源编号以及虚拟设备标识所指代的目标虚拟GPU资源,根据确定出的目标虚拟GPU资源,映射到真实的物理GPU资源来完成计算任务。下面,对该过程进行更详细说明:
可以是在模型应用层的AI任务开始时,目标资源申请模块将资源编号,以及目标资源申请模块对应的虚拟GPU设备的vDev编号(例如只占用1B)发送至资源管理模块,而不需发送完整的资源描述或句柄(例如需占用8B),而资源管理模块可以基于资源编号以及对应虚拟GPU设备的vDev编号快速查询资源映射关系(根据资源编号的数组下标查询资源映射关系),确定目标虚拟GPU资源所对应的真实的物理GPU资源,这样减少IPC传输开销、网络传输开销。
第二方面,基于同一发明构思,本说明书实施例提供一种基于GPU资源的数据处理系统,参考图6所示,该基于GPU资源的数据处理系统包括:
获取单元601,用于获取物理GPU资源以及物理GPU资源的资源配置策略;
资源创建单元602,用于根据所述资源配置策略和物理GPU资源,创建N个虚拟GPU资源,以及生成物理GPU资源和N个虚拟GPU资源之间的资源映射关系,N为正整数;
资源获得单元603,用于根据资源映射关系,获得N个虚拟GPU资源中的目标虚拟GPU资源,并使用目标虚拟资源完成目标应用的计算任务,目标应用属于使用N个虚拟GPU资源的多个应用程序中的任意一个。
在一可选的实施方式下,获取单元601具体包括:
扫描单元,用于扫描本地GPU资源信息,根据本地物理GPU资源信息的扫描结果确定出物理GPU资源,物理GPU资源包括一个以上物理GPU设备的资源;
初始化单元,用于初始化一个以上物理GPU设备的运行环境。
在一可选的实施方式下,资源创建单元602,包括:
根据资源配置策略对物理GPU资源进行资源划分;
针对每个划分出的虚拟GPU资源块预分配物理GPU资源中预定量的GPU资源,得到N个虚拟GPU资源;
对N个虚拟GPU资源中每个虚拟GPU资源进行资源编号,以及将N个虚拟GPU资源中每个虚拟GPU资源绑定虚拟GPU设备,虚拟GPU设备的虚拟设备标识和资源编号用于唯一标识N个虚拟GPU资源中对应的虚拟GPU资源。
在一可选的实施方式下,资源获得单元603,包括:
接口导出单元,用于针对每个虚拟GPU设备导出GPU服务接口;
申请子单元,用于根据资源映射关系,以及导出的GPU服务接口中目标应用预先约定的目标GPU服务接口,申请N个虚拟GPU资源中的目标虚拟GPU资源。
在一可选的实施方式下,申请子单元,具体用于:
基于目标GPU服务接口,获得目标应用上报的资源标识信息,资源标识信息包括目标虚拟GPU资源的资源编号和/或目标虚拟GPU资源所绑定的虚拟GPU设备的虚拟设备标识;
根据资源标识信息查询资源映射关系,确定预先为目标应用分配的虚拟GPU资源,将预先为目标应用分配的虚拟GPU资源作为目标虚拟GPU资源。
在一可选的实施方式下,申请子单元,具体用于:
查询目标应用预先约定的目标GPU服务接口,目标GPU服务接口是为目标虚拟GPU资源对应的物理GPU配置的原始访问接口;
向目标GPU服务接口发起链接;
基于与目标GPU服务接口之间的链接,获得目标应用上报的资源标识信息。
在一可选的实施方式下,资源获得单元601,具体用于:
基于目标应用发起的GPU接口访问申请启动目标对象;
向启动后的目标对象传入目标环境变量,目标环境变量中包含用于访问目标虚拟GPU资源的信息;
调用目标对象,解析出目标环境变量对应的GPU服务接口,作为目标GPU服务接口。
在一可选的实施方式下,资源获得单元603,具体用于:
在目标应用启动时,批量申请目标虚拟GPU资源,目标虚拟资源用于目标应用在不同时间点完成计算任务中的多个子计算任务;或者
在目标应用当前需要处理计算任务中的当前子计算任务时,动态申请目标虚拟GPU资源中用于完成当前子计算任务的虚拟GPU资源。
在一可选的实施方式下,本说明书实施例中的系统还包括:
变化检测单元,用于检测物理GPU资源是否发生变化;
关系更新单元,用于若物理GPU资源是否发生变化,则动态更新资源映射关系。
第三方面,基于与前述基于GPU资源的数据处理方法实施例同样的发明构思,本说明书实施例还提供一种电子设备,如图7所示,包括存储器704、处理器702及存储在存储器704上并可在处理器702上运行的计算机程序,处理器702执行所述程序时实现前文所述进店消费人次确定方法实施例中任一实现方式中的步骤。
其中,在图7中,总线架构(用总线700来代表),总线700可以包括任意数量的互联的总线和桥,总线700将包括由处理器702代表的一个或多个处理器和存储器704代表的存储器的各种电路链接在一起。总线700还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起,这些都是本领域所公知的,因此,本文不再对其进行进一步描述。总线接口706在总线700和接收器701和发送器703之间提供接口。接收器701和发送器703可以是同一个元件,即收发机,提供用于在传输介质上与各种其他装置通信的单元。处理器702负责管理总线700和通常的处理,而存储器704可以被用于存储处理器702在执行操作时所使用的数据。
第四方面,基于与前述方法实施例的同样发明构思,本说明书实施例还提供一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现前文所述基于GPU资源的数据处理方法实施例中任一实现方法所述的步骤。
本说明书是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的设备。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令设备的制造品,该指令设备实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本说明书的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本说明书范围的所有变更和修改。
显然,本领域的技术人员可以对本说明书进行各种改动和变型而不脱离本说明书的精神和范围。这样,倘若本说明书的这些修改和变型属于本说明书权利要求及其等同技术的范围之内,则本说明书也意图包含这些改动和变型在内。