1. Batch Size 基础概念

大家好，我是你们的老朋友。今天咱们聊聊 Batch Size 这个看似简单、实则门道很深的话题。

说实话，我见过太多同学一上来就把 Batch Size 设成 32 或 64，问为什么，答曰「大家都这么设」。嗯，这种做法不能说错，但确实有点浪费 GPU 的性能。我自己在调优的时候，光 Batch Size 这一个参数就折腾过不下百次，踩过的坑能写满一页 A4 纸。

Batch Size，中文叫「批次大小」。说白了，就是每次喂给模型多少个样本，然后统一算一次梯度、更新一次参数。

举个例子：假设你有 1000 张猫狗图片要训练。如果 Batch Size = 32，那模型一次吃 32 张图，吃完算账（反向传播），然后更新权重。吃完这 1000 张图，大概需要 1000 ÷ 32 ≈ 32 个批次。

我个人习惯把 Batch Size 理解成「一口吃多少」。你想想看，一口吃太多容易噎着（显存溢出），一口吃太少又效率低（频繁更新，震荡大）。

  核心公式：

  每次迭代 = 处理一个 Batch → 前向传播 → 计算损失 → 反向传播 → 更新参数

这两个概念经常被搞混。我当年刚入行时也犯过这个错，面试被问到差点翻车。

它们的关系很简单：

总 Iteration 数 = (样本总数 ÷ Batch Size) × Epoch 数

举个例子：1000 张图，Batch Size = 32，训练 10 个 Epoch。

每个 Epoch 的 Iteration = 1000 ÷ 32 ≈ 32 次
总 Iteration = 32 × 10 = 320 次

我在项目中遇到过有人把 Epoch 和 Iteration 混着用，结果日志里记录的训练步数完全对不上，排查了半天才发现是概念搞混了。嗯，这种低级错误咱们尽量避免。

吞吐量，说白了就是「单位时间内能处理多少样本」。这个指标直接决定了你的训练速度。

为什么会这样？我给你拆解一下：

GPU 并行计算特性：GPU 擅长同时处理大量数据。Batch Size 越大，GPU 的利用率越高。我测试过，Batch Size 从 1 提到 32，吞吐量能翻 5-8 倍。
计算/通信比：每次迭代都有固定的开销（启动 kernel、数据传输等）。Batch Size 越大，这些固定开销被分摊到更多样本上，平均每个样本的成本就降低了。
内存带宽瓶颈：这里有个坑——Batch Size 不是越大越好。当 Batch Size 超过某个阈值，GPU 显存带宽会成为瓶颈，吞吐量增长会趋于平缓甚至下降。

我的经验：
对于常见的 NVIDIA GPU（如 A100、V100），Batch Size 在 64-256 之间通常能获得较好的吞吐量。但具体数值需要结合模型大小和显存容量来试。

注意：
我曾经在某个项目中把 Batch Size 从 128 提到 512，结果显存直接爆了。后来发现是模型里有个中间层输出特别大，占了不少显存。所以调 Batch Size 时，记得先看看显存余量。

为了让你更直观地理解 Batch Size 对吞吐量的影响，我画了一张图：

从这张图你能看到：

所以调 Batch Size 就像走钢丝——既要追求吞吐量，又得留足显存余量。我个人建议的做法是：先从小 Batch Size 开始，逐步增大，同时监控 GPU 利用率和显存占用，找到那个「性价比最高」的点。

  一句话总结：

  Batch Size 调优的本质，就是在 GPU 计算效率和显存容量之间找平衡。没有万能的最佳值，只有最适合你当前硬件和模型的值。

好了，这一章的内容就到这里。记住，Batch Size 不是越大越好，也不是越小越好，关键是要「刚刚好」。下一章我会聊聊如何通过实验找到这个「刚刚好」的值，以及一些实用的调参技巧。