企业官网建设流程全解析

1. 我为什么非要自己折腾一个Model-Optimizer

先说个真实场景。上个月我把一个训练好的BERT模型往生产环境推，推理延迟压不下来，GPU显存还动不动就爆。当时团队里有人提议直接上现成的推理引擎，但换引擎不是改个配置文件那么简单，算子兼容性、精度对齐、前后处理衔接全是坑。折腾了三天，效果还是有差距，尤其是量化之后F1掉了两个点，业务方直接不干了。

后来我静下心梳理了一遍，发现问题的关键不在“换个引擎”，而在缺一个能够统一管理"剪枝->量化->蒸馏->部署适配"这条链路的工具层。市面上每个环节都有独立方案，但串起来用的时候，接口风格、精度指标、回退策略全都不一样，稍不留神就跑偏。于是我把之前几个项目里沉淀的脚本和配置整理成了一个内部工具，也就是我现在说的Model-Optimizer。它不是什么火箭科技，核心目标就一句话：把模型从训练态平稳地搬到生产态，尽量少掉点精度、尽量多省点资源。

这篇文章不打算讲那种"安装即用"的卖课式教程，而是从原理到实操，把这个工具的四大核心组件——模型压缩、精度校准、推理加速与内存优化——逐层拆开。如果你也在做模型上线、推理服务优化、边缘端部署，或者单纯想搞清楚“量化到底是怎么掉精度的”“剪枝之后为什么推理反而慢了”，这篇应该能给你一些非官方的、踩过坑的经验。

需要说明的是，为了可复现性，下文涉及的具体命令和配置我会基于PyTorch 2.x + CUDA环境示范，如果你用的是TensorFlow或ONNX Runtime后端，思路相同，参数名会有差异。

2. 模型优化真正在解决哪三类问题

动手写工具之前，我先把问题域切成三类。这是整个Model-Optimizer设计的基础，也是后来排查问题时的依据，不管是新手还是老手，建议先在这里达成共识。

2.1 计算量太大，跑不动

模型在训练时只看精度，不看延迟。一个12层的Transformer，前向推理要做几亿次浮点运算，在A100上当然没压力，但换到4核CPU或者手机芯片上就是灾难。计算量相关的指标主要是FLOPs（浮点运算次数）和模型参数量。FLOPs决定理论上的计算上界，参数量决定内存占用的大头，两者经常被混为一谈，但优化手段完全不同——降低FLOPs要靠剪枝和结构简化，降低参数量要靠量化和蒸馏。

我习惯第一步先做一次profiling，用PyTorch自带的torch.profiler就能看出时间花在哪：

import torch from torch.profiler import profile, ProfilerActivity model.eval() x = torch.randn(1, 3, 224, 224).cuda() with profile(activities=[ProfilerActivity.CPU, ProfilerActivity.CUDA]) as prof: with torch.no_grad(): for _ in range(10): model(x) torch.cuda.synchronize() print(prof.key_averages().table(sort_by="cuda_time_total", row_limit=20))

输出里重点关注两个数字：一个是cuda_time_total占比最高的算子，往往就是优化的突破口；另一个是self_cuda_time_total，这个指标能告诉你哪些是真正耗时的算子，哪些只是被其他算子拖累的。以我的经验，卷积和矩阵乘法相关算子通常占掉70%以上的时间，这时候就该考虑算子融合或者低精度计算了。

2.2 显存占用超标，放不下

训练时我们习惯把整个模型塞进显存，中间激活值随便存。但生产环境可没这么大方。我做推理服务时遇到过最尴尬的事：模型在A10上能跑，但客户那边只有一张T4，显存只有16G，还得同时跑两个模型实例。这时候就要算清楚每部分占多少：

• 模型权重：参数量 × 每个参数的字节数。FP32是4字节，FP16是2字节，INT8量化后是1字节。
• 激活值：batch_size × 序列长度 × 隐藏层维度 × 层数 × 字节数。
• 临时缓冲区：算子执行时分配的中间结果，比如Softmax的中间变量。

一个具体的例子：BERT-base参数量1.1亿，FP32权重约440MB，看起来不大；但激活值才是大头，序列长度512、batch size 32时，激活值随便就上GB级别。这也是为什么量化虽然只把权重缩小到1/4，但总体显存收益却没那么夸张，因为大头在激活值——这时候需要的是梯度检查点（推理时没有梯度，但可以类比做算子级的内存复用）、激活值重计算或者更激进的结构剪枝，而不是单纯把权重精度降一降就完事。

