Model-Optimizer实战：量化剪枝与推理加速部署指南

1. 模型优化器到底在解决什么问题第一次接触 Model-Optimizer 这个概念很多人会把它和优化算法比如 SGD、Adam搞混。其实它跟训练时用的优化器完全是两码事。Model-Optimizer 是一类工具链的统称核心目标只有一个在尽量不损失精度的前提下让训练好的模型跑得更快、占得更少、部署更省。你可以把它理解成模型出厂前的“瘦身提速”流水线。我最早接触这类工具是在一个图像分类项目上。当时训练出来的模型在服务器上跑得好好的一放到边缘设备上就卡得没法看——推理一次要 800 多毫秒内存占用接近 2GB。后来用 Model-Optimizer 做了一轮量化加剪枝推理时间直接降到 120 毫秒模型体积从 240MB 压到 60MB精度只掉了 0.8 个百分点。这个收益在真实项目里是相当可观的。所以这篇文章适合谁看如果你手上有训练好的模型正准备往生产环境部署或者你正在做端侧、嵌入式、移动端的推理落地那 Model-Optimizer 这套东西你绕不开。哪怕你只是想让本地跑模型的时候显存别爆这里面的技巧也用得上。我会从整体设计思路讲到具体操作步骤再到踩过的坑尽量把每个环节都讲透。需要先说明一点Model-Optimizer 不是一个单一工具的名字而是一类技术的集合。不同框架下有不同的实现比如 PyTorch 生态里有 TorchScript、FX Graph Mode QuantizationTensorFlow 生态里有 TFLite Converter 和 TF-TRTONNX 生态里有 ONNX Runtime 的量化工具。它们思路相通但操作细节差异不小。下面我主要以 PyTorch 和 ONNX 这两条最常用的路线来展开其他框架你可以类比迁移。2. 整体设计思路与方案选型拆解2.1 为什么不能直接拿训练好的模型去部署训练和推理是两个完全不同的场景。训练时我们关心的是梯度能不能顺利回传、数值稳不稳定、batch 能不能开大推理时关心的是延迟、吞吐、内存占用、功耗。训练框架为了支持自动求导和动态图会保留大量推理时根本用不到的计算节点和中间变量。这就好比你要搬家训练阶段是把整个仓库都搬走推理阶段其实只需要搬走真正要用的那几件家具。具体来说训练好的模型直接部署会面临几个典型问题。第一是计算图冗余比如 Dropout 层在推理时应该被去掉BatchNorm 应该被折叠进卷积但原始模型里这些节点还在。第二是数值精度过剩训练时用 FP32 是为了梯度稳定推理时 FP16 甚至 INT8 往往就够了。第三是算子实现不最优训练框架的算子为了通用性做了很多妥协推理引擎可以针对特定硬件做深度优化。Model-Optimizer 要做的就是把这些冗余和浪费一层层剥掉。它的设计思路可以概括为三步图优化 → 精度压缩 → 硬件适配。图优化负责去掉无用节点、合并可合并的算子精度压缩负责把 FP32 降到 FP16 或 INT8硬件适配负责把算子映射到目标设备的最优实现上。这三步是有先后顺序的先做图优化再做量化效果通常比反过来好因为图优化之后计算图更干净量化时需要考虑的边界情况更少。2.2 量化、剪枝、蒸馏到底该选哪个Model-Optimizer 这个大类下面最常用的三种手段是量化Quantization、剪枝Pruning和知识蒸馏Knowledge Distillation。很多人一上来就纠结选哪个其实它们解决的问题不一样很多时候是组合使用的。量化是把模型参数和激活值从高精度浮点降到低精度表示。FP32 降到 FP16 是最安全的几乎不掉精度模型体积直接减半推理速度在支持 FP16 的硬件上能提升 1.5 到 2 倍。INT8 量化更激进体积能压到四分之一速度提升 2 到 4 倍但精度损失需要仔细控制。量化的优势是通用性强、落地成本低基本上任何模型都能做所以我一般建议把它作为第一步。剪枝是把模型中不重要的权重或通道去掉。这里有个反直觉的点神经网络里大量权重其实接近零去掉它们对输出影响很小。剪枝分非结构化剪枝和结构化剪枝前者把单个权重置零后者直接砍掉整个通道或层。非结构化剪枝压缩率高但需要专门硬件支持才能加速结构化剪枝压缩率低一些但通用性好。剪枝的难点在于找到合适的剪枝比例剪多了精度崩剪少了没效果。知识蒸馏是让一个小模型去学大模型的输出分布。它不改变原模型结构而是训练一个新模型。蒸馏的效果取决于教师模型的质量和学生模型的能力上限适合你有充足训练资源、且对模型结构有重新设计空间的场景。下面这张表可以帮你快速判断该用哪种手段手段压缩效果精度影响落地难度适用场景FP16 量化体积减半速度 1.5-2x几乎无损低几乎所有模型INT8 量化体积 1/4速度 2-4x可控通常 1%中分类、检测、NLP结构化剪枝体积减 30-50%需微调恢复中高通道冗余大的 CNN非结构化剪枝体积减 70-90%需微调恢复高有稀疏硬件支持知识蒸馏取决于学生模型取决于训练高有重训练资源我的经验是先做 FP16 量化拿到免费收益再评估是否需要 INT8最后才考虑剪枝和蒸馏。这个顺序能让你用最小成本拿到大部分收益避免一上来就做复杂操作结果精度崩了还得回滚。2.3 精度和速度的平衡点怎么找这是 Model-Optimizer 最核心的取舍问题。没有免费的午餐压缩率越高精度损失风险越大。关键是要找到一个可接受的精度下限然后在这个约束下最大化压缩率。我的做法是先定一个精度容忍度。比如分类任务如果原始模型 Top-1 准确率是 95%那我可以接受降到 94.5%也就是 0.5 个百分点的损失。然后从这个约束出发逐步增加压缩强度每加一档就测一次精度直到精度掉到临界点为止。这个过程叫精度-压缩率曲线扫描虽然费时间但能帮你找到最优工作点。还有一个容易被忽略的点不同层对量化的敏感度差异很大。第一层和最后一层通常最敏感中间层相对鲁棒。所以混合精度量化是个好策略——敏感层保持 FP16其他层用 INT8。PyTorch 的 FX Graph Mode 和 ONNX Runtime 都支持这种按层配置精度的方式。3. 核心细节解析与实操要点3.1 计算图优化先把模型“洗干净”在动量化之前一定要先做计算图优化。这一步不做后面量化会引入很多不必要的误差。计算图优化主要包括算子融合、常量折叠、死代码消除这几类操作。算子融合是最重要的一项。最常见的融合模式是 Conv BatchNorm ReLU 融成一个算子。为什么这个融合这么关键因为 BatchNorm 在推理时本质上是一个线性变换它的参数可以完全吸收进前面的卷积权重里。融合之后原本三次内存读写变成一次延迟能降 20% 到 30%。我实测过一个 ResNet-50光做 Conv-BN-ReLU 融合推理速度就提升了 25%。常量折叠是把计算图中所有输入固定的子图提前算好。比如模型里有些形状计算、索引计算输入是常量那这些计算完全可以在导出阶段就算完不用留到运行时。这个优化对动态图模型尤其重要。死代码消除是去掉推理时用不到的节点。最典型的是 Dropout训练时随机置零推理时应该直接透传。还有像训练专用的损失计算分支、梯度相关节点都应该在导出时清掉。在 PyTorch 里做这些优化最方便的方式是用torch.fx做图追踪然后手动或自动地应用优化 pass。也可以用torch.jit.trace或torch.jit.script导出 TorchScriptTorchScript 的编译器会自动做一部分融合。但要注意trace方式对动态控制流支持不好如果模型里有 if-else 分支建议用script。注意做图优化之前一定要先model.eval()把模型切到推理模式。否则 BatchNorm 会用训练时的统计量Dropout 还会随机置零导出的图就是错的。3.2 量化实操从 FP32 到 INT8 的完整路径量化是 Model-Optimizer 里收益最直接的一步。我以 PyTorch 的 FX Graph Mode Quantization 为例把完整流程走一遍。第一步是准备模型和校准数据。量化需要一个校准集来统计激活值的分布范围通常从训练集里抽 100 到 500 个样本就够了。校准集要覆盖真实数据的分布不能只用一类样本否则统计出来的范围会偏。第二步是配置量化方案。PyTorch 提供两种模式Post Training QuantizationPTQ和 Quantization Aware TrainingQAT。PTQ 不需要重新训练速度快适合大多数场景QAT 在训练时模拟量化误差精度更高但需要重新训练几个 epoch。我的建议是先用 PTQ 试如果精度掉太多再上 QAT。第三步是指定量化配置。这里要决定哪些层量化、用什么精度。默认配置是权重用 INT8、激活用 INT8但你可以把敏感层排除掉。下面是一段典型的配置代码import torch from torch.ao.quantization.quantize_fx import prepare_fx, convert_fx from torch.ao.quantization import QConfigMapping # 定义量化配置 qconfig_mapping QConfigMapping().set_global( torch.ao.quantization.get_default_qconfig(fbgemm) ) # 指定不量化的层 qconfig_mapping.set_module_name(classifier, None) # 准备模型 model.eval() example_inputs (torch.randn(1, 3, 224, 224),) prepared_model prepare_fx(model, qconfig_mapping, example_inputs) # 用校准数据跑一遍 with torch.no_grad(): for data in calib_loader: prepared_model(data) # 转换为量化模型 quantized_model convert_fx(prepared_model)第四步是验证精度。量化完一定要在验证集上跑一遍对比原始模型的精度。如果掉得太多可以尝试调整量化配置比如把某些层改成 FP16或者换用 QAT。这里有个细节值得展开fbgemm和qnnpack是两种不同的量化后端。fbgemm针对 x86 服务器优化qnnpack针对 ARM 移动端优化。选错了后端量化模型可能跑不起来或者性能很差。我一般会在服务器上用fbgemm移动端用qnnpack导出时分别处理。3.3 剪枝的粒度选择与敏感度分析剪枝比量化更“暴力”因为它直接改变了模型结构。做剪枝之前必须先做敏感度分析搞清楚每一层对剪枝的容忍度。敏感度分析的做法是逐层尝试不同的剪枝比例观察精度变化。比如对某一层分别剪 10%、20%、30%、40%看精度掉多少。掉得慢的层可以多剪掉得快的层少剪或不剪。这个分析虽然费时间但能避免盲目剪枝导致精度崩溃。剪枝的粒度选择也很关键。非结构化剪枝把单个权重置零压缩率高但需要稀疏矩阵运算支持才能加速普通硬件上反而可能变慢。结构化剪枝直接砍掉整个通道压缩率低一些但通用性好任何硬件都能加速。我一般优先选结构化剪枝除非目标硬件明确支持稀疏计算。PyTorch 里可以用torch.nn.utils.prune做剪枝但它主要是非结构化的。结构化剪枝需要自己实现或者用第三方库。一个简单的结构化剪枝思路是计算每个通道的权重 L2 范数把范数最小的通道整条砍掉然后微调恢复精度。剪枝后一定要微调。剪枝相当于给模型做了一次“手术”微调是让模型重新适应新的结构。微调的学习率要设小一点通常是原始训练学习率的十分之一训练 5 到 10 个 epoch 就够了。3.4 导出与部署ONNX 还是 TorchScript优化完的模型要导出成部署格式。主流选择是 ONNX 和 TorchScript两者各有优劣。ONNX的优势是跨框架、跨平台几乎所有推理引擎都支持。ONNX Runtime 的优化能力很强支持图优化、量化、算子融合一条龙。缺点是某些自定义算子导出可能有问题动态形状支持也不如 TorchScript 灵活。TorchScript的优势是和 PyTorch 生态无缝衔接动态形状支持好自定义算子容易集成。缺点是跨框架能力弱基本只能在 PyTorch 生态里用。我的选择标准是如果部署环境是 ONNX Runtime、TensorRT 这类通用推理引擎就导出 ONNX如果部署环境是 PyTorch 自己的推理框架或者模型里有复杂的动态控制流就用 TorchScript。导出 ONNX 的时候有个常见坑opset 版本选择。opset 版本太低不支持某些算子太高可能推理引擎还不支持。我一般用 opset 13 到 15 之间兼容性和功能比较平衡。导出命令大概是这样torch.onnx.export( model, dummy_input, model.onnx, opset_version14, input_names[input], output_names[output], dynamic_axes{input: {0: batch_size}} )导出之后一定要用onnx.checker验证一下模型合法性再用onnxruntime跑一遍对比输出确保导出没有引入误差。4. 完整实操流程与关键环节实现4.1 环境准备与依赖安装动手之前先把环境搭好。我以 PyTorch 路线为例列出需要装的包pip install torch torchvision pip install onnx onnxruntime pip install onnxruntime-tools pip install neural-compressorneural-compressor是 Intel 开源的一个 Model-Optimizer 工具包集成了量化、剪枝、蒸馏等能力用起来比较省心。如果你不想自己写量化配置可以直接用它的一键量化 API。环境搭好之后先确认一下硬件支持情况。INT8 量化在 x86 上依赖 VNNI 指令集在 ARM 上依赖 dotprod 指令集。可以用lscpu查看 CPU 标志位如果没有对应指令集INT8 量化可能不会加速甚至变慢。4.2 一个完整的量化剪枝实战案例我拿一个实际的图像分类模型来演示完整流程。假设我们有一个训练好的 ResNet-18目标是部署到 x86 服务器上要求推理延迟降低 3 倍以上精度损失不超过 1%。第一步基线测试。先测原始模型的延迟和精度作为对比基准。import time import torch model.eval() model model.cuda() # 预热 for _ in range(10): _ model(torch.randn(1, 3, 224, 224).cuda()) # 测延迟 torch.cuda.synchronize() start time.time() for _ in range(100): _ model(torch.randn(1, 3, 224, 224).cuda()) torch.cuda.synchronize() print(f平均延迟: {(time.time() - start) / 100 * 1000:.2f} ms)假设基线是 45ms精度 94.2%。第二步图优化。用torch.fx做算子融合把 Conv-BN-ReLU 融掉。这一步通常能带来 20% 左右的提速而且精度无损。第三步INT8 量化。用 FX Graph Mode 做 PTQ校准集用 200 张训练图。量化后测精度假设掉到 93.8%损失 0.4 个百分点在容忍范围内。第四步结构化剪枝。对中间层做 20% 的通道剪枝然后微调 5 个 epoch。剪枝后模型更小但精度可能再掉一点假设微调后恢复到 93.5%。第五步导出 ONNX。把优化后的模型导出成 ONNX用 ONNX Runtime 加载开启图优化和 INT8 执行提供器。第六步最终测试。在 ONNX Runtime 上测延迟假设降到 12ms相比基线 45ms 提升了 3.75 倍精度 93.5%损失 0.7 个百分点。目标达成。这个流程里每一步的收益和代价都要记录清楚方便后续调优。我习惯用一个表格来跟踪阶段延迟精度模型体积基线45ms94.2%45MB图优化后36ms94.2%45MBINT8 量化后15ms93.8%12MB剪枝微调后12ms93.5%8MB4.3 校准集构建的讲究校准集的质量直接决定量化精度。我见过太多人随便拿几张图做校准结果量化后精度崩了还以为是量化方法不行。其实问题出在校准集上。校准集要满足几个条件。第一是数量足够太少统计不准太多浪费时间100 到 500 个样本是比较合适的区间。第二是分布覆盖要包含各类别的样本不能只拿某一类。第三是预处理一致校准时的预处理必须和推理时完全一致包括归一化参数、resize 方式等。还有一个进阶技巧用真实数据而不是训练数据做校准。如果训练数据和线上数据分布有差异用线上数据校准效果更好。我做过一个对比实验用训练数据校准量化后精度掉 1.2%用线上数据校准只掉 0.3%差距很明显。4.4 混合精度量化的配置方法混合精度量化是平衡精度和速度的利器。核心思路是敏感层用高精度不敏感层用低精度。怎么判断哪些层敏感前面说的敏感度分析可以用在这里。在 ONNX Runtime 里可以通过QuantizationConfig指定每层的精度。在 PyTorch 里可以用QConfigMapping的set_module_name方法逐层配置。下面是一个混合精度配置的例子qconfig_mapping QConfigMapping() # 默认 INT8 qconfig_mapping.set_global(torch.ao.quantization.get_default_qconfig(fbgemm)) # 第一层和最后一层用 FP16 qconfig_mapping.set_module_name(conv1, torch.ao.quantization.float16_static_qconfig) qconfig_mapping.set_module_name(fc, torch.ao.quantization.float16_static_qconfig)实测下来这种配置能在精度损失减少一半的情况下只牺牲 10% 到 15% 的速度收益性价比很高。5. 常见问题与排查技巧实录5.1 量化后精度暴跌怎么排查精度暴跌是量化最常见的问题。排查思路要按顺序来不要一上来就怀疑量化方法。先查校准集。校准集数量够不够分布全不全预处理对不对我遇到过好几次都是校准集的问题换了校准集精度就回来了。再查敏感层。用逐层量化对比的方式找出哪些层量化后误差最大。把这些层排除掉或者改成 FP16通常能解决大部分精度问题。然后查量化配置。fbgemm和qnnpack选对了吗per-tensor 还是 per-channelper-channel 量化精度更高但某些硬件不支持。如果精度要求高优先用 per-channel。最后查模型本身。有些模型结构对量化天然不友好比如含有大量小数值激活的模型。这种情况下可能需要 QAT 才能救回来。5.2 推理速度没提升反而变慢量化后变慢通常有几个原因。第一是硬件不支持 INT8 加速比如老 CPU 没有 VNNI 指令集INT8 计算反而要走模拟路径比 FP32 还慢。第二是算子没有真正量化有些算子量化后端不支持会 fallback 到 FP32导致频繁的数据类型转换开销更大。第三是量化粒度太细per-channel 量化在某些硬件上需要额外的重排操作反而拖慢速度。排查方法是先用 profiling 工具看每个算子的耗时找出瓶颈在哪。ONNX Runtime 可以用onnxruntime_perf_test做 profilingPyTorch 可以用torch.profiler。5.3 导出 ONNX 报错怎么办ONNX 导出报错是另一个高频问题。常见原因和解决方法我整理成了一张表报错类型常见原因解决方法不支持的算子用了 ONNX 没有的自定义算子注册自定义算子或改用标准算子动态形状错误输入形状不确定指定 dynamic_axes 或固定形状类型不匹配输入类型和模型期望不一致检查 dummy_input 的 dtypeopset 版本问题算子需要更高 opset提高 opset_version我踩过最坑的一次是模型里用了torch.nn.functional.interpolate的align_cornersFalse模式ONNX 导出后结果和 PyTorch 不一致。后来发现是 ONNX 的 resize 算子和 PyTorch 的实现有细微差异改成align_cornersTrue就对齐了。这种数值对齐问题很隐蔽导出后一定要做输出对比。5.4 剪枝后模型无法收敛剪枝后微调不收敛通常是剪得太狠了。剪枝比例要循序渐进不要一次剪太多。我的经验是单次剪枝不超过 30%剪完立即微调微调后再评估是否需要继续剪。另一个原因是微调学习率太大。剪枝后模型结构变了大的学习率会让模型震荡。学习率要降到原始训练的十分之一甚至更低用 cosine 衰减策略慢慢收敛。还有一个容易忽略的点剪枝后 BatchNorm 的统计量要重新校准。剪枝改变了通道数原来的 running mean 和 running var 不再适用。微调时让 BatchNorm 重新统计或者手动重置再统计。5.5 常见问题速查表问题现象可能原因排查方向量化后精度掉 2%校准集问题/敏感层未排除换校准集逐层排查量化后速度无提升硬件不支持/算子未量化查 CPU 指令集做 profilingONNX 导出失败自定义算子/动态形状换算子指定 dynamic_axes剪枝后不收敛剪枝比例过大/学习率过大降低剪枝比例和学习率推理结果不一致数值精度差异/算子实现差异逐层对比输出定位差异层显存占用没降中间激活未优化开启内存复用用推理专用引擎最后分享一个我常用的技巧做任何优化之前先把基线数据完整记录下来包括延迟、精度、内存、模型体积。优化过程中每做一步就记录一次这样出问题能快速定位是哪一步引入的也方便回滚。6. 工具选型与生态对比6.1 主流 Model-Optimizer 工具横向对比市面上做模型优化的工具不少各有侧重。我把自己用过的几个整理一下方便你按需选择。PyTorch 原生工具链FX Graph Mode、TorchScript的优势是和 PyTorch 无缝集成量化、图优化都能做社区活跃文档齐全。缺点是 ONNX 导出偶尔有坑跨框架能力弱。ONNX Runtime的优势是跨框架、跨平台优化能力强支持多种执行提供器CPU、GPU、TensorRT 等。量化工具onnxruntime.quantization用起来很简单几行代码就能做 PTQ。缺点是某些自定义算子支持不好。Neural Compressor是 Intel 开源的集成了量化、剪枝、蒸馏、自动调优支持 PyTorch、TensorFlow、ONNX 多种前端。它的自动调优功能很省心能自动搜索最优量化配置。缺点是文档偏工程化上手门槛稍高。TensorRT是 NVIDIA 的推理优化引擎针对 NVIDIA GPU 做了深度优化性能极强。支持 FP16、INT8、稀疏化。缺点是绑定 NVIDIA 硬件跨平台能力弱。OpenVINO是 Intel 的推理优化工具针对 Intel CPU、GPU、VPU 优化。支持模型转换、量化、图优化。缺点是主要面向 Intel 硬件。选型建议如果部署在 NVIDIA GPU 上优先 TensorRT如果部署在 Intel CPU 上优先 OpenVINO 或 Neural Compressor如果需要跨平台优先 ONNX Runtime如果不想引入额外依赖用 PyTorch 原生工具链。6.2 自动调优工具的使用体验手动调量化配置很费时间自动调优工具能省不少事。Neural Compressor 的自动调优我用得比较多它的思路是给定精度容忍度自动搜索最优量化配置。用法大概是这样from neural_compressor.config import PostTrainingQuantConfig from neural_compressor.quantization import fit # 定义精度容忍度 config PostTrainingQuantConfig( accuracy_criterion{relative: 0.01} # 允许 1% 精度损失 ) # 自动调优 q_model fit( modelmodel, confconfig, calib_dataloadercalib_loader, eval_funceval_func )它会自动尝试不同的量化方案找到满足精度约束的最优配置。实测下来自动调优的结果通常比手动配置好因为它能逐层搜索最优精度组合。缺点是调优过程比较慢可能需要跑几十轮评估。6.3 不同硬件平台的优化策略差异硬件平台不同优化策略差异很大。x86 服务器上INT8 量化配合 VNNI 指令集能获得最大收益重点做算子融合和 INT8 量化。ARM 移动端上重点做模型瘦身和功耗优化INT8 量化用qnnpack后端剪枝比例可以更激进。NVIDIA GPU 上FP16 和 INT8 都有很好的支持TensorRT 能自动做算子融合和精度校准重点是用好 TensorRT 的 INT8 校准工具。边缘 NPU 上情况更复杂不同厂商的 NPU 支持的算子和精度都不一样通常需要专门的模型转换工具。这种情况下建议先用厂商提供的工具做转换和量化再用通用工具做补充优化。7. 我踩过的坑和实操心得做模型优化这几年踩过的坑不少挑几个有代表性的说说。第一个坑以为量化是免费的。刚开始做量化的时候我觉得 FP32 降到 INT8 就是简单地把数值范围映射一下能有什么损失。结果第一次做 INT8 量化精度直接掉了 5 个百分点。后来才明白量化误差会在层与层之间累积尤其是激活值分布不均匀的层量化误差特别大。从那以后我每次量化前都做敏感度分析再也不敢盲目全量量化了。第二个坑忽略校准集的代表性。有一次做量化校准集只用了 50 张图而且都是同一类别的。量化后在验证集上精度还行一上线上就崩了。原因是校准集没覆盖线上数据的分布量化参数统计偏了。后来我把校准集扩到 300 张覆盖所有类别问题就解决了。第三个坑剪枝后忘记重置 BatchNorm。剪枝改变了通道数BatchNorm 的 running 统计量失效了但我忘了重置直接微调结果模型一直不收敛。排查了半天才发现是 BatchNorm 的问题。重置之后重新统计很快就收敛了。第四个坑ONNX 导出后没做数值对比。有一次导出 ONNX 后直接部署结果推理结果和 PyTorch 对不上。排查发现是某个算子的实现差异导致的。从那以后我导出 ONNX 后一定做逐层输出对比确保数值一致再部署。第五个坑在错误的硬件上做量化。有一次在开发机上做 INT8 量化开发机 CPU 不支持 VNNI量化后速度反而变慢了。后来换到支持 VNNI 的服务器上速度才提上来。所以做量化前一定要确认目标硬件的指令集支持情况。这些坑说到底都是细节问题但每一个都能让你白干好几天。我的建议是每做一步优化都做完整测试不要跳步不要想当然。优化是个精细活急不得。最后再分享一个实用技巧如果你不确定该从哪一步开始优化就先做 profiling找出模型推理的瓶颈在哪。是计算密集还是内存密集是某个算子特别慢还是整体都慢搞清楚瓶颈再针对性优化比盲目上量化剪枝效率高得多。我一般用torch.profiler或onnxruntime_perf_test做 profiling几分钟就能定位问题。