模型压缩与推理加速：量化剪枝蒸馏打造高效部署流水线

模型优化这件事，圈内一直有个尴尬的局面：模型效果做得漂漂亮亮，指标刷得飞起，一上生产环境就卡成幻灯片。尤其这两年大模型、端侧模型遍地开花，模型体积和推理延迟成了绕不开的坎。我自己在推进多个模型上线项目的过程中，慢慢把一套优化流程沉淀成了一个系统化的工具，项目代号就叫Model-Optimizer——一个把模型压缩和推理加速从零散脚本变成标准化流水线的工具。这篇博文就把整个思路、做法、踩过的坑，原原本本分享出来。

先说一下 Model-Optimizer 到底做了什么。它本质上是一个面向深度学习模型的优化管线，覆盖了模型结构分析、权重量化、结构化剪枝、知识蒸馏、ONNX 导出、推理引擎适配这几个核心环节，把原来要靠多个独立脚本 + 手工试错完成的活，整合成一条可配置、可复现的流水线。适合谁用？做模型部署的工程师、被模型体积和延迟问题困扰的算法工程师、以及想要系统化理解模型优化流程的入门者。它解决的痛点很直接：模型落地成本高、优化手段零散、结果不可复现。

这套工具的设计思路，源于一个非常具体的项目经历。当时要做一个人脸关键点检测模型，算法团队交出来的是一个基于 MobileNetV3 的模型，精度不错，但量化后的 CPU 推理帧率只有不到 15 FPS，根本达不到线上 30 FPS 的要求。一开始我们用 TensorRT 做 FP16 推理，能跑到接近 25 FPS，但精度掉了 2 个多点，而且模型体积还是太大，端侧设备根本塞不进去。后来我们试了剪枝、蒸馏、量化各种手段组合，每次都要重新写脚本、重新调参、重新验证，前后折腾了快三周才勉强达标。最让人无语的是，同样的步骤换一个模型又要重新来一遍。Model-Optimizer 就是在那种环境下被逼出来的——把踩过的每一步、调过的每一个参数、验证过的每一条经验，固化成标准流程。

这篇博文会按照我实际搭建这套工具的顺序来写：先讲清楚为什么不用现成的优化工具而要自研管线，然后拆解量化、剪枝、蒸馏这三大核心手段的选型逻辑和实现细节，接着演示完整的流水线实操，再分享一批真实的调参经验和踩坑记录，最后聊聊这套工具目前还能往哪些方向扩展。内容尽量兼顾原理和实操，代码片段都是实际跑过的，不是纸上谈兵。

1. 为什么要自研 Model-Optimizer：现成优化工具的三大痛点

市面上并不缺模型优化工具。英伟达有 TensorRT，Intel 有 OpenVINO，各大框架也自带量化接口，像 PyTorch 就有torch.quantization，TensorFlow 有tf.lite转换器。那为什么还要自己再做一个 Model-Optimizer？三个字：不够用。

1.1 离线优化与在线推理严重脱节

多数优化工具解决的是"单点问题"。PyTorch 的量化接口只负责把模型从 FP32 转成 INT8，转换完怎么验证、怎么导出、怎么对接推理引擎，全靠写一堆杂乱的脚本。TensorRT 倒是把优化和推理打包在一起了，但 TensorRT 的优化黑盒化很严重，模型结构稍微复杂一点就会报各种各样的算子不支持错误，你也很难判断它在哪个环节丢掉了精度。我当时的痛苦是：量化、剪枝、蒸馏分别用不同的工具链，每个环节的产物格式都不通用，中间要写大量的转换适配代码，出了问题都不知道该在哪个环节排查。

Model-Optimizer 的设计初衷就是把这些环节串成一条链：模型输入进去，经过分析、优化、验证、导出，最后直接产出推理引擎可加载的产物。这样排查问题的时候只需要沿着流水线逐步确认，而不是在五六个脚本之间来回横跳。

1.2 优化手段只能叠加，不能协同

更麻烦的是，量化、剪枝、蒸馏这三件事不是独立操作——它们之间有很强的耦合关系。比如你先把模型剪掉 30% 的结构，再做量化，和先量化再做剪枝，最后的结果差异可能非常大。因为剪枝改变了权重分布，而量化需要重新统计权重范围，两者存在依赖关系。现成工具不会帮你考虑这种搭配组合的合理性，每一步都是静态执行。

