1. 模型优化器到底在优化什么第一次看到 Model-Optimizer 这个词很多人会下意识觉得它又是一个“调参工具”或者“训练加速库”。我刚开始接触的时候也这么想直到在一个实际项目里被推理延迟卡住脖子才真正理解它要解决的问题域有多宽。简单说Model-Optimizer 是一类面向模型全生命周期的优化工具集合它关注的不是模型结构本身的设计而是模型在训练完成之后、部署上线之前如何通过量化、剪枝、图优化、算子融合、内存复用等手段让同一个模型在同样的硬件上跑得更快、占得更少、耗电更低。这件事为什么值得单独拿出来讲因为绝大多数做算法的人习惯把精力花在“把精度刷上去”但真正到了工程落地阶段精度只差零点几个百分点推理速度却可能差三到五倍。用户不会关心你的模型结构多优雅他们只关心点一下按钮之后多久出结果。Model-Optimizer 就是在这个 gap 里做文章的工具链。它适合谁看如果你是把模型从 notebook 推向生产环境的算法工程师、负责推理服务性能的后端开发、或者在做端侧部署的嵌入式方向从业者那这套东西你绕不开。哪怕你只是想把本地跑的一个 demo 模型压缩到能塞进手机里理解 Model-Optimizer 的工作逻辑也能帮你少走很多弯路。我自己的经验是模型优化这件事最怕的不是技术难而是“不知道从哪里下手”。量化、剪枝、蒸馏、图优化、算子替换每个方向都有一堆论文和工具但真正落地的时候你需要的是一个有先后顺序、有取舍逻辑的流程。Model-Optimizer 这类工具的价值就在于它把这些零散的手段串成了一条可操作的流水线让你不用从零开始拼装。2. 核心优化手段的选型逻辑与适用边界2.1 量化最直接的收益来源也是最容易踩坑的地方量化是 Model-Optimizer 里最常被提到的功能没有之一。它的核心思路是把模型权重和激活值从高精度浮点数比如 FP32转换成低精度表示比如 INT8、FP16甚至 INT4。这样做的好处非常直接内存占用直接砍半甚至更多推理时内存带宽压力大幅降低而在支持低精度计算的硬件上吞吐量能提升两到四倍。但量化不是没有代价的。我见过太多人兴冲冲地把模型转成 INT8结果精度掉得亲妈都不认识。问题出在哪儿主要是激活值的动态范围。权重通常分布比较集中量化起来相对温和但激活值在不同输入下波动很大尤其是 Transformer 类模型里的 attention 输出某些通道的数值可能比其他通道大几十倍。如果你用统一的 scale 去量化所有通道小数值通道的信息就被直接抹掉了。所以实际做量化的时候我一般会按这个顺序推进先做动态量化只量化权重激活值在推理时动态计算 scale这个方案几乎不需要校准数据精度损失通常在一个点以内适合快速验证。如果动态量化的加速效果不够再上静态量化这时候就需要准备一批校准数据让工具在推理过程中统计激活值的分布计算出更合理的量化参数。校准数据不用多几百条就够但一定要有代表性不能全用同一个类别的样本。注意静态量化的校准集如果和实际推理分布偏差太大精度损失可能比不做量化还严重。我一般会从验证集里分层抽样确保每个类别都有覆盖。还有一个容易被忽略的点是逐通道量化和逐张量量化的区别。逐通道量化给每个输出通道单独算 scale精度明显更好但需要硬件支持。你在选工具的时候一定要先确认目标推理引擎是否支持逐通道量化否则转了也用不了。2.2 剪枝不是所有零都值得保留剪枝的逻辑听起来很直觉把模型里不重要的权重置零减少计算量。但实际操作中剪枝的坑比量化还多。原因在于剪枝之后如果只是把权重置零计算量并不会减少因为硬件还是得老老实实做乘法。真正要拿到加速收益必须做到结构化剪枝也就是直接删掉整个通道、整个注意力头或者整个层。非结构化剪枝虽然能压掉很多参数但产生的稀疏矩阵在通用硬件上跑不出加速除非你有专门的稀疏计算库。所以我在做剪枝的时候基本只考虑结构化方案。具体做法是先对每个通道计算一个重要性分数常用的指标有权重 L1/L2 范数、BN 层的缩放因子、或者基于梯度的敏感度。然后按比例剪掉分数最低的通道再对剪枝后的模型做微调恢复精度。这里有个经验值可以参考对于卷积网络剪掉 20% 到 30% 的通道精度通常只掉零点几个百分点微调几个 epoch 就能回来。但超过 50% 之后精度下降会变得非常陡峭而且微调也很难救回来。Transformer 类模型对剪枝更敏感尤其是注意力头剪太多会直接破坏模型的表达能力。2.3 图优化与算子融合不改变数值的加速图优化是 Model-Optimizer 里最“安全”的一类优化因为它不改变模型的数值计算结果只是重新组织计算图的结构。最常见的操作包括把 Conv BN ReLU 融合成一个算子消除冗余的 transpose 和 reshape常量折叠死代码消除等等。这些优化看起来不起眼但累积起来的效果很可观。我实测过一个典型的 CNN 模型经过图优化之后推理延迟降低了 15% 到 20%而且精度完全不变。算子融合之所以有效是因为它减少了 kernel launch 的次数和中间张量的内存读写。在 GPU 上kernel launch 的开销有时候比计算本身还大融合之后一个 kernel 干完三个 kernel 的活收益自然就出来了。不过图优化也有边界。有些融合操作会改变数值精度比如把 FP32 的 BN 融合进 FP16 的 Conv可能会引入微小的误差。大多数情况下这没问题但如果你的模型对数值极其敏感比如某些科学计算场景就需要谨慎评估。2.4 知识蒸馏用大模型教小模型知识蒸馏和前面几种优化手段不太一样它不是对同一个模型做压缩而是训练一个更小的学生模型去模仿大模型的行为。Model-Optimizer 工具链里通常会提供蒸馏的接口让你可以方便地定义损失函数和训练流程。蒸馏的核心在于软标签。大模型的输出经过 softmax 之后会给出每个类别的概率分布这个分布包含了比硬标签更丰富的信息。比如一张猫的图片大模型可能给出猫 0.9、狗 0.08、狐狸 0.02这个 0.08 和 0.02 就告诉学生模型狗和狐狸跟猫有一定的相似性。学生模型通过拟合这个分布能学到更好的决策边界。蒸馏的难点在于温度参数的调节和损失权重的平衡。温度太高软标签会变得过于平滑失去区分度温度太低又退化成硬标签。我一般会从 T4 开始试然后根据学生模型的收敛情况调整。损失函数通常是蒸馏损失和真实标签损失的加权和权重比在 0.5 到 0.9 之间比较常见。3. 从零搭建一条模型优化流水线3.1 环境准备与工具链选型动手之前先把环境理清楚。Model-Optimizer 不是一个单一的库而是一类工具的统称具体用哪个取决于你的目标推理引擎。如果你的部署目标是 TensorRT那优化流程会围绕 TensorRT 的量化工具链展开如果是端侧 CPU 推理ONNX Runtime 的优化器可能更合适如果是移动端 NPU那就要看芯片厂商提供的专用工具了。我一般会建议按这个顺序选型先确定推理硬件再确定推理引擎最后确定优化工具。反过来做很容易出现“优化完了发现引擎不支持”的尴尬局面。比如你花了两天做 INT8 量化结果目标引擎只支持 FP16那就白干了。依赖安装方面Python 环境建议用 3.8 到 3.10太新的版本有时候会遇到 wheel 包不兼容的问题。CUDA 版本要和推理引擎的要求对齐比如 TensorRT 8.x 通常需要 CUDA 11.x。这些版本匹配的细节看起来琐碎但实际项目中因为版本不对齐浪费的时间比写代码的时间还多。3.2 基线测量优化之前先知道起点在哪这一步很多人会跳过但我强烈建议不要省。优化之前先跑一遍原始模型记录下推理延迟、吞吐量、内存占用、精度指标。这些数据是你后续判断优化效果的唯一依据。没有基线你根本不知道优化有没有用更不知道收益有多大。测量的时候要注意几点第一warmup 一定要做够GPU 上通常需要跑几十次才能进入稳定状态第二batch size 要覆盖实际部署场景离线批处理和在线单条推理的优化策略完全不同第三精度指标要在完整的验证集上测不能只看几个样本。我习惯用一个小脚本把基线数据存成 JSON后面每做一步优化就追加一条记录。这样最后能清楚地看到每一步的收益和代价方便做取舍。import time import json import torch def measure_latency(model, input_tensor, warmup50, runs200): model.eval() with torch.no_grad(): for _ in range(warmup): model(input_tensor) if torch.cuda.is_available(): torch.cuda.synchronize() start time.perf_counter() for _ in range(runs): model(input_tensor) if torch.cuda.is_available(): torch.cuda.synchronize() end time.perf_counter() return (end - start) / runs * 1000 # ms这段代码看起来简单但 warmup 和 synchronize 这两个细节决定了数据的可信度。少了任何一个测出来的延迟都可能偏差百分之几十。3.3 量化实操从动态到静态的渐进路线量化实操我一般分三步走。第一步用动态量化快速验证可行性。以 PyTorch 为例几行代码就能搞定import torch.quantization model_fp32 MyModel() model_fp32.eval() model_int8 torch.quantization.quantize_dynamic( model_fp32, {torch.nn.Linear}, dtypetorch.qint8 )动态量化主要针对 Linear 层对 LSTM 和 Transformer 类模型效果比较明显。跑一遍精度测试如果掉点在可接受范围内就可以继续往下走。第二步静态量化。这一步需要插入观察器用校准数据跑一遍然后转换模型model_fp32.qconfig torch.quantization.get_default_qconfig(fbgemm) model_fp32_prepared torch.quantization.prepare(model_fp32) for data in calibration_loader: model_fp32_prepared(data) model_int8 torch.quantization.convert(model_fp32_prepared)校准数据的数量我一般控制在 100 到 500 条之间。太少统计不充分太多浪费时间且收益递减。校准完之后一定要在验证集上完整测一遍精度如果掉点超过 1%就要考虑调整量化配置比如把某些敏感层排除在量化范围之外。第三步量化感知训练。如果静态量化的精度还是达不到要求那就只能在训练阶段就模拟量化误差让模型提前适应。这一步成本最高但效果也最好通常能把精度损失压到 0.5% 以内。3.4 剪枝实操结构化剪枝的完整流程剪枝的实操比量化稍微复杂一点因为涉及到通道重要性的评估和模型结构的修改。我一般用 Torch-Pruning 这类库来做它提供了比较完善的依赖图分析能自动处理通道之间的关联。流程大致是这样的先加载训练好的模型定义剪枝策略比如对每个卷积层剪掉 30% 的通道。然后执行剪枝库会自动修改模型结构把被剪掉的通道对应的权重和 BN 参数都删掉。剪完之后模型会变得“残缺”精度会掉这时候需要微调。微调的学习率要比原始训练小一个数量级通常用 1e-4 到 1e-5。epoch 数不用太多5 到 10 个就够了因为剪枝后的模型只需要微调来恢复精度不需要重新学习特征。微调数据用原始训练集的一个子集就行我一般用 10% 到 20% 的数据量。提示剪枝之后一定要检查模型的输出维度是否和下游任务匹配。我遇到过剪枝把分类头的输入通道剪掉了结果推理时直接报维度错误。3.5 图优化与最终导出图优化通常是在导出阶段完成的。以 ONNX 为例导出之后可以用 ONNX Runtime 的优化器做一轮图优化from onnxruntime.transformers import optimizer optimized_model optimizer.optimize_model( model.onnx, model_typebert, num_heads12, hidden_size768 ) optimized_model.save_model_to_file(model_optimized.onnx)这一步会自动做算子融合、常量折叠、冗余节点消除等操作。对于 Transformer 模型还能做 attention 的专项优化。导出之后记得用 ONNX Runtime 跑一遍推理对比优化前后的延迟和精度。整个流水线走下来一个典型的 BERT 模型在 GPU 上能拿到 2 到 3 倍的加速在 CPU 上能拿到 3 到 4 倍。具体数字取决于模型结构、硬件平台和优化力度。4. 实操中那些文档不会告诉你的坑4.1 精度掉点的排查思路精度掉点是优化过程中最常见的问题但排查起来往往没有头绪。我一般按这个顺序定位先确认掉点发生在哪一步是量化、剪枝还是图优化。如果是量化先看是权重还是激活的问题可以把激活量化关掉只量化权重看精度是否恢复。如果是剪枝先看剪枝比例是否过大逐步降低比例找到临界点。还有一个容易被忽略的点是数据预处理的一致性。优化后的模型如果部署在 C 环境里预处理逻辑和 Python 训练时不一致精度也会掉。我遇到过归一化参数写错导致精度暴跌的情况排查了半天才发现是 mean 和 std 的顺序反了。4.2 推理引擎不支持的算子怎么办优化后的模型经常会遇到算子不支持的问题尤其是自定义算子或者比较新的算子。这时候有几个选择一是回退到优化前的版本把不支持的算子保留在高精度二是用引擎提供的插件机制自己实现三是改写模型结构用支持的算子组合替代。我一般优先选第一种因为成本最低。如果性能收益足够大再考虑第二种。第三种风险最高因为改写后的数值行为可能和原来不一致需要仔细验证。4.3 内存和显存的权衡优化不只是为了快有时候是为了省内存。量化能直接把模型大小砍半剪枝能减少参数量但这两者都会影响精度。实际项目中我一般会先明确内存预算再倒推需要多大的压缩比例然后在这个约束下选择精度损失最小的方案。比如一个模型原始大小 500MB目标平台只有 256MB 可用内存那至少需要 2 倍压缩。这时候 INT8 量化是首选因为它的压缩比刚好是 2 倍而且精度损失通常可控。如果量化后还是超再叠加剪枝。4.4 常见问题速查表问题现象可能原因排查方向解决思路量化后精度暴跌激活值动态范围过大检查各层激活分布改用逐通道量化或混合精度剪枝后模型报维度错误通道依赖关系未处理检查残差连接和 concat 层使用支持依赖分析的剪枝库推理速度没有提升优化未生效或硬件不支持对比优化前后计算图确认引擎是否启用低精度加速导出 ONNX 失败算子不支持或版本不匹配查看导出日志升级 opset 版本或替换算子微调后精度不恢复学习率过大或数据不足检查 loss 曲线降低学习率并增加微调数据这张表是我自己踩坑之后整理的基本上覆盖了八成以上的常见问题。实际遇到的时候先对照表格定位方向再深入排查能省不少时间。5. 优化效果的评估与持续迭代优化做完不是终点而是一个新的起点。模型上线之后输入分布会随着时间变化原本校准好的量化参数可能逐渐失效。我一般会建议建立一个监控机制定期采样线上推理的输入数据重新评估精度和延迟。如果发现精度下降超过阈值就需要重新校准或者重新优化。另一个容易被忽略的点是不同 batch size 下的优化效果差异。量化在小 batch 下的加速比通常不如大 batch因为小 batch 时计算量小内存带宽和 kernel launch 开销占比更高。如果你的服务同时支持单条和批量推理最好分别测一下优化效果必要时针对不同场景用不同的优化配置。还有一点是关于硬件迭代的。新一代硬件往往对低精度计算有更好的支持比如某些 GPU 对 INT8 的吞吐量是 FP16 的两倍。如果你的优化方案是针对旧硬件设计的换到新硬件上可能不是最优的。我一般会在硬件升级时重新跑一遍优化流水线看看有没有新的收益空间。最后分享一个我自己的习惯每次优化都保留完整的配置文件和脚本并且记录下当时的模型版本、数据版本、硬件环境和优化参数。这样过几个月回头看还能复现出同样的结果。模型优化这件事可复现性比什么都重要因为影响精度的因素太多了少记一个参数可能就要多花一天去排查。 Model-Optimizer 模型优化实战：量化、剪枝与图优化全流程
1. 模型优化器到底在优化什么第一次看到 Model-Optimizer 这个词很多人会下意识觉得它又是一个“调参工具”或者“训练加速库”。我刚开始接触的时候也这么想直到在一个实际项目里被推理延迟卡住脖子才真正理解它要解决的问题域有多宽。简单说Model-Optimizer 是一类面向模型全生命周期的优化工具集合它关注的不是模型结构本身的设计而是模型在训练完成之后、部署上线之前如何通过量化、剪枝、图优化、算子融合、内存复用等手段让同一个模型在同样的硬件上跑得更快、占得更少、耗电更低。这件事为什么值得单独拿出来讲因为绝大多数做算法的人习惯把精力花在“把精度刷上去”但真正到了工程落地阶段精度只差零点几个百分点推理速度却可能差三到五倍。用户不会关心你的模型结构多优雅他们只关心点一下按钮之后多久出结果。Model-Optimizer 就是在这个 gap 里做文章的工具链。它适合谁看如果你是把模型从 notebook 推向生产环境的算法工程师、负责推理服务性能的后端开发、或者在做端侧部署的嵌入式方向从业者那这套东西你绕不开。哪怕你只是想把本地跑的一个 demo 模型压缩到能塞进手机里理解 Model-Optimizer 的工作逻辑也能帮你少走很多弯路。我自己的经验是模型优化这件事最怕的不是技术难而是“不知道从哪里下手”。量化、剪枝、蒸馏、图优化、算子替换每个方向都有一堆论文和工具但真正落地的时候你需要的是一个有先后顺序、有取舍逻辑的流程。Model-Optimizer 这类工具的价值就在于它把这些零散的手段串成了一条可操作的流水线让你不用从零开始拼装。2. 核心优化手段的选型逻辑与适用边界2.1 量化最直接的收益来源也是最容易踩坑的地方量化是 Model-Optimizer 里最常被提到的功能没有之一。它的核心思路是把模型权重和激活值从高精度浮点数比如 FP32转换成低精度表示比如 INT8、FP16甚至 INT4。这样做的好处非常直接内存占用直接砍半甚至更多推理时内存带宽压力大幅降低而在支持低精度计算的硬件上吞吐量能提升两到四倍。但量化不是没有代价的。我见过太多人兴冲冲地把模型转成 INT8结果精度掉得亲妈都不认识。问题出在哪儿主要是激活值的动态范围。权重通常分布比较集中量化起来相对温和但激活值在不同输入下波动很大尤其是 Transformer 类模型里的 attention 输出某些通道的数值可能比其他通道大几十倍。如果你用统一的 scale 去量化所有通道小数值通道的信息就被直接抹掉了。所以实际做量化的时候我一般会按这个顺序推进先做动态量化只量化权重激活值在推理时动态计算 scale这个方案几乎不需要校准数据精度损失通常在一个点以内适合快速验证。如果动态量化的加速效果不够再上静态量化这时候就需要准备一批校准数据让工具在推理过程中统计激活值的分布计算出更合理的量化参数。校准数据不用多几百条就够但一定要有代表性不能全用同一个类别的样本。注意静态量化的校准集如果和实际推理分布偏差太大精度损失可能比不做量化还严重。我一般会从验证集里分层抽样确保每个类别都有覆盖。还有一个容易被忽略的点是逐通道量化和逐张量量化的区别。逐通道量化给每个输出通道单独算 scale精度明显更好但需要硬件支持。你在选工具的时候一定要先确认目标推理引擎是否支持逐通道量化否则转了也用不了。2.2 剪枝不是所有零都值得保留剪枝的逻辑听起来很直觉把模型里不重要的权重置零减少计算量。但实际操作中剪枝的坑比量化还多。原因在于剪枝之后如果只是把权重置零计算量并不会减少因为硬件还是得老老实实做乘法。真正要拿到加速收益必须做到结构化剪枝也就是直接删掉整个通道、整个注意力头或者整个层。非结构化剪枝虽然能压掉很多参数但产生的稀疏矩阵在通用硬件上跑不出加速除非你有专门的稀疏计算库。所以我在做剪枝的时候基本只考虑结构化方案。具体做法是先对每个通道计算一个重要性分数常用的指标有权重 L1/L2 范数、BN 层的缩放因子、或者基于梯度的敏感度。然后按比例剪掉分数最低的通道再对剪枝后的模型做微调恢复精度。这里有个经验值可以参考对于卷积网络剪掉 20% 到 30% 的通道精度通常只掉零点几个百分点微调几个 epoch 就能回来。但超过 50% 之后精度下降会变得非常陡峭而且微调也很难救回来。Transformer 类模型对剪枝更敏感尤其是注意力头剪太多会直接破坏模型的表达能力。2.3 图优化与算子融合不改变数值的加速图优化是 Model-Optimizer 里最“安全”的一类优化因为它不改变模型的数值计算结果只是重新组织计算图的结构。最常见的操作包括把 Conv BN ReLU 融合成一个算子消除冗余的 transpose 和 reshape常量折叠死代码消除等等。这些优化看起来不起眼但累积起来的效果很可观。我实测过一个典型的 CNN 模型经过图优化之后推理延迟降低了 15% 到 20%而且精度完全不变。算子融合之所以有效是因为它减少了 kernel launch 的次数和中间张量的内存读写。在 GPU 上kernel launch 的开销有时候比计算本身还大融合之后一个 kernel 干完三个 kernel 的活收益自然就出来了。不过图优化也有边界。有些融合操作会改变数值精度比如把 FP32 的 BN 融合进 FP16 的 Conv可能会引入微小的误差。大多数情况下这没问题但如果你的模型对数值极其敏感比如某些科学计算场景就需要谨慎评估。2.4 知识蒸馏用大模型教小模型知识蒸馏和前面几种优化手段不太一样它不是对同一个模型做压缩而是训练一个更小的学生模型去模仿大模型的行为。Model-Optimizer 工具链里通常会提供蒸馏的接口让你可以方便地定义损失函数和训练流程。蒸馏的核心在于软标签。大模型的输出经过 softmax 之后会给出每个类别的概率分布这个分布包含了比硬标签更丰富的信息。比如一张猫的图片大模型可能给出猫 0.9、狗 0.08、狐狸 0.02这个 0.08 和 0.02 就告诉学生模型狗和狐狸跟猫有一定的相似性。学生模型通过拟合这个分布能学到更好的决策边界。蒸馏的难点在于温度参数的调节和损失权重的平衡。温度太高软标签会变得过于平滑失去区分度温度太低又退化成硬标签。我一般会从 T4 开始试然后根据学生模型的收敛情况调整。损失函数通常是蒸馏损失和真实标签损失的加权和权重比在 0.5 到 0.9 之间比较常见。3. 从零搭建一条模型优化流水线3.1 环境准备与工具链选型动手之前先把环境理清楚。Model-Optimizer 不是一个单一的库而是一类工具的统称具体用哪个取决于你的目标推理引擎。如果你的部署目标是 TensorRT那优化流程会围绕 TensorRT 的量化工具链展开如果是端侧 CPU 推理ONNX Runtime 的优化器可能更合适如果是移动端 NPU那就要看芯片厂商提供的专用工具了。我一般会建议按这个顺序选型先确定推理硬件再确定推理引擎最后确定优化工具。反过来做很容易出现“优化完了发现引擎不支持”的尴尬局面。比如你花了两天做 INT8 量化结果目标引擎只支持 FP16那就白干了。依赖安装方面Python 环境建议用 3.8 到 3.10太新的版本有时候会遇到 wheel 包不兼容的问题。CUDA 版本要和推理引擎的要求对齐比如 TensorRT 8.x 通常需要 CUDA 11.x。这些版本匹配的细节看起来琐碎但实际项目中因为版本不对齐浪费的时间比写代码的时间还多。3.2 基线测量优化之前先知道起点在哪这一步很多人会跳过但我强烈建议不要省。优化之前先跑一遍原始模型记录下推理延迟、吞吐量、内存占用、精度指标。这些数据是你后续判断优化效果的唯一依据。没有基线你根本不知道优化有没有用更不知道收益有多大。测量的时候要注意几点第一warmup 一定要做够GPU 上通常需要跑几十次才能进入稳定状态第二batch size 要覆盖实际部署场景离线批处理和在线单条推理的优化策略完全不同第三精度指标要在完整的验证集上测不能只看几个样本。我习惯用一个小脚本把基线数据存成 JSON后面每做一步优化就追加一条记录。这样最后能清楚地看到每一步的收益和代价方便做取舍。import time import json import torch def measure_latency(model, input_tensor, warmup50, runs200): model.eval() with torch.no_grad(): for _ in range(warmup): model(input_tensor) if torch.cuda.is_available(): torch.cuda.synchronize() start time.perf_counter() for _ in range(runs): model(input_tensor) if torch.cuda.is_available(): torch.cuda.synchronize() end time.perf_counter() return (end - start) / runs * 1000 # ms这段代码看起来简单但 warmup 和 synchronize 这两个细节决定了数据的可信度。少了任何一个测出来的延迟都可能偏差百分之几十。3.3 量化实操从动态到静态的渐进路线量化实操我一般分三步走。第一步用动态量化快速验证可行性。以 PyTorch 为例几行代码就能搞定import torch.quantization model_fp32 MyModel() model_fp32.eval() model_int8 torch.quantization.quantize_dynamic( model_fp32, {torch.nn.Linear}, dtypetorch.qint8 )动态量化主要针对 Linear 层对 LSTM 和 Transformer 类模型效果比较明显。跑一遍精度测试如果掉点在可接受范围内就可以继续往下走。第二步静态量化。这一步需要插入观察器用校准数据跑一遍然后转换模型model_fp32.qconfig torch.quantization.get_default_qconfig(fbgemm) model_fp32_prepared torch.quantization.prepare(model_fp32) for data in calibration_loader: model_fp32_prepared(data) model_int8 torch.quantization.convert(model_fp32_prepared)校准数据的数量我一般控制在 100 到 500 条之间。太少统计不充分太多浪费时间且收益递减。校准完之后一定要在验证集上完整测一遍精度如果掉点超过 1%就要考虑调整量化配置比如把某些敏感层排除在量化范围之外。第三步量化感知训练。如果静态量化的精度还是达不到要求那就只能在训练阶段就模拟量化误差让模型提前适应。这一步成本最高但效果也最好通常能把精度损失压到 0.5% 以内。3.4 剪枝实操结构化剪枝的完整流程剪枝的实操比量化稍微复杂一点因为涉及到通道重要性的评估和模型结构的修改。我一般用 Torch-Pruning 这类库来做它提供了比较完善的依赖图分析能自动处理通道之间的关联。流程大致是这样的先加载训练好的模型定义剪枝策略比如对每个卷积层剪掉 30% 的通道。然后执行剪枝库会自动修改模型结构把被剪掉的通道对应的权重和 BN 参数都删掉。剪完之后模型会变得“残缺”精度会掉这时候需要微调。微调的学习率要比原始训练小一个数量级通常用 1e-4 到 1e-5。epoch 数不用太多5 到 10 个就够了因为剪枝后的模型只需要微调来恢复精度不需要重新学习特征。微调数据用原始训练集的一个子集就行我一般用 10% 到 20% 的数据量。提示剪枝之后一定要检查模型的输出维度是否和下游任务匹配。我遇到过剪枝把分类头的输入通道剪掉了结果推理时直接报维度错误。3.5 图优化与最终导出图优化通常是在导出阶段完成的。以 ONNX 为例导出之后可以用 ONNX Runtime 的优化器做一轮图优化from onnxruntime.transformers import optimizer optimized_model optimizer.optimize_model( model.onnx, model_typebert, num_heads12, hidden_size768 ) optimized_model.save_model_to_file(model_optimized.onnx)这一步会自动做算子融合、常量折叠、冗余节点消除等操作。对于 Transformer 模型还能做 attention 的专项优化。导出之后记得用 ONNX Runtime 跑一遍推理对比优化前后的延迟和精度。整个流水线走下来一个典型的 BERT 模型在 GPU 上能拿到 2 到 3 倍的加速在 CPU 上能拿到 3 到 4 倍。具体数字取决于模型结构、硬件平台和优化力度。4. 实操中那些文档不会告诉你的坑4.1 精度掉点的排查思路精度掉点是优化过程中最常见的问题但排查起来往往没有头绪。我一般按这个顺序定位先确认掉点发生在哪一步是量化、剪枝还是图优化。如果是量化先看是权重还是激活的问题可以把激活量化关掉只量化权重看精度是否恢复。如果是剪枝先看剪枝比例是否过大逐步降低比例找到临界点。还有一个容易被忽略的点是数据预处理的一致性。优化后的模型如果部署在 C 环境里预处理逻辑和 Python 训练时不一致精度也会掉。我遇到过归一化参数写错导致精度暴跌的情况排查了半天才发现是 mean 和 std 的顺序反了。4.2 推理引擎不支持的算子怎么办优化后的模型经常会遇到算子不支持的问题尤其是自定义算子或者比较新的算子。这时候有几个选择一是回退到优化前的版本把不支持的算子保留在高精度二是用引擎提供的插件机制自己实现三是改写模型结构用支持的算子组合替代。我一般优先选第一种因为成本最低。如果性能收益足够大再考虑第二种。第三种风险最高因为改写后的数值行为可能和原来不一致需要仔细验证。4.3 内存和显存的权衡优化不只是为了快有时候是为了省内存。量化能直接把模型大小砍半剪枝能减少参数量但这两者都会影响精度。实际项目中我一般会先明确内存预算再倒推需要多大的压缩比例然后在这个约束下选择精度损失最小的方案。比如一个模型原始大小 500MB目标平台只有 256MB 可用内存那至少需要 2 倍压缩。这时候 INT8 量化是首选因为它的压缩比刚好是 2 倍而且精度损失通常可控。如果量化后还是超再叠加剪枝。4.4 常见问题速查表问题现象可能原因排查方向解决思路量化后精度暴跌激活值动态范围过大检查各层激活分布改用逐通道量化或混合精度剪枝后模型报维度错误通道依赖关系未处理检查残差连接和 concat 层使用支持依赖分析的剪枝库推理速度没有提升优化未生效或硬件不支持对比优化前后计算图确认引擎是否启用低精度加速导出 ONNX 失败算子不支持或版本不匹配查看导出日志升级 opset 版本或替换算子微调后精度不恢复学习率过大或数据不足检查 loss 曲线降低学习率并增加微调数据这张表是我自己踩坑之后整理的基本上覆盖了八成以上的常见问题。实际遇到的时候先对照表格定位方向再深入排查能省不少时间。5. 优化效果的评估与持续迭代优化做完不是终点而是一个新的起点。模型上线之后输入分布会随着时间变化原本校准好的量化参数可能逐渐失效。我一般会建议建立一个监控机制定期采样线上推理的输入数据重新评估精度和延迟。如果发现精度下降超过阈值就需要重新校准或者重新优化。另一个容易被忽略的点是不同 batch size 下的优化效果差异。量化在小 batch 下的加速比通常不如大 batch因为小 batch 时计算量小内存带宽和 kernel launch 开销占比更高。如果你的服务同时支持单条和批量推理最好分别测一下优化效果必要时针对不同场景用不同的优化配置。还有一点是关于硬件迭代的。新一代硬件往往对低精度计算有更好的支持比如某些 GPU 对 INT8 的吞吐量是 FP16 的两倍。如果你的优化方案是针对旧硬件设计的换到新硬件上可能不是最优的。我一般会在硬件升级时重新跑一遍优化流水线看看有没有新的收益空间。最后分享一个我自己的习惯每次优化都保留完整的配置文件和脚本并且记录下当时的模型版本、数据版本、硬件环境和优化参数。这样过几个月回头看还能复现出同样的结果。模型优化这件事可复现性比什么都重要因为影响精度的因素太多了少记一个参数可能就要多花一天去排查。