【问题】

深度学习相关的程序运行时，GPU利用率很低，间隔地达到一下一个较高的值，但大部分时间是0%。

【分析】
通常是因为GPU在等程度的其他动作，主要就是加载数据和CPU上的一些操作（包括数据预处理等），所以可以按照以下步骤逐一确认瓶颈所在：

1. 确认一下CPU利用率是不是很高：
   top # 查看对应CPU利用率是不是爆满
   如果CPU利用已经超负荷了，那说明数据预处理等操作的一步可能就已经达到机器上限了，需要考虑CPU性能是不是不太够。

2. 更常见的原因是I/O瓶颈，尤其常见的情景是数据存储在机械硬盘上，也就是CPU的利用率也不是很高，GPU利用率更低，这时候可以看一下I/O的情况：
   sudo iotop # 需要sudo权限
   如果只用一个进程读数据，那势必会比较慢，这时候应该考虑多进程并行地读数据，如果在pytorch中，可以用torch.util.data.Dataloader来包自定义的数据读取函数，num_worker参数可以控制数据读取的进程数：

自定义数据读取函数

代码隐身了

num_workers的数量具体设置多少要根据CPU核数来确定，可以自己试一下，什么时候CPU和GPU有一个撑满了，就算是够多了。
但是如果机械硬盘的I/O上限在那里，那肯定是再多进程也没有用，这时候只能感叹SSD大法好了。

【总结】

影响程序运行速度主要有三个节点，以及根据常见的机器配置，它们限制速度的可能性大小关系如下：
数据读取（I/O速度）> 数据预处理等（CPU）> 网络前馈（GPU）

在不改变硬件条件的情况下，最能够努力的就是增加数据读取的进程，以及尽量把数据预处理操作能移到GPU上进行的就都移到GPU上。

这是从宏观角度来看的，当然另外还有一些比较细节的黑科技，需要根据特定的程序来寻找针对性的优化方法了。

nvidia-smi指令

命令位置：

所以Path中添加环境变量：
C:\Program Files\NVIDIA Corporation\NVSMI
试验一哈：

要注意的点：

• Driver Version和CUDA Version不是一回事
• CUDA Version实际是环境变量中Path配置的，如果一台机器同时装了多个CUDA，那么这里的CUDA Version显示的是Path中靠前的CUDA版本（和nvcc -V的显示是一样的）
• 下方的GPU使用信息网上有很多资料，但是比较靠谱的资料是去官网查手册，这里不再赘述，只挑几个比较重要的说一下：

1. Temp = Temperature，温度
2. Perf = Performance，性能，P0-P12，由低到高
3. Memory / Usage ,其实下方的数据是“已经使用的显存/总显存”
4. GPU-Util，GPU使用率

• 下方的Processes显示的使用GPU的线程信息：GPU序号，线程ID，线程名，GPU显存使用量
• N/A可以理解为无法显示，并不是无限大的意思

动态刷新GPU信息

nvidia-smi -l    # L小写字母，不是1

每隔一秒刷新一次GPU信息（执行一次nvidia-smi的结果）
后面可以加上自定义的秒数，如：

nvidia-smi -l 5   # 每隔5秒刷新一次

还有更细粒度的：

nvidia-smi -lms    # 每隔1ms刷新一次，（ L小写字母，不是1）

当然也可以自定义毫秒数：

nvidia-smi -lms 500   # 每隔500毫秒刷新一次

个人经验，500ms刷新一次比较适合。
PS：nvidia-smi的用法可以nvidia-smi -h查看：

显存占用高，但是CPU使用率低

如之前的图中：

显存占用率：5456MiB/6144MiB = 88.80%
GPU利用率（GPU-Util）：0%
（即使100ms刷新一次也捕捉不到GPU利用率的提高）
PS：
这里先补充一个知识，回想一下CPU和内存的关系，同理，GPU和显存的关系同。上图的场景类比于CPU与内存即：内存快占满，但CPU使用率很低，eg：

如Java中while(true)创建对象，内存会爆，但是CPU使用率并不高。
上述显卡显存占用率高，GPU利用率低的情况出现在笔记本跑深度学习时，最初以为是显存太低的缘故（load一个batch_size（（一次训练的图片数））的数据即过载），换在16G显存的服务器中跑，同样出现该问题：
修改batch_size（一次训练的图片数）大小，无效，改大改小（最小到1）都不行。

怎么解决呢？

答：
试了n多的方法，终于找到原因：
训练的原始图片大小为3024 * 4032，实际大小为2-3M，太大了。。。
如果解释为什么，则先了解一个背景知识，类似于CPU与内存的关系，在GPU工作流水线中，也是按照显存准备数据——GPU拿数据运算——显存准备数据——GPU拿数据运算 …的方式工作的。如果图片的分辨率太大，即使一张图片（batch_size为1）放入显存，也直接爆了，GPU利用率当然也无从谈起，外在表现就是显存几乎占满，但同时GPU等不到数据，一直空闲。解决方法是将图片分辨率改小就OK了。

回头再看

回头再看，这个问题的解决思路是应该是这样的：

• 确认代码在GPU上跑了
  有两个方法：

• 项目下单独建测试文件test.py or 运行项目的训练模型

import os
from tensorflow.python.client import device_lib
os.environ["TF_CPP_MIN_LOG_LEVEL"] = "99"

if __name__ == "__main__":
    print(device_lib.list_local_devices())

运行文件，可以看到输出GPU硬件信息。
或者直接运行项目的训练模型，因为项目的TensorFlow调用了GPU，也会输出类似上面测试代码的运行效果——输出的GPU信息（猜测是TensorFlow内部也有类似上面的打印GPU信息的代码），此时（必须正在运行TensorFLow代码）查看nvidia-smi的线程信息会有python.exe（）：

