PyTorch DataLoader性能优化：从根源解决GPU利用率低下的问题

我经常遇到这样的训练场景：模型已经能跑起来了，loss 也在正常下降，但看一眼 GPU 利用率只有 40%~60%，显卡风扇半天不转一下，本来两个小时的训练任务硬生生被拖到三四个小时。多数人第一反应是 batch size 太小或模型太浅，于是把 batch 调大、把网络加宽，结果利用率还是上不去。这类问题我排查下来，十次里有七八次的根子都出在 PyTorch DataLoader 上——数据加载的速度跟不上 GPU 消耗的速度。

这篇文章专门写给正在被“GPU 利用率低”困扰的同学。目标是教你用最短路径确认瓶颈是不是在 DataLoader，然后从参数调整、数据处理到特殊情况（比如 WSL 环境、AMD 显卡）一层层把数据管道压榨出来。文章不堆理论，全是能直接复制、照着做的排查方式和实操经验，适合已经会用 PyTorch 写训练脚本、但遇到性能问题时不知道从哪下手的读者。

1. 先分辨清楚：GPU 利用率低究竟是模型问题还是数据没跟上

排查性能问题最忌讳的是一上来就调参。很多人改了一通 num_workers、prefetch_factor，GPU 还是老样子，白白浪费时间。正确做法是先判断问题到底出在哪一层：是模型本身算不动，还是 GPU 一直在等数据。

1.1 不同症状对应不同瓶颈

先对照一下你看到的“低”是哪种形态，这决定了后续排查方向完全不一样。

上面表格里最容易被误判的是第一种锯齿状波动。GPU 在某个瞬间被喂饱了，在下一个瞬间又饿着，反映到监控面板上就是一个上下抖动的曲线。很多人觉得“平均值还有 60%，还行”，但实际训练时间的浪费远比直观感觉严重，因为空闲出来的算力是全白的。

1.2 三步区分“喂不饱”还是“算不动”

我有一套固定流程，几分钟就能把问题归类，不需要一上来就上 profiling 工具。

第一步：把同一个 batch 固定住，循环训练它几十次。具体做法是先把一个 batch 的数据取出来，然后在一个 for 循环里反复对这个固定 tensor 做前向和反向。如果这时 GPU 利用率能跑到 95% 以上，说明模型、优化器、GPU 计算路径本身完全没问题，问题一定出在“每次取新数据”这条路上。如果固定 batch 后利用率依然低，那才要考虑模型结构或训练逻辑本身的问题。

第二步：写一个脚本空转 DataLoader，只遍历不训练。测一下平均生产一个 batch 需要多长时间。这一步会给出一个非常干净的指标：DataLoader 本身到底有多慢。

第三步：把两个时间放一起对比。如果 DataLoader 单 batch 耗时占训练单 step 耗时的 40% 以上，基本可以锁定瓶颈在数据加载。

这个简单的对比能避免一个常见误区：有人发现 GPU 利用率低，就断言是“数据集太大”或“模型太小”，实际上两者都不是，问题只是数据管道的某一环堵住了而已。

1.3 别急着上高级工具

我见过很多同学一上来就装各种可视化 profiling 工具，花一天搭环境，最后连问题在哪都没搞清楚。个人经验是先用手写 for 循环和 print 做验证，把“是不是 DataLoader”这个问题回答了，再考虑要不要用 torch.profiler 或 nvidia-smi dmon 深入定位。工具是辅助，不是起点。把时间浪费在攒工具上，是排查性能问题最典型的低效行为。

2. 拆开 DataLoader 看流水线：瓶颈集中在这四段

要理解为什么 DataLoader 会成为 GPU 利用率的瓶颈，得先知道一个 batch 从硬盘到显卡到底要过几道关卡。大多数人只知道num_workers=8这个参数，却不清楚每个 worker 到底在干什么，所以出了问题也没法定位。

2.1 一个 batch 从硬盘到显卡的完整链路

PyTorch DataLoader 的工作流程大致可以分为四段：