2.3 精度与速度的平衡，没有标准答案

这是最容易被忽视的一类问题，也是Model-Optimizer里最需要人工介入的部分。常遇到的情况是：剪枝20%参数，准确率一点没掉，你信心满满地剪到50%，结果直接崩盘。或者量化的时候，小模型掉点不明显，大模型反而掉得厉害——因为大模型的数值分布更集中，对量化误差更敏感。

所以我在工具里专门加了一个"精度回归测试"模块：每个优化步骤之后，自动在验证集上跑一遍，输出与原始模型的差距。这个数字不是只给自己看，还要存成日志。为什么？因为后续生产阶段出现bad case时，你要能回溯是哪一步优化导致的精度劣化。

三类问题的优先级也存在权衡。我的经验是：如果没有显存压力，先做算子融合和推理引擎优化，收益最高且精度零损失；如果显存紧张，先做量化，但需预留精度校准时间；如果量化后精度仍然不达标，再用蒸馏来补偿。这个顺序和很多教程写的“先剪枝再量化再蒸馏”不同，理由后面会展开。

3. 从压缩到部署：Model-Optimizer的四大核心模块

我把工具拆成四个模块，对应四条优化管线。每个模块都能独立运行，也能组合使用。下面逐个说清楚它们干什么、怎么干、干活时有哪些容易忽略的细节。

3.1 模块一：结构化剪枝，删除“不重要的神经元”

剪枝分两种，非结构化剪枝是直接把权重矩阵里接近零的元素置零，模型变稀疏，但实际推理时如果不配合专用硬件和稀疏库，速度反而更慢——很多新手在这踩坑，以为参数少了就一定更快，其实稠密矩阵运算在GPU上更高效，稀疏矩阵反而要额外的索引开销。结构化剪枝则是把整个卷积核、注意力头或Transformer层删掉，模型真正变小，推理速度确实提升。

我用的是基于L1范数的结构化剪枝，原理很直观：每个卷积核的权重绝对值之和越小，说明它对输出特征图的贡献越低，删掉它对最终结果影响最小。在Transformer里类似操作是剪注意力头：对每一层的每个头计算其输出对最终loss的敏感度（可以通过梯度或统计输出来估计），敏感度低的头直接mask掉。

关键点在于剪枝后的微调。剪掉几个头之后，模型必须重新训练几个epoch来恢复精度。这步我踩过坑：最初图省事，剪完直接上生产，结果BLEU掉了一大截，后来才意识到剪枝本质上是人为制造了一个损坏的模型，不给它学习机会就上线，纯属耍流氓。

剪枝率的设置建议按层分配，不要全局一刀切。我在工具里实现了敏感性分析：对每一层单独做剪枝并观察精度变化，精度敏感的层少剪，不敏感的层多剪。效果最好的配置一般是：Embedding层不剪，底层encoder适当剪，顶层encoder少剪，输出层不剪。

3.2 模块二：量化压缩，用更少的比特装下同样的信息

量化是把FP32的权重和激活值映射到更低比特。最激进的是二值化（1bit），但实际生产用得最多的是INT8，性价比最高。

量化的核心问题是校准和数值映射。常见做法是线性量化：给定一个tensor，找到它的最小值min_val和最大值max_val，然后按公式把浮点数值映射到0~255之间的整数：

scale = (max_val - min_val) / 255 zero_point = -round(min_val / scale) int_val = clamp(round(fp_val / scale) + zero_point, 0, 255)

看起来很简单的公式，但坑在min/max取法。统计整个tensor的实际min和max是最容易过拟合的，因为个别离群点会拉大范围，导致正常数值的量化精度下降。更稳的办法是使用百分位（比如99.9%）而不是极值，把两端的离群点去掉再定范围。

校准数据的选择也很关键。我最初用的是训练集的随机1000张图，后来发现效果不好，因为分布和真实业务数据有偏差。正确的做法是从验证集或真实请求日志里采样一批有代表性的输入，跑一遍模型，统计每层的激活值分布，再来定scale和zero_point。这一步有个专业名词叫校准（calibration），Model-Optimizer里专门实现了两种：MinMax和Percentile，默认用Percentile。

