深度学习PyTorch，TensorFlow中GPU利⽤率较低，CPU利⽤
率很低，且模型训。。。
在深度学习模型训练过程中，在服务器端或者本地pc端，输⼊nvidia-smi来观察显卡的GPU内存占⽤
率（Memory-Usage），显卡的GPU利⽤率（GPU-util），然后采⽤top来查看CPU的线程数（PID数）和利⽤
率（%CPU）。往往会发现很多问题，⽐如，GPU内存占⽤率低，显卡利⽤率低，CPU百分⽐低等等。接下来仔细分析
这些问题和处理办法。
（ps：对于如何在Intel CPU，ARM架构CPU，以及Jetson TensorRT上部署深度学习模型，以及部署遇到的速度问题，该如何解决。请查看我的另外⼀篇⽂章。如何定制化编译Pytorch，TensorFlow，使得CNN模型在CPU，GPU，ARM架构和X86架构，都能快速运⾏，需要对每⼀个平台，有针对性的调整。如何做到最⼤化加速深度学习在不同平台部署性能。请看我的这篇⽂章。）
lips是什么意思1. GPU内存占⽤率问题
小区英文
这往往是由于模型的⼤⼩以及batch size的⼤⼩，来影响这个指标。当你发下你的GPU占⽤率很⼩的时候，⽐如40%，70%，等等。此时，如果你的⽹络结构已经固定，此时只需要改变batch size的⼤⼩，就可以尽量利⽤完整个GPU的内存。GPU的内存占⽤率主要是模型的⼤⼩，包括⽹络的宽度，深度，参数量，中间每⼀层的缓存，都会在内存中开辟空间来进⾏保存，所以模型本⾝会占⽤很⼤⼀部分内存。其次是batch size的⼤⼩，也会占⽤影响内存占⽤率。batch size设置为128，与设置为256相⽐，内存占⽤率是接近于2倍关系。当你batch size设置为128，占⽤率为40%的话，设置为256时，此时模型的占⽤率约等于80%，偏差不⼤。所以在模型结构固定的情况下，尽量将batch size设置⼤，充分利⽤GPU的内存。（GPU会很快的算完你给进去的数据，主要瓶颈在CPU的数据吞吐量上⾯。）
2. GPU利⽤率问题
这个是Volatile GPU-Util表⽰，当没有设置好CPU的线程数时，这个参数是在反复的跳动的，0%，20%，70%，95%，0%。这样停息1-2 秒然后⼜重复起来。其实是GPU在等待数据从CPU传输过来，当从总线传输到GPU之后，GPU逐渐起计算来，利⽤率会突然升⾼，但是GPU的算⼒很强⼤，0.5秒就基本能处理完数据，所以利⽤率接下来⼜会降下去，等待下⼀个batch的传⼊。因此，这个GPU利⽤率瓶颈在内存带宽和内存介质上以及CPU的性能上⾯。最好当然就是换更好的四代或者更强⼤的内存条，配合更好的CPU。
外埠
另外的⼀个⽅法是，在PyTorch这个框架⾥⾯，数据加载Dataloader上做更改和优化，包括num_workers（线程
数），pin_memory，会提升速度。解决好数据传输的带宽瓶颈和GPU的运算效率低的问题。在TensorFlow下⾯，也有这个加载数据的设置。
torch.utils.data.DataLoader(image_datats[x],
batch_size=batch_size,
shuffle=True,
num_workers=8,
pin_memory=True)
为了提⾼利⽤率，⾸先要将num_workers（线程数）设置得体，4,8,16是⼏个常选的⼏个参数。本⼈测试过，将num_workers设置的⾮常⼤，例如，24，32，等，其效率反⽽降低，因为模型需要将数据平均分配到⼏个⼦线程去进⾏预处理，分发等数据操作，设⾼了反⽽影响效率。当然，线程数设置为1，是单个CPU来进⾏数据的预处理和传输给GPU，效率也会低。其次，当你的服务器或者电脑的内
存较⼤，性能较好的时候，建议打开pin_memory打开，就省掉了将数据从CPU传⼊到缓存RAM⾥⾯，再给传输到GPU上；为True时是直接映射到GPU的相关内存块上，省掉了⼀点数据传输时间。
3. CPU的利⽤率问题
很多⼈在模型训练过程中，不只是关注GPU的各种性能参数，往往还需要查看CPU处理的怎么样，利⽤的好不好。这⼀点⾄关重要。但是对于CPU，不能⼀味追求超⾼的占⽤率。如图所⽰，对于14339这个程序来说，其CPU占⽤率为2349%（我的服务器是32核的，所以最⾼为3200%）。这表明⽤了24核CPU来加载数据和做预处理和后处理等。其实主要的CPU花在加载传输数据上。此时，来测量数据加载的时间发现，即使CPU利⽤率如此之⾼，其实际数据加载时间是设置恰当的DataLoader的20倍以上，也就是说这种⽅法来加载数据慢20倍。当DataLoader的num_workers=0时，或者不设置这个参数，会出现这个情况。
CPU利⽤率查看结果
howimetyourmother下图中可以看出，加载数据的实际是12.8s，模型GPU运算时间是0.16s，loss反传和更新时间是0.48s。此时，即使CPU为2349%，但模型的训练速度还是⾮常慢，⽽且，GPU⼤部分是时间是空闲等待状态。
怃然num_workers=0，模型每个阶段运⾏时间统计
当我将num_workers=1时，出现的时间统计如下，load data time为6.3，数据加载效率提升1倍。且此时的CPU利⽤率为170%，⽤的CPU并不多，性能提升1倍。
num_workers=1时，模型每个阶段运⾏时间统计
此时，查看GPU的性能状态（我的模型是放在1,2,3号卡上训练），发现，虽然GPU(1,2,3)的内存利⽤
率很⾼，基本上为98%，但是利⽤率为0%左右。表⾯此时⽹络在等待从CPU传输数据到GPU，此时CPU疯狂加载数据，⽽GPU处于空闲状态。
1,2,3号GPU的内存占⽤率和计算效率截图
由此可见，CPU的利⽤率不⼀定最⼤才最好。
对于这个问题，解决办法是，增加DataLoader这个num_wokers的个数，主要是增加⼦线程的个数，来分担主线程的数据处理压⼒，多线程协同处理数据和传输数据，不⽤放在⼀个线程⾥负责所有的预处理和传输任务。
我将num_workers=8,16都能取得不错的效果。此时⽤top查看CPU和线程数，如果我设置为num_workers=8，线程数有了8个连续开辟的线程PID，且⼤家的占⽤率都在100%左右，这表明模型的CPU端，是较好的分配了任务，提升数据吞吐效率。效果如下图所
⽰，CPU利⽤率很平均和⾼效，每个线程是发挥了最⼤的性能。
num_workers=8时，CPU利⽤率和8个连续PID任务
此时，在⽤nvidia-smi查看GPU的利⽤率，⼏块GPU都在满负荷，满GPU内存，满GPU利⽤率的处理模型，速度得到巨⼤提升。
优化数据加载num_workers=8，和设置batch size的结果
上图中可以看见，GPU的内存利⽤率最⼤化，此时是将batch size设置的较⼤，占满了GPU的内存，然后将num_workers=8，分配多个⼦线程，且设置pin_memory=True，直接映射数据到GPU的专⽤内存，减少数据传输时间。GPU和CPU的数据瓶颈得到解决。整体性能得到权衡。
此时的运⾏时间在表中做了统计：
处理时间统计
处理阶段时间
数据加载0.25s
模型在GPU计算0.21s
loss反传，参数更新0.43s
4. 总结
对上⾯的分析总结⼀下，第⼀是增加batch size，增加GPU的内存占⽤率，尽量⽤完内存，⽽不要剩⼀半，空的内存给另外的程序⽤，两个任务的效率都会⾮常低。第⼆，在数据加载时候，将num_workers线程数设置稍微⼤⼀点，推荐是8,16等，且开启
pin_memory=True。不要将整个任务放在主进程⾥⾯做，这样消耗CPU，且速度和性能极为低下。
Supplementary：看到⼤家在评论回复的问题⽐较多，所以再加⼀些叙述！
开这么多线程。第⼀个，查看你的数据的batch_size，batchsize⼩了，主CPU直接就加载，处理，⽽且没有分配到多GPU⾥⾯（如果你使⽤的是多GPU）；如果是单GPU，那么就是CPU使劲读数据，加载数据，然后GPU
⼀下就处理完了，你的模型应该是很⼩，或者模型的FLOPs很⼩。检查⼀下模型问题。还有就是，现在这个情况下，开8个线程和1个线程，没什么影响，你开⼀个num_workers都⼀样的。如果速度快，没必要分配到多个num_workers去。当数据量⼤的时候，num_workers设置⼤，会⾮常降低数据加载阶段的耗时。这个主要还是应该配合过程。
在调试过程，命令：top 实时查看你的CPU的进程利⽤率，这个参数对应你的num_workers的设置；
命令： watch -n 0.5 nvidia-smi 每0.5秒刷新并显⽰显卡设置。
酬金实时查看你的GPU的使⽤情况，这是GPU的设置相关。这两个配合好。包括batch_size的设置。
时间：2019年9⽉20⽇
5. 再次补充内容
有很多⽹友都在讨论⼀些问题，有时候，我们除了排查代码，每个模块的处理信息之外，其实还可以查⼀下，你的内存卡，是插到哪⼀块插槽的。这个插槽的位置，也⾮常影响代码在GPU上运⾏的效率。
⼤家除了看我上⾯的⼀些⼩的建议之外，评论⾥⾯也有很多有⽤的信息。遇到各⾃问题的⽹友们，把他们的不同情况，都描述和讨论了⼀下，经过交流，⼤家给出了各⾃在训练中，CPU，GPU效率问题的⼀些新的发现和解决问题的⽅法。
针对下⾯的问题，给出⼀点补充说明：
问题1： CPU忙碌，GPU清闲。
数据的预处理，和加载到GPU的内存⾥⾯，花费时间。平衡⼀下batch size, num_workers。power level
问题2：CPU利⽤率低，GPU跑起来，利⽤率浮动，先增加，然后降低，然后等待，CPU也是浮动。
2.1 下⾯是具体的步骤和对策：
在pytorch训练模型时出现以下情况， 情况描述： ⾸先环境：2080Ti + I7-10700K， torch1.6, cuda10.2, 驱动440 参数设置：shuffle=True, num_workers=8, pin_memory=True; 现象1：该代码在另外⼀台电脑上，可以将GPU利⽤率稳定在96%左右 现象2：在个⼈电脑上，CPU利⽤率⽐较低，导致数据加载慢，GPU利⽤率浮动，训练慢约4倍；有意思的是，偶然开始训练时，CPU利⽤率⾼，可以让GPU跑起来，但仅仅⼏分钟，CPU利⽤率降下来就上不去了，⼜回到蜗⽜速度。
可以采⽤的⽅法：
两边的配置都⼀样吗。另⼀台电脑和你的电脑。你看整体，好像设置配置有点不同。包括硬件，CPU的核，内存⼤⼩。你对⽐⼀下两台设备。这是第⼀个。第⼆个，还是代码⾥⾯的配置，代码的⾼效性。你⼀来，CPU利⽤率低，你看⼀下每⼀步，卡到哪⾥，哪⾥是瓶颈，什么步骤最耗时。都记录⼀下每⼀个⼤的步骤的耗时，然后在分析。测试了每⼀个⼤的过程的时间，可以看见，耗时在哪⾥。
主要包括，加载数据，前向传播，反向更新，然后下⼀步。
2.2 经过测试之后，第⼆次问题分析：
经过测试，发现本机卡的地⽅在加载图像的地⽅，有时加载10kb左右的图像需要1s以上，导致整个batch数据加载慢！代码应该没有问题，因为在其他电脑能全速跑起来；硬件上，本机的GPU，CPU
都强悍，环境上也看不出差距，唯⼀差在内存16G，其他测试电脑为32G，请问这种现象和内存直接关系⼤吗？
情况分析
最多可能就在这边。你可以直接测试batch size为1情况下的整个计算。或者将batch size 开到不同的设置下。看加载数据，计算之间的差值。最有可能就是在这个load data，读取数据这块。 电脑的运⾏内存16g 32g。其实都已经够了，然后加载到GPU上，GPU 内存能放下，影响不⼤。所以估计是你的内存相对⼩了，导致的问题。试⼀下。
2.3 问题定位，解决⽅法：
这台电脑的内存条插的位置不对，4个插槽的主板，1根内存的时候应该插在第2个插槽（以cpu端参考起），⽽组装电脑的商家不专业，放在了第4个插槽上，影响性能，更换位置后，速度飞起来了！关于插槽详情，有遇到的朋友去⽹上收，⼀⼤堆！
在⾃⼰电脑，或者⾃⼰配的主机上，跑GPU的时候，记得注意查看你⾃⼰的内存卡是插到哪⼀个槽上的。
补充时间：2021年1⽉15⽇
5.1 再次新补充⼀些内容
有⽹友补充了⼀些在执⾏上⾯的问题中遇到的实际问题，附上他的解决⽅法。
使⽤win 10修改num_workers后可能会报错Broken pipe。
解决⽅法：1. 把代码放到if __name__ == "__main__"：下运⾏；或者2.num_workers默认为0即可；或者3. 在Linux进⾏代码运⾏
有⼀些内容需要说明：在Windows下⾯，设置num_threads，除了在做数据加载的时候，设置num_workers，还可以
⽤torch.t_num_threads(4)多线程，单线程，都会⽤多个CPU核，跑多个CPU core的的。只是CPU利⽤率不⾼。你设置8线程，12线程，CPU会在每个核上，都进⾏分配，只是单核的占⽤率，不⼀样。即使设置2线程，在6核12线程的CPU，也会在每个核⼼上，分配计算资源的。只是单核分配的很少。editorial
5.2 关于加速CPU端训练的⽅法（⽆GPU）
在单独的CPU上，做训练，或者做推理，intel CPU提供了OpenMP 和MKL-DNN的加速库。⼀般torch或者TensorFlow都做了这⼀块的优化。可以查看你的pytorch版本，是否⽀持。
_num_threads())
print(torch.__config__.parallel_info())
print(*torch.__config__.show().split("\n"), p="\n")
torch.t_num_threads(8)
_num_threads())
print(torch.__config__.parallel_info())
公司年会发言稿print(*torch.__config__.show().split("\n"), p="\n")
torch.t_num_threads(8)
分析：
智者千虑必有一失