1. 主进程在每轮 epoch 开始时生成一份索引序列，并根据shuffle设置打乱顺序。如果有Sampler，这里还会涉及权重采样逻辑。
2. 每个 worker 子进程按索引去磁盘读取对应的样本文件，做完dataset.__getitem__里定义的处理（比如读取图像、解码、Resize、数据增强），返回一个或多个样本。
3. worker 把处理好的单个样本放进一块共享内存队列。这个队列是 worker 与主进程之间的传输通道。
4. 主进程的某个线程负责从队列里取出一整个 batch 的样本，调用collate_fn把它们堆叠成带 batch 维度的张量，然后这个 batch 才会被 GPU 复制走参与训练。

注意一个关键点：__getitem__是在 worker 子进程里并发执行的，但collate_fn默认在主进程里执行。所以哪怕你把 worker 数量调到 32，最后一步仍然是在主进程的 CPU 上完成的。

我见过的最典型卡点就出现在这四段里。第一段 shuffle 本身开销不大，不值得优化；第二段如果在线做数据增强，往往占总耗时的一半以上；第三段如果队列太小，worker 生产速度再快也会被堵住，但多数人不会意识到 prefetch 队列也是要调的；第四段 collate 里的内存拷贝更是藏着大量无效操作，后面我会专门展开。

2.2 为什么“CPU 没满但 GPU 闲”也常见

很多人遇到 GPU 利用率低时，会习惯性地用htop看一眼 CPU。如果发现 CPU 使用率只有 40%，就会认为“既然 CPU 没满，问题应该不在数据”。这是个误区。

CPU 没满不代表数据管道通畅。数据加载链路里很多环节是串行的，比如主进程的 collate、磁盘 IO 等待、锁等待。这种情况下只有某一个核或某几个核在忙，其他核都闲着，CPU 整体占用率当然不高。再比如单线程读取 HDD 上的数万张小图，IO 等待期间进程处于睡眠状态，CPU 占用率几乎为零，但 GPU 就是在干等。

拿水管打比方：CPU 就像多个水龙头，磁盘 IO 和 collate 像是把多个龙头汇聚到一根主管道里的阀门。阀门只有一个，龙头再多也会被阀门卡住。所以在排查时，不能只看 CPU 平均占用率，还要看单个进程的 CPU 状态和 IO 等待。

2.3 三个被低估的耗时点

无论数据管道表现如何，有几个地方是普遍容易出问题的，先列出来供参考，后面章节会给出具体操作。

一是每个 epoch 重建索引和打乱顺序。对大规模数据集来说，打乱本来不贵，但如果你的数据是顺序存储的大文件（比如 HDF5、WebDataset），shuffle 会破坏空间局部性，让后面的随机读取变成大量随机跳转，IO 效率变得很糟。

二是大量小文件 IO。假设数据集有五万张 JPEG，每张 200KB，那么一次 epoch 就要打开五万次文件。每次打开文件都要经过路径解析、inode 查找、权限检查，系统调用开销远大于实际读字节的开销。几万次小读加在一起，比连续读十几个大文件慢一个数量级。

三是 collate_fn 的默认组装过程。默认 collate 会把PIL.Image或numpy.ndarray逐个转成torch.Tensor，再一个个torch.stack。样本量一大，这种粒度极小的 Python 循环就会成为隐藏的 CPU 密集区。很多时候问题不在__getitem__，而在这一步。

3. 诊断实操：用这两分钟证明“瓶颈在 DataLoader”

前面说了这么多原理，现在进入实操环节。我给出一套我每次排查都会先跑一遍的流程，全程不需要装任何额外工具，PyTorch 自带和系统自带的东西就够用。

3.1 先写一个空转遍历脚本

这是第一步，先测 DataLoader 本身的裸吞吐量。脚本很简单，就是把训练循环里的模型前向和反向全部拿掉，只遍历 batch。

import time import torch from torch.utils.data import DataLoader # 假设 train_dataset 已经定义好 loader = DataLoader( train_dataset, batch_size=64, num_workers=8, pin_memory=True, ) start = time.perf_counter() total_samples = 0 for i, batch in enumerate(loader): total_samples += batch[0].shape[0] if i >= 200: break elapsed = time.perf_counter() - start print(f"DataLoader 单批平均耗时: {elapsed / (i + 1) * 1000:.2f} ms") print(f"吞吐量: {total_samples / elapsed:.1f} samples/s")

