核心要点
先 profile 定位瓶颈：看 GPU 利用率，低利用率多半卡在数据加载/IO，高利用率才是算力瓶颈
数据侧：增 num_workers、开 pin_memory、预取/缓存、把预处理搬到离线或 GPU 上
计算侧：开混合精度（FP16/BF16）、增大 batch 提吞吐、用更高效算子（如 Flash Attention）
规模侧：单卡到瓶颈就上分布式数据并行（DDP），并检查通信/同步是否成为新瓶颈
标准回答
先量化瓶颈在哪一段，再对症加速（独占一行）
不要凭感觉优化。先看 GPU 利用率（nvidia-smi/dcgm）和用 profiler（如 torch.profiler）拆分一个 step 的耗时：数据加载、H2D 拷贝、前向、反向、优化器各占多少。利用率长期偏低，瓶颈基本在数据/IO 而非算力。
数据加载瓶颈
增大 DataLoader 的 num_workers、开 pin_memory 加速 H2D、用 prefetch 让取数与计算重叠；把重的预处理离线化、缓存或下推到 GPU；小文件多则改用打包格式（如 webdataset）减少随机 IO。
计算瓶颈
开 混合精度 提速并省显存；在显存允许下增大 batch 提升 GPU 吞吐；用高效实现（Flash Attention、融合算子、channels_last）；避免频繁 .item()/CPU-GPU 同步打断流水。
扩展到多卡
单卡到顶就上分布式数据并行（DDP），注意 batch 与学习率同步缩放、用合适的通信后端，并检查梯度同步/all-reduce 是否成为新瓶颈，必要时配合梯度累积减少通信频次（推理服务层优化见 推理服务架构）。
常见误区
⚠️ 常见踩坑
不先 profile 就盲目堆卡或调参，结果瓶颈在数据加载、堆 GPU 也没用；以及训练循环里频繁 print/.item() 触发 GPU 同步，悄悄拖慢整体吞吐。
追问
追问 1：怎么快速判断是数据加载瓶颈还是计算瓶颈？
看 GPU 利用率：若利用率长期很低、且把 batch 数据替换成内存里的随机张量后速度明显变快，说明卡在数据加载/IO；若换成假数据速度几乎不变、利用率本就很高，则是计算瓶颈，该从混合精度、算子效率、batch 入手。
追问 2：增大 batch size 一定能让训练更快吗？
不一定。增大 batch 能提高 GPU 吞吐、减少同步开销，但受显存上限约束，且大 batch 常需调大学习率并加 warmup，否则收敛变差甚至发散；若已是计算饱和或泛化下降，单纯加 batch 收益有限，需配合调度与正则。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。