这不是理想状态，而是训练流水线严重失衡的信号：CPU成了“懒汉”，GPU却在“过劳”；当num_workers远超CPU核心数，进程调度开销剧增，worker空转或锁竞争导致CPU利用率偏低，而GPU因持续接收预加载batch维持高负载。
这通常不是理想状态，而是训练流水线严重失衡的信号：CPU成了“懒汉”，GPU却在“过劳”。真实场景中，CPU利用率长期低于30%、GPU利用率却稳定在85%以上，大概率说明数据供给已超饱和——但代价是CPU计算环节被大幅削弱或绕过，反而埋下稳定性与可调试性隐患。
torch.utils.data.DataLoader 的 num_workers 设得太高
当 num_workers 远超可用CPU核心数（比如16核机器设成32），进程调度开销剧增，实际有效worker反而减少；更关键的是，大量worker空转或竞争锁，htop 里看不到活跃线程，CPU整体占用率就被拉低。GPU却因持续收到预加载好的batch而高负荷运转。
- 典型表现：
nvidia-smi显示 GPU-Util > 85%，htop中 Python 子进程数量多但单个 CPU% 很低（ - 安全上限参考：设为
min(32, os.cpu_count() - 1)，留至少1核给主进程调度 - 验证方式：临时改为
num_workers=0，若CPU%反升、GPU%略降，说明原设置已过度并行化
用了 pin_memory=True 但数据预处理全在GPU上做
pin_memory=True 本意是加速CPU→GPU传输，但它只对从CPU内存拷贝张量生效。如果你把图像解码、归一化、甚至 torchvision.transforms 全部移到了GPU（例如用 torch.cuda.amp 或自定义CUDA kernel），那CPU确实无事可做——所有计算都压给了GPU，CPU自然“闲着”。
- 风险点：GPU显存压力陡增，
torch.cuda.memory_allocated()容易OOM；且多数预处理操作（如随机裁剪）在GPU上并无加速收益 - 正确分工：预处理保留在CPU（用
num_workers并行），仅模型前向/反向在GPU；pin_memory=True配合non_blocking=True传参即可 - 检查方法：在
__getitem__中加assert not tensor.is_cuda，确认输入张量未提前上GPU
训练循环里跳过了CPU密集型操作
有些优化会刻意剥离CPU工作来“腾出带宽”，比如关闭日志、禁用验证、跳过指标计算——这些本该由CPU完成的任务一旦消失，CPU负载就断崖下跌。GPU则因无等待、纯计算而持续满载。
立即学习“Python免费学习笔记（深入）”；
- 常见误操作：把
val_loader注释掉；用torch.no_grad()包裹整个训练step；或把tqdm进度条设为disable=True - 隐蔽陷阱：自定义
loss函数中用了.item()或.cpu().numpy()，但被torch.compile()或torch._dynamo优化掉了同步点，导致CPU侧逻辑被编译器静默消除 - 定位建议：用
torch.profiler.profile抓取一个step，看cpu_time_total是否异常偏低（
真正健康的训练状态，是CPU和GPU保持节奏协同：CPU喂数据不卡顿，GPU算得不过载。当CPU利用率过低时，别急着庆祝“高效”，先查查是不是把本该它干的活儿粗暴砍掉了——那不是提速，是把训练变成了单点高危运行。