这段代码会给你两个定量指标：单批耗时和吞吐量。接下来把它和你的训练脚本对比。

假设你的训练脚本里一个 step（前向 + 反向 + 参数更新）需要 120ms，而这个空转 DataLoader 跑一个 batch 需要 80ms，那么数据加载已经占了训练耗时的三分之二，这个比例下 GPU 利用率不可能高。如果空转只需要 20ms，那你就要去别的地方找原因了，比如模型本身太复杂或者 batch 太小导致单步计算时间过短、GPU kernel 启动开销占比过大。

要注意，空转脚本没有.cuda()和模型计算，所以它的时间严格来说是“纯数据准备时间”的下限。真实训练中数据准备耗时只会比这个更高。如果连下限都这么高，那就没什么好怀疑的了。

3.2 用 torch.profiler 看 CPU 侧与 GPU 侧的时间占比

空转脚本能判断大方向，但要精确定位 DataLoader 内部哪一步最慢，就要用torch.profiler。

from torch.profiler import profile, ProfilerActivity with profile(activities=[ProfilerActivity.CPU, ProfilerActivity.CUDA]) as prof: for step, batch in enumerate(loader): data = batch[0].cuda() # 在这里插入模型前向和反向 # output = model(data) # loss = criterion(output, target) # loss.backward() if step >= 10: break print(prof.key_averages().table(sort_by="cpu_time_total", row_limit=15))

跑完之后看两个维度。第一个是cpu_time_total前几名的操作里，有没有大量 DataLoader 内部的函数，比如collate、__getitem__、DataLoaderIter之类。第二个是 CPU 总耗时和 GPU 总耗时的比例，如果self_cpu_time_total明显高于self_cuda_time_total，就说明每一步 GPU 都在等 CPU 先干完活。

我个人的经验是，很多次用 profiler 一眼就看到collate相关的操作占了 CPU 时间的大头，那种情况下基本不用再猜，直接去改 collate_fn 就行。

3.3 用 nvidia-smi dmon 观察波动形态

nvidia-smi默认显示的利用率只有当前采样瞬间的某个值，看不出时间维度的规律。想看到每个 batch 随时间变化的过程，用dmon模式更合适。

nvidia-smi dmon -s puc -d 1

-s puc是监控电源、利用率、计算资源三类信息，-d 1表示每秒采样一次。输出里最需要关注的是sm字段，它表示流处理器的利用率。

如果sm一会儿 90 一会儿 20，而且波动周期恰好和你的训练 step 周期一致，那么说明每个 step 开始时 GPU 都在等数据，数据准备好了之后才瞬间冲上去算，算完又继续等。这个“锯齿波”就是 DataLoader 供不上货的典型特征。如果sm稳定在一个偏低的值，比如 35，那可能是持续供给不足，也可能是模型本身瓶颈。

还有一个值得留意的字段是pwr，可以观察功率变化是否跟着利用率一起波动。如果没有跟着波动，说明 GPU 大多数时间是在休眠，而不是在计算。

3.4 其他辅助系统检查

最后再补两个不起眼但很有用的检查。

一个是看 worker 进程到底在不在干活。跑训练时另开一个终端执行：

htop

然后按进程数量排序，看有没有多个 python worker 进程。如果设置了 8 个 worker，但只有 1~2 个进程在消耗 CPU，那就说明 worker 之间不太可能是并行工作的，大概率是在等某个共享资源，比如磁盘 IO、锁或者队列。

另一个是确认磁盘 IO 状态。Linux 下可以用iostat -x 1看%util和await，如果磁盘队列持续很高，而 GPU 利用率低，那瓶颈就非常明确了。Windows/WSL 环境下的检查方式稍有些不同，我会在第 6 章案例里专门讲。

4. 参数篇：这几个配置先改，能解决七成数据加载卡顿

