1. 从模型能跑到模型跑得省Model-Optimizer 到底在解决什么做模型部署的人迟早会撞上一堵墙训练时一切正常指标也漂亮可一旦要上线推理延迟、显存占用、单位算力成本这三座大山就压过来了。我最早接触这类工具是在一个视觉检测项目上当时一个骨干网络在服务器上跑得好好的换到边缘设备直接爆显存帧率掉到个位数。那时候我的第一反应是换更小的模型但精度掉得没法看。后来才意识到问题不在于模型大而在于模型没有被优化过——权重里大量冗余、算子没有被融合、精度没有被合理压缩。Model-Optimizer 这类工具要干的事就是把一个能跑的模型变成一个跑得省、跑得快、精度还能守住的模型。先把概念说清楚。Model-Optimizer 不是某一个具体算法而是一整套围绕模型推理效率做文章的技术集合核心目标是在可接受的精度损失范围内降低模型的计算量、参数量、内存占用和推理延迟。它覆盖的手段大致分几类量化把 FP32 压成 INT8 甚至更低、剪枝去掉不重要的权重或通道、知识蒸馏用大模型教小模型、算子融合与图优化把多个算子合并成一个更高效的实现、以及针对特定硬件的编译优化。这几类手段不是互斥的实际项目里往往是组合拳。那它适合谁我给个判断标准。如果你只是做学术实验、跑跑 benchmark对推理成本不敏感那 Model-Optimizer 对你价值有限。但只要你满足下面任意一条它就值得你花时间模型要部署到资源受限的设备上手机、嵌入式、边缘盒子线上服务 QPS 高、GPU 成本压得紧模型大到单卡放不下需要做内存优化或者你需要在延迟和精度之间做精细的权衡。说白了凡是模型要真刀真枪跑起来并且要算成本账的场景都是它的主场。这里有个很多人一开始就搞错的认知优化不是训练完之后的收尾工作而应该从训练阶段就开始布局。比如量化感知训练QAT需要在训练时插入伪量化节点让模型提前适应低精度结构化剪枝需要在训练时加稀疏约束。如果你等模型训练完了才想起来优化很多手段的效果会大打折扣甚至只能退而求其次用训练后量化PTQ。这个顺序问题后面我会专门展开讲。还有一个容易被忽略的点优化的目标不是单一的。有人只盯着模型体积有人只盯着延迟但真实场景里往往是多目标约束。比如精度下降不超过 1%延迟降低 40%显存占用减半这是一个带约束的优化问题而不是单纯追求某个指标极致。理解这一点你才不会在某个指标上钻牛角尖导致整体方案失衡。2. 量化收益最直接但坑也最密集的一环2.1 为什么量化是性价比最高的起点如果只能选一种优化手段我大概率会选量化。原因很实在它带来的收益立竿见影实现成本相对可控而且对绝大多数模型都适用。量化的本质是把高比特的浮点数用低比特的整数来近似表示。以最常见的 FP32 转 INT8 为例一个权重从 32 位降到 8 位理论存储直接变成原来的四分之一同时整数运算在多数硬件上比浮点运算快得多内存带宽压力也大幅下降。但量化不是简单地把数字除以一个系数就完事。它需要一个映射关系把浮点区间 [min, max] 线性映射到整数区间比如 INT8 的 [-128, 127]。这个映射靠两个参数描述——scale缩放因子和 zero_point零点偏移。反量化的时候用这两个参数还原。听起来简单难点在于不同层、不同通道的数值分布差异巨大用一套全局参数去映射精度必然崩。所以实际做法是分层量化甚至分通道量化per-channel让每一层有自己的 scale 和 zero_point。我见过太多人第一次做量化直接拿一个训练好的模型套上 PTQ跑完发现精度掉了十几个点然后得出结论量化不靠谱。问题不在量化本身而在于没有做校准calibration。PTQ 需要一个校准数据集来统计各层的激活值分布从而确定合理的映射范围。校准集不用很大几百到上千个样本通常够用但必须和真实推理数据的分布接近。如果你拿训练集里随机抽的样本去校准而线上数据分布完全不同那量化误差会非常大。2.2 PTQ 和 QAT 的取舍逻辑训练后量化PTQ和量化感知训练QAT是两条路线选择哪条取决于你对精度的容忍度和可投入的资源。PTQ 的流程是训练好的 FP32 模型 → 插入观测节点统计分布 → 计算量化参数 → 转换成量化模型。它的优点是快几十分钟到几小时就能搞定不需要重新训练。缺点是精度损失不可控对于数值分布复杂、对精度敏感的模型比如检测、分割、生成类掉点可能很严重。QAT 则是在训练阶段就模拟量化误差前向传播时插入伪量化节点让权重和激活在训练过程中感受到量化带来的精度损失反向传播时用直通估计器STE绕过不可导的量化操作。这样训练出来的模型对量化更鲁棒最终精度通常明显优于 PTQ。代价是要重新训练算力成本高调参也更麻烦。我的经验判断是分类任务、大模型、对精度不敏感的场合先试 PTQ能接受就用省时省力。检测、分割、关键点、语音这类对数值敏感的模型或者 PTQ 掉点超过阈值时直接上 QAT。还有一个折中方案叫部分量化——只量化对精度不敏感的层比如大部分卷积层保留少数敏感层比如第一层、最后一层、某些特殊算子用浮点这样能在精度和收益之间找到平衡。2.3 量化实操中最容易翻车的几个点第一个坑是激活值的离群点。某些层的激活值会出现极少数特别大的值如果按 min-max 映射这些离群点会把整个量化区间撑大导致大部分正常值被压缩到很窄的整数范围里精度骤降。解决办法是用 KL 散度、百分位数比如取 99.9% 分位等方法来截断牺牲极少数离群点换取整体精度。这个细节在文档里往往一笔带过但实际影响巨大。第二个坑是算子不支持。不是所有算子都能被量化工具正确处理尤其是一些自定义算子、动态 shape 算子、复杂的注意力结构。遇到不支持的算子工具通常会回退到浮点这本身没问题但如果回退的算子处在计算热点上量化收益就被吃掉了。所以量化前一定要先看工具支持的算子列表评估模型里有多少算子会被回退。第三个坑是校准数据的代表性。前面提过这里再强调一次校准集要覆盖真实场景的各种情况包括边界情况。我做过一个项目校准集里全是白天的图像结果夜间图像上线后量化误差爆炸。后来把夜间样本补进校准集问题才解决。第四个坑是量化后的精度评估方式。不能只看整体指标要看分层、分类别的指标。有时候整体精度只掉了 0.5%但某个关键类别掉了 5%这种问题在整体指标里被平均掉了上线后才发现某个场景不可用。建议量化前后做详细的 per-class 对比。3. 剪枝与蒸馏把冗余真正挤出去3.1 结构化剪枝和非结构化剪枝的本质区别剪枝的思路很直观神经网络里大量权重是冗余的去掉它们对精度影响很小。但去掉的方式不同效果天差地别。非结构化剪枝是把单个权重置零产生稀疏矩阵。理论上压缩率可以很高但问题是通用硬件对稀疏矩阵的加速支持很差除非你用专门的稀疏计算库或硬件否则这些零值照样占内存、照样参与计算实际收益几乎为零。我早期踩过这个坑剪了 70% 的权重模型文件是小了但推理速度一点没变因为稠密计算库根本不认这些零。结构化剪枝则是以更大的粒度操作——剪掉整个通道、整个卷积核、整个注意力头。这样剪完之后模型结构是真的变小了不需要特殊硬件支持就能获得实际加速。代价是同样的压缩率下结构化剪枝对精度的伤害通常比非结构化大因为它一刀切掉的是整组参数灵活性差。实际项目里除非你有明确的稀疏硬件支持否则优先选结构化剪枝。判断标准很简单剪完之后模型能不能在目标硬件上真的跑快。跑不快压缩率再高也是自欺欺人。3.2 剪枝的粒度选择与敏感度分析剪枝不是拍脑袋决定剪哪里。正规做法是先做敏感度分析sensitivity analysis逐层尝试剪掉一定比例观察精度变化找出对剪枝敏感的层和不敏感的层。不敏感的层可以多剪敏感的层少剪甚至不剪。粒度上从细到粗有几种单个权重、通道、卷积核、层。粒度越粗加速越明显但精度损失越大。实践中常用的是通道级剪枝因为它在加速和精度之间比较平衡而且大多数推理框架都能正确处理通道数变化的模型。剪枝的流程一般是迭代式的剪一部分 → 微调恢复精度 → 再剪一部分 → 再微调。一次性剪太多模型直接崩掉微调也救不回来。这个剪-调循环的节奏很关键我通常从 10% 的剪枝率开始每次增加 5% 到 10%观察精度曲线找到拐点。3.3 知识蒸馏在优化链路里的位置知识蒸馏严格来说不算压缩它是用一个大模型教师的输出指导一个小模型学生训练让小模型学到教师模型的暗知识。它的价值在于当你需要一个结构本身就小的模型而不是把大模型压小的时候蒸馏是首选。蒸馏的关键在于软标签。教师模型输出的概率分布里包含了类别之间的相似性信息比如一张猫的图片教师可能给出猫 0.9、狗 0.08、其他 0.02这个 0.08 就告诉学生猫和狗有点像这是硬标签one-hot给不了的信息。温度参数 T 用来控制软标签的平滑程度T 越大分布越平滑暗知识越丰富但也不能太大否则噪声也放大。蒸馏和量化、剪枝可以叠加使用。一个典型链路是先用蒸馏训练一个小模型再对小模型做剪枝最后量化。每一环都贡献一部分压缩和加速组合起来效果很可观。但要注意叠加的误差也会累积每一环都要单独验证精度不能等到最后一起看。4. 图优化与算子融合不改变数值的免费加速4.1 算子融合为什么能白捡性能前面讲的量化和剪枝都会改变模型数值需要小心处理精度。而图优化和算子融合是另一类手段——它们不改变计算结果只是让计算过程更高效属于免费加速。最典型的例子是 Conv BN ReLU 的融合。在推理阶段BN 层的参数是固定的可以数学上折叠进前面的卷积权重里ReLU 则可以直接融进卷积的输出激活。融合之后原本三次内存读写变成一次中间结果不用落盘内存带宽和 kernel 启动开销都省了。这类融合在推理框架里通常是自动做的但前提是你的模型图结构清晰、算子标准。如果你的模型里塞了一堆自定义算子或者奇怪的 reshape融合就可能失败。另一个常见的是矩阵乘加融合如 MatMul Add 融成 GEMM 的 beta 参数以及注意力机制里的 QKV 计算融合。这些融合对 Transformer 类模型收益尤其明显。4.2 常量折叠与死代码消除常量折叠是指把图中可以在编译期算出来的部分提前算掉。比如一个常量张量参与的加法没必要每次推理都算一遍直接折叠成一个新常量。死代码消除则是去掉那些输出没有被使用的节点——训练时可能有些辅助分支推理时用不到但图里还留着白白消耗计算。这两个优化听起来很基础但实际项目里经常能捡到不少收益尤其是那些从训练代码直接导出、没有清理过的模型。我见过一个模型导出后图里有近 20% 的节点是训练遗留的辅助计算清理掉之后延迟直接降了一截。4.3 布局转换与内存复用还有一个容易被忽视的优化点是张量布局layout。不同硬件对数据排布有偏好比如某些加速器喜欢 NHWC 而不是 NCHW。如果布局不匹配框架会在算子之间插入转置操作这些转置本身不产生任何有价值的计算纯粹是开销。图优化器会尽量把布局转换合并、消除或者选择整体一致的布局方案。内存复用则是让不同生命周期的中间张量共享同一块内存。推理时中间激活的峰值内存往往远大于模型本身通过分析张量的生命周期把不再需要的张量内存回收给后续张量用能显著降低峰值显存。这对大模型部署尤其关键。5. 一套可复现的优化流程与验证方法5.1 优化前的基线测量不能省我见过太多人一上来就开始量化、剪枝问他基线延迟多少、显存多少答不上来。没有基线你根本不知道优化有没有效果也不知道瓶颈在哪。所以第一步永远是建立基线在目标硬件、目标框架、目标 batch size 下测出模型的延迟、吞吐、显存占用、精度指标。这些数据要记录清楚作为后续每一步对比的参照。测量时要注意几个细节预热warmup要充分前几次推理往往包含初始化开销多次测量取稳定值不要只看一次区分纯推理时间和包含前后处理的时间优化的是哪部分要明确。还有延迟和吞吐是两回事batch size 小的时候看延迟batch size 大的时候看吞吐别混为一谈。5.2 优化顺序的决策逻辑优化手段的先后顺序有讲究。我的建议是先做不改变数值的图优化和算子融合再做量化最后考虑剪枝和蒸馏。理由是这样图优化零风险先拿到免费收益量化收益大、实现相对标准化是主力手段剪枝和蒸馏改动大、调参复杂放在后面作为补充。但这个顺序不是死的。如果模型大到根本跑不起来可能要先剪枝或蒸馏把规模降下来再做量化。如果目标硬件对某种精度有特殊支持比如 INT4那量化就要优先考虑。核心原则是先做风险低、收益高的把简单的收益拿到手再啃硬骨头。5.3 精度验证要做得比训练时更细优化后的精度验证标准要比训练时更严格。训练时看整体指标就够了优化后必须做细粒度对比per-class 精度、混淆矩阵变化、关键样本的预测差异、置信度分布变化。因为优化引入的误差往往不是均匀分布的它可能在某些类别、某些样本上集中爆发。我习惯的做法是准备一个固定的验证集优化前后各跑一遍逐样本对比预测结果把预测发生变化的样本挑出来人工看。如果变化的样本集中在某个类别或某种场景那就要针对性处理。这个方法帮我抓到过好几次整体指标正常但局部崩坏的问题。还有一个实用技巧是分层验证。把验证集按难度、场景、类别分组分别看每组的精度变化。有时候整体只掉 0.3%但某个困难子集掉了 8%这种问题只有分层看才能发现。6. 那些文档里不会写的实战教训6.1 优化工具的输出不等于最终部署形态很多人以为优化工具导出的模型就是最终部署的模型直接拿去上线。这是个误区。优化工具的输出通常是一个中间格式比如 ONNX还需要经过目标推理框架的转换、编译才能真正在硬件上跑。而这个转换过程可能引入新的问题算子不支持导致回退、精度在转换中丢失、图结构被改变导致融合失效。所以完整的验证链路应该是优化后模型 → 转成部署格式 → 在目标硬件上实测精度和性能。每一步都要验证不能跳步。我踩过的最坑的一次是量化模型在工具里验证精度正常转成部署格式后精度崩了排查半天发现是某个算子在转换时被错误处理了。6.2 精度和性能的权衡要量化不能凭感觉精度掉一点没关系速度提上来就行——这话说起来轻松但一点是多少提上来是多少没有量化就没有决策依据。我建议在项目开始就定好约束精度下降不超过 X%延迟降低至少 Y%显存不超过 Z。然后所有优化方案都拿这三个数字去卡达标就用不达标就调。这个约束最好和业务方一起定因为只有业务方知道精度掉多少是真正可接受的。技术人员容易陷入精度越高越好的执念但业务上可能 95% 和 96% 没区别而延迟从 100ms 降到 50ms 价值巨大。6.3 版本管理和可复现性优化过程涉及大量实验不同的量化配置、不同的剪枝率、不同的校准集。如果不做好版本管理很快就会乱套说不清哪个模型对应哪套配置。我的做法是每次实验记录完整的配置包括随机种子、对应的精度和性能数据、以及使用的工具版本。模型文件、配置文件、验证脚本一起归档。工具版本尤其重要。优化工具更新频繁不同版本的行为可能不同同一个配置在新版本上结果可能变化。生产环境要锁定版本升级前必须重新验证。6.4 别忽视端到端的整体优化模型优化只是端到端链路的一环。实际推理延迟里前后处理、数据搬运、框架调度可能占很大比例。我见过模型本身优化得很好但前后处理用了低效的 Python 实现整体延迟下不来。所以优化要有全局视角先 profile 整个链路找到真正的瓶颈再决定优化哪里。有时候优化前后处理比优化模型本身收益还大。7. 关于 Model-Optimizer 这类工具我个人的使用体会用了几年这类工具最大的体会是工具本身不难难的是判断力。知道什么时候该用量化、什么时候该剪枝、什么时候该收手这些判断来自对模型、对硬件、对业务的理解而不是工具文档能给的。工具能帮你执行但决策得你自己做。另一个体会是优化是一个迭代过程不是一次性的。模型在变、数据在变、硬件在变、业务需求在变优化方案也要跟着调整。把优化当成一个持续的工作流而不是项目末期的一个任务心态会好很多。最后分享一个我常用的检查习惯每次优化完除了看指标我一定会亲自跑几个真实样本看看输出是不是合理。指标是平均值真实样本能暴露平均值掩盖的问题。有好几次指标看着正常但实际输出明显不对劲靠人工看样本才发现。这个习惯看起来笨但很管用。 
长河君 · 2026/9/30 4:44:07 · 阅读 1.2k Model-Optimizer 实战：量化、剪枝与图优化加速模型推理
1. 从模型能跑到模型跑得省Model-Optimizer 到底在解决什么做模型部署的人迟早会撞上一堵墙训练时一切正常指标也漂亮可一旦要上线推理延迟、显存占用、单位算力成本这三座大山就压过来了。我最早接触这类工具是在一个视觉检测项目上当时一个骨干网络在服务器上跑得好好的换到边缘设备直接爆显存帧率掉到个位数。那时候我的第一反应是换更小的模型但精度掉得没法看。后来才意识到问题不在于模型大而在于模型没有被优化过——权重里大量冗余、算子没有被融合、精度没有被合理压缩。Model-Optimizer 这类工具要干的事就是把一个能跑的模型变成一个跑得省、跑得快、精度还能守住的模型。先把概念说清楚。Model-Optimizer 不是某一个具体算法而是一整套围绕模型推理效率做文章的技术集合核心目标是在可接受的精度损失范围内降低模型的计算量、参数量、内存占用和推理延迟。它覆盖的手段大致分几类量化把 FP32 压成 INT8 甚至更低、剪枝去掉不重要的权重或通道、知识蒸馏用大模型教小模型、算子融合与图优化把多个算子合并成一个更高效的实现、以及针对特定硬件的编译优化。这几类手段不是互斥的实际项目里往往是组合拳。那它适合谁我给个判断标准。如果你只是做学术实验、跑跑 benchmark对推理成本不敏感那 Model-Optimizer 对你价值有限。但只要你满足下面任意一条它就值得你花时间模型要部署到资源受限的设备上手机、嵌入式、边缘盒子线上服务 QPS 高、GPU 成本压得紧模型大到单卡放不下需要做内存优化或者你需要在延迟和精度之间做精细的权衡。说白了凡是模型要真刀真枪跑起来并且要算成本账的场景都是它的主场。这里有个很多人一开始就搞错的认知优化不是训练完之后的收尾工作而应该从训练阶段就开始布局。比如量化感知训练QAT需要在训练时插入伪量化节点让模型提前适应低精度结构化剪枝需要在训练时加稀疏约束。如果你等模型训练完了才想起来优化很多手段的效果会大打折扣甚至只能退而求其次用训练后量化PTQ。这个顺序问题后面我会专门展开讲。还有一个容易被忽略的点优化的目标不是单一的。有人只盯着模型体积有人只盯着延迟但真实场景里往往是多目标约束。比如精度下降不超过 1%延迟降低 40%显存占用减半这是一个带约束的优化问题而不是单纯追求某个指标极致。理解这一点你才不会在某个指标上钻牛角尖导致整体方案失衡。2. 量化收益最直接但坑也最密集的一环2.1 为什么量化是性价比最高的起点如果只能选一种优化手段我大概率会选量化。原因很实在它带来的收益立竿见影实现成本相对可控而且对绝大多数模型都适用。量化的本质是把高比特的浮点数用低比特的整数来近似表示。以最常见的 FP32 转 INT8 为例一个权重从 32 位降到 8 位理论存储直接变成原来的四分之一同时整数运算在多数硬件上比浮点运算快得多内存带宽压力也大幅下降。但量化不是简单地把数字除以一个系数就完事。它需要一个映射关系把浮点区间 [min, max] 线性映射到整数区间比如 INT8 的 [-128, 127]。这个映射靠两个参数描述——scale缩放因子和 zero_point零点偏移。反量化的时候用这两个参数还原。听起来简单难点在于不同层、不同通道的数值分布差异巨大用一套全局参数去映射精度必然崩。所以实际做法是分层量化甚至分通道量化per-channel让每一层有自己的 scale 和 zero_point。我见过太多人第一次做量化直接拿一个训练好的模型套上 PTQ跑完发现精度掉了十几个点然后得出结论量化不靠谱。问题不在量化本身而在于没有做校准calibration。PTQ 需要一个校准数据集来统计各层的激活值分布从而确定合理的映射范围。校准集不用很大几百到上千个样本通常够用但必须和真实推理数据的分布接近。如果你拿训练集里随机抽的样本去校准而线上数据分布完全不同那量化误差会非常大。2.2 PTQ 和 QAT 的取舍逻辑训练后量化PTQ和量化感知训练QAT是两条路线选择哪条取决于你对精度的容忍度和可投入的资源。PTQ 的流程是训练好的 FP32 模型 → 插入观测节点统计分布 → 计算量化参数 → 转换成量化模型。它的优点是快几十分钟到几小时就能搞定不需要重新训练。缺点是精度损失不可控对于数值分布复杂、对精度敏感的模型比如检测、分割、生成类掉点可能很严重。QAT 则是在训练阶段就模拟量化误差前向传播时插入伪量化节点让权重和激活在训练过程中感受到量化带来的精度损失反向传播时用直通估计器STE绕过不可导的量化操作。这样训练出来的模型对量化更鲁棒最终精度通常明显优于 PTQ。代价是要重新训练算力成本高调参也更麻烦。我的经验判断是分类任务、大模型、对精度不敏感的场合先试 PTQ能接受就用省时省力。检测、分割、关键点、语音这类对数值敏感的模型或者 PTQ 掉点超过阈值时直接上 QAT。还有一个折中方案叫部分量化——只量化对精度不敏感的层比如大部分卷积层保留少数敏感层比如第一层、最后一层、某些特殊算子用浮点这样能在精度和收益之间找到平衡。2.3 量化实操中最容易翻车的几个点第一个坑是激活值的离群点。某些层的激活值会出现极少数特别大的值如果按 min-max 映射这些离群点会把整个量化区间撑大导致大部分正常值被压缩到很窄的整数范围里精度骤降。解决办法是用 KL 散度、百分位数比如取 99.9% 分位等方法来截断牺牲极少数离群点换取整体精度。这个细节在文档里往往一笔带过但实际影响巨大。第二个坑是算子不支持。不是所有算子都能被量化工具正确处理尤其是一些自定义算子、动态 shape 算子、复杂的注意力结构。遇到不支持的算子工具通常会回退到浮点这本身没问题但如果回退的算子处在计算热点上量化收益就被吃掉了。所以量化前一定要先看工具支持的算子列表评估模型里有多少算子会被回退。第三个坑是校准数据的代表性。前面提过这里再强调一次校准集要覆盖真实场景的各种情况包括边界情况。我做过一个项目校准集里全是白天的图像结果夜间图像上线后量化误差爆炸。后来把夜间样本补进校准集问题才解决。第四个坑是量化后的精度评估方式。不能只看整体指标要看分层、分类别的指标。有时候整体精度只掉了 0.5%但某个关键类别掉了 5%这种问题在整体指标里被平均掉了上线后才发现某个场景不可用。建议量化前后做详细的 per-class 对比。3. 剪枝与蒸馏把冗余真正挤出去3.1 结构化剪枝和非结构化剪枝的本质区别剪枝的思路很直观神经网络里大量权重是冗余的去掉它们对精度影响很小。但去掉的方式不同效果天差地别。非结构化剪枝是把单个权重置零产生稀疏矩阵。理论上压缩率可以很高但问题是通用硬件对稀疏矩阵的加速支持很差除非你用专门的稀疏计算库或硬件否则这些零值照样占内存、照样参与计算实际收益几乎为零。我早期踩过这个坑剪了 70% 的权重模型文件是小了但推理速度一点没变因为稠密计算库根本不认这些零。结构化剪枝则是以更大的粒度操作——剪掉整个通道、整个卷积核、整个注意力头。这样剪完之后模型结构是真的变小了不需要特殊硬件支持就能获得实际加速。代价是同样的压缩率下结构化剪枝对精度的伤害通常比非结构化大因为它一刀切掉的是整组参数灵活性差。实际项目里除非你有明确的稀疏硬件支持否则优先选结构化剪枝。判断标准很简单剪完之后模型能不能在目标硬件上真的跑快。跑不快压缩率再高也是自欺欺人。3.2 剪枝的粒度选择与敏感度分析剪枝不是拍脑袋决定剪哪里。正规做法是先做敏感度分析sensitivity analysis逐层尝试剪掉一定比例观察精度变化找出对剪枝敏感的层和不敏感的层。不敏感的层可以多剪敏感的层少剪甚至不剪。粒度上从细到粗有几种单个权重、通道、卷积核、层。粒度越粗加速越明显但精度损失越大。实践中常用的是通道级剪枝因为它在加速和精度之间比较平衡而且大多数推理框架都能正确处理通道数变化的模型。剪枝的流程一般是迭代式的剪一部分 → 微调恢复精度 → 再剪一部分 → 再微调。一次性剪太多模型直接崩掉微调也救不回来。这个剪-调循环的节奏很关键我通常从 10% 的剪枝率开始每次增加 5% 到 10%观察精度曲线找到拐点。3.3 知识蒸馏在优化链路里的位置知识蒸馏严格来说不算压缩它是用一个大模型教师的输出指导一个小模型学生训练让小模型学到教师模型的暗知识。它的价值在于当你需要一个结构本身就小的模型而不是把大模型压小的时候蒸馏是首选。蒸馏的关键在于软标签。教师模型输出的概率分布里包含了类别之间的相似性信息比如一张猫的图片教师可能给出猫 0.9、狗 0.08、其他 0.02这个 0.08 就告诉学生猫和狗有点像这是硬标签one-hot给不了的信息。温度参数 T 用来控制软标签的平滑程度T 越大分布越平滑暗知识越丰富但也不能太大否则噪声也放大。蒸馏和量化、剪枝可以叠加使用。一个典型链路是先用蒸馏训练一个小模型再对小模型做剪枝最后量化。每一环都贡献一部分压缩和加速组合起来效果很可观。但要注意叠加的误差也会累积每一环都要单独验证精度不能等到最后一起看。4. 图优化与算子融合不改变数值的免费加速4.1 算子融合为什么能白捡性能前面讲的量化和剪枝都会改变模型数值需要小心处理精度。而图优化和算子融合是另一类手段——它们不改变计算结果只是让计算过程更高效属于免费加速。最典型的例子是 Conv BN ReLU 的融合。在推理阶段BN 层的参数是固定的可以数学上折叠进前面的卷积权重里ReLU 则可以直接融进卷积的输出激活。融合之后原本三次内存读写变成一次中间结果不用落盘内存带宽和 kernel 启动开销都省了。这类融合在推理框架里通常是自动做的但前提是你的模型图结构清晰、算子标准。如果你的模型里塞了一堆自定义算子或者奇怪的 reshape融合就可能失败。另一个常见的是矩阵乘加融合如 MatMul Add 融成 GEMM 的 beta 参数以及注意力机制里的 QKV 计算融合。这些融合对 Transformer 类模型收益尤其明显。4.2 常量折叠与死代码消除常量折叠是指把图中可以在编译期算出来的部分提前算掉。比如一个常量张量参与的加法没必要每次推理都算一遍直接折叠成一个新常量。死代码消除则是去掉那些输出没有被使用的节点——训练时可能有些辅助分支推理时用不到但图里还留着白白消耗计算。这两个优化听起来很基础但实际项目里经常能捡到不少收益尤其是那些从训练代码直接导出、没有清理过的模型。我见过一个模型导出后图里有近 20% 的节点是训练遗留的辅助计算清理掉之后延迟直接降了一截。4.3 布局转换与内存复用还有一个容易被忽视的优化点是张量布局layout。不同硬件对数据排布有偏好比如某些加速器喜欢 NHWC 而不是 NCHW。如果布局不匹配框架会在算子之间插入转置操作这些转置本身不产生任何有价值的计算纯粹是开销。图优化器会尽量把布局转换合并、消除或者选择整体一致的布局方案。内存复用则是让不同生命周期的中间张量共享同一块内存。推理时中间激活的峰值内存往往远大于模型本身通过分析张量的生命周期把不再需要的张量内存回收给后续张量用能显著降低峰值显存。这对大模型部署尤其关键。5. 一套可复现的优化流程与验证方法5.1 优化前的基线测量不能省我见过太多人一上来就开始量化、剪枝问他基线延迟多少、显存多少答不上来。没有基线你根本不知道优化有没有效果也不知道瓶颈在哪。所以第一步永远是建立基线在目标硬件、目标框架、目标 batch size 下测出模型的延迟、吞吐、显存占用、精度指标。这些数据要记录清楚作为后续每一步对比的参照。测量时要注意几个细节预热warmup要充分前几次推理往往包含初始化开销多次测量取稳定值不要只看一次区分纯推理时间和包含前后处理的时间优化的是哪部分要明确。还有延迟和吞吐是两回事batch size 小的时候看延迟batch size 大的时候看吞吐别混为一谈。5.2 优化顺序的决策逻辑优化手段的先后顺序有讲究。我的建议是先做不改变数值的图优化和算子融合再做量化最后考虑剪枝和蒸馏。理由是这样图优化零风险先拿到免费收益量化收益大、实现相对标准化是主力手段剪枝和蒸馏改动大、调参复杂放在后面作为补充。但这个顺序不是死的。如果模型大到根本跑不起来可能要先剪枝或蒸馏把规模降下来再做量化。如果目标硬件对某种精度有特殊支持比如 INT4那量化就要优先考虑。核心原则是先做风险低、收益高的把简单的收益拿到手再啃硬骨头。5.3 精度验证要做得比训练时更细优化后的精度验证标准要比训练时更严格。训练时看整体指标就够了优化后必须做细粒度对比per-class 精度、混淆矩阵变化、关键样本的预测差异、置信度分布变化。因为优化引入的误差往往不是均匀分布的它可能在某些类别、某些样本上集中爆发。我习惯的做法是准备一个固定的验证集优化前后各跑一遍逐样本对比预测结果把预测发生变化的样本挑出来人工看。如果变化的样本集中在某个类别或某种场景那就要针对性处理。这个方法帮我抓到过好几次整体指标正常但局部崩坏的问题。还有一个实用技巧是分层验证。把验证集按难度、场景、类别分组分别看每组的精度变化。有时候整体只掉 0.3%但某个困难子集掉了 8%这种问题只有分层看才能发现。6. 那些文档里不会写的实战教训6.1 优化工具的输出不等于最终部署形态很多人以为优化工具导出的模型就是最终部署的模型直接拿去上线。这是个误区。优化工具的输出通常是一个中间格式比如 ONNX还需要经过目标推理框架的转换、编译才能真正在硬件上跑。而这个转换过程可能引入新的问题算子不支持导致回退、精度在转换中丢失、图结构被改变导致融合失效。所以完整的验证链路应该是优化后模型 → 转成部署格式 → 在目标硬件上实测精度和性能。每一步都要验证不能跳步。我踩过的最坑的一次是量化模型在工具里验证精度正常转成部署格式后精度崩了排查半天发现是某个算子在转换时被错误处理了。6.2 精度和性能的权衡要量化不能凭感觉精度掉一点没关系速度提上来就行——这话说起来轻松但一点是多少提上来是多少没有量化就没有决策依据。我建议在项目开始就定好约束精度下降不超过 X%延迟降低至少 Y%显存不超过 Z。然后所有优化方案都拿这三个数字去卡达标就用不达标就调。这个约束最好和业务方一起定因为只有业务方知道精度掉多少是真正可接受的。技术人员容易陷入精度越高越好的执念但业务上可能 95% 和 96% 没区别而延迟从 100ms 降到 50ms 价值巨大。6.3 版本管理和可复现性优化过程涉及大量实验不同的量化配置、不同的剪枝率、不同的校准集。如果不做好版本管理很快就会乱套说不清哪个模型对应哪套配置。我的做法是每次实验记录完整的配置包括随机种子、对应的精度和性能数据、以及使用的工具版本。模型文件、配置文件、验证脚本一起归档。工具版本尤其重要。优化工具更新频繁不同版本的行为可能不同同一个配置在新版本上结果可能变化。生产环境要锁定版本升级前必须重新验证。6.4 别忽视端到端的整体优化模型优化只是端到端链路的一环。实际推理延迟里前后处理、数据搬运、框架调度可能占很大比例。我见过模型本身优化得很好但前后处理用了低效的 Python 实现整体延迟下不来。所以优化要有全局视角先 profile 整个链路找到真正的瓶颈再决定优化哪里。有时候优化前后处理比优化模型本身收益还大。7. 关于 Model-Optimizer 这类工具我个人的使用体会用了几年这类工具最大的体会是工具本身不难难的是判断力。知道什么时候该用量化、什么时候该剪枝、什么时候该收手这些判断来自对模型、对硬件、对业务的理解而不是工具文档能给的。工具能帮你执行但决策得你自己做。另一个体会是优化是一个迭代过程不是一次性的。模型在变、数据在变、硬件在变、业务需求在变优化方案也要跟着调整。把优化当成一个持续的工作流而不是项目末期的一个任务心态会好很多。最后分享一个我常用的检查习惯每次优化完除了看指标我一定会亲自跑几个真实样本看看输出是不是合理。指标是平均值真实样本能暴露平均值掩盖的问题。有好几次指标看着正常但实际输出明显不对劲靠人工看样本才发现。这个习惯看起来笨但很管用。