令GPU的生产力数倍提升的最佳方式 – 软件定义算力_业界对gpu使用率的建议

GPU利用率低是当前业界普遍现象

在部署AI业务的时候，大家都会发现一个典型的问题：GPU的利用率非常低。其实这个是众所周知的现象。哪怕是AI界的巨头公司AWS和Meta (前Facebook)，其GPU的利用率也是非常低，见下面来自该两家的数据：

• 2018年，AWS在AWS re:Invent 2018大会曾提及，在AWS上GPU利用率只有10%至30%。

图1：AWS的re:Invent 大会数据

• 2021年，Facebook对其机器学习负载的分析结果，大量的GPU算力被浪费闲置，真正的利用率不足30%

图2：Datacenter-Scale Analysis and Optimization of GPU Machine Learning Workloads

GPU利用率低的原因分析

那么造成这种现象的主要原因是什么呢？技术理论上来说，就是因为算法应用中GPU算子申请了不合理数量的线程和块，从而导致了GPU中大量SM空闲和大量SM的内部资源没有利用。从文字的描述来说，可能难以直接理解，需要从CUDA编程角度来看GPU是如何使用资源说起。如下是CUDA编程模型与GPU的映射关系图:

图3：CUDA软件抽象与硬件结构的对应关系

图4：CUDA编程模型与GPU的映射关系

从上述的图可以知道，基于CUDA编程的算法就是在GPU硬件上启动了线程集合，然后执行多线程并行计算。那么为了更好调度线程，GPU就采用了分层的架构。软件会将kernel函数转化成thread ->Block ->Grid，分别放置在硬件GPU内的SP (Stream Processor)、 SM (Stream Multiprocessor), Device执行计算。而通用GPU的架构中，GPU(即Device)会包含很多的SM，每个SM都有自己的寄存器、缓存和共享内存, 并拥有很多Core资源，可以同时执行多个thread（线程）。可以说SM是GPU中独立的计算单元。

另外在SM内执行和调度thread，并不是以个数进行调度执行的，而是以一组thread数目进行的，其单位为warp （线程束）。也就是说warp是SM内最基本的执行单元。一般一个warp包含32个并行的thread， 这些thread只能执行相同的指令。不过一个SM里面因为其寄存器数量和内存等资源有限，所以单个SM可以支持的最大并发thread或block或warp都是有限的。参考如下几个高端GPU的最大支持并发计算参数表格。

表1：GPU最大支持并发计算参数

那么为什么会发生GPU利用率过低的问题呢？我们分情况来看：

情况1： 算法应用每次申请的thread和block的数量不合理，导致每个SM里面空余了大量的资源没有利用。例如：Nvidia H100, 每个SM最大支持32个Block 或64个warp, 而且每个block可以支持1024个thread，综合来说H100的每个SM最大支持的线程数是2048 （64个warp,  32*64）。

如果算法程序申请使用了32个thread作为1个block单位， 并总共申请了2048个thread，结果该算法实际就申请了2048/32 = 64个block。如上所述H100每次最大只能并行处理32个block, 哪怕SM最大可以支持运行2048个线程，但限于最大处理block数量32的限制，每个SM也只能运行32 * 32=1024个线程，这样就需要2个SM来运行共2048个thread。这个时候每个SM实际上只能占用50%GPU资源。

情况2：算法应用每次申请的thread线程数量少，那么就无法占满GPU中大部分 SM数量。

例如，从寄存器的分配角度来说， 每个SM有65536个寄存器。如果按SM最大并发线程数2048个同时执行， 那么每个线程最多可以有32个寄存器（65536/2048 = 32）。假如算法kernel函数中分配了64个寄存器给每个线程，那么该场合每个SM就只能最大同时运行1024个线程，同样会导致50%占用率。

这个就是算法为GPU算子申请了太少的线程和块，整个GPU中只有少部分的SM参与了计算，还有很多的SM在空闲。

如果上述的2种情况的说法过于复杂，我们可以类比大巴车运输旅游团：

• 旅游社：对应AI算法应用

• 旅游团：对应线程块(block)

• 旅游游客：对应线程(thread)

• 大巴车：对应物理GPU  

• 大巴车的座位：GPU的SM，并假定只有60座BUS接送游客

*上述的对应不一定100%跟算法与GPU资源架构关系相同，仅为解释举例

如果旅游公司某个时刻出发的旅游团只有8个团员，而这个时刻只有一个团，运输公司也只能派出一辆有60个座位的大巴车来接送8个人，这个场合就是上述的情况2。

如果旅游公司某个时刻出发的旅游团不少，有20个，每个团有32个团员，这个时候运输公司需要派出20辆有60个座位的大巴车来接送这10个团。这个场合就是上述的情况1。

大家想一想，这样做法，大巴车的空位率就明显非常高了，自然大巴车的利用率就很低了。

