经常有人问我：“我的模型为什么不收敛？”、“同样的代码换了数据之后效果怎么差了这么多？”。我第一个反问的往往是：“你用的哪个优化器？”，然后很多人就愣住了。说实话，在深度学习的整个训练闭环里，优化器是最容易被当成“黑盒旋钮”来对待的一环，但几乎所有和训练稳定性相关的疑难杂症，追根溯源都能在优化器上找到影子。这篇文章我想好好聊聊“Model-Optimizer”这个在我项目里占据重要位置的工程化组件，结合我自己的实际踩坑经历，帮大家把这个环节彻底盘明白。
先说清楚这篇文章适合谁：你如果已经能跑通一个简单的训练脚本，但对损失函数曲线为什么长这样、换优化器之后效果为什么忽上忽下、怎么把训练过程变得又稳又快感到困惑，那这篇内容就是为你准备的。我不会只罗列优化器原理，而是会把选型逻辑、超参数联动、训练工程里容易被忽略的几个物理细节一次讲透。
1. 一半的炼丹bug都和Optimizer有关：先看它在训练闭环里的真实角色
1.1 优化器不是“更新参数”，而是在“猜下一步往哪走”
很多人看优化器，觉得它就是一行代码：optimizer = Adam(model.parameters(), lr=1e-4)，然后往训练循环里一扔就完事。这种理解不能说错，但会让你在调试时完全使不上力。
我对优化器的理解是：它是整个训练过程中唯一负责“根据当前状态决定参数下一步怎么动”的组件。模型本身决定了“误差面”长什么样，损失函数决定了哪个方向是“更好”，但具体怎么在误差面上往下走、走多大步、要不要参考历史的步子、不同参数要不要区别对待——这些都是优化器说了算。
把它类比成下山过程会更直观。你的模型是一座山上的背包客，损失函数是山的高度，梯度是每个人脚底感受到的坡度。优化器就是决定这个背包客“怎么迈腿”的脑子和习惯：是每一步都重新判断方向，还是沿着一个惯性方向闷头走；是每块肌肉（参数）都用同样的力气，还是根据地形实时调整不同肌肉的发力。同一个山坡，不同习惯的人走，速度和摔跤的概率完全不一样。
1.2 从SGD到Momentum：为什么加一个“惯性”训练快这么多
早期的训练基本全靠SGD（随机梯度下降），它的更新规则简单到有点朴素：
# SGD的更新本质：当前梯度方向 * 学习率，一步一算 param -= lr * grad问题在于，真实的损失表面并不光滑。你可以把mini-batch的梯度理解为“带噪声的方向估计”——单看一步，方向可能偏得离谱，如果每一步都机械地按当前瞬时方向去走，路径就会呈锯齿状，不仅慢，还容易在小坑里打转。
Momentum（动量）的引入就是为了解决这个锯齿问题。它维护一个“历史梯度的指数滑动平均”，每次的实际更新方向是“过去一段时间的平均方向加上当前的校正”。用大白话说就是：给下山过程加了惯性，山谷里左右来回的震荡互相抵消，真正向下的趋势被放大。
# Momentum：不只是看当前梯度，还带上了历史上的“动量” momentum_buffer = momentum * momentum_buffer + grad param -= lr * momentum_buffer我自己实测下来，在CNN图像分类任务上，同样的epoch数，加了0.9动量的SGD比裸SGD收敛速度快小一倍左右，最终精度通常也更高。这个差距在loss面比较“陡峭”或者batch size偏小时的场景尤为明显。
1.3 自适应方法登场：Adam为什么能“无脑”跑通大多数模型
SGD+Momentum的问题是它对“参数尺度”一视同仁。但神经网络里的参数并不平等——有些层（比如embedding）的梯度天然就大，有些层（比如深层全连接）的梯度天然就小。如果你用同一个学习率去更新它们，那些梯度小的参数会被“饿死”，梯度大的参数又会“一步跨过头”。
Adam的核心创新在这一点上非常优雅：它对每个参数单独维护一阶动量（梯度均值）和二阶动量（梯度平方的均值），实际的更新量等于“一阶动量除以二阶动量的平方根”。翻译成人话就是：梯度大的参数，更新时自动缩小步幅；梯度小的参数，更新时自动放大步幅。这就是它“自适应学习率”名字的来源。
# Adam更新规则（简化版）：每个参数有自己的“有效学习率” exp_avg = beta1 * exp_avg + (1 - beta1) * grad exp_avg_sq = beta2 * exp_avg_sq + (1 - beta2) * grad ** 2 param -= lr * exp_avg / (sqrt(exp_avg_sq) + eps)这也解释了为什么Adam在NLP、多模态等模型结构复杂、参数尺度差异大的任务上几乎是默认选择——它不需要你对每个模块的梯度尺度做太多人工干预，相对“无脑”就能收敛得不错。
2. 主流优化器选型：SGD、Adam、AdamW，到底按什么标准挑
2.1 SGD+Momentum：老黄牛型选手，什么场景它反而最强
被Adam“娇惯”过的朋友往往看不上SGD，觉得它又慢又蠢。但说句公道话，SGD+Momentum在CV领域、尤其在使用预训练ResNet或ViT做微调时，效果经常比Adam系列好。我个人的理解是：SGD的更新路径更“老实”，每一步都直接反映当前batch的真实梯度方向，不容易因为自适应机制而把某些细微特征给“抹平”了。
一个典型的例子是目标检测里的微调。我在用SGD+Momentum微调Faster R-CNN时，loss能稳稳当当地降到预期水平；换成Adam后，前期收敛确实快，但到了后期loss尾巴明显变高，mAP也掉了1-2个点。这种“前期快、后期疲软”的现象，其实在不少文献里都被提到过——Adam在泛化性能上普遍逊于SGD。
如果你对泛化性能有极致要求，手上的数据集不大（比如几万张图以内），训练周期能接受，那SGD+Momentum依然是值得优先尝试的选项。它的另一个好处是超参数少，你只需要关注一个学习率，调起来省心。
2.2 Adam的隐患：它为什么会“忘掉”泛化能力
Adam的问题，学术界吵了很多年，我自己体会最深的是它对“学习率衰减”非常迟钝。SGD在训练后期需要配合明显的手动学习率衰减才能逼近最优解，但Adam因为每个参数都在自适应缩放，即便全局学习率不降，有效步长也常常“没感觉”。结果就是：模型在训练集上越走越顺，在验证集上却早就停止进步甚至开始反弹。这就是很多人说的Adam泛化差的一个直观原因。
另一个隐患来自它的二阶动量初始为0。训练早期，二阶动量被低估，导致有效学习率异常偏大，前期几步容易走飞。这也是为什么Adam配warmup几乎成为标配——先用小学习率把二阶动量“焐热”，再放开步子走。
2.3 AdamW：weight decay的复位，解决了我多少问题
AdamW是我这两年固定使用的主力优化器。它和Adam的唯一区别，是把“权重衰减”（weight decay）从梯度的整体缩放里拎出来，单独作用于参数本身。
在传统Adam+L2正则里，正则项会先加进梯度再做自适应缩放，实际效果变成了“梯度大的参数正则弱、梯度小的参数正则强”，非常拧巴。AdamW的做法是先按正常的Adam规则更新，再对每个参数直接乘以一个小于1的系数：
# AdamW：把weight decay从梯度里摘出来，直接在参数上做衰减 param -= lr * weight_decay * param # 这一行和Adam的梯度部分是分开的这种“解耦”带来的实际收益，我自己在BERT类模型微调上感受很明显：同样用3e-5的学习率，AdamW的验证loss比Adam低了约0.3，最终下游任务指标普遍高0.5到1个点。Hugging Face的Transformers库默认优化器就是AdamW，这本身就是一个强烈的信号。
2.4 一键选型对照表：按任务类型直接抄
我整理了一张选型表，虽然简陋但很实用，至少能帮你避开“用错优化器导致的莫名效果差”：
| 任务类型 | 我优先使用的优化器 | 理由 | 备选 |
|---|---|---|---|
| CV分类/检测（从预训练模型微调） | SGD+Momentum（0.9） | 后期泛化好，收敛稳定 | AdamW（低学习率） |
| NLP分类/实体识别（BERT等微调） | AdamW | 与预训练优化器习惯一致，泛化稳 | Adam（需调正则） |
| 从零训练的Transformer | AdamW + warmup | 训练前期稳定，支持长周期收敛 | Adam + warmup |
| 生成模型（GAN/扩散模型） | Adam（或AdamW），双优化器 | 生成任务对自适应速率更敏感 | 视生成器/判别器而定 |
| 大batch训练（batch size > 1024） | LAMB（对Transformer） / SGD大动量 | 大batch下学习率需要线性缩放 | AdamW + 大学习率 |
注意：选型表只是起点，不是终点。真正靠谱的做法是“小规模数据上做对比实验，看验证集表现，再定主力优化器”。我几乎每个新项目都会做一个优化器小pk，成本不高，收益却很实在。
3. 把Optimizer调到“顺手”状态：学习率、warmup、weight decay的内部配合
3.1 学习率是主人，其他都是仆人
如果你只能调一个超参数，那必须是学习率。模型能不能收敛、收敛到多好、会不会震荡，学习率几乎起决定性作用。
我的经验值是：Transformer类模型用AdamW时，学习率从1e-5到5e-5这个区间里探索，默认取3e-5；CNN类用SGD时，从0.01到0.1探索，默认取0.02到0.03。但这不是铁律。学习率与batch size存在线性缩放关系：batch size翻倍时，学习率一般也乘以2，否则有效更新步长会相对变小。
一个很小的技巧：如果你的训练“loss下降缓慢，但验证指标还能涨”，可以试试把学习率放大2倍到3倍，很多时候训练速度会突然快起来。反过来，如果loss在下降但验证指标已经开始退化，把学习率缩小到原来的0.5倍，往往能稳住。
3.2 warmup不是玄学：它保护的是训练早期那几步
warmup，即前若干步用一个比较小的学习率预热，然后逐步加到目标学习率。很多人嫌麻烦不愿意加，但它在两个场景下几乎不可或缺：
- 使用Adam/AdamW时：二阶动量尚未被“焐热”，初始有效步长过大，warmup可以防止前几步把embedding或分类层直接推飞。
- 使用大学习率时：模型起始权重离收敛点很远，如果一开始就大步走，容易进入一个错误的误差面区域，后面再想拉回来就难了。
我自己惯用的配置是线性warmup + 余弦退火（cosine decay），warmup步数占总训练步数的5%到10%。例如总共训练10万步，warmup设5000到10000步。这个组合在多种任务上表现稳定，几乎成了我的默认配置。
# 一个典型的warmup + cosine调度器配置示例（PyTorch） from torch.optim.lr_scheduler import LinearLR, CosineAnnealingLR warmup_steps = 1000 total_steps = 20000 warmup_scheduler = LinearLR(optimizer, start_factor=0.01, total_iters=warmup_steps) cosine_scheduler = CosineAnnealingLR(optimizer, T_max=total_steps - warmup_steps)3.3 weight decay：一个常年被误解的正则化开关
weight decay在AdamW里是直接乘在参数上的，相当于“每隔一步，参数向0靠拢一点点”。它的作用不是“让loss更低”，而是“防止参数变得太大”，从而提升泛化能力。
我见过很多人把weight decay调到0.1甚至更大，理由是“想更狠地正则”，结果模型欠拟合，连训练loss都下不去。我的习惯是：默认0.01到0.05之间，具体看正则需求。数据集小、模型大时，weight decay可以调大一点（0.05以上）；数据集充足时，0.01往往就够。
还有一个容易踩的坑：对bias、LayerNorm的scale参数，一般不做weight decay。原因很简单，这些参数大多是“位置偏移”或“归一化强度”，并不存在“过大”的泛化问题。PyTorch里给优化器分组传递参数可以轻松实现这一点：
optimizer_grouped_parameters = [ {"params": [p for n, p in model.named_parameters() if "bias" in n or "LayerNorm" in n], "weight_decay": 0.0}, {"params": [p for n, p in model.named_parameters() if "bias" not in n and "LayerNorm" not in n], "weight_decay": 0.01}, ]3.4 我自己惯用的几组训练配置
把多个超参数看成一套完整配置而不是孤立项之后，训练效果会稳定很多。我直接把我常用的几组配置贴出来供参考：
- BERT类模型微调：AdamW，lr=3e-5，weight_decay=0.01，线性warmup（5%步数）+线性衰减，batch size 32。
- ResNet系列从零训练（ImageNet级别数据集）：SGD+Momentum（0.9），lr=0.1（配合batch size 256），weight_decay=1e-4，cosine退火，无warmup（或极短warmup）。
- 扩散模型从零训练：AdamW，lr=1e-4，weight_decay=0.01，配合gradient clipping到1.0。
- GPT类大模型从零预训练：AdamW，lr=3e-4，weight_decay=0.1，warmup比例1%，cosine退火到最大lr的10%，并开启梯度裁剪至1.0。
4. 训练现场踩过的Optimizer相关坑（附完整排查思路）
4.1 现象：loss卡在0.693不下降，问题出在“优化器没更新参数”
有一次我在微调一个二分类模型时，loss一直卡在0.693。熟悉二分类的朋友都知道，0.693这个值很特殊——它对应着“模型对每个样本都输出概率0.5”，也就是完全没学会。我一开始怀疑数据有问题，来回检查了三遍数据没发现问题。最后我打印了model.parameters()的梯度，发现梯度全为0，然后才注意到：修改网络结构之后我忘了重新optimizer = AdamW(model.parameters(), ...)，新的模型参数根本没有被优化器绑定。
这个坑非常低级，但实际工作中太常见了。排查思路是：在训练循环里加两行调试代码，直接观察梯度是否正常流动，而不是盲目调整学习率或者网络结构。
# 训练循环中的调试检查：确认梯度确实在被“优化” for name, p in model.named_parameters(): if p.grad is None: print(f"WARNING: {name} has no grad") elif p.grad.abs().max() == 0: print(f"WARNING: {name} has zero grad")4.2 现象：梯度爆炸，grad clip真的够用吗
训练初期loss突然飙到NaN，大概率是梯度爆炸。预防手段有两个：一是gradient clipping（梯度裁剪），二是降低学习率。我先说结论：grad clip是“兜底”，不是“万能药”。
当梯度值达到1e10以上时，即便裁剪过后参数更新，二阶动量依然可能处于异常状态（比如Adam的exp_avg_sq里存了巨大的梯度平方），后面再想恢复就很难。所以，如果你的训练需要频繁仰仗grad clip才能稳住，真正该做的是把学习率降下来，或者找出导致梯度爆炸的结构性问题（比如不使用残差连接的深层网络）。
我的建议配置是grad clip的阈值设为1.0（对Transformer类）或5.0（对CNN类），同时配合学习率warmup。两者一起用，训练过程会明显安稳。
4.3 现象：fp16训练下Adam出现NaN，不是你的代码错了
用NVIDIA GPU进行混合精度训练时，一个高频现象是：Adam优化器在fp16下时不时报NaN。根因在于Adam需要维护exp_avg和exp_avg_sq两个状态，而fp16能表示的数值范围很小，梯度尺度极端时很容易溢出到Inf/NaN。
解决思路有两个方向：一是把优化器状态保持在fp32（PyTorch的AMP对Adam的默认行为就是这样）；二是直接用bf16而不是fp16——bf16保留了和fp32同等的指数范围，在支持它的GPU（如A100、H100）上训练时几乎不会因为指数溢出产生NaN。
我的建议是：如果硬件支持，优先用bf16混合精度；如果只能用fp16，务必确认优化器参数在fp32空间更新，不要贪图省显存而把优化器状态也降到fp16。
4.4 断点续训时没有正确恢复optimizer状态导致的“一切回到解放前”
断点续训是个很常见的需求。我见过不少同事的做法是只保存了model.state_dict()，然后还在重新创建optimizer后从某个学习率开始继续训练。结果往往就是：训练曲线突然崩掉，或者模型表现比中断前还差。
原因很简单：optimizer里不但有当前的参数，还有momentum buffer、exp_avg_sq等历史状态。如果你丢失了这些状态，参数虽然还是旧的，但“惯性”和“每个参数的缩放因子”都是全新的，相当于一个本来按既定节奏走的人突然被清零记忆再出发，步伐节奏完全混乱。
正确的做法是把optimizer的state_dict和scheduler的state_dict一起保存和恢复。
# 保存checkpoint torch.save({ "model": model.state_dict(), "optimizer": optimizer.state_dict(), "scheduler": scheduler.state_dict(), "step": global_step, }, checkpoint_path) # 恢复checkpoint checkpoint = torch.load(checkpoint_path) model.load_state_dict(checkpoint["model"]) optimizer.load_state_dict(checkpoint["optimizer"]) scheduler.load_state_dict(checkpoint["scheduler"]) global_step = checkpoint["step"]注意：如果你改了超参数（比如中途降低学习率），请在恢复时覆盖optimizer里的相应字段，否则旧状态会接管一切。
5. 从“只跑通”到“可复现”：Optimizer的工程化管理经验
5.1 在配置里给optimizer单独留一个段落：理由和模板
很多项目把学习率和优化器参数散落在训练代码的各个角落，换实验像在做考古，极其痛苦。我的习惯是用yaml配置文件把优化器信息集中管理起来，并让训练代码对这个配置有完整的“唯一真源”（single source of truth）意识：
# config/train.yaml 中的optimizer段落 optimizer: name: AdamW lr: 3e-5 weight_decay: 0.01 betas: [0.9, 0.999] eps: 1e-8 scheduler: name: warmup_cosine warmup_ratio: 0.05 min_lr_ratio: 0.1 # 退火到最大lr的10%配置文件一旦固定下来，就要让实验记录系统自动记录这个配置文件、代码版本、数据的hash值。我吃过最大的亏就是：训练完模型之后，忘了记当时的优化器配置，结果几个月后要复现，只能靠Git历史一点点翻，非常低效。
5.2 记录optimizer的一切：版本、超参数、甚至随机种子
优化器行为还有一个隐性因素：参数更新顺序。PyTorch的optimizer按参数组的顺序更新，如果你改了模型代码里named_parameters的返回顺序（比如改了网络注册顺序），优化器的行为虽然不会本质改变，但在浮点加法顺序敏感的情况下，可能会带来微小的结果差异。为了让实验可复现，我自己会在每个实验目录下保留一个experiment_meta.yaml，内容大致包括：
- 优化器名称和全部超参数
- scheduler名称和调度参数
- PyTorch/框架版本、CUDA版本、GPU型号
- 随机种子，以及是否开启了
torch.backends.cudnn.benchmark和torch.use_deterministic_algorithms - 数据集的shuffle种子和采样顺序
5.3 换框架时optimizer带来的微妙差异
同样的AdamW，PyTorch、TensorFlow、JAX实现出来的系数默认值可能不完全一样。这一点在复现别人论文里尤其致命。我遇到过最典型的情况是：论文里写的学习率明明是3e-5，但用PyTorch复现时怎么都不收敛。后来仔细一看，对方用的是TensorFlow的AdamW实现，其中的epsilon默认值是1e-7而不是PyTorch的1e-8，而且它对weight decay的处理方式也有细微差别——AdamW在TensorFlow里等同于“decoupled weight decay”实现，而在某些PyTorch版本中需要依赖optimizer的单独实现。
想避坑，只有一个笨办法：把论文/官方代码里的优化器配置逐字复制，包含eps、betas、weight_decay、以及是否配合AMSGrad全部对齐。很多人只抄学习率，其他参数全用默认值，结果复现不出来还怪论文，其实大多是优化器配置没对齐。
6. 结合我最近的实验：Model-Optimizer在长尾数据集上的行为记录
最后聊一个我最近做的文本分类实验，来展示优化器在真实场景里的微妙之处。数据是不均衡的长尾分类（几百个类别，大部分类别样本极少），模型是RoBERTa-base。
我一开始用了标准的AdamW，lr=3e-5，训练了10个epoch。训练loss一路下降，验证集整体精度看起来也还行，但按类别细分后发现：尾部类别的F1非常差，比头部类别差了20多个点。换了好几种数据采样方法，改善都有限。
后来我做了个小改动：把优化器从AdamW换成SGD+Momentum（lr=0.01），并且在分类头单独设置了一个略高的学习率。结果出乎意料，尾部类别的F1涨了将近5个点。我复盘之后的理解是：AdamW的自适应机制在训练后期太“迁就”头部类别的梯度，导致尾部类别的细微信号被淹没；而SGD+Momentum的更新更“一视同仁”，对低频次特征的利用更充分。
那次实验给我的触动很大：好多时候不是模型不行，而是优化器和你的数据分布不匹配。如果你的数据集不均衡，不妨把SGD+Momentum列入备选优化器，认真跑一组对比实验，不要因为“大家都在用Adam”就放弃其它选项。
还有一个小技巧分享给你：如果你在训练过程中发现验证loss长期下不去，可以先打开梯度监视（grad norm），确认梯度没有消失；确定梯度正常后再去调优化器的学习率策略。顺序不要反，否则很容易白费力气。优化器是一个需要被认真对待的组件，它值得你为每个项目单独留出调试时间。
