1. 模型优化器到底在解决什么问题第一次接触 Model-Optimizer 这个概念是在一个推荐系统的排序模型上。当时线上推理延迟卡在 120ms 下不去GPU 利用率却只有 30% 出头团队里几个人对着 Profiler 的火焰图看了整整两天。后来发现问题不在模型结构也不在特征工程而是整个推理链路里存在大量冗余算子、精度浪费和内存搬运。那次经历让我意识到模型优化器不是一个“锦上添花”的工具而是把训练好的模型真正推到生产环境时必须跨过的一道坎。Model-Optimizer 本质上是一套面向模型推理阶段的优化工具集它做的事情可以拆成三条主线图级别优化、数值精度优化、内存与调度优化。图级别优化负责把计算图里那些“绕远路”的算子合并、消除、重排数值精度优化负责在可接受的精度损失范围内把 FP32 换成 FP16、BF16 甚至 INT8内存与调度优化则关注显存复用、算子融合后的内存布局、以及多流并发下的执行顺序。这三条线不是孤立的实际项目中往往是交叉进行的。它适合谁来用如果你只是跑跑 demo、做做学术实验可能感受不到它的价值。但只要你面临下面任意一种情况Model-Optimizer 就是绕不开的模型要部署到边缘设备算力和内存都紧张线上服务 QPS 高单次推理成本必须压下来模型参数量大单卡装不下需要做量化或切分推理框架对某些算子支持不好需要做图重写。这些场景下优化器带来的收益往往是数倍的而不是百分之几。我见过太多团队把模型训练完就直接丢给推理框架结果线上延迟高、成本高回头再补优化改造成本反而更大。正确的做法是在模型定稿之后、部署之前就把优化器纳入流程。这篇文章我会把 Model-Optimizer 的核心思路、实操步骤、参数选择、踩坑经验完整拆一遍尽量做到你照着做就能复现。2. 核心思路与方案选型拆解2.1 为什么优化器要分层次而不是一把梭很多人对模型优化的第一反应是“量化一下不就行了”。但实际做下来会发现单纯量化经常带来精度崩塌或者在某些算子上根本不支持。原因在于模型优化是一个多目标问题延迟、吞吐、精度、显存、硬件兼容性这几个目标之间是互相拉扯的。你不可能用一个开关同时满足所有目标。所以成熟的 Model-Optimizer 都会分层设计。最底层是图重写层它不改变数值只改变计算图的拓扑结构比如把 Conv BN ReLU 融合成一个算子把连续的 Transpose 消除掉把常量折叠提前算好。这一层是“无损”的收益稳定风险最低应该优先做。中间层是精度层也就是量化。它改变数值表示收益大但风险也大。量化又分训练后量化PTQ和量化感知训练QAT前者快但精度损失不可控后者需要重新训练但精度更稳。选哪个取决于你对精度的容忍度和是否有训练资源。最上层是调度层涉及算子在不同硬件单元上的分配、多流并发、显存池化。这一层最贴近硬件收益取决于具体平台通用性最差但往往能榨出最后一截性能。分层的意义在于你可以逐层开启每开一层就验证一次精度和性能出问题能快速定位是哪一层引入的。如果一把梭全开精度掉了你都不知道是图重写错了还是量化参数不对。2.2 图重写从计算图里“挤水分”图重写的核心思想是消除冗余。一个典型的推理图里冗余主要来自几个地方。第一是训练遗留的算子比如 Dropout 在推理时应该被消除BatchNorm 在推理时可以折叠进卷积权重。第二是框架转换产生的冗余比如从 PyTorch 导出到 ONNX 再到 TensorRT中间会插入大量 Cast、Reshape、Transpose。第三是用户代码里的低效写法比如反复计算同一个常量。我做过一个统计在一个典型的 CV 模型里图重写能消除大约 15% 到 30% 的算子数量。别小看这个比例算子数量直接关系到 kernel launch 开销和调度开销。在 GPU 上每个 kernel launch 都有固定开销算子越多这部分开销占比越大。消除冗余算子之后延迟下降往往比算子数量下降的比例还高。图重写里最值得说的是算子融合。以 Conv BN ReLU 为例推理时 BN 的参数是固定的可以把它折叠进 Conv 的权重和偏置里这样 BN 就消失了Conv 的输出直接过 ReLU。融合后原本三次内存读写变成一次内存带宽压力大幅下降。在内存带宽受限的场景下这种融合的收益非常明显。但融合不是无脑做的。有些融合会改变数值精度比如把多个小算子融合成一个大算子中间结果的累加顺序变了浮点误差就会变。对于精度敏感的模型融合后必须做数值对比。另外融合后的算子需要硬件或推理框架支持如果框架没有对应的 fused kernel融合反而会退化成多个算子白忙一场。2.3 量化精度和性能的平衡术量化是收益最大但也最容易翻车的一环。先说结论PTQ 适合快速验证QAT 适合最终上线。PTQ 不需要重新训练拿校准数据集跑一遍统计激活值分布就能算出量化参数。它的优点是快几十分钟就能搞定缺点是精度损失不可控尤其是当模型里有大量异常值或者激活分布不均匀时PTQ 可能直接把精度打崩。QAT 则是在训练阶段就模拟量化误差让模型自己去适应。它的精度通常比 PTQ 好很多但需要完整的训练流程和调参经验。我一般建议先用 PTQ 跑一版看看精度掉多少。如果掉点在可接受范围内比如 1% 以内就直接用 PTQ如果掉太多再上 QAT。量化的粒度也很关键。逐层量化per-layer是最粗的整个层共用一个 scale实现简单但精度差。逐通道量化per-channel是卷积层的标配每个输出通道一个 scale精度好很多。逐组量化per-group在权重上常用把权重按组切分每组一个 scale进一步降低精度损失。选粒度的时候权重一般用 per-channel 或 per-group激活一般用 per-tensor因为激活的分布通常更集中。还有一个容易被忽略的点是校准集的选择。PTQ 的精度高度依赖校准集校准集必须能代表真实推理时的数据分布。我见过有人拿训练集的前 100 张图做校准结果线上精度崩了因为训练集和线上数据的分布不一致。校准集应该从验证集或真实业务数据里采样数量不用多几百到几千个样本就够但分布一定要对。2.4 内存与调度榨干硬件的最后一滴内存优化的核心是复用。推理过程中很多中间张量的生命周期是错开的理论上可以复用同一块显存。但框架默认的分配策略往往是保守的每个张量都单独分配导致显存峰值很高。Model-Optimizer 会做生命周期分析把不重叠的张量分配到同一块内存从而降低峰值显存。显存降低的直接好处是可以用更大的 batch size从而提高吞吐。在 GPU 上batch size 从 1 提到 8吞吐可能提升 3 到 5 倍因为 GPU 的并行度被充分利用了。但 batch size 也不是越大越好太大会导致延迟上升需要根据业务对延迟和吞吐的权衡来定。调度优化则更贴近硬件。比如在 GPU 上计算和内存拷贝可以并发如果能把数据预取和计算重叠起来就能隐藏内存延迟。再比如多流并发把不同的算子分配到不同的 CUDA 流上让它们并行执行。这些优化需要深入理解硬件架构通用性不强但在特定平台上收益很大。3. 实操流程与关键环节实现3.1 环境准备与工具链搭建动手之前先把工具链理清楚。Model-Optimizer 不是一个单一工具而是一组工具的集合。常见的组合是PyTorch 做模型导出ONNX 做中间表示TensorRT 或 ONNX Runtime 做推理优化。这个组合的优点是生态成熟文档多踩坑容易找到答案。环境准备的第一步是版本对齐。PyTorch、ONNX、TensorRT 之间的版本兼容性是个大坑。我建议用官方推荐的版本组合不要自己乱配。比如 TensorRT 8.x 通常对应 ONNX 1.12 以上PyTorch 1.13 以上。版本不对齐会导致导出失败或者优化后的模型行为异常。第二步是准备校准数据。前面说过校准集要能代表真实分布。我一般会从验证集里随机采样 500 到 1000 个样本存成 numpy 数组或者直接用一个 DataLoader。校准数据不需要标签只需要输入。第三步是准备精度对比脚本。优化前后必须做数值对比否则你无法判断优化是否引入了精度损失。对比脚本要能计算输出张量的最大绝对误差、平均绝对误差、以及相对误差。对于分类模型还要对比 top-1 和 top-5 准确率。import numpy as np def compare_outputs(ref_output, opt_output, atol1e-3, rtol1e-3): max_abs_err np.max(np.abs(ref_output - opt_output)) mean_abs_err np.mean(np.abs(ref_output - opt_output)) rel_err np.max(np.abs(ref_output - opt_output) / (np.abs(ref_output) 1e-8)) print(fMax abs error: {max_abs_err:.6f}) print(fMean abs error: {mean_abs_err:.6f}) print(fMax rel error: {rel_err:.6f}) return max_abs_err atol or rel_err rtol这段脚本看着简单但它是你判断优化是否可用的第一道防线。我建议把它集成到 CI 里每次优化后自动跑一遍。3.2 图重写的具体操作步骤图重写的第一步是导出 ONNX。PyTorch 用torch.onnx.export导出时要注意几个参数。opset_version建议用 13 以上因为低版本对某些算子支持不好。dynamic_axes要正确设置否则 batch 维度会被固定死。do_constant_folding建议开启它会在导出时做一次常量折叠。导出之后用 ONNX 的优化工具做第一轮图重写。ONNX Runtime 提供了onnxruntime.transformers.optimizer和onnxoptimizer两个工具。前者针对 Transformer 类模型做了专门优化后者是通用的图优化。通用的优化包括消除 Identity、消除 Dropout、融合 ConvBN、融合 MatMulAdd 等。import onnx from onnxoptimizer import optimize model onnx.load(model.onnx) passes [ eliminate_identity, eliminate_nop_dropout, fuse_bn_into_conv, fuse_add_bias_into_conv, eliminate_unused_initializer, ] optimized_model optimize(model, passes) onnx.save(optimized_model, model_optimized.onnx)跑完这一轮用 Netron 打开优化前后的模型对比一下看看算子数量少了多少哪些融合生效了。我一般会记录优化前后的算子数量、参数量、模型文件大小作为第一轮收益的量化指标。第二轮图重写是在推理框架里做的。TensorRT 在构建 engine 的时候会自动做图优化包括层融合、精度校准、kernel 自动调优。ONNX Runtime 也有自己的图优化器可以通过SessionOptions配置优化级别。这一轮的优化更贴近硬件收益通常比第一轮更大。3.3 量化参数的计算与选择量化的核心是计算 scale 和 zero_point。以对称量化为例scale 的计算公式是scale max(abs(min_val), abs(max_val)) / (2^(bits-1) - 1)对于 INT8bits8分母是 127。zero_point 在对称量化里是 0在非对称量化里需要额外计算。实际工具里这些计算都是自动的但你需要理解背后的逻辑才能在精度出问题时知道怎么调。校准方法有几种。MinMax是最简单的直接取校准集上的最小值和最大值。MovingAverage是滑动平均对异常值更鲁棒。Entropy是熵校准通过最小化量化前后的信息熵差异来选阈值精度通常最好但计算量大。Percentile是百分位校准取 99.9% 分位数作为阈值能过滤掉极端异常值。我一般先用 Entropy 校准如果精度不达标再试 Percentile。MinMax 只在模型激活分布非常均匀时才用否则容易被异常值带偏。from onnxruntime.quantization import quantize_static, CalibrationMethod quantize_static( model_inputmodel_optimized.onnx, model_outputmodel_int8.onnx, calibration_data_readercalibration_reader, quant_formatQuantFormat.QDQ, per_channelTrue, activation_typeQuantType.QInt8, weight_typeQuantType.QInt8, calibrate_methodCalibrationMethod.Entropy, )这段代码里per_channelTrue表示权重量化用逐通道QuantFormat.QDQ表示用 Quantize-Dequantize 格式这种格式兼容性好但性能略差。如果追求极致性能可以用QOperator格式但兼容性会差一些。量化完之后必须做精度对比。如果精度掉了先检查是不是某些层不适合量化。通常第一层和最后一层对精度影响最大可以考虑跳过这两层的量化。另外LayerNorm、Softmax 这类对数值敏感的算子也建议保持 FP16 或 FP32。3.4 内存复用与 batch size 调优内存复用需要分析张量的生命周期。ONNX Runtime 和 TensorRT 都提供了显存池化机制但默认配置不一定最优。TensorRT 可以通过builder_config.set_memory_pool_limit来限制显存池大小强制复用。batch size 的调优是个经验活。我的做法是先固定一个较小的 batch size比如 1测出单次推理延迟然后逐步增大 batch size记录延迟和吞吐的变化。通常吞吐会先上升后趋于平缓延迟则线性上升。找到吞吐上升变缓的拐点那个 batch size 就是性价比最高的。Batch Size延迟 (ms)吞吐 (samples/s)显存占用 (MB)18.21221024412.53201280818.343715361630.153120483255.65753072从这张表能看出batch size 从 1 到 8吞吐提升了 3.5 倍延迟只增加了 2.2 倍。从 8 到 16吞吐只提升了 21%延迟却增加了 64%。所以 8 是这个场景下的甜点。当然具体数值取决于模型和硬件你需要自己测。3.5 优化效果的量化评估优化做完必须有一套完整的评估体系。我一般从四个维度评估精度、延迟、吞吐、显存。精度用前面说的对比脚本延迟和吞吐用 benchmark 工具显存用框架提供的 API 查询。延迟测试要注意 warmup。第一次推理往往包含 kernel 编译、显存分配等开销不能算数。我一般 warmup 10 次然后测 100 次取平均。测试时要用真实数据不要用随机数据因为随机数据可能触发不同的分支。吞吐测试要区分单流和多流。单流是串行执行多流是并发执行。多流吞吐更能反映线上服务的真实能力但需要框架支持。ONNX Runtime 可以通过inter_op_num_threads和intra_op_num_threads控制并发。显存测试要记录峰值显存而不是平均显存。峰值显存决定了你能用多大的 batch size也决定了会不会 OOM。TensorRT 的engine.get_device_memory_size()可以查询 engine 占用的显存。4. 常见问题与排查技巧实录4.1 精度掉点从哪几个方向排查精度掉点是量化后最常见的问题。排查思路是逐层定位。先把所有层都保持 FP32然后逐层开启量化看哪一层开启后精度掉得最多。ONNX Runtime 提供了QuantizationDebugger工具可以输出每层的量化误差。如果定位到某一层先看这层的激活分布。如果分布有长尾或者双峰说明校准方法不合适换 Entropy 或 Percentile 试试。如果分布正常但精度还是掉说明这层对数值敏感保持 FP16 或 FP32。另一个常见原因是校准集不匹配。校准集和真实数据的分布差异会导致 scale 计算偏差。解决办法是从真实业务数据里采样校准集或者用多个校准集取平均。还有一个隐蔽的原因是算子融合改变了数值。比如 ConvBN 融合后BN 的数值被折叠进 Conv浮点误差会累积。这种问题在 FP32 下不明显但量化后会放大。解决办法是对融合后的算子做数值对比如果误差超过阈值就放弃这个融合。4.2 性能不升反降优化器的“负优化”陷阱优化后性能反而下降这种情况我遇到过好几次。原因通常有几个。第一是融合后的算子没有对应的 kernel框架退化成多个算子反而增加了开销。解决办法是查框架的算子支持列表只做支持的融合。第二是量化后的算子在小 batch 下没有优势。INT8 的优势在于吞吐如果 batch size 是 1INT8 的 kernel 可能比 FP16 还慢因为量化反量化的开销占比大。解决办法是增大 batch size或者在小 batch 场景下不用 INT8。第三是显存池化导致的内存碎片。池化虽然降低了峰值显存但可能导致内存碎片反而增加分配开销。解决办法是调整池化策略或者关闭池化用默认分配。第四是多流并发的调度开销。多流并发虽然能提高吞吐但流之间的同步有开销。如果算子粒度太小同步开销可能超过并发收益。解决办法是合并小算子或者减少流的数量。4.3 部署环境差异导致的“水土不服”在开发机上优化得好好的部署到线上就出问题这种情况太常见了。原因通常是硬件差异。开发机可能是 A100线上是 T4两者的算力、显存、支持的指令集都不一样。TensorRT 的 engine 是硬件相关的A100 上构建的 engine 不能在 T4 上跑。解决办法是在目标硬件上构建 engine。如果线上有多种硬件就为每种硬件构建一个 engine。ONNX Runtime 的兼容性好一些但某些优化也是硬件相关的需要在目标硬件上验证。另一个原因是驱动和库版本差异。开发机的 CUDA 版本和线上不一致可能导致 kernel 行为不同。解决办法是统一版本或者用容器化部署把依赖打包进去。还有一个原因是输入数据差异。开发机用随机数据测试线上用真实数据真实数据的分布可能触发不同的分支。解决办法是用真实数据做 benchmark覆盖各种边界情况。4.4 常见问题速查表问题现象可能原因排查方法解决方案量化后精度掉超过 5%校准集不匹配对比校准集和真实数据分布重新采样校准集量化后精度掉超过 5%敏感层被量化逐层开启量化定位敏感层保持 FP16优化后延迟反而上升融合算子无 kernel查框架算子支持列表放弃不支持的融合优化后延迟反而上升小 batch 下 INT8 无优势对比不同 batch 下的延迟增大 batch 或不用 INT8显存峰值没降池化策略不当查显存分配日志调整池化策略线上精度和开发机不一致硬件差异对比硬件型号和驱动版本目标硬件上重新构建多流并发吞吐没提升同步开销过大查流同步次数合并小算子或减少流数模型导出 ONNX 失败opset 版本不兼容查不支持的算子升级 opset 或自定义算子这张表是我这几年踩坑攒下来的基本覆盖了 80% 的常见问题。遇到新问题先对照这张表排查能省不少时间。4.5 几个容易被忽略的实操心得第一个心得是优化前先做 baseline。很多人一上来就开优化结果优化后不知道提升了多少。正确的做法是先测一版未优化的 baseline记录精度、延迟、吞吐、显存作为对比基准。没有 baseline优化效果就无法量化。第二个心得是每次只改一个变量。图重写、量化、内存优化一次只开一个测完再开下一个。这样出问题能快速定位。我见过有人一次全开精度掉了排查了三天才发现是量化的问题图重写其实没问题。第三个心得是保留中间产物。导出的 ONNX、优化后的 ONNX、量化后的 ONNX都保留下来。出问题时可以逐级回退快速定位是哪一步引入的。另外中间产物也是复现问题的基础没有它们问题很难复现。第四个心得是用 Netron 可视化。Netron 能直观展示计算图的结构优化前后对比一目了然。我习惯在每次优化后用 Netron 打开看看确认融合是否生效有没有意外的算子残留。第五个心得是关注数值稳定性。量化后的模型对输入范围敏感如果输入超出校准时的范围量化误差会急剧放大。解决办法是在推理前对输入做 clip或者用动态量化。动态量化在推理时实时计算 scale对输入范围变化更鲁棒但开销略大。第六个心得是不要迷信工具默认配置。工具的默认配置往往是通用配置不一定适合你的场景。比如 TensorRT 默认的精度是 FP32你需要显式开启 FP16 或 INT8。再比如 ONNX Runtime 默认的优化级别是 BASIC你需要手动调到 EXTENDED 或 ALL。花点时间读文档把配置调对收益可能比换工具还大。5. 不同场景下的优化策略选择5.1 云端高吞吐场景吞吐优先云端服务通常对吞吐敏感对单次延迟容忍度较高。这种场景下优化策略是大 batch INT8 多流并发。大 batch 能充分利用 GPU 并行度INT8 能提升计算吞吐多流并发能隐藏内存延迟。具体操作上先把 batch size 调到显存允许的最大值然后开 INT8 量化最后开多流。多流的数量一般是 GPU 的 SM 数量除以 2具体值需要实测。这个组合下吞吐通常能比 baseline 提升 5 到 10 倍。但要注意大 batch 会增加延迟如果业务对 P99 延迟有要求需要权衡。另外INT8 量化在云端模型上精度损失通常可控因为云端模型一般比较大冗余度高。5.2 边缘设备场景延迟和内存优先边缘设备算力有限内存紧张优化策略是小 batch FP16 激进图重写。FP16 在边缘设备上通常有硬件加速比 INT8 更稳。图重写要更激进把能融合的都融合能消除的都消除因为边缘设备的 kernel launch 开销占比更大。边缘设备上还要注意算子兼容性。很多边缘芯片对算子支持不全某些融合算子可能不支持。解决办法是查芯片的算子支持列表或者用芯片厂商提供的优化工具。比如某些 NPU 有自己的量化工具和编译器用厂商工具通常比通用工具效果好。内存优化在边缘设备上尤其重要。除了显存复用还要考虑权重压缩。权重可以用更低的精度存储推理时再解压。这种方案能大幅降低内存占用但会增加解压开销需要权衡。5.3 精度敏感场景稳字当头有些场景对精度极其敏感比如医疗影像、自动驾驶。这种场景下优化策略是保守图重写 FP16 不做 INT8。图重写只做无损的比如消除 Dropout、折叠 BN不做可能改变数值的融合。FP16 的精度损失通常可接受但也要做数值对比。如果必须用 INT8那就上 QAT。QAT 在训练阶段就模拟量化误差精度比 PTQ 稳很多。但 QAT 需要重新训练成本高。另外QAT 的训练数据和推理数据分布要一致否则量化误差还是会放大。精度敏感场景还要做全面的数值验证。不能只测几个样本要覆盖各种边界情况。我一般会构造一批极端输入比如全零、全一、极大值、极小值看优化后的输出是否正常。5.4 多模型串联场景端到端优化实际业务里往往不是单个模型而是多个模型串联比如检测 分类 后处理。这种场景下单独优化每个模型收益有限要做端到端优化。端到端优化包括模型间的数据传递优化、算子跨模型融合、统一的内存池。模型间的数据传递往往是瓶颈。如果每个模型都做一次 host-device 拷贝开销很大。解决办法是把多个模型编译成一个计算图数据在 device 上直接传递不经过 host。TensorRT 的INetworkDefinition支持多模型组合ONNX Runtime 也支持多模型串联。跨模型融合比较难因为不同模型的算子可能不兼容。但有些融合是可行的比如检测模型的 NMS 可以和后续的分类模型融合。这需要深入理解业务逻辑不是通用优化能解决的。统一内存池能降低多模型场景下的显存峰值。多个模型如果各自管理显存峰值是累加的如果共享内存池峰值是取最大值。这个收益在多模型场景下很可观。6. 工具选型与版本管理经验6.1 主流工具对比与选择依据Model-Optimizer 的工具生态比较丰富常见的有 TensorRT、ONNX Runtime、OpenVINO、TVM 等。选哪个取决于你的硬件平台和部署环境。工具优势劣势适用场景TensorRTNVIDIA 硬件上性能最好只支持 NVIDIAengine 硬件相关NVIDIA GPU 云端/边缘ONNX Runtime跨平台兼容性好性能略逊于 TensorRT多平台部署OpenVINOIntel 硬件优化好只支持 IntelIntel CPU/VPUTVM可定制性强支持多种硬件上手门槛高研究/特殊硬件我的建议是如果只用 NVIDIA GPU优先 TensorRT如果需要跨平台用 ONNX Runtime如果用 Intel 硬件用 OpenVINO如果有特殊硬件或研究需求用 TVM。工具选型还要考虑团队熟悉度。一个团队熟悉的工具即使性能略差也比一个陌生工具好因为出问题能快速解决。我见过团队为了追求极致性能换工具结果踩坑踩了两个月得不偿失。6.2 版本兼容性那些年踩过的坑版本兼容性是 Model-Optimizer 最大的坑之一。PyTorch、ONNX、TensorRT、CUDA、驱动任何一个版本不匹配都可能导致失败。我整理了一个版本对应关系表供参考。PyTorchONNXTensorRTCUDA驱动1.131.128.511.85202.01.138.611.85252.11.148.612.15302.21.158.612.1535这张表不是绝对的但大方向是这样。实际选版本时建议用官方推荐的组合不要自己乱配。如果必须用某个特定版本先去官方文档查兼容性。版本管理的另一个经验是用容器。把整个工具链打包进 Docker 镜像开发、测试、生产用同一个镜像能避免大部分版本问题。镜像里固定 CUDA、驱动、库的版本换机器时直接拉镜像不用重新配环境。6.3 自定义算子与插件开发有时候框架不支持某个算子或者支持的算子性能不好就需要自定义算子。TensorRT 提供了 plugin 机制ONNX Runtime 提供了 custom op 机制。自定义算子需要写 CUDA kernel门槛较高但收益也大。写自定义算子的第一步是确认真的需要。很多情况下用现有算子组合能实现同样的功能性能也不差。只有当现有算子组合的性能瓶颈明显时才值得写自定义算子。第二步是参考官方实现。TensorRT 和 ONNX Runtime 都提供了示例插件照着改比自己从头写快。官方示例通常考虑了边界情况、数值稳定性、性能优化质量比自己写的高。第三步是充分测试。自定义算子的测试要覆盖各种输入形状、数据类型、边界值。我一般会写一个对比脚本用 PyTorch 的参考实现和自定义算子的输出做对比误差超过阈值就报错。自定义算子的维护成本也不低。框架升级时插件可能需要跟着改。所以能用官方算子就用官方算子自定义算子只在必要时用。7. 从优化到上线的完整链路7.1 优化流程的标准化优化流程标准化能大幅提升效率。我一般把流程分成五步导出、图重写、量化、性能测试、精度验证。每一步都有明确的输入输出和验收标准。导出这一步的验收标准是 ONNX 模型能正确加载输出和 PyTorch 一致。图重写的验收标准是算子数量下降输出误差在阈值内。量化的验收标准是精度掉点在可接受范围内。性能测试的验收标准是延迟和吞吐达到目标。精度验证的验收标准是端到端精度达标。标准化之后可以把流程写成脚本一键执行。我一般会写一个optimize.py输入是 PyTorch 模型和配置文件输出是优化后的模型和测试报告。这样每次优化只需要改配置不用重复劳动。7.2 自动化测试与回归优化后的模型必须做回归测试确保没有引入新的问题。回归测试包括精度回归、性能回归、兼容性回归。精度回归是拿一批固定的测试样本对比优化前后的输出。性能回归是测延迟和吞吐确保没有退化。兼容性回归是在目标硬件上跑一遍确保能正常加载和推理。我一般把这些测试集成到 CI 里每次优化后自动跑。测试不通过就阻断上线避免问题流到线上。CI 里还要记录每次优化的指标形成趋势图方便追踪优化效果。7.3 线上监控与持续优化模型上线不是终点而是起点。线上监控要关注几个指标延迟 P50/P99、吞吐、精度、显存、错误率。这些指标异常时要能快速定位是模型问题还是系统问题。持续优化是常态。业务数据分布会变硬件会升级框架会更新优化策略也要跟着调整。我一般每个季度做一次全面优化重新评估量化策略、batch size、工具版本。线上还有一个容易忽略的点是模型版本管理。优化后的模型和原模型要能共存出问题时能快速回滚。我一般会给每个模型版本打标签记录优化配置和测试结果方便追溯。8. 一些个人体会做模型优化这几年最大的体会是优化不是一次性的而是持续的过程。没有一劳永逸的优化方案业务在变硬件在变工具在变优化策略也要跟着变。把优化流程标准化、自动化比追求某一次极致优化更重要。第二个体会是精度和性能的权衡没有标准答案。不同的业务对精度和性能的容忍度不同需要和业务方充分沟通确定可接受的精度损失和性能目标。技术上的最优解不一定是业务上的最优解。第三个体会是工具是手段不是目的。不要为了用某个工具而用某个工具要根据实际需求选工具。有时候一个简单的图重写就能解决问题不需要上量化。有时候量化收益不大反而引入精度问题不如不做。第四个体会是文档和记录很重要。优化过程中踩的坑、试过的方案、最终的配置都要记录下来。下次遇到类似问题能快速参考。团队里其他人也能受益避免重复踩坑。最后分享一个小技巧优化前先问自己三个问题——瓶颈在哪、目标是什么、可接受的代价是什么。想清楚这三个问题优化方向就明确了不会盲目试错。我见过太多人一上来就开量化结果瓶颈在数据预处理量化白做了。先定位瓶颈再选方案效率高很多。