最近半年我一直在维护一个内部代号叫Model-Optimizer的项目。名字听起来像某个现成的开源优化器，其实它是一套模型优化流程：把训练提速、显存压减、模型瘦身、推理加速这四件事整合在同一套方法论里。靠着这套流程，我把两个线上模型的训练时间砍掉了将近一半，推理延迟从 40ms 压到 12ms，模型体积降了一个数量级，精度几乎没有可见损失。

这篇文章就围绕 Model-Optimizer 这套东西展开，讲清楚几个核心问题：优化器选型背后的逻辑、学习率和混合精度的实际调法、剪枝和量化的完整链路、推理引擎的踩坑经验，以及落地时最容易翻车的细节。它不是一篇纯理论科普，更像一份可以直接照着做的优化实施笔记。适合正在被训练速度、显存占用、线上延迟困扰的工程师，也适合刚接触模型优化、想搞明白“到底在优化什么”的入门者。

1. 先把 Model-Optimizer 要解决的问题说清楚

1.1 为什么需要一个独立的模型优化层

很多团队提到“模型优化”，第一反应就是换优化器、调学习率。真正做下来才发现，优化这件事贯穿数据、模型、训练和部署四个阶段，任何一环都可能成为瓶颈。我们最开始也是把加速手段散落在各个脚本里，今天加一个accumulate，明天改一版scheduler，结果问题越补越多，最后连“当前瓶颈到底是什么”都说不清。

Model-Optimizer 这套方案的核心，是把所有优化手段收敛成一条可复用的流程，并且强制在动手前回答三个基本问题：

• 优化目标到底是训练周期、显存占用，还是线上延迟？
• 当前瓶颈是算力、显存、IO，还是算子本身？
• 优化后用什么指标验收，允许多大的精度损失？

这三个问题不先拎清楚，后面很容易白忙。举个很简单的例子：一个 ResNet 分类模型，在 GPU 上训练本来只要两小时，你却花大量精力去搞剪枝，投入产出比就非常低；反过来，如果线上推理卡在某个细碎算子组合上，可能只需要把图优化打开，或者换一个推理引擎，延迟立刻下降一半。Model-Optimizer 这个“优化层”存在的意义，就是逼你先定位、再动手，而不是盲目堆技巧。

1.2 优化对象与性能指标

为了不把不同阶段的问题混在一起，我会把优化对象分成三块，每块对应独立的指标考核。

分开维护指标有个很重要的原因：它们之间经常互相拉扯。量化能把模型体积压到原来的四分之一，但精度可能掉；剪枝能让推理变快，但通常需要重新微调；混合精度能缩短训练时间，但某些敏感算子如果也被半精度化，loss 可能直接发散。所以优化必须形成一张“指标清单”，每次只动一个变量，改完立刻对拍，确认没有引入新问题后再进行下一步。

1.3 适用场景和边界

Model-Optimizer 这套流程并不是万能药。从我做下来的经验看，它比较适合以下几种情况：

• 模型结构和数据集已经相对稳定，不会频繁变更。
• 瓶颈很明确，比如训练时间太长、显存偶尔溢出、线上延迟超时。
• 团队能接受“用少量精度换取速度或体积”的折中方案。
• 有清晰的基线和评估集，可以量化每一次改动的影响。

不适合的场景也有：模型还在频繁改结构，每天换 backbone、换 loss，这时候上优化流程很容易白费功夫，应该先把模型主线定下来；业务场景对精度极其敏感，一点抖动都不能接受，那就只能走比较重的量化感知训练或蒸馏路线，成本会高很多。

另外要明确一个边界：Model-Optimizer 不会帮你发明新模型结构。它解决的是“在固定结构下把资源吃紧的问题解决掉”，不负责效果从 85% 涨到 92%。那个属于模型设计范畴，不要混在一起。

2. 训练侧的优化：让模型先跑得快、跑得稳

2.1 优化器选型不能只看名字

优化器是整个训练过程里最容易背锅的模块。很多人一上来就换成 Adam，觉得“自适应学习率怎么都比 SGD 好吧”，但结果不一定。我见过不少视觉模型，用 SGD + momentum 调到合适的学习率后，收敛速度和最终精度都优于 Adam。

