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

我经常遇到这样的训练场景模型已经能跑起来了loss 也在正常下降但看一眼 GPU 利用率只有 40%~60%显卡风扇半天不转一下本来两个小时的训练任务硬生生被拖到三四个小时。多数人第一反应是 batch size 太小或模型太浅于是把 batch 调大、把网络加宽结果利用率还是上不去。这类问题我排查下来十次里有七八次的根子都出在 PyTorch DataLoader 上——数据加载的速度跟不上 GPU 消耗的速度。这篇文章专门写给正在被“GPU 利用率低”困扰的同学。目标是教你用最短路径确认瓶颈是不是在 DataLoader然后从参数调整、数据处理到特殊情况比如 WSL 环境、AMD 显卡一层层把数据管道压榨出来。文章不堆理论全是能直接复制、照着做的排查方式和实操经验适合已经会用 PyTorch 写训练脚本、但遇到性能问题时不知道从哪下手的读者。1. 先分辨清楚GPU 利用率低究竟是模型问题还是数据没跟上排查性能问题最忌讳的是一上来就调参。很多人改了一通 num_workers、prefetch_factorGPU 还是老样子白白浪费时间。正确做法是先判断问题到底出在哪一层是模型本身算不动还是 GPU 一直在等数据。1.1 不同症状对应不同瓶颈先对照一下你看到的“低”是哪种形态这决定了后续排查方向完全不一样。症状最可能的瓶颈下一步动作GPU 利用率锯齿状波动一时 90% 一时 20%数据供给不稳定DataLoader 嫌疑最大重点排查数据加载链路GPU 利用率稳定但偏低比如一直 40%模型单步计算太轻、batch 太小或数据持续不足先固定 batch 做基准测试CPU 所有核都打满GPU 闲着worker 数量不够或预处理太重增加 num_workers或优化getitemCPU 占用不高GPU 也闲IO 等待、锁等待或主进程 collate 串行检查存储介质、pin_memory、collate_fnGPU 利用率高但训练吞吐上不去模型本身计算/访存瓶颈和数据关系不大重点分析模型结构而不是数据加载上面表格里最容易被误判的是第一种锯齿状波动。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_workers8这个参数却不清楚每个 worker 到底在干什么所以出了问题也没法定位。2.1 一个 batch 从硬盘到显卡的完整链路PyTorch DataLoader 的工作流程大致可以分为四段主进程在每轮 epoch 开始时生成一份索引序列并根据shuffle设置打乱顺序。如果有Sampler这里还会涉及权重采样逻辑。每个 worker 子进程按索引去磁盘读取对应的样本文件做完dataset.__getitem__里定义的处理比如读取图像、解码、Resize、数据增强返回一个或多个样本。worker 把处理好的单个样本放进一块共享内存队列。这个队列是 worker 与主进程之间的传输通道。主进程的某个线程负责从队列里取出一整个 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、WebDatasetshuffle 会破坏空间局部性让后面的随机读取变成大量随机跳转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_size64, num_workers8, pin_memoryTrue, ) 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(fDataLoader 单批平均耗时: {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_bycpu_time_total, row_limit15))跑完之后看两个维度。第一个是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_memoryTrue 到底做了什么pin_memoryTrue的意思是在 CPU 侧分配“锁页内存”也就是物理内存中固定位置、不允许被换出到磁盘的内存块。为什么这很重要普通内存页可能被操作系统随时换出GPU 要从 CPU 拿数据时无法直接 DMA 拷贝必须先经过一次 CPU 的“锁页”操作把数据搬到固定内存里再拷到显存。锁页内存省掉了中间这一步H2D 拷贝走更快的通道而且可以和计算重叠。一句话结论如果你的数据最终要.cuda()进入 GPUpin_memoryTrue几乎总该开着。但有两个例外要注意。一是 WSL2 环境下尤其是 AMD 显卡走 ROCm 驱动的组合pin_memory 可能反而引入稳定性问题表现为训练随机卡死或 worker 崩溃。我在第 6 章的案例三会详细说。二是如果你的num_workers已经很大每个 worker 都在分配锁页内存可能会导致内存碎片化或超出系统允许的锁页内存上限。遇到这种情况要么减少 worker 数要么在系统层调一下锁页内存限制。4.3 persistent_workersTrue小 epoch 数据的救星每个 epoch 结束时DataLoader 默认会把所有 worker 子进程销毁下一个 epoch 从头再 fork 一批。销毁、重建涉及到 Python 进程的初始化、模块重新加载、内存重新分配这个过程并不便宜。如果数据集很小一个 epoch 只需要几十个 step那么重开 worker 的成本可能占到总训练时间的可观比例。你会发现 GPU 利用率在每个 epoch 的开头会有一次明显的掉坑训练越快越明显。这个问题的修复方式简单到不可思议加一个参数就行。persistent_workersTrue加了之后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 的 ndarraycollate 时要先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_size64, num_workers4, # 按你的 CPU 物理核数调整 pin_memoryTrue, persistent_workersTrue, prefetch_factor4, drop_lastTrue, # 训练阶段建议丢弃末尾不足 batch 的部分 )注意drop_lastTrue只在你不介意外面有一批不完整样本时用验证集上一般不建议设置因为评估时通常要保留全部样本。这套配置不是万能的但它能覆盖大部分“默认设置下 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, transformNone): 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.Tensorcollate 只保留一行torch.stack。改完再测DataLoader 单 batch 从 55ms 降到 18msGPU 利用率到了 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_workersTrue。改动前后对比GPU 利用率周期性的“卡嗓子”现象消失整个训练时间缩短了约 20%。如果你也遇到类似的周期性掉坑可以先数一下掉坑的间隔时间如果间隔和 epoch 长度一致第一优先检查的就是有没有开persistent_workers。6.3 案例三WSL2 AMD 显卡下 DataLoader 的神秘“假死”最后一个案例比较特别来自 WSL2 加 AMD 显卡的组合。朋友的机器配置是 AMD 7900 XTXPyTorch 走 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_memoryTrue卡死问题彻底不再复现。之后又把数据从/mnt/d挪到了 WSL2 的~/data目录下GPU 利用率明显回升。这个案例最终确认了两个问题一是 WSL2 访问 Windows 挂载盘的 9P 协议 IO 开销大也就是我之前说的/mnt路径问题二是 ROCm 驱动在 WSL2 环境下对锁页内存和大量 worker 进程的配合并不如 CUDA 在原生 Linux 下那么稳定pin_memoryTrue加多 worker 的组合在这种虚拟化环境下会触发资源异常。最后的稳定配置是num_workers2~4、pin_memoryFalse、persistent_workersTrue数据放在 WSL2 自己的文件系统里。如果后续升级了 ROCm 或 PyTorch 版本可以再逐步往上调参数一点点试验临界点。遇到这类环境相关的问题我的经验是先给参数做减法把 pin_memory 关掉、把 worker 数降到最低先让程序稳定跑通再一项项加回去比一次性照抄满配更容易找到临界点。WSL 和 AMD 这条路线本来就没有特别多现成案例稳妥优先永远是第一位的。