1. 模型优化器到底在解决什么问题第一次接触 Model-Optimizer 这个概念是在一个推荐系统的排序模型上。当时线上推理延迟死活压不下去单次请求要跑 180ms业务方要求降到 80ms 以内。我一开始的想法很朴素——换更小的模型、砍特征、减层数结果 AUC 掉了两个点业务方直接不干了。后来团队里一位做推理优化的老哥说了一句让我记到现在的话“你不需要换模型你需要一个模型优化器。”这句话点醒了我。Model-Optimizer 本质上不是一个具体的库或工具而是一类技术方案的统称它的核心目标是在尽量不损失模型精度的前提下让模型跑得更快、占得更少、部署更省。它解决的是“模型训练完之后怎么办”这个问题——训练只是上半场推理部署才是真正烧钱的下半场。具体来说Model-Optimizer 要处理的核心矛盾有三个精度与速度的矛盾、显存与并发的矛盾、通用性与硬件适配的矛盾。你训练出来的模型可能是 FP32 的、可能是动态图的、可能带着一堆训练专用的算子这些东西直接扔到线上就是灾难。优化器要做的事情就是把这些“训练态”的模型转换成“推理态”的高效形态。适合看这篇内容的人我大致分三类一类是刚把模型训出来、准备上线但发现性能不达标的算法工程师一类是负责推理服务、天天被延迟和成本指标追着跑的工程同学还有一类是想系统了解模型优化全貌、为技术选型做准备的技术负责人。不管你手上是 CV、NLP 还是推荐模型优化的底层逻辑是相通的。我下面会从整体设计思路、核心技术点、完整实操流程、踩坑排查几个维度把 Model-Optimizer 这套东西掰开揉碎讲清楚。所有参数和步骤都是我在实际项目里跑过的能直接抄作业。2. 模型优化的整体设计思路与方案选型2.1 优化的四个层次从粗到细很多人一提到模型优化就想到量化其实量化只是其中一环。我把整个优化空间分成四个层次从粗到细依次是结构层、数值层、计算图层、运行时层。理解这四个层次你才能知道每一步在动什么。结构层是最粗的动的是模型本身的架构。比如把大模型蒸馏成小模型、把多个算子融合成一个、剪掉不重要的通道或注意力头。这一层收益最大但风险也最高因为动了模型结构就可能影响精度需要重新微调。数值层就是大家熟悉的量化把 FP32 换成 FP16、INT8 甚至 INT4。这一层不动结构只动数据表示收益稳定、落地成熟是绝大多数项目的首选切入点。计算图层动的是图的结构比如算子融合、常量折叠、死代码消除。这一层通常由推理框架自动完成但你需要知道它在做什么才能判断为什么优化后反而变慢了。运行时层是最贴近硬件的包括内存复用、算子调度、并行策略。这一层和具体硬件强相关换一个芯片可能就要重做。提示新手建议从数值层入手收益明确、工具链成熟、回滚成本低。结构层和运行时层留给有经验的团队。2.2 为什么不能一步到位做极致优化我见过不少团队一上来就想把模型压到 INT4结果精度崩了返工重来浪费两周。这里有个很重要的原则优化要分层递进、逐层验证。先做无损的图优化再做 FP16再做 INT8每一步都跑一遍精度评估确认没掉点再往下走。原因很简单不同层次的优化会相互影响。你先做了算子融合再量化融合后的算子可能没有对应的量化实现反而要走回退路径。你先量化了再融合融合逻辑又要考虑量化参数的对齐。顺序错了工具链会给你一堆莫名其妙的报错。我的经验顺序是先图优化无损→ 再 FP16几乎无损→ 再 INT8需校准→ 最后考虑结构剪枝或蒸馏。每一步都保留一个可回滚的 checkpoint出问题能立刻退回上一版。2.3 工具选型别重复造轮子Model-Optimizer 这个领域开源工具已经非常成熟没必要自己写。主流的几条技术路线我列个表对比一下方便你按自己的场景选。工具/框架核心能力适用场景上手难度ONNX Runtime图优化、量化、跨平台推理通用部署CPU/GPU 都行低TensorRT极致 GPU 推理优化NVIDIA GPU 服务端中OpenVINOIntel 平台推理优化Intel CPU/核显中TVM编译式优化支持多后端需要深度定制、异构硬件高PyTorch 原生量化训练后量化、量化感知训练PyTorch 生态低选型的核心判断依据是你的部署硬件是什么。GPU 服务端优先 TensorRTCPU 服务端优先 ONNX Runtime 或 OpenVINO需要跨多种硬件就上 TVM。别为了追求“技术先进”选一个团队没人会用的框架维护成本会拖垮你。2.4 精度与性能的权衡策略优化的本质是权衡你得先明确自己的约束条件。我通常问三个问题延迟上限是多少、精度下限是多少、硬件成本预算是多少。这三个问题定了优化目标就清晰了。举个实际例子。之前那个推荐模型延迟要求 80msAUC 不能掉超过 0.3 个点GPU 预算不能增加。我先做图优化延迟从 180ms 降到 150ms精度无损。再做 FP16降到 110ms精度掉了 0.05 个点可接受。最后做 INT8 量化降到 75ms精度掉了 0.25 个点刚好卡在红线内。三步走完目标达成。如果 INT8 那步精度掉了 0.5 个点怎么办那就得回到量化校准环节换校准数据集、调整校准算法或者对敏感层保留 FP16。优化不是一次成功的是反复调参逼近约束边界的过程。3. 核心技术点深度拆解3.1 图优化算子融合与常量折叠图优化是 Model-Optimizer 里最“无痛”的一环因为它理论上不改变数值结果。核心操作有两个算子融合和常量折叠。算子融合是把多个小算子合并成一个大算子减少 kernel 启动开销和中间张量的读写。最典型的是 Conv BN ReLU 融合成一个算子。在训练态这三个是分开的因为 BN 需要更新 running mean 和 variance。但推理态 BN 的参数已经固定了可以把它折叠进 Conv 的权重里数学上完全等价。常量折叠是把图中那些输入固定的计算提前算好。比如模型里有个shape操作输入是固定的那这个 shape 在编译期就能算出来运行时直接读常量就行不用再算一遍。这两个操作看起来简单但收益很实在。我在一个 ResNet 变体上实测光算子融合就能减少约 30% 的 kernel 启动次数延迟降了 15% 左右。而且这部分优化是自动的ONNX Runtime 和 TensorRT 都会默认开启。注意算子融合有个坑融合后的算子如果精度敏感量化时可能出问题。比如 ConvBN 融合后BN 的缩放因子会影响量化的 scale 选择。所以融合和量化的顺序要提前规划好。3.2 量化从 FP32 到 INT8 的关键细节量化是收益最大也最容易翻车的一环。核心思想是用低比特整数表示浮点数减少内存占用和计算量。FP32 到 INT8理论上内存降 4 倍计算速度提升 2-4 倍取决于硬件是否有 INT8 加速指令。量化的数学本质是一个仿射映射real scale * (quantized - zero_point)。scale 是缩放因子zero_point 是零点偏移。校准的过程就是确定每一层、每个张量的 scale 和 zero_point。校准方法主要有三种MinMax、Moving Average MinMax、EntropyKL 散度。MinMax 最简单直接取张量的最大最小值但对异常值敏感。Entropy 方法会统计激活值的分布找一个最优的截断阈值精度通常更好但计算量大一些。我在实际项目里的经验是权重用 MinMax 就够了激活值用 Entropy 或 Moving Average 效果更稳。因为权重的分布相对固定激活值受输入数据影响大异常值多。校准数据集的选择也很关键。一般取 100-500 个样本就够但样本分布要覆盖线上真实场景。我踩过一次坑用训练集末尾的样本做校准结果线上遇到新类型的输入量化误差特别大。后来改成从线上日志里随机采样问题就解决了。3.3 混合精度不是所有层都适合低精度INT8 量化最怕的是某些层对精度特别敏感一量化就掉点。这时候就要用混合精度敏感层保留 FP16 或 FP32其他层用 INT8。哪些层通常比较敏感第一层和最后一层往往敏感因为第一层直接接触输入最后一层直接影响输出。还有那些激活值动态范围特别大的层比如 attention 里的 softmax 前后。以及残差连接的分支量化误差会累积。判断哪些层敏感最土但最有效的办法是逐层量化实验先全 INT8看掉点多少然后把某一层改回 FP16看精度恢复多少。恢复得多的就是敏感层。这个方法费时间但结果最可靠。TensorRT 和 ONNX Runtime 都支持通过配置指定哪些层用高精度。TensorRT 里可以用set_layer_precisionONNX Runtime 里可以在量化配置里设置nodes_to_exclude。3.4 内存复用与算子调度这一层偏工程但对延迟的影响很大。核心思想是复用内存、减少分配、优化调度。推理时每一层的输出张量都需要内存如果每层都新分配分配和释放的开销会累积。优化器会分析张量的生命周期把不再使用的张量内存回收给后面的张量用。这就是内存复用。算子调度是决定哪些算子并行、哪些串行。GPU 上多个 kernel 可以并发执行但前提是没有数据依赖。优化器会分析依赖图把能并行的算子排到一起充分利用 GPU 的 SM 资源。这部分通常由推理框架自动完成但你可以通过一些参数影响它。比如 TensorRT 的builder_config里可以设置 workspace 大小workspace 越大优化器能做的内存复用和调度优化就越多。我一般会把它设成 GPU 显存的 1/4 到 1/2太小了优化受限太大了浪费。4. 完整实操流程从训练模型到优化部署4.1 环境准备与依赖安装先说一下我的实验环境Ubuntu 20.04CUDA 11.8PyTorch 2.0ONNX Runtime 1.16TensorRT 8.6。这套组合是我目前用得最稳的版本兼容性经过验证。安装 ONNX Runtime 的 GPU 版本pip install onnxruntime-gpu1.16.0安装 TensorRT 稍微麻烦点需要先下载对应的 tar 包然后tar -xzvf TensorRT-8.6.1.6.Linux.x86_64-gnu.cuda-11.8.tar.gz export LD_LIBRARY_PATH$LD_LIBRARY_PATH:/path/to/TensorRT-8.6.1.6/lib pip install /path/to/TensorRT-8.6.1.6/python/tensorrt-8.6.1-cp38-none-linux_x86_64.whlPyTorch 导出 ONNX 需要onnx和onnxsimpip install onnx onnxsim提示TensorRT 版本和 CUDA 版本必须严格对应装错了会报各种找不到库的错误。装之前先nvcc --version确认 CUDA 版本。4.2 模型导出为 ONNX 格式ONNX 是模型优化的中间格式几乎所有优化工具都支持它。从 PyTorch 导出 ONNX 的代码大概长这样import torch import torch.onnx model.eval() dummy_input torch.randn(1, 3, 224, 224).cuda() 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_version13是我推荐的版本支持大部分算子且兼容性好。do_constant_foldingTrue开启常量折叠导出时就做一轮图优化。dynamic_axes设置动态 batch这样导出的模型可以接受不同 batch size 的输入部署时更灵活。导出后一定要用onnxsim再简化一遍它会做更激进的图优化python -m onnxsim model.onnx model_sim.onnx我实测下来onnxsim 能再减少 10%-20% 的节点数对后续量化也有好处。4.3 量化校准的完整操作量化分两步先校准再生成量化模型。ONNX Runtime 的量化工具用起来最方便。先准备校准数据。我一般写一个CalibrationDataReaderimport numpy as np from onnxruntime.quantization import CalibrationDataReader class MyCalibReader(CalibrationDataReader): def __init__(self, calib_data): self.data calib_data self.idx 0 def get_next(self): if self.idx len(self.data): return None batch self.data[self.idx] self.idx 1 return {input: batch} def rewind(self): self.idx 0校准数据从线上日志采样预处理成和推理时一致的格式。数量 200 个左右覆盖主要场景。然后执行量化from onnxruntime.quantization import quantize_static, QuantType, QuantFormat quantize_static( model_inputmodel_sim.onnx, model_outputmodel_int8.onnx, calibration_data_readerMyCalibReader(calib_data), quant_formatQuantFormat.QDQ, activation_typeQuantType.QInt8, weight_typeQuantType.QInt8, per_channelTrue, reduce_rangeFalse )quant_formatQDQ是推荐格式兼容性好。per_channelTrue表示权重按通道量化精度比按张量量化好。reduce_rangeFalse在支持 INT8 的硬件上设 False老硬件设 True 避免溢出。4.4 精度评估与性能测试量化完必须做两件事精度评估和性能测试。精度评估用你的业务指标分类模型看准确率排序模型看 AUC检测模型看 mAP。性能测试看延迟、吞吐、显存占用。精度评估的代码就是加载量化模型跑一遍验证集import onnxruntime as ort sess ort.InferenceSession(model_int8.onnx, providers[CUDAExecutionProvider]) preds [] for batch in val_loader: out sess.run(None, {input: batch.numpy()})[0] preds.append(out) # 用 preds 算业务指标性能测试我习惯用onnxruntime自带的 profiling或者直接写个循环测平均延迟import time warmup 20 runs 200 for _ in range(warmup): sess.run(None, {input: dummy_input}) start time.time() for _ in range(runs): sess.run(None, {input: dummy_input}) avg_latency (time.time() - start) / runs * 1000 print(f平均延迟: {avg_latency:.2f} ms)一定要先 warmup因为第一次推理会触发内存分配和 kernel 编译不 warmup 测出来的数据偏高。4.5 TensorRT 引擎构建与部署如果目标是 GPU 极致性能最后一步是转 TensorRT。ONNX 转 TensorRT 有两种方式trtexec命令行和 Python API。我推荐先用trtexec快速验证trtexec --onnxmodel_int8.onnx \ --saveEnginemodel.engine \ --fp16 \ --int8 \ --workspace4096 \ --minShapesinput:1x3x224x224 \ --optShapesinput:8x3x224x224 \ --maxShapesinput:32x3x224x224--fp16 --int8表示允许混合精度TensorRT 会自动选择。--workspace4096是 4GB 工作空间。minShapes/optShapes/maxShapes定义动态 batch 的范围optShapes是性能最优的 batch sizeTensorRT 会针对它做优化。构建完 engine 后用 Python 加载推理import tensorrt as trt import pycuda.driver as cuda logger trt.Logger(trt.Logger.WARNING) with open(model.engine, rb) as f: engine trt.Runtime(logger).deserialize_cuda_engine(f.read()) context engine.create_execution_context() # 分配输入输出显存执行推理TensorRT 的推理代码比较繁琐需要手动管理显存。生产环境建议封装成服务或者用 Triton Inference Server 来托管。5. 常见问题与排查技巧实录5.1 量化后精度掉太多怎么办这是最高频的问题。排查思路按顺序来第一检查校准数据。是不是分布和线上不一致是不是样本太少我遇到过用 50 个样本校准结果精度掉 1 个点加到 300 个样本后只掉 0.2 个点。第二检查量化配置。per_channel开了吗reduce_range设对了吗激活值量化用的是 MinMax 还是 Entropy换成 Entropy 通常能救回一些精度。第三找敏感层。逐层回退到 FP16看哪层影响最大。把最敏感的几层排除量化。第四考虑量化感知训练QAT。如果训练后量化怎么调都不行就在训练时模拟量化误差让模型自己适应。QAT 能把 INT8 的精度损失压到 0.1 个点以内但需要重新训练成本高。5.2 优化后反而变慢了这个坑我也踩过。原因通常有几个一是算子融合后某些融合算子在你的硬件上没有优化实现走了通用路径反而比分开跑慢。解决办法是关掉部分融合或者换推理框架。二是量化后硬件不支持 INT8 加速需要反量化回 FP32 计算多了一次转换开销。确认你的硬件有 INT8 指令集比如 NVIDIA 的 Turing 架构之后、Intel 的 VNNI 指令集。三是动态 batch 设置不合理。optShapes设的 batch size 和实际线上不一致TensorRT 针对错误的 batch size 做了优化。把optShapes设成线上最常见的 batch size。四是内存瓶颈。模型变小了但数据传输成了瓶颈比如 CPU 到 GPU 的拷贝时间占比变高。这时候要考虑把预处理也放到 GPU 上。5.3 动态 shape 支持问题很多模型部署时需要支持动态 batch 或动态序列长度。ONNX 导出时用dynamic_axes声明TensorRT 用minShapes/optShapes/maxShapes声明。但有些算子对动态 shape 支持不好比如 reshape、transpose 在动态维度上容易出错。我的经验是尽量把动态维度限制在 batch 维度其他维度固定。序列长度动态的话用 padding 到固定长度或者用 TensorRT 的IShape机制。如果实在要全动态ONNX Runtime 的支持比 TensorRT 好可以先用 ONNX Runtime 验证。5.4 常见问题速查表问题现象可能原因排查方向量化后精度掉 1 点校准数据分布不对换线上采样数据增加样本量优化后延迟反而升高算子融合不兼容硬件关闭部分融合换框架TensorRT 构建失败算子不支持查 TensorRT 支持的算子列表替换或自定义插件动态 shape 报错算子不支持动态维度固定非 batch 维度或换 ONNX Runtime显存占用没降内存复用没生效增大 workspace检查张量生命周期首次推理特别慢未 warmup加 warmup 轮次触发 kernel 编译5.5 几个独家避坑技巧第一个技巧导出 ONNX 前先把模型里的训练专用算子干掉。比如 dropout、batch norm 的训练模式分支这些在推理时不需要留着会干扰图优化。用model.eval()切到推理模式再检查一遍有没有残留的训练算子。第二个技巧量化校准数据一定要做和推理时完全一致的预处理。我见过有人校准用归一化后的数据推理时忘了归一化结果量化 scale 完全不对。预处理代码最好抽成一个函数校准和推理共用。第三个技巧保留一个 FP32 的 baseline 模型。优化过程中随时对比一旦精度掉超预期立刻回退。别等到优化完了才发现精度崩了那时候已经找不到是哪一步出的问题。第四个技巧TensorRT engine 和硬件绑定。在一个 GPU 上构建的 engine换一个型号的 GPU 可能就用不了需要重新构建。生产环境部署时engine 构建要放在目标机器上做或者用trtexec的--saveEngine在目标机器上生成。6. 不同场景下的优化策略差异6.1 CV 模型优化以 ResNet 和 YOLO 为例CV 模型的优化相对成熟因为结构规整、算子标准。ResNet 这类分类模型图优化和量化收益都很明显。我实测 ResNet50 从 FP32 到 INT8延迟降 3 倍多精度掉 0.3 个点以内。YOLO 这类检测模型稍微复杂点因为后处理NMS部分不好量化。我的做法是主干网络量化后处理保留 FP32。ONNX Runtime 里可以把 NMS 相关节点排除量化TensorRT 里可以用插件实现 NMS。CV 模型还有个特点是输入尺寸固定所以可以针对特定尺寸做极致优化。TensorRT 对固定 shape 的优化比动态 shape 好很多如果业务允许尽量固定输入尺寸。6.2 NLP 模型优化Transformer 的特殊处理Transformer 类模型的优化难点在 attention 机制。attention 里的 softmax 对精度敏感量化容易掉点。我的经验是softmax 前后保留 FP16其他部分 INT8。另外 Transformer 的序列长度动态对 TensorRT 不友好。可以用 padding 到固定长度或者用 TensorRT 的IShape机制。如果序列长度变化很大ONNX Runtime 的动态 shape 支持更省心。还有一点Transformer 的参数量大量化收益特别明显。BERT-base 从 FP32 到 INT8模型大小从 400MB 降到 100MB延迟降 2-3 倍。这部分收益值得花时间调。6.3 推荐模型优化稀疏与稠密的混合推荐模型通常是稀疏特征加稠密网络优化策略要分开看。稀疏部分主要是 embedding 查表瓶颈在内存带宽优化方向是压缩 embedding 表、用低精度存储。稠密部分就是常规的 MLP量化和图优化都适用。推荐模型的另一个特点是 batch size 大动辄几千。这时候内存复用和算子调度的优化收益很大。TensorRT 的大 batch 优化做得不错但要注意 workspace 要设够不然优化受限。我做过一个推荐模型batch size 4096FP32 延迟 180msINT8 加图优化后降到 75ms显存占用从 12GB 降到 4GB。关键就是把 embedding 表用 INT8 存储稠密部分用 FP16混合精度配置调了好几轮才稳定。7. 优化效果的度量与持续迭代7.1 建立完整的评估指标体系优化不能只看延迟要建立一套完整的指标体系。我通常关注这几个P50/P99 延迟、吞吐量QPS、显存占用、精度指标、模型大小。P99 延迟比 P50 更重要因为线上体验由长尾决定。吞吐量决定你的服务成本。显存占用决定单卡能部署几个模型。精度指标是红线不能破。模型大小影响加载速度和存储成本。这些指标要一起看不能顾此失彼。我见过为了压延迟把 batch size 设成 1结果吞吐暴跌单机 QPS 从 1000 降到 200成本反而上升。7.2 A/B 测试与灰度发布优化后的模型上线前一定要做 A/B 测试。把优化模型和原模型同时部署流量按比例分流对比业务指标。只有业务指标不降优化才算成功。灰度发布是控制风险的关键。先放 1% 流量观察一天没问题再放 10%再 50%最后全量。每一步都留回滚方案出问题能立刻切回原模型。我踩过一次坑优化模型离线评估精度没问题上线后业务指标掉了。排查发现是量化对某些长尾样本的误差特别大离线验证集没覆盖到。后来改成从线上日志采样做验证集问题就暴露出来了。7.3 持续优化的迭代节奏模型优化不是一次性的是持续迭代的过程。业务在变、数据在变、硬件在升级优化策略也要跟着调整。我的节奏是每次模型更新都重新跑一遍优化流程每季度评估一次硬件升级带来的优化空间。新硬件可能支持更低的精度比如 INT4或者有新的指令集能带来额外收益。另外优化配置要版本化管理。每次优化的参数、校准数据、评估结果都记录下来方便回溯和对比。我用一个简单的 YAML 文件管理这些配置配合 Git 做版本控制效果不错。8. 我在实际项目中的几点体会做模型优化这几年最大的体会是优化是工程和算法的交叉地带两边都得懂。只懂算法不懂工程你不知道硬件瓶颈在哪只懂工程不懂算法你不知道哪些层能动、哪些不能动。第二个体会是别追求极致追求够用。优化到满足业务约束就行再往下压收益递减、风险递增。我见过团队为了压最后 5ms 延迟花了两周调参结果业务方说 5ms 根本感知不到。第三个体会是工具是死的场景是活的。同一套优化流程换个模型、换个硬件、换个业务场景可能就完全不适用。别迷信某个“最佳实践”要理解原理根据实际情况调整。最后分享一个我常用的小技巧优化前先做 profiling找到真正的瓶颈。很多人一上来就量化结果发现瓶颈在数据预处理量化半天没效果。用nsys或nvprof跑一遍看清楚时间花在哪再决定优化方向。这个习惯帮我省了大量无效工作。模型优化这条路坑多但收益也大。把延迟从 180ms 压到 75ms 的那一刻那种成就感是实打实的。希望这些经验能帮你少走点弯路把模型真正跑出该有的性能。
1. 模型优化器到底在解决什么问题第一次接触 Model-Optimizer 这个概念是在一个推荐系统的排序模型上。当时线上推理延迟死活压不下去单次请求要跑 180ms业务方要求降到 80ms 以内。我一开始的想法很朴素——换更小的模型、砍特征、减层数结果 AUC 掉了两个点业务方直接不干了。后来团队里一位做推理优化的老哥说了一句让我记到现在的话“你不需要换模型你需要一个模型优化器。”这句话点醒了我。Model-Optimizer 本质上不是一个具体的库或工具而是一类技术方案的统称它的核心目标是在尽量不损失模型精度的前提下让模型跑得更快、占得更少、部署更省。它解决的是“模型训练完之后怎么办”这个问题——训练只是上半场推理部署才是真正烧钱的下半场。具体来说Model-Optimizer 要处理的核心矛盾有三个精度与速度的矛盾、显存与并发的矛盾、通用性与硬件适配的矛盾。你训练出来的模型可能是 FP32 的、可能是动态图的、可能带着一堆训练专用的算子这些东西直接扔到线上就是灾难。优化器要做的事情就是把这些“训练态”的模型转换成“推理态”的高效形态。适合看这篇内容的人我大致分三类一类是刚把模型训出来、准备上线但发现性能不达标的算法工程师一类是负责推理服务、天天被延迟和成本指标追着跑的工程同学还有一类是想系统了解模型优化全貌、为技术选型做准备的技术负责人。不管你手上是 CV、NLP 还是推荐模型优化的底层逻辑是相通的。我下面会从整体设计思路、核心技术点、完整实操流程、踩坑排查几个维度把 Model-Optimizer 这套东西掰开揉碎讲清楚。所有参数和步骤都是我在实际项目里跑过的能直接抄作业。2. 模型优化的整体设计思路与方案选型2.1 优化的四个层次从粗到细很多人一提到模型优化就想到量化其实量化只是其中一环。我把整个优化空间分成四个层次从粗到细依次是结构层、数值层、计算图层、运行时层。理解这四个层次你才能知道每一步在动什么。结构层是最粗的动的是模型本身的架构。比如把大模型蒸馏成小模型、把多个算子融合成一个、剪掉不重要的通道或注意力头。这一层收益最大但风险也最高因为动了模型结构就可能影响精度需要重新微调。数值层就是大家熟悉的量化把 FP32 换成 FP16、INT8 甚至 INT4。这一层不动结构只动数据表示收益稳定、落地成熟是绝大多数项目的首选切入点。计算图层动的是图的结构比如算子融合、常量折叠、死代码消除。这一层通常由推理框架自动完成但你需要知道它在做什么才能判断为什么优化后反而变慢了。运行时层是最贴近硬件的包括内存复用、算子调度、并行策略。这一层和具体硬件强相关换一个芯片可能就要重做。提示新手建议从数值层入手收益明确、工具链成熟、回滚成本低。结构层和运行时层留给有经验的团队。2.2 为什么不能一步到位做极致优化我见过不少团队一上来就想把模型压到 INT4结果精度崩了返工重来浪费两周。这里有个很重要的原则优化要分层递进、逐层验证。先做无损的图优化再做 FP16再做 INT8每一步都跑一遍精度评估确认没掉点再往下走。原因很简单不同层次的优化会相互影响。你先做了算子融合再量化融合后的算子可能没有对应的量化实现反而要走回退路径。你先量化了再融合融合逻辑又要考虑量化参数的对齐。顺序错了工具链会给你一堆莫名其妙的报错。我的经验顺序是先图优化无损→ 再 FP16几乎无损→ 再 INT8需校准→ 最后考虑结构剪枝或蒸馏。每一步都保留一个可回滚的 checkpoint出问题能立刻退回上一版。2.3 工具选型别重复造轮子Model-Optimizer 这个领域开源工具已经非常成熟没必要自己写。主流的几条技术路线我列个表对比一下方便你按自己的场景选。工具/框架核心能力适用场景上手难度ONNX Runtime图优化、量化、跨平台推理通用部署CPU/GPU 都行低TensorRT极致 GPU 推理优化NVIDIA GPU 服务端中OpenVINOIntel 平台推理优化Intel CPU/核显中TVM编译式优化支持多后端需要深度定制、异构硬件高PyTorch 原生量化训练后量化、量化感知训练PyTorch 生态低选型的核心判断依据是你的部署硬件是什么。GPU 服务端优先 TensorRTCPU 服务端优先 ONNX Runtime 或 OpenVINO需要跨多种硬件就上 TVM。别为了追求“技术先进”选一个团队没人会用的框架维护成本会拖垮你。2.4 精度与性能的权衡策略优化的本质是权衡你得先明确自己的约束条件。我通常问三个问题延迟上限是多少、精度下限是多少、硬件成本预算是多少。这三个问题定了优化目标就清晰了。举个实际例子。之前那个推荐模型延迟要求 80msAUC 不能掉超过 0.3 个点GPU 预算不能增加。我先做图优化延迟从 180ms 降到 150ms精度无损。再做 FP16降到 110ms精度掉了 0.05 个点可接受。最后做 INT8 量化降到 75ms精度掉了 0.25 个点刚好卡在红线内。三步走完目标达成。如果 INT8 那步精度掉了 0.5 个点怎么办那就得回到量化校准环节换校准数据集、调整校准算法或者对敏感层保留 FP16。优化不是一次成功的是反复调参逼近约束边界的过程。3. 核心技术点深度拆解3.1 图优化算子融合与常量折叠图优化是 Model-Optimizer 里最“无痛”的一环因为它理论上不改变数值结果。核心操作有两个算子融合和常量折叠。算子融合是把多个小算子合并成一个大算子减少 kernel 启动开销和中间张量的读写。最典型的是 Conv BN ReLU 融合成一个算子。在训练态这三个是分开的因为 BN 需要更新 running mean 和 variance。但推理态 BN 的参数已经固定了可以把它折叠进 Conv 的权重里数学上完全等价。常量折叠是把图中那些输入固定的计算提前算好。比如模型里有个shape操作输入是固定的那这个 shape 在编译期就能算出来运行时直接读常量就行不用再算一遍。这两个操作看起来简单但收益很实在。我在一个 ResNet 变体上实测光算子融合就能减少约 30% 的 kernel 启动次数延迟降了 15% 左右。而且这部分优化是自动的ONNX Runtime 和 TensorRT 都会默认开启。注意算子融合有个坑融合后的算子如果精度敏感量化时可能出问题。比如 ConvBN 融合后BN 的缩放因子会影响量化的 scale 选择。所以融合和量化的顺序要提前规划好。3.2 量化从 FP32 到 INT8 的关键细节量化是收益最大也最容易翻车的一环。核心思想是用低比特整数表示浮点数减少内存占用和计算量。FP32 到 INT8理论上内存降 4 倍计算速度提升 2-4 倍取决于硬件是否有 INT8 加速指令。量化的数学本质是一个仿射映射real scale * (quantized - zero_point)。scale 是缩放因子zero_point 是零点偏移。校准的过程就是确定每一层、每个张量的 scale 和 zero_point。校准方法主要有三种MinMax、Moving Average MinMax、EntropyKL 散度。MinMax 最简单直接取张量的最大最小值但对异常值敏感。Entropy 方法会统计激活值的分布找一个最优的截断阈值精度通常更好但计算量大一些。我在实际项目里的经验是权重用 MinMax 就够了激活值用 Entropy 或 Moving Average 效果更稳。因为权重的分布相对固定激活值受输入数据影响大异常值多。校准数据集的选择也很关键。一般取 100-500 个样本就够但样本分布要覆盖线上真实场景。我踩过一次坑用训练集末尾的样本做校准结果线上遇到新类型的输入量化误差特别大。后来改成从线上日志里随机采样问题就解决了。3.3 混合精度不是所有层都适合低精度INT8 量化最怕的是某些层对精度特别敏感一量化就掉点。这时候就要用混合精度敏感层保留 FP16 或 FP32其他层用 INT8。哪些层通常比较敏感第一层和最后一层往往敏感因为第一层直接接触输入最后一层直接影响输出。还有那些激活值动态范围特别大的层比如 attention 里的 softmax 前后。以及残差连接的分支量化误差会累积。判断哪些层敏感最土但最有效的办法是逐层量化实验先全 INT8看掉点多少然后把某一层改回 FP16看精度恢复多少。恢复得多的就是敏感层。这个方法费时间但结果最可靠。TensorRT 和 ONNX Runtime 都支持通过配置指定哪些层用高精度。TensorRT 里可以用set_layer_precisionONNX Runtime 里可以在量化配置里设置nodes_to_exclude。3.4 内存复用与算子调度这一层偏工程但对延迟的影响很大。核心思想是复用内存、减少分配、优化调度。推理时每一层的输出张量都需要内存如果每层都新分配分配和释放的开销会累积。优化器会分析张量的生命周期把不再使用的张量内存回收给后面的张量用。这就是内存复用。算子调度是决定哪些算子并行、哪些串行。GPU 上多个 kernel 可以并发执行但前提是没有数据依赖。优化器会分析依赖图把能并行的算子排到一起充分利用 GPU 的 SM 资源。这部分通常由推理框架自动完成但你可以通过一些参数影响它。比如 TensorRT 的builder_config里可以设置 workspace 大小workspace 越大优化器能做的内存复用和调度优化就越多。我一般会把它设成 GPU 显存的 1/4 到 1/2太小了优化受限太大了浪费。4. 完整实操流程从训练模型到优化部署4.1 环境准备与依赖安装先说一下我的实验环境Ubuntu 20.04CUDA 11.8PyTorch 2.0ONNX Runtime 1.16TensorRT 8.6。这套组合是我目前用得最稳的版本兼容性经过验证。安装 ONNX Runtime 的 GPU 版本pip install onnxruntime-gpu1.16.0安装 TensorRT 稍微麻烦点需要先下载对应的 tar 包然后tar -xzvf TensorRT-8.6.1.6.Linux.x86_64-gnu.cuda-11.8.tar.gz export LD_LIBRARY_PATH$LD_LIBRARY_PATH:/path/to/TensorRT-8.6.1.6/lib pip install /path/to/TensorRT-8.6.1.6/python/tensorrt-8.6.1-cp38-none-linux_x86_64.whlPyTorch 导出 ONNX 需要onnx和onnxsimpip install onnx onnxsim提示TensorRT 版本和 CUDA 版本必须严格对应装错了会报各种找不到库的错误。装之前先nvcc --version确认 CUDA 版本。4.2 模型导出为 ONNX 格式ONNX 是模型优化的中间格式几乎所有优化工具都支持它。从 PyTorch 导出 ONNX 的代码大概长这样import torch import torch.onnx model.eval() dummy_input torch.randn(1, 3, 224, 224).cuda() 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_version13是我推荐的版本支持大部分算子且兼容性好。do_constant_foldingTrue开启常量折叠导出时就做一轮图优化。dynamic_axes设置动态 batch这样导出的模型可以接受不同 batch size 的输入部署时更灵活。导出后一定要用onnxsim再简化一遍它会做更激进的图优化python -m onnxsim model.onnx model_sim.onnx我实测下来onnxsim 能再减少 10%-20% 的节点数对后续量化也有好处。4.3 量化校准的完整操作量化分两步先校准再生成量化模型。ONNX Runtime 的量化工具用起来最方便。先准备校准数据。我一般写一个CalibrationDataReaderimport numpy as np from onnxruntime.quantization import CalibrationDataReader class MyCalibReader(CalibrationDataReader): def __init__(self, calib_data): self.data calib_data self.idx 0 def get_next(self): if self.idx len(self.data): return None batch self.data[self.idx] self.idx 1 return {input: batch} def rewind(self): self.idx 0校准数据从线上日志采样预处理成和推理时一致的格式。数量 200 个左右覆盖主要场景。然后执行量化from onnxruntime.quantization import quantize_static, QuantType, QuantFormat quantize_static( model_inputmodel_sim.onnx, model_outputmodel_int8.onnx, calibration_data_readerMyCalibReader(calib_data), quant_formatQuantFormat.QDQ, activation_typeQuantType.QInt8, weight_typeQuantType.QInt8, per_channelTrue, reduce_rangeFalse )quant_formatQDQ是推荐格式兼容性好。per_channelTrue表示权重按通道量化精度比按张量量化好。reduce_rangeFalse在支持 INT8 的硬件上设 False老硬件设 True 避免溢出。4.4 精度评估与性能测试量化完必须做两件事精度评估和性能测试。精度评估用你的业务指标分类模型看准确率排序模型看 AUC检测模型看 mAP。性能测试看延迟、吞吐、显存占用。精度评估的代码就是加载量化模型跑一遍验证集import onnxruntime as ort sess ort.InferenceSession(model_int8.onnx, providers[CUDAExecutionProvider]) preds [] for batch in val_loader: out sess.run(None, {input: batch.numpy()})[0] preds.append(out) # 用 preds 算业务指标性能测试我习惯用onnxruntime自带的 profiling或者直接写个循环测平均延迟import time warmup 20 runs 200 for _ in range(warmup): sess.run(None, {input: dummy_input}) start time.time() for _ in range(runs): sess.run(None, {input: dummy_input}) avg_latency (time.time() - start) / runs * 1000 print(f平均延迟: {avg_latency:.2f} ms)一定要先 warmup因为第一次推理会触发内存分配和 kernel 编译不 warmup 测出来的数据偏高。4.5 TensorRT 引擎构建与部署如果目标是 GPU 极致性能最后一步是转 TensorRT。ONNX 转 TensorRT 有两种方式trtexec命令行和 Python API。我推荐先用trtexec快速验证trtexec --onnxmodel_int8.onnx \ --saveEnginemodel.engine \ --fp16 \ --int8 \ --workspace4096 \ --minShapesinput:1x3x224x224 \ --optShapesinput:8x3x224x224 \ --maxShapesinput:32x3x224x224--fp16 --int8表示允许混合精度TensorRT 会自动选择。--workspace4096是 4GB 工作空间。minShapes/optShapes/maxShapes定义动态 batch 的范围optShapes是性能最优的 batch sizeTensorRT 会针对它做优化。构建完 engine 后用 Python 加载推理import tensorrt as trt import pycuda.driver as cuda logger trt.Logger(trt.Logger.WARNING) with open(model.engine, rb) as f: engine trt.Runtime(logger).deserialize_cuda_engine(f.read()) context engine.create_execution_context() # 分配输入输出显存执行推理TensorRT 的推理代码比较繁琐需要手动管理显存。生产环境建议封装成服务或者用 Triton Inference Server 来托管。5. 常见问题与排查技巧实录5.1 量化后精度掉太多怎么办这是最高频的问题。排查思路按顺序来第一检查校准数据。是不是分布和线上不一致是不是样本太少我遇到过用 50 个样本校准结果精度掉 1 个点加到 300 个样本后只掉 0.2 个点。第二检查量化配置。per_channel开了吗reduce_range设对了吗激活值量化用的是 MinMax 还是 Entropy换成 Entropy 通常能救回一些精度。第三找敏感层。逐层回退到 FP16看哪层影响最大。把最敏感的几层排除量化。第四考虑量化感知训练QAT。如果训练后量化怎么调都不行就在训练时模拟量化误差让模型自己适应。QAT 能把 INT8 的精度损失压到 0.1 个点以内但需要重新训练成本高。5.2 优化后反而变慢了这个坑我也踩过。原因通常有几个一是算子融合后某些融合算子在你的硬件上没有优化实现走了通用路径反而比分开跑慢。解决办法是关掉部分融合或者换推理框架。二是量化后硬件不支持 INT8 加速需要反量化回 FP32 计算多了一次转换开销。确认你的硬件有 INT8 指令集比如 NVIDIA 的 Turing 架构之后、Intel 的 VNNI 指令集。三是动态 batch 设置不合理。optShapes设的 batch size 和实际线上不一致TensorRT 针对错误的 batch size 做了优化。把optShapes设成线上最常见的 batch size。四是内存瓶颈。模型变小了但数据传输成了瓶颈比如 CPU 到 GPU 的拷贝时间占比变高。这时候要考虑把预处理也放到 GPU 上。5.3 动态 shape 支持问题很多模型部署时需要支持动态 batch 或动态序列长度。ONNX 导出时用dynamic_axes声明TensorRT 用minShapes/optShapes/maxShapes声明。但有些算子对动态 shape 支持不好比如 reshape、transpose 在动态维度上容易出错。我的经验是尽量把动态维度限制在 batch 维度其他维度固定。序列长度动态的话用 padding 到固定长度或者用 TensorRT 的IShape机制。如果实在要全动态ONNX Runtime 的支持比 TensorRT 好可以先用 ONNX Runtime 验证。5.4 常见问题速查表问题现象可能原因排查方向量化后精度掉 1 点校准数据分布不对换线上采样数据增加样本量优化后延迟反而升高算子融合不兼容硬件关闭部分融合换框架TensorRT 构建失败算子不支持查 TensorRT 支持的算子列表替换或自定义插件动态 shape 报错算子不支持动态维度固定非 batch 维度或换 ONNX Runtime显存占用没降内存复用没生效增大 workspace检查张量生命周期首次推理特别慢未 warmup加 warmup 轮次触发 kernel 编译5.5 几个独家避坑技巧第一个技巧导出 ONNX 前先把模型里的训练专用算子干掉。比如 dropout、batch norm 的训练模式分支这些在推理时不需要留着会干扰图优化。用model.eval()切到推理模式再检查一遍有没有残留的训练算子。第二个技巧量化校准数据一定要做和推理时完全一致的预处理。我见过有人校准用归一化后的数据推理时忘了归一化结果量化 scale 完全不对。预处理代码最好抽成一个函数校准和推理共用。第三个技巧保留一个 FP32 的 baseline 模型。优化过程中随时对比一旦精度掉超预期立刻回退。别等到优化完了才发现精度崩了那时候已经找不到是哪一步出的问题。第四个技巧TensorRT engine 和硬件绑定。在一个 GPU 上构建的 engine换一个型号的 GPU 可能就用不了需要重新构建。生产环境部署时engine 构建要放在目标机器上做或者用trtexec的--saveEngine在目标机器上生成。6. 不同场景下的优化策略差异6.1 CV 模型优化以 ResNet 和 YOLO 为例CV 模型的优化相对成熟因为结构规整、算子标准。ResNet 这类分类模型图优化和量化收益都很明显。我实测 ResNet50 从 FP32 到 INT8延迟降 3 倍多精度掉 0.3 个点以内。YOLO 这类检测模型稍微复杂点因为后处理NMS部分不好量化。我的做法是主干网络量化后处理保留 FP32。ONNX Runtime 里可以把 NMS 相关节点排除量化TensorRT 里可以用插件实现 NMS。CV 模型还有个特点是输入尺寸固定所以可以针对特定尺寸做极致优化。TensorRT 对固定 shape 的优化比动态 shape 好很多如果业务允许尽量固定输入尺寸。6.2 NLP 模型优化Transformer 的特殊处理Transformer 类模型的优化难点在 attention 机制。attention 里的 softmax 对精度敏感量化容易掉点。我的经验是softmax 前后保留 FP16其他部分 INT8。另外 Transformer 的序列长度动态对 TensorRT 不友好。可以用 padding 到固定长度或者用 TensorRT 的IShape机制。如果序列长度变化很大ONNX Runtime 的动态 shape 支持更省心。还有一点Transformer 的参数量大量化收益特别明显。BERT-base 从 FP32 到 INT8模型大小从 400MB 降到 100MB延迟降 2-3 倍。这部分收益值得花时间调。6.3 推荐模型优化稀疏与稠密的混合推荐模型通常是稀疏特征加稠密网络优化策略要分开看。稀疏部分主要是 embedding 查表瓶颈在内存带宽优化方向是压缩 embedding 表、用低精度存储。稠密部分就是常规的 MLP量化和图优化都适用。推荐模型的另一个特点是 batch size 大动辄几千。这时候内存复用和算子调度的优化收益很大。TensorRT 的大 batch 优化做得不错但要注意 workspace 要设够不然优化受限。我做过一个推荐模型batch size 4096FP32 延迟 180msINT8 加图优化后降到 75ms显存占用从 12GB 降到 4GB。关键就是把 embedding 表用 INT8 存储稠密部分用 FP16混合精度配置调了好几轮才稳定。7. 优化效果的度量与持续迭代7.1 建立完整的评估指标体系优化不能只看延迟要建立一套完整的指标体系。我通常关注这几个P50/P99 延迟、吞吐量QPS、显存占用、精度指标、模型大小。P99 延迟比 P50 更重要因为线上体验由长尾决定。吞吐量决定你的服务成本。显存占用决定单卡能部署几个模型。精度指标是红线不能破。模型大小影响加载速度和存储成本。这些指标要一起看不能顾此失彼。我见过为了压延迟把 batch size 设成 1结果吞吐暴跌单机 QPS 从 1000 降到 200成本反而上升。7.2 A/B 测试与灰度发布优化后的模型上线前一定要做 A/B 测试。把优化模型和原模型同时部署流量按比例分流对比业务指标。只有业务指标不降优化才算成功。灰度发布是控制风险的关键。先放 1% 流量观察一天没问题再放 10%再 50%最后全量。每一步都留回滚方案出问题能立刻切回原模型。我踩过一次坑优化模型离线评估精度没问题上线后业务指标掉了。排查发现是量化对某些长尾样本的误差特别大离线验证集没覆盖到。后来改成从线上日志采样做验证集问题就暴露出来了。7.3 持续优化的迭代节奏模型优化不是一次性的是持续迭代的过程。业务在变、数据在变、硬件在升级优化策略也要跟着调整。我的节奏是每次模型更新都重新跑一遍优化流程每季度评估一次硬件升级带来的优化空间。新硬件可能支持更低的精度比如 INT4或者有新的指令集能带来额外收益。另外优化配置要版本化管理。每次优化的参数、校准数据、评估结果都记录下来方便回溯和对比。我用一个简单的 YAML 文件管理这些配置配合 Git 做版本控制效果不错。8. 我在实际项目中的几点体会做模型优化这几年最大的体会是优化是工程和算法的交叉地带两边都得懂。只懂算法不懂工程你不知道硬件瓶颈在哪只懂工程不懂算法你不知道哪些层能动、哪些不能动。第二个体会是别追求极致追求够用。优化到满足业务约束就行再往下压收益递减、风险递增。我见过团队为了压最后 5ms 延迟花了两周调参结果业务方说 5ms 根本感知不到。第三个体会是工具是死的场景是活的。同一套优化流程换个模型、换个硬件、换个业务场景可能就完全不适用。别迷信某个“最佳实践”要理解原理根据实际情况调整。最后分享一个我常用的小技巧优化前先做 profiling找到真正的瓶颈。很多人一上来就量化结果发现瓶颈在数据预处理量化半天没效果。用nsys或nvprof跑一遍看清楚时间花在哪再决定优化方向。这个习惯帮我省了大量无效工作。模型优化这条路坑多但收益也大。把延迟从 180ms 压到 75ms 的那一刻那种成就感是实打实的。希望这些经验能帮你少走点弯路把模型真正跑出该有的性能。
