1. 模型优化器到底在优化什么第一次接触 Model-Optimizer 这个概念很多人会把它和“训练框架”“推理引擎”混为一谈。我刚开始做模型部署的时候也踩过这个坑以为把模型丢进某个加速库就万事大吉结果上线后延迟忽高忽低显存占用像坐过山车。后来才明白模型优化器本质上是一套在训练完成之后、部署上线之前对模型做“体检加改造”的工具链它的目标非常明确让同一个模型在目标硬件上跑得更快、占得更少、精度掉得更可控。说得再直白一点训练阶段我们关心的是“能不能收敛”而优化器阶段我们关心的是“能不能落地”。一个在实验室里精度 98% 的模型如果推理一次要 800 毫秒、显存吃掉 12GB那它在真实业务里基本没有生存空间。Model-Optimizer 要解决的就是这个落差问题。它通常包含几个核心能力量化、剪枝、算子融合、图优化、内存复用、内核自动调优。这些词听起来很唬人但拆开看每一个都对应着非常具体的工程动作。我写这篇东西的出发点是发现网上讲模型优化的文章要么停留在论文层面公式一堆但不知道怎么落地要么就是某个框架的官方文档步骤能跑通但完全不解释为什么这么设参数。所以我想以一个真正在项目里反复折腾过的人的角度把 Model-Optimizer 这套东西从思路到实操完整讲一遍。不管你是刚接触模型部署的新人还是已经做过几轮优化的老手应该都能从里面找到能直接抄作业的部分。适合读这篇内容的人大概有三类一是做算法落地、需要把模型塞进边缘设备或低成本服务器的工程师二是做推理服务、天天被延迟和成本指标追着跑的后端同学三是对模型压缩感兴趣、想系统了解量化剪枝实操细节的研究者。我会尽量少用公式多用实际参数和踩坑记录来说明问题。2. 整体优化思路与方案选型拆解2.1 为什么优化要分层次而不是一把梭很多人一上来就想直接量化到 INT8觉得位数越低越快。我早期也这么干过结果模型精度直接崩了分类任务 top-1 掉了 7 个点。后来才理解模型优化是一个分层递进的过程每一层解决不同维度的问题顺序错了就会互相干扰。我的经验是把优化分成四个层次来看。第一层是图级别优化也就是在计算图层面做算子融合、常量折叠、死代码消除。这一层不改变数值精度属于“白捡的收益”应该最先做。第二层是内存与调度优化包括内存池复用、算子执行顺序重排、并行度调整这一层影响的是显存占用和吞吐。第三层是数值精度优化也就是量化从 FP32 到 FP16 再到 INT8这一层收益最大但风险也最高。第四层是结构优化比如剪枝、蒸馏、低秩分解这一层会真正改变模型结构通常放在最后。为什么是这个顺序因为前三层基本不改变模型的数学等价性量化在可控范围内也近似等价做完之后你还能用同一套精度评估流程去验证。而结构优化一旦做了模型就变了再回头调量化参数会很痛苦。我见过有人先剪枝再量化结果两个误差叠加怎么调都救不回来最后只能推倒重来。2.2 量化方案怎么选PTQ 还是 QAT量化是 Model-Optimizer 里最核心也最容易出问题的一环。主流路线有两条训练后量化PTQ和量化感知训练QAT。选哪条不是拍脑袋决定的要看你的数据、算力和精度容忍度。PTQ 的优势是快不需要重新训练拿一个校准集跑几百个样本就能统计出激活值的分布然后算出量化参数。缺点是精度损失不可控尤其是对那些激活值分布很分散的模型比如包含大量注意力机制的 Transformer。QAT 则是在训练过程中插入伪量化节点让模型自己去适应量化误差精度通常能比 PTQ 高 1 到 3 个点但代价是要重新训练算力成本高。我的一般判断标准是这样的如果模型是 CNN 为主、任务对精度不敏感比如粗分类、检测框回归优先 PTQ省时省力。如果是 Transformer 类模型、或者任务对精度极其敏感比如医疗影像分割、语音识别那就老老实实上 QAT。还有一个折中方案叫部分量化只量化对精度不敏感的层比如前面的卷积层把敏感层比如最后的分类头、注意力输出保留在高精度这个在实际项目里用得非常多。2.3 剪枝的粒度与时机剪枝这块粒度选择直接决定了你能不能真正拿到加速收益。非结构化剪枝是把单个权重置零理论上压缩率很高但除非你的推理后端支持稀疏计算否则在实际硬件上根本跑不快因为零值还是要参与计算。结构化剪枝是直接砍掉整个通道、整个注意力头这样模型结构真的变小了加速是实打实的。我的建议是除非你明确知道目标硬件有稀疏加速能力否则一律优先结构化剪枝。剪枝的时机也很关键通常放在量化之前做因为剪枝会改变权重分布先剪枝再量化可以让量化校准更准确。如果反过来量化后的模型再剪枝那些被量化的权重分布会被打乱精度掉得更厉害。2.4 算子融合为什么是性价比最高的优化算子融合是我最推荐新手先上手的一类优化因为它几乎不损失精度收益却很直观。举个最常见的例子卷积后面接 BatchNorm 再接 ReLU这是 CNN 里的标准三件套。在推理阶段BatchNorm 的参数是固定的完全可以把它折叠进卷积的权重和偏置里这样三个算子就变成一个卷积加一个 ReLU甚至 ReLU 也能融进卷积的输出激活里。我实测过一个 ResNet-50 的模型光是把 ConvBNReLU 融合掉推理延迟就降了大概 18%显存占用降了 12%。这个收益是白送的因为数学上完全等价。类似的融合还有矩阵乘加偏置、LayerNorm 融合、注意力里的 QKV 合并等等。做优化的第一步永远应该是先把能融合的算子都融合掉再考虑量化剪枝这些有损操作。3. 核心细节解析与实操要点3.1 量化参数校准的实操细节PTQ 量化的核心是校准校准的质量直接决定量化后的精度。校准集的选择有几个原则第一样本数量不用太多通常 100 到 500 个就够但必须覆盖真实数据的分布第二校准集不能只用训练集最好从验证集或真实业务数据里采样因为训练集和线上数据的分布往往有偏移第三校准时要关闭数据增强用最原始的输入。校准算法也有讲究。最简单的是MinMax直接取激活值的最大最小值作为量化范围但对异常值非常敏感。稍微好一点的是Moving Average MinMax用滑动平均来平滑范围。再进一步是KL 散度校准通过最小化量化前后分布的 KL 散度来选范围对 Transformer 类模型效果明显更好。我在实际项目里CNN 用 Moving Average 就够Transformer 一律上 KL 散度。还有一个容易被忽略的点是逐通道量化和逐张量量化的区别。逐张量是整个权重矩阵共用一个缩放因子逐通道是每个输出通道一个缩放因子。逐通道量化精度明显更高但需要硬件支持。现在主流的推理后端基本都支持逐通道所以除非有特殊限制默认选逐通道。3.2 敏感层识别的具体方法不是所有层都适合量化识别敏感层是保证精度的关键一步。我的做法是逐层量化对比法先把整个模型量化测一遍精度然后每次只把某一层恢复成 FP32再测精度。如果恢复某一层后精度明显回升说明这一层就是敏感层应该保留高精度。这个方法听起来笨但非常有效。一个 50 层的模型跑 50 次评估每次几分钟总共也就几个小时换来的是对模型敏感性的完整认知。我做过一个语音识别模型发现只有最后两层和注意力输出层敏感把这三层保留 FP16其余全 INT8精度只掉了 0.3 个点但推理速度提升了 2.4 倍。除了逐层法还可以看激活值的动态范围。如果某一层的激活值范围特别大、分布特别分散那它大概率是敏感层。这个可以用校准阶段的统计信息快速筛出来作为逐层法的预筛选能省不少时间。3.3 剪枝率怎么定才不翻车剪枝率是最容易拍脑袋定错的参数。定高了精度崩定低了没收益。我的经验是从低到高逐步试探先剪 10%测精度再剪 20%再测直到精度掉到不可接受为止然后回退到上一个安全值。对于结构化剪枝还有一个更科学的做法是基于重要性的排序。每个通道的重要性可以用它的权重 L2 范数、或者它对输出的贡献度来衡量。把通道按重要性排序从最不重要的开始剪。这样比随机剪或者均匀剪效果好很多。我做过对比同样剪 30% 的通道基于重要性排序的精度比均匀剪枝高 2 个点左右。剪枝之后一定要做微调哪怕只训练几个 epoch也能把精度拉回来不少。微调的学习率要设小通常是原始训练学习率的十分之一到百分之一因为模型已经接近收敛学习率太大会把好不容易保留的权重又训乱。3.4 图优化的常见陷阱图优化虽然理论上无损但实操里也有坑。最常见的是融合后数值精度变化。比如 ConvBN 融合BN 的方差可能非常小融合后权重的数值范围会变大如果后续量化没考虑这一点量化误差会放大。所以融合之后要重新做一次校准不能沿用融合前的量化参数。另一个坑是动态形状支持。很多图优化工具默认输入形状是固定的如果你的模型需要支持变长输入比如 NLP 里的不同序列长度优化后的图可能跑不了。这时候要么把输入 padding 到固定长度要么选择支持动态形状的优化后端。我在做文本分类的时候就遇到过这个问题最后是把序列长度统一到 128 才解决。还有一个是自定义算子。如果你的模型里有自己写的算子图优化工具通常不认识会把它当成黑盒保留下来导致融合断链。解决办法是给自定义算子注册融合规则或者把它改写成标准算子的组合。4. 完整实操流程与关键环节实现4.1 环境准备与工具链搭建实操之前先把环境理清楚。我一般用 Python 3.9 或 3.10太新的版本有些优化库还没适配。核心依赖包括深度学习框架PyTorch 或 TensorFlow、推理后端ONNX Runtime、TensorRT 或 OpenVINO、以及优化工具本身。这里要强调一点优化工具和推理后端要匹配比如你用 TensorRT 部署那量化校准最好也用 TensorRT 自带的工具这样量化参数能直接对接不用来回转换。安装完之后先跑一个 baseline记录原始模型的精度、延迟、显存占用。这三个数字是后面所有优化的参照系没有 baseline 你根本不知道优化有没有效果。测延迟的时候要注意 warmup前几次推理通常很慢要跑够次数取稳定值。我一般 warmup 20 次然后测 100 次取平均和中位数。4.2 第一步算子融合与图优化先做无损优化。以 PyTorch 导出 ONNX 为例导出的时候就可以开启一些基础融合。导出命令大概是这样torch.onnx.export( model, dummy_input, model.onnx, opset_version13, do_constant_foldingTrue, input_names[input], output_names[output], dynamic_axes{input: {0: batch, 1: sequence}} )do_constant_foldingTrue会把常量表达式提前算好这是最基础的图优化。导出之后再用 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)这一步做完先测一遍精度和延迟。如果精度有变化说明融合出了问题要回退排查。正常情况下精度应该完全一致延迟降 10% 到 20%。4.3 第二步量化校准与敏感层处理图优化稳定之后开始量化。以 ONNX Runtime 的静态量化为例核心是配置校准数据读取器和量化参数from onnxruntime.quantization import quantize_static, CalibrationDataReader, QuantType class DataReader(CalibrationDataReader): def __init__(self, calibration_data): self.data iter(calibration_data) def get_next(self): return next(self.data, None) quantize_static( model_inputmodel_optimized.onnx, model_outputmodel_int8.onnx, calibration_data_readerDataReader(calib_samples), quant_formatQuantFormat.QDQ, activation_typeQuantType.QInt8, weight_typeQuantType.QInt8, per_channelTrue, calibrate_methodCalibrationMethod.KLDivergence )这里几个参数值得说明。quant_formatQDQ是量化-反量化格式兼容性最好。per_channelTrue开启逐通道量化精度更高。calibrate_method选 KL 散度对 Transformer 友好。校准集我一般准备 200 个样本覆盖各类输入。量化完先测精度。如果掉点超过 1 个点就启动敏感层分析把敏感层恢复成 FP16其余保持 INT8。ONNX Runtime 支持通过op_types_to_exclude来排除特定算子或者用节点名称精确排除。4.4 第三步结构化剪枝与微调量化稳定后再考虑剪枝。剪枝我用的是基于通道重要性的方法核心逻辑是计算每个卷积层或线性层输出通道的 L2 范数排序后剪掉最小的那部分。伪代码大概是这样import torch.nn.utils.prune as prune for name, module in model.named_modules(): if isinstance(module, torch.nn.Conv2d): prune.ln_structured( module, nameweight, amount0.3, n2, dim0 )剪完之后要移除剪枝掩码把结构真正固定下来然后做微调。微调我一般跑 5 到 10 个 epoch学习率设为原始的五十分之一用余弦退火调度。微调完再测精度如果还是掉得多就把剪枝率降下来重来。4.5 第四步端到端性能验证所有优化做完必须做端到端验证。不能只看单算子延迟要看整个推理管线的表现。我一般会测这几个指标首 token 延迟对生成类模型、平均推理延迟、P99 延迟、峰值显存、吞吐量。P99 延迟特别重要因为线上体验往往是被长尾拖垮的。验证的时候要用真实数据不能用随机张量。随机张量的数值分布和真实数据差很多量化后的表现可能完全不一样。我吃过这个亏用随机数据测得好好的上线后精度直接崩排查了半天才发现是校准集的问题。5. 常见问题与排查技巧实录5.1 量化后精度暴跌怎么排查精度暴跌是最常见的问题排查要按顺序来。先看校准集是不是样本太少或者分布不对。再看量化配置是不是用了逐张量而不是逐通道校准方法是不是不合适。然后做敏感层分析找出哪些层不能量化。最后看是不是有异常值某些层的激活值范围特别大把整个量化范围撑开了导致其他值都被压到很小的区间。我遇到过一个典型案例一个检测模型量化后 mAP 掉了 15 个点。排查发现是某个中间层的激活值有一个极端离群点把量化范围撑到了正常值的 100 倍。解决办法是用百分位截断把量化范围限制在 99.9% 分位数以内精度立刻恢复到只掉 1 个点。5.2 优化后反而变慢是什么原因优化后变慢通常有几个原因。一是算子融合断链某个自定义算子打断了融合导致前后算子无法合并。二是量化反量化开销如果量化层和 FP32 层频繁交替每次转换都有开销反而比全 FP32 慢。三是内存布局不匹配优化后的张量布局和硬件偏好不一致导致频繁的内存重排。排查方法是逐段测延迟找出变慢的具体环节。我一般用推理后端自带的 profiling 工具能看到每个算子的耗时。如果发现某个算子耗时异常就重点看它前后的数据转换。5.3 不同硬件上的优化策略差异同一个模型在不同硬件上最优优化策略可能完全不同。GPU 上量化收益主要来自显存带宽节省和 Tensor Core 加速所以 INT8 量化收益大。CPU 上量化收益来自 SIMD 指令和缓存命中率INT8 同样有效但收益没那么夸张。边缘 NPU 上则要看具体芯片支持哪些量化格式有些只支持 INT8 逐张量有些支持混合精度。我的建议是先确定目标硬件再选优化方案不要反过来。我见过有人先在 GPU 上把模型优化到极致结果要部署到边缘设备发现所有优化都不兼容只能重来。5.4 常见问题速查表问题现象可能原因排查方向解决思路量化后精度掉超过 3 个点校准集分布不对检查校准样本来源用真实业务数据重新校准量化后精度掉 1 到 3 个点敏感层未保护逐层量化对比敏感层保留 FP16优化后延迟反而升高算子融合断链profiling 逐算子耗时改写自定义算子或调整融合规则显存占用没降内存池未复用检查内存分配策略开启内存复用或调整 batch剪枝后精度崩剪枝率过高逐步降低剪枝率回退到安全值并微调动态形状报错图优化固定了形状检查输入形状配置开启动态形状或 padding量化模型加载失败量化格式不兼容检查后端支持的格式转换量化格式或换后端5.5 几个我踩过的坑第一个坑是校准集用了训练数据。训练数据经过增强分布和线上数据不一样校准出来的量化参数在线上表现很差。后来我改成从验证集采样问题解决。第二个坑是量化后没重新测精度。有一次我改了一个量化参数觉得影响不大就没测结果上线后精度掉了 2 个点被业务方追着问。从那以后我养成了习惯任何参数改动都要重新跑一遍完整评估。第三个坑是剪枝后忘了移除掩码。PyTorch 的 prune 默认是加掩码权重还在只是被置零了。如果不调用prune.remove模型大小根本没变加速也是假的。这个坑我踩了两次才记住。第四个坑是忽略了大 batch 下的表现。小 batch 测得好好的大 batch 一上显存就爆。后来我测性能都会覆盖多个 batch size确保线上各种负载下都稳定。6. 优化效果的量化评估与持续迭代6.1 建立可复现的评估基线优化不是一次性的活而是一个持续迭代的过程。要迭代就必须有一个稳定可复现的评估基线。我的做法是把评估流程脚本化每次优化后自动跑一遍输出精度、延迟、显存、吞吐四个维度的对比表。这样任何一次改动的影响都能立刻看到不会出现“改了一堆东西但不知道哪个起作用”的情况。评估基线还要固定随机种子、固定输入数据、固定硬件环境。我见过有人在不同机器上测结果差异比优化本身还大完全没法判断优化效果。所以评估一定要在同一台机器、同一套数据上做。6.2 精度与性能的权衡曲线优化本质上是在精度和性能之间找平衡点。我一般会画一条权衡曲线横轴是性能指标延迟或吞吐纵轴是精度。每做一次优化就在曲线上标一个点。理想情况下我们希望曲线尽量往右上角靠也就是同样精度下性能更好或者同样性能下精度更高。有了这条曲线做决策就清晰了。如果业务要求精度不低于某个阈值那就在满足精度的前提下选性能最好的方案。如果业务对延迟有硬性要求那就在满足延迟的前提下选精度最高的方案。这条曲线还能帮你判断某个优化方向是不是值得继续投入如果继续优化收益越来越小就该停手了。6.3 上线后的监控与回滚机制优化后的模型上线一定要有监控和回滚机制。监控要覆盖精度指标和性能指标精度指标可以用线上采样加人工标注的方式定期评估性能指标则实时监控延迟和错误率。一旦发现精度或性能异常要能快速回滚到优化前的版本。我一般会保留至少两个版本优化版和原始版。上线时先灰度把一小部分流量切到优化版观察一段时间没问题再全量。这个流程虽然麻烦但能避免大事故。我见过有人直接全量上线优化模型结果精度崩了影响了几百万用户最后只能紧急回滚。6.4 后续可以继续深挖的方向模型优化这个领域还在快速演进。我目前关注几个方向一是混合精度量化的自动化搜索让工具自动找出每层最优的量化位宽而不是人工试。二是硬件感知的剪枝剪枝时考虑目标硬件的特性剪出硬件真正喜欢的结构。三是大模型的优化随着模型越来越大量化和剪枝的挑战也在变化尤其是 KV Cache 的优化和注意力机制的压缩。这些方向我还在摸索等有成熟经验了再单独写一篇。模型优化没有银弹每个模型、每个硬件、每个业务场景都有自己的最优解。多动手、多测、多记录比看再多理论都管用。 
长河君 · 2026/9/29 9:56:30 · 阅读 1.2k 模型优化器实战：量化剪枝与算子融合的落地指南
1. 模型优化器到底在优化什么第一次接触 Model-Optimizer 这个概念很多人会把它和“训练框架”“推理引擎”混为一谈。我刚开始做模型部署的时候也踩过这个坑以为把模型丢进某个加速库就万事大吉结果上线后延迟忽高忽低显存占用像坐过山车。后来才明白模型优化器本质上是一套在训练完成之后、部署上线之前对模型做“体检加改造”的工具链它的目标非常明确让同一个模型在目标硬件上跑得更快、占得更少、精度掉得更可控。说得再直白一点训练阶段我们关心的是“能不能收敛”而优化器阶段我们关心的是“能不能落地”。一个在实验室里精度 98% 的模型如果推理一次要 800 毫秒、显存吃掉 12GB那它在真实业务里基本没有生存空间。Model-Optimizer 要解决的就是这个落差问题。它通常包含几个核心能力量化、剪枝、算子融合、图优化、内存复用、内核自动调优。这些词听起来很唬人但拆开看每一个都对应着非常具体的工程动作。我写这篇东西的出发点是发现网上讲模型优化的文章要么停留在论文层面公式一堆但不知道怎么落地要么就是某个框架的官方文档步骤能跑通但完全不解释为什么这么设参数。所以我想以一个真正在项目里反复折腾过的人的角度把 Model-Optimizer 这套东西从思路到实操完整讲一遍。不管你是刚接触模型部署的新人还是已经做过几轮优化的老手应该都能从里面找到能直接抄作业的部分。适合读这篇内容的人大概有三类一是做算法落地、需要把模型塞进边缘设备或低成本服务器的工程师二是做推理服务、天天被延迟和成本指标追着跑的后端同学三是对模型压缩感兴趣、想系统了解量化剪枝实操细节的研究者。我会尽量少用公式多用实际参数和踩坑记录来说明问题。2. 整体优化思路与方案选型拆解2.1 为什么优化要分层次而不是一把梭很多人一上来就想直接量化到 INT8觉得位数越低越快。我早期也这么干过结果模型精度直接崩了分类任务 top-1 掉了 7 个点。后来才理解模型优化是一个分层递进的过程每一层解决不同维度的问题顺序错了就会互相干扰。我的经验是把优化分成四个层次来看。第一层是图级别优化也就是在计算图层面做算子融合、常量折叠、死代码消除。这一层不改变数值精度属于“白捡的收益”应该最先做。第二层是内存与调度优化包括内存池复用、算子执行顺序重排、并行度调整这一层影响的是显存占用和吞吐。第三层是数值精度优化也就是量化从 FP32 到 FP16 再到 INT8这一层收益最大但风险也最高。第四层是结构优化比如剪枝、蒸馏、低秩分解这一层会真正改变模型结构通常放在最后。为什么是这个顺序因为前三层基本不改变模型的数学等价性量化在可控范围内也近似等价做完之后你还能用同一套精度评估流程去验证。而结构优化一旦做了模型就变了再回头调量化参数会很痛苦。我见过有人先剪枝再量化结果两个误差叠加怎么调都救不回来最后只能推倒重来。2.2 量化方案怎么选PTQ 还是 QAT量化是 Model-Optimizer 里最核心也最容易出问题的一环。主流路线有两条训练后量化PTQ和量化感知训练QAT。选哪条不是拍脑袋决定的要看你的数据、算力和精度容忍度。PTQ 的优势是快不需要重新训练拿一个校准集跑几百个样本就能统计出激活值的分布然后算出量化参数。缺点是精度损失不可控尤其是对那些激活值分布很分散的模型比如包含大量注意力机制的 Transformer。QAT 则是在训练过程中插入伪量化节点让模型自己去适应量化误差精度通常能比 PTQ 高 1 到 3 个点但代价是要重新训练算力成本高。我的一般判断标准是这样的如果模型是 CNN 为主、任务对精度不敏感比如粗分类、检测框回归优先 PTQ省时省力。如果是 Transformer 类模型、或者任务对精度极其敏感比如医疗影像分割、语音识别那就老老实实上 QAT。还有一个折中方案叫部分量化只量化对精度不敏感的层比如前面的卷积层把敏感层比如最后的分类头、注意力输出保留在高精度这个在实际项目里用得非常多。2.3 剪枝的粒度与时机剪枝这块粒度选择直接决定了你能不能真正拿到加速收益。非结构化剪枝是把单个权重置零理论上压缩率很高但除非你的推理后端支持稀疏计算否则在实际硬件上根本跑不快因为零值还是要参与计算。结构化剪枝是直接砍掉整个通道、整个注意力头这样模型结构真的变小了加速是实打实的。我的建议是除非你明确知道目标硬件有稀疏加速能力否则一律优先结构化剪枝。剪枝的时机也很关键通常放在量化之前做因为剪枝会改变权重分布先剪枝再量化可以让量化校准更准确。如果反过来量化后的模型再剪枝那些被量化的权重分布会被打乱精度掉得更厉害。2.4 算子融合为什么是性价比最高的优化算子融合是我最推荐新手先上手的一类优化因为它几乎不损失精度收益却很直观。举个最常见的例子卷积后面接 BatchNorm 再接 ReLU这是 CNN 里的标准三件套。在推理阶段BatchNorm 的参数是固定的完全可以把它折叠进卷积的权重和偏置里这样三个算子就变成一个卷积加一个 ReLU甚至 ReLU 也能融进卷积的输出激活里。我实测过一个 ResNet-50 的模型光是把 ConvBNReLU 融合掉推理延迟就降了大概 18%显存占用降了 12%。这个收益是白送的因为数学上完全等价。类似的融合还有矩阵乘加偏置、LayerNorm 融合、注意力里的 QKV 合并等等。做优化的第一步永远应该是先把能融合的算子都融合掉再考虑量化剪枝这些有损操作。3. 核心细节解析与实操要点3.1 量化参数校准的实操细节PTQ 量化的核心是校准校准的质量直接决定量化后的精度。校准集的选择有几个原则第一样本数量不用太多通常 100 到 500 个就够但必须覆盖真实数据的分布第二校准集不能只用训练集最好从验证集或真实业务数据里采样因为训练集和线上数据的分布往往有偏移第三校准时要关闭数据增强用最原始的输入。校准算法也有讲究。最简单的是MinMax直接取激活值的最大最小值作为量化范围但对异常值非常敏感。稍微好一点的是Moving Average MinMax用滑动平均来平滑范围。再进一步是KL 散度校准通过最小化量化前后分布的 KL 散度来选范围对 Transformer 类模型效果明显更好。我在实际项目里CNN 用 Moving Average 就够Transformer 一律上 KL 散度。还有一个容易被忽略的点是逐通道量化和逐张量量化的区别。逐张量是整个权重矩阵共用一个缩放因子逐通道是每个输出通道一个缩放因子。逐通道量化精度明显更高但需要硬件支持。现在主流的推理后端基本都支持逐通道所以除非有特殊限制默认选逐通道。3.2 敏感层识别的具体方法不是所有层都适合量化识别敏感层是保证精度的关键一步。我的做法是逐层量化对比法先把整个模型量化测一遍精度然后每次只把某一层恢复成 FP32再测精度。如果恢复某一层后精度明显回升说明这一层就是敏感层应该保留高精度。这个方法听起来笨但非常有效。一个 50 层的模型跑 50 次评估每次几分钟总共也就几个小时换来的是对模型敏感性的完整认知。我做过一个语音识别模型发现只有最后两层和注意力输出层敏感把这三层保留 FP16其余全 INT8精度只掉了 0.3 个点但推理速度提升了 2.4 倍。除了逐层法还可以看激活值的动态范围。如果某一层的激活值范围特别大、分布特别分散那它大概率是敏感层。这个可以用校准阶段的统计信息快速筛出来作为逐层法的预筛选能省不少时间。3.3 剪枝率怎么定才不翻车剪枝率是最容易拍脑袋定错的参数。定高了精度崩定低了没收益。我的经验是从低到高逐步试探先剪 10%测精度再剪 20%再测直到精度掉到不可接受为止然后回退到上一个安全值。对于结构化剪枝还有一个更科学的做法是基于重要性的排序。每个通道的重要性可以用它的权重 L2 范数、或者它对输出的贡献度来衡量。把通道按重要性排序从最不重要的开始剪。这样比随机剪或者均匀剪效果好很多。我做过对比同样剪 30% 的通道基于重要性排序的精度比均匀剪枝高 2 个点左右。剪枝之后一定要做微调哪怕只训练几个 epoch也能把精度拉回来不少。微调的学习率要设小通常是原始训练学习率的十分之一到百分之一因为模型已经接近收敛学习率太大会把好不容易保留的权重又训乱。3.4 图优化的常见陷阱图优化虽然理论上无损但实操里也有坑。最常见的是融合后数值精度变化。比如 ConvBN 融合BN 的方差可能非常小融合后权重的数值范围会变大如果后续量化没考虑这一点量化误差会放大。所以融合之后要重新做一次校准不能沿用融合前的量化参数。另一个坑是动态形状支持。很多图优化工具默认输入形状是固定的如果你的模型需要支持变长输入比如 NLP 里的不同序列长度优化后的图可能跑不了。这时候要么把输入 padding 到固定长度要么选择支持动态形状的优化后端。我在做文本分类的时候就遇到过这个问题最后是把序列长度统一到 128 才解决。还有一个是自定义算子。如果你的模型里有自己写的算子图优化工具通常不认识会把它当成黑盒保留下来导致融合断链。解决办法是给自定义算子注册融合规则或者把它改写成标准算子的组合。4. 完整实操流程与关键环节实现4.1 环境准备与工具链搭建实操之前先把环境理清楚。我一般用 Python 3.9 或 3.10太新的版本有些优化库还没适配。核心依赖包括深度学习框架PyTorch 或 TensorFlow、推理后端ONNX Runtime、TensorRT 或 OpenVINO、以及优化工具本身。这里要强调一点优化工具和推理后端要匹配比如你用 TensorRT 部署那量化校准最好也用 TensorRT 自带的工具这样量化参数能直接对接不用来回转换。安装完之后先跑一个 baseline记录原始模型的精度、延迟、显存占用。这三个数字是后面所有优化的参照系没有 baseline 你根本不知道优化有没有效果。测延迟的时候要注意 warmup前几次推理通常很慢要跑够次数取稳定值。我一般 warmup 20 次然后测 100 次取平均和中位数。4.2 第一步算子融合与图优化先做无损优化。以 PyTorch 导出 ONNX 为例导出的时候就可以开启一些基础融合。导出命令大概是这样torch.onnx.export( model, dummy_input, model.onnx, opset_version13, do_constant_foldingTrue, input_names[input], output_names[output], dynamic_axes{input: {0: batch, 1: sequence}} )do_constant_foldingTrue会把常量表达式提前算好这是最基础的图优化。导出之后再用 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)这一步做完先测一遍精度和延迟。如果精度有变化说明融合出了问题要回退排查。正常情况下精度应该完全一致延迟降 10% 到 20%。4.3 第二步量化校准与敏感层处理图优化稳定之后开始量化。以 ONNX Runtime 的静态量化为例核心是配置校准数据读取器和量化参数from onnxruntime.quantization import quantize_static, CalibrationDataReader, QuantType class DataReader(CalibrationDataReader): def __init__(self, calibration_data): self.data iter(calibration_data) def get_next(self): return next(self.data, None) quantize_static( model_inputmodel_optimized.onnx, model_outputmodel_int8.onnx, calibration_data_readerDataReader(calib_samples), quant_formatQuantFormat.QDQ, activation_typeQuantType.QInt8, weight_typeQuantType.QInt8, per_channelTrue, calibrate_methodCalibrationMethod.KLDivergence )这里几个参数值得说明。quant_formatQDQ是量化-反量化格式兼容性最好。per_channelTrue开启逐通道量化精度更高。calibrate_method选 KL 散度对 Transformer 友好。校准集我一般准备 200 个样本覆盖各类输入。量化完先测精度。如果掉点超过 1 个点就启动敏感层分析把敏感层恢复成 FP16其余保持 INT8。ONNX Runtime 支持通过op_types_to_exclude来排除特定算子或者用节点名称精确排除。4.4 第三步结构化剪枝与微调量化稳定后再考虑剪枝。剪枝我用的是基于通道重要性的方法核心逻辑是计算每个卷积层或线性层输出通道的 L2 范数排序后剪掉最小的那部分。伪代码大概是这样import torch.nn.utils.prune as prune for name, module in model.named_modules(): if isinstance(module, torch.nn.Conv2d): prune.ln_structured( module, nameweight, amount0.3, n2, dim0 )剪完之后要移除剪枝掩码把结构真正固定下来然后做微调。微调我一般跑 5 到 10 个 epoch学习率设为原始的五十分之一用余弦退火调度。微调完再测精度如果还是掉得多就把剪枝率降下来重来。4.5 第四步端到端性能验证所有优化做完必须做端到端验证。不能只看单算子延迟要看整个推理管线的表现。我一般会测这几个指标首 token 延迟对生成类模型、平均推理延迟、P99 延迟、峰值显存、吞吐量。P99 延迟特别重要因为线上体验往往是被长尾拖垮的。验证的时候要用真实数据不能用随机张量。随机张量的数值分布和真实数据差很多量化后的表现可能完全不一样。我吃过这个亏用随机数据测得好好的上线后精度直接崩排查了半天才发现是校准集的问题。5. 常见问题与排查技巧实录5.1 量化后精度暴跌怎么排查精度暴跌是最常见的问题排查要按顺序来。先看校准集是不是样本太少或者分布不对。再看量化配置是不是用了逐张量而不是逐通道校准方法是不是不合适。然后做敏感层分析找出哪些层不能量化。最后看是不是有异常值某些层的激活值范围特别大把整个量化范围撑开了导致其他值都被压到很小的区间。我遇到过一个典型案例一个检测模型量化后 mAP 掉了 15 个点。排查发现是某个中间层的激活值有一个极端离群点把量化范围撑到了正常值的 100 倍。解决办法是用百分位截断把量化范围限制在 99.9% 分位数以内精度立刻恢复到只掉 1 个点。5.2 优化后反而变慢是什么原因优化后变慢通常有几个原因。一是算子融合断链某个自定义算子打断了融合导致前后算子无法合并。二是量化反量化开销如果量化层和 FP32 层频繁交替每次转换都有开销反而比全 FP32 慢。三是内存布局不匹配优化后的张量布局和硬件偏好不一致导致频繁的内存重排。排查方法是逐段测延迟找出变慢的具体环节。我一般用推理后端自带的 profiling 工具能看到每个算子的耗时。如果发现某个算子耗时异常就重点看它前后的数据转换。5.3 不同硬件上的优化策略差异同一个模型在不同硬件上最优优化策略可能完全不同。GPU 上量化收益主要来自显存带宽节省和 Tensor Core 加速所以 INT8 量化收益大。CPU 上量化收益来自 SIMD 指令和缓存命中率INT8 同样有效但收益没那么夸张。边缘 NPU 上则要看具体芯片支持哪些量化格式有些只支持 INT8 逐张量有些支持混合精度。我的建议是先确定目标硬件再选优化方案不要反过来。我见过有人先在 GPU 上把模型优化到极致结果要部署到边缘设备发现所有优化都不兼容只能重来。5.4 常见问题速查表问题现象可能原因排查方向解决思路量化后精度掉超过 3 个点校准集分布不对检查校准样本来源用真实业务数据重新校准量化后精度掉 1 到 3 个点敏感层未保护逐层量化对比敏感层保留 FP16优化后延迟反而升高算子融合断链profiling 逐算子耗时改写自定义算子或调整融合规则显存占用没降内存池未复用检查内存分配策略开启内存复用或调整 batch剪枝后精度崩剪枝率过高逐步降低剪枝率回退到安全值并微调动态形状报错图优化固定了形状检查输入形状配置开启动态形状或 padding量化模型加载失败量化格式不兼容检查后端支持的格式转换量化格式或换后端5.5 几个我踩过的坑第一个坑是校准集用了训练数据。训练数据经过增强分布和线上数据不一样校准出来的量化参数在线上表现很差。后来我改成从验证集采样问题解决。第二个坑是量化后没重新测精度。有一次我改了一个量化参数觉得影响不大就没测结果上线后精度掉了 2 个点被业务方追着问。从那以后我养成了习惯任何参数改动都要重新跑一遍完整评估。第三个坑是剪枝后忘了移除掩码。PyTorch 的 prune 默认是加掩码权重还在只是被置零了。如果不调用prune.remove模型大小根本没变加速也是假的。这个坑我踩了两次才记住。第四个坑是忽略了大 batch 下的表现。小 batch 测得好好的大 batch 一上显存就爆。后来我测性能都会覆盖多个 batch size确保线上各种负载下都稳定。6. 优化效果的量化评估与持续迭代6.1 建立可复现的评估基线优化不是一次性的活而是一个持续迭代的过程。要迭代就必须有一个稳定可复现的评估基线。我的做法是把评估流程脚本化每次优化后自动跑一遍输出精度、延迟、显存、吞吐四个维度的对比表。这样任何一次改动的影响都能立刻看到不会出现“改了一堆东西但不知道哪个起作用”的情况。评估基线还要固定随机种子、固定输入数据、固定硬件环境。我见过有人在不同机器上测结果差异比优化本身还大完全没法判断优化效果。所以评估一定要在同一台机器、同一套数据上做。6.2 精度与性能的权衡曲线优化本质上是在精度和性能之间找平衡点。我一般会画一条权衡曲线横轴是性能指标延迟或吞吐纵轴是精度。每做一次优化就在曲线上标一个点。理想情况下我们希望曲线尽量往右上角靠也就是同样精度下性能更好或者同样性能下精度更高。有了这条曲线做决策就清晰了。如果业务要求精度不低于某个阈值那就在满足精度的前提下选性能最好的方案。如果业务对延迟有硬性要求那就在满足延迟的前提下选精度最高的方案。这条曲线还能帮你判断某个优化方向是不是值得继续投入如果继续优化收益越来越小就该停手了。6.3 上线后的监控与回滚机制优化后的模型上线一定要有监控和回滚机制。监控要覆盖精度指标和性能指标精度指标可以用线上采样加人工标注的方式定期评估性能指标则实时监控延迟和错误率。一旦发现精度或性能异常要能快速回滚到优化前的版本。我一般会保留至少两个版本优化版和原始版。上线时先灰度把一小部分流量切到优化版观察一段时间没问题再全量。这个流程虽然麻烦但能避免大事故。我见过有人直接全量上线优化模型结果精度崩了影响了几百万用户最后只能紧急回滚。6.4 后续可以继续深挖的方向模型优化这个领域还在快速演进。我目前关注几个方向一是混合精度量化的自动化搜索让工具自动找出每层最优的量化位宽而不是人工试。二是硬件感知的剪枝剪枝时考虑目标硬件的特性剪出硬件真正喜欢的结构。三是大模型的优化随着模型越来越大量化和剪枝的挑战也在变化尤其是 KV Cache 的优化和注意力机制的压缩。这些方向我还在摸索等有成熟经验了再单独写一篇。模型优化没有银弹每个模型、每个硬件、每个业务场景都有自己的最优解。多动手、多测、多记录比看再多理论都管用。