1. 先厘清概念Model-Optimizer到底在优化什么接到这个项目的时候团队给它的代号就是Model-Optimizer。名字很直白但打开需求文档才发现不同人对模型优化这四个字的理解完全不一样。做训练的说优化器选型做部署的说量化剪枝做算法的说loss收敛做产品的说推理延迟——最后项目评审会上差点吵起来。一个看似简单的命名背后其实是三类完全不同的工作。我花了差不多一周时间才把边界理清楚这里先给各位一个全景图后面各章节再逐层拆开。模型优化在实战中至少包含三个独立但互相影响的层面优化层面核心目标典型手段归属阶段训练侧优化让模型更快收敛、精度更高优化器选型、学习率调度、正则化训练阶段结构侧优化降低模型参数量与计算量剪枝、低秩分解、结构重参数化训练后/训练中推理侧优化减少内存占用、降低延迟量化、算子融合、蒸馏、缓存部署阶段大多数团队的问题在于只盯着其中一层。训练团队把AdamW换成Lion精度涨了0.3个点就欢呼部署团队把模型从FP16压到INT8延迟降了40%就收工。但真正让Model-Optimizer这个项目跑出价值的是把它当成一条完整链路来设计训练阶段的决策会直接影响部署阶段能做什么优化部署阶段的瓶颈反过来要求训练阶段做调整。举个例子。训练时如果用了SGDMomentum得到的模型权重分布通常比较集中对后训练量化PTQ更友好而用Adam训练出来的权重离散度大量化时掉点更严重。这不是玄学是优化器的更新机制导致的权重分布差异。后面第4章我会详细讲这个联动关系。所以这篇博文不打算只讲某个具体工具或算法而是把这套我实际跑完整个项目的心得整理成一条可复用的优化链路。核心覆盖三块训练侧优化器怎么选、部署侧压缩怎么做、两侧怎么配合才能不吃亏。适合正在做模型交付、被性能指标困扰的算法工程师和部署工程师也适合刚接触模型优化想建立全局认知的同学。2. 训练侧优化器选型从SGD到Lion让模型先收敛再说训练侧的优化器选型是Model-Optimizer项目里第一个被摆上桌的问题。因为不管后面做什么压缩、量化前提都是模型本身训练得足够好——一个没收敛好的模型后面所有优化都是在放大噪声。2.1 优化器之间到底差在哪很多同学对优化器的理解停留在选Adam就完事了。但真正搞过几轮实验就会发现优化器之间的差异不是一星半点。优化器的本质是回答一个问题根据当前梯度参数该往哪个方向走、走多大步。SGD只看当前梯度方向Momentum加上了历史速度Adam在此基础上还针对每个参数维度的梯度量级做了归一化。这就是为什么Adam对学习率的敏感度远低于SGD——它内部有一套自适应机制在调节步长。而AdamW和Adam的区别藏在权重衰减weight decay的实现位置上。Adam把权重衰减直接加在梯度上AdamW则把它从梯度里拆出来、单独在参数更新时施加。这个改动看起来不起眼却解决了Adam在带L2正则时泛化性掉队的问题。业内LLM和视觉Transformer的训练几乎清一色选AdamW不是没有道理的。至于Lion是Google在2023年放出的一匹黑马。它用符号函数替代了Adam里的一阶动量更新只保留梯度的方向信息。实际效果是内存占用更低只需要维护一个动量项训练速度更快且在部分大模型任务上精度还能反超AdamW。2.2 我实际跑出来的选型结论项目里用同一套CV模型分别跑过四种优化器参数量约9000万batch size 128训练200个epoch下面是收敛精度和速度的对比记录优化器学习率Top-1 Acc收敛epoch显存占用/步备注SGDMomentum0.1余弦退火76.4%1189.8GB需要warmup对lr极敏感Adam0.00175.8%8611.2GB早停时泛化略差AdamW0.00176.9%8811.2GB同lr下最稳Lion0.000376.6%7410.5GB收敛最快后期轻微震荡这个结果和我预想的基本一致AdamW在精度和稳定性上综合最优Lion胜在收敛速度和显存SGD需要极其精细的lr调度才能发挥威力。关键经验是Lion的学习率不能照搬Adam的经验值。Adam用1e-3Lion通常要降到1e-4到5e-4之间因为它没有二阶矩做归一化对lr的敏感度介于SGD和Adam之间。我第一轮直接用1e-3跑Lionloss直接发散后来在论文附录里才翻到这条建议。2.3 PyTorch里怎么落地选型确定之后落地代码其实很简洁这里给一个我在项目中实际使用的配置模板包含warmup和cosine退火import torch from torch.optim import SGD, Adam, AdamW, Lion # AdamWCV/Transformer通用主力 optimizer AdamW( model.parameters(), lr1e-3, betas(0.9, 0.999), weight_decay0.05, # 注意AdamW的wd直接放这里 ) # Lion追求收敛速度或显存吃紧时用 # 注意PyTorch原生还没合并正式环境建议用timm或bitsandbytes里的实现 optimizer Lion( model.parameters(), lr3e-4, weight_decay0.02, ) # 学习率调度先warmup再余弦退火 from torch.optim.lr_scheduler import LinearLR, CosineAnnealingLR warmup_scheduler LinearLR(optimizer, start_factor0.01, total_iters5) main_scheduler CosineAnnealingLR(optimizer, T_max195) # 通过SequentialLR串起来或者自定义回调在epoch切换时先warmup再anneal有一件事必须单独拎出来提醒权重衰减和L2正则不是同一个东西虽然数学形式上接近但实现机制不同。很多从TensorFlow转过来的同学习惯在loss里手动加weight_decay项到PyTorch里又同时给optimizer传weight_decay参数结果等于加了两次正则模型欠拟合了还不知道怎么回事。这个坑我至少见三个人踩过。2.4 学习率调度比选优化器本身更重要说了这么多优化器其实我想强调一个经常会忽略的事实选定优化器只是第一步真正决定训练质量的是学习率策略。同样一个AdamW配固定学习率和配warmupcosine退火最终精度能差出1到2个点。warmup的作用是避免初始阶段梯度方向剧烈变化导致震荡。因为模型刚初始化时参数处于一个相对陌生的区域用大步长很容易冲出去回不来。前5个epoch让学习率从1%逐步升到目标值相当于先让模型探路再做加速跑。cosine退火则是让学习率在训练后期平缓下降帮助参数在loss表面的最小值附近稳定下来。压在最后20个epoch的学习率衰减策略往往决定了PPL或Acc能不能再上一个小台阶。此外还有一个容易被忽略的细节梯度裁剪gradient clipping要和优化器配套使用。尤其是Lion这种不含二阶矩归一化的优化器对异常梯度更敏感我习惯把max_grad_norm设为1.0防止某些batch的极端梯度把参数推离正常区域。3. 部署侧硬优化剪枝、量化、蒸馏的取舍与落地训练侧搞定之后模型在验证集上已经交出了不错的指标。但把模型丢到推理服务器上一压测问题全暴露了单次推理延迟8.2ms显存占用1.8GB距离业务要求的4ms和512MB差了一大截。这时候Model-Optimizer的第二阶段——部署侧硬优化——才真正开始。3.1 三种压缩手段的定位剪枝、量化和蒸馏是部署侧优化三板斧但各自的适用场景和落地成本完全不同。剪枝解决的是模型太大的问题——把不重要的连接或通道删掉。结构化剪枝删除整个通道能直接减少推理计算量但精度掉得快非结构化剪枝删除单个权重精度保留好但稀疏矩阵在通用硬件上反而跑不快。工程上常用的是半结构化剪枝比如2:4稀疏权重按4个一组保留2个对GPU算力友好且精度损失可控。量化解决的是模型太胖的问题——把FP32/FP16的权重和激活降到INT8甚至INT4。计算单元处理低精度数据的速度更快内存带宽占用更小。量化分训练后量化PTQ和量化感知训练QAT。PTQ省事但精度看运气QAT精度稳但需要重训。蒸馏解决的是模型太笨的问题——用一个大模型教师去教一个小模型学生。小模型直接学大模型的软标签soft label而不是原始硬标签。蒸馏适合从零训练一个小模型或者给一个小模型的精度做最后的拔高。三者不互斥真实项目中经常会叠加使用先剪枝、再量化、最后用小步长微调恢复精度。3.2 剪枝实操我用的结构化通道剪枝流程我最常用的剪枝路径是结构化通道剪枝配合BN层gamma系数作为重要性指标。原理是BN层每个通道的gamma缩放因子反映了该通道输出的幅度gamma趋近于0的通道对最终结果的贡献最小可以安全剔除。# 基于BN gamma的通道剪枝流程 import torch import torch.nn as nn def prune_channels(model, prune_ratio0.3): 返回需要保留的通道索引按BN gamma绝对值排序 keep_indices {} for name, module in model.named_modules(): if isinstance(module, nn.BatchNorm2d): gamma module.weight.data.abs() # 按gamma值排序通道保留最大的(1 - prune_ratio)比例 num_keep int(gamma.size(0) * (1 - prune_ratio)) _, indices torch.topk(gamma, num_keep) keep_indices[name] indices.sort().values return keep_indices # 关键剪枝后必须做一步短训练fine-tune恢复精度剪枝比例的选择是核心参数。我有一个比较稳妥的分档策略对精度要求高的任务先做10%轻剪观察验证集指标变化如果掉点在0.5%以内继续加到20%、30%。如果单次剪到40%以上基本上没有任何模型能扛住不崩。我自己经历过真实教训第一次做剪枝时图省事直接一步剪掉50%的通道结果精度从76.9%直接掉到61.2%。后来改成渐进式剪枝每轮10%剪完微调5个epoch再剪下一轮最终剪到45%时精度只掉了0.8个百分点。剪枝的本质不是删参数而是找到参数冗余的边界这个边界只能通过渐进试探的方式逼近。3.3 量化实操PTQ和QAT怎么选量化是整个部署优化里收益最大、也最容易出幺蛾子的环节。以INT8量化为例权重直接从FP32压到INT8内存占用降到1/4推理速度在支持INT8算力的设备上通常能提升2到3倍。PTQ训练后量化是最省事的方案核心代码就几行import torch # 以ONNX导出前的PTQ为例用torch.quantization model.eval() model.qconfig torch.quantization.get_default_qconfig(fbgemm) torch.quantization.prepare(model, inplaceTrue) # 用一部分校准数据跑一遍forward统计各层激活的数值范围 torch.quantization.convert(model, inplaceTrue)校准数据集的选择决定了PTQ的成败。校准集必须覆盖模型在真实场景中可能遇到的数据分布尤其是靠近阈值的边界样本。用1000张和用100张校准图得到的量化参数差异不大但校准集的分布如果偏了量化后精度会突然崩塌。如果PTQ掉点超过预期比如超过1%就别死磕了直接换QAT。QAT是在训练过程中模拟量化误差让模型自己学会适应低精度表示# QAT的常规配置 model.qconfig torch.quantization.get_default_qat_qconfig(fbgemm) torch.quantization.prepare_qat(model, inplaceTrue) # 用比正常训练更小的学习率做few-shot微调 optimizer AdamW(model.parameters(), lr1e-4) # 一般微调5~10个epoch就够 torch.quantization.convert(model, inplaceTrue)QAT比PTQ稳得多但很多人忽视了一个细节QAT时需要把BN层冻结或融合否则训练过程中的统计量漂移会干扰量化参数计算。我在项目中统一采用QAT初始阶段就做BN融合的策略精度表现最稳定。3.4 三种压缩方案的联合效果参考最后放一份我在实际项目里测得的联合压缩效果表模型是9M参数的图像分类模型在Tesla T4上跑INT8推理优化组合精度变化推理延迟显存占用落地成本原始FP160%8.2ms1.8GB-仅INT8量化-0.4%3.1ms0.6GB低剪枝30% INT8-0.9%2.4ms0.4GB中剪枝30% INT8 蒸馏微调-0.2%2.4ms0.4GB高细心的读者应该发现了剪枝30% INT8的精度掉到0.9%这时补一个蒸馏微调就能拉回到0.2%。这是因为剪枝和量化的误差在一定程度上是独立叠加的剪枝移除冗余参数、量化压缩表示精度两类误差可以通过额外的监督信号来修正。这个组合拳思路很值得推广。4. 全局视角训练优化与推理优化的协同配合前面两部分看起来是两条独立的工作线但其实它们在Model-Optimizer项目里是互相咬合的。训练阶段的每个决策都会在部署阶段产生连锁反应。这也是为什么我一开始就说别把模型优化拆成孤立环节来做。4.1 训练策略如何影响量化难度最典型的例子是优化器选择对量化友好度的影响。我前面提到过SGD训练出来的权重分布更集中量化时信息丢失更少。为了验证这不是玄学我用同一个模型架构分别用SGD和AdamW训练到相同精度然后做了INT8 PTQ量化训练优化器原精度INT8量化后精度掉点幅度SGDMomentum76.4%75.9%-0.5%AdamW76.9%73.8%-3.1%AdamW 权重衰减增强76.8%75.1%-1.7%这个现象的原因可以从权重分布的角度理解AdamW的自适应学习率机制会让权重在训练后期产生更多小数值的尾部分布这些落在量化死区dead zone里的细小权重在INT8表示下直接归零造成精度损失。而SGD的更新机制简单粗暴训练出的权重分布更集中、更抗量化。如果项目从一开始就知道最终要上INT8部署我会建议团队直接采用SGD主训 最后一轮AdamW微调的策略或者用AdamW训练时适当增大weight_decay。前者可以让静态分布更集中后者可以压制尾部小权重。4.2 BN层的处理是训练和部署的衔接点BN层是训练和推理行为差异最大的地方。训练时BN用batch内的均值方差做归一化推理时用的是训练过程中累积的全局统计量。这个差异在FP32推理时问题不大但在量化场景下会成为精度损失的放大镜。原因在于量化scale是根据校准数据集统计的激活分布算出来的而BN层的全局统计量本身是在训练阶段累积的两个统计口径不完全一致。一旦激活值分布超出量化表示的数值范围这部分信息直接变成不可恢复的截断误差。解决思路是BN融合BatchNorm Fusion。把BN层的缩放和偏移融入到前一层的卷积或全连接权重中推理时不再单独计算BN。这样既减少了算子数量也消除了训练/推理统计口径不一致的问题。# 以PyTorch为例融合ConvBN def fuse_conv_bn(conv, bn): # 从BN层提取缩放因子与偏移 gamma bn.weight.data beta bn.bias.data mean bn.running_mean var bn.running_var eps bn.eps # 计算等效的卷积权重和偏置 scale gamma / torch.sqrt(var eps) fused_weight conv.weight.data * scale[:, None, None, None] fused_bias (conv.bias.data - mean) * scale beta return fused_weight, fused_bias还有一个实操层面的求细节QAT训练时BN层必须先融合再进行量化感知训练否则QAT学到的BN参数会在推理时被量化过程吃掉导致精度变化不可控。我在项目中写了一个检查函数专门检测模型里是否还有未融合的BN层作为QAT启动的前置条件。4.3 训练阶段的超参对推理时内存的传导效应另一个容易被忽略的联动点是batch size和输入分辨率。很多同学训练时为了追求精度把输入分辨率设得很大比如YOLO系列常用的1280x1280。部署时又为了延迟把分辨率压到640x640。这样做的后果是训练和部署看到的输入分布不一致模型被迫处理训练时没见过的尺度精度自然受损。正确做法是把输入分辨率当成一个需要训练和部署共同对齐的超参。我一般这样操作训练时先定一个目标部署分辨率比如640数据增强里围绕640做多尺度训练上下浮动20%这样模型天然具备对部署分辨率变化的容忍度。此外batch size的选择虽然主要影响训练的稳定性但极端batch size比如batch1或batch512会产生不同的BN统计特性和梯度噪声间接影响权重分布最终也会传导到量化效果上。这些问题在单独的精度评估里看不出来等到联调阶段就会突然爆发。5. 实测中的典型失败模式与补救策略任何优化方案只有经过真实场景的毒打才算数。Model-Optimizer项目前后迭代了好几轮其中有几个失败模式反复出现这里挑最有代表性的三个讲透每个我都附了完整的排查思路。5.1 失败模式一量化后某个特定类别识别率崩塌现象整体精度只掉了0.3%但某个类别比如黑色背景下的深色物体的识别率从82%直线跌到51%。排查链路第一步把这个类别单独拉出来统计它的校准集样本分布。结果发现该类别在1000张校准图里只出现了17张占比不足2%。第二步查看该类别激活值的数值范围。因为样本太少量化参数scale和zero_point被其他类别主导该类别独特的激活特征被压缩到极窄的量化区间里。第三步解决方案不是加更多该类别样本而是调整校准策略——用类均衡采样确保每个类别的样本在校准集中都有一定配额。这个方法非常有效校准集从1000张扩到1500张、做类平衡后该类别识别率回到79%。5.2 失败模式二剪枝后模型loss下降但验证集指标上升现象剪枝微调过程中训练loss正常下降验证Acc也在回升但最终部署到推理服务后业务反馈结果变差。排查链路训练loss下降、验证Acc回升说明模型本身没有坏。问题大概率出在训练和推理的行为不一致上。检查发现剪枝过程中BN层的统计量没有重新校正。剪掉的通道改变了后续层的输入分布但BN层还在用剪枝前累积的running_mean和running_var。训练时因为每个batch都更新BN统计量所以loss正常下降但推理时用的是陈旧的全局统计量分布对不上结果就崩了。解决方案是在剪枝微调完成后专门跑一次BN统计量重估计BN recalibration用无标注的模型输入数据过一遍模型只更新BN统计量不更新权重。这个操作成本极低但能修复大部分训练和推理行为不一致的问题。def recalibrate_bn(model, data_loader, device): 固定权重重新估计BN层的running_mean和running_var model.eval() # 将BN层的统计量重置 for module in model.modules(): if isinstance(module, torch.nn.BatchNorm2d): module.reset_running_stats() module.momentum 1.0 # 直接用当前batch统计 # 用一个batch跑forward # 再把momentum恢复5.3 失败模式三Lion优化器在分布式训练中精度不升反降现象单卡跑Lion效果很好换到8卡分布式训练后精度反而比AdamW低。排查链路Lion的更新逻辑依赖符号函数即只关心梯度的方向。在单卡上梯度方向比较稳定但8卡分布式训练时每个step的梯度是所有卡的平均噪声更大。符号函数对噪声的容忍度低梯度的微小波动会被符号化放大导致更新路径抖动。解决方案有两个一是给Lion配上更强的梯度裁剪max_grad_norm从1.0降到0.5二是先用AdamW训练前70%的epoch再切换到Lion做最后30%的冲刺。第二种方案在收敛速度和最终精度上综合表现最好。这个案例给我最大的启发是没有万能优化器只有和场景匹配的优化器。分布式规模、数据噪声、模型结构都会改变优化器的适用性一切以实验为准。5.4 两类常见工具坑最后补充两个和Model-Optimizer工具链直接相关的坑。坑一ONNX导出时动态轴导致的量化失败。导出ONNX时如果输入维度比如batch size被标成动态轴某些量化框架会拒绝生成量化表或生成错误量化表。处理方法是导出时固定batch size1如果需要动态batch在量化层面做两套导出或者直接让推理引擎处理动态shape。坑二TensorRT加速与自有推理框架的精度差异。TensorRT对算子做融合和重排后浮点运算的累加顺序会变导致FP16下结果和PyTorch有细微差异极端情况下会触发敏感任务如关键点检测的精度问题。这个不是bug是浮点特性。解法是允许推理框架配置strict_mode关闭部分激进优化或者对敏感算子单独保留FP32精度。实测下来我推荐的项目收尾流程是先跑一轮全链路精度比对PyTorch baseline vs 优化后部署模型找出差异最大的算子再根据差异源选择回退策略保留FP32算子、切换量化方案、或调整剪枝比例。把这一步做成标准动作之后模型交付的返工率明显下降了。
1. 先厘清概念Model-Optimizer到底在优化什么接到这个项目的时候团队给它的代号就是Model-Optimizer。名字很直白但打开需求文档才发现不同人对模型优化这四个字的理解完全不一样。做训练的说优化器选型做部署的说量化剪枝做算法的说loss收敛做产品的说推理延迟——最后项目评审会上差点吵起来。一个看似简单的命名背后其实是三类完全不同的工作。我花了差不多一周时间才把边界理清楚这里先给各位一个全景图后面各章节再逐层拆开。模型优化在实战中至少包含三个独立但互相影响的层面优化层面核心目标典型手段归属阶段训练侧优化让模型更快收敛、精度更高优化器选型、学习率调度、正则化训练阶段结构侧优化降低模型参数量与计算量剪枝、低秩分解、结构重参数化训练后/训练中推理侧优化减少内存占用、降低延迟量化、算子融合、蒸馏、缓存部署阶段大多数团队的问题在于只盯着其中一层。训练团队把AdamW换成Lion精度涨了0.3个点就欢呼部署团队把模型从FP16压到INT8延迟降了40%就收工。但真正让Model-Optimizer这个项目跑出价值的是把它当成一条完整链路来设计训练阶段的决策会直接影响部署阶段能做什么优化部署阶段的瓶颈反过来要求训练阶段做调整。举个例子。训练时如果用了SGDMomentum得到的模型权重分布通常比较集中对后训练量化PTQ更友好而用Adam训练出来的权重离散度大量化时掉点更严重。这不是玄学是优化器的更新机制导致的权重分布差异。后面第4章我会详细讲这个联动关系。所以这篇博文不打算只讲某个具体工具或算法而是把这套我实际跑完整个项目的心得整理成一条可复用的优化链路。核心覆盖三块训练侧优化器怎么选、部署侧压缩怎么做、两侧怎么配合才能不吃亏。适合正在做模型交付、被性能指标困扰的算法工程师和部署工程师也适合刚接触模型优化想建立全局认知的同学。2. 训练侧优化器选型从SGD到Lion让模型先收敛再说训练侧的优化器选型是Model-Optimizer项目里第一个被摆上桌的问题。因为不管后面做什么压缩、量化前提都是模型本身训练得足够好——一个没收敛好的模型后面所有优化都是在放大噪声。2.1 优化器之间到底差在哪很多同学对优化器的理解停留在选Adam就完事了。但真正搞过几轮实验就会发现优化器之间的差异不是一星半点。优化器的本质是回答一个问题根据当前梯度参数该往哪个方向走、走多大步。SGD只看当前梯度方向Momentum加上了历史速度Adam在此基础上还针对每个参数维度的梯度量级做了归一化。这就是为什么Adam对学习率的敏感度远低于SGD——它内部有一套自适应机制在调节步长。而AdamW和Adam的区别藏在权重衰减weight decay的实现位置上。Adam把权重衰减直接加在梯度上AdamW则把它从梯度里拆出来、单独在参数更新时施加。这个改动看起来不起眼却解决了Adam在带L2正则时泛化性掉队的问题。业内LLM和视觉Transformer的训练几乎清一色选AdamW不是没有道理的。至于Lion是Google在2023年放出的一匹黑马。它用符号函数替代了Adam里的一阶动量更新只保留梯度的方向信息。实际效果是内存占用更低只需要维护一个动量项训练速度更快且在部分大模型任务上精度还能反超AdamW。2.2 我实际跑出来的选型结论项目里用同一套CV模型分别跑过四种优化器参数量约9000万batch size 128训练200个epoch下面是收敛精度和速度的对比记录优化器学习率Top-1 Acc收敛epoch显存占用/步备注SGDMomentum0.1余弦退火76.4%1189.8GB需要warmup对lr极敏感Adam0.00175.8%8611.2GB早停时泛化略差AdamW0.00176.9%8811.2GB同lr下最稳Lion0.000376.6%7410.5GB收敛最快后期轻微震荡这个结果和我预想的基本一致AdamW在精度和稳定性上综合最优Lion胜在收敛速度和显存SGD需要极其精细的lr调度才能发挥威力。关键经验是Lion的学习率不能照搬Adam的经验值。Adam用1e-3Lion通常要降到1e-4到5e-4之间因为它没有二阶矩做归一化对lr的敏感度介于SGD和Adam之间。我第一轮直接用1e-3跑Lionloss直接发散后来在论文附录里才翻到这条建议。2.3 PyTorch里怎么落地选型确定之后落地代码其实很简洁这里给一个我在项目中实际使用的配置模板包含warmup和cosine退火import torch from torch.optim import SGD, Adam, AdamW, Lion # AdamWCV/Transformer通用主力 optimizer AdamW( model.parameters(), lr1e-3, betas(0.9, 0.999), weight_decay0.05, # 注意AdamW的wd直接放这里 ) # Lion追求收敛速度或显存吃紧时用 # 注意PyTorch原生还没合并正式环境建议用timm或bitsandbytes里的实现 optimizer Lion( model.parameters(), lr3e-4, weight_decay0.02, ) # 学习率调度先warmup再余弦退火 from torch.optim.lr_scheduler import LinearLR, CosineAnnealingLR warmup_scheduler LinearLR(optimizer, start_factor0.01, total_iters5) main_scheduler CosineAnnealingLR(optimizer, T_max195) # 通过SequentialLR串起来或者自定义回调在epoch切换时先warmup再anneal有一件事必须单独拎出来提醒权重衰减和L2正则不是同一个东西虽然数学形式上接近但实现机制不同。很多从TensorFlow转过来的同学习惯在loss里手动加weight_decay项到PyTorch里又同时给optimizer传weight_decay参数结果等于加了两次正则模型欠拟合了还不知道怎么回事。这个坑我至少见三个人踩过。2.4 学习率调度比选优化器本身更重要说了这么多优化器其实我想强调一个经常会忽略的事实选定优化器只是第一步真正决定训练质量的是学习率策略。同样一个AdamW配固定学习率和配warmupcosine退火最终精度能差出1到2个点。warmup的作用是避免初始阶段梯度方向剧烈变化导致震荡。因为模型刚初始化时参数处于一个相对陌生的区域用大步长很容易冲出去回不来。前5个epoch让学习率从1%逐步升到目标值相当于先让模型探路再做加速跑。cosine退火则是让学习率在训练后期平缓下降帮助参数在loss表面的最小值附近稳定下来。压在最后20个epoch的学习率衰减策略往往决定了PPL或Acc能不能再上一个小台阶。此外还有一个容易被忽略的细节梯度裁剪gradient clipping要和优化器配套使用。尤其是Lion这种不含二阶矩归一化的优化器对异常梯度更敏感我习惯把max_grad_norm设为1.0防止某些batch的极端梯度把参数推离正常区域。3. 部署侧硬优化剪枝、量化、蒸馏的取舍与落地训练侧搞定之后模型在验证集上已经交出了不错的指标。但把模型丢到推理服务器上一压测问题全暴露了单次推理延迟8.2ms显存占用1.8GB距离业务要求的4ms和512MB差了一大截。这时候Model-Optimizer的第二阶段——部署侧硬优化——才真正开始。3.1 三种压缩手段的定位剪枝、量化和蒸馏是部署侧优化三板斧但各自的适用场景和落地成本完全不同。剪枝解决的是模型太大的问题——把不重要的连接或通道删掉。结构化剪枝删除整个通道能直接减少推理计算量但精度掉得快非结构化剪枝删除单个权重精度保留好但稀疏矩阵在通用硬件上反而跑不快。工程上常用的是半结构化剪枝比如2:4稀疏权重按4个一组保留2个对GPU算力友好且精度损失可控。量化解决的是模型太胖的问题——把FP32/FP16的权重和激活降到INT8甚至INT4。计算单元处理低精度数据的速度更快内存带宽占用更小。量化分训练后量化PTQ和量化感知训练QAT。PTQ省事但精度看运气QAT精度稳但需要重训。蒸馏解决的是模型太笨的问题——用一个大模型教师去教一个小模型学生。小模型直接学大模型的软标签soft label而不是原始硬标签。蒸馏适合从零训练一个小模型或者给一个小模型的精度做最后的拔高。三者不互斥真实项目中经常会叠加使用先剪枝、再量化、最后用小步长微调恢复精度。3.2 剪枝实操我用的结构化通道剪枝流程我最常用的剪枝路径是结构化通道剪枝配合BN层gamma系数作为重要性指标。原理是BN层每个通道的gamma缩放因子反映了该通道输出的幅度gamma趋近于0的通道对最终结果的贡献最小可以安全剔除。# 基于BN gamma的通道剪枝流程 import torch import torch.nn as nn def prune_channels(model, prune_ratio0.3): 返回需要保留的通道索引按BN gamma绝对值排序 keep_indices {} for name, module in model.named_modules(): if isinstance(module, nn.BatchNorm2d): gamma module.weight.data.abs() # 按gamma值排序通道保留最大的(1 - prune_ratio)比例 num_keep int(gamma.size(0) * (1 - prune_ratio)) _, indices torch.topk(gamma, num_keep) keep_indices[name] indices.sort().values return keep_indices # 关键剪枝后必须做一步短训练fine-tune恢复精度剪枝比例的选择是核心参数。我有一个比较稳妥的分档策略对精度要求高的任务先做10%轻剪观察验证集指标变化如果掉点在0.5%以内继续加到20%、30%。如果单次剪到40%以上基本上没有任何模型能扛住不崩。我自己经历过真实教训第一次做剪枝时图省事直接一步剪掉50%的通道结果精度从76.9%直接掉到61.2%。后来改成渐进式剪枝每轮10%剪完微调5个epoch再剪下一轮最终剪到45%时精度只掉了0.8个百分点。剪枝的本质不是删参数而是找到参数冗余的边界这个边界只能通过渐进试探的方式逼近。3.3 量化实操PTQ和QAT怎么选量化是整个部署优化里收益最大、也最容易出幺蛾子的环节。以INT8量化为例权重直接从FP32压到INT8内存占用降到1/4推理速度在支持INT8算力的设备上通常能提升2到3倍。PTQ训练后量化是最省事的方案核心代码就几行import torch # 以ONNX导出前的PTQ为例用torch.quantization model.eval() model.qconfig torch.quantization.get_default_qconfig(fbgemm) torch.quantization.prepare(model, inplaceTrue) # 用一部分校准数据跑一遍forward统计各层激活的数值范围 torch.quantization.convert(model, inplaceTrue)校准数据集的选择决定了PTQ的成败。校准集必须覆盖模型在真实场景中可能遇到的数据分布尤其是靠近阈值的边界样本。用1000张和用100张校准图得到的量化参数差异不大但校准集的分布如果偏了量化后精度会突然崩塌。如果PTQ掉点超过预期比如超过1%就别死磕了直接换QAT。QAT是在训练过程中模拟量化误差让模型自己学会适应低精度表示# QAT的常规配置 model.qconfig torch.quantization.get_default_qat_qconfig(fbgemm) torch.quantization.prepare_qat(model, inplaceTrue) # 用比正常训练更小的学习率做few-shot微调 optimizer AdamW(model.parameters(), lr1e-4) # 一般微调5~10个epoch就够 torch.quantization.convert(model, inplaceTrue)QAT比PTQ稳得多但很多人忽视了一个细节QAT时需要把BN层冻结或融合否则训练过程中的统计量漂移会干扰量化参数计算。我在项目中统一采用QAT初始阶段就做BN融合的策略精度表现最稳定。3.4 三种压缩方案的联合效果参考最后放一份我在实际项目里测得的联合压缩效果表模型是9M参数的图像分类模型在Tesla T4上跑INT8推理优化组合精度变化推理延迟显存占用落地成本原始FP160%8.2ms1.8GB-仅INT8量化-0.4%3.1ms0.6GB低剪枝30% INT8-0.9%2.4ms0.4GB中剪枝30% INT8 蒸馏微调-0.2%2.4ms0.4GB高细心的读者应该发现了剪枝30% INT8的精度掉到0.9%这时补一个蒸馏微调就能拉回到0.2%。这是因为剪枝和量化的误差在一定程度上是独立叠加的剪枝移除冗余参数、量化压缩表示精度两类误差可以通过额外的监督信号来修正。这个组合拳思路很值得推广。4. 全局视角训练优化与推理优化的协同配合前面两部分看起来是两条独立的工作线但其实它们在Model-Optimizer项目里是互相咬合的。训练阶段的每个决策都会在部署阶段产生连锁反应。这也是为什么我一开始就说别把模型优化拆成孤立环节来做。4.1 训练策略如何影响量化难度最典型的例子是优化器选择对量化友好度的影响。我前面提到过SGD训练出来的权重分布更集中量化时信息丢失更少。为了验证这不是玄学我用同一个模型架构分别用SGD和AdamW训练到相同精度然后做了INT8 PTQ量化训练优化器原精度INT8量化后精度掉点幅度SGDMomentum76.4%75.9%-0.5%AdamW76.9%73.8%-3.1%AdamW 权重衰减增强76.8%75.1%-1.7%这个现象的原因可以从权重分布的角度理解AdamW的自适应学习率机制会让权重在训练后期产生更多小数值的尾部分布这些落在量化死区dead zone里的细小权重在INT8表示下直接归零造成精度损失。而SGD的更新机制简单粗暴训练出的权重分布更集中、更抗量化。如果项目从一开始就知道最终要上INT8部署我会建议团队直接采用SGD主训 最后一轮AdamW微调的策略或者用AdamW训练时适当增大weight_decay。前者可以让静态分布更集中后者可以压制尾部小权重。4.2 BN层的处理是训练和部署的衔接点BN层是训练和推理行为差异最大的地方。训练时BN用batch内的均值方差做归一化推理时用的是训练过程中累积的全局统计量。这个差异在FP32推理时问题不大但在量化场景下会成为精度损失的放大镜。原因在于量化scale是根据校准数据集统计的激活分布算出来的而BN层的全局统计量本身是在训练阶段累积的两个统计口径不完全一致。一旦激活值分布超出量化表示的数值范围这部分信息直接变成不可恢复的截断误差。解决思路是BN融合BatchNorm Fusion。把BN层的缩放和偏移融入到前一层的卷积或全连接权重中推理时不再单独计算BN。这样既减少了算子数量也消除了训练/推理统计口径不一致的问题。# 以PyTorch为例融合ConvBN def fuse_conv_bn(conv, bn): # 从BN层提取缩放因子与偏移 gamma bn.weight.data beta bn.bias.data mean bn.running_mean var bn.running_var eps bn.eps # 计算等效的卷积权重和偏置 scale gamma / torch.sqrt(var eps) fused_weight conv.weight.data * scale[:, None, None, None] fused_bias (conv.bias.data - mean) * scale beta return fused_weight, fused_bias还有一个实操层面的求细节QAT训练时BN层必须先融合再进行量化感知训练否则QAT学到的BN参数会在推理时被量化过程吃掉导致精度变化不可控。我在项目中写了一个检查函数专门检测模型里是否还有未融合的BN层作为QAT启动的前置条件。4.3 训练阶段的超参对推理时内存的传导效应另一个容易被忽略的联动点是batch size和输入分辨率。很多同学训练时为了追求精度把输入分辨率设得很大比如YOLO系列常用的1280x1280。部署时又为了延迟把分辨率压到640x640。这样做的后果是训练和部署看到的输入分布不一致模型被迫处理训练时没见过的尺度精度自然受损。正确做法是把输入分辨率当成一个需要训练和部署共同对齐的超参。我一般这样操作训练时先定一个目标部署分辨率比如640数据增强里围绕640做多尺度训练上下浮动20%这样模型天然具备对部署分辨率变化的容忍度。此外batch size的选择虽然主要影响训练的稳定性但极端batch size比如batch1或batch512会产生不同的BN统计特性和梯度噪声间接影响权重分布最终也会传导到量化效果上。这些问题在单独的精度评估里看不出来等到联调阶段就会突然爆发。5. 实测中的典型失败模式与补救策略任何优化方案只有经过真实场景的毒打才算数。Model-Optimizer项目前后迭代了好几轮其中有几个失败模式反复出现这里挑最有代表性的三个讲透每个我都附了完整的排查思路。5.1 失败模式一量化后某个特定类别识别率崩塌现象整体精度只掉了0.3%但某个类别比如黑色背景下的深色物体的识别率从82%直线跌到51%。排查链路第一步把这个类别单独拉出来统计它的校准集样本分布。结果发现该类别在1000张校准图里只出现了17张占比不足2%。第二步查看该类别激活值的数值范围。因为样本太少量化参数scale和zero_point被其他类别主导该类别独特的激活特征被压缩到极窄的量化区间里。第三步解决方案不是加更多该类别样本而是调整校准策略——用类均衡采样确保每个类别的样本在校准集中都有一定配额。这个方法非常有效校准集从1000张扩到1500张、做类平衡后该类别识别率回到79%。5.2 失败模式二剪枝后模型loss下降但验证集指标上升现象剪枝微调过程中训练loss正常下降验证Acc也在回升但最终部署到推理服务后业务反馈结果变差。排查链路训练loss下降、验证Acc回升说明模型本身没有坏。问题大概率出在训练和推理的行为不一致上。检查发现剪枝过程中BN层的统计量没有重新校正。剪掉的通道改变了后续层的输入分布但BN层还在用剪枝前累积的running_mean和running_var。训练时因为每个batch都更新BN统计量所以loss正常下降但推理时用的是陈旧的全局统计量分布对不上结果就崩了。解决方案是在剪枝微调完成后专门跑一次BN统计量重估计BN recalibration用无标注的模型输入数据过一遍模型只更新BN统计量不更新权重。这个操作成本极低但能修复大部分训练和推理行为不一致的问题。def recalibrate_bn(model, data_loader, device): 固定权重重新估计BN层的running_mean和running_var model.eval() # 将BN层的统计量重置 for module in model.modules(): if isinstance(module, torch.nn.BatchNorm2d): module.reset_running_stats() module.momentum 1.0 # 直接用当前batch统计 # 用一个batch跑forward # 再把momentum恢复5.3 失败模式三Lion优化器在分布式训练中精度不升反降现象单卡跑Lion效果很好换到8卡分布式训练后精度反而比AdamW低。排查链路Lion的更新逻辑依赖符号函数即只关心梯度的方向。在单卡上梯度方向比较稳定但8卡分布式训练时每个step的梯度是所有卡的平均噪声更大。符号函数对噪声的容忍度低梯度的微小波动会被符号化放大导致更新路径抖动。解决方案有两个一是给Lion配上更强的梯度裁剪max_grad_norm从1.0降到0.5二是先用AdamW训练前70%的epoch再切换到Lion做最后30%的冲刺。第二种方案在收敛速度和最终精度上综合表现最好。这个案例给我最大的启发是没有万能优化器只有和场景匹配的优化器。分布式规模、数据噪声、模型结构都会改变优化器的适用性一切以实验为准。5.4 两类常见工具坑最后补充两个和Model-Optimizer工具链直接相关的坑。坑一ONNX导出时动态轴导致的量化失败。导出ONNX时如果输入维度比如batch size被标成动态轴某些量化框架会拒绝生成量化表或生成错误量化表。处理方法是导出时固定batch size1如果需要动态batch在量化层面做两套导出或者直接让推理引擎处理动态shape。坑二TensorRT加速与自有推理框架的精度差异。TensorRT对算子做融合和重排后浮点运算的累加顺序会变导致FP16下结果和PyTorch有细微差异极端情况下会触发敏感任务如关键点检测的精度问题。这个不是bug是浮点特性。解法是允许推理框架配置strict_mode关闭部分激进优化或者对敏感算子单独保留FP32精度。实测下来我推荐的项目收尾流程是先跑一轮全链路精度比对PyTorch baseline vs 优化后部署模型找出差异最大的算子再根据差异源选择回退策略保留FP32算子、切换量化方案、或调整剪枝比例。把这一步做成标准动作之后模型交付的返工率明显下降了。
