AI场景下从GPU资源池到GPU双资源池

在AI（人工智能）的场景下，使用各种硬件加速器包括GPU、AI专用加速卡等对AI算法进行加速已经成为必不可少的选择。由于这类GPU、AI专用加速卡的价值占据服务器成本相当大的比例，甚至超过一半的成本，因此如何使用好这些高价值的设备、提高业务对它们的利用率、提高对它们的运维效率成为企业非常关注的要点。

把资源进行池化是数据中心提高资源利用率、提高运维效率的最重要的手段之一。资源池化是通过分布式软件、虚拟化等技术，把某一类资源抽象成为一种可以按照运维的管理要求、被整个数据中心各种用户和业务共享的资源，从而打破资源被用户和业务独占使用的模式，打破单台服务器的CPU、磁盘、网卡等物理资源数量的固定配比，并且能够动态根据用户和业务的需求来进行申请和释放。例如分布式的存储池、软件定义网络、云原生、云计算就是利用资源池化的思想和技术对磁盘、网络、服务器节点、业务应用等资源进行资源池化后的资源抽象。

近几年随着AI的快速发展，业务的快速落地，GPU、AI专用加速卡作为一种通用资源出现在数据中心。为了提高业务对它们的利用率、提高它们的运维效率，它们同样需要进行资源池化。GPU池化之后可以如同分布式共享存储一样，在数据中心被不同用户、业务弹性使用。例如下图是趋动科技(https://www.virtaitech.com/)的GPU资源池化方案所能够呈现的效果。

趋动科技OrionX AI算力资源池化解决方案

经过对GPU进行资源池化之后，整个数据中心不同物理节点的GPU卡都被抽象成为一种虚拟的GPU资源池。上层应用不再直接访问物理GPU，而是访问一种虚拟的GPU。以业内熟知的存储池的特点作为类比，可以看到对GPU进行资源池化之后具有和分布式存储池相似的特点。

存储池与GPU池化的特点类比

GPU资源池

GPU在数据中心经过资源池化之后，可以在如下的方面提升资源利用率，提高运维效率，帮助企业提高ROI：

• 业务按需申请GPU资源。很多业务，尤其是在线生产业务并不是要求算力越高越好。在线业务的负载来自于网络，只要在满足设定的计算延迟目标即可，并不是越快越好。业务对于显存的使用一般都不是正好把单个GPU的显存用满，单个业务独占GPU会有大量显存空闲。相对传统的单个业务独占使用一个物理GPU，经过资源池化之后的虚拟GPU可以避免资源浪费。

• 业务动态申请GPU资源，及时释放。不少企业为内部开发投入了大量的GPU资源，然而开发人员对GPU的利用往往很不充分——比如当他们在进行代码阅读、代码调试的过程中，大量的时间里GPU都是处于闲置状态。传统的GPU管理运维模式中GPU被独占地分配到一个运行环境中，即使应用程序不使用GPU，该GPU也不能被重新分配利用，从而被浪费。经过资源池化的虚拟GPU由于支持动态申请释放、自动根据调度算法使用整个数据中心的空闲GPU资源，所以可以用同样的GPU资源数量支撑数倍的开发人员。

• 有效使用碎片化的GPU资源。在实际场景中会有各种可能导致GPU无法被分配使用的情况。例如有的业务需求大量的CPU资源、内存资源，会导致某个节点的CPU、内存首先成为瓶颈从而有剩余GPU无法使用。GPU资源池化支持远程使用GPU，从而这部分剩余GPU可以提供给数据中心其他业务使用。一些分布式AI应用要求每个节点GPU数量一致，但是由于GPU被碎片化申请走，会导致这类业务不能很好地被排布，导致剩余碎片化资源无法被使用。

• 基于应用任务，实时动态调度GPU资源。传统的GPU管理分配模式下，GPU分配给不同的虚拟机、容器、业务之后，就无法再干预应用程序对GPU资源的使用和访问。而经过GPU资源池化之后，由于应用程序对GPU的访问和使用会实时经过池化软件的控制路径和数据路径，配合池化软件的支持，可以在满足业务需求的前提下，进一步榨取GPU的利用空间。

• 减少运维异构配置的服务器带来的复杂性。同一个数据中心服务器配置不一样的原因有两类。一类是用户主动引入异构配置服务器来为不同的业务选择优化的硬件配置；另外一类是由于历史原因，一些尚未被淘汰的服务器仍然在使用。这些配置不同的服务器极大提高了运维复杂性，也限制了业务对资源使用的有效性。因为固定的服务器配置与发展变化的业务是有天然的矛盾的，而服务器的采购、淘汰是对任何企业都是一个相对缓慢的过程，这样的问题在传统的GPU管理下尤为突出。而经过资源池化的GPU资源池是以整个数据中心作为一层分布式使用模式，可以打破这种物理资源配比，提高运维效率和业务使用资源效率。

• 简化机柜、制冷、供电等一系列基础设施的要求，减少碳排放。GPU服务器不仅是高价值资产，同时也是耗电大户。传统的机柜原来能放10台甚至20台2U服务器，如果需要安装高配的GPU服务器，一个机柜甚至只能放一台GPU服务器。一些数据中心可能因此出现容量不够的情况。通过GPU资源池化，合理配置GPU服务器和CPU服务器，可以大幅度减少对基础设施的要求及成本。

以上是一些业务使用经过资源池化抽象之后的虚拟GPU给企业带来的好处。那么是否一个企业的数据中心的GPU服务器都需要通过GPU资源池化软件抽象成为这种虚拟化的GPU呢？不同业务场景下的答案是不同的。在一些特定场景下，某些应用程序仍然有直接访问使用GPU的需求。类比于公有云的环境下，大部分用户使用的是经过虚拟化的虚拟机，但是为了满足某些实际场景的需求，公有云还提供裸金属服务器这种直接使用物理资源的方式。

如何管理一个数据中心的GPU，既能够提供虚拟GPU的能力来实现对GPU资源高效的管理和使用，也能满足特定需求下直接访问使用物理GPU。答案就是在GPU资源池化的基础之上，实现GPU双资源池。

GPU双资源池

对于AI的场景来说，哪些会有直接访问GPU的需求呢？尽管经过GPU资源池化之后的虚拟GPU保持了CUDA接口兼容，支持绝大部分的CUDA接口，但是仍然有部分能力和直接使用物理GPU有所差异，或者不被支持。

• 和debugger或者profiler相关的功能。和CPU虚拟化这种有完善硬件、操作系统支持不同，目前GPU、AI专用加速芯片对虚拟化方面的支持还比较薄弱。单纯依赖软件来完全实现虚拟化环境下的 debugger、profiler是不可行的。例如英伟达GPU的vGPU对这方面的支持也是有非常大的限制，不具有实操意义。因此在应用开发过程中如果依赖这类功能，需要直接访问使用物理GPU。

• 出于研究目的，对应用算法的性能做深度分析的场景。尽管在大部分AI的场景，例如趋动科技的OrionX GPU资源池软件可以做到性能接近物理GPU的性能，但是在做学术研究，或者在专门针对GPU性能、调度进行研究的时候，为了得到可以在其他非GPU资源池化环境下可以复现的结论，需要直接在物理GPU上做相关的测试和研究。

• 某些非云原生的商业应用，出于保护知识产权的目的，在发布license时深度绑定某一些物理资源特征，导致不可以使用虚拟GPU。

• 用户硬件、软件更新非常快，紧跟GPU厂商的硬件、软件发布的情况。不管是哪种GPU资源池化方案、GPU虚拟化方案，都是一种第三方的软件实现，都是基于某一些特定版本进行支持。那么存在这一类软件落后于最新GPU硬件版本的时间差。包括英伟达原厂的vGPU软件也是如此。如果用户希望在这个时间差内使用最新的硬件和软件，那么需要直接使用物理GPU。

基于以上的分析，我们希望既要通过GPU资源池化使用虚拟GPU来提高GPU的利用率，又的确有直接访问使用物理GPU的需求。一个简单并且直接的方法就是在运维数据中心的时候，固定划分两部分GPU服务器，一部分安装GPU资源池化软件，一部分维持传统的使用物理GPU的方法。这样的方法虽然简单，但是弊端也比较明显。

• 运维复杂，两个资源视图使得GPU的管理复杂化。哪些GPU型号需要如何划分，需要划分多少数量，都是非常难决策的问题。

• 可能导致GPU资源无法充分使用。因为静态的数量划分难以适应动态的业务增长和变化。数量划分少会导致不够用，数量划分多了会导致利用不高。

因此，GPU双资源池不是一个简单的静态的GPU使用功能的划分，而应该是一个统一的管理视图，动态兼顾两类功能的需求。

趋动科技的OrionX GPU资源池化方案就支持这样的双资源池管理模式。在GPU服务器资源加入GPU资源池集群的时候，用户可以使用参数对GPU卡进行初始设定（物理或虚拟），可以指定一部分为物理GPU，一部分为虚拟GPU。初始化之后，用户可以通过CLI/API或图形界面进行切换，下图显示的是两台服务器上各有一块GPU卡，用户可以通过该界面进行虚实的切换。

OrionX 管理界面

用户还可以设置高级参数，来自动设置OrionX vGPU的占比，如下图界面操作：

OrionX支持自动配比虚实GPU资源

OrionX的双资源池管理能力还可以配合对应的Kubernetes插件，和Kubernetes的设备管理能力无缝结合，实现OrionX管理界面和Kubernetes的GPU管理能力融合而不冲突。虚拟GPU和物理GPU在Kubernetes中对应不同类型的资源、业务按照自己的需求申请不同类型的GPU。两种资源配比的动态调整也会和Kubernetes的资源管理能力联动。

GPU资源池化是AI应用落地走向成熟的重要里程碑，说明企业已经从关注功能到开始关注效率。计算机领域其他成熟的资源都经历了这个过程。GPU资源池化也是这两年的热门技术，已经逐渐被市场认可，在互联网、金融、电信运营商、自动驾驶、科研机构和高校等大量的行业企业得到应用。而从GPU资源池到GPU双资源池，更是推动企业放心大胆接受这种新兴的技术, 为企业技术决策者吃个定心丸，进退自如，虚实灵活切换，满足业务需求，增强弹性，规避技术风险。

Reference：

https://docs.nvidia.com/grid/latest/grid-vgpu-user-guide/index.html