量化后的推理速度并不总是更快。在GPU上，INT8计算通常需要Tensor Cores支持才能发挥全部优势；在CPU上，需要AVX512或者VNNI指令集。如果你的部署环境不支持这些指令，量化后反而可能因为额外的反量化操作变得更慢。所以工具里我保留了一个开关——纯INT8模式还是混合精度模式，混合模式是让Conv和MatMul走INT8，其他算子保持FP16，兼顾精度和速度。

3.3 模块三：蒸馏，让轻量模型“抄作业”

蒸馏是精度补偿的王牌手段。思路是把大模型（teacher）的知识迁移给小模型（student）。最简单的方法是软标签蒸馏：训练student时，除了真实的hard label，还让student的预测分布尽量靠近teacher的预测分布，用KL散度作为辅助loss。

我这里更推荐的是特征蒸馏，不仅看输出，还让student的中间层特征图尽量接近teacher的。比如BERT蒸馏时，可以让student的某一层输出和teacher对应层输出做MSE loss，这样student能学到中间表示，而不只是最终答案。

蒸馏的温度参数T是调节“知识软硬”的关键。温度越高，teacher的分布越平滑，小概率类别的信息也能保留；温度太低，分布锐化，就退化成了hard label。实践中我一般从T=3开始调，T=4到5如果参数多了会出现训练不稳定。

蒸馏的细节：teacher模型必须固定不动，不能跟着student一起更新；student的初始化很关键，直接从头训会很慢，我用的是从teacher的部分层参数初始化，比如BERT蒸馏时student的前几层直接用teacher的前几层权重，后面随机初始化。这样既加速收敛，又保留了底层语义能力。

3.4 模块四：推理加速与内存复用，部署前最后一道工序

完成压缩之后，模型理论上已经小了一号，但真正跑起来还要做两件事：计算图优化和内存复用。

计算图优化包括算子融合、常量折叠、冗余节点消除等环节。最经典的融合是Conv+BatchNorm+ReLU三合一：原来要来回读写三次显存的数据，融合后只读一次、写一次，省了两次访存。卷积后面的BN层在推理时其实可以吸收进卷积的权重和偏置——BN在推理时就是一个线性变换，完全可以把它的参数乘进卷积核里，这样模型结构就少了一个节点，推理时就少了一次kernel launch和读写开销。在PyTorch里torch.jit.freeze配合torch.jit.script就能做一部分，但更彻底的是用ONNX导出后再用TensorRT/OpenVINO的图优化器，那些工具里可以看到融合前后的graph差异。

内存复用更直接。推理时不需要保留反向传播的中间变量，所以forward过程中的中间结果能复用内存就复用。我把原始模型拆成了好几段执行，每段只保留当前需要的中间结果，其他全部清空。实现上可以用PyTorch的torch.utils.checkpoint思路改一版适用于推理的版本。下面这是简化逻辑：

class SegmentInference(nn.Module): def __init__(self, segments): super().__init__() self.segments = segments # 模型被切成多个子模块 def forward(self, x): for seg in self.segments: x = seg(x) torch.cuda.empty_cache() # 显存不够时才用，正常不推荐频繁调用 return x

频繁调用torch.cuda.empty_cache()会影响性能，因为每次调用都会触发CUDA context的同步，正确的做法是复用固定的缓存区，或者确保每个seg的输出不需要跨seg保留，让系统自己管理释放。真正有效的是控制batch size与序列长度，配合上面的融合减少中间张量数量。

4. 实操案例：bert-base的INT8量化全流程复盘

这一节拿我自己最近做的一个场景完整过一遍流程。任务是部署一个文本分类模型，要求单条文本推理延迟小于5ms，显存占用小于1.5GB，F1值下降不能超过1个点。原始模型是huggingface的bert-base-uncased微调版，FP32推理延迟约15ms，显存占用约2.1GB。选型时没有直接换引擎，就用Model-Optimizer在PyTorch环境里做整套优化链路。

先看优化前的profiling结果。我用torch.profiler测出来的热点集中在SelfAttention和两个全连接层：SelfAttention里耗时最高的是bmm（批量矩阵乘），两个全连接层分别占了总时间的18%和15%。这意味着单靠算子融合解决不了根本问题——矩阵乘法张数太多，必须从精度或结构上削减计算量。结合显存压力，量化是优先级最高的手段。

