相比较，还原真实的GPU池化
发布时间：2022-04-14 11:47:39 所属栏目：动态 来源：互联网
导读：现阶段，CPU与GPU搭配的异构计算组合仍然是AI算力中心的首
|
现阶段，CPU与GPU搭配的异构计算组合仍然是AI算力中心的首选。在业界AI实际应用中，GPU硬件在业务弹性支撑能力、资金投入产出、能耗和IT架构等方面仍然痛点明显。 CPU和GPU的地位区别较大，一个是必需品，一个是加速器。CPU时刻都在运行，而GPU作为附加在计算机当中的设备（device），只有在需要时才被调用。因此，高效利用GPU资源的关键就在于按需调用、用完释放，且不用关心GPU资源够不够、从哪儿来。 阶段一，简单虚拟化：将物理GPU按固定比例切分成多个虚拟GPU，比如1/2或1/4,每个虚拟GPU的显存相等，算力轮询。 阶段二，任意虚拟化：仍然是以单机GPU虚拟化为目标，但是通过一些技术手段支持物理GPU的从算力和显存两个维度灵活切分，实现自定义大小，满足AI应用差异化需求。 阶段三，远程调用：重要技术突破在于支持GPU的跨节点调用，AI应用可以部署到数据中心的任意位置，不管所在的节点上有没有GPU。在该阶段，资源纳管的范围从单个节点扩展到由网络互联起来的整个数据中心，是从GPU虚拟化向GPU资源池化进化的里程碑。 阶段四，资源池化：关键点在于 按需调用，动态伸缩，用完释放。借助池化能力，AI应用可以根据负载需求调用任意大小的GPU，甚至可以聚合多个物理节点的GPU；在容器或虚机创建之后，仍然可以调整虚拟GPU的数量和大小；在AI应用停止的时候，立刻释放GPU资源回到整个GPU资源池，以便于资源高效流转，充分利用。 开源方案解决的是GPU共享问题，最多 仅做到阶段二（任意虚拟化）。这类方案基本都是基于NVIDIA官方插件( NVIDIA/ K8S -device -plugin)进行改造，在保留官方功能的基础上，通过device-plugin插件对业务容器内注入vGPU配置参数，实现对GPU的显存和计算单元进行限制的目的，从而在一个物理GPU上模拟出多张小的vGPU卡。在K8S集群中，采用扩展调度器（Scheduler）对这些切分后的vGPU进行调度，使不同的容器可以共享同一张物理GPU，提高GPU的利用率。 由此，我们可以看到，这类方案 ①仅支持K8S平台，②仅单机虚拟化。 趋动科技OrionX AI算力资源池化解决方案已经实现了GPU资源池化，即 阶段四。它在软件架构上采用数据面+控制面结合的方式—— 数据面包括OrionX Client Runtime（即AI应用或用户进程）与 OrionX Server Service（即接管GPU之后将GPU虚拟化抽象）两个组件，两者之间交换计算信令，一个Client可以与本机的Server通信，也可以与远端的Server通信，甚至可以同时与多个Server通信，通信的过程其实就是调用GPU计算的过程。如此一来，从OrionX Client的视角看到的就是一个大资源池，任一Client都可以实现前面所说的 按需灵活调用的效果。 控制面包括OrionX Controller和OrionX GUI两个组件，用于与前面的Client和Server交换控制信令，达到分配、调度并管理整个集群内部所有GPU资源的目的。 由此，我们可以看到：① OrionX AI算力资源池化解决方案的这套架构不仅可以支持K8S，还能全面支持KVM及物理机， 适用范围更广。②突破了传统GPU虚拟化技术只能支持单机GPU共享的限制，融合了GPU共享、聚合和远程使用等 多种能力，打造 全能型软件定义GPU。 （编辑：东莞站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