选型要看任务类型。通常的经验是：

• SGD + momentum：适合 CNN 分类、检测等任务，泛化能力强，调好 warmup 和 lr 后非常稳定。
• Adam / AdamW：适合 Transformer 结构、多模态特征对齐、训练初期容易不稳定的场景。AdamW 是 Adam 的改进版，把 weight decay 从 L2 正则中解耦出来，效果在多数任务上更好。
• LAMB：适合超大 batch 的预训练场景，比如单 batch 上万样本时，LAMB 能保持比较稳的收敛。

原理层面可以这样理解：SGD 对每个参数用相同的步长，方向由 gradient 和 momentum 决定，所以对初始学习率很敏感，但泛化往往更好；Adam 利用梯度的一阶矩和二阶矩，为每个参数单独调整步长，对学习率不那么敏感，但长期训练时容易在小梯度上产生过大的修正，导致泛化掉点。AdamW 把权重衰减从梯度修正里拿出来，一定程度上缓解了这个问题。

实际配置时，我用 PyTorch 通常会这样写：

import torch model = torch.nn.Linear(128, 10) # 只是示例 # SGD with momentum optimizer_sgd = torch.optim.SGD( model.parameters(), lr=0.01, momentum=0.9, weight_decay=5e-4, nesterov=True, ) # AdamW optimizer_adamw = torch.optim.AdamW( model.parameters(), lr=1e-4, betas=(0.9, 0.999), weight_decay=0.01, )

如果稳定性优先，我一般先用 SGD+momentum 跑一个小的模型验证集，把基线打出来；如果是多模态或者 Transformer 类模型，直接上 AdamW，但 lr 从 1e-4 起调，不要拍脑袋给太大。

2.2 学习率策略的实际调法

模型收敛质量很多时候不是优化器决定的，而是学习率策略决定的。我常用的策略有两种：warmup + cosine decay和step decay。

warmup 加 cosine 的思路是：训练初期梯度方向噪声很大，直接用大学习率容易发散，所以先用一小段时间把学习率从 0 线性或指数式升到目标值；训练后期再用 cosine 曲线把学习率平滑降到接近 0，让损失在收敛末尾阶段稳定下降。step decay 则是在固定 epoch 处把学习率乘以一个衰减系数，比如在第 30、60、80 个 epoch 分别乘以 0.1，适合训练轮次固定的场景。

这里有一个容易出现 bug 的地方：batch size 翻倍时，学习率也要做相应的线性缩放。如果你的 batch size 从 128 提高到 256，那学习率一般也要乘以 2，否则模型更新步数变少，收敛会变慢。很多人不动学习率，结果发现“扩大 batch 效果变差了”，其实不是方法问题，是学习率没跟上。

确定具体学习率值时，我会先用一个小数据集跑一遍 learning rate finder：从一个很小的学习率（比如 1e-6）开始，逐步增大到较大的值（比如 1e-1），每跑一小步记录 loss，画出 loss 曲线。最优 lr 通常落在 loss 下降最陡的区域附近。比如下降速度最快的位置对应 lr=3e-3，那最终 lr 就取 1e-3 到 3e-3 之间，比较稳妥。

warmup 步数一般取总训练步数的 5% 到 10%。如果总步数接近百万级，warmup 比例可以适当降低；如果只有几千步，warmup 可以省略，甚至可以尝试不用 warmup 直接跑。

2.3 混合精度与显存吞吐优化

训练侧收益最明显且改动最小的方案，就是混合精度。现代 GPU 通常都支持 FP16 计算，配合 Tensor Core 可以把训练速度提升 30% 到 80%，同时显存占用也能下降不少。

PyTorch 里的自动化 AMP 用下来很稳，基本逻辑是：前向和反向时使用 FP16，优化器更新参数时使用 FP32，中间用一个 GradScaler 动态调整 loss scale，防止小梯度在 FP16 下直接下溢到 0。

