1. 从“模型优化器”这个热词说起它到底在解决什么问题“Model-Optimizer”这个词最近在技术圈被反复提起很多人第一次看到会以为它只是某个训练脚本里的一个类名比如 PyTorch 里的torch.optim.Adam。但真正在工程一线待过的人都知道当大家把“Model-Optimizer”当作一个独立话题来讨论时它指的往往不是那个优化算法本身而是一整套围绕模型做“减负、提速、省资源”的工程化手段集合。换句话说它关心的不是“怎么把 loss 降下去”而是“模型已经训好了怎么让它跑得更快、占得更少、上得了更小的设备”。我最早接触这类需求是在一个把视觉模型往边缘设备上搬的项目里。训练环境里跑得好好的模型一到目标硬件上就卡得没法看推理一帧要几百毫秒内存直接爆掉。那时候我才意识到训练阶段的优化器和部署阶段的“模型优化”完全是两码事。前者调的是参数更新策略后者调的是模型结构、数值精度、算子实现和内存布局。Model-Optimizer 这个标题背后真正有价值的部分是后者——它是一套让模型“落地”的工程方法论。这篇文章适合三类人看第一类是做模型部署、被推理性能折磨过的工程师第二类是想了解模型压缩、量化、图优化这些概念但不知道从哪下手的学生或转行者第三类是做算法但需要和工程团队对接、想知道自己交出去的模型会被怎么“改造”的研究人员。我会尽量把每个技术点讲透告诉你为什么这么做、怎么做、做完之后怎么验证以及我在实操中踩过的那些坑。需要先明确一个边界Model-Optimizer 不是某一个具体工具的名字而是一个领域统称。市面上有大量工具和框架在做这件事比如 ONNX Runtime 的图优化、TensorRT 的层融合、各种量化工具链、剪枝库等等。我不会绑定某一个具体产品而是把这类工具背后的通用逻辑拆开讲这样你换任何一套工具都能对上号。2. 模型优化的四条主线量化、剪枝、蒸馏与图优化在动手之前得先搞清楚模型优化到底有哪几条路可以走。很多人一上来就问“怎么把模型变小”但“变小”其实有好几种不同的含义可能是参数数量变少可能是数值精度降低可能是计算图被合并简化也可能是运行时内存占用下降。不同的目标对应不同的技术路线选错了方向后面全是白费功夫。2.1 量化把浮点数换成低比特整数量化是这四条线里性价比最高、落地最广的一种。它的核心思想很朴素神经网络里的权重和激活值原本用 32 位浮点数FP32存储和计算但很多场景下根本不需要这么高的精度用 8 位整数INT8甚至更低就能跑出几乎一样的结果。一个 FP32 权重占 4 字节换成 INT8 只占 1 字节模型体积直接降到四分之一同时整数运算在多数硬件上比浮点运算快得多。量化分两大类训练后量化Post-Training Quantization, PTQ和量化感知训练Quantization-Aware Training, QAT。PTQ 是模型已经训好了直接拿一批校准数据跑一遍统计每层激活值的分布范围然后算出量化参数scale 和 zero-point把权重和激活映射到整数区间。它的优点是快几十分钟就能搞定不需要重新训练。缺点是精度损失不可控遇到对数值敏感的层比如某些注意力结构可能掉点明显。QAT 则是在训练阶段就模拟量化的舍入误差让模型提前“适应”低精度。具体做法是在前向传播里插入伪量化节点把权重和激活先量化再反量化这样梯度还是能正常回传模型会学着在量化噪声下保持精度。QAT 效果通常比 PTQ 好但代价是要重新训练时间和算力成本高不少。我个人的经验是先试 PTQ掉点在接受范围内就用它如果 PTQ 掉点超过阈值再考虑 QAT。校准数据的选取非常关键它必须能代表真实推理时的输入分布。我见过有人拿训练集里随机抽的几百张图做校准结果上线后遇到分布外的输入量化误差直接爆炸。校准集最好从验证集里按类别均衡采样数量不用多几百到一千条通常够用但分布一定要对。2.2 剪枝去掉不重要的连接和通道剪枝的思路是神经网络里存在大量冗余参数把不重要的那些去掉模型照样能跑。剪枝分非结构化剪枝和结构化剪枝。非结构化剪枝是把单个权重置零理论上压缩率高但产生的稀疏矩阵在通用硬件上很难加速除非你有专门支持稀疏计算的加速器。结构化剪枝则是按通道、按层、按注意力头来剪剪完之后模型结构是规整的普通硬件就能直接受益。结构化剪枝的典型流程是先训练一个稠密模型然后根据某种重要性指标比如通道的 L1/L2 范数、BN 层的缩放因子、梯度大小给每个通道打分把分数低的通道连同对应的卷积核一起删掉最后再微调恢复精度。这里有个容易踩的坑剪枝率不能一刀切。有些层对精度极其敏感剪一点点就崩有些层冗余度很高剪掉一半都没事。比较稳妥的做法是逐层做敏感性分析给每层设不同的剪枝率而不是全局统一。2.3 蒸馏让小模型学大模型的“软标签”知识蒸馏是另一条路不直接压缩原模型而是训练一个结构更小的学生模型让它去模仿大模型教师模型的输出。关键在于学生模型学的不是硬标签比如分类任务里的 one-hot而是教师模型输出的概率分布也就是“软标签”。软标签里包含了类别之间的相对关系信息比如“这张图是猫的概率 0.8是狗的概率 0.15”这种信息比单纯的“这是猫”要丰富得多学生模型能学到更好的决策边界。蒸馏的难点在于温度参数和损失权重的调节。温度高的时候软标签更平滑类别间关系信息更充分温度低的时候接近硬标签。通常会在训练初期用较高温度后期降下来。另外教师模型和学生模型的容量差距不能太大差太多学生学不动差太少又没压缩效果。2.4 图优化在计算图层面做等价变换图优化不改变模型的数学等价性而是通过合并算子、消除冗余、重排计算顺序来提速。常见的操作包括算子融合把卷积、BN、ReLU 合并成一个算子减少内存读写、常量折叠把编译期就能算出来的子图提前算好、死代码消除去掉不影响输出的节点、内存复用让不同张量共享同一块内存。这些优化通常由推理框架自动完成比如 ONNX Runtime 和 TensorRT 都有内置的图优化 pass。你不需要手写这些变换但需要知道它们存在并且在导出模型时保留足够的信息让框架能识别出可融合的模式。这四条线不是互斥的实际项目里经常组合使用。比如先剪枝得到一个更小的模型再量化进一步压缩最后用图优化把推理图整理干净。但组合的顺序有讲究后面会细说。3. 量化实操从校准集准备到精度验证的完整链路量化是大多数人第一个会尝试的优化手段因为它见效快、工具成熟。但“跑通”和“跑好”之间差距很大。这一章我把量化的完整链路拆开每一步都讲清楚为什么这么做。3.1 校准集怎么选才算“有代表性”校准集的唯一作用是统计激活值的动态范围从而确定量化参数。它不需要标签但必须覆盖真实推理时可能出现的输入分布。我见过太多人随便拿几十张图就开跑结果量化后模型在特定类别上精度暴跌。一个可靠的做法是从验证集里按类别分层采样每个类别抽相同数量的样本总数控制在 500 到 1000 之间。如果任务没有明确类别比如检测、分割就按场景或数据来源分层。校准集的数量不是越多越好超过一定量后收益递减但分布覆盖度一定要够。另外校准集要经过和推理时完全一致的预处理包括归一化、resize、通道顺序等任何不一致都会导致统计偏差。提示如果你的模型有多个输入分支比如多模态每个分支都要有对应的校准数据不能只校准主分支。3.2 逐层敏感度分析找出不能量化的“刺头”不是所有层都适合量化。有些层对数值精度极其敏感强行量化会导致整体精度崩塌。逐层敏感度分析的做法是每次只把一层保持 FP32其余层量化观察精度变化。如果某层保持 FP32 后精度明显回升说明这层就是敏感层应该在最终量化方案里把它排除。这个分析过程比较耗时因为要跑多次评估。但它是值得的尤其是当 PTQ 掉点严重时敏感度分析能帮你快速定位问题层。常见的敏感层包括网络的第一层和最后一层、某些归一化层、以及输出 logits 的层。很多量化工具支持配置“排除层”列表把敏感层加进去就行。3.3 量化精度验证不能只看一个指标量化后的验证不能只看 top-1 准确率。对于分类任务至少要看 top-1 和 top-5对于检测任务要看 mAP 以及不同 IoU 阈值下的表现对于分割任务要看 mIoU 和逐类 IoU。更重要的是要对比量化前后在同一批测试数据上的逐样本差异找出那些量化后预测翻转的样本分析它们有什么共性。如果翻转样本集中在某些类别或某些场景说明量化方案在这些方向上还有问题。我通常会做一个“精度-体积-延迟”的三方对比表把 FP32 原模型、PTQ 模型、QAT 模型的指标放在一起看。有时候 PTQ 精度只掉 0.5%但延迟降了一半这种就非常划算有时候精度掉 2% 但延迟只降了 10%那就得重新考虑是否值得。方案模型体积推理延迟Top-1 精度是否需重训FP32 原模型100%100%基准否PTQ INT8约 25%约 40%-60%可能掉 0.5%-3%否QAT INT8约 25%约 40%-60%通常掉 0.1%-0.5%是3.4 量化踩坑实录那些文档里不会写的问题第一个坑是算子不支持。不是所有算子都有量化实现遇到不支持的算子工具链可能会回退到 FP32导致实际加速比远低于预期。解决办法是提前查清楚目标推理框架支持哪些量化算子必要时替换模型结构。第二个坑是per-tensor 和 per-channel 的选择。权重量化通常用 per-channel因为不同通道的数值范围差异很大per-channel 能更精细地拟合激活量化通常用 per-tensor因为激活值是动态的per-channel 统计成本太高。搞反了会导致精度明显下降。第三个坑是量化后的模型在不同硬件上表现不一致。同样是 INT8不同芯片的指令集和累加器位宽不同有的用 INT32 累加有的用 INT16这会影响最终精度。所以量化验证一定要在目标硬件上做不能只在开发机上跑。4. 剪枝与蒸馏的工程落地什么时候该用哪一招量化的热度最高但剪枝和蒸馏在特定场景下不可替代。这一章讲清楚它们的适用边界和实操要点。4.1 结构化剪枝的通道重要性评估方法结构化剪枝的核心是“怎么判断一个通道重不重要”。常用的指标有几种L1 范数通道权重的绝对值之和、L2 范数平方和开根号、BN 缩放因子如果网络里有 BN 层缩放因子接近零的通道通常可以剪掉、泰勒展开用一阶泰勒近似删除该通道对 loss 的影响。L1/L2 范数实现简单效果也还行是最常用的 baseline。BN 缩放因子的方法在带 BN 的网络里效果很好因为 BN 的缩放因子本身就在训练中学会了调节各通道的贡献。评估完重要性之后按分数排序剪掉最低的那部分。但剪完之后一定要微调通常用原模型的学习率的三分之一到十分之一跑几个 epoch 就能恢复大部分精度。微调时最好冻结被剪层的前一层避免梯度把已经剪掉的结构又“长”回来。4.2 蒸馏温度与损失权重的调参经验蒸馏的损失函数通常是两部分加权一部分是学生输出和教师软标签的 KL 散度另一部分是学生输出和真实硬标签的交叉熵。权重怎么设我的经验是软标签损失占主导硬标签损失作为辅助比例大概 7:3 到 9:1。温度参数一般从 3 到 5 开始试太高会让分布过于平滑学生学不到有区分度的信息太低又接近硬标签失去蒸馏的意义。还有一个容易被忽略的点教师模型的质量决定蒸馏上限。如果教师模型本身就不够好学生再怎么学也超不过它。所以蒸馏之前要确保教师模型已经调到最优状态。4.3 剪枝、量化、蒸馏的组合顺序这三者可以组合但顺序会影响最终效果。我推荐的顺序是先蒸馏得到小模型再剪枝进一步压缩最后量化。原因是蒸馏需要教师模型的完整信息如果先剪枝或量化教师模型的信息就受损了。剪枝放在蒸馏之后是因为小模型的结构已经确定剪枝的目标更明确。量化放最后是因为量化对结构不敏感但对数值敏感放在最后可以针对最终结构做精细校准。当然这不是铁律。如果算力有限也可以先量化再剪枝但要注意量化后的模型剪枝时重要性评估要在量化域里做不能再用 FP32 的权重范数。5. 图优化与推理引擎让模型在目标硬件上真正跑快模型压缩完了不代表就能跑得快。计算图的组织方式、算子的实现质量、内存的分配策略都会影响最终延迟。这一章讲图优化和推理引擎层面的实操。5.1 算子融合的触发条件与验证方法算子融合是最常见的图优化。以 Conv-BN-ReLU 为例推理阶段 BN 的参数是固定的可以把它折叠进卷积的权重和偏置里这样三个算子就变成一个卷积。融合之后中间结果不需要写回内存再读出来省了两次内存访问延迟能降不少。但融合有触发条件。框架需要能识别出“Conv 后面紧跟着 BNBN 后面紧跟着 ReLU”这种模式。如果你的模型在导出时把 BN 拆成了多个算子或者中间插了别的操作融合就不会发生。验证方法是导出模型后用推理引擎的图可视化工具看一下数一数实际执行的算子数量和融合前的对比。如果数量没变说明融合没生效需要检查导出配置。5.2 内存复用与动态形状的处理内存复用是指让生命周期不重叠的张量共享同一块内存。推理引擎通常会自动做这件事但在动态形状场景下会变得复杂。动态形状意味着每次推理的输入尺寸可能不同内存分配无法提前确定引擎可能每次都要重新分配带来额外开销。处理动态形状的常见做法是如果实际业务中输入尺寸变化范围有限可以把它固定成几个典型尺寸分别编译出对应的执行计划运行时根据输入选择最接近的计划。如果尺寸变化确实很大就要接受一定的性能损失或者选择对动态形状支持更好的引擎。5.3 不同推理引擎的选型对比选推理引擎不能只看跑分要结合目标硬件、模型类型、团队熟悉度来综合判断。下面这张表是我根据实际项目经验整理的对比供参考。引擎优势硬件量化支持动态形状上手难度ONNX RuntimeCPU/多平台INT8/FP16较好低TensorRTNVIDIA GPUINT8/FP16/INT4一般中OpenVINOIntel CPU/VPUINT8/FP16较好中TFLite移动端/边缘INT8/FP16一般低选型时还要考虑算子覆盖率。有些引擎对某些算子不支持会回退到 CPU 执行反而更慢。上线前一定要做端到端的性能测试不能只看单个算子的 benchmark。6. 优化效果的度量与回归验证别让优化变成“负优化”优化做完怎么证明它真的有效这一章讲度量方法和回归验证流程。6.1 延迟、吞吐、内存的测量规范延迟测量要区分单次延迟和端到端延迟。单次延迟是模型推理本身的时间端到端延迟还包括预处理、后处理、数据传输。很多优化只关注前者结果上线后发现端到端没快多少因为瓶颈在预处理上。测量时要控制变量同一个硬件、同一个输入尺寸、同一个 batch size、同一个预热次数。预热很重要第一次推理通常包含初始化开销不能算进去。一般预热 10 到 20 次然后取 100 次以上的平均值和 P99 值。P99 比平均值更能反映真实体验因为用户感受到的卡顿往往来自长尾延迟。内存测量要区分峰值内存和常驻内存。峰值内存决定你能不能跑起来常驻内存决定你能同时跑几个实例。6.2 精度回归的自动化流程优化后的模型必须经过完整的精度回归不能只跑几个样例就上线。自动化流程应该包括固定测试集、逐样本对比优化前后的输出、统计精度指标、标记翻转样本、生成对比报告。如果团队有 CI/CD 流程最好把精度回归做成一个 gate精度下降超过阈值就阻断发布。翻转样本的分析特别有价值。我通常会按类别、按输入尺寸、按亮度等维度对翻转样本做分组统计看看是否有系统性偏差。如果翻转集中在某个类别可能是该类别的校准数据不足如果集中在某种尺寸可能是动态形状处理有问题。6.3 线上灰度与回滚策略再充分的离线验证也不能完全替代线上验证。上线时一定要走灰度先放小流量对比优化模型和原模型的业务指标比如点击率、转化率、用户停留时长。如果业务指标没有下降再逐步放大流量。同时要准备好回滚方案一旦发现异常能快速切回原模型。灰度期间要重点监控延迟的 P99 和错误率。有些问题在离线测试中不会暴露比如特定输入触发了某个不支持量化的算子路径导致延迟飙升。这种只有真实流量才能发现。7. 我在模型优化项目里踩过的几个真实坑最后分享几个具体案例都是我在实际项目里踩过的希望能帮你少走弯路。第一个坑是校准集和测试集分布不一致。有一次做量化校准集用的是白天场景的图片测试集里混了夜间图片结果夜间样本的量化误差特别大精度掉了将近 5 个点。后来把校准集换成白天夜间混合精度恢复到只掉 0.8%。这件事让我养成了一个习惯校准集一定要覆盖所有已知的场景维度。第二个坑是剪枝后没有充分微调。有一次剪枝率设得比较激进剪完直接评估精度掉得惨不忍睹我以为方案失败了。后来老老实实微调了 10 个 epoch精度恢复了 90% 以上。剪枝本质上是对模型做了一次“手术”术后恢复期不能省。第三个坑是忽略了预处理的一致性。量化工具在统计激活范围时用的预处理必须和推理时完全一致。我有一次在校准时用了 BGR 通道顺序推理时用的是 RGB结果量化参数完全对不上精度直接崩了。这种低级错误听起来不可思议但在赶工期的时候真的会发生。第四个坑是过度追求压缩率。有一段时间我沉迷于把模型压到极致量化加剪枝加蒸馏全上模型体积降到了原来的十分之一但精度掉了 8 个点业务方根本不接受。后来退回到只做量化体积降到四分之一精度只掉 0.5%反而顺利上线了。优化的目标是“够用就好”不是“越极致越好”。这些经验归结成一句话模型优化是一个权衡的艺术不是单纯的技术堆叠。每次做决策之前先问清楚业务能接受的精度下限是多少、延迟上限是多少、硬件约束是什么然后再选技术路线。脱离约束谈优化都是纸上谈兵。
Model-Optimizer实战：量化、剪枝、蒸馏与图优化全链路解析
1. 从“模型优化器”这个热词说起它到底在解决什么问题“Model-Optimizer”这个词最近在技术圈被反复提起很多人第一次看到会以为它只是某个训练脚本里的一个类名比如 PyTorch 里的torch.optim.Adam。但真正在工程一线待过的人都知道当大家把“Model-Optimizer”当作一个独立话题来讨论时它指的往往不是那个优化算法本身而是一整套围绕模型做“减负、提速、省资源”的工程化手段集合。换句话说它关心的不是“怎么把 loss 降下去”而是“模型已经训好了怎么让它跑得更快、占得更少、上得了更小的设备”。我最早接触这类需求是在一个把视觉模型往边缘设备上搬的项目里。训练环境里跑得好好的模型一到目标硬件上就卡得没法看推理一帧要几百毫秒内存直接爆掉。那时候我才意识到训练阶段的优化器和部署阶段的“模型优化”完全是两码事。前者调的是参数更新策略后者调的是模型结构、数值精度、算子实现和内存布局。Model-Optimizer 这个标题背后真正有价值的部分是后者——它是一套让模型“落地”的工程方法论。这篇文章适合三类人看第一类是做模型部署、被推理性能折磨过的工程师第二类是想了解模型压缩、量化、图优化这些概念但不知道从哪下手的学生或转行者第三类是做算法但需要和工程团队对接、想知道自己交出去的模型会被怎么“改造”的研究人员。我会尽量把每个技术点讲透告诉你为什么这么做、怎么做、做完之后怎么验证以及我在实操中踩过的那些坑。需要先明确一个边界Model-Optimizer 不是某一个具体工具的名字而是一个领域统称。市面上有大量工具和框架在做这件事比如 ONNX Runtime 的图优化、TensorRT 的层融合、各种量化工具链、剪枝库等等。我不会绑定某一个具体产品而是把这类工具背后的通用逻辑拆开讲这样你换任何一套工具都能对上号。2. 模型优化的四条主线量化、剪枝、蒸馏与图优化在动手之前得先搞清楚模型优化到底有哪几条路可以走。很多人一上来就问“怎么把模型变小”但“变小”其实有好几种不同的含义可能是参数数量变少可能是数值精度降低可能是计算图被合并简化也可能是运行时内存占用下降。不同的目标对应不同的技术路线选错了方向后面全是白费功夫。2.1 量化把浮点数换成低比特整数量化是这四条线里性价比最高、落地最广的一种。它的核心思想很朴素神经网络里的权重和激活值原本用 32 位浮点数FP32存储和计算但很多场景下根本不需要这么高的精度用 8 位整数INT8甚至更低就能跑出几乎一样的结果。一个 FP32 权重占 4 字节换成 INT8 只占 1 字节模型体积直接降到四分之一同时整数运算在多数硬件上比浮点运算快得多。量化分两大类训练后量化Post-Training Quantization, PTQ和量化感知训练Quantization-Aware Training, QAT。PTQ 是模型已经训好了直接拿一批校准数据跑一遍统计每层激活值的分布范围然后算出量化参数scale 和 zero-point把权重和激活映射到整数区间。它的优点是快几十分钟就能搞定不需要重新训练。缺点是精度损失不可控遇到对数值敏感的层比如某些注意力结构可能掉点明显。QAT 则是在训练阶段就模拟量化的舍入误差让模型提前“适应”低精度。具体做法是在前向传播里插入伪量化节点把权重和激活先量化再反量化这样梯度还是能正常回传模型会学着在量化噪声下保持精度。QAT 效果通常比 PTQ 好但代价是要重新训练时间和算力成本高不少。我个人的经验是先试 PTQ掉点在接受范围内就用它如果 PTQ 掉点超过阈值再考虑 QAT。校准数据的选取非常关键它必须能代表真实推理时的输入分布。我见过有人拿训练集里随机抽的几百张图做校准结果上线后遇到分布外的输入量化误差直接爆炸。校准集最好从验证集里按类别均衡采样数量不用多几百到一千条通常够用但分布一定要对。2.2 剪枝去掉不重要的连接和通道剪枝的思路是神经网络里存在大量冗余参数把不重要的那些去掉模型照样能跑。剪枝分非结构化剪枝和结构化剪枝。非结构化剪枝是把单个权重置零理论上压缩率高但产生的稀疏矩阵在通用硬件上很难加速除非你有专门支持稀疏计算的加速器。结构化剪枝则是按通道、按层、按注意力头来剪剪完之后模型结构是规整的普通硬件就能直接受益。结构化剪枝的典型流程是先训练一个稠密模型然后根据某种重要性指标比如通道的 L1/L2 范数、BN 层的缩放因子、梯度大小给每个通道打分把分数低的通道连同对应的卷积核一起删掉最后再微调恢复精度。这里有个容易踩的坑剪枝率不能一刀切。有些层对精度极其敏感剪一点点就崩有些层冗余度很高剪掉一半都没事。比较稳妥的做法是逐层做敏感性分析给每层设不同的剪枝率而不是全局统一。2.3 蒸馏让小模型学大模型的“软标签”知识蒸馏是另一条路不直接压缩原模型而是训练一个结构更小的学生模型让它去模仿大模型教师模型的输出。关键在于学生模型学的不是硬标签比如分类任务里的 one-hot而是教师模型输出的概率分布也就是“软标签”。软标签里包含了类别之间的相对关系信息比如“这张图是猫的概率 0.8是狗的概率 0.15”这种信息比单纯的“这是猫”要丰富得多学生模型能学到更好的决策边界。蒸馏的难点在于温度参数和损失权重的调节。温度高的时候软标签更平滑类别间关系信息更充分温度低的时候接近硬标签。通常会在训练初期用较高温度后期降下来。另外教师模型和学生模型的容量差距不能太大差太多学生学不动差太少又没压缩效果。2.4 图优化在计算图层面做等价变换图优化不改变模型的数学等价性而是通过合并算子、消除冗余、重排计算顺序来提速。常见的操作包括算子融合把卷积、BN、ReLU 合并成一个算子减少内存读写、常量折叠把编译期就能算出来的子图提前算好、死代码消除去掉不影响输出的节点、内存复用让不同张量共享同一块内存。这些优化通常由推理框架自动完成比如 ONNX Runtime 和 TensorRT 都有内置的图优化 pass。你不需要手写这些变换但需要知道它们存在并且在导出模型时保留足够的信息让框架能识别出可融合的模式。这四条线不是互斥的实际项目里经常组合使用。比如先剪枝得到一个更小的模型再量化进一步压缩最后用图优化把推理图整理干净。但组合的顺序有讲究后面会细说。3. 量化实操从校准集准备到精度验证的完整链路量化是大多数人第一个会尝试的优化手段因为它见效快、工具成熟。但“跑通”和“跑好”之间差距很大。这一章我把量化的完整链路拆开每一步都讲清楚为什么这么做。3.1 校准集怎么选才算“有代表性”校准集的唯一作用是统计激活值的动态范围从而确定量化参数。它不需要标签但必须覆盖真实推理时可能出现的输入分布。我见过太多人随便拿几十张图就开跑结果量化后模型在特定类别上精度暴跌。一个可靠的做法是从验证集里按类别分层采样每个类别抽相同数量的样本总数控制在 500 到 1000 之间。如果任务没有明确类别比如检测、分割就按场景或数据来源分层。校准集的数量不是越多越好超过一定量后收益递减但分布覆盖度一定要够。另外校准集要经过和推理时完全一致的预处理包括归一化、resize、通道顺序等任何不一致都会导致统计偏差。提示如果你的模型有多个输入分支比如多模态每个分支都要有对应的校准数据不能只校准主分支。3.2 逐层敏感度分析找出不能量化的“刺头”不是所有层都适合量化。有些层对数值精度极其敏感强行量化会导致整体精度崩塌。逐层敏感度分析的做法是每次只把一层保持 FP32其余层量化观察精度变化。如果某层保持 FP32 后精度明显回升说明这层就是敏感层应该在最终量化方案里把它排除。这个分析过程比较耗时因为要跑多次评估。但它是值得的尤其是当 PTQ 掉点严重时敏感度分析能帮你快速定位问题层。常见的敏感层包括网络的第一层和最后一层、某些归一化层、以及输出 logits 的层。很多量化工具支持配置“排除层”列表把敏感层加进去就行。3.3 量化精度验证不能只看一个指标量化后的验证不能只看 top-1 准确率。对于分类任务至少要看 top-1 和 top-5对于检测任务要看 mAP 以及不同 IoU 阈值下的表现对于分割任务要看 mIoU 和逐类 IoU。更重要的是要对比量化前后在同一批测试数据上的逐样本差异找出那些量化后预测翻转的样本分析它们有什么共性。如果翻转样本集中在某些类别或某些场景说明量化方案在这些方向上还有问题。我通常会做一个“精度-体积-延迟”的三方对比表把 FP32 原模型、PTQ 模型、QAT 模型的指标放在一起看。有时候 PTQ 精度只掉 0.5%但延迟降了一半这种就非常划算有时候精度掉 2% 但延迟只降了 10%那就得重新考虑是否值得。方案模型体积推理延迟Top-1 精度是否需重训FP32 原模型100%100%基准否PTQ INT8约 25%约 40%-60%可能掉 0.5%-3%否QAT INT8约 25%约 40%-60%通常掉 0.1%-0.5%是3.4 量化踩坑实录那些文档里不会写的问题第一个坑是算子不支持。不是所有算子都有量化实现遇到不支持的算子工具链可能会回退到 FP32导致实际加速比远低于预期。解决办法是提前查清楚目标推理框架支持哪些量化算子必要时替换模型结构。第二个坑是per-tensor 和 per-channel 的选择。权重量化通常用 per-channel因为不同通道的数值范围差异很大per-channel 能更精细地拟合激活量化通常用 per-tensor因为激活值是动态的per-channel 统计成本太高。搞反了会导致精度明显下降。第三个坑是量化后的模型在不同硬件上表现不一致。同样是 INT8不同芯片的指令集和累加器位宽不同有的用 INT32 累加有的用 INT16这会影响最终精度。所以量化验证一定要在目标硬件上做不能只在开发机上跑。4. 剪枝与蒸馏的工程落地什么时候该用哪一招量化的热度最高但剪枝和蒸馏在特定场景下不可替代。这一章讲清楚它们的适用边界和实操要点。4.1 结构化剪枝的通道重要性评估方法结构化剪枝的核心是“怎么判断一个通道重不重要”。常用的指标有几种L1 范数通道权重的绝对值之和、L2 范数平方和开根号、BN 缩放因子如果网络里有 BN 层缩放因子接近零的通道通常可以剪掉、泰勒展开用一阶泰勒近似删除该通道对 loss 的影响。L1/L2 范数实现简单效果也还行是最常用的 baseline。BN 缩放因子的方法在带 BN 的网络里效果很好因为 BN 的缩放因子本身就在训练中学会了调节各通道的贡献。评估完重要性之后按分数排序剪掉最低的那部分。但剪完之后一定要微调通常用原模型的学习率的三分之一到十分之一跑几个 epoch 就能恢复大部分精度。微调时最好冻结被剪层的前一层避免梯度把已经剪掉的结构又“长”回来。4.2 蒸馏温度与损失权重的调参经验蒸馏的损失函数通常是两部分加权一部分是学生输出和教师软标签的 KL 散度另一部分是学生输出和真实硬标签的交叉熵。权重怎么设我的经验是软标签损失占主导硬标签损失作为辅助比例大概 7:3 到 9:1。温度参数一般从 3 到 5 开始试太高会让分布过于平滑学生学不到有区分度的信息太低又接近硬标签失去蒸馏的意义。还有一个容易被忽略的点教师模型的质量决定蒸馏上限。如果教师模型本身就不够好学生再怎么学也超不过它。所以蒸馏之前要确保教师模型已经调到最优状态。4.3 剪枝、量化、蒸馏的组合顺序这三者可以组合但顺序会影响最终效果。我推荐的顺序是先蒸馏得到小模型再剪枝进一步压缩最后量化。原因是蒸馏需要教师模型的完整信息如果先剪枝或量化教师模型的信息就受损了。剪枝放在蒸馏之后是因为小模型的结构已经确定剪枝的目标更明确。量化放最后是因为量化对结构不敏感但对数值敏感放在最后可以针对最终结构做精细校准。当然这不是铁律。如果算力有限也可以先量化再剪枝但要注意量化后的模型剪枝时重要性评估要在量化域里做不能再用 FP32 的权重范数。5. 图优化与推理引擎让模型在目标硬件上真正跑快模型压缩完了不代表就能跑得快。计算图的组织方式、算子的实现质量、内存的分配策略都会影响最终延迟。这一章讲图优化和推理引擎层面的实操。5.1 算子融合的触发条件与验证方法算子融合是最常见的图优化。以 Conv-BN-ReLU 为例推理阶段 BN 的参数是固定的可以把它折叠进卷积的权重和偏置里这样三个算子就变成一个卷积。融合之后中间结果不需要写回内存再读出来省了两次内存访问延迟能降不少。但融合有触发条件。框架需要能识别出“Conv 后面紧跟着 BNBN 后面紧跟着 ReLU”这种模式。如果你的模型在导出时把 BN 拆成了多个算子或者中间插了别的操作融合就不会发生。验证方法是导出模型后用推理引擎的图可视化工具看一下数一数实际执行的算子数量和融合前的对比。如果数量没变说明融合没生效需要检查导出配置。5.2 内存复用与动态形状的处理内存复用是指让生命周期不重叠的张量共享同一块内存。推理引擎通常会自动做这件事但在动态形状场景下会变得复杂。动态形状意味着每次推理的输入尺寸可能不同内存分配无法提前确定引擎可能每次都要重新分配带来额外开销。处理动态形状的常见做法是如果实际业务中输入尺寸变化范围有限可以把它固定成几个典型尺寸分别编译出对应的执行计划运行时根据输入选择最接近的计划。如果尺寸变化确实很大就要接受一定的性能损失或者选择对动态形状支持更好的引擎。5.3 不同推理引擎的选型对比选推理引擎不能只看跑分要结合目标硬件、模型类型、团队熟悉度来综合判断。下面这张表是我根据实际项目经验整理的对比供参考。引擎优势硬件量化支持动态形状上手难度ONNX RuntimeCPU/多平台INT8/FP16较好低TensorRTNVIDIA GPUINT8/FP16/INT4一般中OpenVINOIntel CPU/VPUINT8/FP16较好中TFLite移动端/边缘INT8/FP16一般低选型时还要考虑算子覆盖率。有些引擎对某些算子不支持会回退到 CPU 执行反而更慢。上线前一定要做端到端的性能测试不能只看单个算子的 benchmark。6. 优化效果的度量与回归验证别让优化变成“负优化”优化做完怎么证明它真的有效这一章讲度量方法和回归验证流程。6.1 延迟、吞吐、内存的测量规范延迟测量要区分单次延迟和端到端延迟。单次延迟是模型推理本身的时间端到端延迟还包括预处理、后处理、数据传输。很多优化只关注前者结果上线后发现端到端没快多少因为瓶颈在预处理上。测量时要控制变量同一个硬件、同一个输入尺寸、同一个 batch size、同一个预热次数。预热很重要第一次推理通常包含初始化开销不能算进去。一般预热 10 到 20 次然后取 100 次以上的平均值和 P99 值。P99 比平均值更能反映真实体验因为用户感受到的卡顿往往来自长尾延迟。内存测量要区分峰值内存和常驻内存。峰值内存决定你能不能跑起来常驻内存决定你能同时跑几个实例。6.2 精度回归的自动化流程优化后的模型必须经过完整的精度回归不能只跑几个样例就上线。自动化流程应该包括固定测试集、逐样本对比优化前后的输出、统计精度指标、标记翻转样本、生成对比报告。如果团队有 CI/CD 流程最好把精度回归做成一个 gate精度下降超过阈值就阻断发布。翻转样本的分析特别有价值。我通常会按类别、按输入尺寸、按亮度等维度对翻转样本做分组统计看看是否有系统性偏差。如果翻转集中在某个类别可能是该类别的校准数据不足如果集中在某种尺寸可能是动态形状处理有问题。6.3 线上灰度与回滚策略再充分的离线验证也不能完全替代线上验证。上线时一定要走灰度先放小流量对比优化模型和原模型的业务指标比如点击率、转化率、用户停留时长。如果业务指标没有下降再逐步放大流量。同时要准备好回滚方案一旦发现异常能快速切回原模型。灰度期间要重点监控延迟的 P99 和错误率。有些问题在离线测试中不会暴露比如特定输入触发了某个不支持量化的算子路径导致延迟飙升。这种只有真实流量才能发现。7. 我在模型优化项目里踩过的几个真实坑最后分享几个具体案例都是我在实际项目里踩过的希望能帮你少走弯路。第一个坑是校准集和测试集分布不一致。有一次做量化校准集用的是白天场景的图片测试集里混了夜间图片结果夜间样本的量化误差特别大精度掉了将近 5 个点。后来把校准集换成白天夜间混合精度恢复到只掉 0.8%。这件事让我养成了一个习惯校准集一定要覆盖所有已知的场景维度。第二个坑是剪枝后没有充分微调。有一次剪枝率设得比较激进剪完直接评估精度掉得惨不忍睹我以为方案失败了。后来老老实实微调了 10 个 epoch精度恢复了 90% 以上。剪枝本质上是对模型做了一次“手术”术后恢复期不能省。第三个坑是忽略了预处理的一致性。量化工具在统计激活范围时用的预处理必须和推理时完全一致。我有一次在校准时用了 BGR 通道顺序推理时用的是 RGB结果量化参数完全对不上精度直接崩了。这种低级错误听起来不可思议但在赶工期的时候真的会发生。第四个坑是过度追求压缩率。有一段时间我沉迷于把模型压到极致量化加剪枝加蒸馏全上模型体积降到了原来的十分之一但精度掉了 8 个点业务方根本不接受。后来退回到只做量化体积降到四分之一精度只掉 0.5%反而顺利上线了。优化的目标是“够用就好”不是“越极致越好”。这些经验归结成一句话模型优化是一个权衡的艺术不是单纯的技术堆叠。每次做决策之前先问清楚业务能接受的精度下限是多少、延迟上限是多少、硬件约束是什么然后再选技术路线。脱离约束谈优化都是纸上谈兵。
