企业官网建设流程全解析

1. 模型优化器到底在优化什么

第一次接触 Model-Optimizer 这个概念，很多人会把它和优化算法（Optimizer，比如 SGD、AdamW）搞混。这两个东西名字像，但完全不是一个层面的东西。优化算法是训练时用来更新梯度的，而 Model-Optimizer 是一整套围绕“让模型跑得更小、更快、更省”的工具链和方法论。它处理的是模型训练完成之后、部署上线之前的那段工作——量化、剪枝、蒸馏、算子融合、图优化，这些都属于它的范畴。

我最初接触这块是因为一个很现实的问题：一个 7B 参数量的模型，FP16 精度下光权重就要占 14GB 显存，推理时加上 KV Cache 和中间激活值，一张 24GB 的卡跑起来都紧巴巴的。业务方还要求延迟控制在 200ms 以内，这就逼着你必须做优化。Model-Optimizer 解决的正是这类问题——在不显著损失精度的前提下，把模型的资源占用压下来。

这篇文章适合几类人看：一是做模型部署的工程师，手里有训练好的模型但不知道怎么压缩；二是算法工程师，想了解量化、剪枝这些技术到底怎么落地；三是对推理性能有要求的开发者，比如要做端侧部署或者高并发服务。不管你是刚接触还是已经踩过一些坑，下面这些内容应该都能对上你的实际场景。

2. 整体优化思路与方案选型

2.1 先搞清楚瓶颈在哪，再动手优化

很多人一上来就问“量化怎么做”“剪枝用什么工具”，但我觉得第一步应该是定位瓶颈。模型推理慢，可能是计算密集（compute-bound），也可能是访存密集（memory-bound）。这两种情况的优化策略完全不同。

判断方法很简单：算一下模型的算术强度（Arithmetic Intensity），也就是每读取一个字节能完成多少次浮点运算。如果算术强度低，说明瓶颈在访存，这时候量化（减少数据位宽）效果最明显；如果算术强度高，说明瓶颈在计算，那就要考虑算子融合、剪枝或者换更高效的注意力实现。

我一般会先用 profiling 工具跑一遍，看时间花在哪里。PyTorch 的torch.profiler就够用了，能看到每个算子的耗时占比。如果发现大部分时间花在矩阵乘法上，那量化是首选；如果花在 LayerNorm、激活函数这些逐元素操作上，那算子融合收益更大。

2.2 量化、剪枝、蒸馏，到底选哪个

这三条路线各有适用场景，我整理了一个对比表：

实际项目中，这三者往往组合使用。比如先剪枝再量化，或者用蒸馏训练一个小模型再做量化部署。但组合的顺序有讲究——一般先做结构层面的优化（剪枝、蒸馏），再做数值层面的优化（量化），因为量化后的模型很难再做结构修改。

2.3 为什么量化是最优先考虑的方案

在大多数部署场景下，量化是性价比最高的选择。原因有几个：第一，它不需要重新训练，post-training quantization（PTQ）几十分钟就能搞定；第二，主流推理框架对量化支持都很好，TensorRT、ONNX Runtime、OpenVINO 都有成熟的量化工具链；第三，压缩效果立竿见影，FP16 转 INT8 直接省一半显存，延迟通常能降 30%-50%。

但量化也不是万能的。如果模型本身对数值精度很敏感（比如一些生成任务），PTQ 之后精度掉得厉害，那就得考虑量化感知训练（QAT），代价是要重新训练。另外，INT8 量化对硬件有要求，不是所有设备都支持 INT8 加速指令。

3. 量化实操：从 FP16 到 INT8 的完整流程

3.1 量化前的准备工作

动手之前，有几件事必须先做。第一，确认推理框架支持哪些量化格式。TensorRT 支持 FP16、INT8、INT4（部分），ONNX Runtime 支持动态量化和静态量化，不同框架的量化策略不一样。第二，准备好校准数据集（calibration dataset）。PTQ 需要一批代表性数据来统计激活值的分布范围，这个数据集不需要标签，但必须能代表真实输入分布，一般 100-500 个样本就够了。

第三，建立一个精度评估基线。量化之前先跑一遍原始模型的精度指标，量化之后再跑一遍，对比差异。评估指标要选和业务相关的，比如分类任务看 Top-1/Top-5 准确率，生成任务看 BLEU、ROUGE 或者人工评估。我见过有人只看 loss 就判断量化是否成功，结果上线后发现生成质量明显下降，这就是评估指标没选对。

3.2 动态量化与静态量化的选择

ONNX Runtime 把量化分成动态和静态两种。动态量化只量化权重，激活值在推理时动态计算量化参数，不需要校准数据，实现简单，适合 LSTM、Transformer 这类模型。静态量化权重和激活都量化，需要校准数据，但推理速度更快，适合 CNN 类模型。

