在模型训练和部署这条线上摸爬滚打久了你会发现一个很朴素的道理模型效果的上限由数据和架构决定但模型能不能跑得起来、跑得划算、跑得快几乎全看优化这两个字做到什么程度。我去年花了大半年时间打磨了一个内部项目代号就叫 Model-Optimizer一开始它只是我想偷懒写的一套脚本集合后来慢慢长成了覆盖训练加速、推理优化、模型压缩和自动调参的小框架。这篇文章就围绕这个项目展开聊聊我踩过的坑、验证过的方法以及怎么把这些东西落到自己的流程里。不管你手头是 CV 模型、NLP 模型还是多模态模型只要你在为训练太慢、显存放不下、推理扛不住、精度掉太多这些问题头疼这篇文章都值得你花十分钟读完。里面没有玄学都是我在 GPU 集群上调参、把模型塞进边缘设备时攒下来的一线经验。1. Model-Optimizer 到底是什么从一次偷懒开始的工程复盘先说清楚这个项目解决的问题。当时团队在做一个人脸关键点检测模型训练阶段的 loss 一直降不下去后期推理速度也只有 30 FPS 左右离线上要求的 60 FPS 差一大截。我最初的想法很简单把优化器换掉、把算子融合打开、把模型量化一下看看能不能把指标救回来。结果发现每次都要写一堆重复的配置、实验记录和对比脚本于是干脆写了一套工具把模型优化这件事标准化了。1.1 项目定位不是某个单独算法而是一套优化流程Model-Optimizer 不是某个具体的优化算法而是一条从训练到部署的优化流水线。它主要解决三个层次的问题第一层是训练加速即在保证精度不崩的前提下通过优化器选择、学习率调度、混合精度等手段把训练时间压下来第二层是模型瘦身通过剪枝、量化、蒸馏等方法把模型体积和计算量降下来第三层是推理加速通过算子融合、图优化、内存复用等编译期技术把模型在具体硬件上的推理速度提上去。这套东西听起来每个点都不新鲜但真正用起来你会发现难点在于这些优化手段之间会互相影响。比如你把模型量化到 INT8精度下降 0.5%本来是可接受的但如果你同时做了剪枝这两个误差叠加起来可能就变成 2%直接导致线上效果不合格。Model-Optimizer 最核心的价值就是能把这一堆操作编排起来让你看清楚每个环节单独和叠加之后的效果避免优化了个寂寞。1.2 核心使用场景与目标用户这个项目最适合两类人来用。第一类是算法工程师他们训练完模型之后时常要面对把模型部署到手机端或者提高线上吞吐这类需求但又不愿意去啃编译原理和硬件指令集第二类是推理引擎的开发者他们需要一个自动化的基准测试和优化工具链帮他们在不同硬件后端上找到最优配置。我自己的使用经验是Model-Optimizer 把下面这条链路串起来了训练日志分析、优化器选择与超参搜索、模型导出格式统一、离线量化与评估、图优化与算子融合选项搜索、端到端性能回归。每一步的输入输出都是标准化的文件这样团队协作时每个人只需要关心自己负责的那一段。2. 核心细节解析优化器选型、超参配置与训练侧调优如果只看项目名字很多人会以为 Model-Optimizer 只关心训练时的优化器Optimizer比如 Adam、SGD 这类。这确实是项目里最早也最成熟的一部分但它的内涵比单纯换一个优化器要深得多。2.1 优化器家族选型从 SGD 到 AdamW 再到自适应方案现在训练神经网络主流优化器就三大类。SGD 带 Momentum泛化能力最强收敛稳定但对学习率很敏感而且天然不擅长处理稀疏梯度Adam/AdamW自适应学习率训练 Transformer 和大部分 CNN 几乎是无脑首选但业界普遍观察到它收敛到的泛化性能往往不如调好的 SGDLAMB/LARS这类大批次优化器专门为了几百甚至几千的 batch size 设计解决大 batch 下收敛不稳定问题。我在 Model-Optimizer 里内置了一个优化器接口可以一键切换但我更想强调的是选型逻辑。如果你训练的是中小规模 CNN数据量又不算大SGD 加余弦退火通常比 Adam 稳如果你训练的是大规模预训练模型AdamW 配合线性 warmup 是目前最成熟的选择如果你要在几百张卡上同步训练LAMB 几乎是唯一答案。2.2 超参配置学习率、权重衰减、warmup 这些值不是拍脑袋定的关于超参配置我见过最多的错误就是直接抄别人模型的参数。A 模型用的学习率是 1e-4不代表你的模型也能用 1e-4因为学习率跟网络结构、数据量、batch size 都耦合。Model-Optimizer 里实现了一套简单的学习率范围测试Learning Rate Range Test从小学习率到大学习率跑几个 step观察 loss 曲线找到下降最陡的区域作为初始学习率参考值。具体流程是先选一个足够小的学习率比如 1e-6每个 iteration 按指数增大学习率到 1e-1 为止。然后画出 loss 随学习率变化的曲线。一般来说loss 下降最快的点对应的学习率就是最优学习率的上限实际用它的 1/2 到 1/3 比较安全。这个方法成本很低但比拍脑袋强太多。权重衰减也一样。很多人直接设 5e-4但我用网格搜索加早停测过不同任务的敏感度结论是大模型对权重衰减更敏感一版推荐 1e-2 这类相对较大的值配合 AdamW小模型用 5e-4 到 1e-3 比较稳妥。这个差异主要是因为预训练模型的权重大正则化作用会被放大。2.3 混合精度训练AMP 不是简单换精度三个关键开关要注意混合精度训练现在已经是标配NVIDIA 的 apex 或者 PyTorch 自带 AMP 可以一行代码开启。但实际用起来有几个细节不处理好轻则训练不稳定重则 loss 变成 NaN。第一个关键是loss scaling。混合精度训练的原理是前向和反向用 FP16 计算但主权重保存在 FP32。FP16 的表示范围比较窄梯度算出来如果太小会直接变成 0所以标准做法是给 loss 乘一个很大的缩放因子等梯度更新时再除掉。如果你用动态 loss scalingPyTorch 会自动调整这个因子基本不用操心如果你手动设置建议从 128 开始观察梯度是否溢出来调整。第二个关键是FP32 主权重。在 PyTorch 里使用amp的 GradScaler 时参数更新时会把 FP16 梯度转回 FP32然后更新 FP32 的权重副本。这个机制的代价是显存翻倍但换来的稳定性值得。第三个关键是BN 层的精度。BatchNorm 在 FP16 下计算很容易出问题很多框架默认把 BN 保留在 FP32。如果你用的是 NVIDIA 新一代显卡可以尝试用 TF32 来跑卷积这比 FP16 更接近 FP32 的数值范围误差小很多。实测下来TF32 在 Ampere 架构上的速度比 FP32 快 4 到 8 倍但精度几乎无损。3. 推理侧优化量化、剪枝与图优化的完整实操流程训练侧的优化主要是帮你把模型效果好地训出来推理侧优化才是 Model-Optimizer 真正让人感觉超值的地方。模型训完之后部署到线上瓶颈往往不在算力而在内存带宽和延迟约束这时候瘦身和加速就变得非常重要。3.1 模型量化的完整流程离线量化与量化感知训练怎么选我把量化作为 Model-Optimizer 的第一个重点模块因为它是性价比最高的加速手段。以 TensorRT 或者 ONNX Runtime 上的 INT8 量化为参考一个 FP32 的模型量化成 INT8 后模型体积减少 75%在支持的硬件上推理速度通常能提升 1.5 到 3 倍。离线量化PTQ是最省事的路径。你只需要准备一小部分校准数据比如几百张图片或者几千条文本跑一遍推理统计每层的激活值分布然后计算出每个 Tensor 的 scale 和 zero point把 FP32 的权重映射到 INT8。校准数据的选择很关键一定要有代表性覆盖模型实际会遇到的数据分布否则量化后在某些样本上可能出现特别大的精度损失。量化感知训练QAT适合离线量化效果不好的模型。它的原理是在训练过程中就模拟量化的误差让模型自己学会适应低精度。QAT 训练完成之后再导出成 INT8 模型精度损失通常能控制在 1% 以内。代价就是要多花一轮训练时间和不少调参精力。实操过程中我建议先做离线量化如果精度损失在可接受范围就直接用如果不行再考虑 QAT。不要一上来就 QAT训练成本太高。3.2 卷积核剪枝与结构化剪枝选对粒度才能在硬件上真正加速剪枝是另一项常用技术但很多教程只教非结构化剪枝也就是把权重矩阵里绝对值小的元素直接置 0。这种剪枝虽然在理论上能减少计算量实际推理时如果不配合专门的稀疏推理库几乎没有任何加速效果。Model-Optimizer 重点实现的是结构化剪枝。对卷积层来说我们可以把整个卷积核通道剪掉。比如一个卷积层有 64 个卷积核每个卷积核是 3x3x64如果我们认为其中 16 个通道的重要性很低就把这 16 个通道对应的输入和输出通道一并删掉。这一步做起来比听起来复杂关键难题在于图层之间的依赖。你删掉某一层的输出通道下一层的输入通道就必须跟着删所以需要构建一张通道依赖图从输入到输出逐层传递裁剪掩码。这个逻辑我大概写了五百行代码属于项目里比较核心的工程点。实际经验是结构化剪枝可以比较容易地剪掉 20% 到 30% 的通道精度基本不掉。但剪到 50% 以上就需要配合蒸馏或者重新训练来修复精度了。3.3 图优化与算子融合让推理引擎为你自动提速量化、剪枝之后还有一道大菜就是图优化。这个技术对很多算法工程师比较陌生因为做这件事的是推理引擎比如 TensorRT、ONNX Runtime、OpenVINO。图优化的核心思路是算子融合。一个神经网络模型在计算图中包含成百上千个算子每个算子执行时都要从显存或内存读写数据。如果能把这些算子合并成一个中间结果不落内存速度提升非常明显。最常见的融合是 Conv BN ReLU 三合一。这三个算子联合计算在数学上等价于一个卷积然后经过一个特定的仿射变换加截断所以完全可以合成一个算子。TensorRT 会自动做这件事ONNX Runtime 也有对应的优化 pass。Model-Optimizer 做的是在导出模型时提前把 BN 层的参数吸收进卷积层这样导出的 ONNX 图本身就比较干净用任何推理引擎都能得到更好的融合效果。3.4 在 ONNX Runtime 上手动搜索最优优化配置一份实测记录ONNX Runtime 支持很多 session option你需要为不同的模型和硬件找到最优配置组合。Model-Optimizer 实现了一个简单的配置搜索逻辑把优化级别ORT_ENABLE_ALL、执行模式OR 并行还是顺序、线程数、算子供后端CPU 还是 CUDA这些参数组合起来在同一份测试集上逐个跑一遍排出最优组合。以我的一个 ResNet50 分类模型为例默认配置下 CPU 推理延迟是 12 毫秒。我把 graph optimization level 从 basic 改成 all延迟降到了 8 毫秒再开启 parallel execution 并把线程数调到物理核数延迟降到了 5.6 毫秒最后开启 PyTorch 导出 ONNX 时的动态轴优化延迟降到了 5.1 毫秒。这套组合拳打下来比原始模型快了 2.4 倍而且精度几乎无损。4. 性能实测一组成熟模型优化前后的真实对比数据上面讲了这么多理论我挑两组最有代表性的实测数据一组是服务器端 GPU 推理一组是边缘侧 CPU 推理供大家参考。4.1 场景一工业缺陷检测模型在 NVIDIA T4 上的优化对比这个模型是工业质检项目里的一个二分类网络结构接近 ResNet18输入 512x512x3FP32 版本大小 44MB在 T4 上 FP32 推理延迟约 3.8 毫秒。我们依次应用了ONNX 图优化、FP16 推理、TensorRT INT8 量化。最终模型版本为 INT8 TensorRT engine模型大小 11.5MB端到端单张推理延迟降到 1.1 毫秒吞吐量从 263 QPS 提升到 909 QPS。离线校准用了 1000 张产线上的真实缺陷样本分类准确率从优化前的 98.7% 微降到 98.4%在产线可以接受的范围。4.2 场景二语音唤醒词模型在树莓派 4B 上的优化对比这个项目需要把一个关键词识别模型部署到树莓派 4B 上原来模型太大CPU 实时推理跑不动。流程是先用结构化剪枝裁掉 40% 的通道再量化成 INT8最后用 ONNX Runtime 的 CPU 加速。FP32 未裁剪模型大小 12.6MB单次推理 210 毫秒剪枝加量化后模型大小为 3.1MB单次推理降到 46 毫秒。唤醒词检测率从 92% 降到 87%误唤醒率从 
长河君 · 2026/11/3 20:32:30 · 阅读 1.2k 模型优化实战：训练加速、推理优化与模型压缩的完整工程经验
在模型训练和部署这条线上摸爬滚打久了你会发现一个很朴素的道理模型效果的上限由数据和架构决定但模型能不能跑得起来、跑得划算、跑得快几乎全看优化这两个字做到什么程度。我去年花了大半年时间打磨了一个内部项目代号就叫 Model-Optimizer一开始它只是我想偷懒写的一套脚本集合后来慢慢长成了覆盖训练加速、推理优化、模型压缩和自动调参的小框架。这篇文章就围绕这个项目展开聊聊我踩过的坑、验证过的方法以及怎么把这些东西落到自己的流程里。不管你手头是 CV 模型、NLP 模型还是多模态模型只要你在为训练太慢、显存放不下、推理扛不住、精度掉太多这些问题头疼这篇文章都值得你花十分钟读完。里面没有玄学都是我在 GPU 集群上调参、把模型塞进边缘设备时攒下来的一线经验。1. Model-Optimizer 到底是什么从一次偷懒开始的工程复盘先说清楚这个项目解决的问题。当时团队在做一个人脸关键点检测模型训练阶段的 loss 一直降不下去后期推理速度也只有 30 FPS 左右离线上要求的 60 FPS 差一大截。我最初的想法很简单把优化器换掉、把算子融合打开、把模型量化一下看看能不能把指标救回来。结果发现每次都要写一堆重复的配置、实验记录和对比脚本于是干脆写了一套工具把模型优化这件事标准化了。1.1 项目定位不是某个单独算法而是一套优化流程Model-Optimizer 不是某个具体的优化算法而是一条从训练到部署的优化流水线。它主要解决三个层次的问题第一层是训练加速即在保证精度不崩的前提下通过优化器选择、学习率调度、混合精度等手段把训练时间压下来第二层是模型瘦身通过剪枝、量化、蒸馏等方法把模型体积和计算量降下来第三层是推理加速通过算子融合、图优化、内存复用等编译期技术把模型在具体硬件上的推理速度提上去。这套东西听起来每个点都不新鲜但真正用起来你会发现难点在于这些优化手段之间会互相影响。比如你把模型量化到 INT8精度下降 0.5%本来是可接受的但如果你同时做了剪枝这两个误差叠加起来可能就变成 2%直接导致线上效果不合格。Model-Optimizer 最核心的价值就是能把这一堆操作编排起来让你看清楚每个环节单独和叠加之后的效果避免优化了个寂寞。1.2 核心使用场景与目标用户这个项目最适合两类人来用。第一类是算法工程师他们训练完模型之后时常要面对把模型部署到手机端或者提高线上吞吐这类需求但又不愿意去啃编译原理和硬件指令集第二类是推理引擎的开发者他们需要一个自动化的基准测试和优化工具链帮他们在不同硬件后端上找到最优配置。我自己的使用经验是Model-Optimizer 把下面这条链路串起来了训练日志分析、优化器选择与超参搜索、模型导出格式统一、离线量化与评估、图优化与算子融合选项搜索、端到端性能回归。每一步的输入输出都是标准化的文件这样团队协作时每个人只需要关心自己负责的那一段。2. 核心细节解析优化器选型、超参配置与训练侧调优如果只看项目名字很多人会以为 Model-Optimizer 只关心训练时的优化器Optimizer比如 Adam、SGD 这类。这确实是项目里最早也最成熟的一部分但它的内涵比单纯换一个优化器要深得多。2.1 优化器家族选型从 SGD 到 AdamW 再到自适应方案现在训练神经网络主流优化器就三大类。SGD 带 Momentum泛化能力最强收敛稳定但对学习率很敏感而且天然不擅长处理稀疏梯度Adam/AdamW自适应学习率训练 Transformer 和大部分 CNN 几乎是无脑首选但业界普遍观察到它收敛到的泛化性能往往不如调好的 SGDLAMB/LARS这类大批次优化器专门为了几百甚至几千的 batch size 设计解决大 batch 下收敛不稳定问题。我在 Model-Optimizer 里内置了一个优化器接口可以一键切换但我更想强调的是选型逻辑。如果你训练的是中小规模 CNN数据量又不算大SGD 加余弦退火通常比 Adam 稳如果你训练的是大规模预训练模型AdamW 配合线性 warmup 是目前最成熟的选择如果你要在几百张卡上同步训练LAMB 几乎是唯一答案。2.2 超参配置学习率、权重衰减、warmup 这些值不是拍脑袋定的关于超参配置我见过最多的错误就是直接抄别人模型的参数。A 模型用的学习率是 1e-4不代表你的模型也能用 1e-4因为学习率跟网络结构、数据量、batch size 都耦合。Model-Optimizer 里实现了一套简单的学习率范围测试Learning Rate Range Test从小学习率到大学习率跑几个 step观察 loss 曲线找到下降最陡的区域作为初始学习率参考值。具体流程是先选一个足够小的学习率比如 1e-6每个 iteration 按指数增大学习率到 1e-1 为止。然后画出 loss 随学习率变化的曲线。一般来说loss 下降最快的点对应的学习率就是最优学习率的上限实际用它的 1/2 到 1/3 比较安全。这个方法成本很低但比拍脑袋强太多。权重衰减也一样。很多人直接设 5e-4但我用网格搜索加早停测过不同任务的敏感度结论是大模型对权重衰减更敏感一版推荐 1e-2 这类相对较大的值配合 AdamW小模型用 5e-4 到 1e-3 比较稳妥。这个差异主要是因为预训练模型的权重大正则化作用会被放大。2.3 混合精度训练AMP 不是简单换精度三个关键开关要注意混合精度训练现在已经是标配NVIDIA 的 apex 或者 PyTorch 自带 AMP 可以一行代码开启。但实际用起来有几个细节不处理好轻则训练不稳定重则 loss 变成 NaN。第一个关键是loss scaling。混合精度训练的原理是前向和反向用 FP16 计算但主权重保存在 FP32。FP16 的表示范围比较窄梯度算出来如果太小会直接变成 0所以标准做法是给 loss 乘一个很大的缩放因子等梯度更新时再除掉。如果你用动态 loss scalingPyTorch 会自动调整这个因子基本不用操心如果你手动设置建议从 128 开始观察梯度是否溢出来调整。第二个关键是FP32 主权重。在 PyTorch 里使用amp的 GradScaler 时参数更新时会把 FP16 梯度转回 FP32然后更新 FP32 的权重副本。这个机制的代价是显存翻倍但换来的稳定性值得。第三个关键是BN 层的精度。BatchNorm 在 FP16 下计算很容易出问题很多框架默认把 BN 保留在 FP32。如果你用的是 NVIDIA 新一代显卡可以尝试用 TF32 来跑卷积这比 FP16 更接近 FP32 的数值范围误差小很多。实测下来TF32 在 Ampere 架构上的速度比 FP32 快 4 到 8 倍但精度几乎无损。3. 推理侧优化量化、剪枝与图优化的完整实操流程训练侧的优化主要是帮你把模型效果好地训出来推理侧优化才是 Model-Optimizer 真正让人感觉超值的地方。模型训完之后部署到线上瓶颈往往不在算力而在内存带宽和延迟约束这时候瘦身和加速就变得非常重要。3.1 模型量化的完整流程离线量化与量化感知训练怎么选我把量化作为 Model-Optimizer 的第一个重点模块因为它是性价比最高的加速手段。以 TensorRT 或者 ONNX Runtime 上的 INT8 量化为参考一个 FP32 的模型量化成 INT8 后模型体积减少 75%在支持的硬件上推理速度通常能提升 1.5 到 3 倍。离线量化PTQ是最省事的路径。你只需要准备一小部分校准数据比如几百张图片或者几千条文本跑一遍推理统计每层的激活值分布然后计算出每个 Tensor 的 scale 和 zero point把 FP32 的权重映射到 INT8。校准数据的选择很关键一定要有代表性覆盖模型实际会遇到的数据分布否则量化后在某些样本上可能出现特别大的精度损失。量化感知训练QAT适合离线量化效果不好的模型。它的原理是在训练过程中就模拟量化的误差让模型自己学会适应低精度。QAT 训练完成之后再导出成 INT8 模型精度损失通常能控制在 1% 以内。代价就是要多花一轮训练时间和不少调参精力。实操过程中我建议先做离线量化如果精度损失在可接受范围就直接用如果不行再考虑 QAT。不要一上来就 QAT训练成本太高。3.2 卷积核剪枝与结构化剪枝选对粒度才能在硬件上真正加速剪枝是另一项常用技术但很多教程只教非结构化剪枝也就是把权重矩阵里绝对值小的元素直接置 0。这种剪枝虽然在理论上能减少计算量实际推理时如果不配合专门的稀疏推理库几乎没有任何加速效果。Model-Optimizer 重点实现的是结构化剪枝。对卷积层来说我们可以把整个卷积核通道剪掉。比如一个卷积层有 64 个卷积核每个卷积核是 3x3x64如果我们认为其中 16 个通道的重要性很低就把这 16 个通道对应的输入和输出通道一并删掉。这一步做起来比听起来复杂关键难题在于图层之间的依赖。你删掉某一层的输出通道下一层的输入通道就必须跟着删所以需要构建一张通道依赖图从输入到输出逐层传递裁剪掩码。这个逻辑我大概写了五百行代码属于项目里比较核心的工程点。实际经验是结构化剪枝可以比较容易地剪掉 20% 到 30% 的通道精度基本不掉。但剪到 50% 以上就需要配合蒸馏或者重新训练来修复精度了。3.3 图优化与算子融合让推理引擎为你自动提速量化、剪枝之后还有一道大菜就是图优化。这个技术对很多算法工程师比较陌生因为做这件事的是推理引擎比如 TensorRT、ONNX Runtime、OpenVINO。图优化的核心思路是算子融合。一个神经网络模型在计算图中包含成百上千个算子每个算子执行时都要从显存或内存读写数据。如果能把这些算子合并成一个中间结果不落内存速度提升非常明显。最常见的融合是 Conv BN ReLU 三合一。这三个算子联合计算在数学上等价于一个卷积然后经过一个特定的仿射变换加截断所以完全可以合成一个算子。TensorRT 会自动做这件事ONNX Runtime 也有对应的优化 pass。Model-Optimizer 做的是在导出模型时提前把 BN 层的参数吸收进卷积层这样导出的 ONNX 图本身就比较干净用任何推理引擎都能得到更好的融合效果。3.4 在 ONNX Runtime 上手动搜索最优优化配置一份实测记录ONNX Runtime 支持很多 session option你需要为不同的模型和硬件找到最优配置组合。Model-Optimizer 实现了一个简单的配置搜索逻辑把优化级别ORT_ENABLE_ALL、执行模式OR 并行还是顺序、线程数、算子供后端CPU 还是 CUDA这些参数组合起来在同一份测试集上逐个跑一遍排出最优组合。以我的一个 ResNet50 分类模型为例默认配置下 CPU 推理延迟是 12 毫秒。我把 graph optimization level 从 basic 改成 all延迟降到了 8 毫秒再开启 parallel execution 并把线程数调到物理核数延迟降到了 5.6 毫秒最后开启 PyTorch 导出 ONNX 时的动态轴优化延迟降到了 5.1 毫秒。这套组合拳打下来比原始模型快了 2.4 倍而且精度几乎无损。4. 性能实测一组成熟模型优化前后的真实对比数据上面讲了这么多理论我挑两组最有代表性的实测数据一组是服务器端 GPU 推理一组是边缘侧 CPU 推理供大家参考。4.1 场景一工业缺陷检测模型在 NVIDIA T4 上的优化对比这个模型是工业质检项目里的一个二分类网络结构接近 ResNet18输入 512x512x3FP32 版本大小 44MB在 T4 上 FP32 推理延迟约 3.8 毫秒。我们依次应用了ONNX 图优化、FP16 推理、TensorRT INT8 量化。最终模型版本为 INT8 TensorRT engine模型大小 11.5MB端到端单张推理延迟降到 1.1 毫秒吞吐量从 263 QPS 提升到 909 QPS。离线校准用了 1000 张产线上的真实缺陷样本分类准确率从优化前的 98.7% 微降到 98.4%在产线可以接受的范围。4.2 场景二语音唤醒词模型在树莓派 4B 上的优化对比这个项目需要把一个关键词识别模型部署到树莓派 4B 上原来模型太大CPU 实时推理跑不动。流程是先用结构化剪枝裁掉 40% 的通道再量化成 INT8最后用 ONNX Runtime 的 CPU 加速。FP32 未裁剪模型大小 12.6MB单次推理 210 毫秒剪枝加量化后模型大小为 3.1MB单次推理降到 46 毫秒。唤醒词检测率从 92% 降到 87%误唤醒率从