我最初看到“Model-Optimizer”这个项目名时第一反应是这不就是深度学习里那个optimizer选型的事吗但真正把项目做下来才发现这个名字背后能装的东西远比想象中大。Model-Optimizer在我这里被定义成一个贯穿训练和推理全流程的优化工具箱——它既包含训练阶段优化器SGD、AdamW这些的选型和超参调优也包含模型训练完成后针对部署场景的量化、剪枝、蒸馏等压缩手段。简单说这个项目解决的是三个问题训练能不能更稳、更快模型能不能更小、推理能不能更省。这篇文章我打算完整拆解一下我在Model-Optimizer项目里的思路、踩过的坑、以及最终落地的方案。它适合正在做深度学习训练调参的人也适合那些模型已经训练完、但卡在显存不够、推理延迟过高、部署资源受限的工程师。无论你是刚入门还是已经调过一阵子参这里面应该都有可以直接抄作业的内容。1. Model-Optimizer的整体设计优化不是单点改动而是一条链路1.1 训练阶段和推理阶段优化的是两件完全不同的事项目最开始我只盯着训练阶段的optimizer比如Adam和SGD哪个好、学习率怎么设、weight decay该给多少。后来发现对于大多数实际业务场景训练阶段的优化和部署阶段的优化是两个独立的问题域但它们经常被混为一谈导致项目目标模糊。训练阶段的优化关注的是收敛速度、稳定性、最终精度泛化能力。你要的是模型在验证集上表现好训练过程别动不动就loss爆炸。推理阶段的优化关注的是显存占用、推理延迟、吞吐量、功耗。你要的是模型能在GPU上跑得动、在CPU上也能接受、在边缘设备上不至于卡死。Model-Optimizer这个项目就是把我手头多个模型的优化实践统一到一个流程里训练时把optimizer和调度器调稳训练完再针对目标硬件做压缩和加速。两者之间还有一条隐含的关联——如果训练阶段不加正则、不做扰动模型权重本身质量差后面做量化剪枝时精度掉点会更严重。所以整个优化的起点不是部署那一刻而是训练刚开始时的超参设置。1.2 为什么我不用框架的默认配置而是自己手动控制现在PyTorch、TensorFlow里一行model.fit()或者Trainer.train()就能把训练跑起来默认配置已经很均衡。但默认意味着平庸尤其当你的任务不是标准ImageNet分类而是目标检测、语义分割、或者多模态模型时默认优化器往往不是最优解。举个例子PyTorch里Adam默认学习率是1e-3这对很多CV任务来说偏大容易在训练后期震荡而默认的weight decay在Adam里实际上并不规范真正应该用的是AdamW里解耦的weight decay方案。如果完全依赖默认配置项目前期的训练曲线就会埋下隐患。我在Model-Optimizer里做的最重要决定是把训练和推理的所有可控参数显式地记录、对比、版本化。每个实验都有一份超参配置文件optimizer类型、学习率策略、warmup步数、量化方式、剪枝比例全部落在代码仓库里而不是散落在训练日志里。这样做的直接好处是项目能做到任何一次实验结果都可以复现任何一次优化尝试都可以量化收益。后面讲实操时我会拿具体配置例子说明。2. 训练优化器选型与调参从AdamW到SGD的实战对比2.1 优化器的本质在梯度下降这张地图上怎么走得更聪明要理解optimizer选型可以先把它类比成下山。SGD就是一个只知道当前位置、跟着最陡方向走的人步长学习率固定容易走弯路但最终能到山脚。Adam则像是一个带“惯性”和“自适应步伐”的人它会把过去几步的方向和坡度大小都记下来遇到平坦区域自动迈大一步遇到陡坡自动收小步伐所以前期收敛非常快。问题在于Adam虽然快但泛化性能经常不如调好参数的SGD。这背后的原因学术上有多种解释我自己的理解是Adam对每个参数用梯度的二阶矩做归一化相当于给整个参数空间都做了不同程度的缩放这会让某些方向的更新变得过于“平滑”反而削弱了正则化带来的隐式惩罚效果。而SGD虽然笨但它的随机性恰恰给训练带来了一种隐式的正则化。所以在Model-Optimizer项目里我的选型规则很简单场景推荐优化器原因标准CNN分类/检测任务训练资源充足SGD Momentum泛化好收敛稳定配合cosine退火效果好Transformer/BERT类模型或训练初期想快速看到效果AdamW自带解耦weight decay训练稳定适配attention机制大规模预训练 下游微调AdamW 分层学习率不同层更新幅度不同保持预训练特征计算资源有限希望快速迭代Adam不带W参数少、收敛快可后期切SGD精调2.2 分组学习率、warmup和cosine退火的配置记录项目里我用得最顺手的组合是AdamW 线性warmup cosine退火。warmup的意义很多人知道但具体怎么选步数是有讲究的。warmup步数一般取总训练步数的5%到10%。比如总训练步数50000步warmup就是2500到5000步。warmup期间学习率从0线性升到目标值目的是让模型先以一个温和的节奏适应数据分布避免一开始梯度太大导致loss震荡甚至发散。我实测过特别是用了大learning rate比如3e-4以上的BERT微调不配warmup几乎必然出现前几百步loss不降反升的情况。cosine退火则是让学习率沿着余弦曲线从峰值降到接近0。它的好处是前期下降缓慢模型有充足时间在大学习率区间探索后期下降加快帮助模型收敛到更平滑的极小值点。和传统的step decay比如每30轮除以10相比cosine省去了手动判断“什么时候该降学习率”的过程适合大规模自动化实验。以下是我在Model-Optimizer里一个典型视觉任务的优化器配置optimizer: type: AdamW lr: 2e-4 betas: [0.9, 0.999] eps: 1e-8 weight_decay: 0.05 layer_decay: 0.75 scheduler: type: cosine warmup_ratio: 0.08 min_lr: 1e-6这里layer_decay是给Transformer类模型用的分层学习率衰减靠近输入的层衰减多0.75的系数每个block衰减一次越往后保留越多原始预训练信息。这是从MAE、BEiT这些论文里验证过的做法直接抄过来用在微调场景很有效。2.3 怎么判断优化器在正常工作不只是看loss曲线很多人只看train loss下降就觉得万事大吉其实还不够。我在项目里养成了一个习惯每次训练都额外记录梯度范数grad norm和学习率实时值这两条曲线。梯度范数能反馈优化器是否稳定。如果梯度范数突然暴涨到几个数量级以上说明出现了梯度爆炸大概率是学习率太大或者数据里有异常值。如果梯度范数一直特别小比如小于1e-4说明梯度消失模型基本学不动。另外要多关注验证集loss和训练集loss的“开口”时间点。如果训练到某个阶段val loss开始上升但train loss继续下降这是过拟合的明确信号。这时与其调optimizer不如先检查weight decay是否太小、数据增强是否太弱。实践中我把weight decay从0.01调到0.05后val loss的开口时间往后推迟了将近20%的训练轮数。3. 推理阶段压缩与加速量化、剪枝、蒸馏的落地路径3.1 先确认目标硬件再决定压缩手段训练完成后进入部署阶段Model-Optimizer的第二个功能模块开始起作用。这里最关键的一步不是立刻选量化还是剪枝而是先确认一个核心问题目标硬件和延迟目标是什么如果你部署在NVIDIA GPU上TensorRT和FP16/INT8量化是首选速度快、工具链成熟。如果你部署在CPU上剪枝和蒸馏可能比量化更有效尤其是那些结构稀疏度本来就高的模型。如果你部署在手机或嵌入式设备上那么量化几乎是必选项因为内存带宽和算力都有限。我自己碰到的典型场景是一个语义分割模型FP32版本在GPU上单帧推理12ms需要降到5ms以内才能满足实时需求。当时我第一时间尝试INT8量化结果速度从12ms降到4ms精度mIoU只掉了0.8个百分点。这个收益远大于剪枝带来的两倍加速。所以我的优先级建议是先量化再剪枝蒸馏作为最后手段。量化是“白捡”的加速不改变模型结构只改数值表示剪枝会改变结构后续往往需要重训练蒸馏则需要准备额外的小模型和一个完整的蒸馏训练流程周期最长。3.2 从FP32到INT8PTQ量化实操记录量化分为训练后量化PTQ和量化感知训练QAT。PTQ不需要重新训练模型只是用少量校准数据统计权重和激活值的分布然后映射到INT8范围。QAT则需要在训练过程中模拟量化误差精度更高但成本和复杂度都高一个等级。PTQ流程我整理为四步准备200到500张有代表性的校准图片覆盖类别分布和光照、角度等真实场景差异。在推理框架我用的是PyTorch TensorRT里开启per-channel量化对权重做量化对激活值用per-tensor量化。统计每层激活值的min/max范围这一步最好使用百分位而不是全局min/max因为个别异常值会撑大量化范围导致精度下降。我习惯用99.99%百分位做截断。跑一遍完整验证集对比INT8和FP32的精度差。如果掉点超过1%优先调整校准数据量或百分位阈值。校准数据的选择是最容易被忽略的坑。我曾经偷懒用了训练集里的几百张图片做校准结果模型在真实场景测试时精度暴跌。原因是训练集图片和部署场景的真实数据分布有偏差校准出来的量化范围失真。后来我改成从线上采集的日志中抽取真实推理图片做校准精度差异立刻恢复正常。3.3 剪枝不只是删参数结构化剪枝与稀疏化重训练剪枝的思路是砍掉不重要的神经元、通道或者注意力头。我在Model-Optimizer里主要做的是结构化剪枝也就是直接删掉卷积层的某个输出通道。相比非结构化剪枝权重矩阵里的零散置零结构化剪枝能真正减少计算量而不只是减少存储量。剪枝的具体步骤是对每个卷积层的每个输出通道计算它对应BN层的缩放因子gamma的L1范数gamma小说明这个通道对输出贡献低优先剪掉。设定全局剪枝比例比如40%然后按所有通道重要性排序保留前60%。剪完后的模型必须重训练或者至少微调几轮让剩余通道重新适应任务。我一般用初始学习率的十分之一跑原训练数据的20%左右就能恢复大部分精度。这里有个特别容易踩的坑beta、gamma层在剪枝后顺序会变如果你的代码直接按索引做权重切片没有正确重新映射BN层和卷积层的通道对应关系模型跑起来就是错乱的。我折腾了整整一个下午才查出这个问题最终确认是剪枝后的通道索引映射没做对。这个bug在TensorRT导出时不会报错只会默默输出错误的结果排查起来非常恶心。4. 常见问题与排查技巧实录4.1 训练时loss变成NaN先稳住优化器再查数据NaN问题在Model-Optimizer项目里遇到过好几次。第一次是训练一个深层Transformer模型第几百步时loss突然变成NaN梯度值也爆掉。排查思路是这样的第一步把学习率降到原来的十分之一如果NaN不再出现大概率是学习率过大。第二步检查数据中是否包含NaN特征值特别是文本任务里padding_mask和attention_mask没有对齐时logits里会混入无穷大。第三步检查数值精度如果开了混合精度AMP且没有开启grad_scaler梯度下溢也会导致NaN。我个人遇到的情况是模型里用了一个exp(x)的softmax前处理输入x中有几个非常大的正数导致exp溢出为inf再除就变成NaN。修复方式是给x先减去最大值log-sum-exp技巧数值上立刻稳定。这个坑是复现别人代码时踩到的提醒大家不要轻信网上copy下来的预处理公式带着跑一遍才放心。4.2 量化后精度掉点严重问题多半在校准阶段而不是模型本身很多朋友跑PTQ遇到INT8精度掉3%以上第一反应是量化方法有问题马上想转QAT。但我的经验是掉点的大部分原因在校准数据的质量和校准参数的选择上。首先校准数据样本量太少少于100张会导致激活值范围统计不准。其次量化范围如果直接取激活值的min/max很容易被离群点带偏。我曾经在某个检测模型上试过直接min/max校准掉点2.3%改用99.99%百分位后掉点降到0.6%。还有一个细节有些模型里存在对数值敏感的分支比如检测头的decode模块或者分割模型的边界细化层。这些层最好跳过量化保持FP32。TensorRT里可以给指定层设置精度PyTorch的torch.autocast也能做类似的事。我一般会先逐层评估量化敏感度把误差最大的前5个层挑出来保持FP32整体精度损失通常就能控制在可接受范围。4.3 显存不足和吞吐量之间的权衡一次真实调优记录训练时最容易遇到的是CUDA out of memory。Model-Optimizer项目里我跑一个batch size 16的检测模型直接OOM当时第一反应是降batch size降到8确实能跑但训练速度慢了一半。后来我做了三件事打开混合精度AMP显存直接减半batch size又从8升到了12。用torch.utils.checkpoint对Backbone做梯度检查点用一次前向重计算换显存batch size最终回到16。关闭优化器状态的momentum缓存如果你用SGDmomentum缓存占优化器显存的大头把优化器换成Adafactor训练大模型时显存占用比AdamW少一个量级。推理阶段的显存优化则简单得多动态batch、模型半精度权重加载、以及及时清理CUDA cache。推理时我还会故意把batch size压到4以下来降低延迟波动因为过大的batch虽然吞吐高但单次推理延迟会拉高不符合实时的要求。这中间需要根据实际场景去平衡没有绝对最优。5. 最后分享一个Model-Optimizer项目里的小技巧整个项目做下来我最大的一点点经验是优化前先做性能基线分析别凭感觉动手。一开始我总想着先把模型量化到INT8、剪枝50%、蒸馏一个小模型多个手段叠加看起来收益最大结果每个方向都做了一半反而没有一个跑了完整的评估。后来我改成每次只做一种优化手段完整跑完精度和速度评测把数据记录在对照表里再决定下一步。这种“一次只动一个变量”的思路看起来进展慢实际是最快的。因为每一步的收益和代价都明确后面再做组合时心里有数。Model-Optimizer这个项目后续我还在扩展两个方向一个是把量化、剪枝后的模型用AutoML方案自动搜索最优压缩组合另一个是把优化器调参的结果统一收集起来形成一套针对不同任务自动推荐超参的规则库。如果你正在做类似的优化工作建议也从自己的训练日志里总结规律长时间的积累比网上任何标准答案都更贴合你的实际场景。
Model-Optimizer实战：从优化器选型到量化剪枝的深度学习模型优化全流程
我最初看到“Model-Optimizer”这个项目名时第一反应是这不就是深度学习里那个optimizer选型的事吗但真正把项目做下来才发现这个名字背后能装的东西远比想象中大。Model-Optimizer在我这里被定义成一个贯穿训练和推理全流程的优化工具箱——它既包含训练阶段优化器SGD、AdamW这些的选型和超参调优也包含模型训练完成后针对部署场景的量化、剪枝、蒸馏等压缩手段。简单说这个项目解决的是三个问题训练能不能更稳、更快模型能不能更小、推理能不能更省。这篇文章我打算完整拆解一下我在Model-Optimizer项目里的思路、踩过的坑、以及最终落地的方案。它适合正在做深度学习训练调参的人也适合那些模型已经训练完、但卡在显存不够、推理延迟过高、部署资源受限的工程师。无论你是刚入门还是已经调过一阵子参这里面应该都有可以直接抄作业的内容。1. Model-Optimizer的整体设计优化不是单点改动而是一条链路1.1 训练阶段和推理阶段优化的是两件完全不同的事项目最开始我只盯着训练阶段的optimizer比如Adam和SGD哪个好、学习率怎么设、weight decay该给多少。后来发现对于大多数实际业务场景训练阶段的优化和部署阶段的优化是两个独立的问题域但它们经常被混为一谈导致项目目标模糊。训练阶段的优化关注的是收敛速度、稳定性、最终精度泛化能力。你要的是模型在验证集上表现好训练过程别动不动就loss爆炸。推理阶段的优化关注的是显存占用、推理延迟、吞吐量、功耗。你要的是模型能在GPU上跑得动、在CPU上也能接受、在边缘设备上不至于卡死。Model-Optimizer这个项目就是把我手头多个模型的优化实践统一到一个流程里训练时把optimizer和调度器调稳训练完再针对目标硬件做压缩和加速。两者之间还有一条隐含的关联——如果训练阶段不加正则、不做扰动模型权重本身质量差后面做量化剪枝时精度掉点会更严重。所以整个优化的起点不是部署那一刻而是训练刚开始时的超参设置。1.2 为什么我不用框架的默认配置而是自己手动控制现在PyTorch、TensorFlow里一行model.fit()或者Trainer.train()就能把训练跑起来默认配置已经很均衡。但默认意味着平庸尤其当你的任务不是标准ImageNet分类而是目标检测、语义分割、或者多模态模型时默认优化器往往不是最优解。举个例子PyTorch里Adam默认学习率是1e-3这对很多CV任务来说偏大容易在训练后期震荡而默认的weight decay在Adam里实际上并不规范真正应该用的是AdamW里解耦的weight decay方案。如果完全依赖默认配置项目前期的训练曲线就会埋下隐患。我在Model-Optimizer里做的最重要决定是把训练和推理的所有可控参数显式地记录、对比、版本化。每个实验都有一份超参配置文件optimizer类型、学习率策略、warmup步数、量化方式、剪枝比例全部落在代码仓库里而不是散落在训练日志里。这样做的直接好处是项目能做到任何一次实验结果都可以复现任何一次优化尝试都可以量化收益。后面讲实操时我会拿具体配置例子说明。2. 训练优化器选型与调参从AdamW到SGD的实战对比2.1 优化器的本质在梯度下降这张地图上怎么走得更聪明要理解optimizer选型可以先把它类比成下山。SGD就是一个只知道当前位置、跟着最陡方向走的人步长学习率固定容易走弯路但最终能到山脚。Adam则像是一个带“惯性”和“自适应步伐”的人它会把过去几步的方向和坡度大小都记下来遇到平坦区域自动迈大一步遇到陡坡自动收小步伐所以前期收敛非常快。问题在于Adam虽然快但泛化性能经常不如调好参数的SGD。这背后的原因学术上有多种解释我自己的理解是Adam对每个参数用梯度的二阶矩做归一化相当于给整个参数空间都做了不同程度的缩放这会让某些方向的更新变得过于“平滑”反而削弱了正则化带来的隐式惩罚效果。而SGD虽然笨但它的随机性恰恰给训练带来了一种隐式的正则化。所以在Model-Optimizer项目里我的选型规则很简单场景推荐优化器原因标准CNN分类/检测任务训练资源充足SGD Momentum泛化好收敛稳定配合cosine退火效果好Transformer/BERT类模型或训练初期想快速看到效果AdamW自带解耦weight decay训练稳定适配attention机制大规模预训练 下游微调AdamW 分层学习率不同层更新幅度不同保持预训练特征计算资源有限希望快速迭代Adam不带W参数少、收敛快可后期切SGD精调2.2 分组学习率、warmup和cosine退火的配置记录项目里我用得最顺手的组合是AdamW 线性warmup cosine退火。warmup的意义很多人知道但具体怎么选步数是有讲究的。warmup步数一般取总训练步数的5%到10%。比如总训练步数50000步warmup就是2500到5000步。warmup期间学习率从0线性升到目标值目的是让模型先以一个温和的节奏适应数据分布避免一开始梯度太大导致loss震荡甚至发散。我实测过特别是用了大learning rate比如3e-4以上的BERT微调不配warmup几乎必然出现前几百步loss不降反升的情况。cosine退火则是让学习率沿着余弦曲线从峰值降到接近0。它的好处是前期下降缓慢模型有充足时间在大学习率区间探索后期下降加快帮助模型收敛到更平滑的极小值点。和传统的step decay比如每30轮除以10相比cosine省去了手动判断“什么时候该降学习率”的过程适合大规模自动化实验。以下是我在Model-Optimizer里一个典型视觉任务的优化器配置optimizer: type: AdamW lr: 2e-4 betas: [0.9, 0.999] eps: 1e-8 weight_decay: 0.05 layer_decay: 0.75 scheduler: type: cosine warmup_ratio: 0.08 min_lr: 1e-6这里layer_decay是给Transformer类模型用的分层学习率衰减靠近输入的层衰减多0.75的系数每个block衰减一次越往后保留越多原始预训练信息。这是从MAE、BEiT这些论文里验证过的做法直接抄过来用在微调场景很有效。2.3 怎么判断优化器在正常工作不只是看loss曲线很多人只看train loss下降就觉得万事大吉其实还不够。我在项目里养成了一个习惯每次训练都额外记录梯度范数grad norm和学习率实时值这两条曲线。梯度范数能反馈优化器是否稳定。如果梯度范数突然暴涨到几个数量级以上说明出现了梯度爆炸大概率是学习率太大或者数据里有异常值。如果梯度范数一直特别小比如小于1e-4说明梯度消失模型基本学不动。另外要多关注验证集loss和训练集loss的“开口”时间点。如果训练到某个阶段val loss开始上升但train loss继续下降这是过拟合的明确信号。这时与其调optimizer不如先检查weight decay是否太小、数据增强是否太弱。实践中我把weight decay从0.01调到0.05后val loss的开口时间往后推迟了将近20%的训练轮数。3. 推理阶段压缩与加速量化、剪枝、蒸馏的落地路径3.1 先确认目标硬件再决定压缩手段训练完成后进入部署阶段Model-Optimizer的第二个功能模块开始起作用。这里最关键的一步不是立刻选量化还是剪枝而是先确认一个核心问题目标硬件和延迟目标是什么如果你部署在NVIDIA GPU上TensorRT和FP16/INT8量化是首选速度快、工具链成熟。如果你部署在CPU上剪枝和蒸馏可能比量化更有效尤其是那些结构稀疏度本来就高的模型。如果你部署在手机或嵌入式设备上那么量化几乎是必选项因为内存带宽和算力都有限。我自己碰到的典型场景是一个语义分割模型FP32版本在GPU上单帧推理12ms需要降到5ms以内才能满足实时需求。当时我第一时间尝试INT8量化结果速度从12ms降到4ms精度mIoU只掉了0.8个百分点。这个收益远大于剪枝带来的两倍加速。所以我的优先级建议是先量化再剪枝蒸馏作为最后手段。量化是“白捡”的加速不改变模型结构只改数值表示剪枝会改变结构后续往往需要重训练蒸馏则需要准备额外的小模型和一个完整的蒸馏训练流程周期最长。3.2 从FP32到INT8PTQ量化实操记录量化分为训练后量化PTQ和量化感知训练QAT。PTQ不需要重新训练模型只是用少量校准数据统计权重和激活值的分布然后映射到INT8范围。QAT则需要在训练过程中模拟量化误差精度更高但成本和复杂度都高一个等级。PTQ流程我整理为四步准备200到500张有代表性的校准图片覆盖类别分布和光照、角度等真实场景差异。在推理框架我用的是PyTorch TensorRT里开启per-channel量化对权重做量化对激活值用per-tensor量化。统计每层激活值的min/max范围这一步最好使用百分位而不是全局min/max因为个别异常值会撑大量化范围导致精度下降。我习惯用99.99%百分位做截断。跑一遍完整验证集对比INT8和FP32的精度差。如果掉点超过1%优先调整校准数据量或百分位阈值。校准数据的选择是最容易被忽略的坑。我曾经偷懒用了训练集里的几百张图片做校准结果模型在真实场景测试时精度暴跌。原因是训练集图片和部署场景的真实数据分布有偏差校准出来的量化范围失真。后来我改成从线上采集的日志中抽取真实推理图片做校准精度差异立刻恢复正常。3.3 剪枝不只是删参数结构化剪枝与稀疏化重训练剪枝的思路是砍掉不重要的神经元、通道或者注意力头。我在Model-Optimizer里主要做的是结构化剪枝也就是直接删掉卷积层的某个输出通道。相比非结构化剪枝权重矩阵里的零散置零结构化剪枝能真正减少计算量而不只是减少存储量。剪枝的具体步骤是对每个卷积层的每个输出通道计算它对应BN层的缩放因子gamma的L1范数gamma小说明这个通道对输出贡献低优先剪掉。设定全局剪枝比例比如40%然后按所有通道重要性排序保留前60%。剪完后的模型必须重训练或者至少微调几轮让剩余通道重新适应任务。我一般用初始学习率的十分之一跑原训练数据的20%左右就能恢复大部分精度。这里有个特别容易踩的坑beta、gamma层在剪枝后顺序会变如果你的代码直接按索引做权重切片没有正确重新映射BN层和卷积层的通道对应关系模型跑起来就是错乱的。我折腾了整整一个下午才查出这个问题最终确认是剪枝后的通道索引映射没做对。这个bug在TensorRT导出时不会报错只会默默输出错误的结果排查起来非常恶心。4. 常见问题与排查技巧实录4.1 训练时loss变成NaN先稳住优化器再查数据NaN问题在Model-Optimizer项目里遇到过好几次。第一次是训练一个深层Transformer模型第几百步时loss突然变成NaN梯度值也爆掉。排查思路是这样的第一步把学习率降到原来的十分之一如果NaN不再出现大概率是学习率过大。第二步检查数据中是否包含NaN特征值特别是文本任务里padding_mask和attention_mask没有对齐时logits里会混入无穷大。第三步检查数值精度如果开了混合精度AMP且没有开启grad_scaler梯度下溢也会导致NaN。我个人遇到的情况是模型里用了一个exp(x)的softmax前处理输入x中有几个非常大的正数导致exp溢出为inf再除就变成NaN。修复方式是给x先减去最大值log-sum-exp技巧数值上立刻稳定。这个坑是复现别人代码时踩到的提醒大家不要轻信网上copy下来的预处理公式带着跑一遍才放心。4.2 量化后精度掉点严重问题多半在校准阶段而不是模型本身很多朋友跑PTQ遇到INT8精度掉3%以上第一反应是量化方法有问题马上想转QAT。但我的经验是掉点的大部分原因在校准数据的质量和校准参数的选择上。首先校准数据样本量太少少于100张会导致激活值范围统计不准。其次量化范围如果直接取激活值的min/max很容易被离群点带偏。我曾经在某个检测模型上试过直接min/max校准掉点2.3%改用99.99%百分位后掉点降到0.6%。还有一个细节有些模型里存在对数值敏感的分支比如检测头的decode模块或者分割模型的边界细化层。这些层最好跳过量化保持FP32。TensorRT里可以给指定层设置精度PyTorch的torch.autocast也能做类似的事。我一般会先逐层评估量化敏感度把误差最大的前5个层挑出来保持FP32整体精度损失通常就能控制在可接受范围。4.3 显存不足和吞吐量之间的权衡一次真实调优记录训练时最容易遇到的是CUDA out of memory。Model-Optimizer项目里我跑一个batch size 16的检测模型直接OOM当时第一反应是降batch size降到8确实能跑但训练速度慢了一半。后来我做了三件事打开混合精度AMP显存直接减半batch size又从8升到了12。用torch.utils.checkpoint对Backbone做梯度检查点用一次前向重计算换显存batch size最终回到16。关闭优化器状态的momentum缓存如果你用SGDmomentum缓存占优化器显存的大头把优化器换成Adafactor训练大模型时显存占用比AdamW少一个量级。推理阶段的显存优化则简单得多动态batch、模型半精度权重加载、以及及时清理CUDA cache。推理时我还会故意把batch size压到4以下来降低延迟波动因为过大的batch虽然吞吐高但单次推理延迟会拉高不符合实时的要求。这中间需要根据实际场景去平衡没有绝对最优。5. 最后分享一个Model-Optimizer项目里的小技巧整个项目做下来我最大的一点点经验是优化前先做性能基线分析别凭感觉动手。一开始我总想着先把模型量化到INT8、剪枝50%、蒸馏一个小模型多个手段叠加看起来收益最大结果每个方向都做了一半反而没有一个跑了完整的评估。后来我改成每次只做一种优化手段完整跑完精度和速度评测把数据记录在对照表里再决定下一步。这种“一次只动一个变量”的思路看起来进展慢实际是最快的。因为每一步的收益和代价都明确后面再做组合时心里有数。Model-Optimizer这个项目后续我还在扩展两个方向一个是把量化、剪枝后的模型用AutoML方案自动搜索最优压缩组合另一个是把优化器调参的结果统一收集起来形成一套针对不同任务自动推荐超参的规则库。如果你正在做类似的优化工作建议也从自己的训练日志里总结规律长时间的积累比网上任何标准答案都更贴合你的实际场景。