如果诊断之后确认瓶颈在 DataLoader，接下来先不要重构代码，先从参数入手。PyTorch DataLoader 的几个核心参数组合对了，大部分项目的卡顿问题能直接解决。

4.1 num_workers：按核数分配，而不是越大越爽

num_workers决定创建多少个子进程来并行执行__getitem__。直觉上 workers 越多并行度越高，但实际不是这么简单。

每个 worker 都是一个完整的 Python 进程，有自己的 GIL 和内存空间。如果 worker 数量超过了 CPU 物理核心数，超出来的部分不会真的并行执行，只会排队抢 CPU 时间片，反而增加上下文切换开销。如果设置得过高，还会触发内存瓶颈，因为每个 worker 都要复制一份数据集的 Python 对象引用和内部缓存。

我的建议是：先设为 CPU 物理核心数的一半到三分之二。比如 8 核的机器可以先设 4~6，然后用前面空转脚本测试不同 worker 数量下的吞吐量变化。我实际测过的项目里，worker 从 1 升到 4 时吞吐量提升非常明显，从 4 升到 8 时提升变得很小，从 8 升到 16 时甚至可能下降。找到那个“再多加也没什么提升”的临界点，就停在那个值。

4.2 pin_memory=True 到底做了什么

pin_memory=True的意思是：在 CPU 侧分配“锁页内存”，也就是物理内存中固定位置、不允许被换出到磁盘的内存块。

为什么这很重要？普通内存页可能被操作系统随时换出，GPU 要从 CPU 拿数据时，无法直接 DMA 拷贝，必须先经过一次 CPU 的“锁页”操作，把数据搬到固定内存里，再拷到显存。锁页内存省掉了中间这一步，H2D 拷贝走更快的通道，而且可以和计算重叠。

一句话结论：如果你的数据最终要.cuda()进入 GPU，pin_memory=True几乎总该开着。但有两个例外要注意。

一是 WSL2 环境下，尤其是 AMD 显卡走 ROCm 驱动的组合，pin_memory 可能反而引入稳定性问题，表现为训练随机卡死或 worker 崩溃。我在第 6 章的案例三会详细说。

二是如果你的num_workers已经很大，每个 worker 都在分配锁页内存，可能会导致内存碎片化或超出系统允许的锁页内存上限。遇到这种情况，要么减少 worker 数，要么在系统层调一下锁页内存限制。

4.3 persistent_workers=True：小 epoch 数据的救星

每个 epoch 结束时，DataLoader 默认会把所有 worker 子进程销毁，下一个 epoch 从头再 fork 一批。销毁、重建涉及到 Python 进程的初始化、模块重新加载、内存重新分配，这个过程并不便宜。

如果数据集很小，一个 epoch 只需要几十个 step，那么重开 worker 的成本可能占到总训练时间的可观比例。你会发现 GPU 利用率在每个 epoch 的开头会有一次明显的掉坑，训练越快越明显。这个问题的修复方式简单到不可思议：加一个参数就行。

persistent_workers=True

加了之后，worker 会在 epoch 间存活，省掉反复 fork 的开销。注意这个参数要求num_workers大于 0，它还会影响数据集内部随机状态的延续方式，如果你的训练脚本里依赖每个 epoch 重新洗牌，建议在worker_init_fn里显式设置随机种子，确保每个 epoch 的随机效果符合预期。

4.4 prefetch_factor：让队列提前装满

默认情况下，prefetch_factor是 2，意思是每个 worker 最多预加载 2 个 batch 的数据。如果单 batch 处理时间比较长，或数据生产速度不稳定，这个默认值很容易让队列在训练过程中突然饿掉。

把prefetch_factor调大到 4 或 6，可以让 worker 更早地把数据准备好，GPU 拿到 batch 后马上有下一个等着。这会多占用一些内存，但通常物超所值。

我在显存 24GB、内存 64GB 的机器上常用 4；如果内存充足且单 batch 处理耗时在几百毫秒以上，我会提升到 6 或 8。不过要记住，这个值调高并不会单方面提升吞吐，它只是让队列更有余量，真正的瓶颈还在数据生产速度本身。

