to(device)耗时长本质是GPU等数据：GPU-Util在0%→95%→0%间规律跳变（间隔0.5–2秒），Memory-Usage稳定、温度低，说明瓶颈在CPU侧，如num_workers=0、磁盘IO瓶颈、Dataset中未缓存的重复解码等。
to(device) 耗时长，不是 to 本身慢，而是它暴露了上游瓶颈——你看到的延迟，90% 是在等数据。
to(device) 耗时长但 nvidia-smi 显示 GPU-Util 忽高忽低
这是典型“GPU 等数据”信号：
-
GPU-Util在 0% → 95% → 0% 之间规律跳变，间隔约 0.5–2 秒 -
Memory-Usage稳定、温度低、风扇不响 - 说明 GPU 算得快，但每次算完就得干等下一 batch 送进来
根本原因几乎都在 CPU 侧：
-
DataLoader的num_workers=0：所有数据加载和预处理全挤在主线程，无法并行 - 磁盘 I/O 瓶颈：
iostat -x 1显示%util ≈ 100%或await > 10ms - 图像解码/归一化写死在
Dataset.getitem里，且没缓存（每读一次都重解） - 数据路径在 HDD 或 NFS 上（尤其是云环境挂载的远程存储）
先改 DataLoader(num_workers=4, pin_memory=True)，再观察跳变是否收敛；若仍跳，直接查存储介质类型。
输入张量太小导致 to(device) “显得”特别慢
PCIe 传输有固定开销（约 0.1–0.3ms），当计算本身极轻时，搬运反而成大头：
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
-
x.shape中 batch 维以外任意维度 ≤ 64（如(1, 3, 64, 64)或(8, 128)）就要怀疑 - 验证方法：放大
batch_size（如从 16 → 64），看单 step 时间是否下降、GPU-Util是否更平稳 - 注意：若放大后报
OutOfMemoryError，说明瓶颈已转为显存，此时该优化数据加载或启用梯度累积，而不是硬扛小张量
to(device) 调用位置错误或重复调用
to() 对 Tensor 是非原地操作，对 nn.Module 是原地操作，混用易出错：
- 错误写法：
data.cuda()（返回新张量，但没赋值），接着用model(data)→ 报Expected all tensors to be on the same device - 正确写法：
data = data.to(device)，且必须和模型用同一个device - 常见冗余：在训练循环里反复调用
x.to(device)，其实只要确保 DataLoader 输出的x已在 GPU 即可（配合pin_memory=True+non_blocking=True）
non_blocking=True 只在 pin_memory=True 时生效，否则会被静默忽略——这点极易被忽略。
真正卡住 to(device) 的，从来不是 GPU，而是 CPU 加载、磁盘读取、内存拷贝这三道门。优化顺序永远是：先让数据流起来，再谈张量搬得快不快。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
