num_workers设过高导致CPU满载、GPU空等，根本原因是DataLoader子进程失控：OpenMP/MKL默认占满CPU核心，加pickle开销；小数据集IO无压力但CPU空转调度。

num_workers设太高反而让CPU跑满、GPU干等

根本问题不在模型或CUDA，而在DataLoader子进程失控：每个num_workers默认启用全部CPU核心跑OpenMP/MKL，还自带pickle序列化开销。小数据集上IO没压力，CPU却在空转调度线程。

• num_workers=0最稳——主进程加载，适合调试、Windows或数据量小的场景
• Linux/macOS下num_workers=2～4是甜点区；再高基本无效，还易触发GIL争抢和内存拷贝
• 别盲目按CPU核数设（比如16核就设12），实测超过4后吞吐几乎不涨，CPU负载却线性上升

pin_memory=True不配non_blocking=True等于白开

pin_memory=True只把主机内存锁住，真正提速靠的是GPU端异步传输。如果.to(device, non_blocking=True)没加，数据仍会同步拷贝，CPU卡在等待，GPU也拿不到数据。

• 必须成对使用：pin_memory=True + tensor.to(device, non_blocking=True)
• 仅GPU训练时才开pin_memory；CPU训练开它反而多一次内存拷贝
• 若num_workers=0，pin_memory无效——因为没子进程，无需固定页内存

OpenCV/Albumentations在后台偷偷占满CPU

很多人调了num_workers和torch.set_num_threads()没用，最后发现是cv2.imread或albumentations.Compose内部调用了OpenCV多线程，默认吃满所有核。

提示词大师-python版

图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍

下载

• 禁用OpenCV多线程：cv2.setNumThreads(0)（注意不是0表示“不限”，而是0表示“禁用”）
• albumentations若底层用cv2，同样需提前调cv2.setNumThreads(0)
• 避免在__getitem__里用torchvision.transforms.ToTensor()——PIL解码是纯CPU密集型，应提前转成.pt或用torch.compile加速

OMP_NUM_THREADS和MKL_NUM_THREADS必须全局设

torch.set_num_threads(1)只管PyTorch算子（如torch.mm），对DataLoader子进程完全无效。子进程走multiprocessing，必须靠环境变量控制。

立即学习“Python免费学习笔记（深入）”；

• 启动脚本最开头就设：os.environ["OMP_NUM_THREADS"] = "1"、os.environ["MKL_NUM_THREADS"] = "1"
• Windows上还要加mp.set_start_method("spawn")，否则fork可能死锁CUDA上下文
• Conda环境（尤其Miniconda）常fallback到OpenBLAS，torch.__config__.show()可查当前BLAS后端；MKL缺失时CPU单核跑久，监控显示“100%”但实际非并行

真实瓶颈往往藏在预处理链路最深那层——不是你没开多线程，而是多个库各自开了一套，互相打架。调参前先top -H看线程归属，比盲目改num_workers有用得多。