去年夏天我遇到过一场挺无语的训练事故一个7B模型微调任务为了赶进度同时换了三样东西——优化器从AdamW换成了Lion开了混合精度还把batch size翻了一倍。结果模型跑到第150步左右loss直接变成NaN再往后几步就飞成inf。整整一个周末我都在怀疑数据和代码写错了最后定位下来哪哪都没坏纯粹是优化器、学习率、精度策略这三者不匹配。从那次之后我就意识到一件事所谓的Model-Optimizer不是一个孤立的优化器模块也不是一段调参脚本而是一整套围绕模型训练的组合工程。它解决的核心问题是三个能不能收敛收敛多快显存和算力吃不吃得消。这篇文章想把这套组合工程里最关键的几块拆开讲清楚包括优化器选型、学习率调度、混合精度、梯度累积、多卡并行以及收敛异常排查适合正在做预训练、微调或者是被多卡训练显存折磨的工程师参考。1. 别急着换“网红优化器”先把当前训练卡在哪搞清楚这两年新优化器出得很快Lion、Sophia、Schedule-Free之类的名字经常出现在热点榜上社区里也时不时有人晒“换了某种优化器之后收敛速度提升X倍”。但我在实际项目里看到的更多是反例模型在AdamW下稳稳当当换成Lion之后loss像过山车或者Sophia在一半任务上表现不错换个batch size就发散发散。问题很少出在优化器本身更多是使用场景和超参完全不匹配。1.1 从Loss曲线上反推真正的瓶颈在动优化器之前我会先盯着loss曲线回答一个问题当前训练过程的瓶颈到底是收敛质量、训练速度还是数值稳定性训练速度慢但loss趋势健康这种最常见。显卡利用率上不去、数据加载卡IO、DDP同步开销过大都会让一个本来合理的优化器配置显得“慢”。这时候你换Lion或Sophia顶多是把每步计算量稍微降低一点收益远远赶不上把数据管道问题修好。我以前有个项目loss曲线漂亮得不行但每步耗时离谱最后排查发现是磁盘随机读取小文件导致的优化器根本不需要换。如果loss长期在一个高位附近波动降不下去这往往不是优化器问题而是学习率设置过小、模型容量不够、或者是标签噪声太大。如果loss一开始下降很快训练到中期突然反弹先别怀疑优化器优先查学习率是不是过高、batch size是否太小导致梯度估计方差过大以及是否存在灾难性遗忘式的任务冲突。最刺眼的是loss突然变成NaN或inf。这种情况通常要优先查数据里有没有异常值、混合精度配置是否合理、梯度裁剪有没有开而不是第一反应去换优化器。我的经验是把loss曲线按“长期不降”“中途反弹”“突然爆掉”“整体缓慢”这四类区分开再去决定下一步动哪里比盲目调参有效得多。1.2 主流优化器选型速查表这里我整理了一份这几年实测下来比较稳的选型参考覆盖了最常见的几类训练场景。表里的学习率是一个相对可靠的起点但不是绝对答案真实项目里还是要小范围扫描。优化器适用场景典型LR起点显存占用注意事项SGD MomentumCV迁移、小规模微调、GAN0.01~0.1最低收敛稳但慢大模型很少用Adam通用任务早期验证1e-4~3e-4较高建议在Adam基础上做L2正则时要小心AdamWTransformer微调、大部分生成任务1e-5~5e-5大模型较高当前最稳的事实标准weight_decay建议0.01LAMB大批量预训练、BERT类任务1e-4~2e-4较高适合大batch几万甚至几十万场景LionCV分类、部分扩散模型3e-5~1e-4较低显存占用小但LR通常要比Adam缩小约5~10倍Sophia大模型预训练5e-5~1e-4接近Adam实现复杂对代码鲁棒性要求高AdamW之所以能成为Transformer微调的事实标准核心在于它把weight decay和L2正则解耦了能更好地控制大模型参数范数在大规模数据下权重衰减的幅度不容易漂移。Lion省显存是因为它不需要维护二阶梯度动量相当于只存一份模型副本加少量额外状态但这也意味着它对学习率极其敏感。我见过很多人从AdamW切到Lion后学习率还是1e-4结果loss直接起飞其实就是没有做对应的LR缩放。选优化器我给自己定了一条原则先明确要解决什么瓶颈。显存不够优先看混合精度和FSDP吞吐上不去看数据管道和通信收敛不稳先查LR和warmup。只有当你确认瓶颈真的出在优化器本身的迭代效率上才值得去换新优化器。大多数情况下AdamW加一套合理的调度策略已经能打赢八成项目。2. 学习率与衰减策略才是“另一半”优化很多人在优化器上反复横跳却很容易忽略一个事实同一个优化器配合不同的学习率调度表现差距可能比更换优化器还大。Model-Optimizer这套组合里LR调度至少占一半的权重。优化器负责“怎么走”学习率负责“每一步走多远”两者必须一起设计。2.1 Warmup为什么能救回早期震荡Warmup在现在的训练配置里几乎是标配但很多人对它的理解停留在“前人经验”。实际上模型刚初始化时参数分布偏离最优解很远早期梯度的均值和方差都偏大尤其是Transformer里LayerNorm和Embedding的梯度在头几个step常常异常巨大。如果在第一步就用峰值学习率参数可能直接被推到loss landscape里的陡峭区域表现出来就是第10步到第50步之间loss暴涨或者出现NaN。Warmup的本质是给模型一个“预热期”学习率从接近0线性增长到目标值让参数先适应数据分布和梯度尺度再进入快速学习阶段。我经验里一个比较稳的设置是warmup step占训练总步数的2%~5%。在预训练任务上可以取到5%微调任务通常2%~3%就够。像HuggingFace Trainer里的warmup_ratio0.03就是一个不错的通用起点。还有一个很容易被忽略的细节当你增大batch size时warmup步数也需要同比拉长。原因是更大的batch让梯度估计更稳定但单个批次带来的梯度方向更“权威”参数变化方向更明确这时候如果warmup太短模型反而容易被前几个大梯度带偏。我试过把batch从32提到64却只保留原来warmup步数训练初期loss震荡明显加重把warmup步数也翻倍之后才恢复稳定。2.2 Cosine Decay和线性衰减到底怎么选学习率衰减策略主流就两类线性衰减和余弦衰减再细节一点还有多项式衰减和warmupcosine的组合。余弦衰减是我在微调和预训练任务上用得最多的方案它在训练中后期保持一个较高且逐渐下降的学习率接近结束时又快速把LR压到接近零帮助参数进入更平滑的极小值区域。线性衰减则更直白从峰值线性降到零实现简单、行为可预期。实验对比下来如果训练步数足够长最终精度两者差距通常不大但cosine在中期更稳对LR峰值选择的敏感度更低。我自己的习惯是总步数固定、训练充分时选cosine步数很少、只想快速验证某个idea是否work时选线性因为它的行为更好解释。需要强调一点衰减策略必须和warmup配合使用而不是二选一。正确的组合是前端warmup把LR拉起来后端decay把它压下去。在HuggingFace里配置就是warmup_ratio0.03加上lr_scheduler_typecosine基本上是这几年微调任务最通用的一套组合。2.3 一套可以直接上手的初始超参组合很多读者要的不是理论而是起点下面这套是我跑7B模型微调和13B模型LoRA微调时比较常用的初始配置拿过去可以直接作为第一版跑通AdamWbeta10.9beta20.999eps1e-8learning_rate5e-57B微调LoRA可以放到1e-4~2e-4weight_decay0.01warmup_ratio0.03lr_scheduler_typecosine开启梯度裁剪max_grad_norm1.0这套配置的核心逻辑是AdamW提供稳的更新方向cosine负责把后期收敛做扎实warmup抵抗早期震荡梯度裁剪兜底意外的大梯度。对比用固定学习率加AdamW的方案这套在多个项目里都明显减少了loss突然拔高的情况。如果你的模型参数量更大比如30B往上Learning Rate要相应往下降。大模型的loss landscape更陡峭一个在7B上跑得很好的5e-5放到30B上可能让loss直接下不去。我一般的习惯是7B用5e-513B用3e-530B以上先试试1e-5~2e-5跑100步左右看loss下降速度再决定要不要放大。3. 让显存与速度兼得的三板斧AMP、梯度累积、梯度检查点显存不够几乎是中大型模型训练的常态。很多人一开始只想换优化器来省显存但实际上那只是杯水车薪。真正把训练跑起来的三板斧是混合精度、梯度累积和梯度检查点这三样加在一起常常能把一个显存爆炸的配置救回来。3.1 混合精度里的GradScaler远不止一个开关混合精度的原理我不赘述了核心是把占用大头的前向激活和梯度用FP16或BF16存优化器状态保持FP32精度。很多人开了AMP之后遇到一个问题loss曲线出现类似“心跳”的锯齿纹甚至训练到一半突然出现一次loss跳变。这通常不是模型坏了而是GradScaler在动态调整loss scale。AMP训练时梯度在反向传播过程中会乘上一个很大的比例因子防止FP16下梯度精度不够。如果某一步乘完scale之后梯度溢出变成了inf这步更新会被跳过GradScaler会把scale调小正常一段时间后又调大。体现在loss曲线上就是偶尔一个明显的突变如果你的日志里记录了scale值能看到它正好在那个时间点变化。实操上我的建议是至少在日志里把GradScaler的scale值打出来和loss一起观察。如果频繁出现loss跳变但scale一直在下调那说明模型里确实存在梯度不稳定只靠AMP的动态缩放不够需要配合梯度裁剪或降低LR。另外P40这类老卡不支持BF16只能FP16更要留心溢出问题。顺便提一句在A100/H100这类硬件上我建议优先用BF16它的指数范围和FP32一致基本不会发生溢出GradScaler都不太需要训练稳定性会高很多。3.2 梯度累积不是把batch塞进显存那么简单梯度累积的思路好理解原来8 batch一步现在用1 batch累4步等效batch是4再把参数更新一次。这样可以让你在显存很小的情况下模拟大批量训练。但它在工程上有两个坑。第一如果是带BatchNorm的模型梯度累积不等于真的大批量因为BN的统计数据是按每个小batch计算的。Transformer结构不太依赖BN问题不大但CNN模型用这套组合就要小心。第二在DDP分布式训练下梯度累积如果处理不当每一步都会触发一次全量梯度同步通信量和计算量都白白浪费。正确做法是中间累积步用model.no_sync()包起来只让最后一步触发梯度同步。HuggingFace Trainer会自动处理这部分但如果你是自己写的PyTorch训练循环一定要记得加。还有个隐藏问题有效batch增大之后学习率也要相应放大。很多人梯度累积配到8倍等效batch却还沿用原来的LR结果模型收敛变慢或者loss震荡。一般可以按有效batch的比例线性增加LR但这需要同时加长warmup。batch变大梯度估计更准可以走更大步前提是得给模型一个适应的过程。3.3 梯度检查点的时间换空间账本梯度检查点是另一个把显存从悬崖边拉回来的手段。它的原理很多人听过前向过程不保存每一层的中间激活值等到反向传播需要梯度时再重新算一遍。也就是说用更多的计算量换更低的显存峰值。实测下来开启梯度检查点后显存一般能下降30%~50%训练时间会上涨约20%~30%这个交换在中大模型场景下非常划算。我在单卡24G上微调13B LoRA时不开启检查点连加载权重都勉强开了之后不仅跑起来了还能把batch size提到4整体训练速度反而比降低batch size硬跑更快。具体实现上HuggingFace里就是model.gradient_checkpointing_enable()或者TrainingArguments里gradient_checkpointingTrue。更精细的做法是只对Transformer的Attention层或者每隔几层开启一次检查点而不是全部开启。有些代码库支持按层列表指定checkpointed_layers这样可以人工找一个显存和时间都更优的折中点。4. 多卡并行后优化器配置必须跟着分布式方案一起改单卡训练把模型跑通只是第一步真正让人头疼的是从单卡扩展到多卡过程中的种种配置变化。很多人在单卡上配好的优化器参数一上多卡全变了味第一个要背锅的往往就是学习率没有重新调整。4.1 DDP带来的LR缩放问题DDP和单卡的最大区别是每次更新等效于在大batch上计算梯度。8卡训练每卡batch 2全局有效batch就是16。如果还沿用单卡batch 2时的学习率训练很容易变得不稳定。这时候需要应用基本的线性缩放规则Learning Rate按照有效batch size的倍数大致同比放大。batch从2变成16LR可以在原来基础上放大2~4倍而不是直接放大8倍具体倍数跟模型规模有关越大越要保守。同时warmup也要跟着调整。DDP训练初期各卡的同步通信会带来额外开销令前几百步的梯度估计比单卡更不稳定warmup步数适当增加能明显减少前期毛刺。我在一个多卡训练任务里遇到过模型前50步loss高点忽高忽低把warmup从200步加到500步之后曲线立刻顺了。4.2 FSDP为什么能吃掉7B模型的显存当模型大到连加载都困难时DDP就不太够用了。FSDP的核心思路是分片把参数、梯度和优化器状态拆成很多份分别放在不同卡上。这样每个GPU只需要保存一小部分状态。7B模型如果用AdamW全量微调显存需求按最粗糙的算法也要在100GB以上单张80G的A100根本放不下但用FSDP把优化器状态分片后配合混合精度和梯度检查点一张80G甚至A800都能跑得动。FSDP和手工实现梯度同步不一样它对显存的压缩主要来自两层一是优化器状态分片这和大规模Adam优化器动不动几十GB的参数状态完全不同二是参数和梯度也是分片的反向传播结束后会释放掉。代价就是通信量显著增加同一批数据内需要多次拉取和聚合参数。如果卡间网速弱模型虽然能跑但训练吞吐会很难看。我的经验是在数据中心级的高速网卡环境下FSDP很香但在普通PCIe或以太网办公环境里优先考虑用梯度累积降低通信频率再把FSDP的CPU offload打开来换显存。4.3 显存估算的速算公式与实操验证有个快速的显存估算方法全量训练一个模型大约按每参数16字节算。以7B模型为例参数本身FP16是14GB梯度是14GB优化器状态AdamW里包括FP32的master weight、momentum、variance三份又是84GB以上加一起粗算112GB左右。这还没算中间激活值所以7B全量微调在单卡80G上注定不行。如果改用LoRA之类参数高效微调方法可训练参数可能只有原来的1%甚至更低显存大头变成冻结权重加激活值7B就能在24G卡上跑了。这个速算公式主要用来做配置前的预估避免方案设计阶段就埋下显存炸弹。开训之前我一般会先用一个很小的batch把模型加载起来跑两步看实际显卡占用再按比例推算目标batch下的显存需求误差通常不大。5. 当Loss变成NaN一条值得背下来的排查链路模型训练过程中遇到NaN几乎是每个训练工程师必经的噩梦而且往往是在一个看起来很正常的step里突然出现。我第一次遇到时花了整整一天乱查后来总结出一套固定的排查链路按顺序执行基本能锁定八成问题的源头。5.1 先做分类别一头扎进代码里遇到NaN我的第一个动作不是翻代码而是确认它是真NaN还是假NaN。真NaN是loss直接变空或inf假NaN是loss变成很大的数值后又恢复正常对应的是梯度溢出被AMP处理器吞掉或跳过。这两种的修复方向完全不同。如果是真正的NaN再看它出现的位置。是训练刚开始就出现还是训练了很久之后突然出现。开始就出现在数据或初始化有问题例如Embedding初始化异常、标签里有NaN、或者输入数据包含非数值。训练中途出则优先考虑学习率过大、优化器状态损坏、混合精度溢出。5.2 我常用的五个排查步骤第一步固定随机种子并尝试小批量复现。很多人遇到NaN后的第一反应是改配置再跑一遍这样很难定位因为不同步的随机流会让现象不可复现。我会把batch_size缩到最小固定seed确保同一个数据顺序下能稳定复现同一个step的NaN。第二步回滚到纯FP32。如果FP32下问题消失那就可以锁定混合精度溢出相关。这步能很快把问题范围从“算法问题”缩小到“数值精度问题”。转化到BF16后基本不会溢出所以新卡上我更推荐直接用BF16。第三步检查数据和标签。把训练数据里是否存在inf和NaN写成一个单独的检查逻辑。我实际遇到过标签里第8300条样本有一个超大异常值导致每轮跑到那一步就NaN排查时发现loss曲线极其规律每隔固定步数就爆一次这类问题看数据比看代码更快。第四步检查梯度范数。可以打印每一步的grad_norm观察它是不是在NaN之前已经变成一个异常大的值。grad_norm达到数百甚至上千时就说明参数已经处在悬崖边下一步就可能爆掉。此时梯度裁剪max_grad_norm1.0能帮你把模型从崩溃边缘拉回来。第五步把优化器换回AdamW。不是长期方案而是作为对照实验。如果换成AdamW后同样的配置不再NaN那就是当前优化器超参不匹配。我那年从AdamW换Lion导致NaN就是通过这一步锁定的最后只是把LR从1e-4降到2e-5问题就消失了。5.3 高频症状对照表症状常见原因排查重点修复方向固定步数后规律性NaN数据里有异常值数据预处理和标签清洗数据或采样时剔除inf/nan训练刚开始就NaN初始化不当、输入异常Embedding层与LR降低LR、检查输入、调整初始化开启AMP后偶发NaNFP16溢出GradScaler和grad_norm换BF16开梯度裁剪无限大规模多卡训练中loss爆涨LR过大或warmup不足有效batch和LR比例缩放LR、延长warmup优化器换新后立刻发散优化器LR体系不匹配对比AdamW结果按新优化器重新扫描LR排查链路的核心原则就一条一次只改一个变量并把变量变化后的现象记下来。没有记录就不会有对比没有对比就很难定位这是我在排错过程中吃过最大的一次亏换来的经验。6. 一份可以直接复制使用的Model-Optimizer配置模板给一堆零散的建议不如直接给一份完整的模板。下面这份配置是我目前在多个项目里验证过的组合可以直接抄到代码里再根据自己任务做微调。6.1 基于HuggingFace Trainer的配置from transformers import TrainingArguments training_args TrainingArguments( output_dir./model_optimizer_training, per_device_train_batch_size1, per_device_eval_batch_size1, gradient_accumulation_steps8, learning_rate5e-5, lr_scheduler_typecosine, warmup_ratio0.03, optimadamw_torch, weight_decay0.01, max_grad_norm1.0, fp16False, bf16True, gradient_checkpointingTrue, logging_steps10, save_steps100, )这组参数是针对7B~13B模型微调场景设计的。batch设成1加梯度累积8步等效batch为8显存压力被梯度检查点承接了一部分BF16避开FP16的数值溢出问题cosine加warmup把LR生命周期拉满梯度裁剪兜底。第一次跑建议把batch加到能塞进显存的最大值然后在梯度累积步数里把等效总batch控制在合理范围。需要说明的是我刻意没有用fp16True而是用bf16True。在V100/A100等现代设备上BF16的数值范围和FP32接近省心很多不必担心GradScaler出不稳态。如果你用的是P40或者老式设备BF16可能不支持那就得退回fp16True并定时检查GradScaler日志。6.2 纯PyTorch环境下的自定义实现如果你的代码不用Trainer而是自己写训练循环下面这段可以直接参考import torch from transformers import get_cosine_schedule_with_warmup def build_optimizer_and_scheduler(model, train_steps, lr5e-5, warmup_ratio0.03): optimizer torch.optim.AdamW( model.parameters(), lrlr, betas(0.9, 0.999), eps1e-8, weight_decay0.01, ) warmup_steps int(train_steps * warmup_ratio) scheduler get_cosine_schedule_with_warmup( optimizer, num_warmup_stepswarmup_steps, num_training_stepstrain_steps, ) return optimizer, scheduler训练循环里有一个细节很容易翻车如果你开启了学习率调度需要在每个optimizer.step()之后调用scheduler.step()而不是在zero_grad之前。否则warmup和decay的节奏会跟实际参数更新错位。还有一个技巧是日志里同时记录当前LR每次训练完回看loss和LR的联动关系很快就知道是不是LR策略不对劲。6.3 记录哪些日志复盘才不会靠猜我自己的训练日志模板里固定记录这几个指标loss、learning_rate、grad_norm、loss_scale仅FP16、显存峰值。只有保存在一起才能在事后把NaN、loss震荡这些现象跟某个具体变化绑在一起。很多人只记loss遇到问题就靠记忆猜测当时改了什么这是最浪费时间的复盘方式。我习惯每隔50或100步输出一个summary训练结束后再统一落到CSV里用Excel或脚本拉曲线。像“第800步出现NaN”和“第800步时grad_norm突然到了2000”这两条信息放在一起基本一秒就能判断是梯度爆炸问题而非数据问题。这套思路其实就是Model-Optimizer工程化的核心不是把优化器调到完美而是让每一条“配置、状态、结果”的链路都有迹可循。那次踩坑之后我每次开新训练的第一件事就是先建好这套日志体系再谈跑得快不快。