4.5 collate_fn 别再做“重活”

默认的 collate_fn 会把一个个 PIL Image 转为 Tensor 并堆叠起来。如果你的__getitem__返回的是已经转好的同尺寸 Tensor，那默认流程还说得过去；但如果你在__getitem__里返回 PIL Image 或 ndarray，那么 collate 阶段就会发生大量重复转换和内存拷贝。

一个典型的“collate 重活”场景是：每个样本都是一个 HWC 的 ndarray，collate 时要先np.asarray再torch.from_numpy再torch.stack，最后还要做维度转置。这些操作全在主进程串行执行，且每一步都会产生临时对象，内存分配和释放次数多到吓人。

我常用的快速写法是把转换前移到__getitem__，collate 里只做堆叠：

def collate_fn(batch): images = torch.stack([item[0] for item in batch]) labels = torch.tensor([item[1] for item in batch]) return images, labels

前提是__getitem__返回的 image 已经是统一尺寸的torch.Tensor。如果还有一些尺寸需要处理，那就用 resize 后的 Tensor 返回，不要在 collate 里统一处理。

这样改完，CPU 侧的 collate 耗时通常会肉眼可见地降下去，有时候仅这一处优化就能让 GPU 利用率提高二三十个百分点。

4.6 一个可以直接抄的通用配置

在我这边测过的大多数常规训练任务里，下面这套配置是一个很稳的起步点：