以上两种情况，就是在GPU底层执行计算层面上造成GPU资源浪费的本质原因。而当前用户在使用环境上因为GPU资源管理和调度的问题更加放大了这种缺陷，造成了前文所描述的异常低的GPU利用率！

例如1，当前服务器集群的资源调度策略（主要考虑CPU，内存）是以服务器节点为单位调度分配给上层算法的话，那么这个造成的浪费更甚了。就如同上述运输公司派出的接送车辆单位不是一辆普通的大巴（单个GPU），而是有两节车厢相连的双层巴士 （单个服务器节点具备4个GPU），其大巴车的座位空置率自然更加惊人了。

例如2， 当前基于物理资源的申请方式，当用户申请了整机的资源，如果是1台或多台4卡服务器， 但是用户有可能并不是24小时都在连续使用，在开发的场合中，更可能是只有1/3时间在运行GPU计算，而且项目结束后，用户并不一定及时归还资源。就像一个旅行社申请了1辆或多辆大巴使用30天，但是这些大巴有10天是没有运送旅客的， 而且实际上在申请大巴后的第22天后就基本完成旅行社原来的计划，之后就不使用大巴了。

所以综合来说，因为GPU底层执行计算会有资源浪费，而目前用户在管理，分配和调度GPU资源的方式和策略，更是放大了其浪费的效果，导致了GPU的利用率异常低下。

现实中最适合的提高GPU生产力的方案

要改变大巴空位率的问题，只有2个方向：要不就是旅游公司，将不同时刻出发的团合并在一起，原则就是凑够60人为一个单位进行接送；要不就是运输公司自己具备多种规格的接送车辆，有2/4/6/8……不同座位数量的多台车辆，可以按实际旅游团的人数派出相应的座位数量的车辆。

照进现实中AI算法使用GPU的现状，同理，业界想提高GPU的利用率，提升GPU生产力的话，要不就是算法针对GPU进行定制开发（需要针对GPU型号，CUDA版本等），就是按GPU的资源去定制最优化的线程块和warp数量，尽量利用GPU资源，提高生产力（即旅行社进行团员数量和团数量的最大优化）；要不就是针对算法对GPU资源的需求，自定义最适配的GPU资源给算法使用，避免浪费（即运输公司进行针对团员数量和团数量，进行供应车辆的优化）。

但是第一个思路，算法针对GPU进行定制开发，是不可能普遍做到的，现实中甚至是大部分的算法模型都没有做类似的优化。所以，后者思路我们可以去尝试实现。

从第二种思路来说，也就是从GPU供应端来看，上述造成GPU利用率低的情况是因为我们提供了整块物理GPU资源给算法模型，而算法模型没有能力利用整块GPU资源。所以，如果我们提供的不是以物理GPU为单位的算力和显存，而是使用软件来灵活自定义GPU算力和显存的方式去提供合适的GPU资源给算法模型，这样就可以避免或最大化改善了GPU利用率过低的问题了。 

趋动科技的OrionX 软件就是这样一个软件定义算力，按需供应GPU资源的方案，它可以极大提高GPU生产力。OrionX可以通过软件的方式自定义虚拟GPU的资源，分为算力和显存两个维度来进行自定义。

• 算力：1%~100%  （以1%为单位调整算力，算力上限是物理GPU的100%算力

• 显存：1MB ~ ？MB  (以1MB为单位调整显存，容量上限是物理GPU的显存 + 服务器可用内存)

也就是说我们可以使用软件定义的方式来灵活地定义不同数量座位（SM和显存）的不同运送车辆（GPU），来接送旅行社不同团员数量的旅行团，即可以按旅行团来定制座位的车辆，实现按需分配。这样就解决了原来大巴车座位空置率高的问题。换成了GPU，就是解决了GPU底层执行计算时候资源浪费的问题。

接下来就是解决用户高效率管理使用GPU的问题了，就像旅行社如何合理地充分利用运送车辆的工作时间一样。OrionX针对这种情况，有着非常完善的解决方案。

当用户申请虚拟GPU资源后，如果用户并没有马上开始运行算法代码、执行GPU计算，那么实际上其申请的GPU资源并没有让该用户占用；只有用户真正执行代码，运行GPU计算的时候，其GPU资源才会被占用。而且一旦算法代码执行完毕，其占用的GPU资源会自动马上释放，参与到下一次的资源分配，无需人工干预。所以，在开发的场合，基本无需担心算法开发工程师长期不合理占用资源。这个机制，解决了传统使用上GPU资源不合理占用而闲置的问题。

另外，趋动科技的OrionX软件可以将整个GPU服务器集群中所有的GPU组成一个大的GPU资源池，然后针对算法程序的需求，可以基于整个资源池的资源（算力和显存）进行按需供给，也就是可以跨节点调用GPU资源，见下图。

图5：OrionX根据模型需求，灵活供应GPU资源

