1. 模型优化器到底在解决什么问题第一次接触 Model-Optimizer 这个概念是在一个推荐系统的排序模型上。当时线上推理延迟死活压不下去单次请求要跑 180ms业务方要求砍到 50ms 以内。我一开始的想法很朴素——换更小的模型、砍特征、降 batch结果 AUC 掉了两个点业务方直接不干了。后来才意识到问题不在模型本身而在于我从来没认真对待过优化器这一层。这里说的 Model-Optimizer不是指训练时用的 SGD、Adam 那种参数更新算法而是指一整套围绕模型推理与部署阶段的优化工具链和策略集合。它要做的事情很明确在不显著损失精度的前提下把模型的计算量、内存占用、推理延迟压到最低。能做的事情包括算子融合、量化、剪枝、图优化、内存复用、算子替换等等。解决的问题也很直接——模型越训越大但线上资源是有限的中间这道鸿沟就得靠优化器来填。适合谁来参考如果你是把模型训完就丢给工程团队部署的算法同学这篇能帮你理解部署侧到底在抱怨什么如果你是负责推理服务的工程同学这篇能给你一套可落地的优化流程如果你是自己做 side project、想把模型塞进边缘设备或者手机端的开发者那这套东西你迟早要碰。我踩过的最大一个坑就是把优化当成一个开关——以为调个 API 就能变快。实际上 Model-Optimizer 是一套需要反复迭代的工程流程每一步都要验证精度、测延迟、看内存缺一不可。2. 优化器的整体设计思路与方案选型2.1 为什么不能只靠换小模型这一招很多人对模型优化的第一反应就是蒸馏一个小模型或者换个轻量 backbone。这招确实有效但它有几个硬伤。第一蒸馏需要重新训练成本高、周期长而且蒸馏出来的模型往往在长尾样本上表现很差。第二换 backbone 意味着整个特征工程、预处理逻辑可能都要跟着改牵一发动全身。第三有些场景下你根本没得选——比如模型是第三方提供的你只能拿到一个冻结的计算图。所以真正成熟的 Model-Optimizer 思路是分层优化从计算图层面、数值精度层面、内存层面、算子层面分别下手每一层都能拿到一部分收益叠加起来效果才明显。这就像给一辆车省油你不能只盯着发动机轮胎气压、车身风阻、驾驶习惯都得管。2.2 四层优化策略的取舍逻辑我把常见的优化手段归成四层每一层的收益、风险和适用场景都不一样。优化层级典型手段延迟收益精度风险实施成本图层面算子融合、常量折叠、死代码消除10%-30%极低低数值层面FP16、INT8 量化、混合精度30%-60%中中结构层面剪枝、稀疏化、低秩分解20%-50%高高内存层面内存池、原地操作、KV Cache 复用10%-25%极低中选型的核心原则是先做零风险的图优化再做可控风险的量化最后才考虑结构层面的改动。我见过太多团队一上来就搞剪枝结果精度崩了回头连基线都找不回来。2.3 图优化为什么是第一步图优化之所以应该排在最前面是因为它几乎不改变数值计算结果。算子融合Operator Fusion把 Conv BN ReLU 这种连续的小算子合并成一个大的 kernel减少的是 kernel launch 开销和中间张量的读写。常量折叠Constant Folding把能在编译期算出来的东西提前算掉。死代码消除把那些对输出没贡献的分支直接砍掉。这些操作在数学上是等价的所以精度不会掉。实测下来一个典型的 CNN 模型做完图优化延迟能降 15% 左右而且完全不用重新训练。这是性价比最高的一步没有理由跳过。2.4 量化为什么是收益最大也最容易翻车的一步量化把 FP32 的权重和激活值用 INT8 甚至 INT4 表示理论上有 4 倍的内存节省和 2-4 倍的计算加速。但它的坑也最多。最典型的问题是激活值动态范围过大某些层的输出可能从 -1000 到 1000直接线性量化到 INT8 会丢失大量精度。解决办法是校准Calibration拿一批有代表性的数据跑一遍前向统计每一层激活值的分布据此确定量化参数scale 和 zero_point。校准集的选择非常关键必须覆盖线上真实的数据分布。我曾经用训练集做校准结果线上精度掉了 3 个点换成线上采样的一万条数据后精度只掉 0.3 个点。另一个坑是逐层量化 vs 逐通道量化。逐通道量化对权重的每个输出通道单独计算 scale精度更好但实现复杂逐层量化简单但精度差。对于卷积层我一般推荐逐通道对于全连接层逐层通常够用。3. 核心细节解析与实操要点3.1 计算图捕获一切优化的起点不管你用什么框架优化的第一步都是把模型的计算图完整地捕获下来。PyTorch 有torch.jit.trace和torch.jit.script两条路TensorFlow 有 SavedModel 和 GraphDefONNX 则是跨框架的通用中间表示。我个人的经验是优先用 ONNX 作为中间格式。原因是它的生态最成熟各种优化工具onnx-simplifier、onnxruntime 的 graph optimizer、TensorRT 的 parser都支持它。而且 ONNX 的图结构清晰调试起来方便。捕获图的时候有几个细节要注意。第一动态 shape 的处理。如果你的模型输入 batch size 是变化的trace 的时候要用dynamic_axes标注出来否则导出的图会被固定成某个 shape。第二控制流的处理。if/else、循环这些在 trace 模式下会被展开成静态图如果分支依赖输入数据trace 会出错这时候必须用 script 模式。第三自定义算子的处理。如果你的模型里有自己写的 CUDA kernel导出 ONNX 时需要注册对应的 symbolic否则会报 unsupported operator。import torch import torch.onnx model.eval() dummy_input torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, model.onnx, input_names[input], output_names[output], dynamic_axes{ input: {0: batch_size}, output: {0: batch_size} }, opset_version13 )导出之后我强烈建议用onnx.checker.check_model验证一下图的合法性再用onnx.shape_inference.infer_shapes补全 shape 信息。这两步能提前发现很多问题。3.2 算子融合的实操细节算子融合不是随便两个算子都能合的。融合的前提是中间张量不被其他地方引用而且融合后的 kernel 在数值上等价。常见的融合模式有几种。Conv BN 的融合是最经典的。BN 在推理阶段本质上是一个仿射变换可以把它吸收进 Conv 的权重和偏置里。具体推导是这样的Conv 输出y W*x bBN 做z gamma * (y - mean) / sqrt(var eps) beta。把 y 代入得到z gamma/sqrt(vareps) * W * x (gamma/sqrt(vareps) * (b - mean) beta)。所以新的权重是W gamma/sqrt(vareps) * W新的偏置是b gamma/sqrt(vareps) * (b - mean) beta。这一步在数学上完全等价精度零损失。Conv BN ReLU 的融合则要注意 ReLU 的位置。如果 ReLU 紧跟在 BN 后面融合后直接在输出上做 clamp 即可。但如果中间还有其他操作就不能盲目融合。注意融合 Conv BN 之前一定要确认模型处于 eval 模式。训练模式下 BN 用的是 batch 统计量融合会出错。3.3 量化校准的完整流程量化校准我一般分四步走。第一步准备校准数据集。数量不用太多1000 到 5000 条就够但必须覆盖线上真实分布。如果是分类任务每个类别都要有样本如果是检测任务各种尺度、各种场景的图都要有。第二步跑前向收集统计量。用校准集跑一遍模型记录每一层激活值的 min、max、直方图。ONNX Runtime 和 TensorRT 都提供了Calibrator接口也可以自己写。第三步计算量化参数。最简单的是 min-max 校准直接用[min, max]映射到[-127, 127]。但这种方法对离群值很敏感。更好的选择是熵校准Entropy Calibration它通过最小化量化前后的信息熵差异来确定截断阈值能有效抑制离群值的影响。TensorRT 默认用的就是熵校准。第四步验证精度。拿一个独立的验证集对比量化前后的输出差异。我一般看两个指标top-1 一致率和最大绝对误差。如果 top-1 一致率低于 99%就要考虑是不是某些层不适合量化可以设置量化黑名单把这些层保留 FP32。from onnxruntime.quantization import quantize_dynamic, QuantType quantize_dynamic( model_inputmodel.onnx, model_outputmodel_int8.onnx, weight_typeQuantType.QInt8, per_channelTrue, reduce_rangeFalse )reduce_range这个参数值得说一下。它把量化范围从[-127, 127]缩到[-64, 63]目的是避免某些硬件上 INT8 乘法的溢出问题。如果你的目标硬件是较老的 CPU建议开启如果是现代 GPU 或 NPU可以关掉以保留精度。3.4 剪枝的粒度选择与恢复训练剪枝分非结构化剪枝和结构化剪枝。非结构化剪枝把单个权重置零稀疏度可以做到很高90%但需要硬件支持稀疏计算才能加速否则只是省了存储。结构化剪枝直接砍掉整个通道或整个注意力头硬件友好但精度损失更大。我的建议是如果目标硬件支持稀疏加速比如某些 NPU用非结构化剪枝否则老老实实用结构化剪枝。结构化剪枝之后一定要做恢复训练Fine-tuning用原模型做 teacher剪枝后的模型做 student做知识蒸馏。学习率要调小一般是原训练的 1/10 到 1/100训练几个 epoch 就能把精度拉回来大部分。剪枝比例怎么定我的经验是从 10% 开始每次增加 10%直到精度掉超过 1 个点就停。不要一次性剪太多渐进式剪枝效果更好。4. 完整实操流程与关键环节实现4.1 环境准备与工具链搭建先把工具链理清楚。我常用的组合是PyTorch 做训练和导出ONNX 做中间表示ONNX Runtime 或 TensorRT 做推理优化。如果目标平台是移动端再加一个 NCNN 或 MNN。pip install torch onnx onnxruntime onnxsim pip install onnxruntime-tools版本兼容性是个大坑。ONNX 的 opset 版本、ONNX Runtime 的版本、CUDA 的版本三者之间必须匹配。我曾经因为 opset 用了 15 而 ONNX Runtime 只支持到 13卡了整整一个下午。建议锁定版本写进 requirements.txt。4.2 从训练模型到优化后模型的完整链路整个链路我画成一条线训练模型 - 导出 ONNX - 图简化 - 量化 - 精度验证 - 部署。导出 ONNX 之后第一件事是用 onnx-simplifier 做一次图简化。它会做常量折叠、死代码消除、算子融合还能把一些冗余的 reshape、transpose 干掉。python -m onnxsim model.onnx model_sim.onnx然后是量化。我一般先做动态量化dynamic quantization因为它不需要校准数据实施简单。如果动态量化的精度和速度都满足要求就不做静态量化了。如果动态量化速度不够动态量化只量化权重激活值还是 FP32再上静态量化。静态量化的流程前面讲过这里补充一个细节量化感知训练QAT。如果 PTQ训练后量化精度掉太多可以在训练阶段就插入伪量化节点让模型适应量化误差。QAT 的精度通常比 PTQ 高 1-2 个点但需要重新训练成本更高。4.3 延迟测试与瓶颈定位优化做完必须测延迟。测延迟有几个讲究。第一warmup。第一次推理往往包含内存分配、kernel 编译等开销必须跑几十次 warmup 之后再测。第二测端到端还是测单算子。端到端延迟是业务关心的但定位瓶颈要看单算子。ONNX Runtime 提供了 profiling 功能能输出每个算子的耗时。import onnxruntime as ort sess_options ort.SessionOptions() sess_options.enable_profiling True sess ort.InferenceSession(model_int8.onnx, sess_options) # 跑几次推理 prof_file sess.end_profiling()拿到 profiling 文件后用onnxruntime.tools里的脚本解析成表格按耗时排序就能看到哪个算子是大头。我遇到过的典型瓶颈包括LayerNorm 在 INT8 下反而变慢因为要额外的量化/反量化、大 kernel 的卷积在特定 shape 下效率低、transpose 导致的内存重排。4.4 精度验证的量化指标精度验证不能只看一个数。我一般看四个指标top-1 一致率、top-5 一致率、平均绝对误差MAE、最大绝对误差MaxAE。指标含义可接受阈值top-1 一致率量化前后预测类别相同的比例 99%top-5 一致率量化前后 top-5 集合的交集比例 99.5%MAE输出向量的平均绝对误差 0.01MaxAE输出向量的最大绝对误差 0.1如果 top-1 一致率不达标先看是哪些样本不一致。如果集中在某些类别说明这些类别的激活值分布特殊可以考虑对这些层单独处理。如果 MaxAE 很大但 MAE 很小说明只有少数样本误差大可能是离群值导致的检查校准集是否覆盖了这些情况。5. 常见问题与排查技巧实录5.1 量化后精度暴跌的排查路径精度暴跌是最常见的问题。我的排查顺序是这样的。先确认校准集是否有代表性。把校准集的分布和验证集的分布画出来对比如果差异大换校准集。再确认是不是某些层不适合量化。逐层做敏感度分析每次只量化一层看精度掉多少。掉得多的层加入黑名单保留 FP32。然后检查是否有算子不支持量化。ONNX Runtime 对某些算子比如某些激活函数、某些归一化的量化支持不完善会 fallback 到 FP32导致量化图里混着 FP32 和 INT8反而更慢。最后看是不是 per-tensor 量化的问题。改成 per-channel 试试。5.2 推理速度不升反降的几种情况量化后变慢听起来反直觉但确实会发生。原因通常有几个。一是量化/反量化开销。如果模型里量化层和 FP32 层交替出现每次切换都要插入 QuantizeLinear 和 DequantizeLinear这些操作本身有开销。解决办法是尽量减少 FP32 层的数量让量化区域连成片。二是硬件不支持 INT8 加速。有些老 GPU 的 INT8 算力还不如 FP16这时候量化反而亏。先查清楚目标硬件的 INT8 峰值算力。三是batch size 太小。INT8 的加速效果在大 batch 下才明显batch1 的时候 kernel launch 开销占主导量化收益被抵消。四是内存带宽瓶颈。如果模型本身是 memory-bound 而不是 compute-bound量化省下的计算量没用反而因为要读写量化参数增加了带宽压力。5.3 动态 shape 导致的优化失效动态 shape 是优化器的一大敌人。很多图优化和量化策略都假设 shape 是固定的。如果输入 shape 变化优化器可能退化成通用路径性能大打折扣。我的处理方式是如果业务允许尽量固定 shape。比如把输入 resize 到固定尺寸或者把 batch size 固定。如果必须支持动态 shape那就针对几个典型的 shape 分别做优化运行时根据实际 shape 选择对应的优化图。ONNX Runtime 支持profile机制可以为不同的 shape 范围预编译优化后的 kernel。配置好之后运行时切换 shape 不会触发重新编译。5.4 常见问题速查表问题现象可能原因排查方法解决方案量化后精度掉 2%校准集无代表性对比校准集与验证集分布换用线上采样数据量化后精度掉 2%某些层敏感逐层敏感度分析敏感层保留 FP32量化后变慢量化/反量化开销大profiling 看 QuantizeLinear 耗时减少 FP32 层量化后变慢硬件 INT8 算力弱查硬件规格改用 FP16动态 shape 性能差优化器退化对比固定 shape 性能固定 shape 或分档优化导出 ONNX 失败自定义算子看报错信息注册 symbolic融合后结果不对训练模式未切换检查 model.training调 model.eval()提示每次做完一步优化都要保存中间产物和对应的精度、延迟数据。优化是个迭代过程随时可能回滚没有基线数据会非常痛苦。5.5 几个我踩过的坑第一个坑是在 GPU 上做量化校准在 CPU 上推理。校准时的数值精度和推理时不一致导致量化参数偏移。后来统一在目标硬件上做校准。第二个坑是忽略了预处理和后处理的开销。模型本身优化到 20ms但图像 resize 花了 30ms整体还是慢。优化要看端到端不能只盯模型。第三个坑是过度优化。为了追求极致延迟把模型压得太狠结果线上遇到分布外样本时表现很差。优化要有底线精度损失控制在业务可接受范围内。第四个坑是没有版本管理。优化过程中产生了十几个中间模型最后分不清哪个是哪个。后来我养成了习惯每个模型文件都带上优化步骤和精度指标的命名比如model_int8_entropy_top1_99.2.onnx。6. 不同场景下的优化策略选择6.1 云端 GPU 推理场景云端 GPU 场景下算力相对充裕优化的重点应该放在吞吐量而不是单次延迟。这时候 batch size 可以开大量化的收益最明显。TensorRT 是这个场景下的首选它的 kernel 自动调优和 INT8 校准做得非常成熟。具体配置上我一般开 FP16 或 INT8开启 TensorRT 的builder优化让它自动搜索最优的 kernel 组合。注意 TensorRT 的 engine 是和 GPU 型号绑定的换卡要重新构建。6.2 边缘设备与移动端场景边缘设备的算力、内存、功耗都受限优化的重点是模型体积和内存占用。这时候量化几乎是必选项而且往往要上 INT8 甚至 INT4。剪枝和知识蒸馏也值得考虑。工具链上NCNN、MNN、TFLite 都是不错的选择。它们对 ARM 架构的 NEON 指令集有专门优化INT8 推理效率很高。要注意的是不同框架的量化方案不通用换框架要重新量化。6.3 大模型推理场景大模型的优化逻辑和小模型完全不同。大模型的瓶颈通常在内存带宽和KV Cache 管理上而不是计算量。这时候量化的主要收益是省显存让更大的模型能塞进有限的显存里。KV Cache 的优化是大模型特有的。常见手段包括Cache 量化、Cache 分页、Cache 复用prefix caching。这些技术能把显存占用降下来从而支持更大的 batch 或更长的上下文。另外大模型的算子融合策略也不一样。Attention 的 QKV 投影可以融合成一个矩阵乘FlashAttention 把整个 attention 计算融合成一个 kernel避免了中间矩阵的读写。这些优化对小模型意义不大但对大模型是刚需。6.4 实时流式推理场景流式推理的特点是输入是连续的小片段延迟要求极高。这时候 batch size 通常是 1量化的加速效果有限优化的重点应该放在减少 kernel launch 开销和流水线并行上。CUDA Graph 是流式场景的利器。它把一系列 kernel launch 捕获成一个图运行时一次性提交大幅减少 CPU 侧的调度开销。实测能把小 batch 场景的延迟降 30% 以上。7. 优化效果的度量与持续迭代7.1 建立可靠的基线优化之前必须先建立基线。基线包括原始模型的精度指标、端到端延迟、各阶段耗时分解、内存占用峰值、模型文件大小。这些数据要记录在案每次优化后对比。基线测试的环境要和线上一致。CPU 型号、GPU 型号、内存大小、驱动版本、框架版本任何一个不同都可能导致数据不可比。我一般会写一个 benchmark 脚本把这些环境信息一起打印出来。7.2 优化收益的归因分析做完一系列优化后要知道每一步贡献了多少。我的做法是逐步叠加每步都测。先做图优化测一次再加量化测一次再加剪枝测一次。这样能清楚看到每步的收益也能发现哪些步骤是负收益。有时候两步优化会互相干扰。比如先量化再剪枝和先剪枝再量化结果可能不一样。一般来说先做图优化再做剪枝最后做量化这个顺序比较稳。因为剪枝会改变权重分布量化参数需要重新校准。7.3 线上监控与回滚机制优化后的模型上线必须配套监控。重点监控的指标包括推理延迟的 P50/P95/P99、精度指标如果有在线评估、内存占用、错误率。一旦发现异常要能快速回滚到优化前的版本。所以优化前的模型和配置要完整保留回滚脚本要提前准备好。我见过因为回滚不及时导致线上事故扩大的案例教训很深刻。注意优化后的模型在线上遇到分布外数据时表现可能和离线评估差异很大。上线初期建议做小流量灰度观察一段时间再全量。7.4 持续迭代的思路模型优化不是一次性的工作。业务数据在变模型在更新硬件在升级优化策略也要跟着调整。我的建议是建立一个优化流水线把导出、简化、量化、验证、部署这些步骤自动化每次模型更新自动跑一遍。同时要维护一个优化配置库记录不同模型、不同硬件下的最优配置。新模型来了先查配置库有相似的直接复用没有再从头调。这样能大幅减少重复劳动。8. 一些个人体会做模型优化这几年最大的感受是优化是一门平衡的艺术不是追求极致的技术。你永远在精度、延迟、内存、成本之间做取舍没有银弹。一个在 A 场景下效果拔群的方案换到 B 场景可能完全失效。另一个体会是测量比优化本身更重要。很多人一上来就调参数、换工具但连瓶颈在哪都不知道。先把 profiling 做扎实把数据摆出来优化方向自然就清晰了。我见过太多团队花了两周做量化最后发现瓶颈根本不在计算上而在数据预处理。最后分享一个小技巧优化前先问自己三个问题。第一这个模型的延迟目标是多少当前差多少第二精度能接受掉多少第三目标硬件是什么支持哪些加速指令这三个问题答清楚了优化方案基本就定了。答不清楚做再多实验也是瞎撞。Model-Optimizer 这个领域变化很快新的量化算法、新的融合策略、新的硬件特性层出不穷。保持学习保持动手比记住某个具体工具的参数更重要。