1. 从“优化器实例测试”说起：为什么这件事值得单独拎出来做
但凡做过一段时间模型训练的人，大概率都经历过这样的场景：模型结构调了好几版，数据管道也反复清洗过，训练脚本跑起来 loss 就是不降，或者降着降着突然炸成 NaN。排查半天，最后发现问题出在优化器上——学习率设大了、权重衰减配错了、动量参数和 batch size 不匹配。这类问题不解决，前面所有工作都是白费。
“优化器实例测试”这个标题，说白了就是把优化器从整个训练流程里单独拆出来，用可控的小规模实验去验证它的行为是否符合预期。它不是一个模型训练任务，而是一个诊断性、验证性的工程动作。核心目标有三个：第一，确认优化器在当前配置下能否稳定收敛；第二，观察不同超参数对参数更新轨迹的影响；第三，在正式大规模训练之前，用极低成本排除优化器层面的隐患。
这件事适合谁来做？我的判断是，只要你满足以下任意一条，就值得花时间做一轮优化器实例测试：正在调试一个新的模型结构，不确定该配什么优化器；从别的框架迁移过来，优化器实现细节有差异；训练过程中出现过 loss 震荡、梯度爆炸、参数不更新等异常；或者你只是想搞清楚 Adam、SGD、AdamW 这些优化器到底在干什么。哪怕你是刚入门的新手，做一遍这个测试，对优化器的理解会比看十篇教程都来得实在。
我自己的习惯是，每次启动一个正式训练任务之前，都会先跑一个“迷你版”的优化器实例测试。用几十个参数的小网络、几百条假数据，几分钟就能跑完，但能提前暴露掉八成以上的配置问题。下面我把这套流程完整拆开讲，包括设计思路、关键细节、实操步骤和踩过的坑。
2. 优化器实例测试的整体设计与思路拆解
2.1 为什么要单独测试优化器，而不是直接训练
很多人会觉得，优化器不就是torch.optim.Adam(model.parameters(), lr=1e-3)一行代码的事，有什么好测的？这个想法在简单场景下没问题，但一旦涉及以下情况，风险就出来了。
第一，优化器与模型结构的耦合。比如你用了大量 LayerNorm 或者 Embedding 层，不同优化器对这类参数的更新行为差异很大。第二，优化器与学习率调度器的配合。Warmup 阶段用 Adam 和用 SGD 的稳定性完全不同。第三，框架实现差异。同样是 AdamW，不同版本对 weight decay 的处理方式可能不一样，有的把 decay 加在梯度上，有的直接作用在参数上，结果差别很大。
单独测试的核心逻辑是控制变量。把模型固定成一个极简结构，把数据固定成可复现的随机张量，然后只改变优化器相关的配置，观察参数更新的范数、loss 曲线、梯度分布。这样出来的结论是干净的，不会被数据质量、模型复杂度这些因素干扰。
2.2 测试方案的核心设计原则
我在设计这套测试时，遵循了四条原则，这里逐条说明理由。
原则一：模型要足够小，但结构要覆盖典型层类型。我一般用一个包含 Linear、Embedding、LayerNorm 的三层小网络，参数量控制在几千到几万。太小了看不出行为差异，太大了跑得慢。覆盖这几类层是因为它们对优化器的敏感度不同，Embedding 层通常需要更大的更新幅度，LayerNorm 的参数则对 weight decay 很敏感。
原则二：数据要可复现且任务要可解。我通常构造一个简单的回归或分类任务，用固定随机种子生成数据，保证同样的输入每次得到同样的输出。任务必须是有解的，也就是说存在一组参数能让 loss 降到接近零，这样才能判断优化器是否真的在有效工作。如果任务本身无解，loss 不降你也不知道是优化器的问题还是任务的问题。
原则三：监控指标要全面。只看 loss 是不够的。我会同时记录：每步的 loss 值、参数更新的 L2 范数、梯度的 L2 范数、以及关键层参数的均值变化。这四个指标结合起来，能区分出“学习率太小导致更新微弱”“梯度爆炸导致更新过大”“weight decay 过强导致参数被压向零”等不同问题。
原则四：对比实验要有基准。每次测试至少跑两组：一组是待验证的配置，一组是已知稳定的基准配置。比如你想测试一个新的学习率，那就同时跑一个默认学习率的对照组。没有基准，单看一条曲线很难判断好坏。
2.3 工具选型与框架考量
框架层面，我主要用 PyTorch 做这类测试，原因是它的优化器实现透明，可以方便地访问梯度、参数和状态。TensorFlow 和 JAX 也能做，但 PyTorch 的动态图机制在调试时更直观。如果你用的是其他框架，思路是一样的，只是 API 调用方式不同。
具体用到的工具包括：PyTorch 的torch.optim模块、torch.nn.utils.clip_grad_norm_用于梯度裁剪测试、以及 matplotlib 或 tensorboard 用于可视化。不需要额外的第三方库，标准工具链就够了。
提示：不要用真实数据集做优化器实例测试。真实数据的分布复杂，会引入额外变量。用随机生成的、固定种子的合成数据，才能保证测试结果可复现、可对比。
3. 核心细节解析与实操要点
3.1 测试网络的搭建细节
我用的测试网络结构是这样的：一个 Embedding 层（词表大小 100，维度 16），接一个 Linear 层（16 到 32），再接一个 LayerNorm，最后输出到 1 维做回归。参数量大约在 2000 左右。这个规模的好处是，单步训练在 CPU 上只要几毫秒，跑 500 步也就几秒钟。
搭建时有几个细节要注意。第一，初始化方式要固定。我会手动设置随机种子，并且用torch.nn.init显式初始化每一层的权重，避免不同运行之间的初始化差异干扰结论。第二，Embedding 层的 padding_idx 要设好，否则 padding 对应的梯度会污染其他词的更新。第三，LayerNorm 的 eps 参数在不同框架里默认值可能不同，测试时要显式指定，避免隐式差异。
代码层面大概是这样：
import torch import torch.nn as nn torch.manual_seed(42) class TinyNet(nn.Module): def __init__(self): super().__init__() self.emb = nn.Embedding(100, 16, padding_idx=0) self.fc = nn.Linear(16, 32) self.ln = nn.LayerNorm(32, eps=1e-5) self.out = nn.Linear(32, 1) def forward(self, x): x = self.emb(x).mean(dim=1) x = self.fc(x) x = self.ln(x) return self.out(x)这段代码的关键点在于mean(dim=1)把序列维度压掉了，让整个网络变成一个简单的回归器。这样做的目的是减少变量，让优化器的行为更容易被观察。
3.2 数据构造与任务设计
数据方面，我构造一个简单的映射任务：输入是随机整数序列，目标是这些整数的某种固定函数值。比如目标就是输入序列的均值乘以一个系数。这样任务有确定解，网络只要学到这个线性关系，loss 就能降到很低。
具体做法是：生成 256 条样本，每条样本是长度 8 的随机整数序列，目标值是序列中非零元素的均值。用 MSE loss 训练。这个任务足够简单，任何正常工作的优化器都应该能在几百步内把 loss 降到 0.01 以下。如果降不下去，说明优化器配置有问题。
注意：目标值的量级要控制好。如果目标值在 0 到 1 之间，初始 loss 大概在 0.1 量级；如果目标值在 0 到 100 之间，初始 loss 会到几百。量级不同，合适的学习率也不同。我一般把目标值归一化到 0 到 1 之间，这样学习率在 1e-3 到 1e-2 之间都比较稳。
3.3 监控指标的采集与解读
训练循环里，我除了调用loss.backward()和optimizer.step()，还会额外做几件事。
第一，在optimizer.step()之前，记录梯度的 L2 范数。方法是遍历所有参数的.grad，算平方和再开根号。这个值能反映当前梯度的大小，如果它突然变得很大，说明可能要梯度爆炸。
第二，在optimizer.step()之后，记录参数更新的 L2 范数。方法是保存 step 之前的参数副本，step 之后算差值。这个值直接反映优化器这一步把参数移动了多远。如果它接近零，说明学习率太小或者梯度消失了；如果它非常大，说明学习率太大。
第三，记录关键层的参数均值。我一般看 Embedding 层和 LayerNorm 层的参数均值变化。如果 LayerNorm 的权重均值持续下降，说明 weight decay 可能过强了。
这三个指标加上 loss，构成一个四维的观察窗口。下面这个表格是我总结的指标异常与可能原因的对应关系：
| 指标表现 | 可能原因 | 排查方向 |
|---|---|---|
| loss 不降，更新范数接近零 | 学习率过小或梯度消失 | 增大学习率，检查激活函数 |
| loss 震荡，更新范数忽大忽小 | 学习率过大或 batch size 过小 | 降低学习率，增大 batch |
| loss 降后突升，梯度范数爆炸 | 梯度爆炸 | 加梯度裁剪，降低学习率 |
| 参数均值持续向零收缩 | weight decay 过强 | 降低 weight decay 或换 AdamW |
| Embedding 更新范数远小于其他层 | 稀疏梯度未正确处理 | 检查优化器是否支持稀疏 |
这张表是我踩了很多次坑之后总结出来的，基本上覆盖了八成以上的常见问题。
4. 实操过程与核心环节实现
4.1 基准配置的建立
第一步是跑一个基准配置，确认整个测试流程本身是通的。我用 Adam，学习率 1e-3，betas 默认 (0.9, 0.999)，eps 1e-8，weight decay 0。跑 500 步，每 50 步打印一次 loss 和更新范数。
基准跑下来，正常情况下 loss 应该从初始的 0.1 左右稳步降到 0.001 以下，更新范数从 1e-2 量级逐渐降到 1e-4 量级。如果基准都跑不通，那说明测试代码本身有问题，先别急着测其他配置。
这里有个细节：第一次跑的时候不要开梯度裁剪。梯度裁剪会掩盖梯度爆炸的问题，让你误以为配置是稳定的。基准配置要暴露真实行为，所以不加任何修饰。
4.2 学习率扫描实验
基准通了之后，我开始做学习率扫描。选一组学习率：1e-4、5e-4、1e-3、5e-3、1e-2，其他配置保持不变，每个学习率跑 300 步，记录最终 loss 和训练过程中的最大更新范数。
这个实验的目的是找到稳定收敛的学习率区间。我的经验是，对于这个小网络和这个任务，1e-3 到 5e-3 之间通常是最稳的。1e-4 会收敛太慢，300 步可能还没降到位；1e-2 则容易在初期震荡，loss 曲线会出现明显的锯齿。
跑完之后，我会画一张图，横轴是学习率，纵轴是最终 loss，用对数坐标。正常情况下应该看到一个 U 形曲线：学习率太小和太大都不好，中间有个最优区间。如果曲线是单调的，说明扫描范围没选对，要调整范围重跑。
4.3 优化器类型对比实验
学习率扫描之后，我固定一个合适的学习率，比如 1e-3，然后换不同的优化器跑对比。我一般会测这几个：SGD（带 momentum 0.9）、Adam、AdamW、RMSprop。
这里的关键观察点是收敛速度和最终 loss 的差异。SGD 通常收敛慢但最终 loss 可能更低，Adam 系列收敛快但有时会过拟合。AdamW 和 Adam 的区别在于 weight decay 的处理方式，如果任务对参数正则化敏感，两者差异会很明显。
我实测下来，在这个小任务上，Adam 和 AdamW 的表现很接近，都在 200 步左右收敛到 0.001 以下。SGD 需要 400 步以上才能达到类似水平。RMSprop 介于两者之间。这个结论不一定适用于所有任务，但至少说明在这个配置下，Adam 系列是更高效的选择。
4.4 梯度裁剪的阈值测试
梯度裁剪是训练稳定性的一大利器，但阈值设多少合适，很多人是拍脑袋定的。我的做法是：先跑一遍不裁剪的训练，记录梯度范数的分布，然后根据分布来定阈值。
具体操作是：在训练循环里记录每一步的梯度范数，跑 500 步，然后看这个序列的均值和最大值。如果最大值是均值的 10 倍以上，说明存在偶发的梯度尖峰，裁剪阈值可以设在均值的 3 到 5 倍。如果最大值和均值差不多，说明梯度很稳定，裁剪的必要性不大。
我实测下来，这个小网络的梯度范数均值在 0.5 左右，最大值偶尔到 3 左右。所以我把裁剪阈值设在 2.0，既能拦住尖峰，又不会影响正常更新。设成 1.0 就太激进了，会明显拖慢收敛。
提示：梯度裁剪的阈值不要设成固定值就完事。不同任务、不同模型、不同训练阶段的梯度范数分布都不一样。养成先观察再定阈值的习惯，比抄一个默认值靠谱得多。
4.5 权重衰减的敏感性测试
Weight decay 是另一个容易被忽视的参数。我做过一组对比：weight decay 分别设 0、1e-4、1e-2、1e-1，其他配置固定。观察 LayerNorm 层权重的均值变化。
结果是：weight decay 为 0 时，LayerNorm 权重均值基本稳定；1e-4 时略有下降但不明显；1e-2 时下降明显，500 步后权重均值降了大约 20%；1e-1 时权重被强烈压向零，loss 都降不下去。
这个实验说明，weight decay 不是越大越好，也不是随便设一个就行。对于包含 LayerNorm 的网络，weight decay 通常应该设得小一些，或者对 LayerNorm 参数单独排除。AdamW 相比 Adam 的优势就在这里，它把 weight decay 和梯度更新解耦了，行为更可控。
5. 常见问题与排查技巧实录
5.1 优化器实例测试中的典型问题速查
下面这张表是我在实际测试中反复遇到的问题和对应的解决方法，按出现频率排序。
| 问题现象 | 根本原因 | 解决方法 |
|---|---|---|
| loss 完全不动，更新范数为零 | 优化器没有接收到参数，或参数 requires_grad 为 False | 检查 model.parameters() 是否包含所有需要训练的参数 |
| loss 降几步后变 NaN | 学习率过大导致数值溢出 | 降低学习率，加梯度裁剪，检查是否有除零操作 |
| 不同优化器结果差异极小 | 学习率太小，所有优化器都退化成 SGD | 增大学习率重新测试 |
| Embedding 层参数不更新 | 稀疏梯度未启用或优化器不支持 | 设置 sparse=True 或换用支持稀疏的优化器 |
| 更新范数远大于梯度范数 | weight decay 过大或学习率过大 | 检查 weight decay 设置，降低学习率 |
| 多次运行结果不一致 | 随机种子未固定或数据顺序有随机性 | 固定所有随机源，包括 Python、NumPy、框架层面 |
5.2 几个容易踩的坑
坑一：忘了固定随机种子。这个听起来很基础，但我见过太多人栽在这里。PyTorch 的随机性来源不止一个，torch.manual_seed只固定了框架层面的随机，Python 的random和 NumPy 的随机需要单独固定。数据加载器的 shuffle 也要设种子。少固定一个，结果就可能不可复现。
坑二：用真实数据做测试。真实数据的分布复杂，batch 之间的差异大，优化器的行为会被数据噪声掩盖。我坚持用合成数据做优化器测试，就是为了把数据这个变量彻底排除掉。
坑三：只看 loss 不看更新范数。loss 是最终结果，更新范数是过程指标。有时候 loss 看起来在降，但更新范数已经小到 1e-8 量级，说明训练已经停滞了，只是 loss 还在缓慢滑动。只看 loss 会误判训练状态。
坑四：忽略优化器的状态初始化。Adam 系列优化器有动量状态，第一次 step 时状态是零，更新幅度和后续步骤不同。如果只跑几步就下结论，可能会被初始状态误导。我一般至少跑 100 步以上再判断。
坑五：在不同设备上对比结果。CPU 和 GPU 的浮点运算精度不同，同样的配置可能得到略有差异的结果。做对比实验时，所有配置要在同一设备上跑。
5.3 独家避坑技巧
分享几个我从实践中总结的小技巧，常规文档里不会写。
技巧一：用参数更新范数与梯度范数的比值来判断学习率是否合适。这个比值我称之为“更新比率”。正常情况下，这个比值应该在 1e-3 到 1e-2 量级。如果比值接近 1，说明学习率太大了，参数更新幅度和梯度本身一样大，容易震荡；如果比值小于 1e-4，说明学习率太小，更新微弱。这个指标比单看 loss 敏感得多。
技巧二：在训练初期打印每一层的更新范数。不同层的更新幅度应该在同一量级。如果某一层的更新范数比其他层小一两个数量级，说明这一层可能没在有效学习。常见于 Embedding 层和输出层，因为它们的梯度特性不同。
技巧三：用两个不同的随机种子各跑一遍。如果两次结果的 loss 曲线差异很大，说明配置对初始化太敏感，稳定性不够。稳定的配置应该在不同种子下表现一致。
技巧四：把优化器的 betas 参数也纳入测试范围。很多人只调学习率，忽略 betas。实际上 beta1 从 0.9 调到 0.95 或 0.85，对收敛行为的影响可能比学习率还大。特别是当梯度噪声较大时，beta1 设小一点能让优化器更快响应新梯度。
技巧五：测试结束后，把最优配置的完整参数记下来。包括优化器类型、学习率、betas、eps、weight decay、梯度裁剪阈值、batch size。这些参数是一个整体，单独记学习率没有意义。我习惯用一个 YAML 文件保存，下次直接加载。
6. 从测试结果到正式训练的迁移策略
6.1 小网络结论能否直接用于大模型
这是很多人关心的问题：在小网络上测出来的优化器配置，能不能直接搬到正式的大模型训练里？我的答案是：方向可以借鉴，数值必须调整。
小网络和大模型的核心差异在于梯度噪声的量级和参数更新的相互影响。大模型的 batch size 通常更大，梯度噪声更小，所以可以承受更大的学习率。同时，大模型的参数更多，同样的 weight decay 对整体行为的影响更复杂。
我的做法是：在小网络测试中确定优化器类型和 betas 这类结构性参数，然后在大模型上做小规模的学习率扫描。比如小网络测出 AdamW 比 Adam 好，那大模型也用 AdamW；但小网络的最优学习率是 1e-3，大模型可能要从 1e-4 开始试。
6.2 学习率调度器的配合测试
优化器实例测试通常用固定学习率，但正式训练往往配调度器。这两者需要配合测试。我的做法是在小网络测试的最后阶段，加上一个简单的余弦退火或线性 warmup，观察优化器在变化学习率下的行为。
关键观察点是 warmup 阶段。如果 warmup 步数太少，优化器在初期可能因为学习率突然增大而震荡；如果 warmup 太长，训练效率会降低。我一般让 warmup 占总步数的 5% 到 10%，然后根据 loss 曲线微调。
6.3 测试结果的可视化与记录
测试做完之后，我会把所有曲线画在一张图上，包括不同学习率的 loss 曲线、不同优化器的对比曲线、梯度范数和更新范数的变化曲线。这张图是后续决策的依据，也是团队沟通的材料。
记录方面，我用一个简单的表格保存每次实验的配置和结果。表格的列包括：实验编号、优化器类型、学习率、betas、weight decay、梯度裁剪阈值、最终 loss、收敛步数、是否出现异常。这个表格积累多了之后，能看出很多规律，比如某种优化器在某个学习率区间特别容易震荡。
提示：实验记录不要只记成功的配置，失败的配置同样有价值。知道什么配置不行，和知道什么配置行，同样重要。我自己的记录里，失败实验的数量是成功实验的三倍以上。
7. 一些个人体会与后续扩展方向
这套优化器实例测试的流程，我从几年前开始用，中间迭代了很多版。最开始只是简单跑一下 loss，后来慢慢加上了更新范数、梯度范数、参数均值这些指标，才真正能把问题定位清楚。我的体会是，优化器的问题，八成都能通过观察更新范数和梯度范数的关系来定位，剩下的两成需要看参数的具体变化。
后续如果想深入，可以往几个方向扩展。一是加入二阶优化器的对比，比如 LBFGS，虽然在大模型上不实用，但作为基准能帮助理解一阶方法的局限。二是测试混合精度训练下的优化器行为，fp16 和 fp32 的梯度范数差异很大，优化器配置需要相应调整。三是把测试自动化，写成一个脚本，输入配置列表，自动跑完所有组合并生成报告。这个我目前在做，跑一轮完整测试大概十分钟，比手动操作效率高很多。
最后分享一个小技巧：如果你不确定该从哪个学习率开始试，就用 1e-3 作为起点，然后按 3 倍或 10 倍的比例上下扫描。这个经验值在大多数中小规模任务上都适用，能帮你快速缩小搜索范围。
