1. 训练侧的优化器不是换名字就能变强1.1 优化器到底在优化什么今年年初我们接了一个让人头疼的活儿一个做车牌识别的边缘端项目模型是同事之前在GPU服务器上训练的精度还不错但一部署到本地的8核ARM盒子上单张图片从预处理到推理结束要420毫秒业务指标卡在150毫秒以内。一开始我的思路是换推理框架、开多线程、调内存池折腾了两周只挤出了不到60毫秒。真正把时间打下来靠的是把整个链路想清楚——从训练侧的优化器选择到推理侧的剪枝和量化再到最后的精度校验。我把这整套方法论做成了一套内部工具链取名叫Model-Optimizer。这篇文章就把这套方法的参数细节和踩过的坑完整复盘一遍适合正在做边缘端部署、被模型延迟和体积卡住或者想系统理解优化器原理的工程师参考。好多朋友提到“优化器”就默认是Adam或者SGD二选一模型不收敛就换一个换了还不行就再加正则。其实优化器不是撞大运它本质上只解决一个问题怎么根据梯度去更新参数。梯度给出了方向优化器决定走多快、走不稳的时候怎么刹住车、进入平坦区域后怎么找更细的方向。你可以把它想象成下山SGD就像一个只凭当前坡度判断的人动量是给它手里加了一根拐杖能记住之前的方向遇到坑洼不轻易转向Adam则像是给每条腿装上了独立调节的避震器每个参数都有自己的一套步长。理解了这层你才知道为什么同一个模型换一个优化器表现能差出一大截。优化器更新时的关键变量有三个方向、步长、还有对噪声的容忍度。SGD很老实方向就是当前梯度的反方向所以它对噪声敏感batch-size稍微小一点loss曲线就容易抖。Adam记录了梯度的一阶矩和二阶矩前者相当于动量后者相当于对每个参数历史梯度振幅的估计用它来折算步长这样经常出现大梯度的参数会走得保守梯度一直很小的参数反而敢走快一点。这也是Adam在Transformer类模型上那么稳定的原因——注意力层里不同位置的梯度尺度差异极大统一的步长根本没法兼顾。1.2 我常用的四套基线配置Model-Optimizer里维护了四套经过反复验证的优化器基线配置不是为了炫技而是为了让不同模型启动时都有一个靠谱的起点。优化器适用场景初始超参核心注意点SGD Momentum中小数据集CNN、需要强泛化能力lr0.01momentum0.9weight_decay1e-4学习率需要较长warmup对lr最敏感AdamWTransformer、大模型、多模态lr3e-4weight_decay0.05beta10.9beta20.999weight decay与lr解耦embedding层别漏掉AdamCNN分类、检测等常规任务lr1e-3beta10.9beta20.999边训练边降lr别指望Adam自己收敛到极小点Lion大规模训练、显存/内存受限lr1e-4weight_decay0.01更新量比Adam大warmup不够容易前期发散SGDMomentum常常被低估但它有个Adam不具备的优点最后收敛到的解通常更“平”在量化到INT8之后的精度损失往往更小。原因在于Adam的步长自适应会导致参数在极小值附近抖动幅度偏大解的位置更尖对量化误差更敏感。如果你的模型主要目标是部署而不是刷榜SGD路线值得认真试一次代价只是训练时间普遍要拉长1.5到2倍。AdamW和传统Adam最本质的区别是它把权重衰减从梯度项里拆了出来。传统Adam在计算梯度时会把L2正则项一并算进去然后再经过二阶矩归一化导致正则强度被“步长缩放”改变了。AdamW则是先按梯度更新参数再用一个独立的衰减系数去乘参数正则强度和当前梯度、步长都不耦合。这句话听起来简单但实际效果差很多同样的weight_decay0.05AdamW在BERT类模型上能稳定压过传统的L2正则就是因为embedding和LayerNorm这类参数不再被错误地过度惩罚。Lion则是Google在2023年放出来的优化器字面意思是“用符号动量来更新”。它不像Adam记录二阶矩而是维护一阶动量然后用这个动量的正负号乘上学习率去更新参数。只存一阶动量意味着内存占用少一截而且更新方向“非正即负”相当于每一步都在做一次极简的二值决策。实测下来它在很多大模型任务上收敛更快但有个毛病更新量偏大训练早期如果warmup太短loss会直接冲上天。我的习惯是warmup步数至少占全流程的5%初始学习率再往下压一半观察前几百步的梯度范数没有尖峰了才放心离开。1.3 比“选优化器”更重要的三件事选对了优化器只是开始真正决定模型训练质量的往往是下面三件事。第一学习率调度比优化器的选择更影响最终结果。我见过太多人固定一个lr跑到底训练集loss在很长一段时间内纹丝不动就反过来怀疑优化器坏了。实际上Adam这类自适应优化器普遍需要warmup因为训练初期二阶矩估计还没稳定过大的学习率会让embedding这类梯度波动剧烈的参数剧烈跳变。我的标准操作是先用5%到10%的训练步数把学习率从0线性升到目标值接着用余弦退火慢慢降到接近0。余弦退火的含义是前期降得慢后期降得快让参数在训练后段有机会先去探路、再稳定下来基本上每次都能比固定学习率多出一两个点。第二加大batch size之后学习率不能线性地跟着翻倍。业界约定俗成的sqrt规则是batch扩大4倍、lr扩大2倍但这条规则只在数据分布均匀时成立。你的数据集如果有明显类别不均衡lr涨太多会让头部类别主导梯度。更稳的办法是保持lr不变只把梯度累积步数增大让梯度估得更准这样有时候反而能收敛到更好的点。第三用梯度范数而不是loss来监控训练健康度。loss指标太粗等它变差往往已经晚了。我习惯每个step都记录全参数梯度的L2范数如果某个step突然出现一个尖峰说明模型正在越过一个很陡的区域这时候后续训练大概率会产生剧烈波动。对策是给梯度范数设置一个裁剪阈值比如max_norm1.0。这不会改变优化器的选择却能让Adam和Lion都跑得更稳。这也是Model-Optimizer里默认打开的一个开关很多精度事故其实就是被这个简单的裁剪挡住的。2. 推理侧的压缩链路我为什么坚持“先剪枝、后量化”2.1 先剪枝后量化才能让两种方法都生效训练侧的优化器解决的是“模型值不值钱”的问题推理侧的压缩解决的是“模型跑不跑得动”的问题。Model-Optimizer的核心链路并不复杂先做结构剪枝再做量化最后用蒸馏兜底。这个顺序我踩过一次坑在这里直接说明原因。剪枝是砍掉不重要的连接或通道量化是把模型参数的存储和计算精度从FP32降到INT8甚至INT4。如果先量化再剪枝你会遇到两个麻烦一是量化工具在做算子融合时会把结构固定成一套静态计算图稀疏化之后再往里面塞剪枝结构往往要重新走一遍优化流程效果打折二是很多推理引擎对“稠密低精度”的优化支持很好对“稀疏低精度”却根本没有对应的内核。反过来先剪枝再量化剪掉冗余通道之后剩下特征图分布更集中逐层统计出来的量化阈值会更准INT8的精度损失普遍能再小0.3到0.5个百分点。2.2 结构化剪枝优先别在CPU上追求稀疏矩阵我们在ARM盒子上试过一种最直接的非结构化剪枝把绝对值小的权重直接置零。结果CPU推理时间几乎没有变化。原因很简单CPU上的矩阵乘法库针对的是稠密块你生成一个带空洞的稀疏矩阵如果没有对应的稀疏内核计算时还要花额外时间去跳过空洞性能不升反降。所以在CPU和边缘设备上老老实实用结构化剪枝。结构化剪枝里最常用的是通道剪枝。拿一个卷积层举例假设它的权重shape是[64, 128, 3, 3]64是输出通道数。剪掉一半不重要的输出通道后权重变成[32, 128, 3, 3]下一层的输入通道也跟着从64变成32整个矩阵乘法尺寸肉眼可见地缩小。我们当时的检测模型一共剪掉了约35%的通道参数量压缩到原来的60%经过几轮微调后mAP只掉了0.2个点CPU单线程推理时间从420毫秒降到了大约280毫秒。怎么判断哪些通道不重要常见方法是看每个通道对后续层输出的贡献对一批校准数据做统计把每个通道的平均激活绝对值排名小的优先剪。另一种更优雅的做法是用BN层的缩放因子gamma作为重要性指标gamma越接近0说明该通道的输出本来就趋向于被抑制剪掉它对精度影响最小。这项技术在早期被称为Network Slimming后来被很多框架吸收Model-Optimizer里也默认用了这个策略。2.3 量化PTQ和QAT的取舍剪枝做完再上量化。量化有两个选择训练后量化PTQ和量化感知训练QAT。PTQ的思路是拿着一个训练好的模型喂一批校准数据统计每层激活值的实际分布然后用KL散度之类的方法计算最小化信息损失的量化边界。比如某一层激活值大部分落在[-6, 6]区间极端值不过是偶尔的尖峰那么把这层量化映射到[-128, 127]就选[-6, 6]尖峰单独做clip处理。整个过程通常只要几分钟不需要重训。它在大多数CNN上表现都不错INT8量化后精度掉0.5%以内很正常。QAT则是在训练阶段就模拟量化误差在计算图里插入伪量化节点前向的时候把权重和激活Round成整数再还原成浮点反向传播时用直通估计器让梯度能顺利流过这些不可导节点。这样模型在训练过程中就见过了“被量化后”的自己跑出的权重更抗量化。代价是要重训一遍模型时间成本高。我们的分界线很简单如果PTQ后精度掉点超过0.5%或者模型里有大量对数值敏感的层比如注意力、LayerNorm就直接上QAT。校准集的选取很容易被忽略但它直接影响PTQ的效果。校准集不需要大几百到一千张代表性图片就够了关键是覆盖真实的边界情况。我们做车牌识别时第一次测试全用白天样本PTQ结果的白天精度几乎没掉结果夜间的误检率翻了一倍。后来把夜间雨景、强光反射、倾斜车牌各放了几十张进校准集量化后的夜间精度才恢复过来。这个教训后面还会专门讲。2.4 蒸馏量化精度崩掉之后的最后手段剪枝加量化之后有时精度还是不达标这时候我的最后手段是知识蒸馏。训练一个大的teacher模型不容易但我们在Model-Optimizer里直接复用原始未压缩模型作为teacher把压缩后的小模型当作student让student去学teacher的软输出。蒸馏的温度T是一个关键超参。T越高softmax输出的分布越平滑teacher给出的“类别间相似度”信息越丰富但T太高会把本来清晰的边界彻底模糊掉反而让student学不到重点。我们的经验是T3起步在车牌识别这种强分类任务里一般在2到4之间调。另外蒸馏loss和原始交叉熵loss要做一个权重配比我们惯用0.5:0.5然后监控student在各种温度下的输出分布。那次QAT之后精度已经比PTQ好了不少但离业务还差0.8个点用T3的蒸馏又补回来1.8个点最后反而比指标线还高出1个点。3. 部署优化时最容易翻车的三个细节3.1 动态shape的代价比你想象得高推理优化工具通常会对计算图做算子融合、内存复用和内核选择这些优化都依赖“在编译期就知道每层的输入输出大小”。如果你把动态shape放开允许任意宽高的图片进入模型那么优化工具要么退回普通kernel要么在运行期反复重新构建内部计划。后者的开销有时候比模型本身的推理还高。我们最开始为了图省事直接保留动态shapeTensorRT的engine构建倒是成功了但跑起来性能只比没优化快10%出头。后来把输入分辨率统一成固定尺寸比如把图片Pad到640×640推理代码里再按原图比例还原检测框整个engine的算子融合终于生效延迟直接又降了35%。如果你的业务场景允许让图片等比缩放加padding就尽量固定shape这是成本最低、收益最明显的一步。动态shape不是不能用但你要明确知道每一次shape的变化都可能让推理框架付出额外的plan重建开销。3.2 层融合和算子替换会带来数值偏差推理引擎为了性能会把连续的小算子融合成一个大的kernel典型的就是ConvBatchNormReLU三道合并成一道。这个融合在数学上几乎等价但实际计算顺序变了浮点运算结果会有一丁点差异。FP32下这些差异可以被忽略一旦量化到INT8误差会被放大。我们踩过的一个具体例子是量化后模型整体精度只掉了0.4个点但某一类特殊字符的识别正确率从92%掉到了84%。排查过程是一层层比对把原始模型和量化模型各自在相同输入下逐层输出特征图计算余弦相似度。结果发现某几层的相似度降到0.93以下继续往里查是Concat层和后续Conv融合后拼接顺序里的Channel顺序变了导致对应的量化缩放因子不一致。解决方案也不复杂在算子融合阶段把这类敏感层加入白名单不让它们自动融合。这件事给我们的教训是不要相信引擎的“等量代换”精度异常时一定要有逐层对齐的工具链。3.3 校准集选不好白天指标漂亮晚上全是误报前面提过校准集这里展开讲。PTQ量化需要进行校准校准集就是用来让量化工具统计激活值分布的数据。如果你的校准集是随机从训练集里抽的很可能抽出来的全是晴天白天的图。整个量化的阈值就会偏向白天场景量化误差集中在晚上大灯的强光区域和暗光区域的低亮度区域。我们的夜间误检率问题就是这么来的。现象很诡异测试集整体精度只下降0.3%看起来完全正常但单独分开统计后发现夜间组精度下降整整4.2%白天组反而上升了0.1%。原因就在校准集的数据分布白天样本太多Quantizer为了守住主要分布选择性地牺牲了分布占比小但数值范围极端的夜间样本。修正方法是构建一个数据均衡的校准集白天、夜间、逆光、模糊、遮挡各占一定比例总量500到1000张就够。调整之后整个量化的最差值从4.2%收敛回到0.8%以内。校准集的构建应该和你实际部署场景强绑定而不是简单从训练集随机抽样。4. 效果怎么算成功延迟、吞吐、精度一个都不能少4.1 不要只报“单次延迟下降30%”有一次我在周会上报了一个很好的成绩“INT8之后单张图片推理延迟下降45%。”结果被业务方一句话问住“盒子上同时要跑八个进程还能保证150毫秒吗”单次延迟是最容易测也最容易骗自己的指标。Model-Optimizer的评估体系里至少要看下面这些维度指标测试方法容易犯的错端到端延迟从输入图片读入到拿到结果统计p50/p95/p99只报p50不看长尾吞吐量固定batch持续压测算QPS不说明并发和batch size资源占用峰值RSS、CPU占用率、显存不看多实例叠加后的占用精度差异原始模型和优化模型在同一测试集上的业务指标用top-1替代业务指标延迟也不是越低越好。推理框架的底层调度器通常会为不同batch size挑选不同kernel一个只在batch1上优化的配置可能在batch4时性能反而更差。我习惯把单帧、多帧、多线程三种场景都压一遍再结合实际部署时的并发模型确定最终版本。还有一点常常被忽视模型体积也是延迟的一部分。一个1.2GB的模型和300MB的模型在冷启动加载时的差距是质变的。量化到INT8之后内存占用直接降到原来的四分之一这对单板上同时跑多个服务的场景可能比延迟更重要。我们在优化时把模型从1.2GB压到320MB加载时间从8秒降到1秒这几个数字也写进了最终的技术报告。4.2 绑定业务指标的A/B验收模型的精度指标和业务的验收指标之间往往还有一道坎。你的模型可能报告mAP只掉了0.3%但业务方关心的是“误识别率”和“超时率”这两个指标。mAP和误识别率不是同一个东西后者对某些特定类别的失败敏感得多。所以我现在的做法是把模型优化后的版本直接接进一个影子服务把线上真实流量复制一份打过去同时跑旧版和新版跑上一两天再比两个版本的业务指标。A/B阶段重点看的指标包括超时比例、错误识别的发生率、平均响应时间、内存持续占用。这个阶段的收益评估比任何测试集都更有说服力。有一次我们在影子环境跑了两天发现新版本整体延迟降低了35%但某个特定时段出现了周期性的延迟抖动原因是动态内存分配和某个外部依赖的定时任务撞在一起。这个现象在纯离线压测里根本没出现过。所以我把A/B阶段从两天延长到了五天跨越完整的业务周期尽量覆盖各种流量特征。所有优化方案最终目的是让模型和业务目标对齐。延迟数字再好看如果业务指标、稳定性达不到要求这个优化就是失败的。反过来如果延迟只降了20%但系统稳定性大幅提升、内存占用减半那它依然是一个值得上线的版本。5. 最后分享一个可复用的检查清单回到Model-Optimizer本身这套方法现在内部跑得很顺。为了让后来的同事不再重复踩坑我梳理了一份精简的检查清单在这里也分享出来。5.1 训练阶段检查项确定优化器基线小型CNN优先SGDMomentumTransformer与大模型优先AdamW显存受限试Lion。设置warmup步数占比5%到10%初始学习率从当前配置的四分之一或一半开始做线性升温。打开梯度裁剪max_norm从1.0开始观察梯度范数曲线有尖峰就调低。监控训练健康度不只盯loss同时看梯度范数、参数更新幅度和激活值的分布。5.2 压缩与部署阶段检查项顺序固定先结构化剪枝再PTQ或QAT量化最后蒸馏兜底。剪枝优先用BN层的gamma作为通道重要性依据剪完用少量数据微调1到2个epoch。量化前先构建均衡校准集覆盖真实场景的边界情况不要从训练集随机抽。固定输入shape或把图片统一pad到部署kernel最优的尺寸拒绝动态shape的隐性开销。导出模型后对原始模型和优化模型的逐层输出做余弦相似度核对敏感层加入白名单避免被过度融合。5.3 验收阶段检查项延迟统计p50、p95、p99不要只报平均值。同时测单帧、多帧、多线程以及多实例叠加后的资源占用。精度用业务口径不只看top-1或mAP。放到影子环境跑至少48小时观察超时率、误判率、内存是否持续增长。确认回滚路径一旦新版异常能在几分钟内切回旧版。这套清单我现在每做一个新项目都会跑一遍帮我在第一轮就过滤掉大部分潜在问题。Model-Optimizer本质上不是一个花哨的新算法集合而是把训练、压缩、部署、验收这一整条链路里的关键变量显式地管起来。很多时候模型跑不快不是单点工具的锅而是链路里有某个变量失控了。把这些变量一个个盯住速度、体积、精度的平衡自然就有了。