好，已经能够确定TensorFlow调用了GPU跑代码。

② 观察显存和GPU利用率
一定要使用动态刷新nvidia-smi命令，因为有时GPU利用率是跳跃式变化的，同时尽量关
闭其他使用GPU的程序，单独观察tensorflow利用情况。

• 显存占用低，GPU利用率低
  很明显，这是因为batch_size太小，显存没完全利用，GPU没有喂饱，尝试增大batch_size
• 显存占用高，GPU利用率低
  大概率batch_size太高，即显存成为bottle_neck，GPU一直在等显存的数据此时尝试逐步减小batch_size，观察GPU利用率。如果batch_size已经为1，问题依旧，则考虑是不是单张图片分辨率太大的问题。

已经证实了我的猜想“从batch_size角度考虑”的正确性。详细解释在后面更新。

GPU利用率低而显存占用率高的思考

问题描述：在深度学习training中，可以看到cpu利用率很高、内存占用率很高、显存占用率很                           高，但GPU利用率很低，train比较耗时。

本文对这个问题进行了思考。

（仅仅是自己遇到问题思考的一些内容，也不一定正确，期待和大家交流探讨）

1.先了解下深度学习中数据的加载问题

先将硬盘中的数据读取到内存中，然后CPU从内存中读取数据，再将数据传输到显存中，等待GPU处理，处理完成之后会传递一部分参数数据到CPU。同时CPU还会将网络和损失函数等传递给GPU。详细可以看这里：http://t.csdn.cn/reYH6。

2.遇到的问题描述

性能可以在任务管理中查看，也可以通过终端查看。不多过阐述。

内存占用率很高（27G/63G）；CPU利用率很高70%-90%；显存占用率很高，GPU利用率不高。可以看下图，我用的dataset是Cityscapes精细标注的版本。

3．问题分析

1）从CPU传输数据角度来考虑

   GPU处理的数据是从CPU拿过来的，是否存在io传输瓶颈的问题？针对我的情况来看，我的理解是cpu、显存占用率都这么高，可以理解为GPU要从显存拿数据做处理，如果传输受到了限制，那首先显存占用率会降下来，所以这一点可以排除。

2）从batch_size角度考虑

可以从bs传输数据的的角度考虑，先假设GPU处理数据时间小于数据传输时间（具体计算是又模型来决定，而且确实是小于的，因为没看到显卡的数据一直是满的），当传一个bs的数据就非常大的时候（足以占满显存），那GPU利用率低的主要原因是由于显存大小限制的，因为GPU一直在空闲等待数据中。

但是这个角度我还不能验证，等我训练完之后抽空试试看，但是这个思路可以和大家分享。

以上两点是我的思考，以下是两点有关调参的小tips。

Num_works和pin memory这两个参数的作用，第一个是开辟多少个CPU线程来处理数据，可以根据CPU核数设置，一般用4,8,16等。但是这个参数也不能太大。当这个参数太大是，在分发数据的时候可能会消耗一定的时间，极端点可以理解为CPU处理数据很快只要1s，但是因为线程数太多而分发数据的时候花了5s。pin memory的介绍可以参考这里：pin_memory - 知乎。简单讲就是该参数开启时，可以减少数据传递到显存中的时间。

更新2022.5.31

解释：这段时间对代码有进行了修改，对细节也把握更多了。我跑的代码是GSCNN的代码，看到作者传进模型的feature map 是[b,3,720,720]，进过wideresnet七层处理之后最后得到m7为[b,4096,90,90]，然后传入到ASPP做卷积操作。当时跑代码的时候，模型只有cnn的计算，可以看到设备使用情况，在上面可以看到。当时设置的训练集和验证集的bs都为6，num_works设置好像为5.

后面这段时间我将transformers加入到GSCNN中，计划是将在不同的cnn层之后加入TF，但是在实际操作过程中由于太吃显存了，硬件条件有限（48G 2*3090），最后只加了一层TF，但是就这一层TF加进去之后，GPU的利用率马上就上来了。很明显大家都知道TF的计算量是非常大的。所以基于这一点我们可以得出结论，之前显存里面全是加载进来的数据，GPU计算性能没被拉满，是因为受到显存的限制。假设GPU的计算能力为十个单位。传入同样大小的数据，以占满显存为准（48G），纯CNN的时候计算需求为1个单位，那加入TF之后计算需求为4个单位。（举个例子）

关于内存和CPU利用率变化的原因是bs和num_works设置的时候不一样引起的，这个不是重点讨论对象，根据这个现象我们可以得出结论：1、显存会限制GPU性能的发挥，2、利用率（可以理解为计算需求）和模型中计算量有关。

思考到这里我又有了疑问了：之前也跑过同样数据集，好像是deeplabv3+模型，其中一个模型跑起来速度超级快的，（当时已经意识到了GPU利用率的问题，所以特地有关注GPU利用率）GPU利用率也很高，好想达到了百分之八九十的样子。对比这个模型（纯CNN的），同样都是一些卷积操作，为什么dpV3+ 跑起来GPU利用率那么高，训练耗时少 ，而gscnn就不行。

结合我上面的思路我考虑到了是不是传给模型的数据问题，我测试了gscnn中传给模型的数据为

[b,3,720,720],但是我没有测试dpV3+的数据是多大，所以疑问就是不同大小分辨率的图片传给模型会对性能有影响吗？为什么有的代码传给模型的分辨率较高，有的较低，这一差异的出发点在哪？

待我探索完成后来更新这个问题的答案。

参考：

https://www.jb51.net/article/213809.htm

https://www.cxyzjd.com/article/ProLayman/104758331