train_loader = DataLoader( train_dataset, batch_size=64, num_workers=4, # 按你的 CPU 物理核数调整 pin_memory=True, persistent_workers=True, prefetch_factor=4, drop_last=True, # 训练阶段建议丢弃末尾不足 batch 的部分 )

注意drop_last=True只在你不介意外面有一批不完整样本时用，验证集上一般不建议设置，因为评估时通常要保留全部样本。这套配置不是万能的，但它能覆盖大部分“默认设置下 GPU 利用率稀碎”的场景。

5. 压榨数据通道：预处理前移、缓存命中与存储介质选择

参数调完之后，如果 GPU 利用率还是不够，就要开始动数据管道的结构了。这个阶段的核心思路是：能离线做的操作不做在线做，能缓存的反复读不做重复读，能连续读的不随机跳。

5.1 预处理前移：把能离线做的都离线做

一个常见的误区是：把所有数据预处理都丢进__getitem__里，感觉这样“灵活”。比如每次训练迭代都做“读原图 → PIL 转 RGB → resize → 归一化 → 转 ndarray → 转 Tensor”。问题是，Resize 和归一化对同一张图来说每次得到的结果都是确定的，为什么要重复算几千次？

正确做法是把这些确定性操作提前到数据准备阶段。具体可以写一个离线脚本，把原图统一 Resize 到某个尺寸，存成 numpy 或 tensor 文件。训练时的__getitem__只需要做两件事:从文件读入预处理好后的数据，然后做必须在线完成的随机增强（随机裁剪、翻转、颜色扰动）。

例如，目标输入尺寸是 224x224，可以先把所有图 Resize 到 256x256 并存成.npy，训练时只做随机裁剪。这样一次迭代里省的不仅是 Resize 的 CPU 时间，还省了原始图像解码的时间。图像解码（JPEG/PNG）在 CPU 上的开销往往被低估，提前转换之后这部分就完全消失。

5.2 把数据缓存到内存：暴力但有效

如果数据集总大小小于物理内存，最有效的优化是把整个数据集加载到内存里，每个 epoch 直接读内存而不是读磁盘。

实现一个带缓存的 Dataset 并不复杂：

import os import torch import psutil from torch.utils.data import Dataset class CachedDataset(Dataset): def __init__(self, file_list, transform=None): self.file_list = file_list self.transform = transform self.cache = {} self.memory_limit = psutil.virtual_memory().available * 0.6 def __len__(self): return len(self.file_list) def __getitem__(self, idx): if idx in self.cache: sample = self.cache[idx] else: sample = torch.load(self.file_list[idx]) # 控制缓存内存上限，防止把整台机器吃满 if psutil.Process().memory_info().rss < self.memory_limit: self.cache[idx] = sample if self.transform: sample = self.transform(sample) return sample

这里我在缓存写入前做了一个内存判断，用的是psutil检查当前进程内存占用。别小看这个检查，数据增强或数据格式不同会让单样本内存大小差异很大，不加限制的话很容易在不知不觉中把内存吃满，然后就是 Linux 的 OOM Killer 出来删进程了。

缓存对num_workers的配合也很重要：多个 worker 进程会各自持有一份缓存副本，内存占用会乘以 worker 数。如果内存足够，这个方案能把数据加载耗时压到极低；如果内存不足，就只缓存一部分最常用的样本，或者干脆放弃缓存，转而把数据放到更快的存储上。

5.3 存储介质和文件组织：小文件是隐形杀手

做了在线缓存之后，下一个常见瓶颈是存储介质和文件访问模式。

如果你的项目数据是散落在几百个目录里的几万张 JPG，即便在 SSD 上，每次迭代都随机打开一个新文件，系统也需要做路径解析和 inode 查找。这个问题在 HDD 上更严重，随机 IO 的速度比顺序 IO 慢两个数量级。

我有两个比较实用的建议：

第一，数据尽量放在 SSD 上。第二，把大量小文件打包成一个大文件。常见的做法有 WebDataset、HDF5，或者直接把图片缩到统一尺寸后存成一个大.npy文件。大文件的好处是可以顺序读，文件系统缓存命中率大幅提高，worker 访问时只需要在固定偏移量上读取。

但大文件方案和 shuffle 有个矛盾：shuffle 会导致随机 offset 访问，重新变成随机 IO。折中方案是先把大文件按顺序读入内存或页缓存，然后用内存中的索引配合随机 offset 访问。这样第一次从头到尾读一遍，之后的随机访问实际上都落在页缓存上，性能比直接随机读磁盘好得多。

还有一个 WSL 专属的坑要特别说：不要直接在 WSL2 里读取 Windows 挂载盘上的训练数据，也就是/mnt/c、/mnt/d这些路径。WSL2 访问 Windows 文件系统走的是 9P 协议，涉及内核态和用户态来回切换，IO 性能比原生 Linux 文件系统低很多，小文件场景下差距更吓人。数据放到 WSL2 自己的虚拟磁盘里，比如~/data，能明显改善。

5.4 要不要上 DALI 这类重型增强库

如果你把前面几步都做完了，GPU 利用率还是上不去，而且明显卡在数据增强部分，比如 RandomCrop、ColorJitter、Cutout 这类操作占用了大量 CPU 计算，那可以考虑上 NVIDA DALI 这类 GPU 端增强库。

但我个人建议先不要一上来就换。DALI 的引入意味着改变数据加载管线的 API 风格、需要重新实现一部分增强逻辑、还要处理不同增强库之间的细微差异。对大部分项目来说，先把原生 PyTorch 的参数和预处理前移做完，通常已经能拿到 50%~80% 的提升。如果还不够，再评估 DALI 带来的收益是否值得额外维护成本。

我见过不少人读了技术博客后直接换 DALI，结果增强行为不一致导致实验结果对不上了，又花很长时间去复现原逻辑，属于典型的用复杂度换性能。先易后难，永远是排查性能问题的第一原则。

6. 三个真实案例：你遇到的“掉坑”我基本都蹲过

这一章我挑三个真实场景，记录当时完整的排查链路和结果，方便你对照自己的情况。每个案例的处理思路都会覆盖出现过的现象、诊断过程、确认根因和最终修复。

6.1 案例一：collate_fn 里的“隐形翻译官”

背景是一个图像分类项目，训练集是 SSD 上的几万张 JPG，网络是 ResNet 系列，显卡是 3090。数据量不算夸张，但 GPU 利用率一直稳定在 55% 左右，怎么调 batch size 都没用。

我先是跑了空转 DataLoader 的脚本，发现单 batch 耗时约 55ms，而训练单 step 约 95ms，数据加载占比接近 58%。继续用 torch.profiler 排查，发现 CPU 时间榜首不是__getitem__，而是 collate 操作。

打开数据集代码才发现，__getitem__返回的是 HWC 的np.ndarray，于是默认 collate 里就开始“翻译”：先np.asarray转成数组，再torch.from_numpy转 Tensor，又一次次去torch.stack，最后还要做 numpy 和 tensor 之间的多次内存拷贝。样本量为 64 的 batch，每一步都产生大量临时对象，主进程 CPU 光忙这些了。

修复方式就是前移转换：让__getitem__直接返回 CHW 的torch.Tensor，collate 只保留一行torch.stack。改完再测，DataLoader 单 batch 从 55ms 降到 18ms，GPU 利用率到了 85%~92%。整个过程没加任何依赖，纯粹是消除重复劳动。

这个案例给我最大的体会是：collate_fn 默认逻辑看起来很省事，但对自定义数据集来说往往是最容易被忽略的隐性瓶颈，闲下来时值得专门打开 profiler 看一次。

6.2 案例二：persistent_workers 缺位让每个 epoch 开头“卡嗓子”

背景是另一个项目，数据集不大，约三千张图，每个 epoch 只有几十个 step，但 epoch 数量很多，训练要跑几百轮。现象是 GPU 利用率在每轮 epoch 开头的五六步会掉到 20% 左右，之后回升到 90%。

先用 nvidia-smi dmon 观察，发现利用率曲线是规律的周期性塌陷，塌陷周期刚好等于一个 epoch 的长度。定位思路立刻就清楚了：epoch 结束时 DataLoader 会把所有 worker 销毁，下一个 epoch 开始重新 fork 进程。每次 fork 都要重新初始化 Python 环境、加载数据集对象、分配内存，这个成本在“epoch 很短”的场景里显得特别刺眼。

修复就是给 DataLoader 加上了persistent_workers=True。改动前后对比，GPU 利用率周期性的“卡嗓子”现象消失，整个训练时间缩短了约 20%。

如果你也遇到类似的周期性掉坑，可以先数一下掉坑的间隔时间：如果间隔和 epoch 长度一致，第一优先检查的就是有没有开persistent_workers。

6.3 案例三：WSL2 + AMD 显卡下 DataLoader 的神秘“假死”

最后一个案例比较特别，来自 WSL2 加 AMD 显卡的组合。朋友的机器配置是 AMD 7900 XTX，PyTorch 走 ROCm 驱动，数据放在 Windows 的 D 盘，通过/mnt/d挂载进 WSL2 访问。

现象是训练刚启动时 GPU 利用率就很低，而且程序会随机卡死。卡死时终端偶发报错：DataLoader worker (pid xxx) is killed by signal: Bus error。这个错误在原生 Linux + CUDA 环境里我非常少见，但在 WSL2 + ROCm 的组合下反复出现。

排查过程是从减参数开始的。先把num_workers从 8 降到 2，卡死概率明显下降；然后关闭pin_memory=True，卡死问题彻底不再复现。之后又把数据从/mnt/d挪到了 WSL2 的~/data目录下，GPU 利用率明显回升。

这个案例最终确认了两个问题：一是 WSL2 访问 Windows 挂载盘的 9P 协议 IO 开销大，也就是我之前说的/mnt路径问题；二是 ROCm 驱动在 WSL2 环境下对锁页内存和大量 worker 进程的配合并不如 CUDA 在原生 Linux 下那么稳定，pin_memory=True加多 worker 的组合在这种虚拟化环境下会触发资源异常。

最后的稳定配置是num_workers=2~4、pin_memory=False、persistent_workers=True，数据放在 WSL2 自己的文件系统里。如果后续升级了 ROCm 或 PyTorch 版本，可以再逐步往上调参数，一点点试验临界点。

遇到这类环境相关的问题，我的经验是先给参数做减法：把 pin_memory 关掉、把 worker 数降到最低，先让程序稳定跑通，再一项项加回去，比一次性照抄满配更容易找到临界点。WSL 和 AMD 这条路线本来就没有特别多现成案例，稳妥优先永远是第一位的。