一个容易被忽略的点是：不是所有算子都适合 FP16。像 LayerNorm、Softmax 这类对精度敏感的操作，最好通过torch.cuda.amp.autocast自动管理的规则让它们保持在 FP32。如果你发现混合精度训练时 loss 曲线有不正常的抖动，先看日志里 loss scale 是否在持续下降，如果一直下降，大概率是某个算子对 FP16 太敏感。

显存优化方面，最有用的两个手段是gradient accumulation和gradient checkpointing。Gradient accumulation 并不降低单样本显存，它只是把 N 个 batch 的梯度累积起来，再一次性更新参数，相当于等效扩大了 batch size。比如你想用 64 的 batch size，但显存只能塞下 16，那就跑 4 个小 batch 再更新一次参数。它解决的是“batch size 不够影响收敛”的问题，不解决“单 batch 显存放不下”。

Gradient checkpointing 则完全相反，它是用计算换显存：前向传播时不保存中间激活，反向传播时临时重新计算。显存峰值通常能降低 50% 到 70%，代价是训练时间增加 20% 到 30% 左右，适合大模型、大输入的场景。

数据加载同样不能拖后腿。DataLoader里num_workers要开够，pin_memory=True建议打开，它能让 GPU 从页锁定内存直接拷贝数据，减少宿主端传输时间。训练时养成看 GPU 利用率的习惯，nvidia-smi里 GPU-Util 如果长期低于 70%，问题多半不在模型，而在数据加载或存储在瓶颈。

3. 部署侧的优化：让模型瘦下来、跑得快

3.1 模型结构上的减重思路

训练和模型瘦身是两回事。模型结构减重，常用手段有三类：剪枝、知识蒸馏、低秩分解。

剪枝是去掉模型中不重要的连接或通道。非结构化剪枝，也就是对单个权重做稀疏化，理论上参数量下降很多，但稀疏矩阵在普通 CPU 和 GPU 上不一定能转换成实际速度，很多硬件对随机稀疏不友好。所以我更推荐做结构化剪枝，尤其是通道剪枝：直接剪掉卷积分支里的某个通道，输出数据结构保持不变，后续计算量实实在在减少，也更容易和推理引擎配合。

通道剪枝怎么判断哪个通道不重要？比较常见的方法是利用 BatchNorm 的缩放因子。训练时在 BN 层后面加一个稀疏约束，逼迫大部分缩放因子趋向 0，然后用这些缩放因子作为通道重要性的排序，把值很小的通道剪掉。实际操作时要注意：剪枝比例不要一次拉太高，我先从 30% 试起，配合微调，观察精度变化再决定是否加大比例。

知识蒸馏是另一种思路：让一个小模型（学生）去学大模型（教师）的软输出。普通训练给的是 hard label，蒸馏用softmax(logits / T)得到的 soft label 作为监督，温度 T 拉高了低置信度类别的信息。比如原来正确类是猫，其他类别概率接近 0，但温度调高后，“狗”和“老虎”的概率分布被展平，这些类间关系信息对学生模型很有帮助。T 一般取 3 到 8，学生模型结构可以比教师小很多。用蒸馏训练一个 MobileNet 级的小模型，经常能在保留 95% 以上精度的前提下，把参数量压到原来的 1/5 甚至更低。

低秩分解现在的使用频率不如前两种。它适合全连接层比较多、权重矩阵本身存在较大冗余的模型，把一个大矩阵拆成两个小矩阵，计算量能减少。但视觉模型里卷积占大头，低秩分解收益有限，更适合老式的 DNN 推荐模型。

3.2 量化：从 FP32 到 INT8 的完整链路

量化是部署优化里收益最直接的手段。原理很简单：把浮点数值映射到整数区间，比如 FP32 的权重经过 scale 和 zero point 换算后变成 INT8，单个参数从 4 字节降到 1 字节，模型体积缩到 1/4，推理速度通常也能上一个台阶。

