刚接手带人的那阵子，我被问得最多的不是网络结构怎么设计，而是“batch size 设多少合适”。这问题看着像调参小事，实际牵扯的东西相当多：梯度估计的统计性质、显存和吞吐的工程约束、归一化层的数值稳定性，甚至最后模型的泛化表现。神经网络训练中 Batch 的作用，远不止“一次喂几条数据”这么一句话——它决定了每一步更新时模型“看到的世界”有多大、这个世界的统计噪声有多强、以及你的硬件到底跑得满不满。
我准备把这件事从头拆一遍：反向传播那一行代码里 batch 究竟做了什么，batch size 怎么和学习率联动，显存预算怎么算，梯度累积为什么经常“模拟不像”，多卡环境下全局 batch 怎么换算，最后是我这几年踩过的坑和一份排查清单。刚入门想把原理理顺的可以看，已经在带项目、需要给团队定训练配置的更应该看，因为这里面很多决策一旦定错，后面调什么都别扭。
1. Batch 在训练循环里到底做了什么
1.1 一次参数更新的完整链路
大多数训练脚本的核心就那几行，我把它抄在下面，然后逐行说清楚 batch 站在哪个位置：
for x, y in loader: pred = model(x) loss = criterion(pred, y) # 这一批 B 条样本的平均损失 optimizer.zero_grad() loss.backward() # 反传得到的是 B 条样本梯度的平均 optimizer.step()关键在loss的定义上。框架里常用的分类交叉熵、回归的均方误差，默认都对 batch 维度取了平均。也就是说，你算出来的标量损失是 B 条样本损失的均值，反传之后得到的梯度自然也是 B 条样本梯度的均值。
写成公式就是：
$$L = \frac{1}{B}\sum_{i=1}^{B} l_i \quad\Rightarrow\quad \frac{\partial L}{\partial w} = \frac{1}{B}\sum_{i=1}^{B}\frac{\partial l_i}{\partial w}$$
这个均值操作是整个 batch 机制的核心。它做的事情本质上是一次蒙特卡洛估计：真实的“全量梯度”需要对整个数据分布求期望，但分布未知，只能用样本去估。抽一个样本估一次误差很大，抽 B 个取平均，误差就小得多。
统计上这个结论很干净：如果单样本梯度是真实梯度的无偏估计，方差为 σ²，那么 B 个独立样本取平均后，方差变成 σ²/B，标准差变成 σ/√B。翻成工程语言——batch size 从 16 加到 64，梯度噪声的标准差只降到原来的一半，而不是 1/4。这条 1/√B 的规律是后面所有讨论的地基，很多“加 batch 收益越来越小”的直觉都源于它。
1.2 batch、step、epoch 三个词别混着用
这三个词在代码和文档里经常被混用，我见过不少人把 step 和 epoch 当成一回事，结果调度器参数全错。先把定义钉死：
| 名词 | 含义 | 常见写法 |
|---|---|---|
| batch size | 一次前向加反向处理的样本数 | batch_size/B |
| step（iter） | 一次参数更新，消耗一个 batch | global_step |
| epoch | 把训练集完整过一遍 | num_epochs |
| 每轮步数 | 一个 epoch 内发生的参数更新次数 | ceil(N / B) |
这套关系里最容易出事的是最后一行。假设训练集有 10 万条样本，batch size 从 64 改成 256，每轮步数就从 1563 掉到 391，整整少了一个数量级。如果你的学习率调度器是按 step 计数的（余弦退火、阶梯衰减基本都是），那训练节奏就完全变了——原本在第 50 轮降到底的学习率，现在可能第 8 轮就到谷底了。这种情况下模型表现变差，你会误以为是 batch size 本身的问题，实际上只是调度器没跟着改。
我自己的习惯是在配置文件里显式写一个total_steps，由epochs × ceil(N/B)算出来传给调度器，换 batch size 时它自动跟着变，能省掉一大类莫名其妙的问题。
1.3 为什么不逐样本更新，也不全量更新
理解 batch 最直观的办法是看两个极端。
batch size 等于 1，也就是常说的逐样本更新。每来一条数据就更新一次参数，一个 epoch 内参数被改 N 次。听起来“信息利用很充分”，实际有几个硬伤：梯度噪声极大，损失曲线抖得像心电图；矩阵乘法的维度退化成向量，GPU 的并行算力基本被浪费；归一化层更是没法用，一条样本算出来的均值和方差毫无意义。这种情况在早期小规模实验里可能还行，规模化训练基本没人这么干。
另一个极端是全批量，一次更新用上全部数据。梯度是精确的、确定性的，损失单调下降，理论上很美好。但代价是显存和时间都撑不住，而且一个 epoch 只更新一次参数，收敛速度慢到无法接受。更麻烦的是确定性梯度容易让优化过程卡在鞍点附近，因为没有任何随机扰动帮你“晃出去”。
提示：优化的本质不是“沿最陡方向猛冲”，而是在带噪声的地形里逐步逼近。梯度噪声既是干扰，也是探索的动力，这一点在后面的泛化讨论里还会反复提到。
中间这条路——小批量随机梯度下降——就是行业默认的答案。它用可控的噪声换来了可接受的单步成本，同时保留了足够的更新频率。batch size 的选择，说白了就是在这个权衡谱系上找个你硬件和任务都能接受的点。
用一个生活化的类比收束这一节：想知道全国人的平均身高，挨个量一遍成本太高；只量一个人，运气不好碰上个篮球运动员，结论就废了；随机抽几百人取平均，误差已经足够小。抽样人数与估计精度的关系是 1/√n 递减，抽到一定数量之后再加人，边际收益肉眼可见地变小。batch size 的逻辑完全一致。
2. Batch Size 如何改变训练动力学
2.1 梯度噪声与有效学习率
把梯度写成“真实梯度 + 噪声”的形式：
$$g_B = g + \epsilon,\quad \mathbb{E}[\epsilon]=0,\quad \text{Var}(\epsilon)=\sigma^2/B$$
参数的更新量是lr × g_B。噪声项lr × ε的幅度和lr/√B成正比。这就引出一个非常重要的结论：改变 batch size 会隐式改变有效学习率。
举个具体数字。原来 batch=32、lr=0.01，梯度噪声标准差记为 1（归一化单位）。你把 batch 提到 128，噪声标准差降到 0.5。如果 lr 不变，那么噪声引起的参数抖动幅度直接减半，模型相当于“变保守了”——每一步迈得没那么随机，但收敛速度反而下降，因为你并没有因为噪声变小而把步子迈大。
这也解释了为什么很多人把 batch 从 32 加到 256，然后发现 loss 下降变慢、最后精度还略差：不是大 batch 本身不行，而是更新次数少了 8 倍，而 lr 没变，累积的步长总量少了一大截。等价的说法是“同样的 epoch 数下，模型走的路更短了”。
2.2 学习率和 batch size 的缩放经验
围绕这个问题，社区里沉淀了两条常用的经验规则：
| 缩放方式 | 公式 | 适用场景 | 风险 |
|---|---|---|---|
| 线性缩放 | lr = base_lr × (B / base_B) | 中小规模、batch 放大倍数不大（2~8 倍） | 大倍数下初期极不稳定，必须配 warmup |
| 平方根缩放 | lr = base_lr × sqrt(B / base_B) | 放大倍数很大、或数据噪声本身较高 | 收敛偏慢，需要更多 epoch |
| 不缩放 | lr保持不变 | 只想加 batch 提吞吐、不追求同等收敛速度 | 训练轮数需要相应增加 |
线性缩放的逻辑来自“梯度噪声相对幅度不变”：噪声幅度正比于lr/√B，要让这个比值保持不变，lr就得正比于√B的平方，也就是 B。但实践里线性缩放有个前提——梯度方向在大 batch 下确实更准，你可以放心迈大步。这个前提在训练初期往往不成立，模型还处在随机状态，大步长容易直接跑飞。所以线性缩放几乎总是和 warmup 绑在一起用。
平方根缩放更保守，它的思路是保持参数更新的方差不变，而不是保持噪声相对幅度不变。我在这几年做过的一些任务里，放大 8 倍以内的 batch 用线性缩放加 warmup 基本没问题，放大到 32 倍以上时会偏向平方根缩放，或者干脆用线性缩放但把 warmup 拉长到几千步。
有一点必须提醒：这些公式是起点，不是定理。不同任务、不同优化器、有没有自适应学习率，实际的适配系数差别很大。我的做法是先按平方根缩放起手，稳定之后再逐步往线性缩放靠，看损失曲线有没有异常波动。
2.3 显存、吞吐与硬件效率的三角权衡
工程视角下，batch size 直接决定了两件事：显存占用和计算效率。
显存方面，参数、梯度、优化器状态这三块是固定的，和数据量无关；激活值是随 batch size 线性增长的。所以 batch size 越大，激活部分占比越高，最终 OOM 几乎总是发生在激活上。具体估算方法放到第 4 节细讲。
计算效率方面，GPU 这类加速器喜欢“大块头”的计算。矩阵乘法在维度很小的时候，大量时间花在调度和访存上，算力单元反而是闲着的。batch size 太小，卷积和矩阵乘的批次维度撑不起来，利用率可能只有峰值的两三成。我见过有人抱怨“显卡买了却跑不满”，八成就是 batch size 或者数据加载拖了后腿。
但增大 batch 不是免费的午餐。超过某个点之后，吞吐增长会变缓甚至不增，原因是：
- 显存带宽和缓存容量成为瓶颈，大张量反复搬运；
- 单个 batch 的计算时间变长，流水线的并行重叠效率下降；
- 数据加载、预处理跟不上计算速度，GPU 出现等待。
我一般会做一个简单的实测：固定其他条件，把 batch size 从 8 一路拉到显存上限，记录每组配置下的每秒处理样本数。曲线通常在某个位置出现明显的拐点，拐点之后每秒样本数不再上涨，那这个点就是你这个模型在这张卡上的经济 batch size。硬要再往上加，只会降低更新频率、拉长训练时间。
2.4 大 batch 与小 batch 的泛化之争
这个话题讨论了很多年，结论其实没那么玄乎。
主流解释是“平坦极小值 vs 尖锐极小值”。小 batch 的梯度噪声大，参数在损失面上被反复“晃”，倾向于落进一个四周都比较平坦的坑里；大 batch 噪声小，优化路径更确定，容易钻进一个很窄的坑，训练集上损失很低，但换个数据分布就掉下来。
这个解释本身是成立的，但被过度演绎了。实际情况是：大 batch 带来的泛化损失，很多时候可以用别的办法补回来，比如更强的数据增强、更长的训练轮数、合适的学习率调度、以及权重衰减的调整。真正导致“大 batch 训练失败”的，往往不是泛化问题，而是学习率和 warmup 没配套，模型压根没收敛好。
我自己的经验是：在中等规模任务上，batch size 在 32 到 256 之间变化，只要学习率按规则相应调整、训练轮数给够，最终效果差异通常在小数点后一位的量级，远没有网上渲染得那么夸张。真正需要警惕的是把 batch 放大到几千这种量级，那确实需要专门的技术手段配合。
3. Batch 与归一化层的耦合细节
3.1 BatchNorm 的统计量是怎么来的
批归一化这个层，是 batch size 影响最剧烈的地方。它的前向逻辑很朴素：对每个通道，在当前 batch 内算出均值和方差，把特征标准化，再乘一个可学习的缩放、加一个可学习的偏移。
$$\hat{x} = \frac{x - \mu_B}{\sqrt{\sigma_B^2 + \epsilon}},\quad y = \gamma\hat{x}+\beta$$
其中μ_B和σ_B²是当前 batch 在该通道上的统计量。训练时每次前向都重新算，同时用一个动量系数把这两个值累积到滑动平均里，推理阶段就用这份累积的滑动平均。
问题就来了：μ_B和σ_B²是对真实分布统计量的估计，样本数就是 batch size。估计的误差同样遵循 1/√B 规律。batch size 是 256 时，每个通道有 256 个样本参与统计，估计得比较稳；batch size 掉到 4 甚至 2，统计量噪声极大，标准化之后特征分布每步都在变，训练自然不稳。
3.2 小 batch 下归一化为什么崩
我见过最典型的现象是：训练损失一路往下走，看起来很健康，但验证集指标怎么都不涨，甚至越训越差。排查半天发现是 batch size 只有 8，归一化层的滑动平均没估准，推理时用的均值方差和训练时的实际分布对不上，前向输出整体偏移，后面的层全部受影响。
还有一个更隐蔽的表现：训练和推理的指标差距随 batch size 减小而迅速扩大。正常情况下两者应该接近，如果发现验证指标比训练指标差一大截，且排除了过拟合和数据泄漏，那就要怀疑归一化统计量。
业界一般的经验值是每卡 batch size 不低于 16，最好在 32 以上，才能保证归一化层稳定工作。这个数字不是硬性规定，但低于 16 之后风险上升得很快，低于 8 基本就是在赌运气。
注意：这里的“每卡”两个字很重要。如果你用了跨卡同步的归一化，统计量是在所有卡的样本上合并计算的，那看的是全局 batch；如果没开同步，每张卡各自算各自的，那就要看单卡 batch。
3.3 几种可选的替代与补救方案
batch 实在上不去的时候，有这么几条路：
换成不依赖 batch 维度的归一化。组归一化、层归一化都是在单个样本内部做统计，和 batch size 完全无关，小 batch 下非常稳。代价是它们在某些视觉任务上的效果略逊于批归一化，需要实验验证。
开启跨卡同步统计。把多张卡的样本合起来算均值和方差，等效放大统计样本量。代价是每层都要做一次全局通信，训练速度会掉一些，卡越多掉得越明显。网络带宽一般的情况下，这个开销不能忽略。
冻结归一化层的统计量。先用一个较大的 batch 跑一段，把滑动平均估准，然后冻结这两个缓冲区不再更新，后续用小 batch 微调。这招在算力受限的微调场景里挺好用，但要注意冻结之后如果数据分布变了，统计量就失配了。
调整动量系数。滑动平均的更新是running = (1-m) × running + m × current。默认动量通常是 0.1，意味着每个 batch 贡献 10%。小 batch 下当前统计量噪声大，可以把这个系数调小（比如 0.01），让滑动平均更平滑，减少单批噪声的影响。这个改动很便宜，值得先试。
4. 落地：给任务定一个靠谱的 Batch 配置
4.1 显存预算怎么估
不用估得很精确，但量级必须心里有数，否则就是反复 OOM 反复试。思路是把显存拆成固定部分和变动部分。
固定部分（和 batch size 无关）：
- 参数：
P × 4字节（单精度） - 梯度：
P × 4字节 - 优化器状态：带动量的优化器通常是参数的 2 倍，即
P × 8字节；换成低精度训练时还要额外存一份主权重
合起来大约P × 16字节。一个一亿参数的模型，这部分就是 1.6 GB 左右，是个常量，你怎么调 batch 都省不掉。
变动部分是激活值，也就是反向传播时需要保存下来的中间结果。它的量级可以这样粗估：单样本激活字节数 ≈ 各层输出特征图元素个数之和 × 4。以一个处理 224×224 输入的卷积网络为例，第一层输出 64 个 112×112 的特征图，单样本就是 80 万个元素，约 3.2 MB。整网所有层加起来，单样本激活往往在 10 MB 到 30 MB 量级。
那么 batch size 为 64 时，激活部分大约 0.6 GB 到 2 GB。加上固定的 1.6 GB，再加上框架自身的运行时开销和显存碎片，整体在 3 GB 上下。
这个估算的实际用途是：当你想把 batch 从 64 提到 256 时，能立刻判断出“固定部分不变，激活部分要涨 3 倍，多出来 2 到 6 GB”，从而决定是直接加、还是开混合精度、还是只能上梯度累积。
顺带说一句混合精度。把前向的激活存成半精度，激活显存直接砍半，这是 batch size 上不去时性价比最高的一招。不过要注意数值稳定性，损失缩放该开还得开。
4.2 梯度累积的正确写法
显存不够又想要大 batch 的效果，标准解法是梯度累积：把一个大 batch 拆成若干个 micro-batch，分别前向反向，梯度先攒着，攒够了一次性更新。
accum_steps = 8 # 等效 batch = micro_batch × accum_steps optimizer.zero_grad() for i, (x, y) in enumerate(loader): pred = model(x) loss = criterion(pred, y) / accum_steps # 关键：必须除 loss.backward() if (i + 1) % accum_steps == 0: optimizer.step() optimizer.zero_grad()这里有几个容易翻车的点，我逐条说。
损失必须除以累积步数。因为每次backward()都是把梯度累加到.grad上而不是覆盖，如果不除，最终梯度就是 8 个小 batch 梯度之和，等效学习率放大了 8 倍。这个错误非常常见，表现是训练初期就炸。
归一化层并不会真的等效。这是最容易被忽略的。真的大 batch 训练时，归一化层在 256 条样本上算统计量；梯度累积时每个 micro-batch 只有 32 条，统计量是在 32 条上算的。两者的前向结果根本不一样，所谓“等效”只在梯度层面成立。如果你的模型重度依赖批归一化，梯度累积出来的效果可能和真大 batch 有明显差距。解决办法要么是换归一化类型，要么是开跨卡同步统计。
最后一组不完整的累积要处理。数据集长度不能被accum_steps整除时，循环末尾会剩几个 micro-batch 的梯度没更新就进入下一个 epoch 了。影响不大，但如果追求严谨，可以在 epoch 结束时补一次step。
学习率要按等效 batch 来设。上面例子里等效 batch 是micro_batch × 8，学习率就该按这个数去套缩放规则，而不是按 micro-batch。
4.3 warmup 与调度器的配合
batch size 一大，初期的不稳定就被放大。原因是训练刚开始时参数随机，梯度的方向和尺度都很飘，大 batch 虽然降低了噪声，但一旦方向错了，一大步迈出去回不来。
warmup 就是解药：前若干个 step 里，让学习率从接近 0 线性爬升到目标值。
warmup_steps = int(total_steps * 0.05) # 常见比例 1% ~ 10% def lr_lambda(step): if step < warmup_steps: return (step + 1) / warmup_steps progress = (step - warmup_steps) / max(1, total_steps - warmup_steps) return 0.5 * (1 + math.cos(math.pi * progress)) # 余弦退火warmup 长度怎么定？我一般按总步数的 1% 到 5% 起手，batch 越大、模型越深，比例往上调。放大 batch 倍数特别多的时候（比如 16 倍以上），warmup 给到 5% 到 10% 也不过分。判断标准很直接：看前几百步的损失曲线，如果 warmup 期间还在剧烈震荡，说明爬升太快或目标学习率太高。
还有一个细节：warmup 期间的步数是从 0 开始算的，如果你中途断点续训，要确保 warmup 状态也跟着恢复，否则会重新爬一遍坡，白白浪费一段训练。这类 bug 在长周期训练里特别坑，因为往往要过很久才从指标上察觉。
4.4 多卡环境下 batch 怎么换算
上了多卡数据并行之后，batch 的概念就分裂成两层，必须分清楚：
$$\text{global_batch} = \text{per_gpu_batch} \times \text{num_gpus} \times \text{accum_steps}$$
学习率要按global_batch来缩放，归一化统计量要看你有没有开同步，日志里报的“每步样本数”也该是 global 的。我见过团队里两个人对同一个实验报出完全不同的吞吐数据，最后发现一个按单卡算一个按全局算，白吵了半天。
多卡还有个隐性约束：单卡 batch 不能太小。因为每张卡上跑的是独立的计算，单卡 batch 掉到 4 以下，归一化的老问题又回来了，而且通信开销占比上升，加速比会很难看。实践里单卡 batch 维持在 16 到 32 是比较舒服的区间，卡数多了之后靠全局 batch 把总量堆上去。
另外要留意学习率的“非线性加速比”。理想情况是 8 卡线性加速，但通信、数据加载、同步点都会吃掉一部分。如果你的任务是计算密集型的，加速比能到 7 倍以上就算正常；如果是通信密集或者小模型，5 倍多也别太惊讶，问题往往出在单卡 batch 太小导致通信占比过高。
5. 常见问题与排查实录
5.1 一张速查表
把这些年遇到的典型症状整理成表，遇到问题先对着扫一遍，能省不少时间：
| 现象 | 大概率原因 | 优先尝试 |
|---|---|---|
| 训练初期 loss 直接跳到异常值 | 学习率相对 batch 太大，或没做 warmup | 降学习率、加 warmup |
| loss 剧烈震荡，长期不收敛 | batch 太小导致梯度噪声过大 | 增大 batch，或降学习率 |
| 训练 loss 降但验证指标不涨 | 归一化统计量失准（batch 太小） | 加大 batch / 换归一化 / 调滑动动量 |
| 训练和验证指标差距巨大 | 同上，或滑动平均被后期数据带偏 | 检查归一化层的缓冲区 |
| 显存 OOM，但显卡利用率很低 | batch 太小、数据加载是瓶颈 | 先查数据管线，再考虑加 batch |
| 加大 batch 后吞吐没提升 | 已经过了经济 batch 点 | 回到拐点处的配置 |
| 梯度累积效果不如真大 batch | 归一化统计量不一致 / 损失没除 | 开同步归一化，检查损失缩放 |
| 多卡加速比远低于卡数 | 单卡 batch 太小，通信占比高 | 提高单卡 batch |
| 断点续训后指标倒退 | warmup 状态、调度器步数没恢复 | 把 step 和调度器状态一起存 |
| 换 batch 后学习率曲线形状变了 | total_steps没跟着重算 | 由 epochs 和 batch 推导总步数 |
5.2 几个真实场景的处理思路
有个做图像分类的同学找我，说他训一个中等规模的卷积网络，单卡 batch 只能开到 8，因为再大就 OOM。结果就是第 3 节说的那套症状——训练损失一路降到很低，验证准确率卡在某个数不动。我先让他确认了归一化层的滑动统计量，果然是估计得一团糟。
处理过程分三步走。先开混合精度，激活显存砍半，单卡 batch 从 8 提到 16；再把归一化换成不依赖 batch 统计的类型，验证指标立刻正常爬升；最后补了梯度累积，等效 batch 到了 64，学习率按等效值重新调，训练曲线终于顺了。整个过程没换模型结构，纯粹是把 batch 相关的配置理顺。
另一个场景是分布式训练。有个项目上到 8 卡之后，吞吐只提升了 3 倍多。排查下来是单卡 batch 设成了 4，通信时间占了每步的一大半。把单卡 batch 提到 16、学习率按全局 batch 重新缩放之后，加速比到了 6.5 倍左右。这里的关键认知是：多卡并行的效率不只看卡数，还要看每张卡上有没有足够的活干。
还有一种情况是“换了 batch 之后一切都怪”。有位同事把 batch 从 64 改成 128，学习率也按线性缩放翻倍了，结果训练前几百步就发散。原因是他的调度器按 step 计数，总步数从 3000 降到了 1500，但配置里total_steps还写着 3000，余弦曲线拉长了一倍，学习率在高位停留过久。这类问题排查起来其实很快，只要养成“改 batch 必须同步检查 total_steps”的习惯就不会犯。
5.3 小 batch 训练的补偿手段
有些任务就是没法上大 batch，比如三维数据、超高分辨率图像、长序列，显存天然吃紧。这种情况下我通常按下面的顺序做补偿：
先解决归一化。这是小 batch 下最大的杀手，换掉它往往能解决一半问题。其次是梯度累积，把等效 batch 撑起来，虽然不完美但方向是对的。再就是降低学习率并延长训练轮数，用小步慢走换稳定。最后可以考虑一些对噪声天然友好的优化器配置，比如适当调高动量系数，让更新方向更平滑。
要接受一个现实：小 batch 训练就是比大 batch 慢、比大 batch 更依赖调参。与其花力气死磕，不如在硬件允许的范围内先把 batch 堆到归一化层能稳定工作的下限，再谈其他优化。
6. 我在实际项目里的几条体会
关于 batch size 这件事，我踩过的坑比看过的论文多。分享几个不太会写在文档里的经验。
第一，别迷信“最优 batch size”这种说法。它不存在。同一个模型在不同数据、不同硬件、不同的数据增强强度下，合适的 batch 完全不一样。真正稳定成立的只有那几条关系：噪声随 1/√B 下降、显存随 B 线性增长、更新次数随 B 反比减少。把这三条记住，剩下的靠实测。
第二，改 batch size 的时候，一次只改一个变量。我见过太多人同时改 batch、学习率、优化器参数、数据增强，然后模型不收敛了，完全不知道是哪个引起的。正确做法是固定其他条件，只动 batch，看损失曲线的形状变化，再决定学习率怎么跟。
第三，把实验配置里的 batch 相关参数集中管理。batch_size、accum_steps、lr、warmup_steps、total_steps这几项互相牵连，散落在代码各处迟早出问题。我现在的习惯是在配置文件顶部放一个推导块，由 epochs 和数据集大小自动算出总步数，再由总步数算出 warmup 步数，改一个数全链路跟着动。
第四个小技巧：训练开始后的前 200 步，把每步的梯度范数打出来。如果它在 warmup 期间从很小迅速冲到几十上百再回落，说明 warmup 有效果；如果一直在剧烈跳动甚至逐级攀升，那基本可以判定学习率偏高或者 batch 太小，趁早调整，别等训了几个小时才发现。
第五，日志里一定要记全局 batch 和单卡 batch 两个数，还有有没有开同步归一化。等三个月后回头复现实验，这些信息比任何超参都重要。我自己就吃过亏——同一个配置跑出两个差异不小的结果，翻日志才发现一次开了同步归一化一次没开，白折腾一轮。
最后说一句关于“大 batch 训不好”的判断。很多人遇到这种情况就归因于泛化，实际上九成以上是配置没配套：学习率没缩放、warmup 没加、总步数没重算、归一化统计量没估准。这些都不是玄学问题，逐条核对就能定位。真正需要动用高级技巧去解决泛化损失的情况，比想象中少得多。把基础的账算清楚，比追新方法实在。
