num_workers应匹配CPU物理核心数与数据IO特性：物理核心≤8时设为min(4, os.cpu_count()//2)；SSD+大文件可设为os.cpu_count()//2（≤12）；机械硬盘或小文件密集场景则强制设为2～4并配prefetch_factor=2。
PyTorch DataLoader的num_workers设多少才不拖后腿
设得太小，CPU喂不饱GPU；设太大，反而触发进程争抢和内存抖动。实测中，num_workers不是越大越好，而是要匹配你的CPU物理核心数和数据集IO特性。
常见错误是直接写 num_workers=8 或 num_workers=os.cpu_count()，结果在小文件多的数据集（如ImageNet子集含上万张JPG）上引发大量 lsof | grep '.jpg' | wc -l 超过2000，磁盘I/O卡死。
- 物理核心数 ≤ 8：设为
min(4, os.cpu_count() // 2) - SSD + 大文件（如LMDB/TFRecord）：可设为
os.cpu_count() // 2，上限不超过12 - 机械硬盘或小文件密集场景：强制降为 2～4，并配合
prefetch_factor=2
pin_memory=True到底该不该开
开了能加速CPU→GPU的拷贝，但前提是你的数据类型支持 pinned memory（比如 torch.float32 或 torch.long）。如果数据里混了 Python list、PIL.Image 或自定义对象，开 pin_memory=True 不仅无效，还会在 DataLoader 初始化时静默失败或报 RuntimeError: unable to pin memory。
典型踩坑场景：用了 transforms.Lambda 返回 PIL 图像，或在 Dataset.__getitem__ 中返回了未转成 tensor 的 numpy 数组。
立即学习“Python免费学习笔记（深入）”；
- 只对纯 tensor 数据开启：确认
__getitem__返回的是torch.Tensor类型 - 搭配
non_blocking=True使用：在.to(device, non_blocking=True)中启用异步传输 - 别在验证集 loader 上盲目复用训练集配置：验证时 batch size 常更大，
pin_memory可能引发显存碎片
预处理操作放CPU还是GPU更合理
绝大多数图像增强（如 ColorJitter、RandomAffine）默认在CPU上执行，而它们恰恰是 cProfile 火焰图里最常占满60%+时间的热点。这不是因为算法慢，而是 PIL 和 OpenCV 的单线程瓶颈太明显。
把部分增强搬到 GPU 上，能显著缓解 CPU 压力，但要注意：不是所有操作都适合搬——比如解码 JPEG 还得靠 CPU，强行用 torchvision.io.read_image 反而更慢。
- 适合 GPU 加速的：归一化（
Normalize）、裁剪（CenterCrop）、翻转（RandomHorizontalFlip）等 tensor-level 操作 - 必须留在 CPU 的：JPEG/PNG 解码、
Resize（除非用torchvision.transforms.v2的 GPU 后端） - 简单粗暴提速法：用
torchvision.transforms.v2替换老版transforms，它默认启用 CUDA-aware pipeline（PyTorch ≥ 2.0）
为什么GPU利用率忽高忽低，跟DataLoader关系最大
GPU 利用率在 nvidia-smi 里剧烈抖动（比如 0% → 95% → 20% → 80%），基本可以断定是 DataLoader 供给不稳。根本原因不是“没开多线程”，而是线程间负载不均或阻塞点没暴露出来。
一个容易被忽略的事实：__getitem__ 里任何同步 IO（如打开新文件、读取 HDF5 子集、调用 subprocess）都会让整个 worker 卡住，其他 worker 无法补偿——哪怕你开了 8 个 worker。
- 用
torch.utils.bottleneck快速定位：运行python -m torch.utils.bottleneck train.py --epochs 1，重点看 CPU profiling 报告里有没有PIL.Image.open或h5py.File.__init__ - 改用内存映射格式：LMDB 或 TFRecord 预加载索引后，
__getitem__变成纯内存寻址，worker 效率翻倍 - 避免在
__getitem__中做日志、计时、随机种子重设等副作用操作
真正卡住训练的，往往不是模型本身，而是那一行看似无害的 image = Image.open(path) —— 它让整个 worker 线程停在系统调用上，GPU只能干等。
