2. 硬件视角：GPU显存与计算单元、显存带宽对Batch Size的限制、CPU-GPU数据传输瓶颈
聊到Batch Size调参，很多人第一反应是「调大点，跑得快」。嗯，这话对了一半。另一半藏在硬件里。
我刚开始做深度学习那会儿，也踩过这个坑。把Batch Size从32调到128，心想训练速度能翻4倍吧？结果一跑，显存直接爆了。后来我才明白——Batch Size不是你想设多大就设多大，硬件说了算。
2.1 GPU显存：你的第一道天花板
说白了，每个Batch的数据、模型参数、中间激活值、梯度，全都要塞进显存里。显存不够，一切免谈。
我习惯用一个简单公式估算显存占用：
显存占用 ≈ 模型参数 × 4字节 + Batch Size × 单样本数据量 × 4字节 + 中间激活 × 4字节举个例子。一个ResNet-50模型，参数约25M，单精度下就是100MB。输入图片224×224×3，单样本约0.6MB。如果你设Batch Size=256，光数据就占了153MB。再加上中间激活——这个才是大头，ResNet-50的中间激活能到几百MB甚至上GB。
关键结论：显存是硬约束。Batch Size的上限 = (总显存 - 模型参数 - 中间激活) / 单样本数据量。
我的小技巧：先用小Batch Size跑一个step，看显存占用。然后线性外推，就能估算出最大Batch Size。我在项目中经常用这招，省得反复试错。
2.2 显存带宽：被忽视的隐形杀手
显存够用就万事大吉了？不是的。你想想看，数据要从显存搬到计算单元，这个搬运速度就是显存带宽。
为什么Batch Size太小会浪费带宽？因为每次搬运数据都有固定开销。Batch Size=1时，你搬一次数据只算一个样本，带宽利用率极低。Batch Size=64时，同样搬一次数据能算64个样本，带宽利用率就上去了。
我遇到过这样一个案例：用V100训练BERT，Batch Size从32调到64，吞吐量提升了80%。但再调到128，只提升了10%。为什么？因为显存带宽已经接近饱和了。
注意：显存带宽的利用率不是线性的。通常有个「甜点区」——Batch Size再大，吞吐量提升就微乎其微了。我建议你做个实验：从2的幂次开始试（32、64、128、256），找到吞吐量增长明显放缓的那个点。
2.3 CPU-GPU数据传输：最容易被忽略的瓶颈
这个坑我踩得最惨。有一次训练一个视频模型，数据量特别大。我设了很大的Batch Size，结果GPU利用率一直在30%左右徘徊。查了半天才发现——CPU来不及把数据喂给GPU。
为什么会这样？
- 数据加载慢：CPU要从磁盘读数据、做预处理（裁剪、归一化、增强），这些都要时间
- 传输带宽有限：PCIe 3.0 x16的理论带宽约16GB/s，但实际能到10GB/s就不错了
- Batch Size越大，传输压力越大：每个step要传的数据量 = Batch Size × 单样本大小
我曾经用PyTorch的DataLoader，默认num_workers=0，结果CPU预处理成了瓶颈。后来改成num_workers=4，GPU利用率直接飙到90%以上。
我的建议：
- 用多个worker并行加载数据（num_workers=4或8）
- 开启pin_memory=True，加速CPU到GPU的传输
- 如果数据预处理太重，考虑用NVIDIA DALI这类库
2.4 知识体系：一张图看懂
下面这张图总结了硬件视角下Batch Size调参的核心逻辑。我习惯用这种图来梳理思路，你也试试看。
2.5 实战建议：怎么找到你的甜点区
说了这么多理论，来点实际的。我一般按这个步骤找Batch Size：
- 先测显存上限：从Batch Size=2开始，每次翻倍，直到OOM。记下最大能跑的Batch Size。
- 再测吞吐量：在最大Batch Size的1/4、1/2、3/4、1倍处各跑几十个step，记录每秒处理的样本数。
- 观察GPU利用率：用nvidia-smi或nvtop看GPU利用率。如果利用率低于80%，说明有瓶颈。
- 调优传输：如果GPU利用率低，优先优化数据加载（num_workers、pin_memory、DALI）。
记住：Batch Size不是越大越好。我见过有人用A100跑Batch Size=1024，结果显存带宽成了瓶颈，吞吐量反而比512时还低。找到那个「甜点区」才是关键。
嗯，硬件视角这部分就聊到这儿。下一节我们会从算法角度看看Batch Size对收敛的影响——那又是另一番天地了。
想要更多资料，联系可可