我最初看到“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到INT8：PTQ量化实操记录
量化分为训练后量化（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缓存（如果你用SGD，momentum缓存占优化器显存的大头），把优化器换成Adafactor，训练大模型时显存占用比AdamW少一个量级。
推理阶段的显存优化则简单得多：动态batch、模型半精度权重加载、以及及时清理CUDA cache。推理时我还会故意把batch size压到4以下来降低延迟波动，因为过大的batch虽然吞吐高，但单次推理延迟会拉高，不符合实时的要求。这中间需要根据实际场景去平衡，没有绝对最优。
5. 最后分享一个Model-Optimizer项目里的小技巧
整个项目做下来，我最大的一点点经验是：优化前先做性能基线分析，别凭感觉动手。一开始我总想着先把模型量化到INT8、剪枝50%、蒸馏一个小模型，多个手段叠加，看起来收益最大，结果每个方向都做了一半，反而没有一个跑了完整的评估。
后来我改成每次只做一种优化手段，完整跑完精度和速度评测，把数据记录在对照表里，再决定下一步。这种“一次只动一个变量”的思路，看起来进展慢，实际是最快的。因为每一步的收益和代价都明确，后面再做组合时心里有数。
Model-Optimizer这个项目后续我还在扩展两个方向：一个是把量化、剪枝后的模型用AutoML方案自动搜索最优压缩组合，另一个是把优化器调参的结果统一收集起来，形成一套针对不同任务自动推荐超参的规则库。如果你正在做类似的优化工作，建议也从自己的训练日志里总结规律，长时间的积累比网上任何标准答案都更贴合你的实际场景。