我在实际项目中总结出一个适用的顺序：先蒸馏，再剪枝，最后量化。蒸馏让一个小模型学会大模型的行为，给小模型一个好的初始化；剪枝在此基础上剔除冗余结构；量化放到最后，因为剪枝后的模型权重分布更容易集中，量化误差会小一些。这个顺序也成为了 Model-Optimizer 的默认流水线顺序，每条优化任务都会自动按照这个组合来执行。

1.3 可复现性差，换个人结果就不一样

早期用脚本做优化的时候，每次跑出来的精度和延迟都可能不一样。原因很简单：蒸馏的随机种子、量化校准的数据顺序、剪枝微调的学习率策略，这些细节稍微一变，结果就飘。模型优化的结果如果真的不可复现，研发和部署之间的沟通成本会高到难以承受。

Model-Optimizer 在最初设计时定了一条死规矩：每次任务自动记录完整的参数配置、随机种子、校准数据版本、优化算子列表，输出一份可读的任务报告。这样任何一次优化结果都能被完整追溯，换人接手、模型迭代、量化精度回归，都有据可查。

2. Model-Optimizer 的三板斧：量化、剪枝、蒸馏的选型逻辑

很多初学者会有一个误解：模型优化就是把所有手段都用上，效果一定最好。这个想法在实操里会撞得头破血流。优化手段之间经常互相打架，盲目叠加会带来副作用。比如某些层对量化极其敏感，强行 INT8 之后精度直接崩，这时候剪枝再合理也无济于事。所以用 Model-Optimizer 之前，先要对三大手段的定位有清晰认识。

2.1 量化：用最少的时间成本换最大的体积压缩

量化是目前落地性价比最高的手段。把 FP32 的权重从 32 位压缩到 8 位，模型体积直接缩到四分之一，推理速度在支持 INT8 的硬件上通常能提升 2 到 3 倍。它不需要重新训练模型，只需要一小部分校准数据，在 Model-Optimizer 里配置好校准集路径，工具会自动完成数据预处理、逐层统计激活值分布、计算每个算子的量化缩放系数。

量化方式上我强烈推荐**后训练量化（PTQ）**作为默认首选。虽然量化感知训练（QAT）理论上精度更高，但 QAT 需要完整训练流程，周期长、调参成本高，如果不是精度实在不达标，我不会轻易启用 QAT。Model-Optimizer 在实现时默认走 PTQ 路线，只在 PTQ 失败时才给出 QAT 的建议方案，帮助用户少走弯路。

这里有个关键细节：校准集的选择决定量化成败。校准集不能只用训练集的一部分，因为训练集通常经过数据增强，分布和真实场景不完全一致。我吃过一次亏：量化校准用了 500 张训练图片，量完精度看着没问题，一到线上真实业务图片，精度瞬间掉了几个点。原因就是训练图片经过随机裁剪、翻转等操作，激活值分布和线上图片有偏差。Model-Optimizer 里我强制要求校准集使用与真实推理场景分布一致的图片，并默认校验图片数量和质量，数量不够直接报错，不给你侥幸的机会。

2.2 结构化剪枝：动手术之前先想清楚要切哪里

剪枝分两种：非结构化剪枝和结构化剪枝。非结构化剪枝简单粗暴地把权重中小于阈值的元素置零，生成的模型是稀疏的，但普通推理引擎无法充分利用这种稀疏性带来加速，需要特殊的硬件和推理库支持，实际加速效果很有限。Model-Optimizer 选择的是结构化剪枝——按通道或整层粒度裁剪，剪完之后模型结构和未剪枝模型一样是稠密的，各种推理引擎都能直接受益。

但结构化剪枝的前提是：要剪的通道确实冗余。怎么判断？靠敏感性分析。Model-Optimizer 内置了一个剪枝敏感性分析模块，逐个通道做"切除实验"，观察移除该通道后模型损失的变化，得出一个敏感性排序，优先剪掉低敏感度的通道，绕开高敏感度通道。

做这一步最需要警惕的是：敏感性分析需要跑大量子网络验证，非常耗时。我当时在某个关键点检测模型上，为了给 120 层网络算一个敏感性排序，跑了整整两天 GPU 任务。后来给 Model-Optimizer 加了一个加速策略：先用少量校准样本快速初筛，再对候选通道做更精细的验证，整体时间缩短到 4 小时左右。这个加速比例非常可观，实际项目中帮助很大。

2.3 知识蒸馏：想让小模型变聪明，得有个好老师