所以，OrionX的软件定义算力的方案，不但可以解决单体GPU内部SM数量占用率低的问题，还可以跨节点调用GPU资源，这样两者结合方式，对于整个数据中心的GPU的资源都可以充分利用，实现整个数据中心的GPU生产力最大化。这种利用软件定义算力结合本地和远程调用资源的方式，可以称之为GPU池化或算力池化。

笔者在最近的一个结合业务的测试中，就使用了OrionX的软件定义算力的功能，实现了业务层面倍数级别的生产力提升。具体的测试方式和对比请参考如下信息。

首先我们在如下配置的物理服务器上分别测试了目标检测yolov5和文字识别PaddleOCR的最大业务处理能力。

• CPU：2* Intel(R) Xeon(R) Gold 5218R

• 内存：378GB

• 硬盘：500GB

• OS：CENTOS 7.9

• GPU：Nvidia T4 * 1

结果就是：

• Yolov5 ：125.6 FPS  （即每秒可以推理125.6张图片）

• PaddleOCR:  0.75 秒  （即识别一张指定标准图片的文字需要0.75秒） 

以上的这两个结果是目前使用物理GPU提供给1个Yolov5模型或1个PaddleOCR模型推理产生的业务处理结果。

但是实际上，1个Yolov5模型或1个PaddleOCR模型并没有完全利用完GPU T4的算力和显存， 如同上文提及的情况1和2。

所以我们可以使用软件定义的方式将T4切分成多个虚拟GPU来提供给多个Yolov5或PaddleOCR模型进行并行的处理，这样业务的吞吐量是否就可以实现数倍的提高呢？

首先，改变整个物理GPU为单位资源的提供方式，使用软件定义虚拟GPU资源如下：

• Yolov5测试： 定义每个OrionX vGPU分配40%算力 ，4GB显存。定义1张T4 GPU分成 12个OrionX vGPU, 每个OrionX vGPU提供给1个Yolov5模型，这样就可以实现12个Yolov5模型并行推理；

• PaddleOCR测试：定义每个OrionX vGPU分配20%算力，3GB显存。定义1张T4 GPU分成5个OrionX vGPU， 每个OrionX vGPU提供给1个PaadleOCR模型，这样可以实现5个PaddleOCR模型并行推理；

（注意：Yolov5测试项目定义虚拟GPU，使用了OrionX的资源超分功能，所以可以分配超越物理GPU原来的算力和显存值）

其测试结果如下：

视频推理-目标检测模型Yolov5业务：

表2：Yolov5的测试结果

• 采用物理GPU：1张T4 物理GPU只能运行1个Yolov5模型，不能并发运行2个或以上的模型， 其每秒可以推理125.625张图片， 即125.625 FPS。

• OrionX软件定义GPU资源：1张T4物理GPU可以同时运行12个Yolov5模型，每秒可以推理510.58张图片， 即510.58 FPS。也就是说，同一张T4 GPU其业务处理能力是原来的4.06倍。 

文字识别-PaddleOCR业务：

表3：PaddleOCR的测试结果

• 采用物理GPU：1张T4物理GPU只能运行1个PaddleOCR模型，不能并发运行2个或以上的模型，其文字识别的时长为0.75秒。

• OrionX软件定义GPU资源：1张T4物理GPU可以同时运行5个PaddleOCR模型，虽然文字识别时长为1.23秒，高于原来单张物理卡识别时长，但是1.23秒在业务标准以内（要求不大于2秒）。所以在业务标准以内，同样的T4 GPU其业务处理能力是原来的5倍。

  
  
   

从上述的结果，我们可以明确地知道软件定义算力的方案对于GPU生产力提升有着非常显著效果。

当然正如上文所提及的，因为算法中为GPU算子申请了不合理的线程和块才导致了GPU资源浪费，所以这个具体的提升效率比例的数字，会与不同的算法有具体的关系。

趋动科技的软件定义算力方案OrionX除了可以提升GPU的效能外，同时也可以实现人效提升，节约硬件的投资，对于节能减排也起到明显的效果。趋动科技的OrionX如同二十多年前的VMWARE一样，将会使用软件定义的方式来重新定义AI算力，为即将到来的以智算资源为中心的数据中心带来革命性的技术！

本文参考资料：

1. Dissecting the CUDA scheduling hierarchy: a Performance and Predictability Perspective

https://conferences.computer.org/cpsiot/pdfs/RTAS2020-4uXAu5nqG7QNiz5wFYyfj6/549900a210/549900a210.pdf

2. 聊聊 Nvidia GPU——CUDA、底层硬件架构、调度策略

https://mp.weixin.qq.com/s/u_lhA5Kg_8MLhneXEdJ_NQ

3. SM详解与Warp Scheduler，合理块和线程的数量对GPU利用率非常重要

https://zhuanlan.zhihu.com/p/670063380

4. CUDA 编程上手指南(一)：CUDA C 编程及 GPU 基本知识

https://mp.weixin.qq.com/s/kxYSw_fR4QMZ2-O5fvOR8g