1. 从“模型优化器”这个热词说起它到底在解决什么问题“Model-Optimizer”这个词最近在技术社区里出现的频率明显高了起来。很多人第一次看到它会下意识地以为这是某个具体的开源库或者某个云厂商的产品名。实际上它更像是一个功能角色的统称——凡是承担“让模型跑得更快、更小、更省资源”这一职责的组件都可以被归到模型优化器这个范畴里。它可能是一个独立的工具链也可能是训练框架里的一个模块甚至是你自己写的一段量化脚本。我在实际项目里接触模型优化这件事最早是从一个很朴素的痛点开始的训练出来的模型在实验环境里跑得好好的一放到实际业务环境里就各种问题——推理延迟高得离谱、显存占用把同卡上的其他服务挤爆、批量请求一上来就排队。那时候我的做法很粗暴就是换更大的卡、加更多的机器。后来算了一笔账才发现硬件成本的增长速度远远超过业务收益的增长速度这条路根本走不通。真正能解决问题的还是回到模型本身去做优化。模型优化器要解决的核心矛盾说白了就一句话在尽量不损失精度的前提下把模型的计算量和存储量降下来。这个矛盾之所以难是因为精度和效率天然是一对冤家。你把模型压得越狠精度掉得就越明显你想保住精度那压缩空间就非常有限。模型优化器的价值就在于它提供了一套系统性的方法论和工具让你能在这个矛盾里找到一个可接受的平衡点而不是靠拍脑袋去试。这篇文章适合哪些人看如果你正在做模型部署、推理服务搭建、边缘端模型落地或者你只是单纯觉得自己的模型“太胖了”想瘦身那接下来的内容应该对你有用。我会从模型优化器的核心工作维度讲起然后逐个拆解量化、剪枝、蒸馏、编译优化这几条主流技术路线再结合我自己的实操经验聊聊选型逻辑和踩过的坑。不会堆砌论文里的公式重点放在“实际怎么做”和“为什么这么做”上。2. 模型优化器的四个核心工作维度在动手做优化之前有必要先搞清楚模型优化器到底能从哪些角度入手。我把它归纳为四个维度计算量、存储量、内存访问、并行效率。这四个维度不是孤立的很多时候你优化了其中一个另外几个也会跟着变化但理解它们各自的含义能帮你在遇到瓶颈时快速定位问题出在哪。2.1 计算量FLOPs 降下来延迟不一定线性下降计算量通常用 FLOPs浮点运算次数来衡量。一个模型的 FLOPs 越高理论上需要的计算时间就越长。所以很多优化手段的第一目标就是降低 FLOPs比如把大卷积核换成小卷积核、把全连接层换成全局平均池化、用深度可分离卷积替代标准卷积。但这里有一个非常容易踩的坑FLOPs 降低了实际推理延迟不一定跟着降。我早期做过一个实验把一个标准卷积全部换成深度可分离卷积FLOPs 降了将近 8 倍但实际在目标硬件上跑下来延迟只降了不到 2 倍。原因在于深度可分离卷积的算子碎片化严重GPU 的并行计算单元利用率上不去大量的时间花在了 kernel launch 和内存搬运上而不是真正的计算上。所以看计算量指标的时候一定要结合目标硬件的特性。在 GPU 上大矩阵乘法这种计算密集型的算子效率很高反而是那些看起来 FLOPs 很低的逐元素操作会成为瓶颈。而在一些专用的推理芯片上情况又不一样。我的经验是FLOPs 只作为参考指标最终一定要在目标硬件上实测端到端延迟。2.2 存储量参数量决定模型“体重”存储量主要看参数量和权重的位宽。一个 FP32 的模型每个参数占 4 个字节一个 1 亿参数的模型就是 400MB。如果换成 INT8直接降到 100MB。这对于边缘设备来说差别是巨大的——很多嵌入式设备的存储空间可能就只有几百 MBFP32 模型根本放不下。存储量优化最直接的手段就是量化把 FP32 的权重和激活值用更低位的格式来表示。INT8 是最常见的现在 INT4 甚至二值化网络也在一些场景下有了应用。量化的好处不只是省存储还能省带宽——模型加载的时候需要从内存里读权重位宽越低读取速度越快这对推理延迟的改善有时候比计算优化还明显。但量化有一个绕不开的问题精度损失。尤其是激活值的量化因为激活值的分布是动态的不同输入对应的范围差异很大量化误差会直接影响到输出结果。后面讲量化的时候我会详细说怎么处理这个问题。2.3 内存访问被大多数人忽略的隐形瓶颈内存访问这个维度很多刚接触模型优化的人会忽略。但在实际推理中内存带宽往往是比计算能力更稀缺的资源。尤其是在 GPU 上计算单元的速度远快于显存读写速度很多算子其实是“内存 bound”而不是“计算 bound”。举个例子一个简单的 ReLU 激活函数它的计算量几乎可以忽略不计但它需要把整个特征图从显存读进来做完比较后再写回去。如果特征图很大这个读写过程消耗的时间可能比前面那个卷积层还多。这就是为什么现在很多推理框架都在做算子融合——把卷积、BN、ReLU 融合成一个算子中间结果不落显存直接在寄存器或共享内存里传递省掉大量的读写开销。模型优化器在做图优化的时候算子融合是最基本也是收益最明显的一步。TensorRT、TVM、OpenVINO 这些推理框架都会在编译阶段自动做算子融合。但自动融合不是万能的有些情况下需要你手动调整模型结构把能融合的算子放在一起避免中间插入一些打断融合的操作。2.4 并行效率多卡多核不是简单堆硬件最后一个维度是并行效率。当单卡性能压榨到极限之后自然就会想到用多卡并行来提升吞吐。但并行不是简单地把模型切开放到多张卡上就行通信开销、负载均衡、同步等待这些问题都会影响最终的加速比。数据并行是最常见的每张卡持有完整的模型副本处理不同的数据批次。这种方式实现简单但要求模型能完整放进单卡显存。模型并行则是把模型的不同层放到不同的卡上适合超大模型但层与层之间的通信会成为瓶颈。流水线并行是模型并行的一种改进通过把批次切分成多个微批次让不同卡上的计算重叠起来减少等待时间。在实际项目里我一般会先看单卡能不能放下模型。能放下就优先数据并行简单可靠。放不下再考虑模型并行或流水线并行但这时候就要仔细评估通信开销了。如果卡间的通信带宽不够并行带来的收益可能被通信开销完全吃掉。3. 量化模型优化器里最立竿见影的手段量化是我在所有优化手段里最推荐优先尝试的原因很简单收益大、改动小、工具链成熟。一个 FP32 模型量化到 INT8模型大小直接变成原来的四分之一推理速度通常能有 2 到 4 倍的提升而精度损失在很多任务上可以控制在 1% 以内。这个投入产出比是其他优化手段很难比的。3.1 训练后量化与量化感知训练的选择量化分两条路线训练后量化PTQ和量化感知训练QAT。PTQ 是拿训练好的 FP32 模型直接做量化不需要重新训练速度快、成本低。QAT 是在训练过程中模拟量化误差让模型提前适应低精度表示精度保持得更好但需要重新训练成本高。我的建议是先试 PTQ不行再上 QAT。大部分常规模型用 PTQ 就能拿到不错的结果。具体来说如果你的模型结构比较规整以卷积和全连接为主PTQ 的精度损失通常很小。但如果模型里有大量动态范围很大的激活值或者有 LSTM 这类对数值精度敏感的模块PTQ 可能就不太够用了。PTQ 里面又分动态量化和静态量化。动态量化只量化权重激活值在推理时动态计算量化参数实现简单但加速效果有限。静态量化同时量化权重和激活值需要一批校准数据来统计激活值的分布范围加速效果更好。校准数据不需要标注从训练集里随机抽几百张就够了但要注意校准数据的分布要能覆盖实际推理时的输入分布。3.2 校准集的选择比量化算法本身更重要这一点是我踩过坑之后才深刻体会到的。很多人做量化的时候把精力都花在对比不同的量化算法上却忽略了校准集的质量。实际上校准集选得不好再好的量化算法也救不回来。我遇到过一个案例一个图像分类模型用随机抽的校准集做 PTQ精度掉了 5 个百分点。后来分析发现随机抽的校准集里某个类别的图片特别少导致这个类别对应的激活值范围统计偏了量化之后这个类别的识别率大幅下降。后来改成按类别分层抽样每个类别抽相同数量的图片精度损失降到了 0.8%。校准集的选择有几个原则覆盖所有类别、覆盖不同的输入尺度、覆盖边界情况。如果你的模型处理的是变长输入校准集里就要包含各种长度的样本。如果输入有季节性或周期性变化校准集也要体现这种变化。校准集的数量不用太多几百到一千个样本通常就够了但质量一定要保证。3.3 逐层量化与混合精度的实操配置在实际操作中不是所有层都适合量化到 INT8。有些层对精度特别敏感比如第一层卷积和最后一层全连接量化之后精度损失会很明显。这时候就需要混合精度量化——对敏感的层保持 FP16 或 FP32其他层量化到 INT8。以 TensorRT 为例你可以通过层名称来指定哪些层不参与 INT8 量化。具体做法是在构建 engine 的时候设置set_flag和set_layer_precision把敏感层标记为 FP16。但这里有个细节INT8 层和 FP16 层之间的衔接处会有额外的类型转换开销如果频繁切换反而会拖慢速度。所以混合精度的策略应该是“大块连续”而不是“逐层切换”。另一个实操技巧是逐层敏感度分析。做法很简单每次只把一个层量化到 INT8其他层保持 FP32然后测精度。把所有层都跑一遍就能得到每个层对量化的敏感度排序。敏感度低的层放心量化敏感度高的层保持高精度。这个分析过程虽然耗时但一次分析之后可以复用到同系列的所有模型上性价比很高。4. 剪枝与蒸馏给模型做减法和拜师学艺量化的思路是“降低每个参数的表示精度”而剪枝和蒸馏的思路是“减少参数的数量”和“让小模型学到大模型的本事”。这两条路线和量化是互补的可以叠加使用。4.1 结构化剪枝与非结构化剪枝的取舍剪枝的核心思想是神经网络里有很多参数其实是冗余的去掉它们对输出结果影响很小。剪枝就是找出这些冗余参数并去掉。非结构化剪枝是把单个权重置零粒度最细理论上能剪掉最多的参数。但问题是剪完之后权重矩阵变得稀疏而普通的 GPU 和推理芯片对稀疏矩阵的计算效率并不高除非有专门的稀疏计算支持。所以非结构化剪枝在实际部署中往往“剪了但没快”参数量是少了但推理速度没提升。结构化剪枝是以通道、卷积核、层为单位进行剪枝剪完之后模型结构是规整的不需要特殊的稀疏计算支持直接就能在通用硬件上获得加速。代价是剪枝粒度粗可能剪掉一些其实还有用的参数。但在实际工程中结构化剪枝的可用性远高于非结构化剪枝。我一般会先用结构化剪枝把模型压到一个合理的规模然后再用量化进一步压缩。这个组合拳打下来模型大小和推理速度都能有数量级的改善。4.2 剪枝率怎么定从敏感度分析到迭代剪枝剪枝率是最关键的参数。剪得太少没效果剪得太多精度崩盘。我的做法是从低剪枝率开始迭代进行。具体流程是这样的先设定一个初始剪枝率比如 10%对模型做剪枝后微调几个 epoch看精度恢复情况。如果精度恢复得很好就加大剪枝率再试如果精度掉得厉害就降低剪枝率。这样逐步逼近一个精度和压缩率的平衡点。这里有一个经验值可以参考对于常规的卷积网络每层剪掉 20% 到 30% 的通道通常是比较安全的精度损失可以通过少量微调恢复。但第一层和最后一层要特别小心这两层的通道数通常不建议剪或者只剪很小的比例。还有一个技巧是全局剪枝和逐层剪枝的选择。逐层剪枝是每层独立设定剪枝率全局剪枝是根据所有层的参数重要性统一排序后剪枝。全局剪枝通常能获得更好的压缩率因为它会把冗余度高的层多剪一些冗余度低的层少剪一些。但全局剪枝的实现复杂度更高需要维护一个全局的重要性排序。4.3 知识蒸馏中温度参数的调节经验知识蒸馏的思路是让一个小模型学生模型去模仿一个大模型教师模型的输出。学生模型不直接学习硬标签而是学习教师模型输出的软概率分布这个分布里包含了类别之间的相似性信息比硬标签更有信息量。温度参数 T 是蒸馏里最关键的调节旋钮。T 越大软概率分布越平滑类别之间的相对关系信息越丰富T 越小分布越接近硬标签。常规的做法是在训练初期用较大的 T让模型充分学习类别间的关系后期逐渐减小 T让模型逼近真实的分类边界。我自己的经验是T 在 3 到 10 之间比较合适。T 太小比如 1 到 2蒸馏的效果和直接训练差别不大T 太大比如 20 以上软标签的分布过于平滑学生模型学到的信息反而变得模糊。另外蒸馏损失和原始分类损失的权重也需要调节通常蒸馏损失的权重在 0.5 到 0.9 之间效果比较好。蒸馏还有一个容易被忽略的点教师模型的质量决定了学生模型的上限。如果教师模型本身就不够好学生模型再怎么学也超不过它。所以做蒸馏之前先确保教师模型是经过充分训练和调优的。5. 图优化与编译推理框架在背后做了什么前面讲的量化、剪枝、蒸馏都是在模型结构或参数层面做文章。而图优化和编译是在计算图层面做优化它不改变模型的数学等价性但能显著提升执行效率。这部分工作通常由推理框架自动完成但了解它做了什么能帮你在遇到问题时知道该往哪个方向排查。5.1 算子融合的收益与边界条件算子融合是图优化里收益最大的一步。最常见的融合模式是 Conv BN ReLU 融合成一个算子。在原始模型里这三个操作是分开的卷积算完写回显存BN 从显存读出来算完再写回去ReLU 再来一遍。融合之后中间结果不落显存直接在寄存器里传递省掉了两次显存读写。但算子融合不是无条件的。融合的前提是算子之间的数据依赖关系允许合并而且融合后的算子要在目标硬件上有高效的实现。有些框架在融合时会检查算子的属性比如卷积的 padding 模式、BN 的训练/推理模式等如果属性不匹配就不会融合。我在实际项目中遇到过一种情况模型里有一个分支结构两个分支各自做卷积然后相加。框架没有把这两个卷积分支融合成一个因为它们的输入相同但权重不同融合后计算量并没有减少。这种情况下手动调整模型结构把两个分支的卷积合并成一个更大的卷积输出通道数翻倍然后再拆分有时候能获得更好的融合效果。5.2 内存复用与计算图重排的实际效果内存复用是另一个重要的图优化手段。在推理过程中很多中间张量在用完之后就可以释放了后面的张量可以复用这块内存。框架会分析整个计算图的生命周期给每个张量分配一个内存偏移量让生命周期不重叠的张量共享同一块内存。这个优化对显存受限的场景特别有用。我做过一个实验一个中等规模的检测模型不做内存复用的时候峰值显存占用是 2.3GB做了内存复用之后降到了 1.6GB降幅接近 30%。这意味着原来只能跑一个实例的卡现在可以跑两个实例吞吐直接翻倍。计算图重排是另一个容易被忽略的优化。框架会根据算子的依赖关系重新排列执行顺序把可以并行的算子放在一起执行减少同步等待。比如在残差网络里主分支和跳跃连接的计算可以并行框架会把它们排在一起而不是串行执行。5.3 不同推理后端的选型对比目前主流的推理后端有 TensorRT、OpenVINO、ONNX Runtime、TVM 等它们各有侧重。推理后端适用硬件优势局限TensorRTNVIDIA GPU算子融合和量化支持最成熟性能极致绑定 NVIDIA 硬件模型转换有时会失败OpenVINOIntel CPU/GPU/VPUIntel 平台优化好CPU 推理性能强非 Intel 平台支持有限ONNX Runtime跨平台通用性好支持多种后端极致性能不如专用框架TVM跨平台可针对特定硬件自动调优使用门槛高调优耗时我的选型逻辑是如果目标硬件是 NVIDIA GPU优先 TensorRT如果是 Intel CPU优先 OpenVINO如果需要跨平台部署或者快速验证用 ONNX Runtime如果有特殊硬件需要深度定制考虑 TVM。不要试图用一个框架解决所有问题混合使用是常态。6. 实操中的选型逻辑与踩坑记录前面讲了这么多技术点最后这部分我想聊聊实际做优化时的决策逻辑以及我踩过的一些印象深刻的坑。这些经验在官方文档里通常找不到但往往比技术本身更能决定项目的成败。6.1 优化顺序先量化还是先剪枝这个问题我被问过很多次。我的答案是先剪枝再量化。原因在于剪枝改变的是模型结构量化改变的是数值表示。如果先量化再剪枝剪枝后的模型结构变了之前量化时统计的激活值分布可能就不准了需要重新校准。而先剪枝再量化剪枝后的模型结构是确定的量化校准可以一次做到位。但也不是绝对的。如果剪枝率很低比如 10% 以内对激活值分布的影响很小先量化再剪枝也不是不行。另外如果时间紧迫量化是必须做的剪枝是可选的那当然先做量化。核心原则是结构性的改动放在前面数值性的改动放在后面。还有一个顺序问题蒸馏和剪枝的关系。如果你打算同时用蒸馏和剪枝建议先蒸馏再剪枝。因为蒸馏需要一个好的教师模型和一个结构完整的学生模型如果先剪枝把学生模型剪残了蒸馏的效果会大打折扣。6.2 精度掉点排查从数据到算子的逐层定位精度掉点是优化过程中最常见的问题。模型优化完了精度掉了好几个点这时候怎么排查我的排查链路是这样的第一步确认掉点是否来自优化本身。用同样的测试集和测试脚本分别跑优化前和优化后的模型确保对比条件一致。有时候掉点是因为测试脚本的预处理不一致或者测试集本身有变化不一定是优化的锅。第二步定位掉点发生在哪个阶段。如果是量化导致的先检查校准集是否覆盖了所有场景。如果是剪枝导致的检查剪枝率是否过高或者某些关键层被剪了。如果是蒸馏导致的检查温度参数和损失权重是否合理。第三步逐层对比输出。这是最有效但也最耗时的方法。把优化前后的模型每一层的输出都拿出来对比看从哪一层开始出现明显的偏差。找到偏差最大的层重点分析这个层的优化策略是否合适。我遇到过一个案例量化后精度掉了 3 个点逐层对比发现是某个中间层的激活值范围特别大INT8 的表示范围不够用导致大量数值被截断。后来把这个层改成 FP16其他层保持 INT8精度恢复到了只掉 0.5 个点。6.3 硬件适配同一模型在不同芯片上的表现差异同一个模型同样的优化策略在不同硬件上的表现可能天差地别。我做过一个对比实验一个经过 INT8 量化的模型在 NVIDIA T4 上推理延迟是 8ms在另一款推理芯片上是 15ms而在某款边缘设备上直接跑不起来——因为那个设备不支持 INT8 的某些算子。这个实验给我的教训是优化策略必须和硬件绑定。在 GPU 上有效的优化换到 CPU 或专用芯片上可能完全无效甚至起反作用。所以做优化之前一定要先明确目标硬件是什么然后针对这个硬件做针对性的优化。另外硬件的驱动版本和推理框架版本也会影响性能。我遇到过升级驱动之后同样的模型推理速度提升了 20% 的情况。所以保持驱动和框架版本更新有时候能白捡性能提升。6.4 优化效果的评估不要只看单一指标最后聊聊评估。很多人评估优化效果只看模型大小和推理延迟这其实是不够的。一个完整的评估应该包括模型大小、推理延迟、吞吐量、精度、显存占用、功耗。这几个指标之间往往是互相制约的。比如量化降低了模型大小和延迟但可能带来精度损失。剪枝减少了参数量但可能影响吞吐量因为剪枝后的模型结构可能对硬件不友好。所以评估的时候要综合考虑根据业务场景确定哪个指标最重要。如果是移动端场景功耗和模型大小可能是第一优先级。如果是云端服务吞吐量和延迟更重要。如果是精度敏感的场景那精度就是红线任何优化都不能突破这个红线。我一般会先和业务方确认好优先级然后再制定优化方案避免优化完了才发现方向错了。提示做任何优化之前先保存一份原始模型的完整备份包括权重、配置文件和推理脚本。优化过程中随时可以回退到原始版本做对比这是排查问题的基准线。7. 我个人的优化工具箱与日常习惯说了这么多方法论最后分享一些我日常用的工具和习惯。这些不是什么高深的东西但都是长期实践下来觉得真正好用的。模型分析阶段我常用的是 Netron 来看模型结构用 fvcore 或 thop 来统计 FLOPs 和参数量。这两个工具都很轻量装上就能用不需要复杂的配置。Netron 的可视化很直观能快速看出模型里有哪些算子、哪些地方可能存在优化空间。量化工具方面PyTorch 自带的量化工具链已经比较完善了torch.quantization模块支持 PTQ 和 QAT。如果目标硬件是 NVIDIA GPU我会用 TensorRT 的量化工具它的校准和层敏感度分析功能更强大。如果是 Intel CPUOpenVINO 的 POT 工具也很好用。剪枝工具我用得比较多的是 Torch-Pruning 这个库它支持结构化剪枝而且能自动处理层之间的依赖关系不用手动去调整每一层的输入输出通道数。这个库的文档写得也很清楚上手很快。日常习惯方面我有几个坚持了很多年的做法。第一每次优化实验都记录完整的配置和结果包括模型版本、优化参数、硬件环境、测试指标。这些记录在后来排查问题时帮了我大忙。第二优化前后一定要做端到端的精度验证不能只看中间层的指标。第三保持对新技术的好奇心模型优化这个领域发展很快新的量化算法、新的剪枝策略、新的推理框架层出不穷定期看看最新的论文和开源项目能帮你保持技术敏感度。模型优化这件事说到底是一个在约束条件下找最优解的工程问题。没有银弹没有一劳永逸的方案每个模型、每个硬件、每个业务场景都需要针对性地分析和调优。但只要你理解了背后的原理掌握了基本的工具和方法就能在面对新问题时快速找到切入点。希望这些经验对你有帮助少走一些我当年走过的弯路。 
长河君 · 2026/9/29 12:35:13 · 阅读 1.2k 模型优化器实战：量化、剪枝、蒸馏与图优化全解析
1. 从“模型优化器”这个热词说起它到底在解决什么问题“Model-Optimizer”这个词最近在技术社区里出现的频率明显高了起来。很多人第一次看到它会下意识地以为这是某个具体的开源库或者某个云厂商的产品名。实际上它更像是一个功能角色的统称——凡是承担“让模型跑得更快、更小、更省资源”这一职责的组件都可以被归到模型优化器这个范畴里。它可能是一个独立的工具链也可能是训练框架里的一个模块甚至是你自己写的一段量化脚本。我在实际项目里接触模型优化这件事最早是从一个很朴素的痛点开始的训练出来的模型在实验环境里跑得好好的一放到实际业务环境里就各种问题——推理延迟高得离谱、显存占用把同卡上的其他服务挤爆、批量请求一上来就排队。那时候我的做法很粗暴就是换更大的卡、加更多的机器。后来算了一笔账才发现硬件成本的增长速度远远超过业务收益的增长速度这条路根本走不通。真正能解决问题的还是回到模型本身去做优化。模型优化器要解决的核心矛盾说白了就一句话在尽量不损失精度的前提下把模型的计算量和存储量降下来。这个矛盾之所以难是因为精度和效率天然是一对冤家。你把模型压得越狠精度掉得就越明显你想保住精度那压缩空间就非常有限。模型优化器的价值就在于它提供了一套系统性的方法论和工具让你能在这个矛盾里找到一个可接受的平衡点而不是靠拍脑袋去试。这篇文章适合哪些人看如果你正在做模型部署、推理服务搭建、边缘端模型落地或者你只是单纯觉得自己的模型“太胖了”想瘦身那接下来的内容应该对你有用。我会从模型优化器的核心工作维度讲起然后逐个拆解量化、剪枝、蒸馏、编译优化这几条主流技术路线再结合我自己的实操经验聊聊选型逻辑和踩过的坑。不会堆砌论文里的公式重点放在“实际怎么做”和“为什么这么做”上。2. 模型优化器的四个核心工作维度在动手做优化之前有必要先搞清楚模型优化器到底能从哪些角度入手。我把它归纳为四个维度计算量、存储量、内存访问、并行效率。这四个维度不是孤立的很多时候你优化了其中一个另外几个也会跟着变化但理解它们各自的含义能帮你在遇到瓶颈时快速定位问题出在哪。2.1 计算量FLOPs 降下来延迟不一定线性下降计算量通常用 FLOPs浮点运算次数来衡量。一个模型的 FLOPs 越高理论上需要的计算时间就越长。所以很多优化手段的第一目标就是降低 FLOPs比如把大卷积核换成小卷积核、把全连接层换成全局平均池化、用深度可分离卷积替代标准卷积。但这里有一个非常容易踩的坑FLOPs 降低了实际推理延迟不一定跟着降。我早期做过一个实验把一个标准卷积全部换成深度可分离卷积FLOPs 降了将近 8 倍但实际在目标硬件上跑下来延迟只降了不到 2 倍。原因在于深度可分离卷积的算子碎片化严重GPU 的并行计算单元利用率上不去大量的时间花在了 kernel launch 和内存搬运上而不是真正的计算上。所以看计算量指标的时候一定要结合目标硬件的特性。在 GPU 上大矩阵乘法这种计算密集型的算子效率很高反而是那些看起来 FLOPs 很低的逐元素操作会成为瓶颈。而在一些专用的推理芯片上情况又不一样。我的经验是FLOPs 只作为参考指标最终一定要在目标硬件上实测端到端延迟。2.2 存储量参数量决定模型“体重”存储量主要看参数量和权重的位宽。一个 FP32 的模型每个参数占 4 个字节一个 1 亿参数的模型就是 400MB。如果换成 INT8直接降到 100MB。这对于边缘设备来说差别是巨大的——很多嵌入式设备的存储空间可能就只有几百 MBFP32 模型根本放不下。存储量优化最直接的手段就是量化把 FP32 的权重和激活值用更低位的格式来表示。INT8 是最常见的现在 INT4 甚至二值化网络也在一些场景下有了应用。量化的好处不只是省存储还能省带宽——模型加载的时候需要从内存里读权重位宽越低读取速度越快这对推理延迟的改善有时候比计算优化还明显。但量化有一个绕不开的问题精度损失。尤其是激活值的量化因为激活值的分布是动态的不同输入对应的范围差异很大量化误差会直接影响到输出结果。后面讲量化的时候我会详细说怎么处理这个问题。2.3 内存访问被大多数人忽略的隐形瓶颈内存访问这个维度很多刚接触模型优化的人会忽略。但在实际推理中内存带宽往往是比计算能力更稀缺的资源。尤其是在 GPU 上计算单元的速度远快于显存读写速度很多算子其实是“内存 bound”而不是“计算 bound”。举个例子一个简单的 ReLU 激活函数它的计算量几乎可以忽略不计但它需要把整个特征图从显存读进来做完比较后再写回去。如果特征图很大这个读写过程消耗的时间可能比前面那个卷积层还多。这就是为什么现在很多推理框架都在做算子融合——把卷积、BN、ReLU 融合成一个算子中间结果不落显存直接在寄存器或共享内存里传递省掉大量的读写开销。模型优化器在做图优化的时候算子融合是最基本也是收益最明显的一步。TensorRT、TVM、OpenVINO 这些推理框架都会在编译阶段自动做算子融合。但自动融合不是万能的有些情况下需要你手动调整模型结构把能融合的算子放在一起避免中间插入一些打断融合的操作。2.4 并行效率多卡多核不是简单堆硬件最后一个维度是并行效率。当单卡性能压榨到极限之后自然就会想到用多卡并行来提升吞吐。但并行不是简单地把模型切开放到多张卡上就行通信开销、负载均衡、同步等待这些问题都会影响最终的加速比。数据并行是最常见的每张卡持有完整的模型副本处理不同的数据批次。这种方式实现简单但要求模型能完整放进单卡显存。模型并行则是把模型的不同层放到不同的卡上适合超大模型但层与层之间的通信会成为瓶颈。流水线并行是模型并行的一种改进通过把批次切分成多个微批次让不同卡上的计算重叠起来减少等待时间。在实际项目里我一般会先看单卡能不能放下模型。能放下就优先数据并行简单可靠。放不下再考虑模型并行或流水线并行但这时候就要仔细评估通信开销了。如果卡间的通信带宽不够并行带来的收益可能被通信开销完全吃掉。3. 量化模型优化器里最立竿见影的手段量化是我在所有优化手段里最推荐优先尝试的原因很简单收益大、改动小、工具链成熟。一个 FP32 模型量化到 INT8模型大小直接变成原来的四分之一推理速度通常能有 2 到 4 倍的提升而精度损失在很多任务上可以控制在 1% 以内。这个投入产出比是其他优化手段很难比的。3.1 训练后量化与量化感知训练的选择量化分两条路线训练后量化PTQ和量化感知训练QAT。PTQ 是拿训练好的 FP32 模型直接做量化不需要重新训练速度快、成本低。QAT 是在训练过程中模拟量化误差让模型提前适应低精度表示精度保持得更好但需要重新训练成本高。我的建议是先试 PTQ不行再上 QAT。大部分常规模型用 PTQ 就能拿到不错的结果。具体来说如果你的模型结构比较规整以卷积和全连接为主PTQ 的精度损失通常很小。但如果模型里有大量动态范围很大的激活值或者有 LSTM 这类对数值精度敏感的模块PTQ 可能就不太够用了。PTQ 里面又分动态量化和静态量化。动态量化只量化权重激活值在推理时动态计算量化参数实现简单但加速效果有限。静态量化同时量化权重和激活值需要一批校准数据来统计激活值的分布范围加速效果更好。校准数据不需要标注从训练集里随机抽几百张就够了但要注意校准数据的分布要能覆盖实际推理时的输入分布。3.2 校准集的选择比量化算法本身更重要这一点是我踩过坑之后才深刻体会到的。很多人做量化的时候把精力都花在对比不同的量化算法上却忽略了校准集的质量。实际上校准集选得不好再好的量化算法也救不回来。我遇到过一个案例一个图像分类模型用随机抽的校准集做 PTQ精度掉了 5 个百分点。后来分析发现随机抽的校准集里某个类别的图片特别少导致这个类别对应的激活值范围统计偏了量化之后这个类别的识别率大幅下降。后来改成按类别分层抽样每个类别抽相同数量的图片精度损失降到了 0.8%。校准集的选择有几个原则覆盖所有类别、覆盖不同的输入尺度、覆盖边界情况。如果你的模型处理的是变长输入校准集里就要包含各种长度的样本。如果输入有季节性或周期性变化校准集也要体现这种变化。校准集的数量不用太多几百到一千个样本通常就够了但质量一定要保证。3.3 逐层量化与混合精度的实操配置在实际操作中不是所有层都适合量化到 INT8。有些层对精度特别敏感比如第一层卷积和最后一层全连接量化之后精度损失会很明显。这时候就需要混合精度量化——对敏感的层保持 FP16 或 FP32其他层量化到 INT8。以 TensorRT 为例你可以通过层名称来指定哪些层不参与 INT8 量化。具体做法是在构建 engine 的时候设置set_flag和set_layer_precision把敏感层标记为 FP16。但这里有个细节INT8 层和 FP16 层之间的衔接处会有额外的类型转换开销如果频繁切换反而会拖慢速度。所以混合精度的策略应该是“大块连续”而不是“逐层切换”。另一个实操技巧是逐层敏感度分析。做法很简单每次只把一个层量化到 INT8其他层保持 FP32然后测精度。把所有层都跑一遍就能得到每个层对量化的敏感度排序。敏感度低的层放心量化敏感度高的层保持高精度。这个分析过程虽然耗时但一次分析之后可以复用到同系列的所有模型上性价比很高。4. 剪枝与蒸馏给模型做减法和拜师学艺量化的思路是“降低每个参数的表示精度”而剪枝和蒸馏的思路是“减少参数的数量”和“让小模型学到大模型的本事”。这两条路线和量化是互补的可以叠加使用。4.1 结构化剪枝与非结构化剪枝的取舍剪枝的核心思想是神经网络里有很多参数其实是冗余的去掉它们对输出结果影响很小。剪枝就是找出这些冗余参数并去掉。非结构化剪枝是把单个权重置零粒度最细理论上能剪掉最多的参数。但问题是剪完之后权重矩阵变得稀疏而普通的 GPU 和推理芯片对稀疏矩阵的计算效率并不高除非有专门的稀疏计算支持。所以非结构化剪枝在实际部署中往往“剪了但没快”参数量是少了但推理速度没提升。结构化剪枝是以通道、卷积核、层为单位进行剪枝剪完之后模型结构是规整的不需要特殊的稀疏计算支持直接就能在通用硬件上获得加速。代价是剪枝粒度粗可能剪掉一些其实还有用的参数。但在实际工程中结构化剪枝的可用性远高于非结构化剪枝。我一般会先用结构化剪枝把模型压到一个合理的规模然后再用量化进一步压缩。这个组合拳打下来模型大小和推理速度都能有数量级的改善。4.2 剪枝率怎么定从敏感度分析到迭代剪枝剪枝率是最关键的参数。剪得太少没效果剪得太多精度崩盘。我的做法是从低剪枝率开始迭代进行。具体流程是这样的先设定一个初始剪枝率比如 10%对模型做剪枝后微调几个 epoch看精度恢复情况。如果精度恢复得很好就加大剪枝率再试如果精度掉得厉害就降低剪枝率。这样逐步逼近一个精度和压缩率的平衡点。这里有一个经验值可以参考对于常规的卷积网络每层剪掉 20% 到 30% 的通道通常是比较安全的精度损失可以通过少量微调恢复。但第一层和最后一层要特别小心这两层的通道数通常不建议剪或者只剪很小的比例。还有一个技巧是全局剪枝和逐层剪枝的选择。逐层剪枝是每层独立设定剪枝率全局剪枝是根据所有层的参数重要性统一排序后剪枝。全局剪枝通常能获得更好的压缩率因为它会把冗余度高的层多剪一些冗余度低的层少剪一些。但全局剪枝的实现复杂度更高需要维护一个全局的重要性排序。4.3 知识蒸馏中温度参数的调节经验知识蒸馏的思路是让一个小模型学生模型去模仿一个大模型教师模型的输出。学生模型不直接学习硬标签而是学习教师模型输出的软概率分布这个分布里包含了类别之间的相似性信息比硬标签更有信息量。温度参数 T 是蒸馏里最关键的调节旋钮。T 越大软概率分布越平滑类别之间的相对关系信息越丰富T 越小分布越接近硬标签。常规的做法是在训练初期用较大的 T让模型充分学习类别间的关系后期逐渐减小 T让模型逼近真实的分类边界。我自己的经验是T 在 3 到 10 之间比较合适。T 太小比如 1 到 2蒸馏的效果和直接训练差别不大T 太大比如 20 以上软标签的分布过于平滑学生模型学到的信息反而变得模糊。另外蒸馏损失和原始分类损失的权重也需要调节通常蒸馏损失的权重在 0.5 到 0.9 之间效果比较好。蒸馏还有一个容易被忽略的点教师模型的质量决定了学生模型的上限。如果教师模型本身就不够好学生模型再怎么学也超不过它。所以做蒸馏之前先确保教师模型是经过充分训练和调优的。5. 图优化与编译推理框架在背后做了什么前面讲的量化、剪枝、蒸馏都是在模型结构或参数层面做文章。而图优化和编译是在计算图层面做优化它不改变模型的数学等价性但能显著提升执行效率。这部分工作通常由推理框架自动完成但了解它做了什么能帮你在遇到问题时知道该往哪个方向排查。5.1 算子融合的收益与边界条件算子融合是图优化里收益最大的一步。最常见的融合模式是 Conv BN ReLU 融合成一个算子。在原始模型里这三个操作是分开的卷积算完写回显存BN 从显存读出来算完再写回去ReLU 再来一遍。融合之后中间结果不落显存直接在寄存器里传递省掉了两次显存读写。但算子融合不是无条件的。融合的前提是算子之间的数据依赖关系允许合并而且融合后的算子要在目标硬件上有高效的实现。有些框架在融合时会检查算子的属性比如卷积的 padding 模式、BN 的训练/推理模式等如果属性不匹配就不会融合。我在实际项目中遇到过一种情况模型里有一个分支结构两个分支各自做卷积然后相加。框架没有把这两个卷积分支融合成一个因为它们的输入相同但权重不同融合后计算量并没有减少。这种情况下手动调整模型结构把两个分支的卷积合并成一个更大的卷积输出通道数翻倍然后再拆分有时候能获得更好的融合效果。5.2 内存复用与计算图重排的实际效果内存复用是另一个重要的图优化手段。在推理过程中很多中间张量在用完之后就可以释放了后面的张量可以复用这块内存。框架会分析整个计算图的生命周期给每个张量分配一个内存偏移量让生命周期不重叠的张量共享同一块内存。这个优化对显存受限的场景特别有用。我做过一个实验一个中等规模的检测模型不做内存复用的时候峰值显存占用是 2.3GB做了内存复用之后降到了 1.6GB降幅接近 30%。这意味着原来只能跑一个实例的卡现在可以跑两个实例吞吐直接翻倍。计算图重排是另一个容易被忽略的优化。框架会根据算子的依赖关系重新排列执行顺序把可以并行的算子放在一起执行减少同步等待。比如在残差网络里主分支和跳跃连接的计算可以并行框架会把它们排在一起而不是串行执行。5.3 不同推理后端的选型对比目前主流的推理后端有 TensorRT、OpenVINO、ONNX Runtime、TVM 等它们各有侧重。推理后端适用硬件优势局限TensorRTNVIDIA GPU算子融合和量化支持最成熟性能极致绑定 NVIDIA 硬件模型转换有时会失败OpenVINOIntel CPU/GPU/VPUIntel 平台优化好CPU 推理性能强非 Intel 平台支持有限ONNX Runtime跨平台通用性好支持多种后端极致性能不如专用框架TVM跨平台可针对特定硬件自动调优使用门槛高调优耗时我的选型逻辑是如果目标硬件是 NVIDIA GPU优先 TensorRT如果是 Intel CPU优先 OpenVINO如果需要跨平台部署或者快速验证用 ONNX Runtime如果有特殊硬件需要深度定制考虑 TVM。不要试图用一个框架解决所有问题混合使用是常态。6. 实操中的选型逻辑与踩坑记录前面讲了这么多技术点最后这部分我想聊聊实际做优化时的决策逻辑以及我踩过的一些印象深刻的坑。这些经验在官方文档里通常找不到但往往比技术本身更能决定项目的成败。6.1 优化顺序先量化还是先剪枝这个问题我被问过很多次。我的答案是先剪枝再量化。原因在于剪枝改变的是模型结构量化改变的是数值表示。如果先量化再剪枝剪枝后的模型结构变了之前量化时统计的激活值分布可能就不准了需要重新校准。而先剪枝再量化剪枝后的模型结构是确定的量化校准可以一次做到位。但也不是绝对的。如果剪枝率很低比如 10% 以内对激活值分布的影响很小先量化再剪枝也不是不行。另外如果时间紧迫量化是必须做的剪枝是可选的那当然先做量化。核心原则是结构性的改动放在前面数值性的改动放在后面。还有一个顺序问题蒸馏和剪枝的关系。如果你打算同时用蒸馏和剪枝建议先蒸馏再剪枝。因为蒸馏需要一个好的教师模型和一个结构完整的学生模型如果先剪枝把学生模型剪残了蒸馏的效果会大打折扣。6.2 精度掉点排查从数据到算子的逐层定位精度掉点是优化过程中最常见的问题。模型优化完了精度掉了好几个点这时候怎么排查我的排查链路是这样的第一步确认掉点是否来自优化本身。用同样的测试集和测试脚本分别跑优化前和优化后的模型确保对比条件一致。有时候掉点是因为测试脚本的预处理不一致或者测试集本身有变化不一定是优化的锅。第二步定位掉点发生在哪个阶段。如果是量化导致的先检查校准集是否覆盖了所有场景。如果是剪枝导致的检查剪枝率是否过高或者某些关键层被剪了。如果是蒸馏导致的检查温度参数和损失权重是否合理。第三步逐层对比输出。这是最有效但也最耗时的方法。把优化前后的模型每一层的输出都拿出来对比看从哪一层开始出现明显的偏差。找到偏差最大的层重点分析这个层的优化策略是否合适。我遇到过一个案例量化后精度掉了 3 个点逐层对比发现是某个中间层的激活值范围特别大INT8 的表示范围不够用导致大量数值被截断。后来把这个层改成 FP16其他层保持 INT8精度恢复到了只掉 0.5 个点。6.3 硬件适配同一模型在不同芯片上的表现差异同一个模型同样的优化策略在不同硬件上的表现可能天差地别。我做过一个对比实验一个经过 INT8 量化的模型在 NVIDIA T4 上推理延迟是 8ms在另一款推理芯片上是 15ms而在某款边缘设备上直接跑不起来——因为那个设备不支持 INT8 的某些算子。这个实验给我的教训是优化策略必须和硬件绑定。在 GPU 上有效的优化换到 CPU 或专用芯片上可能完全无效甚至起反作用。所以做优化之前一定要先明确目标硬件是什么然后针对这个硬件做针对性的优化。另外硬件的驱动版本和推理框架版本也会影响性能。我遇到过升级驱动之后同样的模型推理速度提升了 20% 的情况。所以保持驱动和框架版本更新有时候能白捡性能提升。6.4 优化效果的评估不要只看单一指标最后聊聊评估。很多人评估优化效果只看模型大小和推理延迟这其实是不够的。一个完整的评估应该包括模型大小、推理延迟、吞吐量、精度、显存占用、功耗。这几个指标之间往往是互相制约的。比如量化降低了模型大小和延迟但可能带来精度损失。剪枝减少了参数量但可能影响吞吐量因为剪枝后的模型结构可能对硬件不友好。所以评估的时候要综合考虑根据业务场景确定哪个指标最重要。如果是移动端场景功耗和模型大小可能是第一优先级。如果是云端服务吞吐量和延迟更重要。如果是精度敏感的场景那精度就是红线任何优化都不能突破这个红线。我一般会先和业务方确认好优先级然后再制定优化方案避免优化完了才发现方向错了。提示做任何优化之前先保存一份原始模型的完整备份包括权重、配置文件和推理脚本。优化过程中随时可以回退到原始版本做对比这是排查问题的基准线。7. 我个人的优化工具箱与日常习惯说了这么多方法论最后分享一些我日常用的工具和习惯。这些不是什么高深的东西但都是长期实践下来觉得真正好用的。模型分析阶段我常用的是 Netron 来看模型结构用 fvcore 或 thop 来统计 FLOPs 和参数量。这两个工具都很轻量装上就能用不需要复杂的配置。Netron 的可视化很直观能快速看出模型里有哪些算子、哪些地方可能存在优化空间。量化工具方面PyTorch 自带的量化工具链已经比较完善了torch.quantization模块支持 PTQ 和 QAT。如果目标硬件是 NVIDIA GPU我会用 TensorRT 的量化工具它的校准和层敏感度分析功能更强大。如果是 Intel CPUOpenVINO 的 POT 工具也很好用。剪枝工具我用得比较多的是 Torch-Pruning 这个库它支持结构化剪枝而且能自动处理层之间的依赖关系不用手动去调整每一层的输入输出通道数。这个库的文档写得也很清楚上手很快。日常习惯方面我有几个坚持了很多年的做法。第一每次优化实验都记录完整的配置和结果包括模型版本、优化参数、硬件环境、测试指标。这些记录在后来排查问题时帮了我大忙。第二优化前后一定要做端到端的精度验证不能只看中间层的指标。第三保持对新技术的好奇心模型优化这个领域发展很快新的量化算法、新的剪枝策略、新的推理框架层出不穷定期看看最新的论文和开源项目能帮你保持技术敏感度。模型优化这件事说到底是一个在约束条件下找最优解的工程问题。没有银弹没有一劳永逸的方案每个模型、每个硬件、每个业务场景都需要针对性地分析和调优。但只要你理解了背后的原理掌握了基本的工具和方法就能在面对新问题时快速找到切入点。希望这些经验对你有帮助少走一些我当年走过的弯路。