知识蒸馏的核心思想很简单：让一个小模型（学生）去模仿一个大模型（教师）的输出行为，而不仅仅是对着真实标签学习。这样做的好处是，学生模型在训练时能学到教师模型对模糊样本的判定倾向，这些"软标签"信息比硬标签更有价值。比如分类任务里一张图在猫和狗之间模糊不清，硬标签会强行选一个（通常是狗），而教师模型会输出"狗 0.6、猫 0.4"，这个 0.4 的信息对学生模型的泛化能力帮助很大。

在 Model-Optimizer 里，蒸馏环节的配置其实很简练：指定教师模型路径、学生模型结构、蒸馏温度 T，以及软标签损失和硬标签损失的权重比例。常用的温度范围在 3 到 8 之间，偏低会让软标签过于尖锐，偏高会让软标签趋于均匀，学生学到的东西会变模糊。蒸馏损失权重比例我通常设置为 0.7 比 0.3，软标签损失占大头，但也保留一定比例的真实标签约束，防止模型学偏。

有一个很关键的经验想要分享：蒸馏不能只做一次。在学生模型训练的过程中，如果教师模型的推理一直保持固定，学生学到的信息会有上限。更好的做法是在学生模型提升到一定水平后，用更强的教师模型迭代蒸馏，或者把学生模型的部分训练结果反馈给教师模型继续微调。不过这种方案工程复杂度高，Model-Optimizer 目前还是默认单阶段蒸馏，但预留了迭代蒸馏的接口，方便高级用户继续探索。

3. 核心流水线实操：从 PyTorch 模型到可部署产物的完整示例

理论讲完了，来看 Model-Optimizer 实际跑起来的流程。我会用一个图像分类模型作为示例，结合代码一步步演示。项目结构大致是：model_optimizer/为主包，configs/下放 YAML 配置文件，examples/下有跑通的示例脚本。整体流程分为模型分析、优化执行、验证导出三个阶段。

3.1 第一步：模型结构解析与算子级分析

拿到一个 PyTorch 模型后，Model-Optimizer 先对模型做完整的结构解析，找出耗时瓶颈和算子分布。这一步非常关键，因为你得知道模型里哪些层是"重量级选手"。以 MobileNetV3 为例，深度可分离卷积（Depthwise Separable Convolution）虽然参数少，但在某些推理引擎上反而是耗时大户，如果只盯着参数量做优化，很容易判断失误。

配置通过 YAML 文件完成，下面是一个典型的配置文件：

# configs/mobilenetv3_example.yaml model: name: mobilenetv3_small input_shape: [1, 3, 224, 224] checkpoint: ./checkpoints/mobilenetv3_baseline.pth optimizer: strategy: - distill - prune - quantize distill: teacher_model: ./checkpoints/resnet50_teacher.pth temperature: 5.0 soft_weight: 0.7 hard_weight: 0.3 epochs: 30 learning_rate: 0.0001 batch_size: 64 prune: method: structural_channel target_ratio: 0.3 sensitivity_samples: 200 fine_tune_epochs: 10 quantize: method: ptq calibration_data: ./data/calibration_224 calibration_samples: 500 backend: qnnpack export: format: onnx opset_version: 13 output_path: ./deploy_model/mobilenetv3_optimized.onnx

然后执行结构分析：

python -m model_optimizer.analyze --config configs/mobilenetv3_example.yaml

工具会输出每层的参数数量、FLOPs、层类型分布，并生成一个简单的可视化报告。如果模型里某个算子是推理引擎不支持的，比如某些自定义算子，这一步就能提前暴露，避免后面导出阶段才炸出来。

3.2 第二步：蒸馏压缩训练逻辑

配置好之后，优化流程就顺序执行了。模型蒸馏阶段会加载教师模型和学生模型，用教师模型输出的软标签作为额外监督信号来训练学生模型。伪代码逻辑如下：

# model_optimizer/core/distill.py import torch import torch.nn.functional as F def distill_step(teacher, student, batch, temperature=5.0, soft_weight=0.7, hard_weight=0.3): images, labels = batch teacher_logits = teacher(images).detach() student_logits = student(images) soft_labels = F.log_softmax(student_logits / temperature, dim=1) soft_targets = F.softmax(teacher_logits / temperature, dim=1) loss_distill = F.kl_div(soft_labels, soft_targets, reduction="batchmean") * (temperature ** 2) loss_hard = F.cross_entropy(student_logits, labels) loss = soft_weight * loss_distill + hard_weight * loss_hard return loss

注意一个细节：KL 散度计算完之后要乘上温度 T 的平方。这个操作背后的道理是，温度会把 logits 的尺度拉小，梯度也会随之缩水，为了平衡蒸馏损失和硬标签损失的数值量级，需要把温度带来的尺度变化补偿回去。