量化第一步是校准数据采集。我从训练集里随机抽了256条样本，但做了个额外处理——过滤掉那些长度超过128的样本，因为生产请求里长文本比例不高，校准应该贴近真实分布而不是训练分布。跑完分布统计之后发现，第6层和第8层的激活值分布有双峰特征，单靠一个scale去映射会损失精度。这种情况我的处理方案是在这两层之间插入一个per-channel量化策略，而不是全局per-tensor。

量化完成后做精度回归，用的是验证集的2000条文本。对比数据如下：

F1掉了0.8个点，在1个点的容忍线以内，但我觉得这个数字太接近红线了，怕泛化到真实场景会超。于是加了蒸馏补偿：用原模型当teacher，量化后的INT8模型当student，用特征蒸馏微调了1200步，学习率设5e-5，温度3。微调后F1回升到0.9205，基本追平了FP32。

蒸馏后的显存和延迟没有变化，因为模型结构、weights的位宽都没变，变的只是权重数值，所以推理性能和1.2GB显存这个结果保持不变。

5. 量化精度回落的定位链路：一个典型的排查过程

做完一轮量化+蒸馏之后，我又被一个问题卡了两天：某个特定类别（比如“科技”类文本）的召回率从0.91掉到了0.82，其他类别几乎没影响。整体F1看着还行，但细看就想骂人。这个现象非常典型，也很容易骗过粗粒度指标——如果你只盯着总F1，根本发现不了问题。

5.1 复现与定位：从整体指标到层间分布

第一步，把该类别的bad case聚出来，逐个看预测置信度分布。发现正常样本的置信度普遍在0.75以上，但这类样本量化后置信度一下子掉到0.55左右，这说明不是随机噪声，而是系统性的精度损失。

第二步，对比FP32和INT8模型在每一层的输出分布。我把两个模型的中间层激活值都dump出来，用KL散度算各层分布差异，发现差异最大的是第10层和第11层。对bert-base来说这两层已经是高层语义层，负责的是“抽象特征”，量化误差在这里被放大，最终反映到分类置信度上。也就是说问题不在量化本身，而是这两层的激活值分布中存在离群点，拉大了量化范围。

第三步，直接看第10层的激活值直方图。果然，绝大多数值集中在-2到2之间，但有少量值跑到了±15附近。整体min/max校准会为了照顾这不到0.5%的极端值，把scale定得很大，导致大部分正常值在INT8空间里挤向同一个区间，分辨率大幅下降，等效精度直接从8bit降到约4bit。

5.2 解决方案：百分位校准+离群值处理

我把校准策略从MinMax调整为Percentile 99.9，同时把超出范围的值做了clip处理。这里的关键点是：选择99.9还是99.99，需要根据实际直方图调整。99.9比较激进，99.99保守一些、精度损失更小但压缩收益略有缩小。我测试结果是99.9配合1e-3的截断系数对当前场景最优。

改完再跑精度回归，第10层的KL散度下降了一个数量级，该类别召回率恢复到0.90。整个过程中我最大的体会是：量化的坑基本都不在公式上，而在数据分布认知上。你以为自己在调精度，其实是在调对真实数据分布的理解。

还有一个值得注意的细节：校准数据里能不能覆盖离群点存在很大的偶然性。同样一个模型，换一种校准数据分布，导出结果就可能不同。所以Model-Optimizer里每次校准都会记录校准集的统计摘要（每层的min/max/mean/std以及99.9百分位值），做版本管理，将来模型行为异常时可以拿这个摘要来比对。

6. 剪枝与算子融合的联合调优：延迟还能再降的秘诀

完成量化只是第一步，当延迟目标卡着临界线时，就需要在剪枝和算子融合上继续深挖。这一节说说量化之后，我怎么把延迟从4.8ms继续压到3.2ms。

6.1 剪枝率敏感性表：用数据说话

我对模型做逐层敏感性分析的方法如下：固定一层，其余层不动，把该层的卷积核/注意力头逐步剪掉5%~30%，观察精度变化。对bert-base这种Transformer结构，结果非常典型：底层（1-4层）剪头影响不大，中间（5-8层）部分敏感，顶层（9-12层）极其敏感；且Attention层比FFN层更敏感。

据此定下的剪枝方案是：第1-4层剪掉15%的注意力头，5-8层剪10%，9-12层不剪；FFN层统一剪20%。剪完后模型参数量减少约18%，推理速度提升约15%。关键是精度几乎没掉，F1只降了0.1个点。这个效果和文献报告的“Transformer有大量冗余头”基本一致。

6.2 剪枝感知的量化：先瘦身再压缩

