尧图网站建设 
1. 模型优化器到底在解决什么问题第一次接触 Model-Optimizer 这个概念是在一个推荐系统的项目里。当时模型训练完离线指标 AUC 看着还行一上线推理延迟直接飙到 800msQPS 连预期的三分之一都不到。团队一开始想的是加机器后来发现加机器只是把问题往后拖——单次推理的计算量摆在那里堆硬件成本翻倍但收益有限。真正把延迟压下来的是对模型本身做了一轮系统性的优化算子融合、量化、剪枝、图优化一套组合拳下来延迟降到 120ms模型体积缩了 70%精度只掉了 0.3 个百分点。这就是 Model-Optimizer 存在的意义。它不是一个具体的库或者工具而是一类技术方案的统称——在保证模型精度可接受的前提下通过一系列变换手段让模型跑得更快、占得更少、部署更省。你可以把它理解成给模型做体能训练不是换一个更强的运动员而是让现有的运动员跑得更经济、更高效。适合谁来关注这块内容三类人最需要一是做模型部署的工程师天天被推理延迟和显存占用折磨二是算法工程师模型训出来发现落不了地三是做端侧 AI 的开发者手机、嵌入式设备上那点算力不优化根本跑不动。不管你用的是 PyTorch、TensorFlow 还是 ONNX Runtime优化思路是相通的。我下面要聊的是从实战角度拆解 Model-Optimizer 的完整技术链路——为什么这么选、每一步怎么做、踩过哪些坑、参数怎么定。内容偏工程落地不搞纯理论推导能直接抄作业的部分我会尽量写清楚。2. 优化方案的整体设计与选型逻辑2.1 先搞清楚优化目标延迟、吞吐还是体积很多人一上来就问用什么量化方案最好这个问题本身就问错了。优化的第一步不是选工具而是明确你的瓶颈到底在哪。延迟敏感、吞吐敏感、体积敏感对应的优化策略完全不同。我一般用下面这张表来快速定位优化目标典型场景优先手段次要手段单次推理延迟实时交互、自动驾驶算子融合、图优化量化、剪枝吞吐量离线批处理、推荐召回量化、批处理优化算子融合模型体积端侧部署、OTA 升级量化、剪枝知识蒸馏显存占用大模型推理量化、KV Cache 优化算子融合训练速度大模型微调混合精度、梯度检查点分布式优化这张表是我踩了不少坑之后总结的。早期我做过一个语音识别的端侧项目一上来就上剪枝结果模型体积是小了但推理速度反而变慢——因为剪枝后的稀疏结构在移动端 CPU 上没有对应的加速库支持反而引入了额外的索引开销。后来换成 INT8 量化体积和速度同时改善。优化手段和硬件平台是强绑定的脱离部署环境谈优化方案都是耍流氓。2.2 优化手段的优先级排序我的经验是优化要按投入产出比排序而不是按技术时髦度排序。下面是我常用的优先级图优化与算子融合几乎无损收益稳定应该最先做。把多个小算子合并成一个大算子减少 kernel launch 开销和中间张量的读写。量化收益最大的一环FP32 到 INT8 理论上能带来 4 倍的内存带宽节省和 2-4 倍的计算加速。但精度风险也最大需要仔细校准。剪枝适合参数冗余度高的模型但需要硬件和推理框架支持稀疏计算才能真正加速。知识蒸馏用大模型教小模型适合需要重新设计网络结构的场景周期长但上限高。编译优化TVM、TensorRT 这类编译器自动做算子融合和调度优化属于交给工具的部分。注意不要一次性把所有手段全上。每加一种优化都要重新评估精度和性能否则出了问题根本定位不到是哪一步引入的。2.3 为什么选择渐进式优化而不是一步到位我见过太多团队想一步到位直接上 INT4 量化加结构化剪枝结果精度崩了回头排查花了两周。渐进式优化的核心逻辑是控制变量每做一步优化记录精度变化和性能变化建立一条清晰的因果链。具体做法是维护一个优化记录表类似这样阶段优化手段精度变化延迟变化体积变化baseline无100%100%100%step1算子融合-0.05%-35%0%step2INT8 量化-0.4%-60%-75%step3结构化剪枝 20%-0.8%-15%-20%有了这张表你随时可以回退到任意一个阶段也能清楚知道每个手段的真实贡献。这套方法论我在三个不同项目里用过每次都能在精度和性能之间找到那个甜点。3. 核心优化手段的细节拆解与实操要点3.1 算子融合最稳的第一刀算子融合的原理不复杂。深度学习模型的计算图里很多相邻的小算子其实可以合并。比如Conv2D BatchNorm ReLU这三个操作推理阶段 BatchNorm 的参数是固定的完全可以折叠进 Conv 的权重里ReLU 作为激活函数直接接在后面。融合之后原本三次内存读写变成一次kernel launch 从三次变成一次。在 PyTorch 里做这件事最直接的方式是torch.jit.trace加torch.jit.freeze然后导出到 ONNX 或 TensorRT。但这里有个坑不是所有算子都能被自动融合。我遇到过自定义的激活函数导致融合失败最后是手动改写模型结构把能融合的部分显式合并。手动融合 ConvBN 的代码大概长这样import torch import torch.nn as nn def fuse_conv_bn(conv, bn): fused_conv nn.Conv2d( conv.in_channels, conv.out_channels, kernel_sizeconv.kernel_size, strideconv.stride, paddingconv.padding, biasTrue ) # BN 的均值方差折叠进卷积权重 bn_std torch.sqrt(bn.running_var bn.eps) fused_conv.weight.data conv.weight.data * (bn.weight / bn_std).reshape(-1, 1, 1, 1) fused_conv.bias.data (conv.bias - bn.running_mean) * bn.weight / bn_std bn.bias return fused_conv这段代码的关键在于理解 BN 在推理阶段的本质它就是一个逐通道的线性变换。把(x - mean) / std * gamma beta展开和卷积的W * x b合并就能得到新的权重和偏置。实测下来单这一项在 ResNet50 上就能带来 15%-20% 的延迟下降。实操心得融合前一定要把模型切到eval()模式否则 BN 用的是 batch 统计量融合结果会错得离谱。这个坑我踩过一次排查了半天才发现是模式没切。3.2 量化收益最大也最容易翻车量化是把 FP32 的权重和激活值用更低比特表示常见的是 INT8。核心公式是real_value scale * (quantized_value - zero_point)scale是缩放因子zero_point是零点偏移。这两个参数决定了量化的精度。计算方式有对称量化和非对称量化两种对称量化 zero_point 固定为 0适合权重非对称量化适合激活值因为激活值的分布通常不对称。量化的难点在于校准。你需要一批有代表性的数据跑一遍模型统计每一层激活值的分布然后确定 scale 和 zero_point。校准集的选择直接决定量化精度。我的经验是校准集样本量 500-1000 条足够太多收益递减校准集分布必须和真实推理数据一致否则量化误差会放大优先用训练集的子集而不是随机噪声PyTorch 的量化 API 分动态量化和静态量化。动态量化只量化权重激活值在推理时动态计算 scale适合 LSTM、Transformer 这类模型静态量化权重和激活都量化需要校准适合 CNN。import torch.quantization as tq # 静态量化流程 model.eval() model.qconfig tq.get_default_qconfig(fbgemm) model_prepared tq.prepare(model, inplaceFalse) # 校准 with torch.no_grad(): for data in calibration_loader: model_prepared(data) model_quantized tq.convert(model_prepared, inplaceFalse)fbgemm是 x86 平台的量化后端ARM 平台用qnnpack。选错后端会导致量化后的模型根本跑不起来或者性能还不如 FP32。量化精度损失的控制我一般遵循这个原则逐层量化逐层验证。先量化权重看精度掉多少再量化激活看掉多少。如果某一层特别敏感就把它排除在量化范围外保持 FP32。这种混合精度量化在 Transformer 上特别有用注意力层的 softmax 和 layernorm 通常对量化很敏感。3.3 剪枝结构化和非结构化的抉择剪枝是把模型中不重要的权重或结构去掉。分两种非结构化剪枝把单个权重置零稀疏度高但需要专门硬件支持才能加速结构化剪枝把整个通道或整个层去掉直接改变模型结构通用硬件都能加速我现在的项目基本只用结构化剪枝原因很现实非结构化剪枝在通用 GPU 和 CPU 上加速效果很差除非你有支持稀疏计算的专用加速器。结构化剪枝虽然压缩率低一些但收益是实打实的。结构化剪枝的关键是评估通道重要性。常用指标有 L1 范数、L2 范数、BN 的 gamma 值。BN gamma 剪枝是我用得最多的因为 BN 的缩放因子在训练中会自动学习到每个通道的重要性gamma 接近零的通道基本可以安全去掉。# 基于 BN gamma 的通道剪枝 def prune_by_bn_gamma(model, threshold0.01): for name, module in model.named_modules(): if isinstance(module, nn.BatchNorm2d): gamma module.weight.data.abs() mask gamma threshold # 根据 mask 裁剪对应通道 # 实际实现需要同步裁剪上下游层 return model剪枝最麻烦的地方是上下游层的同步裁剪。你剪了 Conv 的输出通道后面 BN 的通道数要跟着变再后面的 Conv 输入通道也要变。手动做很容易出错建议用现成的库比如torch.nn.utils.prune或者nni的剪枝模块。注意剪枝后一定要做微调。剪枝相当于给模型做了手术精度必然下降微调 10-20 个 epoch 通常能把精度拉回来大部分。微调时的学习率要调小一般是原始学习率的十分之一。3.4 知识蒸馏换个思路做优化知识蒸馏不是压缩现有模型而是训练一个更小的学生模型去模仿大模型的行为。损失函数通常是学生输出和教师输出的 KL 散度加上学生和真实标签的交叉熵。温度参数 T 是蒸馏的核心超参。T 越大教师输出的软标签分布越平滑学生能学到的暗知识越多。但 T 太大也会导致信息模糊。我的经验是 T 取 3-5 比较合适配合 alpha 权重 0.7 左右教师损失占 0.7真实标签损失占 0.3。蒸馏适合的场景是你有充足算力训练大模型但部署环境只能跑小模型。比如 BERT-base 蒸馏到 6 层的小模型精度能保留 97% 左右推理速度翻倍。4. 完整实操流程与关键环节实现4.1 环境准备与基线测量优化之前必须先建立可靠的基线。我见过有人优化了半天结果发现基线测量本身就不准白忙一场。基线测量要记录这几个指标推理延迟用time.perf_counter()测跑 100 次取平均前 10 次作为 warmup 丢弃吞吐量固定 batch size测每秒处理样本数显存占用torch.cuda.max_memory_allocated()模型体积保存后的文件大小精度指标任务相关的指标分类用 accuracy检测用 mAPimport time import torch def measure_latency(model, input_tensor, warmup10, runs100): model.eval() with torch.no_grad(): for _ in range(warmup): model(input_tensor) torch.cuda.synchronize() start time.perf_counter() for _ in range(runs): model(input_tensor) torch.cuda.synchronize() end time.perf_counter() return (end - start) / runs * 1000 # mstorch.cuda.synchronize()这行很关键。CUDA 是异步执行的不加同步测出来的时间是 kernel launch 的时间不是实际计算时间。这个坑我早期踩过测出来的延迟比实际低了一个数量级。4.2 优化流水线的搭建我的标准优化流水线是这样的导出 ONNX 模型用onnxsim做初步的图简化用 ONNX Runtime 或 TensorRT 做算子融合和图优化在优化后的图上做量化校准评估精度如果掉太多回退到混合精度如果还需要压缩做结构化剪枝加微调最终导出部署格式导出 ONNX 的时候有个细节要注意动态轴的处理。如果你的模型支持变长输入导出时要显式指定 dynamic axes否则 ONNX 会把输入 shape 固定死。torch.onnx.export( model, dummy_input, model.onnx, input_names[input], output_names[output], dynamic_axes{input: {0: batch, 1: sequence}, output: {0: batch}}, opset_version13 )opset_version建议用 13 或更高低版本对某些算子支持不好。但也不是越高越好要看你部署环境的 ONNX Runtime 版本支持到哪。4.3 量化校准的实操细节校准是量化里最需要耐心的环节。我一般这样做class CalibrationDataLoader: def __init__(self, data, batch_size8): self.data data self.batch_size batch_size def __iter__(self): for i in range(0, len(self.data), self.batch_size): batch self.data[i:iself.batch_size] yield torch.stack(batch) # 校准过程 model.eval() model.qconfig torch.quantization.get_default_qconfig(fbgemm) model_fp32_prepared torch.quantization.prepare(model) calib_loader CalibrationDataLoader(calib_samples) with torch.no_grad(): for batch in calib_loader: model_fp32_prepared(batch) model_int8 torch.quantization.convert(model_fp32_prepared)校准完之后一定要做逐层精度对比。把 FP32 和 INT8 模型在同一个测试集上跑逐层对比输出差异。如果某一层的余弦相似度低于 0.99这层就是敏感层考虑保留 FP32。我做过一个实验在 BERT 上逐层分析量化敏感度发现层类型量化后余弦相似度是否建议量化Embedding0.998是Attention QKV0.995是Attention Softmax0.972否FFN0.996是LayerNorm0.981谨慎Softmax 和 LayerNorm 是量化敏感区这两个地方保留 FP32其余量化整体精度能提升 1-2 个百分点而性能损失很小。4.4 剪枝与微调的配合剪枝的实操流程我总结成四步训练一个精度达标的基线模型分析各层的重要性确定剪枝比例执行剪枝得到稀疏模型微调恢复精度剪枝比例不能一刀切。浅层特征提取层通常冗余度低剪多了精度崩深层语义层冗余度高可以多剪。我的经验是浅层剪 10%-20%深层剪 30%-50%。微调的时候有个技巧冻结未剪枝的层只训练剪枝后的层。这样收敛更快也不容易破坏原有特征。微调学习率用原始学习率的 0.1训练 15-20 个 epoch精度基本能恢复到剪枝前的 98% 以上。5. 常见问题与排查技巧实录5.1 量化后精度暴跌怎么排查这是最高频的问题。我的排查顺序是检查校准集分布是否和真实数据一致样本量够不够检查 qconfig后端选对了吗x86 用 fbgemmARM 用 qnnpack逐层对比找出敏感层排除量化检查算子支持有些算子不支持量化会被自动跳过导致前后不一致有一次我遇到量化后精度掉了 15 个点排查半天发现是校准集用了归一化前的数据而模型训练时用的是归一化后的。这种低级错误最容易犯也最难发现。5.2 优化后模型反而变慢的原因优化后变慢通常有三个原因算子融合失败某些自定义算子阻断了融合反而增加了图复杂度量化反量化开销混合精度量化时FP32 和 INT8 之间的转换有开销如果转换太频繁得不偿失硬件不支持某些优化后的算子在目标硬件上没有加速实现排查方法是做 profiling用torch.profiler或者nsys看每个算子的耗时找出真正的瓶颈。5.3 常见问题速查表问题现象可能原因解决方案量化后精度掉 5%校准集分布不对换用真实推理数据做校准量化后模型跑不起来后端选错x86 用 fbgemmARM 用 qnnpack剪枝后精度无法恢复剪枝比例过高降低剪枝比例增加微调 epoch融合后延迟没降融合未生效检查算子是否支持融合ONNX 导出失败opset 版本低升级 opset 到 13推理结果和训练不一致BN 模式问题确保 eval 模式导出5.4 几个容易被忽略的细节第一个是输入预处理的一致性。优化后的模型对输入分布更敏感如果预处理有细微差异量化误差会被放大。我一般会把预处理也固化进模型图里避免部署时的差异。第二个是 batch size 的影响。量化模型在小 batch 下的加速比通常不如大 batch因为量化反量化的固定开销被摊薄了。如果你的场景是单样本推理量化收益可能没想象中那么大。第三个是版本兼容性。PyTorch、ONNX、ONNX Runtime、TensorRT 之间的版本兼容性是个大坑。我建议锁定一套验证过的版本组合不要轻易升级。下面是我目前用着比较稳的一套torch2.1.0 onnx1.14.0 onnxruntime1.16.0 tensorrt8.6.1这套组合在 CNN 和 Transformer 上都验证过量化、剪枝、融合都能正常工作。6. 优化效果的评估与持续迭代优化不是一次性的工作模型在迭代优化策略也要跟着调整。我一般会建立一个自动化的评估流水线每次模型更新后自动跑一遍优化和评估输出对比报告。评估维度我固定看四个精度、延迟、吞吐、体积。四个指标画成雷达图一眼就能看出这次优化是全面进步还是拆东墙补西墙。如果精度掉了但延迟没降多少这次优化就是失败的直接回退。还有一点优化后的模型要重新做一遍完整的测试不能只测精度。我遇到过量化后模型在某些边界输入上输出 NaN 的情况正常测试集上完全看不出来。所以边界测试、异常输入测试都要补上。最后分享一个我常用的技巧把优化配置写成 YAML 文件不同模型用不同配置避免每次手动改代码。配置里记录每种优化手段的参数和开关方便做 A/B 对比。这套配置管理方式让我在多个项目之间切换时省了大量重复劳动也让优化过程变得可复现、可追溯。 Model-Optimizer实战：算子融合、量化与剪枝的渐进式优化链路
1. 模型优化器到底在解决什么问题第一次接触 Model-Optimizer 这个概念是在一个推荐系统的项目里。当时模型训练完离线指标 AUC 看着还行一上线推理延迟直接飙到 800msQPS 连预期的三分之一都不到。团队一开始想的是加机器后来发现加机器只是把问题往后拖——单次推理的计算量摆在那里堆硬件成本翻倍但收益有限。真正把延迟压下来的是对模型本身做了一轮系统性的优化算子融合、量化、剪枝、图优化一套组合拳下来延迟降到 120ms模型体积缩了 70%精度只掉了 0.3 个百分点。这就是 Model-Optimizer 存在的意义。它不是一个具体的库或者工具而是一类技术方案的统称——在保证模型精度可接受的前提下通过一系列变换手段让模型跑得更快、占得更少、部署更省。你可以把它理解成给模型做体能训练不是换一个更强的运动员而是让现有的运动员跑得更经济、更高效。适合谁来关注这块内容三类人最需要一是做模型部署的工程师天天被推理延迟和显存占用折磨二是算法工程师模型训出来发现落不了地三是做端侧 AI 的开发者手机、嵌入式设备上那点算力不优化根本跑不动。不管你用的是 PyTorch、TensorFlow 还是 ONNX Runtime优化思路是相通的。我下面要聊的是从实战角度拆解 Model-Optimizer 的完整技术链路——为什么这么选、每一步怎么做、踩过哪些坑、参数怎么定。内容偏工程落地不搞纯理论推导能直接抄作业的部分我会尽量写清楚。2. 优化方案的整体设计与选型逻辑2.1 先搞清楚优化目标延迟、吞吐还是体积很多人一上来就问用什么量化方案最好这个问题本身就问错了。优化的第一步不是选工具而是明确你的瓶颈到底在哪。延迟敏感、吞吐敏感、体积敏感对应的优化策略完全不同。我一般用下面这张表来快速定位优化目标典型场景优先手段次要手段单次推理延迟实时交互、自动驾驶算子融合、图优化量化、剪枝吞吐量离线批处理、推荐召回量化、批处理优化算子融合模型体积端侧部署、OTA 升级量化、剪枝知识蒸馏显存占用大模型推理量化、KV Cache 优化算子融合训练速度大模型微调混合精度、梯度检查点分布式优化这张表是我踩了不少坑之后总结的。早期我做过一个语音识别的端侧项目一上来就上剪枝结果模型体积是小了但推理速度反而变慢——因为剪枝后的稀疏结构在移动端 CPU 上没有对应的加速库支持反而引入了额外的索引开销。后来换成 INT8 量化体积和速度同时改善。优化手段和硬件平台是强绑定的脱离部署环境谈优化方案都是耍流氓。2.2 优化手段的优先级排序我的经验是优化要按投入产出比排序而不是按技术时髦度排序。下面是我常用的优先级图优化与算子融合几乎无损收益稳定应该最先做。把多个小算子合并成一个大算子减少 kernel launch 开销和中间张量的读写。量化收益最大的一环FP32 到 INT8 理论上能带来 4 倍的内存带宽节省和 2-4 倍的计算加速。但精度风险也最大需要仔细校准。剪枝适合参数冗余度高的模型但需要硬件和推理框架支持稀疏计算才能真正加速。知识蒸馏用大模型教小模型适合需要重新设计网络结构的场景周期长但上限高。编译优化TVM、TensorRT 这类编译器自动做算子融合和调度优化属于交给工具的部分。注意不要一次性把所有手段全上。每加一种优化都要重新评估精度和性能否则出了问题根本定位不到是哪一步引入的。2.3 为什么选择渐进式优化而不是一步到位我见过太多团队想一步到位直接上 INT4 量化加结构化剪枝结果精度崩了回头排查花了两周。渐进式优化的核心逻辑是控制变量每做一步优化记录精度变化和性能变化建立一条清晰的因果链。具体做法是维护一个优化记录表类似这样阶段优化手段精度变化延迟变化体积变化baseline无100%100%100%step1算子融合-0.05%-35%0%step2INT8 量化-0.4%-60%-75%step3结构化剪枝 20%-0.8%-15%-20%有了这张表你随时可以回退到任意一个阶段也能清楚知道每个手段的真实贡献。这套方法论我在三个不同项目里用过每次都能在精度和性能之间找到那个甜点。3. 核心优化手段的细节拆解与实操要点3.1 算子融合最稳的第一刀算子融合的原理不复杂。深度学习模型的计算图里很多相邻的小算子其实可以合并。比如Conv2D BatchNorm ReLU这三个操作推理阶段 BatchNorm 的参数是固定的完全可以折叠进 Conv 的权重里ReLU 作为激活函数直接接在后面。融合之后原本三次内存读写变成一次kernel launch 从三次变成一次。在 PyTorch 里做这件事最直接的方式是torch.jit.trace加torch.jit.freeze然后导出到 ONNX 或 TensorRT。但这里有个坑不是所有算子都能被自动融合。我遇到过自定义的激活函数导致融合失败最后是手动改写模型结构把能融合的部分显式合并。手动融合 ConvBN 的代码大概长这样import torch import torch.nn as nn def fuse_conv_bn(conv, bn): fused_conv nn.Conv2d( conv.in_channels, conv.out_channels, kernel_sizeconv.kernel_size, strideconv.stride, paddingconv.padding, biasTrue ) # BN 的均值方差折叠进卷积权重 bn_std torch.sqrt(bn.running_var bn.eps) fused_conv.weight.data conv.weight.data * (bn.weight / bn_std).reshape(-1, 1, 1, 1) fused_conv.bias.data (conv.bias - bn.running_mean) * bn.weight / bn_std bn.bias return fused_conv这段代码的关键在于理解 BN 在推理阶段的本质它就是一个逐通道的线性变换。把(x - mean) / std * gamma beta展开和卷积的W * x b合并就能得到新的权重和偏置。实测下来单这一项在 ResNet50 上就能带来 15%-20% 的延迟下降。实操心得融合前一定要把模型切到eval()模式否则 BN 用的是 batch 统计量融合结果会错得离谱。这个坑我踩过一次排查了半天才发现是模式没切。3.2 量化收益最大也最容易翻车量化是把 FP32 的权重和激活值用更低比特表示常见的是 INT8。核心公式是real_value scale * (quantized_value - zero_point)scale是缩放因子zero_point是零点偏移。这两个参数决定了量化的精度。计算方式有对称量化和非对称量化两种对称量化 zero_point 固定为 0适合权重非对称量化适合激活值因为激活值的分布通常不对称。量化的难点在于校准。你需要一批有代表性的数据跑一遍模型统计每一层激活值的分布然后确定 scale 和 zero_point。校准集的选择直接决定量化精度。我的经验是校准集样本量 500-1000 条足够太多收益递减校准集分布必须和真实推理数据一致否则量化误差会放大优先用训练集的子集而不是随机噪声PyTorch 的量化 API 分动态量化和静态量化。动态量化只量化权重激活值在推理时动态计算 scale适合 LSTM、Transformer 这类模型静态量化权重和激活都量化需要校准适合 CNN。import torch.quantization as tq # 静态量化流程 model.eval() model.qconfig tq.get_default_qconfig(fbgemm) model_prepared tq.prepare(model, inplaceFalse) # 校准 with torch.no_grad(): for data in calibration_loader: model_prepared(data) model_quantized tq.convert(model_prepared, inplaceFalse)fbgemm是 x86 平台的量化后端ARM 平台用qnnpack。选错后端会导致量化后的模型根本跑不起来或者性能还不如 FP32。量化精度损失的控制我一般遵循这个原则逐层量化逐层验证。先量化权重看精度掉多少再量化激活看掉多少。如果某一层特别敏感就把它排除在量化范围外保持 FP32。这种混合精度量化在 Transformer 上特别有用注意力层的 softmax 和 layernorm 通常对量化很敏感。3.3 剪枝结构化和非结构化的抉择剪枝是把模型中不重要的权重或结构去掉。分两种非结构化剪枝把单个权重置零稀疏度高但需要专门硬件支持才能加速结构化剪枝把整个通道或整个层去掉直接改变模型结构通用硬件都能加速我现在的项目基本只用结构化剪枝原因很现实非结构化剪枝在通用 GPU 和 CPU 上加速效果很差除非你有支持稀疏计算的专用加速器。结构化剪枝虽然压缩率低一些但收益是实打实的。结构化剪枝的关键是评估通道重要性。常用指标有 L1 范数、L2 范数、BN 的 gamma 值。BN gamma 剪枝是我用得最多的因为 BN 的缩放因子在训练中会自动学习到每个通道的重要性gamma 接近零的通道基本可以安全去掉。# 基于 BN gamma 的通道剪枝 def prune_by_bn_gamma(model, threshold0.01): for name, module in model.named_modules(): if isinstance(module, nn.BatchNorm2d): gamma module.weight.data.abs() mask gamma threshold # 根据 mask 裁剪对应通道 # 实际实现需要同步裁剪上下游层 return model剪枝最麻烦的地方是上下游层的同步裁剪。你剪了 Conv 的输出通道后面 BN 的通道数要跟着变再后面的 Conv 输入通道也要变。手动做很容易出错建议用现成的库比如torch.nn.utils.prune或者nni的剪枝模块。注意剪枝后一定要做微调。剪枝相当于给模型做了手术精度必然下降微调 10-20 个 epoch 通常能把精度拉回来大部分。微调时的学习率要调小一般是原始学习率的十分之一。3.4 知识蒸馏换个思路做优化知识蒸馏不是压缩现有模型而是训练一个更小的学生模型去模仿大模型的行为。损失函数通常是学生输出和教师输出的 KL 散度加上学生和真实标签的交叉熵。温度参数 T 是蒸馏的核心超参。T 越大教师输出的软标签分布越平滑学生能学到的暗知识越多。但 T 太大也会导致信息模糊。我的经验是 T 取 3-5 比较合适配合 alpha 权重 0.7 左右教师损失占 0.7真实标签损失占 0.3。蒸馏适合的场景是你有充足算力训练大模型但部署环境只能跑小模型。比如 BERT-base 蒸馏到 6 层的小模型精度能保留 97% 左右推理速度翻倍。4. 完整实操流程与关键环节实现4.1 环境准备与基线测量优化之前必须先建立可靠的基线。我见过有人优化了半天结果发现基线测量本身就不准白忙一场。基线测量要记录这几个指标推理延迟用time.perf_counter()测跑 100 次取平均前 10 次作为 warmup 丢弃吞吐量固定 batch size测每秒处理样本数显存占用torch.cuda.max_memory_allocated()模型体积保存后的文件大小精度指标任务相关的指标分类用 accuracy检测用 mAPimport time import torch def measure_latency(model, input_tensor, warmup10, runs100): model.eval() with torch.no_grad(): for _ in range(warmup): model(input_tensor) torch.cuda.synchronize() start time.perf_counter() for _ in range(runs): model(input_tensor) torch.cuda.synchronize() end time.perf_counter() return (end - start) / runs * 1000 # mstorch.cuda.synchronize()这行很关键。CUDA 是异步执行的不加同步测出来的时间是 kernel launch 的时间不是实际计算时间。这个坑我早期踩过测出来的延迟比实际低了一个数量级。4.2 优化流水线的搭建我的标准优化流水线是这样的导出 ONNX 模型用onnxsim做初步的图简化用 ONNX Runtime 或 TensorRT 做算子融合和图优化在优化后的图上做量化校准评估精度如果掉太多回退到混合精度如果还需要压缩做结构化剪枝加微调最终导出部署格式导出 ONNX 的时候有个细节要注意动态轴的处理。如果你的模型支持变长输入导出时要显式指定 dynamic axes否则 ONNX 会把输入 shape 固定死。torch.onnx.export( model, dummy_input, model.onnx, input_names[input], output_names[output], dynamic_axes{input: {0: batch, 1: sequence}, output: {0: batch}}, opset_version13 )opset_version建议用 13 或更高低版本对某些算子支持不好。但也不是越高越好要看你部署环境的 ONNX Runtime 版本支持到哪。4.3 量化校准的实操细节校准是量化里最需要耐心的环节。我一般这样做class CalibrationDataLoader: def __init__(self, data, batch_size8): self.data data self.batch_size batch_size def __iter__(self): for i in range(0, len(self.data), self.batch_size): batch self.data[i:iself.batch_size] yield torch.stack(batch) # 校准过程 model.eval() model.qconfig torch.quantization.get_default_qconfig(fbgemm) model_fp32_prepared torch.quantization.prepare(model) calib_loader CalibrationDataLoader(calib_samples) with torch.no_grad(): for batch in calib_loader: model_fp32_prepared(batch) model_int8 torch.quantization.convert(model_fp32_prepared)校准完之后一定要做逐层精度对比。把 FP32 和 INT8 模型在同一个测试集上跑逐层对比输出差异。如果某一层的余弦相似度低于 0.99这层就是敏感层考虑保留 FP32。我做过一个实验在 BERT 上逐层分析量化敏感度发现层类型量化后余弦相似度是否建议量化Embedding0.998是Attention QKV0.995是Attention Softmax0.972否FFN0.996是LayerNorm0.981谨慎Softmax 和 LayerNorm 是量化敏感区这两个地方保留 FP32其余量化整体精度能提升 1-2 个百分点而性能损失很小。4.4 剪枝与微调的配合剪枝的实操流程我总结成四步训练一个精度达标的基线模型分析各层的重要性确定剪枝比例执行剪枝得到稀疏模型微调恢复精度剪枝比例不能一刀切。浅层特征提取层通常冗余度低剪多了精度崩深层语义层冗余度高可以多剪。我的经验是浅层剪 10%-20%深层剪 30%-50%。微调的时候有个技巧冻结未剪枝的层只训练剪枝后的层。这样收敛更快也不容易破坏原有特征。微调学习率用原始学习率的 0.1训练 15-20 个 epoch精度基本能恢复到剪枝前的 98% 以上。5. 常见问题与排查技巧实录5.1 量化后精度暴跌怎么排查这是最高频的问题。我的排查顺序是检查校准集分布是否和真实数据一致样本量够不够检查 qconfig后端选对了吗x86 用 fbgemmARM 用 qnnpack逐层对比找出敏感层排除量化检查算子支持有些算子不支持量化会被自动跳过导致前后不一致有一次我遇到量化后精度掉了 15 个点排查半天发现是校准集用了归一化前的数据而模型训练时用的是归一化后的。这种低级错误最容易犯也最难发现。5.2 优化后模型反而变慢的原因优化后变慢通常有三个原因算子融合失败某些自定义算子阻断了融合反而增加了图复杂度量化反量化开销混合精度量化时FP32 和 INT8 之间的转换有开销如果转换太频繁得不偿失硬件不支持某些优化后的算子在目标硬件上没有加速实现排查方法是做 profiling用torch.profiler或者nsys看每个算子的耗时找出真正的瓶颈。5.3 常见问题速查表问题现象可能原因解决方案量化后精度掉 5%校准集分布不对换用真实推理数据做校准量化后模型跑不起来后端选错x86 用 fbgemmARM 用 qnnpack剪枝后精度无法恢复剪枝比例过高降低剪枝比例增加微调 epoch融合后延迟没降融合未生效检查算子是否支持融合ONNX 导出失败opset 版本低升级 opset 到 13推理结果和训练不一致BN 模式问题确保 eval 模式导出5.4 几个容易被忽略的细节第一个是输入预处理的一致性。优化后的模型对输入分布更敏感如果预处理有细微差异量化误差会被放大。我一般会把预处理也固化进模型图里避免部署时的差异。第二个是 batch size 的影响。量化模型在小 batch 下的加速比通常不如大 batch因为量化反量化的固定开销被摊薄了。如果你的场景是单样本推理量化收益可能没想象中那么大。第三个是版本兼容性。PyTorch、ONNX、ONNX Runtime、TensorRT 之间的版本兼容性是个大坑。我建议锁定一套验证过的版本组合不要轻易升级。下面是我目前用着比较稳的一套torch2.1.0 onnx1.14.0 onnxruntime1.16.0 tensorrt8.6.1这套组合在 CNN 和 Transformer 上都验证过量化、剪枝、融合都能正常工作。6. 优化效果的评估与持续迭代优化不是一次性的工作模型在迭代优化策略也要跟着调整。我一般会建立一个自动化的评估流水线每次模型更新后自动跑一遍优化和评估输出对比报告。评估维度我固定看四个精度、延迟、吞吐、体积。四个指标画成雷达图一眼就能看出这次优化是全面进步还是拆东墙补西墙。如果精度掉了但延迟没降多少这次优化就是失败的直接回退。还有一点优化后的模型要重新做一遍完整的测试不能只测精度。我遇到过量化后模型在某些边界输入上输出 NaN 的情况正常测试集上完全看不出来。所以边界测试、异常输入测试都要补上。最后分享一个我常用的技巧把优化配置写成 YAML 文件不同模型用不同配置避免每次手动改代码。配置里记录每种优化手段的参数和开关方便做 A/B 对比。这套配置管理方式让我在多个项目之间切换时省了大量重复劳动也让优化过程变得可复现、可追溯。