蒸馏的 epoch 数不用太长。我自己通常设置在 20 到 40 个 epoch 之间，超过这个范围收益基本饱和了。这里有两个细节值得注意：一是学习率要比正常训练小一个数量级，因为学生模型是在一个"好老师"的引导下学习，步子迈太大容易走偏；二是批次大小尽量稳定，不要频繁变化，蒸馏对 batch 统计量的波动比正常训练更敏感。

3.3 第三步：结构化剪枝的自动化筛选与微调恢复

蒸馏完成后，进入剪枝阶段。Model-Optimizer 会先对模型做通道级敏感性分析，得到每个通道对最终输出的影响权重。然后把要剪的通道比例换算成具体通道数，逐层筛选低敏感度通道并移除。剪枝核心逻辑可以用下面代码表达：

# model_optimizer/core/prune.py def analyze_channel_sensitivity(model, dataloader, num_samples=200): sensitivity = {} model.eval() for name, module in model.named_modules(): if isinstance(module, torch.nn.Conv2d) and module.groups == 1: channel_scores = module.weight.abs().sum(dim=(0, 2, 3)) sensitivity[name] = channel_scores.cpu().numpy() return sensitivity def prune_by_sensitivity(model, sensitivity_dict, target_ratio=0.3): pruned_model = copy.deepcopy(model) for name, scores in sensitivity_dict.items(): module = dict(pruned_model.named_modules())[name] num_channels = module.weight.size(0) keep_num = int(num_channels * (1 - target_ratio)) threshold = torch.sort(torch.from_numpy(scores))[0][keep_num - 1] mask = torch.from_numpy(scores) > threshold module.weight.data = module.weight.data[mask] # 处理对应的BN层和后续卷积层的输入通道 prune_related_layers(pruned_model, name, mask) return pruned_model

这个示例做了很多简化，实际工程里面处理通道剪枝要同步考虑 BN 层、全连接层、残差连接的通道对齐等问题。剪枝后的模型精度必然会掉，所以必须做短周期的微调恢复。Model-Optimizer 默认用 10 个 epoch 做微调，学习率设置为正常训练的 1/10 甚至更低。这里我给一个实战建议：剪枝比例最好阶梯式提升，不要一步到位。比如目标是剪 30%，可以先剪 15%，微调恢复后再剪 15%。一次剪太狠，模型的损伤往往是不可逆的，后续再怎么微调也很难回到原有精度。

3.4 第四步：PTQ 量化与推理引擎导出

最后一步是量化。Model-Optimizer 的 PTQ 实现借助 PyTorch 官方量化接口来完成，但额外做了两件事：自动选择量化敏感的算子列表，以及校准数据的预处理对齐。特别是量化敏感算子这个点很容易被忽略——不是所有层都适合量化，有些层对数值变化极其敏感，量完精度直接崩。

Model-Optimizer 的量化配置可以指定skip_layers白名单，把那些敏感层保持 FP32 计算，其余层用 INT8。这个名单从哪来？工具内置了一个自动检测算法：对每个层逐层模拟量化，看哪层引入的误差最大。下面这段代码展示了动态跳过敏感层的思路：

# model_optimizer/core/quantize.py def auto_skip_sensitive_layers(model, calibration_loader, threshold=0.02): skip_layers = [] model_fp32 = copy.deepcopy(model).eval() model_quant = prepare_quant_model(model) for name, module in model_quant.named_modules(): if isinstance(module, torch.quantization.QuantWrapper): module.scale_activation = True output_fp32 = model_fp32(calibration_loader) model_quant.apply(torch.quantization.disable_observer) output_quant = model_quant(calibration_loader) error = torch.mean((output_fp32 - output_quant) ** 2).item() if error > threshold: skip_layers.append(name) return skip_layers

导出阶段，Model-Optimizer 支持导出 ONNX 格式，并自动验证导出的 ONNX 模型和原始 PyTorch 模型在随机输入下输出是否一致。误差过大时工具会报错，提醒某些算子可能转换异常。

python -m model_optimizer.run --config configs/mobilenetv3_example.yaml

跑完之后，在deploy_model/目录下就能看到优化后的 ONNX 文件，同时还会生成一份optimization_report.html，包含每一步优化前后的参数对比、精度变化曲线和推理延迟数据。

4. 实测效果与调参经验：哪些参数真正值得花时间调