我的经验是：Transformer 类模型优先试动态量化，因为激活值分布随输入变化大，静态量化容易掉精度；CNN 类模型用静态量化，校准数据能很好地覆盖激活分布，加速效果更明显。

代码层面，ONNX Runtime 的动态量化很简单：

from onnxruntime.quantization import quantize_dynamic, QuantType quantize_dynamic( model_input="model_fp32.onnx", model_output="model_int8.onnx", weight_type=QuantType.QInt8 )

静态量化稍微复杂一点，需要配置校准数据读取器：

from onnxruntime.quantization import quantize_static, CalibrationDataReader class DataReader(CalibrationDataReader): def __init__(self, calibration_data): self.data = calibration_data self.iter = iter(self.data) def get_next(self): return next(self.iter, None) quantize_static( model_input="model_fp32.onnx", model_output="model_int8.onnx", calibration_data_reader=DataReader(calib_data), quant_format=QuantFormat.QDQ )

3.3 校准数据集的设计要点

校准数据集的质量直接决定量化精度。我踩过的坑是：随便拿了几十条数据做校准，结果量化后模型在某些输入上输出完全乱掉。后来分析发现，那几十条数据分布太集中，没有覆盖到边界情况。

正确的做法是：校准数据要从真实业务数据里采样，覆盖各种输入长度、各种类别、各种边界情况。数量上 100-500 条通常够用，但更重要的是多样性。如果业务输入有长文本也有短文本，校准集里都要有；如果有多语言场景，每种语言都要覆盖。

另外，校准数据的预处理必须和推理时完全一致。我遇到过有人校准用了一套 tokenizer，推理用另一套，结果量化参数完全对不上，精度崩得一塌糊涂。

3.4 量化精度损失的排查思路

量化后精度掉了，怎么排查？我一般按这个顺序来：

第一，看是哪些层出了问题。逐层对比量化前后的输出，找到误差最大的层。ONNX Runtime 提供了quantize_static的 debug 模式，可以输出每层的量化误差。

第二，检查这些层是否适合量化。有些层对精度特别敏感，比如 softmax 之前的最后一层、LayerNorm 的输入，这些层可以考虑跳过量化，保持 FP16。

第三，调整量化粒度。Per-tensor 量化改成 per-channel 量化，精度通常会好一些，但推理速度会略慢。如果 per-channel 还不够，可以考虑混合精度量化，敏感层用 FP16，其他层用 INT8。

第四，如果 PTQ 怎么调都不行，那就上 QAT。QAT 在训练时模拟量化误差，让模型学会适应低精度，精度通常能恢复到接近原始水平。

4. 剪枝与蒸馏的落地细节

4.1 结构化剪枝 vs 非结构化剪枝

剪枝分两种：非结构化剪枝是把单个权重置零，结构化剪枝是直接去掉整个通道、注意力头或者层。非结构化剪枝压缩率高，但需要专门的稀疏计算库才能加速，通用硬件上收益有限。结构化剪枝压缩率低一些，但直接减少计算量，通用硬件上就能加速。

实际部署中，我优先选结构化剪枝。比如剪掉 Transformer 的某些注意力头，或者减少 FFN 的中间维度。这些操作直接改变模型结构，推理时不需要特殊支持。

剪枝的流程一般是：训练一个稠密模型 → 评估每个结构单元的重要性 → 按重要性排序 → 剪掉最不重要的部分 → 微调恢复精度。重要性评估可以用权重范数、梯度信息或者专门的剪枝算法（比如 Movement Pruning）。

4.2 蒸馏的温度参数怎么调

知识蒸馏的核心是让学生模型学习教师模型的软标签（soft label）。温度参数 T 控制软标签的平滑程度：T 越大，软标签越平滑，学生能学到更多类间关系；T 越小，软标签越接近硬标签，学生主要学分类边界。

我的经验是：T 一般设在 2-10 之间。分类任务 T=3-5 比较常见，生成任务 T 可以大一些。另外，蒸馏损失和原始任务损失的权重比也要调，通常蒸馏损失占 0.5-0.9。如果学生模型和教师模型差距大，蒸馏损失权重要高一些；如果差距小，可以适当降低。

蒸馏的一个常见误区是：只蒸馏最后一层的输出。实际上，中间层的特征也可以蒸馏，让学生模型学习教师模型的中间表示。这种方法叫 hint learning，对小模型特别有效。

4.3 剪枝和蒸馏的组合策略

如果单独剪枝或蒸馏效果不够，可以组合使用。我试过的一个方案是：先用蒸馏训练一个中等大小的学生模型，再对这个学生模型做结构化剪枝，最后微调。这样比直接在原模型上剪枝效果更好，因为学生模型本身已经学得比较紧凑了。

