GPU利用率低？6大瓶颈排查清单：从DataLoader到显存碎片

1. 从显卡在转但利用率只有30%说起如果你正在跑AI训练任务打开nvidia-smi或者nvitop发现GPU利用率长期在20%到50%之间来回跳甚至时不时掉到个位数而训练一个epoch的时间比预期长了三四倍——恭喜你你遇到了AI训练里最经典也最让人抓狂的问题之一GPU利用率低。这个问题的迷惑性在于它不像OOM那样直接报错也不像loss不收敛那样有明确信号。显卡风扇在转、显存占了一大半、进程也没崩但就是不出活。很多人的第一反应是是不是显卡不够好然后去租更贵的卡结果发现换了A100之后利用率还是上不去。这说明瓶颈根本不在GPU本身而在数据供给、CPU预处理、IO、通信、框架配置或者代码逻辑的某一个环节上。我前后在单机多卡、多机多卡、以及单卡微调这几种场景下都踩过这个坑最夸张的一次是8卡A100跑一个视觉任务利用率只有15%排查到最后发现是DataLoader的num_workers设成了0整个数据加载在主进程里串行执行GPU大部分时间在等数据。改完之后利用率直接拉到85%以上训练时间从14小时压到2小时出头。这篇内容就是把这几年排查GPU利用率低的经验整理成一份可复用的清单。我会按先看什么、再看什么、最后看什么的顺序把6个最常见的瓶颈逐个拆开每个瓶颈都给出定位方法、判断依据、修复手段并且解释为什么这么排查。适合正在做AI训练、被利用率问题卡住的工程师和研究者也适合刚配好深度学习环境、想搞清楚为什么我的卡跑不满的新手。提示全文的排查思路基于PyTorch生态为主但大部分原理对TensorFlow、JAX同样适用因为瓶颈的物理本质是一样的。2. 排查前的基线先搞清楚正常长什么样在动手排查之前必须先建立一个基线认知。很多人一看到利用率不是100%就慌其实GPU利用率本身就是一个瞬时采样值波动是正常的。关键是看长期平均值和波动模式。2.1 用nvitop替代nvidia-smi做持续观测nvidia-smi默认是快照式的你敲一次它给你一个瞬间值这个值参考意义有限。我强烈建议用nvitop它能实时刷新还能看到每个进程的GPU占用、显存、以及CPU侧的配合情况。pip install nvitop nvitop跑起来之后你会看到一个动态界面。重点观察三个指标GPU利用率SM占用、显存占用、功耗。如果利用率在30%到90%之间规律性波动通常是数据加载和计算在交替属于正常但可优化的状态如果长期低于30%且功耗也上不去那基本可以确定有硬瓶颈。2.2 判断瓶颈类型计算密集还是IO密集一个快速的判断方法是看功耗。GPU满载时功耗会接近TDP比如A100是400W3090是350W。如果利用率显示50%但功耗只有150W说明GPU根本没在全力计算它在等东西。另一个方法是看CPU利用率。开一个htop在旁边如果训练时CPU某个核心跑满100%而GPU利用率上不去那瓶颈大概率在CPU侧的数据预处理如果CPU也很闲GPU也很闲那可能是IO或者同步等待。我把常见的几种利用率-功耗-CPU组合整理成一张表方便你快速对号入座GPU利用率功耗CPU状态最可能的瓶颈低且波动低单核跑满DataLoader预处理低且平稳低很闲IO读取或网络存储周期性掉0波动周期性忙同步点/梯度allreduce高但吞吐低高正常计算本身或算子效率多卡不均不均正常负载不均衡或通信这张表是我自己排查时最常用的第一层筛选工具能帮你把排查范围从所有可能缩小到两三个方向。2.3 建立可复现的基准测试排查最忌讳的是改一个参数跑一次看结果因为训练本身有随机性你根本分不清是改动生效了还是波动。正确做法是先固定一个小规模基准用固定的随机种子、固定的数据子集比如1000条、跑固定的step数比如200步记录下平均利用率和每步耗时。之后每次改动都跑同一个基准对比数据。# 基准测试的关键固定种子 固定步数 记录耗时 import torch, time torch.manual_seed(42) start time.time() for step, batch in enumerate(loader): if step 200: break # ... training step ... if step % 20 0: torch.cuda.synchronize() # 关键同步后才能准确计时 print(fstep {step}, elapsed {time.time()-start:.2f}s)注意那个torch.cuda.synchronize()不加它的话CUDA是异步执行的你测出来的时间全是假的这是新手最容易犯的计时错误。3. 瓶颈一DataLoader把GPU饿死了这是所有GPU利用率低的问题里出现频率最高的一个没有之一。我粗略估计我遇到的利用率问题里至少一半根因在数据侧。3.1 为什么DataLoader会成为瓶颈GPU的计算速度极快一个batch的前向反向可能只要几十毫秒。但数据从磁盘读出来、解码、做数据增强、转成tensor、再搬到显存这一套流程如果放在主进程里串行做可能要几百毫秒。结果就是GPU算完一个batch后闲着等下一个batch利用率自然上不去。打个比方GPU是一个吃饭极快的人DataLoader是给他夹菜的服务员。如果服务员夹一筷子菜要10秒而这个人吃一口只要1秒那这个人90%的时间都在等菜这就是GPU被饿死。3.2 定位方法看DataLoader耗时占比最直接的定位方式是在训练循环里分别计时。把数据加载时间和计算时间分开统计import time, torch t_data, t_compute 0.0, 0.0 for step, batch in enumerate(loader): t0 time.time() data batch[0].cuda(non_blockingTrue) t1 time.time() # forward backward loss model(data) loss.backward() optimizer.step() optimizer.zero_grad() torch.cuda.synchronize() t2 time.time() t_data t1 - t0 t_compute t2 - t1 if step % 50 0 and step 0: print(fdata: {t_data/step*1000:.1f}ms, compute: {t_compute/step*1000:.1f}ms)如果data时间接近甚至超过compute时间那瓶颈就实锤在数据侧了。正常情况下data时间应该远小于compute时间理想状态是data只占compute的10%到20%。3.3 修复手段num_workers、pin_memory、persistent_workers三件套确认是数据瓶颈后按下面的顺序调参第一把num_workers调大。默认值是0意味着数据加载在主进程里做这是最慢的配置。一般设成CPU物理核心数比如8核CPU设816核设12到16。但也不是越大越好超过物理核心数之后反而会因为进程切换开销导致变慢。loader DataLoader( dataset, batch_size64, num_workers8, # 关键根据CPU核心数调整 pin_memoryTrue, # 关键锁页内存加速H2D拷贝 persistent_workersTrue, # 关键避免每个epoch重建worker prefetch_factor4, # 每个worker预取batch数 shuffleTrue, )第二开启pin_memoryTrue。这个参数让数据放在锁页内存pinned memory里从CPU到GPU的拷贝可以用DMA直接传输速度能快2到3倍。很多人不知道这个参数白白浪费了带宽。第三开启persistent_workersTrue。默认情况下每个epoch结束worker进程会被销毁、下个epoch重新创建这个创建开销在小数据集上可能占掉好几秒。开启后worker常驻省掉反复创建的开销。3.4 数据增强别用CPU硬扛如果做完上面三步利用率还是上不去那问题可能出在数据增强本身太重。比如你用了很复杂的CPU版增强大量PIL操作、随机裁剪旋转色彩抖动单个样本处理就要几十毫秒那再多worker也扛不住。这时候有两个方向一是把增强搬到GPU上做用kornia或者torchvision.transforms.v2的GPU版本二是简化增强把一些非必要的操作去掉。我见过一个项目数据增强里有个特别耗时的弹性形变去掉之后利用率从40%直接到80%而模型精度只掉了0.3个点这笔账怎么算都划算。注意num_workers调大之后如果出现内存暴涨通常是worker里缓存了太多数据检查一下dataset的__getitem__有没有意外的全局缓存。4. 瓶颈二IO和存储把数据管道堵住了DataLoader调优之后如果还是慢下一个要怀疑的就是IO。数据加载的源头是磁盘或网络存储如果源头供不上后面worker再多也是巧妇难为无米之炊。4.1 本地磁盘 vs 网络存储的性能差异先明确一个事实网络存储NFS、对象存储挂载的随机读性能通常比本地NVMe SSD差一到两个数量级。如果你在小数据集上测试没问题一上大规模数据集利用率就崩八成是存储的问题。判断方法很简单用iostat或者iotop看训练时的磁盘读带宽# 每2秒刷新一次看磁盘读速率和IO等待 iostat -x 2 # 或者看具体进程的IO iotop -o如果看到%util接近100%或者await平均等待时间很高说明磁盘已经是瓶颈了。对于大量小文件比如图像分类数据集动辄几十万张小图随机读的性能尤其关键。4.2 小文件问题的三种解法小文件是IO性能的头号杀手。几十万张图片每张几十KB读的时候磁头/闪存要不停寻道效率极低。三种常见解法方案一打包成LMDB或WebDataset格式。把大量小文件合并成少数几个大文件顺序读性能能提升5到10倍。WebDataset的tar分片格式尤其适合流式读取配合webdataset库可以直接替换DataLoader。方案二预先解码缓存。如果数据是图片第一次读的时候解码成numpy数组存到内存或本地SSD后续直接读数组省掉解码开销。代价是占空间但换来的是速度。方案三数据本地化。如果用的是网络存储训练前把数据同步到本地NVMe。这一步虽然要等但一次同步能换来整个训练周期的加速非常值。4.3 一个真实的IO排查案例我之前遇到过一个case8卡训练利用率只有20%DataLoader的num_workers已经调到16了还是没用。用iotop一看磁盘读带宽只有50MB/s而这块NVMe的理论带宽是3GB/s。进一步查发现数据存在一个网络挂载盘上实际走的是千兆网理论带宽上限就125MB/s还要跟其他任务抢。把数据rsync到本地盘之后读带宽直接飙到2GB/s利用率从20%拉到75%。这个案例的教训是排查IO一定要看实际带宽不要假设存储没问题。存储类型顺序读带宽随机读IOPS适合场景本地NVMe3-7 GB/s50万大规模训练首选本地SATA SSD500 MB/s10万中小规模机械硬盘150 MB/s100-200冷数据存储千兆网络存储100 MB/s低不推荐训练用万兆网络存储1 GB/s中可接受5. 瓶颈三CPU预处理和Python GIL的隐形拖累有时候DataLoader的worker也开了、IO也够快但利用率还是上不去。这时候要往更底层看CPU到底在忙什么以及Python的GIL有没有在拖后腿。5.1 用py-spy定位CPU热点py-spy是一个采样型性能分析工具能在不修改代码、不重启进程的情况下看到Python函数级的CPU占用。装好之后直接attach到训练进程pip install py-spy # 找到训练进程PID py-spy top --pid PID # 或者生成火焰图 py-spy record -o profile.svg --pid PID --duration 30跑30秒生成的火焰图能非常直观地告诉你CPU时间花在哪。如果看到大量时间在PIL.Image.open、cv2.resize、或者某个自定义的__getitem__里那优化方向就明确了。5.2 GIL对多线程数据加载的影响Python的GIL全局解释器锁意味着同一时刻只有一个线程能执行Python字节码。如果你用的是num_workers0PyTorch用的是多进程而不是多线程所以GIL影响不大。但如果你在dataset里用了多线程比如自己开了ThreadPool那GIL会让多线程几乎失效。一个常见的坑是在__getitem__里调用了某个内部用多线程的库结果线程之间互相抢GIL反而比单线程还慢。这种情况要么改成多进程要么把那个库换成释放GIL的实现比如numpy的很多操作、OpenCV的cv2函数都会释放GIL。5.3 把预处理搬到GPU上如果CPU预处理确实太重最彻底的解法是搬到GPU。以图像增强为例kornia提供了GPU版的常用增强import kornia.augmentation as K # 定义在GPU上执行的增强管道 aug K.AugmentationSequential( K.RandomHorizontalFlip(p0.5), K.RandomAffine(degrees15, scale(0.9, 1.1)), K.ColorJitter(0.2, 0.2, 0.2, 0.1), data_keys[input], ).cuda() # 在训练循环里数据搬到GPU后再做增强 data batch.cuda(non_blockingTrue) data aug(data)这样CPU只负责最基础的读取和搬运重活全交给GPU。代价是GPU要分出一部分算力做增强但通常这部分开销远小于CPU预处理的时间。实测下来对于增强密集的任务这个改动能让利用率提升20到40个百分点。提示GPU增强会占用显存如果显存本来就紧张要权衡一下。另外增强的随机性要保证可复现记得同步随机种子。6. 瓶颈四多卡通信和同步点的周期性卡顿单卡排查完多卡场景下还有一类特有的瓶颈通信。多卡训练时梯度需要allreduce同步如果通信慢或者负载不均GPU会在同步点周期性等待表现为利用率规律性掉坑。6.1 识别通信瓶颈的特征通信瓶颈的典型特征是利用率呈周期性波动每隔几个step掉一次且掉的时机和同步点吻合。用nvitop观察会看到所有卡的利用率同时掉下去又同时起来像心跳一样。另一个特征是扩展性差。比如单卡每秒处理100个样本理论上8卡应该800但实际只有300扩展效率不到40%那基本可以确定通信或同步有问题。6.2 NCCL环境变量的调优PyTorch多卡通信底层用NCCLNCCL有几个关键环境变量能显著影响性能# 指定通信网卡多网卡时尤其重要 export NCCL_SOCKET_IFNAMEeth0 # 开启P2P和共享内存单机内通信加速 export NCCL_P2P_DISABLE0 export NCCL_SHM_DISABLE0 # 调整buffer大小大模型建议调大 export NCCL_BUFFSIZE8388608 # 开启IB如果有InfiniBand export NCCL_IB_DISABLE0其中NCCL_SOCKET_IFNAME是最容易出问题的。如果机器有多张网卡NCCL可能选了一张慢的比如管理网卡而不是数据网卡通信速度直接差一个数量级。我遇到过一次指定网卡后allreduce时间从200ms降到20ms。6.3 梯度累积和梯度检查点的取舍如果通信确实是瓶颈且短期内无法改善硬件可以用梯度累积来减少同步频率。比如累积4个step再同步一次通信次数降到1/4accum_steps 4 for step, batch in enumerate(loader): loss model(batch) / accum_steps loss.backward() if (step 1) % accum_steps 0: optimizer.step() optimizer.zero_grad()代价是等效batch size变大可能需要调整学习率。另一个手段是梯度检查点gradient checkpointing用计算换显存间接允许更大的batch提高计算密度。但要注意检查点本身会增加计算量如果瓶颈是计算而不是通信反而会变慢。手段减少通信增加计算适用场景梯度累积是否通信瓶颈明显梯度检查点否是显存瓶颈混合精度否略增通用加速大batch相对减少否显存充足7. 瓶颈五算子效率和框架配置的隐性损耗前面四个瓶颈都在数据侧和通信侧但有时候数据和通信都没问题利用率就是上不去这时候要怀疑计算本身——也就是GPU到底在算什么算得高不高效。7.1 混合精度几乎无脑的加速手段torch.cuda.amp自动混合精度能把大部分计算降到FP16在支持Tensor Core的卡上V100、A100、H100、RTX系列能带来2到3倍的速度提升而且精度损失通常很小from torch.cuda.amp import autocast, GradScaler scaler GradScaler() for batch in loader: optimizer.zero_grad() with autocast(dtypetorch.float16): output model(batch) loss criterion(output, target) scaler.scale(loss).backward() scaler.step(optimizer) scaler.update()注意GradScaler是必须的因为FP16的梯度容易下溢scaler会自动调整loss的缩放因子。如果不用scaler直接FP16训练很可能loss变成NaN。7.2 算子融合和torch.compilePyTorch 2.0引入的torch.compile能把模型图编译优化自动做算子融合减少kernel启动开销和显存访问model torch.compile(model, modemax-autotune)max-autotune模式会花较长时间编译但运行时性能最好。实测在Transformer类模型上通常有20%到50%的加速。不过要注意首次编译有开销且不是所有模型都能顺利编译遇到报错可以退回modedefault。7.3 排查算子效率用profiler看kernel时间如果怀疑某个算子在拖后腿用PyTorch自带的profilerfrom torch.profiler import profile, ProfilerActivity with profile(activities[ProfilerActivity.CUDA]) as prof: for _ in range(10): model(batch) print(prof.key_averages().table(sort_bycuda_time_total, row_limit20))输出会按CUDA时间排序告诉你哪些kernel最耗时。如果看到某个自定义算子或者某个奇怪的reshape/transpose占了大量时间那就是优化目标。常见的低效算子包括频繁的.cpu()调用、不必要的.contiguous()、以及小kernel过多导致的启动开销。注意profiler本身有开销测出来的绝对时间会偏大但相对占比是准的用它来定位热点没问题。8. 瓶颈六显存碎片和OOM边缘的反复重试最后一个瓶颈比较隐蔽显存。显存不足本身会OOM报错但显存碎片化不会报错它会让PyTorch反复尝试分配、释放、整理表现为利用率忽高忽低、训练速度不稳定。8.1 显存碎片的识别用torch.cuda.memory_summary()能看到显存的分配情况print(torch.cuda.memory_summary(device0, abbreviatedFalse))重点看reserved和allocated的差值。如果reserved远大于allocated比如reserved 40GB但allocated只有25GB说明有大量碎片被缓存着没法用。这时候可以调PYTORCH_CUDA_ALLOC_CONFexport PYTORCH_CUDA_ALLOC_CONFexpandable_segments:Trueexpandable_segments让PyTorch用可扩展的显存段能显著减少碎片。这个配置在长训练任务里尤其有用我基本是默认开着的。8.2 batch size的甜点区batch size不是越大越好。太小的batch GPU吃不满太大的batch可能触发显存整理甚至OOM。找到甜点区的方法是从当前batch开始每次翻倍观察利用率和每样本耗时。当利用率不再提升、或者每样本耗时开始上升时就过了甜点区。一般来说甜点区在GPU利用率达到85%到95%、显存占用70%到85%之间。留一点显存余量给碎片和峰值比把显存榨干要稳。8.3 动态batch和梯度累积的组合如果显存实在有限可以用小batch加梯度累积来模拟大batch。这样既不会OOM又能保持等效的大batch训练效果。关键是累积步数要和batch size配合保持等效batch size不变# 目标等效batch 256但显存只够64 micro_batch 64 accum_steps 256 // micro_batch # 4这样每4个micro step做一次optimizer step等效batch就是256。注意BatchNorm这类对batch size敏感的层小batch下统计量会不准可以考虑换成GroupNorm或者SyncBatchNorm。9. 一份可以直接照着跑的排查清单把上面六个瓶颈的排查逻辑串起来形成一份从上到下的清单。建议按顺序执行因为前面的瓶颈不解决后面的优化效果会被掩盖。第一步建立基线用nvitop持续观测记录平均利用率和功耗固定种子和步数跑一个200步的基准记录每步耗时用torch.cuda.synchronize()保证计时准确第二步数据侧排查分别计时data和compute看data占比是否超过20%num_workers设为CPU物理核心数开pin_memory和persistent_workers用iotop看磁盘读带宽是否打满小文件考虑打包成LMDB或WebDataset用py-spy看CPU热点重增强考虑搬到GPU第三步通信侧排查多卡看利用率是否周期性掉坑检查NCCL_SOCKET_IFNAME是否指定了正确的网卡算扩展效率低于60%考虑梯度累积第四步计算侧排查开启混合精度amp尝试torch.compile用profiler看kernel时间分布第五步显存侧排查看reserved和allocated的差值开启expandable_segments找batch size甜点区必要时梯度累积第六步验证每次改动后重跑基准对比数据记录每次改动的收益避免负优化这份清单我用了两年多基本覆盖了90%以上的利用率问题。剩下的10%通常是硬件故障比如某张卡降频或者框架bug那种情况就得看dmesg和驱动日志了。10. 几个我踩过的坑和私藏技巧最后分享几个清单之外的实战经验都是文档里不会写、但实际排查时特别有用的。坑一nvidia-smi的利用率会骗人。它显示的utilization是过去一段时间内有kernel在跑的时间占比哪怕kernel很小、GPU大部分单元闲着它也可能显示100%。所以看到100%不代表真的跑满了要结合功耗和实际吞吐一起看。真正靠谱的指标是sm__throughput这类硬件计数器但那个要nsight才能看。坑二多进程DataLoader的worker会继承父进程的随机状态。如果你在dataset里用了随机数做增强不设置worker的种子每个worker会生成相同的随机序列导致增强多样性下降。正确做法是在worker_init_fn里给每个worker设不同的种子def worker_init_fn(worker_id): np.random.seed(torch.initial_seed() % 2**32 worker_id) loader DataLoader(..., worker_init_fnworker_init_fn)坑三torch.cuda.synchronize()会掩盖异步带来的性能。排查时为了准确计时加同步是对的但正式训练时不要在每个step都同步否则会破坏CUDA的异步流水线反而变慢。只在需要精确计时的基准测试里加。技巧一用nvtop或nvitop的进程视图定位多进程问题。多卡训练时如果有某个进程异常nvitop能直接看到是哪个PID在占卡配合py-spy能快速定位到具体代码。技巧二把排查过程脚本化。我写了一个bench.py接受不同的配置参数num_workers、batch_size、amp开关自动跑基准并输出对比表格。这样每次调参不用手动改代码效率高很多。技巧三关注GPU频率。有时候利用率上不去是因为GPU降频了用nvidia-smi -q -d CLOCK看当前频率是否接近最大频率。降频通常是散热问题或者功耗墙机房温度高的时候尤其明显。这套排查方法的核心逻辑其实就一句话GPU利用率低本质是GPU在等某个东西找到它在等什么问题就解决了一半。数据、IO、CPU、通信、计算、显存六个方向逐个排除总能找到那个拖后腿的环节。