顺序上必须是在量化之前做剪枝，不要反过来。为什么？因为量化会把一部分权重置零，而剪枝是对剩余权重重要性做排序。如果先量化再剪枝，量化误差会干扰重要性的判断——一个本来很重要的权重可能因为量化噪声看起来不重要，剪掉了就掉点。先剪枝再量化，剪枝后的模型结构更干净，量化时校准也更容易。

组合执行后，模型结构和参数量如下：INT8量化前先做了剪枝，最终体积从112MB进一步降到89MB，延迟从4.8ms降到3.9ms。但离3.2ms还有距离，这时剩下的空间在算子融合。

6.3 算子融合实测：QKV融合与FFN重组

对Transformer模型来说，最有效的融合点是多头注意力的QKV计算。原始实现是分别做三个Linear，各进行一次矩阵乘；可以拼接成一个大的Linear，一次性算完再split。虽然FLOPs总量不变，但减少了一次kernel launch，对短序列推理的提升很明显。

同理，FFN两个全连接在推理中可以合成为一个等效线性变换：W_combined = W2 @ W1，b_combined = W2 @ b1 + b2，中间的非线性激活函数决定了能否吸收。GELU这种非线性无法被线性层吸收，所以不能直接合成；但如果用的是近似线性化GELU，或者把激活函数与卷积融合，又是另一个路子。我在工具里做的是选择性融合——对无法合并的层不动，能合并的层合并。

不过这里有个坑：融合之后的数值精度会略变，因为矩阵乘的顺序变了，浮点累积误差不同。我实测融合后精度在F1上掉了0.05个点，在可接受范围。还有一个更隐蔽的问题：融合后的权重矩阵计算方式是W2 @ W1，如果W1和W2有稀疏结构（来自剪枝），融合后稠密化会让推理变慢。所以我只对全稠密层做了融合，稀疏层保持两张权重分开推理。

最终延迟3.2ms，F1相对原始FP32模型掉了0.35个点，显存1.1GB，全部达标。整套优化流程串起来的效果：

每一步都能独立回溯、独立开关，这是我觉得Model-Optimizer最值钱的地方。

7. 工具链选型与二次开发经验：不迷信单一框架

做Model-Optimizer的过程中，我试过不少现成方案，也踩了不少框架绑定的坑。这一节给准备自己搭优化工具链的朋友一些选型建议。

7.1 PyTorch生态与ONNX Runtime/TensorRT的边界

PyTorch 2.x自带的torch.compile在动态shape场景下有额外编译开销，我第一次跑短文本（序列长度20）时比eager模式还慢，因为编译开销摊不掉。适合的领域是固定shape的批量推理，不适合高并发变长请求。

ONNX Runtime的CPU推理优化很成熟，尤其是量化算子的支持比PyTorch干净利落。但它在动态shape上同样有短板，ONNX图的动态维度一旦操作不当，就容易变成静态图，遇到变长输入就疯狂padding，计算量白白翻倍。TensorRT的INT8量化走的是层间校准和融合管线，速度和显存优化最彻底，但它依赖特定GPU架构，换了卡型就得重新构建engine，灵活性差很多。

我的实践建议是：把Model-Optimizer做成一个中间层，先用PyTorch做粒度和算法级别的调试（剪枝率、量化方案、蒸馏loss权重），确定参数之后再把模型导出成ONNX，交给ONNX Runtime或TensorRT做终端的图优化。两头各取所长。PyTorch适合研究怎么修剪调整，TensorRT/ONNX Runtime适合研究怎么跑最快，不要让一个框架干所有事。

7.2 校准数据管理：最容易被忽视的工程细节

校准数据散落在训练集、验证集或线上日志里，这个“从哪儿来”的问题直接决定量化效果。踩过的坑是团队里一位同学用自己的本地小数据集做校准，模型上线第一天就爆了异常告警，因为线上文本风格和他那批数据差太远。

我在工具里做了一套校准集管理机制：校准样本必须有标签，否则无法评估量化后的精度变化；来源必须可追溯，记录文件名、采样时间、清洗规则；一个模型对应一套独立校准集，版本号跟随模型版本走。这套做法听起来像软件工程而不是算法，但恰恰是保证量化项目可持续的关键。很多模型优化项目死在“模型改了一版，但校准数据还在用上一版的”这种问题上。

7.3 自研组件的核心代码结构