量化的两个关键概念是per-tensor 和 per-channel。Per-channel 对权重的每一输出通道单独算 scale，精度通常更好，因为不同通道的取值范围可能差别很大；Per-tensor 全层用同一组缩放参数，实现简单，但如果某一通道数值特别大，其他通道都会被“带偏”。经验上，权重建议用 per-channel 对称量化，激活层用 per-tensor 非对称量化。

量化落地有两条路线：PTQ和QAT。

PTQ 是在训练后用少量校准数据统计每层激活范围，直接转 INT8，速度快、不需要重新训练。关键点是校准数据集要有代表性，我一般取 200 到 500 张覆盖不同场景的线上样本，样本如果过少或分布偏了，量化后的精度会明显掉。做完 PTQ 后，如果某些层精度掉得厉害，可以采用混合精度量化，把敏感层保留为 FP16 或 FP32，其余层走 INT8，这也是工程上最常用的折中方案。

QAT 是量化感知训练：在训练过程中就把伪量化误差模拟进去，让模型在量化环境里适应。它能比 PTQ 保住更多精度，但代价是训练时间增加，调参也要多花精力。实操中，我会先做一轮 PTQ 看精度是否在可接受范围；如果掉点超过阈值，再考虑 QAT，不直接上重型方案。

量化不是单独生效的。剪枝后先微调，再做量化，往往比单独量化精度更好；反过来，如果先量化再剪枝，误差会叠加，精度崩掉的可能性很大。

3.3 运行时与推理引擎的取舍

模型量化完，还需要推理引擎把它跑起来。不同的引擎擅长不同平台：

推理引擎最大的优化点是算子融合和内存复用。比如Conv + BN + ReLU三段算子，如果能融合成一个节点，少几次中间张量的读写，延迟自然降低。TensorRT 的图优化做得很彻底，环境合适时，单纯换个引擎就能让 FP32 模型跑出接近 FP16 的速度。

有一个很常见的误区：只盯着模型本身，忽略了预处理和后处理。实际线上延迟 = 输入解码 + 缩放归一化 + 模型推理 + 输出解析。如果每次请求都要在 CPU 上做 resize，瓶颈依然在数据通道上。条件允许时，可以把图像预处理也放到 GPU 上用算子实现，或者直接编进 TensorRT 插件，这个优化往往比模型优化更猛。

4. 一次真实的 Model-Optimizer 落地过程

4.1 现网模型的摸底与基线建立

拿我一个图像分类模型举例。原始模型是 ResNet18，训练集 12 万张，单卡训练一个完整周期要 9 小时；线上服务跑在 2 核 CPU 容器上，单次请求 p99 延迟 40ms，模型文件 47MB，分类准确率 91.2%。

开始优化前，我先做了完整摸底：

• 训练侧记录：单轮训练时长、显存峰值、loss 曲线、稳定后的准确率。
• 部署侧记录：p99 / p95 延迟、每秒吞吐 QPS、进程内存占用、模型体积。

这些数据必须留档，而且每次改动都要重新对拍。没有基线，后面所有优化都说不清楚到底是变好还是变坏。

4.2 分阶段优化路线

我把这一轮优化分成两个阶段，训练侧先走，部署侧跟进。

训练侧优化：优化器保留 SGD + momentum，但把学习率策略从固定值改成了 warmup + cosine decay，warmup 步数设为总步数的 8%；同时开启混合精度 AMP，batch size 从 128 提高到 256，对应学习率做了线性缩放。训练时间从 9 小时降到 5 小时，最终准确率从 91.2% 升到了 91.5%，说明调整是正向的。

部署侧优化：先做通道剪枝。我用 BN 缩放因子做重要性排序，剪掉 40% 的通道，模型体积从 47MB 降到 29MB。剪完之后重新微调 5 个 epoch，准确率从 91.5% 降到 91.2%，损失很轻微。然后做 PTQ，用 300 张线上真实样本作为校准集，转成 INT8 后，模型文件只剩 5.8MB，延迟从 40ms 降到 22ms，准确率又掉了 0.2pp，到 91.0%。最后把模型导出成 ONNX，接入 ONNX Runtime，开启算子融合后，p99 延迟从 22ms 压到 12ms，模型体积保持 5.8MB 不变。