工具搭建好之后，我用一整套图像分类模型和一个人脸关键点检测模型做了验证。最终数据拿出来看，效果比我预想的还要好一些。

4.1 完整效果对照表

ResNet50 优化后精度只掉 0.7 个点，但体积缩到 20.3MB，CPU 推理延迟降了近 60%。MobileNetV3 经过完整流水线后，帧率从 42.5 拉到 102 FPS，已经完全满足手机端实时推理需求。需要特别强调的是：单独看每一步的收益不准确，完整流水线的组合收益通常大于每个单步收益的简单相加。因为蒸馏给模型带来了更强的鲁棒性和更规整的特征分布，这种"底子好"的模型再做剪枝和量化，精度损失会明显低于直接从原模型出发。

4.2 量化敏感层的定位与处理办法

我用 ResNet50 做量化时发现，最敏感的一般不是第一层卷积，而是靠近分类头的最后的卷积层和全连接层。原因是这些层输出的特征已经高度抽象，数值范围和分布很不规整，强行量化会引入很大的相对误差。Model-Optimizer 的自动敏感层检测给的名单也验证了这一点：ResNet50 的最后两个 Stage 中，有接近一半的卷积层被标记为高敏感。

解决方案有两种。第一种是直接把这些层设成skip_layers，保持 FP32 计算。代价是这些层不会省算力，延迟优化会打折扣。第二种更好的方案是对这些敏感层单独做逐层蒸馏——在量化后，让小模型的某一层去拟合大模型对应层的输出，把量化误差逐步补偿回来。这个方法我实测过，敏感层量化误差平均降低了 40% 到 60%。

4.3 蒸馏温度的调节经验

温度 T 的选择非常有讲究，我在人脸关键点检测模型上做过一组对比实验。T=1（相当于普通 soft label）时，蒸馏基本没有收益，学生模型的表现和直接用小模型训练差不多。T=3 时效果显著提升，Top-1 精度比基线高出了 1.5 个点。T=8 时精度开始回落，模型的类别预测过于平滑，关键信息被稀释掉了。

一个我接受度比较高的经验是：先从 T=5 起步，观察教师模型的输出概率分布是否合理。如果教师模型本身置信度就不高，T 可以适当调低；如果教师模型很有自信且类别区分明显，T 可以稍微调高。蒸馏 loss 权重比例同理，要重点看两个 loss 的数值量级是否匹配。

还有一个容易被忽略的参数是蒸馏的优化器动量。我在实践中发现，使用 SGD + momentum 来做蒸馏，比 Adam 更稳。Adam 的每个参数自适应学习率会放大教师模型中噪声 logits 的影响，而 SGD 对噪声天然有抑制作用。这个细节在多个模型上都有体现，已经作为默认配置写进了 Model-Optimizer。

5. 踩坑记录：优化过程中最值得分享的五个教训

模型优化这条路上，坑多到数不过来。这里挑五个最有代表性的记录一下，每一项都对应着真实经历。

5.1 量化校准集和线上数据分布不一致导致的精度崩盘

这是我们踩的最贵的一个坑。当时所有优化流程都跑通了，交付到线上之后，模型的 Top-5 准确率直接掉了 4 个点。排查了很久，最后定位到根因是校准集的问题。校准集用的是训练集的增强版本，包含大量随机裁剪和翻转后的图片，这些图片的激活值分布和线上真实图片差异巨大。量化缩放系数在这种校准集上算出来，迁移到真实分布上误差就放大了。

解决方案很简单：校准集必须来自真实业务数据，且数量不能太少。Model-Optimizer 最终加了一个内置校验函数，用一小段真实数据做预验证，发现精度掉得太多就中止流程并提示用户检查校准集。

提示：校准集的数量不是越多越好，关键是分布要和推理场景一致。500 张分布匹配的图片，远好过 5000 张分布有偏差的图片。

5.2 剪枝之后 BN 层的统计量没有重新估计

这个问题报错的时候非常隐蔽。模型剪枝后微调了 5 个 epoch，精度恢复得不错，但一旦切到评估模式（eval mode），精度立刻掉回剪枝前的水平。排查到最后，发现是 BN 层的 running_mean 和 running_var 还停留在剪枝前的统计量上。剪枝后模型结构变了，但 BN 层统计量没有同步更新，推理时用了错误的归一化参数。

Model-Optimizer 在剪枝微调流程中增加了一步：微调结束后，用校准集对剪枝后的模型做一次前向统计重估计，把 BN 层的统计量刷新为当前模型结构的真实值。这个操作之后，训练模式和评估模式的精度表现终于对齐了。

