1. 模型优化器到底在解决什么问题第一次接触 Model-Optimizer 这个概念是在一个推荐系统的排序模型上。当时线上推理延迟死活压不下去单次请求要跑 180ms业务方要求降到 80ms 以内。我试过减层、减特征、换更小的模型效果都掉得厉害。后来团队里一位做推理优化的老哥说了一句“你这不是模型太大是没做图优化和算子融合。”那是我第一次意识到模型优化器不是“训练加速器”它更像是一个模型上线前的编译器和瘦身教练。Model-Optimizer 这个词在不同团队嘴里含义不太一样。有人指的是 PyTorch 生态里的torch.optim那一套优化算法SGD、Adam、AdamW 等有人指的是模型压缩工具链量化、剪枝、蒸馏还有人指的是推理引擎里的图优化模块算子融合、常量折叠、内存复用。我在这篇里把范围划清楚我讨论的是“面向模型部署与推理的优化工具链”也就是把训练好的模型经过一系列变换变成在目标硬件上跑得更快、更省内存、精度损失可控的产物。它解决的核心问题就三个延迟、吞吐、显存占用。适合谁来读如果你正在做模型上线、推理服务、端侧部署或者你训练完模型发现“跑得动但跑不快”这篇就是写给你的。如果你只是做算法实验、不关心部署那可以先收藏等你要上线那天再翻出来。我下面会按“整体设计思路 → 核心细节 → 实操过程 → 问题排查”这条线走中间会穿插我踩过的坑和实测数据。2. 整体设计思路与方案选型拆解2.1 为什么不能直接拿训练模型去推理训练框架和推理框架的诉求是相反的。训练要的是灵活动态图、可变 batch、随时改结构、方便调试。推理要的是确定固定图、固定 shape、算子融合、内存预分配。你直接拿 PyTorch 的model.eval()去跑推理框架内部还是会保留大量训练期的开销比如 autograd 的图结构、不必要的类型转换、逐算子 kernel launch。我做过一个对比实验同一个 BERT-base 模型batch1序列长度 128运行方式单次延迟显存占用PyTorch eager 模式42ms1.8GBPyTorch torch.compile21ms1.5GBONNX Runtime14ms1.1GBTensorRT FP166ms0.7GB这个表不是让你迷信某个数字而是说明一件事优化器带来的收益是数量级的不是百分之几。但代价是精度可能掉、转换可能失败、调试变难。所以选型的第一原则是先明确你的瓶颈在哪。如果是显存不够优先量化如果是延迟高优先图优化和算子融合如果是吞吐上不去优先 batch 调度和并发。2.2 优化手段的分层逻辑我把 Model-Optimizer 的手段分成四层从浅到深第一层图级优化。不改权重只改计算图。包括算子融合ConvBNReLU 合成一个、常量折叠、死代码消除、内存复用。这一层最安全精度零损失收益通常 20%~50%。第二层精度优化。把 FP32 降到 FP16 或 INT8。收益大但需要校准精度可能掉 0.1%~1%。INT8 需要校准数据集FP16 基本可以直接转。第三层结构优化。剪枝、蒸馏、低秩分解。这一层会改模型结构需要重新微调收益最大但风险也最大。第四层硬件特定优化。针对特定芯片的指令集、内存布局、算子库做定制。收益最高但可移植性最差。我的建议是按顺序做每做一层测一次精度和延迟。不要一上来就 INT8 量化先把图优化吃干净很多时候图优化做完就已经达标了。2.3 工具选型的几个关键考量市面上做模型优化的工具不少我列几个我用过的工具适用场景优点缺点ONNX Runtime跨平台推理生态好、支持广图优化程度中等TensorRTNVIDIA GPU性能极致绑定硬件、转换麻烦OpenVINOIntel CPU/GPUCPU 优化强生态相对封闭TVM多硬件可定制性强学习曲线陡torch.compilePyTorch 原生无痛接入后端依赖多选型的核心不是“哪个最强”而是“哪个和你现有链路最兼容”。我见过团队为了用 TensorRT 把整个服务重写结果维护成本爆炸。能在一个工具里解决的问题不要引入第二个工具。3. 核心细节解析与实操要点3.1 算子融合最安全的第一刀算子融合是图优化的核心。原理很简单把多个小算子合并成一个大算子减少 kernel launch 次数和中间张量的读写。比如Conv2d BatchNorm2d ReLU在推理时 BatchNorm 的参数是固定的可以折叠进 Conv 的权重和偏置里然后 ReLU 直接接在后面。数学上BatchNorm 在推理时是y (x - mean) / sqrt(var eps) * gamma betaConv 是x W * input b把 BN 代入 Conv得到新的权重和偏置W W * gamma / sqrt(var eps) b (b - mean) * gamma / sqrt(var eps) beta这样三个算子就变成一个 Conv。我在一个 ResNet-50 上实测融合后延迟从 18ms 降到 12ms精度完全不变。注意融合的前提是推理模式训练模式下 BN 的统计量在变不能折叠。另外如果 BN 后面不是 ReLU 而是别的激活融合规则要相应调整。3.2 量化收益大但坑也多量化是把 FP32 的权重和激活值用更低比特表示。最常见的是 INT8。核心问题是如何确定缩放因子scale和零点zero point。对称量化的公式q round(x / scale) x q * scalescale 通常取max(abs(x)) / 127。非对称量化多一个 zero pointq round(x / scale) zero_point校准的方法有两种静态校准和动态量化。静态校准需要一批代表性数据跑一遍统计每层激活值的分布确定 scale。动态量化在推理时实时算 scale灵活但慢。我踩过最大的坑是校准数据集分布不对。有一次我用随机噪声做校准结果量化后模型在真实数据上精度掉了 8 个点。后来换成真实业务数据采样 500 条精度只掉 0.3%。所以校准数据一定要覆盖真实场景的分布数量不用多500~1000 条足够但要有代表性。另一个坑是敏感层。有些层对量化特别敏感比如第一层和最后一层还有 attention 里的 softmax。我的做法是先全量化测精度如果掉太多就把敏感层保留 FP16 或 FP32混合精度推理。TensorRT 和 ONNX Runtime 都支持这种混合模式。3.3 内存复用与显存规划推理时的显存占用分三块权重、激活值、临时缓冲区。权重是固定的激活值和临时缓冲区是动态的。优化器会做内存复用如果两个张量的生命周期不重叠就复用同一块内存。这里有个实操技巧把 batch size 设成 1 先测峰值显存再逐步加大。因为很多框架的显存分配是“按需增长”你不跑到峰值就不知道真实占用。我习惯用torch.cuda.max_memory_allocated()或者 TensorRT 的engine.get_device_memory_size()来看。还有一个容易被忽略的点输入输出的内存布局。NCHW 和 NHWC 在不同硬件上性能差异很大。NVIDIA GPU 上 TensorRT 默认用 NHWC 做卷积因为 Tensor Core 对 NHWC 更友好。如果你从 PyTorch 转过去记得检查 transpose 是否被融合掉了否则会多出不必要的内存拷贝。3.4 动态 shape 的处理策略真实业务里输入 shape 往往是变的。比如 NLP 任务里序列长度不固定CV 任务里图片尺寸不固定。优化器对动态 shape 的支持程度直接决定了你能不能上线。三种策略固定 shape padding把输入 pad 到固定长度。简单性能最好但浪费计算。多 profile为几个典型 shape 各编译一个引擎运行时选择最接近的。TensorRT 的 optimization profile 就是这个思路。完全动态运行时根据实际 shape 编译。灵活但首次编译慢且某些优化用不了。我的经验是如果 shape 分布集中用多 profile如果分布很散先做 padding 到几个档位。完全动态只在 shape 真的无法预测时才用。4. 实操过程与核心环节实现4.1 从 PyTorch 导出 ONNX 的完整流程第一步永远是导出。以 PyTorch 为例import torch import torch.onnx model MyModel() model.load_state_dict(torch.load(model.pth)) model.eval() dummy_input torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy_input, model.onnx, export_paramsTrue, opset_version13, do_constant_foldingTrue, input_names[input], output_names[output], dynamic_axes{ input: {0: batch_size}, output: {0: batch_size} } )几个关键参数opset_version建议用 13 或更高低版本很多算子不支持。do_constant_folding让 PyTorch 先做一轮常量折叠减轻后续优化器负担。dynamic_axes声明哪些维度是动态的。不声明的话导出的图就是固定 shape。注意导出后一定要用onnx.checker.check_model()验证一遍再用onnxruntime跑一次和 PyTorch 的输出对比。我见过太多导出成功但数值对不上的情况通常是某个算子实现差异导致的。4.2 ONNX Runtime 的图优化配置ONNX Runtime 的优化分三个级别import onnxruntime as ort sess_options ort.SessionOptions() sess_options.graph_optimization_level ort.GraphOptimizationLevel.ORT_ENABLE_ALL sess_options.intra_op_num_threads 4 sess_options.inter_op_num_threads 2 session ort.InferenceSession(model.onnx, sess_options)ORT_ENABLE_ALL会开启所有图优化包括算子融合、常量折叠、冗余消除。intra_op_num_threads控制单个算子内部的并行度inter_op_num_threads控制算子之间的并行度。这两个参数对 CPU 推理影响很大建议根据核数调整intra_op设成物理核数inter_op设成 2 或 4。如果想看优化后的图可以设置sess_options.optimized_model_filepath model_optimized.onnx然后用 Netron 打开对比你会看到很多小算子被合并了。4.3 TensorRT 引擎构建与 INT8 校准TensorRT 的流程稍微复杂一点但收益也最大。核心步骤import tensorrt as trt logger trt.Logger(trt.Logger.WARNING) builder trt.Builder(logger) network builder.create_network(1 int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)) parser trt.OnnxParser(network, logger) with open(model.onnx, rb) as f: parser.parse(f.read()) config builder.create_builder_config() config.set_memory_pool_limit(trt.MemoryPoolType.WORKSPACE, 1 30) config.set_flag(trt.BuilderFlag.FP16) # INT8 校准 if use_int8: config.set_flag(trt.BuilderFlag.INT8) calibrator MyCalibrator(calibration_data) config.int8_calibrator calibrator engine builder.build_engine(network, config)INT8 校准器需要实现get_batch和get_batch_size方法返回校准数据。校准算法推荐用EntropyCalibrator2它比 MinMax 更稳对异常值不敏感。我实测过一个图像分类模型FP32 延迟 15msFP16 降到 7msINT8 降到 4msTop-1 精度从 76.2% 掉到 75.8%。这个代价在大多数业务里是可以接受的。4.4 精度对齐与回归测试优化完最重要的一步是精度对齐。我的做法是准备 100~200 条真实样本。用原始模型和优化后模型各跑一遍保存输出。计算余弦相似度或最大绝对误差。如果误差超过阈值逐层排查。排查工具推荐polygraphy它可以逐层对比 ONNX 和 TensorRT 的输出polygraphy run model.onnx --trt --onnxrt --validate它会告诉你哪一层的输出差异最大。通常问题出在量化层或者某个被融合的算子。实操心得精度对齐不要只看最终输出中间层的差异更能定位问题。另外测试数据一定要覆盖边界情况比如全零输入、极大值输入这些在真实场景里偶尔会出现。5. 常见问题与排查技巧实录5.1 转换失败类问题问题一ONNX 导出报错 “Unsupported operator”原因通常是用了 PyTorch 的自定义算子或新算子。解决办法升级 opset_version。用torch.onnx.register_custom_op_symbolic注册自定义符号。实在不行把该算子替换成等价的标准算子组合。问题二TensorRT 解析 ONNX 失败常见原因是 ONNX 里有权重为动态的算子或者用了 TensorRT 不支持的 opset。排查步骤用trtexec --onnxmodel.onnx --verbose看详细日志。用onnxsim简化模型onnxsim model.onnx model_sim.onnx。检查是否有NonZero、ScatterND等 TensorRT 支持较差的算子。5.2 精度下降类问题问题三量化后精度掉太多排查顺序检查校准数据是否覆盖真实分布。检查是否有层对量化敏感尝试混合精度。检查量化算法换 EntropyCalibrator2 试试。如果还不行只量化权重激活值保留 FP16。问题四FP16 溢出FP16 的动态范围比 FP32 小很多某些层的激活值可能溢出。解决办法在 TensorRT 里设置config.set_flag(trt.BuilderFlag.OBEY_PRECISION_CONSTRAINTS)强制某些层用 FP32。或者在导出 ONNX 时把敏感层标记为 FP32。5.3 性能不达预期类问题问题五优化后延迟没降多少可能原因瓶颈不在计算在数据拷贝或预处理。用 profiler 看时间分布。batch size 太小GPU 利用率低。尝试加大 batch。动态 shape 导致优化器没做深度融合。尝试固定 shape。问题六显存反而变大了通常是内存复用没生效或者优化器保留了中间张量。检查是否开启了do_constant_folding。是否有多余的 transpose 或 reshape。TensorRT 的 workspace 是否设得过大。5.4 常见问题速查表现象可能原因排查方法解决方向转换报错算子不支持看 verbose 日志升级 opset / 替换算子精度掉点多校准数据不对换真实数据校准混合精度延迟没降瓶颈在 IOprofiler 看时间优化预处理显存变大内存复用失效看优化后图关掉冗余优化首次推理慢引擎编译看是否运行时编译预编译引擎6. 我个人的几条实操建议做模型优化这几年我最大的体会是不要为了优化而优化。先测基线找到真正的瓶颈再动手。我见过太多团队花两周做量化结果发现瓶颈在数据预处理量化收益只有 5%。第二条建议是每一步都要有回退方案。优化后的模型精度掉了、性能不达标你要能快速回到上一个可用版本。我的做法是每个优化阶段都保存一份模型和对应的测试报告出问题直接回滚。第三条是精度和性能要一起看。只追求延迟低精度掉到业务不可接受等于白做。我通常会给业务方一个表格列出不同优化级别的延迟和精度让他们选。比如优化级别延迟精度适用场景原始 FP3242ms76.2%离线批处理图优化28ms76.2%一般在线服务FP1614ms76.1%延迟敏感服务INT87ms75.6%高并发场景最后分享一个小技巧用onnxsim先简化再优化。很多模型导出后有一堆冗余的 reshape、transpose、identity先简化一遍后续优化器的效果会好很多。这个步骤花不了几分钟但收益经常出乎意料。另外如果你的模型要跑在多种硬件上建议以 ONNX 为中间表示然后针对不同硬件用不同的后端。这样维护成本最低也最灵活。TensorRT 虽然快但绑定 NVIDIA一旦换硬件就要重做。ONNX Runtime 虽然没那么极致但胜在通用。怎么选看你的业务对性能和成本的权衡。