4.3 效果对拍与验收

所有优化叠加后的结果如下：

验收标准我当时定的是：准确率下降不能超过 0.5pp，p99 延迟波动不能超过 10%。最终准确率 91.0%，符合要求。上线前用同一批测试集做了 A/B 比对，连续压测 3 小时，没有出现长尾超时。

这个过程说明，模型优化不是单点操作，而是多个手段的组合。单独做剪枝收益有限，单独换引擎也吃不到量化带来的体积红利。分阶段优化、每阶段留档，是最稳妥的路线。

5. 常见问题与排查技巧实录

5.1 训练侧：loss 不降或震荡怎么办

我遇到最多的训练问题是 loss 不降或反复震荡。排查顺序按经验来：

• 先用小 batch 过拟合一小部分数据，如果 loss 能降到接近 0，说明模型本身没问题，问题在数据或学习策略。
• 再打印梯度范数。如果梯度范数突然暴涨又变回 0，多半是梯度爆炸，加torch.nn.utils.clip_grad_norm_，阈值设 1.0 或 0.5。
• 如果是固定轮次后才出现 loss 震荡，看看是不是 lr 太高，warmup 结束前后很容易翻车。
• 如果数据里噪声多，标签错误率高，适度增大 warmup 比例，并考虑 label smoothing。

一个很多人都踩过的坑：混合精度开了，但没有用 GradScaler。FP16 的梯度容易下溢，模型看似在训练，实际上参数几乎没更新，loss 长期不降。

5.2 部署侧：量化后精度掉得多

量化后精度掉太多，常见原因有四个：

• 校准集太少或和线上数据分布不一致，导致激活范围统计不准。
• 某些层对量化很敏感，比如检测头的回归分支、注意力层。
• 模型本身已经很小，冗余度低，量化误差没有缓冲余地。
• 权重量化方式用了 per-tensor，没有尝试 per-channel。

排查方法：先做一次逐层量化误差分析，把每一层单独用 FP32 权重替换回量化模型，看哪一层单独恢复能带来最大的精度回升。定位到敏感层后，把这层设为混合精度，其他层保持 INT8。如果这样还不行，就上 QAT。另外记住，剪枝后要先微调再量化，两个误差源不要叠加。

5.3 工程侧：框架版本和算子不支持

ONNX 导出时报“不支持的算子”，TensorRT 构建时报 “missing implementation”，这类问题基本是算子兼容性闹的。排查思路：先把模型用 ONNX Runtime CPU 跑一遍，看是不是也能报错；再用可视化工具看一下 ONNX 图里的算子列表，找有没有比较冷门的自定义算子。

处理方法有三种：

• 把自定义算子替换成标准算子组合，这是最省事的。
• 使用推理引擎的 plugin 扩展，TensorRT 允许自己写插件，但成本高。
• 把不支持的部分留在 CPU 上，片外处理，适合只在边界出现的不兼容。

版本问题更要命。CUDA、cuDNN、TensorRT 之间要求精确匹配，升级任何一项，另外几个很可能也要跟着动。我现在所有模型优化环境都用固定版本的 Docker 镜像打包，避免新老环境互相污染。

5.4 避坑清单

最后整理一份自己踩出来的避坑清单，不能说全，但每一条都是拿时间换来的。

说一个很多人忽视的细节：推理延迟的测量一定要附带推理引擎的预热过程。第一次调用通常包含图初始化和显存分配，这个时间会被算进去，导致你误判真实性能。我在压测的时候会先跑 100 次以上，让引擎完全进入稳态，再记录 p99 数据，这样得到的数字才是线上真实体感。

回到 Model-Optimizer 这个项目本身，我最大的体会是：优化最大的风险不是技术做不到，而是想不清楚到底要什么。没有明确的目标、没有基线数据、没有验收红线，再多的技巧也只能让你在原地打转。先把“优化什么、代价是什么、如何验收”想透，后面的每一步才踩得实。如果你正好也被训练资源和线上延迟卡住，不妨从建立基线和单变量改动开始试起，这套流程用起来比预期的还要顺手。