DataLoader 的 num_workers 不是越大越快：RTX 3090 上把 0/2/4/8/16 跑完后，我更建议先看这 3 件事很多教程一上来就建议把num_workers设成 CPU 核心数，或者至少“越大越不容易卡 GPU”。我这次在一台 20 逻辑核 + RTX 3090 的机器上，把0/2/4/8/16跑在两条完全不同的数据管线上，结果很不一样：内存里已经准备好的张量，2个 worker 先把速度拉慢了；JPEG 解码和增强很重的场景，0又成了最慢的那个。真正决定num_workers的，不是你有几个核，而是__getitem__到底在干什么。这篇文章不复读“多试几个数就好”，而是把 PyTorch 官方文档里的提醒、社区里反复出现的慢速案例，和一组可复现的本地实验放到一起。你看完至少能带走三件事：什么场景该从0开始，什么场景该从4或8开始，以及为什么短 epoch 里persistent_workers往往比盲目加 worker 更值钱。PyTorch 文档其实早就埋了提示，但很多教程只讲了前半句PyTorch 官方调优指南确实建议在训练时启用异步数据加载，也就是把num_workers