1. 模型优化器到底在优化什么第一次看到 Model-Optimizer 这个词很多人会下意识以为它又是一个新的训练框架或者某个大厂开源的“一键加速”工具。实际上模型优化器要解决的问题比训练框架更底层也更琐碎——它处理的是模型从“能跑”到“跑得好、跑得省、跑得稳”之间的那段路。我接触模型优化这件事最早是从一个很具体的场景开始的一个已经训练完的图像分类模型在服务器上推理一张图要 80 毫秒业务方要求压到 20 毫秒以内同时精度不能掉超过 0.5%。当时我第一反应是换更小的模型重新训练但重新训练意味着重新标注、重新调参、重新验证周期至少两周。后来我换了个思路用模型优化器对现有模型做量化、算子融合和内存布局调整三天就把延迟压到了 18 毫秒精度只掉了 0.3%。这件事让我意识到模型优化器不是训练阶段的附属品而是一个独立的、值得单独拿出来研究的工程环节。所谓模型优化器你可以把它理解成模型和硬件之间的“翻译官”加“调度员”。模型是用 Python 和数学公式描述的硬件只认指令、内存和缓存。优化器要做的事情就是把前者翻译成后者能高效执行的形式同时在不改变模型语义的前提下尽可能减少计算量、内存访问量和数据搬运次数。它涵盖的范围很广包括但不限于量化、剪枝、蒸馏、算子融合、图优化、内存复用、并行策略选择、编译优化等。这篇文章适合谁看如果你是一个算法工程师模型已经训好了但部署效果不理想那这篇内容能帮你找到优化方向如果你是一个工程部署人员面对一堆模型文件不知道从哪下手那这篇内容能给你一套可操作的流程如果你是一个刚入门的学生想了解模型从实验室到生产环境之间发生了什么那这篇内容也能给你一个相对完整的图景。我不打算讲太多数学推导而是把重点放在“为什么这么做”和“具体怎么做”上尽量让不同基础的读者都能拿走能用的东西。2. 模型优化器的核心思路与方案选型2.1 为什么不能只靠“换小模型”解决问题很多人一提到模型优化第一反应就是换一个更小的模型比如把 ResNet-50 换成 MobileNet把 BERT-base 换成 DistilBERT。这个思路本身没错但它有两个前提第一你有时间和资源重新训练第二小模型在你的任务上精度损失可以接受。现实情况往往不是这样。我遇到过很多场景模型是业务方指定的精度指标是合同里写死的训练数据是敏感数据不能随便动这时候你只能在不改变模型结构的前提下做优化。模型优化器的价值就在这里。它不改变模型的数学定义而是改变模型的执行方式。举个例子一个卷积层在数学上就是乘加运算但在硬件上你可以用不同的指令集、不同的数据排布、不同的并行方式来执行它。优化器要做的就是找到在当前硬件上最快的那种执行方式。这就像同样是从 A 点到 B 点你可以走路、骑车、开车、坐地铁路径没变但耗时完全不同。2.2 量化、剪枝、蒸馏、编译四条主流路线的取舍模型优化器涉及的技术路线很多但落到实操层面最常用的无非四条量化、剪枝、蒸馏和编译优化。这四条路线不是互斥的很多时候需要组合使用但它们的适用场景和代价差别很大。量化是把模型参数和激活值从高精度浮点数比如 FP32转换成低精度表示比如 INT8、FP16 甚至 INT4。它的核心优势是直接减少内存占用和计算量因为低精度运算在大多数硬件上都有专门的加速指令。量化的难点在于精度控制尤其是激活值的动态范围估计如果校准集选得不好精度掉几个点是很常见的事。剪枝是去掉模型中“不重要”的权重或神经元。它的逻辑是神经网络通常有大量冗余参数去掉一部分不会显著影响输出。剪枝分为结构化剪枝和非结构化剪枝前者去掉整个通道或层后者只去掉单个权重。非结构化剪枝理论上压缩率更高但实际部署时往往需要专门的稀疏计算库支持否则加速效果有限。蒸馏是用一个大模型教师去指导一个小模型学生训练。它的优势是学生模型结构可以完全重新设计灵活性高但缺点是需要重新训练周期长而且教师模型的质量直接决定学生模型的上限。编译优化是把模型的计算图转换成硬件友好的中间表示然后由编译器自动做算子融合、内存规划、指令调度等优化。这条路线对开发者最友好因为大部分工作由编译器完成但它的效果高度依赖编译器的成熟度和硬件支持程度。下面这张表是我在实际项目中总结的选型参考你可以根据自己的场景对号入座优化路线典型压缩比精度损失风险是否需要重训练部署复杂度适用场景量化2-4 倍中通常不需要低推理延迟敏感、硬件支持低精度剪枝2-10 倍中高通常需要微调中模型体积敏感、有稀疏计算支持蒸馏2-10 倍低需要低可重新训练、追求小模型高精度编译优化1.5-3 倍极低不需要低通用加速、不想动模型结构2.3 一个容易被忽略的原则先定位瓶颈再选工具我见过太多人一上来就开始量化结果发现模型瓶颈根本不在计算量上而在内存带宽或者数据预处理上。量化完了延迟没降多少精度倒是掉了一截。所以我的习惯是任何优化动作之前先做一轮 profiling搞清楚时间到底花在哪里。Profiling 的工具选择取决于你的部署环境。如果是 GPU 环境Nsight Systems 和 Nsight Compute 是首选如果是 CPU 环境perf 和 VTune 更合适如果是移动端Android 的 systrace 或者 iOS 的 Instruments 都能用。关键是要拿到算子级别的时间分布知道哪个层、哪个算子、哪次内存拷贝占了大头。我自己的经验是一个模型推理延迟的构成通常是这样的计算占 40%-60%内存访问占 20%-40%框架调度和预处理占 10%-30%。如果你的模型计算占比很高那量化、剪枝、编译优化都有效如果内存访问占比高那算子融合和内存布局优化更关键如果框架调度占比高那可能需要换推理引擎或者做图级别的优化。方向选错了再努力也是白费。3. 量化实操从 FP32 到 INT8 的完整流程3.1 量化前的准备工作校准集怎么选量化最核心的环节是校准也就是用一批代表性数据去统计激活值的动态范围然后确定量化参数scale 和 zero point。校准集选得好不好直接决定量化后的精度。我见过有人随便拿几十张图做校准结果量化后精度掉了 5 个点换了一批校准数据后精度只掉 0.2%。校准集的选择有几个原则。第一数量要够通常 100-500 个样本比较合适太少统计不准确太多浪费时间。第二分布要匹配校准集的数据分布应该和实际推理时的数据分布一致。如果你做的是人脸识别校准集就应该是人脸图不能拿风景图凑数。第三要覆盖边界情况比如极端光照、遮挡、大角度旋转等这些样本能帮助量化参数更好地覆盖激活值的动态范围。实际操作中我通常从验证集里随机采样 200 个样本作为校准集然后额外加入 20-30 个已知的困难样本。校准完成后一定要在完整的验证集上跑一遍精度确认没有明显下降再进入下一步。3.2 训练后量化与量化感知训练的差异量化分为两大类训练后量化PTQ和量化感知训练QAT。PTQ 是在模型训练完成后直接做量化不需要重新训练速度快适合快速验证。QAT 是在训练过程中模拟量化误差让模型提前适应低精度计算精度通常更好但需要重新训练。我的建议是先用 PTQ 试一版如果精度满足要求就直接用不满足再考虑 QAT。PTQ 的流程通常包括加载模型、插入观测节点、跑校准集、计算量化参数、转换模型、验证精度。大部分推理框架都提供了 PTQ 的工具链比如 TensorRT 的 pytorch-quantization、ONNX Runtime 的 quantization 工具、TFLite 的 converter 等。QAT 的流程更复杂一些需要在训练脚本里插入伪量化节点让前向传播模拟量化误差反向传播仍然用浮点数更新权重。训练完成后再把伪量化节点替换成真正的量化算子。QAT 的训练周期通常是原始训练的 10%-20%学习率要调小否则容易震荡。下面是一个 PTQ 的典型代码流程以 ONNX Runtime 为例import onnx from onnxruntime.quantization import quantize_dynamic, QuantType # 加载原始 FP32 模型 model_fp32 model.onnx model_int8 model_quantized.onnx # 动态量化不需要校准集 quantize_dynamic( model_inputmodel_fp32, model_outputmodel_int8, weight_typeQuantType.QInt8 ) # 如果是静态量化需要提供校准数据 from onnxruntime.quantization import quantize_static, CalibrationDataReader class MyCalibrationReader(CalibrationDataReader): def __init__(self, calibration_data): self.data calibration_data self.index 0 def get_next(self): if self.index len(self.data): return None batch self.data[self.index] self.index 1 return {input: batch} reader MyCalibrationReader(calibration_data) quantize_static( model_inputmodel_fp32, model_outputmodel_int8, calibration_data_readerreader )注意动态量化只量化权重激活值仍然是浮点数适合 LSTM、Transformer 等模型静态量化同时量化权重和激活值加速效果更好但需要校准集。3.3 量化精度掉点了怎么办逐层分析与混合精度量化后精度下降是常态关键是怎么定位问题。我的做法是逐层对比量化前后的输出差异找出误差最大的层。大部分框架都支持逐层输出对比比如 PyTorch 的 hook 机制、ONNX Runtime 的 profiling 模式等。定位到问题层之后有几种处理方式。第一种是混合精度把敏感层保持 FP16 或 FP32其他层用 INT8。第二种是调整量化粒度从 per-tensor 改成 per-channel后者对权重的量化更精细。第三种是换校准算法比如从 MinMax 换成 Entropy 或 Percentile后者对异常值更鲁棒。我自己的经验是Transformer 类模型的注意力层对量化比较敏感卷积类模型的第一个和最后一个卷积层通常也比较敏感。这些层如果精度掉得多优先考虑保留高精度。4. 剪枝与蒸馏结构优化的两条路径4.1 结构化剪枝与非结构化剪枝的工程差异剪枝听起来很简单去掉不重要的权重就行了但实际工程中结构化剪枝和非结构化剪枝的差异非常大。非结构化剪枝去掉单个权重理论上压缩率可以很高但得到的稀疏矩阵在通用硬件上很难加速因为大多数硬件对稀疏计算的支持有限。结构化剪枝去掉整个通道或层得到的模型仍然是稠密的可以直接用现有推理引擎加速但压缩率相对较低。我通常建议如果你的部署环境有专门的稀疏计算库比如 NVIDIA 的 sparse tensor core可以考虑非结构化剪枝否则优先选结构化剪枝。结构化剪枝的流程一般是训练一个基准模型、计算每个通道的重要性分数、按分数排序、去掉低分通道、微调恢复精度。重要性分数的计算方式有很多种比如权重的 L1/L2 范数、BN 层的缩放因子、梯度信息等。下面是一个基于 BN 缩放因子的通道剪枝示例import torch import torch.nn as nn def compute_channel_importance(model): importance {} for name, module in model.named_modules(): if isinstance(module, nn.BatchNorm2d): # BN 的 weight 参数反映了该通道的重要性 importance[name] module.weight.data.abs().clone() return importance def prune_channels(model, importance, threshold): for name, module in model.named_modules(): if isinstance(module, nn.BatchNorm2d): mask importance[name] threshold # 根据 mask 裁剪对应的卷积层和 BN 层 # 具体实现略需要同步修改前后层 return model注意剪枝后一定要微调否则精度损失可能很大。微调的学习率通常设为原始训练的 1/10 到 1/100训练几个 epoch 就能恢复大部分精度。4.2 蒸馏的温度参数与损失函数设计蒸馏的核心思想是让学生模型模仿教师模型的输出分布而不仅仅是硬标签。这里的关键参数是温度temperature它控制软标签的平滑程度。温度越高软标签越平滑学生模型能学到的类别间关系越多温度越低软标签越接近硬标签蒸馏效果越接近普通训练。我通常把温度设在 3-10 之间具体取决于任务。分类任务通常用 4-6检测任务用 2-4。损失函数一般是软标签损失和硬标签损失的加权和权重比通常设为 0.7:0.3 或 0.5:0.5。蒸馏的另一个关键是教师模型的选择。教师模型不一定要比学生模型大很多但一定要在目标任务上表现足够好。如果教师模型本身精度就不高学生模型很难超过它。我见过有人用一个小模型去蒸馏另一个小模型结果学生模型精度还不如直接训练这就是教师模型选择不当的典型问题。5. 编译优化与推理引擎选型5.1 算子融合为什么能加速算子融合是编译优化中最常见也最有效的手段之一。它的逻辑很简单把多个连续的小算子合并成一个大的算子减少中间结果的写回和读取。比如 Conv BN ReLU 这三个算子如果不融合需要把 Conv 的输出写到内存再读出来做 BN再写回去做 ReLU。融合之后这三个操作在一个 kernel 里完成中间结果留在寄存器或共享内存里内存访问量大幅减少。我实测过一个 ResNet-50 模型ConvBNReLU 融合后推理延迟降低了约 15%。如果模型里这种连续算子很多融合带来的收益会更大。大部分推理引擎都支持自动算子融合比如 TensorRT、ONNX Runtime、TVM 等但融合的效果取决于引擎的成熟度和模型的图结构。5.2 TensorRT、ONNX Runtime、OpenVINO 的适用场景推理引擎的选型没有绝对的好坏关键看你的硬件和模型类型。下面这张表是我在实际项目中总结的对比推理引擎主要硬件优势劣势适用场景TensorRTNVIDIA GPU性能极致、量化支持好生态封闭、只支持 NVIDIAGPU 服务器推理ONNX RuntimeCPU/GPU/多平台跨平台、生态开放极致性能略逊多平台部署、快速验证OpenVINOIntel CPU/GPU/VPUIntel 硬件优化好非 Intel 硬件支持弱Intel 平台部署TFLite移动端/嵌入式体积小、功耗低算子支持有限移动端、IoT 设备TVM多硬件可定制、支持新硬件学习曲线陡研究、特殊硬件我的建议是如果你的部署环境是 NVIDIA GPU优先用 TensorRT如果是多平台或者快速验证用 ONNX Runtime如果是 Intel CPU 服务器用 OpenVINO如果是移动端用 TFLite。不要为了追求极致性能去用一个不熟悉的引擎调试成本可能远大于性能收益。5.3 内存布局与数据排布的影响内存布局对性能的影响经常被忽略但在某些模型上它比算子融合还重要。举个例子NCHW 和 NHWC 两种数据排布在不同硬件上的性能差异可能达到 2-3 倍。NVIDIA GPU 通常对 NHWC 更友好因为 Tensor Core 的矩阵运算要求通道维度连续而 Intel CPU 对 NCHW 的支持更好因为 SIMD 指令更适合这种布局。转换内存布局通常不需要改模型代码只需要在推理引擎的配置里指定即可。但要注意布局转换本身也有开销如果模型里频繁在两种布局之间切换反而会变慢。所以我的做法是整个模型统一用一种布局不要混用。6. 常见问题与排查技巧实录6.1 量化后精度暴跌的排查清单量化后精度暴跌是最常见的问题我整理了一个排查清单按优先级排序排查项可能原因解决方法校准集分布不匹配、数量太少重新采样 200-500 个代表性样本量化粒度per-tensor 太粗改成 per-channel校准算法MinMax 对异常值敏感换成 Entropy 或 Percentile敏感层某些层对量化敏感混合精度保留 FP16激活值范围动态范围过大检查是否有异常输入算子支持某些算子量化实现有 bug回退到 FP16 或 FP32我遇到过一次精度暴跌排查了半天发现是校准集里混入了几张全黑的图导致激活值范围估计严重偏小。换掉那几张图之后精度立刻恢复正常。所以校准集的质量比数量更重要一定要人工检查一遍。6.2 推理延迟不降反升的几种情况优化之后延迟反而变高这种情况也不少见。常见原因有几个第一量化后的模型虽然计算量小了但引入了额外的量化/反量化算子如果这些算子没有被融合开销可能超过收益。第二剪枝后的模型虽然参数少了但稀疏计算库的调度开销可能更大。第三编译优化时算子融合策略不当导致寄存器压力过大出现溢出。我的排查方法是先用 profiling 工具对比优化前后的算子级别时间分布找出变慢的算子然后针对性处理。如果是量化/反量化算子的问题尝试开启引擎的融合选项如果是稀疏计算的问题考虑换回稠密模型或者换一个稀疏库如果是寄存器溢出的问题调整融合策略或者降低并行度。6.3 跨平台部署的兼容性坑跨平台部署是另一个容易踩坑的地方。同一个模型在服务器上跑得好好的放到移动端就报错这种情况太常见了。主要原因有几个第一某些算子在移动端推理引擎里没有实现或者实现方式不同。第二移动端的浮点精度支持有限FP16 可能被降级成 FP32。第三移动端的内存和功耗限制导致某些优化策略不可用。我的经验是跨平台部署一定要尽早做兼容性测试不要等到最后才移植。测试的时候先用一个简单的模型跑通全流程确认算子支持、精度、性能都符合预期再换正式模型。另外尽量用推理引擎提供的标准算子避免自定义算子因为自定义算子在跨平台时往往需要重新实现。7. 我个人的优化流程与工具链推荐经过多个项目的积累我现在的模型优化流程基本固定下来了。第一步profiling搞清楚瓶颈在哪。第二步根据瓶颈选优化路线计算瓶颈优先量化内存瓶颈优先融合调度瓶颈优先换引擎。第三步小范围验证用一个小模型或者一个子图先试确认效果和精度。第四步全量优化逐步应用所有优化手段每步都验证精度。第五步跨平台测试确保目标硬件上都能跑通。工具链方面我常用的组合是PyTorch 做训练和导出ONNX 做中间表示ONNX Runtime 做快速验证TensorRT 做 GPU 部署TFLite 做移动端部署。量化用 ONNX Runtime 的 quantization 工具或者 TensorRT 的 pytorch-quantization剪枝用 torch.nn.utils.prune 或者自己写脚本蒸馏用 PyTorch 原生训练流程。最后分享一个小技巧优化过程中一定要保留每一步的中间模型和精度记录不要嫌麻烦。我吃过亏有一次优化到一半发现精度不对想回退到上一个版本结果中间模型没保存只能从头再来。从那以后我养成了每步都保存模型和记录精度的习惯虽然占点磁盘空间但省下的时间远不止那点空间。这个领域变化很快新的量化算法、新的编译技术、新的硬件支持层出不穷。我的建议是不要追求一次学到所有东西先把一条路线走通比如量化然后再逐步扩展。模型优化本质上是一个工程问题经验比理论更重要多动手、多踩坑、多总结比看十篇论文都管用。
模型优化器实战：量化、剪枝、蒸馏与编译优化全解析
1. 模型优化器到底在优化什么第一次看到 Model-Optimizer 这个词很多人会下意识以为它又是一个新的训练框架或者某个大厂开源的“一键加速”工具。实际上模型优化器要解决的问题比训练框架更底层也更琐碎——它处理的是模型从“能跑”到“跑得好、跑得省、跑得稳”之间的那段路。我接触模型优化这件事最早是从一个很具体的场景开始的一个已经训练完的图像分类模型在服务器上推理一张图要 80 毫秒业务方要求压到 20 毫秒以内同时精度不能掉超过 0.5%。当时我第一反应是换更小的模型重新训练但重新训练意味着重新标注、重新调参、重新验证周期至少两周。后来我换了个思路用模型优化器对现有模型做量化、算子融合和内存布局调整三天就把延迟压到了 18 毫秒精度只掉了 0.3%。这件事让我意识到模型优化器不是训练阶段的附属品而是一个独立的、值得单独拿出来研究的工程环节。所谓模型优化器你可以把它理解成模型和硬件之间的“翻译官”加“调度员”。模型是用 Python 和数学公式描述的硬件只认指令、内存和缓存。优化器要做的事情就是把前者翻译成后者能高效执行的形式同时在不改变模型语义的前提下尽可能减少计算量、内存访问量和数据搬运次数。它涵盖的范围很广包括但不限于量化、剪枝、蒸馏、算子融合、图优化、内存复用、并行策略选择、编译优化等。这篇文章适合谁看如果你是一个算法工程师模型已经训好了但部署效果不理想那这篇内容能帮你找到优化方向如果你是一个工程部署人员面对一堆模型文件不知道从哪下手那这篇内容能给你一套可操作的流程如果你是一个刚入门的学生想了解模型从实验室到生产环境之间发生了什么那这篇内容也能给你一个相对完整的图景。我不打算讲太多数学推导而是把重点放在“为什么这么做”和“具体怎么做”上尽量让不同基础的读者都能拿走能用的东西。2. 模型优化器的核心思路与方案选型2.1 为什么不能只靠“换小模型”解决问题很多人一提到模型优化第一反应就是换一个更小的模型比如把 ResNet-50 换成 MobileNet把 BERT-base 换成 DistilBERT。这个思路本身没错但它有两个前提第一你有时间和资源重新训练第二小模型在你的任务上精度损失可以接受。现实情况往往不是这样。我遇到过很多场景模型是业务方指定的精度指标是合同里写死的训练数据是敏感数据不能随便动这时候你只能在不改变模型结构的前提下做优化。模型优化器的价值就在这里。它不改变模型的数学定义而是改变模型的执行方式。举个例子一个卷积层在数学上就是乘加运算但在硬件上你可以用不同的指令集、不同的数据排布、不同的并行方式来执行它。优化器要做的就是找到在当前硬件上最快的那种执行方式。这就像同样是从 A 点到 B 点你可以走路、骑车、开车、坐地铁路径没变但耗时完全不同。2.2 量化、剪枝、蒸馏、编译四条主流路线的取舍模型优化器涉及的技术路线很多但落到实操层面最常用的无非四条量化、剪枝、蒸馏和编译优化。这四条路线不是互斥的很多时候需要组合使用但它们的适用场景和代价差别很大。量化是把模型参数和激活值从高精度浮点数比如 FP32转换成低精度表示比如 INT8、FP16 甚至 INT4。它的核心优势是直接减少内存占用和计算量因为低精度运算在大多数硬件上都有专门的加速指令。量化的难点在于精度控制尤其是激活值的动态范围估计如果校准集选得不好精度掉几个点是很常见的事。剪枝是去掉模型中“不重要”的权重或神经元。它的逻辑是神经网络通常有大量冗余参数去掉一部分不会显著影响输出。剪枝分为结构化剪枝和非结构化剪枝前者去掉整个通道或层后者只去掉单个权重。非结构化剪枝理论上压缩率更高但实际部署时往往需要专门的稀疏计算库支持否则加速效果有限。蒸馏是用一个大模型教师去指导一个小模型学生训练。它的优势是学生模型结构可以完全重新设计灵活性高但缺点是需要重新训练周期长而且教师模型的质量直接决定学生模型的上限。编译优化是把模型的计算图转换成硬件友好的中间表示然后由编译器自动做算子融合、内存规划、指令调度等优化。这条路线对开发者最友好因为大部分工作由编译器完成但它的效果高度依赖编译器的成熟度和硬件支持程度。下面这张表是我在实际项目中总结的选型参考你可以根据自己的场景对号入座优化路线典型压缩比精度损失风险是否需要重训练部署复杂度适用场景量化2-4 倍中通常不需要低推理延迟敏感、硬件支持低精度剪枝2-10 倍中高通常需要微调中模型体积敏感、有稀疏计算支持蒸馏2-10 倍低需要低可重新训练、追求小模型高精度编译优化1.5-3 倍极低不需要低通用加速、不想动模型结构2.3 一个容易被忽略的原则先定位瓶颈再选工具我见过太多人一上来就开始量化结果发现模型瓶颈根本不在计算量上而在内存带宽或者数据预处理上。量化完了延迟没降多少精度倒是掉了一截。所以我的习惯是任何优化动作之前先做一轮 profiling搞清楚时间到底花在哪里。Profiling 的工具选择取决于你的部署环境。如果是 GPU 环境Nsight Systems 和 Nsight Compute 是首选如果是 CPU 环境perf 和 VTune 更合适如果是移动端Android 的 systrace 或者 iOS 的 Instruments 都能用。关键是要拿到算子级别的时间分布知道哪个层、哪个算子、哪次内存拷贝占了大头。我自己的经验是一个模型推理延迟的构成通常是这样的计算占 40%-60%内存访问占 20%-40%框架调度和预处理占 10%-30%。如果你的模型计算占比很高那量化、剪枝、编译优化都有效如果内存访问占比高那算子融合和内存布局优化更关键如果框架调度占比高那可能需要换推理引擎或者做图级别的优化。方向选错了再努力也是白费。3. 量化实操从 FP32 到 INT8 的完整流程3.1 量化前的准备工作校准集怎么选量化最核心的环节是校准也就是用一批代表性数据去统计激活值的动态范围然后确定量化参数scale 和 zero point。校准集选得好不好直接决定量化后的精度。我见过有人随便拿几十张图做校准结果量化后精度掉了 5 个点换了一批校准数据后精度只掉 0.2%。校准集的选择有几个原则。第一数量要够通常 100-500 个样本比较合适太少统计不准确太多浪费时间。第二分布要匹配校准集的数据分布应该和实际推理时的数据分布一致。如果你做的是人脸识别校准集就应该是人脸图不能拿风景图凑数。第三要覆盖边界情况比如极端光照、遮挡、大角度旋转等这些样本能帮助量化参数更好地覆盖激活值的动态范围。实际操作中我通常从验证集里随机采样 200 个样本作为校准集然后额外加入 20-30 个已知的困难样本。校准完成后一定要在完整的验证集上跑一遍精度确认没有明显下降再进入下一步。3.2 训练后量化与量化感知训练的差异量化分为两大类训练后量化PTQ和量化感知训练QAT。PTQ 是在模型训练完成后直接做量化不需要重新训练速度快适合快速验证。QAT 是在训练过程中模拟量化误差让模型提前适应低精度计算精度通常更好但需要重新训练。我的建议是先用 PTQ 试一版如果精度满足要求就直接用不满足再考虑 QAT。PTQ 的流程通常包括加载模型、插入观测节点、跑校准集、计算量化参数、转换模型、验证精度。大部分推理框架都提供了 PTQ 的工具链比如 TensorRT 的 pytorch-quantization、ONNX Runtime 的 quantization 工具、TFLite 的 converter 等。QAT 的流程更复杂一些需要在训练脚本里插入伪量化节点让前向传播模拟量化误差反向传播仍然用浮点数更新权重。训练完成后再把伪量化节点替换成真正的量化算子。QAT 的训练周期通常是原始训练的 10%-20%学习率要调小否则容易震荡。下面是一个 PTQ 的典型代码流程以 ONNX Runtime 为例import onnx from onnxruntime.quantization import quantize_dynamic, QuantType # 加载原始 FP32 模型 model_fp32 model.onnx model_int8 model_quantized.onnx # 动态量化不需要校准集 quantize_dynamic( model_inputmodel_fp32, model_outputmodel_int8, weight_typeQuantType.QInt8 ) # 如果是静态量化需要提供校准数据 from onnxruntime.quantization import quantize_static, CalibrationDataReader class MyCalibrationReader(CalibrationDataReader): def __init__(self, calibration_data): self.data calibration_data self.index 0 def get_next(self): if self.index len(self.data): return None batch self.data[self.index] self.index 1 return {input: batch} reader MyCalibrationReader(calibration_data) quantize_static( model_inputmodel_fp32, model_outputmodel_int8, calibration_data_readerreader )注意动态量化只量化权重激活值仍然是浮点数适合 LSTM、Transformer 等模型静态量化同时量化权重和激活值加速效果更好但需要校准集。3.3 量化精度掉点了怎么办逐层分析与混合精度量化后精度下降是常态关键是怎么定位问题。我的做法是逐层对比量化前后的输出差异找出误差最大的层。大部分框架都支持逐层输出对比比如 PyTorch 的 hook 机制、ONNX Runtime 的 profiling 模式等。定位到问题层之后有几种处理方式。第一种是混合精度把敏感层保持 FP16 或 FP32其他层用 INT8。第二种是调整量化粒度从 per-tensor 改成 per-channel后者对权重的量化更精细。第三种是换校准算法比如从 MinMax 换成 Entropy 或 Percentile后者对异常值更鲁棒。我自己的经验是Transformer 类模型的注意力层对量化比较敏感卷积类模型的第一个和最后一个卷积层通常也比较敏感。这些层如果精度掉得多优先考虑保留高精度。4. 剪枝与蒸馏结构优化的两条路径4.1 结构化剪枝与非结构化剪枝的工程差异剪枝听起来很简单去掉不重要的权重就行了但实际工程中结构化剪枝和非结构化剪枝的差异非常大。非结构化剪枝去掉单个权重理论上压缩率可以很高但得到的稀疏矩阵在通用硬件上很难加速因为大多数硬件对稀疏计算的支持有限。结构化剪枝去掉整个通道或层得到的模型仍然是稠密的可以直接用现有推理引擎加速但压缩率相对较低。我通常建议如果你的部署环境有专门的稀疏计算库比如 NVIDIA 的 sparse tensor core可以考虑非结构化剪枝否则优先选结构化剪枝。结构化剪枝的流程一般是训练一个基准模型、计算每个通道的重要性分数、按分数排序、去掉低分通道、微调恢复精度。重要性分数的计算方式有很多种比如权重的 L1/L2 范数、BN 层的缩放因子、梯度信息等。下面是一个基于 BN 缩放因子的通道剪枝示例import torch import torch.nn as nn def compute_channel_importance(model): importance {} for name, module in model.named_modules(): if isinstance(module, nn.BatchNorm2d): # BN 的 weight 参数反映了该通道的重要性 importance[name] module.weight.data.abs().clone() return importance def prune_channels(model, importance, threshold): for name, module in model.named_modules(): if isinstance(module, nn.BatchNorm2d): mask importance[name] threshold # 根据 mask 裁剪对应的卷积层和 BN 层 # 具体实现略需要同步修改前后层 return model注意剪枝后一定要微调否则精度损失可能很大。微调的学习率通常设为原始训练的 1/10 到 1/100训练几个 epoch 就能恢复大部分精度。4.2 蒸馏的温度参数与损失函数设计蒸馏的核心思想是让学生模型模仿教师模型的输出分布而不仅仅是硬标签。这里的关键参数是温度temperature它控制软标签的平滑程度。温度越高软标签越平滑学生模型能学到的类别间关系越多温度越低软标签越接近硬标签蒸馏效果越接近普通训练。我通常把温度设在 3-10 之间具体取决于任务。分类任务通常用 4-6检测任务用 2-4。损失函数一般是软标签损失和硬标签损失的加权和权重比通常设为 0.7:0.3 或 0.5:0.5。蒸馏的另一个关键是教师模型的选择。教师模型不一定要比学生模型大很多但一定要在目标任务上表现足够好。如果教师模型本身精度就不高学生模型很难超过它。我见过有人用一个小模型去蒸馏另一个小模型结果学生模型精度还不如直接训练这就是教师模型选择不当的典型问题。5. 编译优化与推理引擎选型5.1 算子融合为什么能加速算子融合是编译优化中最常见也最有效的手段之一。它的逻辑很简单把多个连续的小算子合并成一个大的算子减少中间结果的写回和读取。比如 Conv BN ReLU 这三个算子如果不融合需要把 Conv 的输出写到内存再读出来做 BN再写回去做 ReLU。融合之后这三个操作在一个 kernel 里完成中间结果留在寄存器或共享内存里内存访问量大幅减少。我实测过一个 ResNet-50 模型ConvBNReLU 融合后推理延迟降低了约 15%。如果模型里这种连续算子很多融合带来的收益会更大。大部分推理引擎都支持自动算子融合比如 TensorRT、ONNX Runtime、TVM 等但融合的效果取决于引擎的成熟度和模型的图结构。5.2 TensorRT、ONNX Runtime、OpenVINO 的适用场景推理引擎的选型没有绝对的好坏关键看你的硬件和模型类型。下面这张表是我在实际项目中总结的对比推理引擎主要硬件优势劣势适用场景TensorRTNVIDIA GPU性能极致、量化支持好生态封闭、只支持 NVIDIAGPU 服务器推理ONNX RuntimeCPU/GPU/多平台跨平台、生态开放极致性能略逊多平台部署、快速验证OpenVINOIntel CPU/GPU/VPUIntel 硬件优化好非 Intel 硬件支持弱Intel 平台部署TFLite移动端/嵌入式体积小、功耗低算子支持有限移动端、IoT 设备TVM多硬件可定制、支持新硬件学习曲线陡研究、特殊硬件我的建议是如果你的部署环境是 NVIDIA GPU优先用 TensorRT如果是多平台或者快速验证用 ONNX Runtime如果是 Intel CPU 服务器用 OpenVINO如果是移动端用 TFLite。不要为了追求极致性能去用一个不熟悉的引擎调试成本可能远大于性能收益。5.3 内存布局与数据排布的影响内存布局对性能的影响经常被忽略但在某些模型上它比算子融合还重要。举个例子NCHW 和 NHWC 两种数据排布在不同硬件上的性能差异可能达到 2-3 倍。NVIDIA GPU 通常对 NHWC 更友好因为 Tensor Core 的矩阵运算要求通道维度连续而 Intel CPU 对 NCHW 的支持更好因为 SIMD 指令更适合这种布局。转换内存布局通常不需要改模型代码只需要在推理引擎的配置里指定即可。但要注意布局转换本身也有开销如果模型里频繁在两种布局之间切换反而会变慢。所以我的做法是整个模型统一用一种布局不要混用。6. 常见问题与排查技巧实录6.1 量化后精度暴跌的排查清单量化后精度暴跌是最常见的问题我整理了一个排查清单按优先级排序排查项可能原因解决方法校准集分布不匹配、数量太少重新采样 200-500 个代表性样本量化粒度per-tensor 太粗改成 per-channel校准算法MinMax 对异常值敏感换成 Entropy 或 Percentile敏感层某些层对量化敏感混合精度保留 FP16激活值范围动态范围过大检查是否有异常输入算子支持某些算子量化实现有 bug回退到 FP16 或 FP32我遇到过一次精度暴跌排查了半天发现是校准集里混入了几张全黑的图导致激活值范围估计严重偏小。换掉那几张图之后精度立刻恢复正常。所以校准集的质量比数量更重要一定要人工检查一遍。6.2 推理延迟不降反升的几种情况优化之后延迟反而变高这种情况也不少见。常见原因有几个第一量化后的模型虽然计算量小了但引入了额外的量化/反量化算子如果这些算子没有被融合开销可能超过收益。第二剪枝后的模型虽然参数少了但稀疏计算库的调度开销可能更大。第三编译优化时算子融合策略不当导致寄存器压力过大出现溢出。我的排查方法是先用 profiling 工具对比优化前后的算子级别时间分布找出变慢的算子然后针对性处理。如果是量化/反量化算子的问题尝试开启引擎的融合选项如果是稀疏计算的问题考虑换回稠密模型或者换一个稀疏库如果是寄存器溢出的问题调整融合策略或者降低并行度。6.3 跨平台部署的兼容性坑跨平台部署是另一个容易踩坑的地方。同一个模型在服务器上跑得好好的放到移动端就报错这种情况太常见了。主要原因有几个第一某些算子在移动端推理引擎里没有实现或者实现方式不同。第二移动端的浮点精度支持有限FP16 可能被降级成 FP32。第三移动端的内存和功耗限制导致某些优化策略不可用。我的经验是跨平台部署一定要尽早做兼容性测试不要等到最后才移植。测试的时候先用一个简单的模型跑通全流程确认算子支持、精度、性能都符合预期再换正式模型。另外尽量用推理引擎提供的标准算子避免自定义算子因为自定义算子在跨平台时往往需要重新实现。7. 我个人的优化流程与工具链推荐经过多个项目的积累我现在的模型优化流程基本固定下来了。第一步profiling搞清楚瓶颈在哪。第二步根据瓶颈选优化路线计算瓶颈优先量化内存瓶颈优先融合调度瓶颈优先换引擎。第三步小范围验证用一个小模型或者一个子图先试确认效果和精度。第四步全量优化逐步应用所有优化手段每步都验证精度。第五步跨平台测试确保目标硬件上都能跑通。工具链方面我常用的组合是PyTorch 做训练和导出ONNX 做中间表示ONNX Runtime 做快速验证TensorRT 做 GPU 部署TFLite 做移动端部署。量化用 ONNX Runtime 的 quantization 工具或者 TensorRT 的 pytorch-quantization剪枝用 torch.nn.utils.prune 或者自己写脚本蒸馏用 PyTorch 原生训练流程。最后分享一个小技巧优化过程中一定要保留每一步的中间模型和精度记录不要嫌麻烦。我吃过亏有一次优化到一半发现精度不对想回退到上一个版本结果中间模型没保存只能从头再来。从那以后我养成了每步都保存模型和记录精度的习惯虽然占点磁盘空间但省下的时间远不止那点空间。这个领域变化很快新的量化算法、新的编译技术、新的硬件支持层出不穷。我的建议是不要追求一次学到所有东西先把一条路线走通比如量化然后再逐步扩展。模型优化本质上是一个工程问题经验比理论更重要多动手、多踩坑、多总结比看十篇论文都管用。
