1. 模型优化器到底在解决什么问题第一次接触 Model-Optimizer 这个概念是在一个推荐系统的排序模型上。当时线上推理延迟死活压不下去单次请求要跑 180ms业务方要求降到 80ms 以内。我试过换更小的模型、砍特征、加机器效果都不理想——换小模型掉点太狠加机器成本又扛不住。后来一位做推理优化的朋友点了我一句你为什么不从优化器层面看看模型训练完之后权重里其实藏着大量冗余优化器就是干这个的。这句话让我重新理解了 Model-Optimizer 的定位。它不是一个训练框架也不是一个推理引擎而是介于训练和部署之间的一层“精加工车间”。训练出来的模型权重往往是稠密的、冗余的、精度过高的直接拿去部署既浪费显存又拖慢速度。Model-Optimizer 要做的就是在尽量不损失精度的前提下把模型压缩、量化、剪枝、蒸馏让它变得又小又快。具体来说一个完整的 Model-Optimizer 通常覆盖这几件事量化把 FP32 权重压成 INT8 甚至 INT4、剪枝去掉不重要的连接或通道、知识蒸馏用大模型教小模型、结构重参数化把多分支合并成单路、算子融合把多个小算子合成一个大算子。这些技术单独拎出来都不新鲜但 Model-Optimizer 的价值在于把它们工程化、流水线化让你不用自己从零写 CUDA kernel也不用自己推导量化公式。这篇文章适合谁看如果你是把模型训完就丢给工程团队部署的算法同学看完你会知道部署同学到底在抱怨什么如果你是负责推理性能的工程同学看完你能拿到一套可复现的优化流程和踩坑清单如果你只是好奇为什么同一个模型别人跑得比你快那这篇也能给你答案。我会尽量少讲公式多讲“为什么这么选”和“实际怎么操作”把我在几个真实项目里趟过的路摊开来说。2. 优化器的核心思路与方案选型2.1 为什么不能只靠“换个更小的模型”很多人对模型优化的第一反应是直接训个小模型不就行了这个思路在有些场景下成立但在大多数业务场景里行不通。原因很简单——小模型不是大模型的等比缩小版它的表达能力有硬上限。你从 BERT-base 换到 BERT-tiny参数量掉了 90%但某些细粒度的语义区分能力可能直接崩掉掉点不是线性的而是断崖式的。Model-Optimizer 的思路完全不同。它不改变模型的“知识容量”而是改变知识的“存储和计算方式”。打个比方一本 500 页的书你要把它塞进一个只能装 200 页的文件夹。换小模型相当于重新写一本 200 页的简写版内容必然丢失而量化剪枝相当于把书里的废话删掉、把长句压缩、把重复内容合并核心信息还在只是表达更紧凑了。这个区别决定了优化器的技术路线保精度优先压体积其次。所有优化手段都要围绕“精度损失可控”这个前提来设计否则优化出来的模型没法上线等于白干。2.2 量化、剪枝、蒸馏三条路怎么选这三条路不是互斥的实际项目里经常组合使用但入门时得先搞清楚各自的适用场景和代价。量化是性价比最高的一条路。它把 FP32 的权重和激活值映射到低比特整数域显存直接降 4 倍FP32 到 INT8推理速度通常能提升 2-4 倍。量化的核心难点在于校准——你得用一批有代表性的数据跑一遍统计每一层激活值的动态范围确定缩放因子scale和零点zero point。校准集选得不好量化误差会累积精度掉得莫名其妙。剪枝分结构化和非结构化两种。非结构化剪枝把单个权重置零理论上压缩率高但通用硬件跑不出加速因为 GPU 对稀疏矩阵的支持有限。结构化剪枝直接砍掉整个通道或注意力头压缩后是规整的稠密矩阵硬件友好但精度损失相对大。我一般建议先做结构化剪枝把冗余通道砍掉再做量化两步叠加效果最好。知识蒸馏是另一条路用一个大的 teacher 模型指导小的 student 模型训练。它不压缩已有模型而是重新训一个小的。蒸馏的坑在于 teacher 和 student 的容量差距不能太大否则 student 学不动。而且蒸馏需要重新训练时间成本高适合有充足算力和训练数据的场景。下面这张表是我在实际选型时用的判断依据优化手段压缩率精度损失是否需要重训硬件加速效果适用场景INT8 量化4x低1%否校准即可显著绝大多数推理场景INT4 量化8x中1-3%否需校准显著显存极度受限结构化剪枝2-4x中是微调中等通道冗余明显的模型非结构化剪枝5-10x低是微调依赖硬件有稀疏加速支持的平台知识蒸馏自定义可控是完整训练取决于 student有训练资源的场景2.3 优化流水线的顺序为什么很重要这几步的先后顺序不是随便排的。我踩过的最大坑就是顺序搞反导致优化效果大打折扣。正确的顺序通常是先剪枝再量化最后做算子融合。原因在于剪枝会改变模型结构如果先量化再剪枝剪枝后的通道对应的量化参数就失效了得重新校准。而算子融合放在最后是因为它依赖最终的模型结构前面的步骤改了结构融合方案就得跟着变。还有一个细节剪枝之后一定要做微调fine-tune哪怕只跑几个 epoch。剪枝相当于给模型做了“手术”切掉了部分连接模型需要重新适应。不微调直接量化精度会雪上加霜。我一般剪枝后微调 3-5 个 epoch学习率调到原来的十分之一效果比较稳。3. 核心细节解析与实操要点3.1 量化校准集怎么选才不翻车校准集是量化的命门。我见过太多人随便拿几百条训练数据当校准集结果线上精度掉得离谱。校准集的核心要求是分布代表性它要能覆盖线上真实请求的输入分布。具体怎么选我的做法是从线上日志里采样而不是从训练集里采样。训练集和线上数据的分布往往有偏移用训练集校准等于用错误的尺子量衣服。采样量不用太多500-1000 条足够但要保证覆盖各个业务场景。比如推荐场景要覆盖不同用户活跃度、不同物品类目NLP 场景要覆盖不同长度、不同领域的文本。校准算法本身也有讲究。最常用的是MinMax 校准取激活值的最大最小值确定范围简单但对离群值敏感。如果某层激活值有个别极端值整个量化范围会被拉大导致正常值被压缩到很窄的区间精度损失严重。这时候可以用KL 散度校准或百分位校准前者最小化量化前后的分布差异后者直接截断极端百分位。实测下来KL 校准在 Transformer 类模型上效果最好百分位校准在 CNN 上更稳。注意校准集一定要和推理时的预处理保持一致。我遇到过一次校准用的是未归一化的数据推理时做了归一化结果量化参数完全对不上精度直接崩了。3.2 剪枝粒度与敏感度分析剪枝不是无脑砍得先做敏感度分析。每一层对精度的贡献不一样有些层砍 50% 都没事有些层砍 10% 就崩。敏感度分析的做法是逐层尝试不同的剪枝比例观察验证集精度的变化画出敏感度曲线。我通常把层分成三类高敏感层剪枝比例控制在 10% 以内、中敏感层20-30%、低敏感层可以到 50%。第一层和最后一层通常最敏感中间的重复结构层最不敏感。Transformer 里注意力头的冗余度比 FFN 层高可以优先剪注意力头。剪枝粒度上通道剪枝是最实用的。它直接砍掉整个卷积核或整个注意力头剪完还是规整的矩阵。相比之下权重剪枝虽然压缩率高但需要专门的稀疏计算库支持通用性差。通道剪枝的关键是重要性评分常用的有 L1 范数、L2 范数、BN 层缩放因子。我实测下来用 BN 层的 gamma 系数做评分最准因为它直接反映了该通道对输出的贡献。剪枝完记得做迭代剪枝不要一次砍到位。一次砍太多模型直接废掉微调也救不回来。我一般分 3-4 轮每轮砍 10-15%砍完微调再砍下一轮。这样精度曲线是平滑下降的可控性强。3.3 算子融合的收益与边界算子融合是把多个连续的小算子合并成一个大的 kernel减少 kernel launch 开销和中间结果的显存读写。在 GPU 上kernel launch 的开销其实不小一个模型如果有几百个小算子光 launch 就占了不少时间。最常见的融合模式是Conv BN ReLU三合一。训练时 BN 是独立层推理时 BN 的参数可以完全折叠进 Conv 的权重里变成一个带偏置的卷积再接 ReLU。这样三个算子变一个中间不需要存 BN 的输出显存和延迟都省了。另一个高频模式是LayerNorm 残差连接的融合在 Transformer 里收益很大。LayerNorm 涉及均值方差计算单独跑要读一遍写一遍融合后可以在寄存器里完成。但融合不是越多越好。融合的前提是算子之间的数据依赖是线性的、无分支的。如果中间有分支、有动态控制流强行融合会改变语义。而且融合后的 kernel 太大寄存器压力上升反而可能降低 occupancy。我一般只融合那些“确定安全且收益明显”的模式不追求极致。4. 完整实操流程与关键环节4.1 环境准备与依赖确认动手之前先把环境理清楚。Model-Optimizer 这类工具通常依赖特定版本的深度学习框架和推理引擎版本不匹配是最高频的翻车原因。以主流的 PyTorch 生态为例你需要确认这几样PyTorch 版本、CUDA 版本、推理引擎版本如 TensorRT、ONNX Runtime、以及优化器工具本身的版本。我建议用 conda 建独立环境把版本锁死避免和系统里的其他项目冲突。conda create -n model-opt python3.10 conda activate model-opt pip install torch2.1.0 torchvision0.16.0 pip install onnx1.15.0 onnxruntime-gpu1.17.0装完之后先跑一个最小验证加载一个预训练模型导出 ONNX再用推理引擎加载一遍确认整条链路通。这一步花十分钟能省掉后面几小时的排查。提示CUDA 版本和推理引擎版本必须严格对应。TensorRT 8.6 对应 CUDA 11.8TensorRT 10 对应 CUDA 12.x装错了会在加载引擎时报莫名其妙的错。4.2 基线测量先知道优化前是什么样优化之前必须测基线否则你根本不知道优化有没有效果。基线要测三个指标精度在验证集上的准确率/F1 等、延迟单次推理耗时要测 P50 和 P99、显存占用峰值显存。测延迟时有个细节一定要用固定输入尺寸并且预热足够次数。GPU 有频率爬升的过程前几次推理会偏慢。我一般预热 50 次再测 200 次取平均。P99 延迟比平均延迟更重要因为它反映了最差情况线上超时通常发生在 P99。import torch import time model.eval().cuda() dummy_input torch.randn(1, 3, 224, 224).cuda() # 预热 with torch.no_grad(): for _ in range(50): model(dummy_input) # 测延迟 latencies [] with torch.no_grad(): for _ in range(200): torch.cuda.synchronize() start time.perf_counter() model(dummy_input) torch.cuda.synchronize() latencies.append(time.perf_counter() - start) latencies.sort() print(fP50: {latencies[100]*1000:.2f}ms) print(fP99: {latencies[198]*1000:.2f}ms)4.3 量化实操从校准到导出量化的完整流程分四步准备校准集、插入量化观察器、跑校准、导出量化模型。以 PyTorch 的量化流程为例先定义量化配置。对于 CNN用fbgemmx86或qnnpackARM对于 Transformer建议用动态量化或 SmoothQuant 这类专门方案。import torch.quantization as tq # 1. 设置量化配置 model.qconfig tq.get_default_qconfig(fbgemm) # 2. 插入观察器 model_prepared tq.prepare(model, inplaceFalse) # 3. 跑校准 model_prepared.eval() with torch.no_grad(): for batch in calib_loader: model_prepared(batch) # 4. 转换为量化模型 model_quantized tq.convert(model_prepared, inplaceFalse)校准完之后一定要在验证集上测精度。如果掉点超过 1%先别急着导出回头检查校准集和量化配置。常见问题是某些层不适合量化比如第一层和最后一层可以对这些层做skip 处理保持 FP32。导出 ONNX 时要注意量化后的模型导出需要指定 opset 版本opset 13 以上对量化算子支持比较好。导出后用 ONNX Runtime 加载对比一下和 PyTorch 的精度差异确认没有导出损失。4.4 剪枝实操敏感度分析与迭代剪枝剪枝的第一步是敏感度分析。我写了一个简单的脚本逐层尝试不同剪枝比例def sensitivity_analysis(model, val_loader, layers, ratios): results {} for layer_name in layers: for ratio in ratios: # 复制模型对该层剪枝 pruned copy.deepcopy(model) prune_layer(pruned, layer_name, ratio) acc evaluate(pruned, val_loader) results[(layer_name, ratio)] acc return results跑完敏感度分析你会得到一张表横轴是剪枝比例纵轴是精度。根据这张表给每层分配不同的剪枝比例。高敏感层少剪低敏感层多剪。然后进入迭代剪枝循环剪一轮、微调、评估、再剪。微调时学习率要调小我一般用原始学习率的 1/10跑 3-5 个 epoch。如果某一轮剪完精度掉超过 2%说明剪多了回退到上一轮减小比例。注意剪枝后模型的 BN 统计量会失效微调时一定要让 BN 层重新统计。做法是把模型设为 train 模式跑几个 batch再切回 eval 评估。4.5 算子融合与最终导出算子融合通常在导出阶段完成。如果用 TensorRT它会在构建 engine 时自动做融合你只需要在配置里开启相应选项。如果用 ONNX Runtime可以用onnxruntime.transformers.optimizer做图优化。TensorRT 构建 engine 的关键参数config builder.create_builder_config() config.set_memory_pool_limit(trt.MemoryPoolType.WORKSPACE, 1 30) config.set_flag(trt.BuilderFlag.FP16) # 开启 FP16 config.set_flag(trt.BuilderFlag.INT8) # 开启 INT8 config.int8_calibrator calibrator # 指定校准器构建完 engine 后用trtexec工具测一下性能对比优化前的基线。正常情况下INT8 融合能带来 3-5 倍的加速。如果加速不明显检查是不是某些层回退到了 FP32或者融合没生效。5. 常见问题与排查技巧实录5.1 量化后精度掉得离谱怎么办这是最高频的问题。排查顺序我一般是这样先看校准集。校准集是不是从训练集采的是不是覆盖了所有场景数量够不够我遇到过一次校准集只有 100 条而且全是短文本结果长文本推理时精度崩了。换成 1000 条覆盖长短分布的校准集后问题解决。再看敏感层。用逐层量化对比的方式找出哪些层量化后误差最大。对这些层做 skip保持 FP32。通常第一层卷积和最后的分类层最敏感。最后看量化方案。对称量化和非对称量化效果不一样per-tensor 和 per-channel 也不一样。激活值通常用非对称量化因为 ReLU 后都是非负的权重用对称量化。per-channel 量化比 per-tensor 精度高但计算稍慢权衡着选。5.2 剪枝后模型跑不出加速剪枝了但速度没变快八成是剪枝方式不对。非结构化剪枝把权重置零但矩阵还是稠密的GPU 照样按稠密矩阵算自然没加速。要加速必须做结构化剪枝真正把通道砍掉矩阵维度变小。另一个可能是剪枝比例不够。砍 10% 的通道理论加速也就 10%被其他开销一摊薄就看不出来了。要看到明显加速剪枝比例至少 30% 以上。还有可能是瓶颈不在被剪的层。如果模型的时间主要花在某个没剪的层上剪其他层对总延迟没影响。用 profiler 看一下各层耗时占比优先剪耗时大户。5.3 优化后模型上线精度波动离线测精度没问题上线后精度波动通常是数据分布偏移导致的。离线验证集和线上真实数据分布不一致量化参数在离线数据上校准的到线上就不准了。解决办法是用线上数据做校准或者做在线校准——定期用最新的线上数据重新校准量化参数。有些推理引擎支持动态量化能在推理时根据实际输入调整量化范围但会带来额外开销看场景取舍。还有一个隐蔽的坑预处理不一致。训练时的归一化参数、resize 方式、padding 策略推理时必须完全一致。我见过一次训练用 BGR推理用 RGB精度直接掉 5 个点排查了两天才发现。5.4 常见问题速查表问题现象可能原因排查方法解决方案量化后精度掉 3%校准集不具代表性检查校准集来源和分布从线上日志采样增加覆盖量化后精度掉 3%敏感层被量化逐层量化对比敏感层 skip保持 FP32剪枝后无加速非结构化剪枝检查剪枝后矩阵是否稀疏改用结构化通道剪枝剪枝后无加速剪枝比例太低统计剪枝比例提高到 30% 以上剪枝后精度崩一次剪太多查看剪枝比例改迭代剪枝每轮 10-15%上线精度波动数据分布偏移对比线上线下数据分布用线上数据校准上线精度波动预处理不一致逐项对比预处理流程统一训练和推理预处理融合后速度反降kernel 过大用 profiler 看 occupancy减少融合范围导出 ONNX 失败opset 版本低检查 opset 版本升到 13 以上推理引擎加载失败版本不匹配检查 CUDA/引擎版本严格对应版本5.5 几个我踩过的独家坑第一个坑量化校准时的 batch size。校准时的 batch size 要和推理时一致否则激活值的统计分布会偏。我试过校准用 batch 32推理用 batch 1结果精度掉了 2 个点。改成 batch 1 校准后恢复正常。第二个坑剪枝后的模型保存。剪枝改变了模型结构保存时不能只存权重要存整个模型结构。我一开始只存了 state_dict加载时维度对不上白忙活半天。第三个坑TensorRT engine 的序列化。engine 是和 GPU 架构绑定的在 A100 上构建的 engine 拿到 T4 上跑不了。要么在每个目标机型上分别构建要么用 ONNX 作为中间格式运行时再构建。第四个坑动态 shape 的处理。如果模型支持变长输入量化校准和 engine 构建都要考虑动态 shape。TensorRT 需要配置 optimization profile指定最小、最优、最大 shape。配置不当会导致某些 shape 走 fallback速度骤降。6. 优化效果的度量与持续迭代6.1 怎么定义“优化成功”优化不是一次性的活得有明确的度量标准。我一般从三个维度定义成功精度损失控制在 1% 以内、延迟降低 50% 以上、显存降低 60% 以上。三个指标同时达标才算成功只快不准或者只准不快都没意义。度量的时候要注意公平对比。优化前后的测试环境要一致同一块 GPU、同一个 batch size、同样的预热次数。我见过有人拿优化前的 P50 对比优化后的 P99得出“优化后更慢”的荒谬结论。6.2 建立回归测试机制模型优化最怕的是“这次调好了下次换个模型又翻车”。所以一定要把优化流程脚本化、自动化建立回归测试。我的做法是写一个 pipeline 脚本输入原始模型和校准数据自动完成量化、剪枝、融合、导出、评估全流程输出一份报告包含精度、延迟、显存的前后对比。每次有新模型要优化跑一遍脚本就行不用手动重复操作。回归测试还要覆盖边界 case空输入、超长输入、异常输入。量化后的模型对异常输入更敏感容易出 NaN 或溢出。这些 case 在离线测试时就要覆盖到别等上线了才发现。6.3 什么情况下该放弃优化不是所有模型都值得优化。如果模型本身已经很小比如参数量 1M优化收益有限投入产出比不划算。如果模型延迟瓶颈不在计算而在 IO比如大量 embedding 查表量化剪枝也帮不上忙得从架构层面解决。还有一种情况模型精度本来就卡在业务红线边缘任何精度损失都不可接受。这时候优化空间很小不如考虑换更高效的模型架构或者从系统层面优化比如批处理、缓存。我在实际项目里的体会是Model-Optimizer 这类工具最大的价值不是某个具体技术而是它提供了一套标准化的优化流程。以前每个模型都要重新摸索怎么量化、怎么剪枝现在有一套可复用的方法论新模型上手快很多。但工具终究是工具真正决定优化效果的还是你对模型结构、数据分布、硬件特性的理解。多测、多对比、多记录把每次优化的参数和结果都存下来时间长了你就有一套自己的“优化配方”了。最后分享一个小技巧优化前先跑一遍 profiler看清楚时间到底花在哪。很多时候你以为的瓶颈和实际的瓶颈完全不是一回事。我有个项目一直以为是卷积层慢profiler 一跑发现是 LayerNorm 占了 40% 的时间针对性优化后效果立竿见影。别凭感觉优化让数据说话。
模型优化器实战：量化剪枝与算子融合的推理加速指南
1. 模型优化器到底在解决什么问题第一次接触 Model-Optimizer 这个概念是在一个推荐系统的排序模型上。当时线上推理延迟死活压不下去单次请求要跑 180ms业务方要求降到 80ms 以内。我试过换更小的模型、砍特征、加机器效果都不理想——换小模型掉点太狠加机器成本又扛不住。后来一位做推理优化的朋友点了我一句你为什么不从优化器层面看看模型训练完之后权重里其实藏着大量冗余优化器就是干这个的。这句话让我重新理解了 Model-Optimizer 的定位。它不是一个训练框架也不是一个推理引擎而是介于训练和部署之间的一层“精加工车间”。训练出来的模型权重往往是稠密的、冗余的、精度过高的直接拿去部署既浪费显存又拖慢速度。Model-Optimizer 要做的就是在尽量不损失精度的前提下把模型压缩、量化、剪枝、蒸馏让它变得又小又快。具体来说一个完整的 Model-Optimizer 通常覆盖这几件事量化把 FP32 权重压成 INT8 甚至 INT4、剪枝去掉不重要的连接或通道、知识蒸馏用大模型教小模型、结构重参数化把多分支合并成单路、算子融合把多个小算子合成一个大算子。这些技术单独拎出来都不新鲜但 Model-Optimizer 的价值在于把它们工程化、流水线化让你不用自己从零写 CUDA kernel也不用自己推导量化公式。这篇文章适合谁看如果你是把模型训完就丢给工程团队部署的算法同学看完你会知道部署同学到底在抱怨什么如果你是负责推理性能的工程同学看完你能拿到一套可复现的优化流程和踩坑清单如果你只是好奇为什么同一个模型别人跑得比你快那这篇也能给你答案。我会尽量少讲公式多讲“为什么这么选”和“实际怎么操作”把我在几个真实项目里趟过的路摊开来说。2. 优化器的核心思路与方案选型2.1 为什么不能只靠“换个更小的模型”很多人对模型优化的第一反应是直接训个小模型不就行了这个思路在有些场景下成立但在大多数业务场景里行不通。原因很简单——小模型不是大模型的等比缩小版它的表达能力有硬上限。你从 BERT-base 换到 BERT-tiny参数量掉了 90%但某些细粒度的语义区分能力可能直接崩掉掉点不是线性的而是断崖式的。Model-Optimizer 的思路完全不同。它不改变模型的“知识容量”而是改变知识的“存储和计算方式”。打个比方一本 500 页的书你要把它塞进一个只能装 200 页的文件夹。换小模型相当于重新写一本 200 页的简写版内容必然丢失而量化剪枝相当于把书里的废话删掉、把长句压缩、把重复内容合并核心信息还在只是表达更紧凑了。这个区别决定了优化器的技术路线保精度优先压体积其次。所有优化手段都要围绕“精度损失可控”这个前提来设计否则优化出来的模型没法上线等于白干。2.2 量化、剪枝、蒸馏三条路怎么选这三条路不是互斥的实际项目里经常组合使用但入门时得先搞清楚各自的适用场景和代价。量化是性价比最高的一条路。它把 FP32 的权重和激活值映射到低比特整数域显存直接降 4 倍FP32 到 INT8推理速度通常能提升 2-4 倍。量化的核心难点在于校准——你得用一批有代表性的数据跑一遍统计每一层激活值的动态范围确定缩放因子scale和零点zero point。校准集选得不好量化误差会累积精度掉得莫名其妙。剪枝分结构化和非结构化两种。非结构化剪枝把单个权重置零理论上压缩率高但通用硬件跑不出加速因为 GPU 对稀疏矩阵的支持有限。结构化剪枝直接砍掉整个通道或注意力头压缩后是规整的稠密矩阵硬件友好但精度损失相对大。我一般建议先做结构化剪枝把冗余通道砍掉再做量化两步叠加效果最好。知识蒸馏是另一条路用一个大的 teacher 模型指导小的 student 模型训练。它不压缩已有模型而是重新训一个小的。蒸馏的坑在于 teacher 和 student 的容量差距不能太大否则 student 学不动。而且蒸馏需要重新训练时间成本高适合有充足算力和训练数据的场景。下面这张表是我在实际选型时用的判断依据优化手段压缩率精度损失是否需要重训硬件加速效果适用场景INT8 量化4x低1%否校准即可显著绝大多数推理场景INT4 量化8x中1-3%否需校准显著显存极度受限结构化剪枝2-4x中是微调中等通道冗余明显的模型非结构化剪枝5-10x低是微调依赖硬件有稀疏加速支持的平台知识蒸馏自定义可控是完整训练取决于 student有训练资源的场景2.3 优化流水线的顺序为什么很重要这几步的先后顺序不是随便排的。我踩过的最大坑就是顺序搞反导致优化效果大打折扣。正确的顺序通常是先剪枝再量化最后做算子融合。原因在于剪枝会改变模型结构如果先量化再剪枝剪枝后的通道对应的量化参数就失效了得重新校准。而算子融合放在最后是因为它依赖最终的模型结构前面的步骤改了结构融合方案就得跟着变。还有一个细节剪枝之后一定要做微调fine-tune哪怕只跑几个 epoch。剪枝相当于给模型做了“手术”切掉了部分连接模型需要重新适应。不微调直接量化精度会雪上加霜。我一般剪枝后微调 3-5 个 epoch学习率调到原来的十分之一效果比较稳。3. 核心细节解析与实操要点3.1 量化校准集怎么选才不翻车校准集是量化的命门。我见过太多人随便拿几百条训练数据当校准集结果线上精度掉得离谱。校准集的核心要求是分布代表性它要能覆盖线上真实请求的输入分布。具体怎么选我的做法是从线上日志里采样而不是从训练集里采样。训练集和线上数据的分布往往有偏移用训练集校准等于用错误的尺子量衣服。采样量不用太多500-1000 条足够但要保证覆盖各个业务场景。比如推荐场景要覆盖不同用户活跃度、不同物品类目NLP 场景要覆盖不同长度、不同领域的文本。校准算法本身也有讲究。最常用的是MinMax 校准取激活值的最大最小值确定范围简单但对离群值敏感。如果某层激活值有个别极端值整个量化范围会被拉大导致正常值被压缩到很窄的区间精度损失严重。这时候可以用KL 散度校准或百分位校准前者最小化量化前后的分布差异后者直接截断极端百分位。实测下来KL 校准在 Transformer 类模型上效果最好百分位校准在 CNN 上更稳。注意校准集一定要和推理时的预处理保持一致。我遇到过一次校准用的是未归一化的数据推理时做了归一化结果量化参数完全对不上精度直接崩了。3.2 剪枝粒度与敏感度分析剪枝不是无脑砍得先做敏感度分析。每一层对精度的贡献不一样有些层砍 50% 都没事有些层砍 10% 就崩。敏感度分析的做法是逐层尝试不同的剪枝比例观察验证集精度的变化画出敏感度曲线。我通常把层分成三类高敏感层剪枝比例控制在 10% 以内、中敏感层20-30%、低敏感层可以到 50%。第一层和最后一层通常最敏感中间的重复结构层最不敏感。Transformer 里注意力头的冗余度比 FFN 层高可以优先剪注意力头。剪枝粒度上通道剪枝是最实用的。它直接砍掉整个卷积核或整个注意力头剪完还是规整的矩阵。相比之下权重剪枝虽然压缩率高但需要专门的稀疏计算库支持通用性差。通道剪枝的关键是重要性评分常用的有 L1 范数、L2 范数、BN 层缩放因子。我实测下来用 BN 层的 gamma 系数做评分最准因为它直接反映了该通道对输出的贡献。剪枝完记得做迭代剪枝不要一次砍到位。一次砍太多模型直接废掉微调也救不回来。我一般分 3-4 轮每轮砍 10-15%砍完微调再砍下一轮。这样精度曲线是平滑下降的可控性强。3.3 算子融合的收益与边界算子融合是把多个连续的小算子合并成一个大的 kernel减少 kernel launch 开销和中间结果的显存读写。在 GPU 上kernel launch 的开销其实不小一个模型如果有几百个小算子光 launch 就占了不少时间。最常见的融合模式是Conv BN ReLU三合一。训练时 BN 是独立层推理时 BN 的参数可以完全折叠进 Conv 的权重里变成一个带偏置的卷积再接 ReLU。这样三个算子变一个中间不需要存 BN 的输出显存和延迟都省了。另一个高频模式是LayerNorm 残差连接的融合在 Transformer 里收益很大。LayerNorm 涉及均值方差计算单独跑要读一遍写一遍融合后可以在寄存器里完成。但融合不是越多越好。融合的前提是算子之间的数据依赖是线性的、无分支的。如果中间有分支、有动态控制流强行融合会改变语义。而且融合后的 kernel 太大寄存器压力上升反而可能降低 occupancy。我一般只融合那些“确定安全且收益明显”的模式不追求极致。4. 完整实操流程与关键环节4.1 环境准备与依赖确认动手之前先把环境理清楚。Model-Optimizer 这类工具通常依赖特定版本的深度学习框架和推理引擎版本不匹配是最高频的翻车原因。以主流的 PyTorch 生态为例你需要确认这几样PyTorch 版本、CUDA 版本、推理引擎版本如 TensorRT、ONNX Runtime、以及优化器工具本身的版本。我建议用 conda 建独立环境把版本锁死避免和系统里的其他项目冲突。conda create -n model-opt python3.10 conda activate model-opt pip install torch2.1.0 torchvision0.16.0 pip install onnx1.15.0 onnxruntime-gpu1.17.0装完之后先跑一个最小验证加载一个预训练模型导出 ONNX再用推理引擎加载一遍确认整条链路通。这一步花十分钟能省掉后面几小时的排查。提示CUDA 版本和推理引擎版本必须严格对应。TensorRT 8.6 对应 CUDA 11.8TensorRT 10 对应 CUDA 12.x装错了会在加载引擎时报莫名其妙的错。4.2 基线测量先知道优化前是什么样优化之前必须测基线否则你根本不知道优化有没有效果。基线要测三个指标精度在验证集上的准确率/F1 等、延迟单次推理耗时要测 P50 和 P99、显存占用峰值显存。测延迟时有个细节一定要用固定输入尺寸并且预热足够次数。GPU 有频率爬升的过程前几次推理会偏慢。我一般预热 50 次再测 200 次取平均。P99 延迟比平均延迟更重要因为它反映了最差情况线上超时通常发生在 P99。import torch import time model.eval().cuda() dummy_input torch.randn(1, 3, 224, 224).cuda() # 预热 with torch.no_grad(): for _ in range(50): model(dummy_input) # 测延迟 latencies [] with torch.no_grad(): for _ in range(200): torch.cuda.synchronize() start time.perf_counter() model(dummy_input) torch.cuda.synchronize() latencies.append(time.perf_counter() - start) latencies.sort() print(fP50: {latencies[100]*1000:.2f}ms) print(fP99: {latencies[198]*1000:.2f}ms)4.3 量化实操从校准到导出量化的完整流程分四步准备校准集、插入量化观察器、跑校准、导出量化模型。以 PyTorch 的量化流程为例先定义量化配置。对于 CNN用fbgemmx86或qnnpackARM对于 Transformer建议用动态量化或 SmoothQuant 这类专门方案。import torch.quantization as tq # 1. 设置量化配置 model.qconfig tq.get_default_qconfig(fbgemm) # 2. 插入观察器 model_prepared tq.prepare(model, inplaceFalse) # 3. 跑校准 model_prepared.eval() with torch.no_grad(): for batch in calib_loader: model_prepared(batch) # 4. 转换为量化模型 model_quantized tq.convert(model_prepared, inplaceFalse)校准完之后一定要在验证集上测精度。如果掉点超过 1%先别急着导出回头检查校准集和量化配置。常见问题是某些层不适合量化比如第一层和最后一层可以对这些层做skip 处理保持 FP32。导出 ONNX 时要注意量化后的模型导出需要指定 opset 版本opset 13 以上对量化算子支持比较好。导出后用 ONNX Runtime 加载对比一下和 PyTorch 的精度差异确认没有导出损失。4.4 剪枝实操敏感度分析与迭代剪枝剪枝的第一步是敏感度分析。我写了一个简单的脚本逐层尝试不同剪枝比例def sensitivity_analysis(model, val_loader, layers, ratios): results {} for layer_name in layers: for ratio in ratios: # 复制模型对该层剪枝 pruned copy.deepcopy(model) prune_layer(pruned, layer_name, ratio) acc evaluate(pruned, val_loader) results[(layer_name, ratio)] acc return results跑完敏感度分析你会得到一张表横轴是剪枝比例纵轴是精度。根据这张表给每层分配不同的剪枝比例。高敏感层少剪低敏感层多剪。然后进入迭代剪枝循环剪一轮、微调、评估、再剪。微调时学习率要调小我一般用原始学习率的 1/10跑 3-5 个 epoch。如果某一轮剪完精度掉超过 2%说明剪多了回退到上一轮减小比例。注意剪枝后模型的 BN 统计量会失效微调时一定要让 BN 层重新统计。做法是把模型设为 train 模式跑几个 batch再切回 eval 评估。4.5 算子融合与最终导出算子融合通常在导出阶段完成。如果用 TensorRT它会在构建 engine 时自动做融合你只需要在配置里开启相应选项。如果用 ONNX Runtime可以用onnxruntime.transformers.optimizer做图优化。TensorRT 构建 engine 的关键参数config builder.create_builder_config() config.set_memory_pool_limit(trt.MemoryPoolType.WORKSPACE, 1 30) config.set_flag(trt.BuilderFlag.FP16) # 开启 FP16 config.set_flag(trt.BuilderFlag.INT8) # 开启 INT8 config.int8_calibrator calibrator # 指定校准器构建完 engine 后用trtexec工具测一下性能对比优化前的基线。正常情况下INT8 融合能带来 3-5 倍的加速。如果加速不明显检查是不是某些层回退到了 FP32或者融合没生效。5. 常见问题与排查技巧实录5.1 量化后精度掉得离谱怎么办这是最高频的问题。排查顺序我一般是这样先看校准集。校准集是不是从训练集采的是不是覆盖了所有场景数量够不够我遇到过一次校准集只有 100 条而且全是短文本结果长文本推理时精度崩了。换成 1000 条覆盖长短分布的校准集后问题解决。再看敏感层。用逐层量化对比的方式找出哪些层量化后误差最大。对这些层做 skip保持 FP32。通常第一层卷积和最后的分类层最敏感。最后看量化方案。对称量化和非对称量化效果不一样per-tensor 和 per-channel 也不一样。激活值通常用非对称量化因为 ReLU 后都是非负的权重用对称量化。per-channel 量化比 per-tensor 精度高但计算稍慢权衡着选。5.2 剪枝后模型跑不出加速剪枝了但速度没变快八成是剪枝方式不对。非结构化剪枝把权重置零但矩阵还是稠密的GPU 照样按稠密矩阵算自然没加速。要加速必须做结构化剪枝真正把通道砍掉矩阵维度变小。另一个可能是剪枝比例不够。砍 10% 的通道理论加速也就 10%被其他开销一摊薄就看不出来了。要看到明显加速剪枝比例至少 30% 以上。还有可能是瓶颈不在被剪的层。如果模型的时间主要花在某个没剪的层上剪其他层对总延迟没影响。用 profiler 看一下各层耗时占比优先剪耗时大户。5.3 优化后模型上线精度波动离线测精度没问题上线后精度波动通常是数据分布偏移导致的。离线验证集和线上真实数据分布不一致量化参数在离线数据上校准的到线上就不准了。解决办法是用线上数据做校准或者做在线校准——定期用最新的线上数据重新校准量化参数。有些推理引擎支持动态量化能在推理时根据实际输入调整量化范围但会带来额外开销看场景取舍。还有一个隐蔽的坑预处理不一致。训练时的归一化参数、resize 方式、padding 策略推理时必须完全一致。我见过一次训练用 BGR推理用 RGB精度直接掉 5 个点排查了两天才发现。5.4 常见问题速查表问题现象可能原因排查方法解决方案量化后精度掉 3%校准集不具代表性检查校准集来源和分布从线上日志采样增加覆盖量化后精度掉 3%敏感层被量化逐层量化对比敏感层 skip保持 FP32剪枝后无加速非结构化剪枝检查剪枝后矩阵是否稀疏改用结构化通道剪枝剪枝后无加速剪枝比例太低统计剪枝比例提高到 30% 以上剪枝后精度崩一次剪太多查看剪枝比例改迭代剪枝每轮 10-15%上线精度波动数据分布偏移对比线上线下数据分布用线上数据校准上线精度波动预处理不一致逐项对比预处理流程统一训练和推理预处理融合后速度反降kernel 过大用 profiler 看 occupancy减少融合范围导出 ONNX 失败opset 版本低检查 opset 版本升到 13 以上推理引擎加载失败版本不匹配检查 CUDA/引擎版本严格对应版本5.5 几个我踩过的独家坑第一个坑量化校准时的 batch size。校准时的 batch size 要和推理时一致否则激活值的统计分布会偏。我试过校准用 batch 32推理用 batch 1结果精度掉了 2 个点。改成 batch 1 校准后恢复正常。第二个坑剪枝后的模型保存。剪枝改变了模型结构保存时不能只存权重要存整个模型结构。我一开始只存了 state_dict加载时维度对不上白忙活半天。第三个坑TensorRT engine 的序列化。engine 是和 GPU 架构绑定的在 A100 上构建的 engine 拿到 T4 上跑不了。要么在每个目标机型上分别构建要么用 ONNX 作为中间格式运行时再构建。第四个坑动态 shape 的处理。如果模型支持变长输入量化校准和 engine 构建都要考虑动态 shape。TensorRT 需要配置 optimization profile指定最小、最优、最大 shape。配置不当会导致某些 shape 走 fallback速度骤降。6. 优化效果的度量与持续迭代6.1 怎么定义“优化成功”优化不是一次性的活得有明确的度量标准。我一般从三个维度定义成功精度损失控制在 1% 以内、延迟降低 50% 以上、显存降低 60% 以上。三个指标同时达标才算成功只快不准或者只准不快都没意义。度量的时候要注意公平对比。优化前后的测试环境要一致同一块 GPU、同一个 batch size、同样的预热次数。我见过有人拿优化前的 P50 对比优化后的 P99得出“优化后更慢”的荒谬结论。6.2 建立回归测试机制模型优化最怕的是“这次调好了下次换个模型又翻车”。所以一定要把优化流程脚本化、自动化建立回归测试。我的做法是写一个 pipeline 脚本输入原始模型和校准数据自动完成量化、剪枝、融合、导出、评估全流程输出一份报告包含精度、延迟、显存的前后对比。每次有新模型要优化跑一遍脚本就行不用手动重复操作。回归测试还要覆盖边界 case空输入、超长输入、异常输入。量化后的模型对异常输入更敏感容易出 NaN 或溢出。这些 case 在离线测试时就要覆盖到别等上线了才发现。6.3 什么情况下该放弃优化不是所有模型都值得优化。如果模型本身已经很小比如参数量 1M优化收益有限投入产出比不划算。如果模型延迟瓶颈不在计算而在 IO比如大量 embedding 查表量化剪枝也帮不上忙得从架构层面解决。还有一种情况模型精度本来就卡在业务红线边缘任何精度损失都不可接受。这时候优化空间很小不如考虑换更高效的模型架构或者从系统层面优化比如批处理、缓存。我在实际项目里的体会是Model-Optimizer 这类工具最大的价值不是某个具体技术而是它提供了一套标准化的优化流程。以前每个模型都要重新摸索怎么量化、怎么剪枝现在有一套可复用的方法论新模型上手快很多。但工具终究是工具真正决定优化效果的还是你对模型结构、数据分布、硬件特性的理解。多测、多对比、多记录把每次优化的参数和结果都存下来时间长了你就有一套自己的“优化配方”了。最后分享一个小技巧优化前先跑一遍 profiler看清楚时间到底花在哪。很多时候你以为的瓶颈和实际的瓶颈完全不是一回事。我有个项目一直以为是卷积层慢profiler 一跑发现是 LayerNorm 占了 40% 的时间针对性优化后效果立竿见影。别凭感觉优化让数据说话。