1. 模型优化器到底在解决什么问题
第一次接触 Model-Optimizer 这个概念，是在一个推荐系统的排序模型上。当时线上推理延迟死活压不下去，单次请求要跑 180ms，业务方要求降到 50ms 以内。我试过换更小的模型、砍特征、加机器，效果都不理想——小模型精度掉得厉害，加机器成本又扛不住。后来一位做推理优化的朋友点了我一句：“你缺的不是模型，是优化器。”这句话让我重新理解了 Model-Optimizer 这个方向的价值。
Model-Optimizer 不是某一个具体的库或工具，而是一类技术方案的统称。它的核心目标很明确：在尽量不损失模型精度的前提下，让模型跑得更快、占得更少、部署更灵活。它解决的问题贯穿模型生命周期的后半段——训练完成之后，到真正上线服务之间的那段“最后一公里”。这段路看起来短，实际上坑最多：精度和速度的权衡、不同硬件的适配、量化后的精度补偿、算子融合的边界条件，每一个都能让人折腾好几天。
适合看这篇内容的人，我大致分三类。第一类是算法工程师，模型训完了要自己部署，发现推理性能不达标；第二类是工程侧的同学，负责把算法团队的模型接进服务框架，经常被延迟和显存问题卡住；第三类是做端侧部署的，手机、嵌入式设备上跑模型，算力和内存都紧张，优化器几乎是必选项。不管你属于哪一类，下面这些内容都是从实际项目里踩出来的，不是纸上谈兵。
2. 整体设计思路与方案选型拆解
2.1 为什么优化器不能“一招鲜”
很多人一开始会有一个误区：找一个最火的优化工具，套上去就完事了。我早期也这么想过，结果在一个 CV 模型上用了某量化方案，精度直接掉了 8 个点，根本没法上线。后来才明白，Model-Optimizer 的方案选型必须和你的场景强绑定。
选型的第一个维度是硬件目标。服务端 GPU 和端侧 NPU 的优化路径完全不同。GPU 上你可以用 FP16 混合精度、TensorRT 做层融合，端侧可能只能走 INT8 量化加定点运算。第二个维度是精度容忍度。推荐系统里排序模型掉 0.5 个点可能还能接受，但医疗影像分割模型掉 0.5 个点就是事故。第三个维度是工程成本。有些优化方案需要改模型结构、重训，有些只需要在推理时加一个转换步骤，投入产出比差很多。
我一般会先画一个简单的决策表，把这三个维度列出来，再去看候选方案。下面这个表是我在多个项目里总结出来的，可以直接参考：
| 场景类型 | 推荐优化路径 | 精度影响 | 工程成本 |
|---|---|---|---|
| 服务端 GPU 推理 | FP16 + 算子融合 + 动态批处理 | 极小 | 中 |
| 服务端 CPU 推理 | INT8 量化 + 图优化 | 小到中 | 中 |
| 端侧移动设备 | INT8 量化 + 剪枝 + 算子替换 | 中 | 高 |
| 边缘盒子 | INT8 量化 + 层融合 | 中 | 中 |
| 精度敏感场景 | FP16 + 算子融合，不做量化 | 极小 | 低 |
这张表不是绝对的，但能帮你快速缩小范围。比如你做的是端侧人脸检测，那基本就是 INT8 量化加剪枝的路子，不用纠结要不要上 FP16。
2.2 优化器的三层结构：图级、算子级、数据级
把 Model-Optimizer 拆开看，它其实在三个层面上做事情。理解这三层，你就能明白为什么有些优化能叠加，有些会冲突。
图级优化是最上层的，它看的是整个计算图。常见的操作包括常量折叠、死代码消除、算子融合。举个例子，卷积后面跟一个 ReLU，图级优化会把它们合并成一个算子，减少一次内存读写。这个层面的优化通常不改变数值结果，精度无损，是最安全的。
算子级优化深入到每个算子的实现。比如矩阵乘法，你可以选择不同的分块策略、不同的指令集。这一层和硬件绑定最紧，GPU 上用 cuBLAS，CPU 上用 oneDNN，端侧用厂商提供的加速库。算子级优化做得好，性能提升非常明显，但需要针对具体硬件调优。
数据级优化就是量化、剪枝这类操作了。它直接改变模型的权重和激活值表示。INT8 量化把 FP32 的权重压到 8 位整数，模型体积直接小 4 倍，推理速度也能提升 2 到 4 倍。但代价是精度损失，需要用校准数据集来补偿。
这三层不是孤立的。实际项目里，我通常先做图级优化拿到无损收益，再做算子级优化压榨硬件性能，最后才考虑数据级优化。顺序反了的话，量化后的模型再做图优化，可能会遇到算子不支持的问题，反而麻烦。
2.3 精度与速度的平衡点怎么找
这是 Model-Optimizer 里最核心也最头疼的问题。我的经验是：不要追求极致的速度，而是找到业务能接受的精度下限，然后在这个约束下最大化速度。
具体怎么做？先确定精度基线。用原始 FP32 模型在验证集上跑一遍，记下指标。然后每做一步优化，都重新评估精度。我一般会设一个阈值，比如精度下降不超过 1%，超过就回退。这个阈值要和业务方对齐，不能自己拍脑袋。
有一个技巧是分层量化。不是所有层都对量化敏感。通常第一层和最后一层比较敏感，中间的卷积层和全连接层容忍度更高。你可以只量化中间层，首尾保持 FP16 或 FP32。这样精度损失小，速度提升也能拿到大部分。我在一个图像分类项目里用这个方法，INT8 量化后精度只掉了 0.3 个点，推理速度提升了 2.8 倍。
还有一个点是校准集的选择。量化需要校准数据来统计激活值的分布。校准集不能随便拿几张图就用，它要能代表真实推理时的数据分布。我一般会从验证集里随机抽 500 到 1000 个样本做校准，太少统计不准，太多没必要。校准集和测试集不能重叠，否则评估结果会虚高。
3. 核心细节解析与实操要点
3.1 量化：从 FP32 到 INT8 的关键步骤
量化是 Model-Optimizer 里用得最多的技术，但也是最容易出问题的。我把它拆成几个关键步骤，每一步都有坑。
第一步是确定量化方案。对称量化和非对称量化选哪个？对称量化把零点固定在 0，实现简单，适合权重；非对称量化有独立的零点和缩放因子，适合激活值，因为激活值分布通常不对称。实际项目里我一般用权重对称、激活非对称的组合，这是大多数推理框架的默认选择。
第二步是插入量化节点。以 PyTorch 为例，你需要用torch.quantization模块在模型里插入QuantStub和DeQuantStub，标记量化的起点和终点。这一步看起来简单，但位置选错了会影响精度。比如在残差连接的分支上，量化节点要放在加法之前还是之后，需要根据具体结构判断。
import torch import torch.quantization as tq class QuantizedModel(torch.nn.Module): def __init__(self, model): super().__init__() self.quant = tq.QuantStub() self.model = model self.dequant = tq.DeQuantStub() def forward(self, x): x = self.quant(x) x = self.model(x) x = self.dequant(x) return x # 配置量化方案 model.qconfig = tq.get_default_qconfig('fbgemm') tq.prepare(model, inplace=True) # 用校准集跑一遍 for data in calib_loader: model(data) tq.convert(model, inplace=True)第三步是校准。校准的目的是统计激活值的动态范围，确定缩放因子。校准集跑完后，convert会把 FP32 的权重转成 INT8。这里要注意，校准集的数量和多样性直接影响量化精度。我试过只用 100 张图校准，结果某些层的缩放因子偏得厉害，精度掉了 5 个点。后来加到 800 张，精度损失控制在 1 个点以内。
第四步是精度评估与补偿。量化后一定要在完整验证集上评估，不能只看校准集的结果。如果精度掉太多，可以考虑量化感知训练（QAT）。QAT 在训练时模拟量化误差，让模型学会适应 INT8 表示。QAT 的代价是需要重新训练，但精度通常能恢复到接近 FP32 的水平。
注意：量化后的模型不能再直接用于训练，只能推理。如果后续还要微调，需要保留 FP32 版本。
3.2 算子融合的边界条件与实操
算子融合是图级优化的核心手段，它把多个小算子合并成一个大算子，减少内核启动开销和内存访问。最常见的融合模式是 Conv + BN + ReLU，这三个算子融合后，BN 的参数会被折叠进卷积权重，ReLU 变成卷积输出后的激活函数。
但融合不是无条件的。我遇到过几种融合失败的情况，值得说一下。
第一种是分支结构。如果 Conv 的输出同时流向两个分支，一个接 BN，一个直接输出，那 BN 就不能简单折叠进卷积。因为折叠后另一个分支的输入就变了。这种情况下，优化器通常会放弃融合，或者插入额外的算子来保持语义。
第二种是动态形状。如果输入的形状在推理时是变化的，某些融合策略会失效。比如动态批处理场景下，BN 的统计量需要实时计算，不能提前折叠。这时候可以考虑用 InstanceNorm 替代，或者关闭这部分融合。
第三种是自定义算子。如果你用了自己写的 CUDA 算子，优化器可能不认识它，无法融合。解决办法是给自定义算子注册融合模式，或者手动在算子内部实现融合逻辑。
实操上，我一般用 TensorRT 或 ONNX Runtime 来做算子融合。以 ONNX Runtime 为例，你可以通过graph_optimization_level控制融合强度：
import onnxruntime as ort options = ort.SessionOptions() options.graph_optimization_level = ort.GraphOptimizationLevel.ORT_ENABLE_ALL session = ort.InferenceSession("model.onnx", options)ORT_ENABLE_ALL会开启所有可用的融合，包括 Conv+BN+ReLU、MatMul+Add 等。但有时候过度融合会导致精度问题，特别是涉及浮点累加顺序变化的场景。如果发现精度异常，可以降到ORT_ENABLE_EXTENDED或ORT_ENABLE_BASIC逐级排查。
3.3 剪枝：结构化与非结构化的选择
剪枝是另一种常用的 Model-Optimizer 手段，它通过移除模型中不重要的权重来减小模型体积和计算量。剪枝分两种：非结构化剪枝和结构化剪枝。
非结构化剪枝把单个权重置零，理论上可以压缩模型，但实际推理时，稀疏矩阵的加速需要硬件和库的支持。很多推理框架对稀疏矩阵的加速效果有限，甚至可能因为索引开销变得更慢。我早期在一个项目里用了非结构化剪枝，模型体积确实小了，但推理速度没变，白折腾。
结构化剪枝直接移除整个通道或整个层，得到的模型是稠密的，推理框架能直接加速。代价是精度损失可能更大，因为剪枝粒度粗。实际项目里，我优先考虑结构化剪枝，特别是通道剪枝。
通道剪枝的关键是重要性评估。怎么判断一个通道重不重要？常用的指标有 L1 范数、L2 范数、BN 缩放因子。我一般用 BN 缩放因子，因为 BN 的 gamma 参数在训练中会自适应调整，gamma 接近零的通道说明对输出贡献小，可以剪掉。
剪枝的流程通常是：训练一个基准模型，评估各通道的重要性，剪掉最不重要的部分，然后微调恢复精度。微调这一步不能省，剪枝后的模型精度通常会掉几个点，微调能把大部分精度找回来。
import torch.nn.utils.prune as prune # 对卷积层做 L1 非结构化剪枝，剪掉 30% prune.l1_unstructured(conv_layer, name='weight', amount=0.3) # 永久移除被剪的权重 prune.remove(conv_layer, 'weight')提示：剪枝比例不要一次设太高，建议从 10% 到 20% 开始，逐步增加，每次剪枝后都评估精度。
3.4 动态批处理与内存复用
动态批处理是服务端推理优化的重要一环。它的思路是把多个请求攒在一起，凑成一个批次送进模型，充分利用 GPU 的并行能力。但批次大小不是越大越好，显存占用和延迟都会随批次增大而增加。
我一般会做一个简单的延迟-吞吐曲线测试。固定一个延迟上限，比如 50ms，然后逐步增大批次，看吞吐量什么时候到拐点。拐点之后，吞吐增长变缓，延迟却继续上升，就不划算了。
内存复用是另一个容易被忽略的点。推理过程中，中间激活值会占用大量显存。如果每次推理都重新分配显存，开销很大。优化器可以通过内存池来复用这些空间。PyTorch 的 CUDA 缓存分配器已经做了这件事，但在多模型或多流场景下，可能需要手动配置。
import torch # 设置显存分配策略，减少碎片 torch.cuda.memory._set_allocator_settings('max_split_size_mb:128')这个设置把大块显存的分割阈值调到 128MB，减少小碎片。实测下来，在多个模型交替推理的场景下，显存碎片率能降低 30% 左右。
4. 完整实操流程与关键环节实现
4.1 环境准备与工具链搭建
动手之前，先把工具链理清楚。Model-Optimizer 涉及的工具比较多，我按功能分类列一下。
| 功能 | 常用工具 | 适用场景 |
|---|---|---|
| 图优化 | ONNX Runtime, TensorRT | 服务端 GPU/CPU |
| 量化 | PyTorch Quantization, TensorFlow Lite | 端侧、服务端 |
| 剪枝 | Torch Prune, Neural Compressor | 模型压缩 |
| 算子融合 | TensorRT, TVM | 高性能推理 |
| 端侧部署 | TFLite, NCNN, MNN | 移动端、嵌入式 |
环境搭建的第一步是确定推理框架。服务端 GPU 我首选 TensorRT，它的算子融合和量化支持最成熟。CPU 场景用 ONNX Runtime，跨平台兼容性好。端侧看芯片，高通用 SNPE，联发科用 NeuroPilot，通用方案用 NCNN 或 MNN。
第二步是准备模型。大多数优化工具接受 ONNX 格式作为输入。如果你用的是 PyTorch，可以用torch.onnx.export导出。导出时注意设置opset_version，不同版本支持的算子不一样。我一般用 opset 13 或 14，兼容性和功能比较平衡。
torch.onnx.export( model, dummy_input, "model.onnx", opset_version=13, input_names=['input'], output_names=['output'], dynamic_axes={'input': {0: 'batch_size'}} )dynamic_axes设置让批次维度可变，方便后续做动态批处理。如果不需要动态批次，可以去掉这个参数，导出的模型会更简单。
第三步是验证 ONNX 模型的正确性。导出后不要直接拿去优化，先用 ONNX Runtime 跑一遍，和原始 PyTorch 的输出对比。我遇到过导出后精度对不上的情况，原因是某些算子在不同框架里的实现有细微差异。这时候需要定位到具体算子，手动替换或调整。
4.2 从 FP32 到 INT8 的完整量化流程
下面以 ResNet-50 为例，走一遍完整的量化流程。这个流程我在多个项目里复用，效果稳定。
第一步，加载预训练模型并评估 FP32 基线。
import torch import torchvision.models as models model = models.resnet50(pretrained=True) model.eval() # 在验证集上评估 correct = 0 total = 0 with torch.no_grad(): for images, labels in val_loader: outputs = model(images) _, predicted = torch.max(outputs, 1) total += labels.size(0) correct += (predicted == labels).sum().item() print(f"FP32 精度: {100 * correct / total:.2f}%")第二步，配置量化方案并插入量化节点。
import torch.quantization as tq model.qconfig = tq.get_default_qconfig('fbgemm') model_fused = tq.fuse_modules(model, [['conv1', 'bn1', 'relu']]) model_prepared = tq.prepare(model_fused, inplace=False)fuse_modules把 Conv+BN+ReLU 融合在一起，这是量化前的标准操作。融合后 BN 的参数被折叠进卷积，减少计算量。
第三步，用校准集跑一遍，统计激活值分布。
def calibrate(model, data_loader, num_batches=10): model.eval() with torch.no_grad(): for i, (images, _) in enumerate(data_loader): if i >= num_batches: break model(images) calibrate(model_prepared, calib_loader, num_batches=10)校准批次的数量根据数据集大小调整。ImageNet 这种规模，10 个批次（每批 32 张）通常够了。小数据集可以适当增加。
第四步，转换为 INT8 模型并评估精度。
model_quantized = tq.convert(model_prepared, inplace=False) # 评估量化后精度 correct = 0 total = 0 with torch.no_grad(): for images, labels in val_loader: outputs = model_quantized(images) _, predicted = torch.max(outputs, 1) total += labels.size(0) correct += (predicted == labels).sum().item() print(f"INT8 精度: {100 * correct / total:.2f}%")ResNet-50 在这个流程下，INT8 精度通常比 FP32 低 0.5 到 1 个点。如果掉得太多，可以尝试逐层量化，把敏感层排除在外。
第五步，导出量化模型并测试推理速度。
# 导出 TorchScript scripted = torch.jit.script(model_quantized) torch.jit.save(scripted, "resnet50_int8.pt") # 测试速度 import time input_tensor = torch.randn(1, 3, 224, 224) with torch.no_grad(): # 预热 for _ in range(10): model_quantized(input_tensor) # 计时 start = time.time() for _ in range(100): model_quantized(input_tensor) elapsed = (time.time() - start) / 100 print(f"平均推理时间: {elapsed * 1000:.2f}ms")实测下来，ResNet-50 在 CPU 上 INT8 比 FP32 快 2.5 到 3 倍，GPU 上提升小一些，大概 1.5 到 2 倍，因为 GPU 本身对 FP16 支持很好，INT8 的优势没那么明显。
4.3 算子融合的实操与效果验证
算子融合的效果验证需要对比融合前后的计算图。ONNX Runtime 提供了可视化工具，可以把优化后的图导出成 DOT 格式，用 Graphviz 查看。
import onnxruntime as ort options = ort.SessionOptions() options.graph_optimization_level = ort.GraphOptimizationLevel.ORT_ENABLE_ALL options.optimized_model_filepath = "model_optimized.onnx" session = ort.InferenceSession("model.onnx", options)运行后会生成model_optimized.onnx，用 Netron 打开就能看到融合后的结构。Conv+BN+ReLU 应该变成一个单独的 Conv 节点，BN 和 ReLU 消失了。
融合的效果可以用 profiling 来量化。ONNX Runtime 支持 profiling，记录每个算子的耗时。
options.enable_profiling = True session = ort.InferenceSession("model.onnx", options) # 跑几次推理 for _ in range(10): session.run(None, {'input': input_data}) # 导出 profiling 结果 prof_file = session.end_profiling() print(f"Profiling 结果: {prof_file}")打开 profiling 文件，对比融合前后的算子数量和总耗时。我做过一个实验，一个包含 200 多个算子的模型，融合后降到 80 多个，推理时间从 45ms 降到 28ms，提升接近 40%。
注意：算子融合可能会改变浮点运算的顺序，导致微小的数值差异。如果模型对数值精度极其敏感，融合后需要重新验证。
4.4 端侧部署的量化与加速
端侧部署和服务器端差别很大。端侧芯片的算力、内存、功耗都受限，优化策略更激进。我以高通平台为例，走一遍端侧量化的流程。
第一步，用 AIMET 或 SNPE 的工具做量化。高通的 Neural Processing SDK 提供了模型转换工具，可以把 ONNX 或 TensorFlow 模型转成 DLC 格式。
# 转换 ONNX 到 DLC snpe-onnx-to-dlc --input_network model.onnx --output_path model.dlc # 量化 DLC snpe-dlc-quantize --input_dlc model.dlc --output_dlc model_quantized.dlc \ --input_list calibration_list.txtcalibration_list.txt里是校准图片的路径列表。高通工具会读取这些图片，统计激活值分布，生成量化参数。
第二步，在设备上跑量化模型，验证精度和速度。SNPE 提供了snpe-net-run工具，可以在设备上执行推理。
snpe-net-run --container model_quantized.dlc --input_list test_list.txt \ --output_dir output --use_dsp--use_dsp指定用 DSP 执行，功耗比 CPU 低，速度也更快。实测下来，ResNet-50 在高通 855 上，DSP 推理只要 15ms，CPU 要 80ms。
第三步，精度对比。端侧量化精度损失通常比服务端大，因为校准数据少，芯片的量化实现也有差异。我一般会准备 100 到 200 张测试图，对比设备输出和服务器 FP32 输出的差异。如果 Top-1 精度掉超过 2 个点，就需要调整量化策略，比如混合精度量化，把敏感层保持 FP16。
5. 常见问题与排查技巧实录
5.1 量化后精度暴跌的排查思路
量化后精度暴跌是最常见的问题。我遇到过几次，总结了一套排查流程。
先看掉多少。掉 0.5 个点以内，属于正常范围，可以接受。掉 1 到 3 个点，需要优化。掉 5 个点以上，基本是哪里出错了。
然后定位敏感层。用逐层量化的方法，每次只量化一层，看哪一层量化后精度掉得最多。PyTorch 的torch.quantization支持按模块设置 qconfig，可以把敏感层的 qconfig 设为 None，跳过量化。
# 跳过第一层和最后一层的量化 model.quant[0].qconfig = None model.fc.qconfig = None我做过一个实验，ResNet-50 的第一层卷积量化后精度掉了 2 个点，跳过它之后，整体精度损失降到 0.4 个点。第一层通常对输入数据的细节敏感，量化误差会被后续层放大。
再看校准集。校准集数量不够或分布偏差，会导致缩放因子不准。我一般会检查校准集的类别分布，确保每个类别都有足够样本。如果校准集里某个类别的样本特别少，那个类别的精度可能会明显下降。
最后看量化方案。对称量化和非对称量化的选择，per-tensor 和 per-channel 的选择，都会影响精度。权重用 per-channel 量化通常比 per-tensor 好，因为每个通道的权重分布不同，per-channel 能更精确地表示。
5.2 算子融合失败的原因与解决
算子融合失败通常有几个原因，我整理成速查表：
| 现象 | 可能原因 | 解决方法 |
|---|---|---|
| Conv+BN 未融合 | BN 处于训练模式 | 设置 model.eval() |
| ReLU 未融合 | ReLU 有多个消费者 | 检查图结构，确认是否可融合 |
| 融合后精度异常 | 浮点累加顺序变化 | 降低优化级别，逐级排查 |
| 自定义算子未融合 | 优化器不认识该算子 | 注册融合模式或手动融合 |
| 动态形状导致融合失败 | 形状在推理时变化 | 固定形状或使用动态融合策略 |
我遇到最多的是 BN 未融合，原因是模型没有切到 eval 模式。训练模式下 BN 用当前批次的统计量，无法折叠进卷积。导出 ONNX 之前一定要model.eval()，这是基本操作，但新手容易忘。
另一个坑是 ReLU 的融合。如果 ReLU 的输出被多个算子使用，优化器可能不敢融合，因为融合后其他消费者就拿不到 ReLU 之前的输出了。这种情况下，可以手动调整图结构，把 ReLU 复制一份，让每个分支独立融合。
5.3 推理速度不升反降的诡异情况
优化后速度反而变慢，这种情况我也遇到过几次。原因通常有几个。
量化开销大于收益。INT8 量化在 CPU 上收益明显，但在某些 GPU 上，量化后的算子需要额外的转换步骤，反而变慢。我试过一个模型在 V100 上量化后速度没变，在 T4 上快了 1.8 倍。所以量化前一定要在目标硬件上实测。
内存瓶颈。如果模型本身是内存密集型的，量化减少了计算量但没减少内存访问，速度提升有限。这时候需要结合算子融合和内存复用。
批次太小。INT8 量化的优势在大批次下更明显，因为并行度更高。如果批次是 1，量化后的算子可能无法充分利用硬件。我一般建议批次至少 8，最好 16 以上。
线程配置不当。CPU 推理时，线程数设置不合理会导致性能下降。ONNX Runtime 默认用所有核心，但在某些场景下，过多线程反而增加调度开销。可以手动设置线程数：
options.intra_op_num_threads = 4 options.inter_op_num_threads = 2intra_op是算子内的并行线程，inter_op是算子间的并行线程。一般设成物理核心数的一半到全部，根据实测调整。
5.4 跨平台部署的兼容性问题
跨平台部署时，兼容性是另一个大坑。同一个 ONNX 模型，在不同推理框架上的行为可能不一样。
算子支持差异。某些算子在一个框架里支持，在另一个里不支持。比如HardSwish在 ONNX Runtime 里支持，但在某些端侧框架里需要拆成多个基本算子。解决办法是导出时用opset_version控制算子集，或者手动替换不支持的算子。
数值精度差异。不同框架对浮点运算的实现有细微差异，导致输出不完全一致。如果模型对数值敏感，这种差异可能被放大。我一般会设置一个容差，比如输出差异在 1e-4 以内算通过。
输入输出格式差异。有的框架要求 NCHW，有的要求 NHWC。导出模型时要注意目标框架的要求，必要时做格式转换。
# 转换 NCHW 到 NHWC import torch x = torch.randn(1, 3, 224, 224) x_nhwc = x.permute(0, 2, 3, 1)跨平台部署前，我建议先在目标框架上跑一遍完整的验证集，确认精度和速度都达标，再上线。不要只看几个样本的结果，那样容易漏掉边界情况。
6. 一些实操心得与后续扩展方向
做了这么多项目，我最大的体会是：Model-Optimizer 没有银弹，每个模型、每个硬件、每个场景都需要单独调。但有一些通用的原则可以帮你少走弯路。
第一，先无损后有损。图级优化和算子融合通常无损，先做这些，拿到确定的收益。量化、剪枝这些有损操作放在后面，因为它们需要反复调参和验证。
第二，量化不是越激进越好。INT8 够用就不要上 INT4，精度损失和工程复杂度都会增加。我见过有人为了追求极致压缩，上了 INT4 量化，结果精度掉得没法用，最后还是回到 INT8。
第三，校准集要用心准备。校准集的质量直接决定量化精度。我一般会从真实业务数据里抽样，确保覆盖各种边界情况。如果业务数据分布会漂移，校准集也要定期更新。
第四，性能测试要在目标硬件上做。开发机上的结果只能参考，真实性能要看部署环境。我吃过亏，在开发机上测得好好的，上线后发现目标服务器的 CPU 型号不同，性能差了一大截。
后续如果还想深入，可以往几个方向扩展。一是自动化优化，用搜索算法自动找最优的量化配置和融合策略，减少人工调参。二是硬件感知优化，针对特定芯片的指令集和内存层次做定制优化。三是动态优化，根据运行时负载自动调整批次大小和量化精度，在延迟和吞吐之间动态平衡。
这些方向我还在摸索，有新的心得再分享。如果你也在做 Model-Optimizer 相关的工作，欢迎交流踩坑经验。