Model-Optimizer的核心结构并不复杂，我贴一个简化版的目录能帮你快速理解：

model_optimizer/ ├── compress/ │ ├── pruning.py # 结构化剪枝：L1/L2/敏感度分析 │ ├── quantize.py # 量化：MinMax/Percentile校准 │ └── distill.py # 蒸馏：软标签/特征/注意力蒸馏 ├── optimize/ │ ├── fuse.py # 算子融合：ConvBNRelu/QKV融合 │ └── memory.py # 推理内存复用与分段执行 ├── evaluate/ │ ├── accuracy.py # 精度回归测试 │ └── profiler.py # 延迟/显存 profiling └── export/ ├── to_onnx.py # ONNX 导出 └── engine_builder.py # TensorRT/OpenVINO 构建

每个模块的输入输出都定义成统一的数据结构（OptimizedModel），包含model对象、config、校准数据引用、评估报告。这样组合使用时就像搭积木。

8. 生产环境中Model-Optimizer的坑与应对策略

就算离线阶段所有指标都达标，到了生产环境还是会有新问题。这一节专门写“上线之后才会遇到”的几类坑，全是我自己踩过的。

8.1 动态shape导致的隐式Padding浪费

上线后我发现一个诡异现象：压测时P99延迟正常，但线上实际P99高出30%。后来看监控发现，上线流量里有一条长文本（512 tokens）请求，模型被迫动态调整shape走了慢路径。更麻烦的是，如果框架做了动态padding，其他短请求也会被补到512的长度，整个batch的延迟直接被拉长。

应对方案是把请求按长度分桶（比如2^4、2^5、2^6...），同桶内统一padding到桶的上界。这样把动态shape问题转成有限个静态shape组合，TensorRT可以直接为每个桶预构建engine，PyTorch也能稳定复用CUDA图。分桶的粒度要斟酌：桶太多导致每个桶请求量少、并发低；桶太少浪费计算。线上我们分了8个桶，效果最好。

8.2 量化模型对输入扰动的敏感性

一些聚类bad case显示，量化模型对同义词替换这种微小输入扰动更敏感。比如“电影”改成“影片”，FP32模型判断不变，INT8模型直接翻转预测。

原因在于量化误差相当于给网络加了微小噪声，这些噪声在深层被放大后，会让模型更倾向于落在决策边界附近。解决办法是量化后做对抗训练：在蒸馏微调阶段加入FGSM生成的对抗样本，强制模型在边界附近也有稳定输出。这块我加进去之后，bad case数减少约40%。代价是训练时间增加了约20%，算力换稳定，值得。

8.3 推理框架的数值一致性坑

同一份ONNX模型，在PyTorch、ONNX Runtime、TensorRT三个后端上结果可能不同。卷积实现的算法（比如隐式GEMM和Winograd）不同，浮点误差分布就不同；INT8实现时DP4A指令和Tensor Core的量化累加方式也不同。上线前一定要定义清楚以哪个后端为基准，否则测试和线上对不上账。

我踩过的一次：离线测试用的ONNX Runtime，上线是TensorRT，结果某几个样本的置信度差0.02，刚好排在阈值两侧，造成了线上误判。后来我在Model-Optimizer里加了“后端一致性检查”模块，对1000条样本同时跑两个后端，输出置信度差异超过0.01的样本单独观察，先在离线把差异控制住再上线。

9. 一点个人体会

Model-Optimizer这个工具做下来，我最深的感受是：模型优化的核心瓶颈从来不是某个算子或者某个公式，而是整条链路的可观测性。你看不到每一层的数值分布变化，就不知道量化精度掉在了哪里；你看不到每个后端的微小数值差异，就不知道线上bad case从何而来。工具本身是脚手架，真正决定成败的是你对自己模型的了解程度。

最后分享一个实用建议：新项目引入优化工具链时，别一上来就全量套路跑一遍。先量化，再根据精度损失决定要不要蒸馏，如果延迟还不够再考虑剪枝和融合——这个顺序能让你以最小成本找到自己的优化极限。我在这个过程中反复调试后确定的最优顺序确实是先量化，理由也说过：量化收益最大且操作最简单，先拿到大头收益，再决定是否值得花时间做精度补偿和结构剪枝。

如果你也想做一套类似的工具，建议从profiling开始，先看清楚自己的模型到底慢在哪、占在哪，再动手改。磨刀不误砍柴工，这句话在模型优化这条路上特别灵验。