组合的顺序很重要。先蒸馏后剪枝，学生模型有更多冗余可以被剪；先剪枝后蒸馏，剪枝后的模型可能已经损失了一些信息，蒸馏恢复起来更困难。当然，具体效果还是要看任务和模型，建议两种顺序都试一下。

5. 推理引擎与算子融合的配合

5.1 TensorRT 的优化流程

TensorRT 是目前 NVIDIA 平台上最成熟的推理优化引擎。它的优化流程大致是：解析模型 → 层融合 → 精度校准（如果做 INT8）→ 内核自动调优 → 生成引擎。

层融合是 TensorRT 的核心优化之一。比如 Conv + BN + ReLU 会被融合成一个算子，减少内存访问和内核启动开销。Transformer 里的 Multi-Head Attention 也可以被融合成一个大算子。这些融合在量化之后做效果更好，因为量化后的算子更简单，融合规则更容易匹配。

用 TensorRT 做 INT8 量化时，需要提供校准缓存（calibration cache）。第一次校准比较慢，但缓存可以保存下来，后续构建引擎直接复用。

5.2 ONNX Runtime 的图优化

ONNX Runtime 的图优化分三个级别：基础优化、扩展优化、布局优化。基础优化包括常量折叠、冗余节点消除；扩展优化包括算子融合、矩阵乘法优化；布局优化主要针对特定硬件做数据布局转换。

我一般会开启所有级别的优化，然后对比优化前后的性能。有时候某些优化反而会拖慢速度，比如在 CPU 上做布局转换可能得不偿失。这时候可以通过graph_optimization_level参数控制优化级别。

ONNX Runtime 还支持执行提供器（Execution Provider）切换，CPU 上用 OpenMP，GPU 上用 CUDA 或 TensorRT。同一个模型可以在不同硬件上跑，只需要切换 EP。

5.3 算子融合的注意事项

算子融合虽然能加速，但也有一些坑。第一，融合后的算子可能对输入形状有要求，动态形状的模型融合效果会打折扣。第二，融合可能改变数值精度，特别是涉及归约操作的融合（比如 LayerNorm），融合后精度可能有细微变化。第三，不是所有融合都能加速，有些融合在小 batch 下反而更慢。

我的做法是：融合前后都跑一遍 benchmark，用数据说话。如果融合后延迟没降反升，那就关掉对应的融合规则。

6. 常见问题与排查技巧实录

6.1 量化后精度暴跌怎么办

这是最常见的问题。排查步骤：

• 检查校准数据是否覆盖了真实输入分布，数量是否足够
• 逐层对比量化前后输出，定位误差最大的层
• 尝试 per-channel 量化替代 per-tensor 量化
• 对敏感层跳过量化，保持 FP16
• 如果以上都不行，改用 QAT

我遇到过一个案例：量化后模型在短文本上正常，长文本上输出乱码。后来发现是校准数据全是短文本，长文本的激活值分布完全没覆盖到。补充长文本校准数据后问题解决。

6.2 剪枝后模型不收敛

剪枝后微调不收敛，通常是剪得太狠了。可以逐步剪枝：先剪 10%，微调恢复；再剪 10%，再微调。这样比一次性剪 50% 效果好得多。

另外，剪枝后的学习率要调小。剪枝已经破坏了模型的一部分结构，大学习率会让模型震荡。我一般用原始学习率的 1/10 到 1/100。

6.3 推理速度没有明显提升

量化或剪枝后速度没提升，可能的原因：

• 硬件不支持低精度加速，比如某些 CPU 不支持 INT8 指令
• 瓶颈不在计算而在访存，量化减少的是计算量，访存没减少
• 算子融合没生效，或者融合后反而更慢
• batch size 太小，GPU 利用率不足

排查方法：用 profiling 工具看时间花在哪里，对比优化前后的算子耗时。

6.4 常见问题速查表

7. 一些实操心得

做模型优化这几年，最大的体会是：没有银弹。量化、剪枝、蒸馏各有各的适用场景，关键是要先搞清楚瓶颈在哪，再选对应的手段。我见过太多人一上来就量化，结果模型本身是访存瓶颈，量化后速度没变，精度还掉了。

另一个体会是：评估指标一定要和业务对齐。离线指标好看不代表线上效果好。我一般会在优化后做 A/B 测试，用真实业务指标验证。有时候离线精度只掉了 0.5%，但线上转化率掉了 2%，这种优化就是失败的。

最后分享一个小技巧：优化过程中一定要保留中间产物。量化前的 FP16 模型、校准缓存、剪枝后的 checkpoint，这些都要存好。一旦优化后效果不达标，可以快速回滚到上一个版本，不用从头再来。我吃过这个亏，一次量化失败后想回滚，发现原始模型被覆盖了，只能重新训练，白白浪费了两天。