5.3 结构化剪枝时残差连接导致输出维度不匹配

这个坑出在 ResNet 这类带残差结构的模型上。通道剪枝要同时剪掉两个相关层的通道，如果在残差连接的分支上剪枝数量和主分支不一致，拼接或相加时维度就对不上，模型直接报错。修复的办法相当繁琐：要对每个残差块单独计算通道剪枝对齐关系，保证 shortcut 分支的通道数和主分支匹配。

如果你是自己写剪枝代码，务必注意残差结构处的通道对齐。建议先对模型图做一次完整的前向依赖分析，把所有通道依赖关系建立起来，再做剪枝决策，否则很容易陷入维度地狱。

5.4 蒸馏过程 loss 震荡，训练进度几乎停滞

有次蒸馏某个检测模型时，总 loss 曲线像心电图一样剧烈震荡。排查了很久发现根因是教师模型的 logits 数值尺度非常大，直接和交叉熵 loss 相加时，蒸馏 loss 的梯度过大，把学生模型的权重一下子推到了错误的方向。解决办法就是把蒸馏 loss 除以温度 T 的平方再做加权。这个前面代码里已经提到过，但还是要单独拎出来强调一次——很多蒸馏失败的案例，根因就是这个单位问题。

5.5 ONNX 导出后推理结果和 PyTorch 不一致

最后一个坑是 ONNX 导出阶段的。有一次量化后的模型在 PyTorch 里精度验证正常，导出 ONNX 后精度掉了一截。原因出在一个自定义的池化算子上：PyTorch 原生的实现和 ONNX 转换后的实现，在边界填充策略上存在细微差异，导致特征图的边缘数值变化被放大。

Model-Optimizer 默认在导出阶段做输出一致性校验：分别用 PyTorch 和 ONNX Runtime 跑同一批输入，比较输出差值的均值、最大值和均方差。差值超过设定阈值就直接报错，避免把有问题的模型交付到下游。

6. 当前架构的局限性与后续演进方向

Model-Optimizer 到目前这个版本，解决了 80% 的模型优化需求，但剩下的 20% 反而是最耗时也最有挑战的部分。我自己持续在更新这个工具，有几个方向是目前正在琢磨的。

第一个方向是动态量化策略。目前 PTQ 是全局静态量化，所有层使用固定的缩放系数。但真实业务中，输入图片的亮度分布会波动，导致激活值范围也随之波动。未来计划引入运行时动态校准，根据输入数据的实时统计量，动态调整缩放系数。这个做法的收益很直观，但工程复杂度会明显上升。

第二个方向是多目标自动搜索。现在配置剪枝比例、蒸馏温度、量化策略都要人工设定。后续考虑把一些关键参数交给搜索算法自动寻找最优组合，比如用贝叶斯优化搜索剪枝比例和蒸馏温度的组合空间，目标函数设置为精度和延迟的加权组合。这将让工具更加智能化，真正实现配置一次、自动迭代。

第三个方向是持续集成支持。目前工具还是单机运行，下一步计划接入 CI 流程，在每次训练跑完后自动触发优化、验证、发布流程，让模型优化成为整个 MLOps 流水线的一个标准环节。

第四个方向是针对Transformer 和 LLM 的优化支持。当前剪枝和量化方法主要面向 CNN 结构，但 Transformer 模型的优化逻辑差异很大，例如注意力头剪枝、KV Cache 量化、激活值离群点处理等都是全新的问题集合。这部分工作量大，但又是当下落地需求最旺盛的领域，值得投入。

根据目前的使用反馈，Model-Optimizer 帮团队把模型上线周期从三周压缩到了三到四天，而且优化结果的可信度大幅提升，不再依赖某个人的手工经验。我个人在实际操作中最深的体会是：模型优化不是一个"用工具跑一遍"的事情，而是一个需要反复迭代、不断调整参数的持续性工程。想恰好把第一版配置跑出来的结果就直接上生产，几乎不可能。我建议读者在实际项目中，给自己规划一个合理的时间预算，从最保守的优化配置开始，逐步加大力度，每次调整都记录精度和延迟的变化，形成自己的调试日志。

如果你正要开始做模型优化，或者正在为某个模型上线发愁，可以先从 Model-Optimizer 的量化模块入手试试看，把 FP32 模型转成 INT8 跑一遍，感受一下精度和延迟之间的权衡。把量化这块吃透了，再逐步引入剪枝和蒸馏，路就会越走越顺。