几个月前我把一个视觉模型部署到线上推理服务，压测一上来，P99延迟直接顶到了红线，而计算资源占用还不到一半。当时团队里最直接的想法是"加机器"，我盘了一圈参数之后反而觉得，问题根本不在于硬件不够，而是模型本身有太多冗余——不少层的通道数明显过量，权重里接近四成的数值对最终输出的贡献几乎可以忽略。于是我开始系统性地做模型压缩与推理加速这件事。
这篇文章把我这段时间的完整实践整理出来，覆盖量化、剪枝、蒸馏、推理运行时的优化，以及衡量压缩成果的指标和方法。适合正在做模型部署、想在不换硬件的前提下把延迟和体积压下来的同学参考。内容不会只停在概念层面，每一部分都会交代我实际怎么选、怎么测、在哪里翻过车。
1. 压缩之前，先搞清楚推理时间到底花在哪了
很多人拿到"模型太大、跑得太慢"这个问题，第一反应就是上量化或者剪枝。但如果不先弄清楚模型的性能瓶颈，压缩方向很容易选错。我见过一个项目把卷积层从几百个通道一路剪到几十个，模型体积是下来了，推理延迟几乎没变——因为那个模型真正耗时的是后面的归一化和采样层。所以第一步永远是性能分析。
1.1 计算量还是访存量：先分清你的模型是"算不动"还是"取太慢"
推理耗时有两大来源：一个是真正的算术运算，也就是FLOPs；另一个是把数据从内存搬到计算单元里的过程，叫访存。绝大多数刚接触优化的同学只盯着FLOPs，觉得算得越少就越快，但实际上很多算子在推理的时候瓶颈根本不在计算，而在访存。
我常用的一个判断方法是看"计算强度"，也就是在一个算子里，计算量和数据搬运量的比值。打个比方：你要做一桌菜，如果全部时间都花在真正炒菜上，那是"算不动"；如果锅一直在空烧，人一直在跑来跑去拿食材、找调料，那就是"取太慢"。普通的卷积、全连接这类密集算子，计算强度通常比较高，压缩FLOPs有用；而归一化、激活函数、通道拼接、Softmax这些操作，数据量不小但每个元素只做几次简单运算，计算强度很低，真正的开销全在搬运数据上。
所以做压缩之前，先问自己一个问题：我的模型是卷积和矩阵乘法占大头，还是各种元素级算子占大头？如果是前者，剪枝、量化都立竿见影；如果是后者，更应该关注算子融合、内存布局，单纯把参数删掉意义不大。
1.2 用性能分析器给模型做一次"体检"
判断瓶颈不能靠猜，要实测。主流的训练框架都自带性能分析工具，可以直接跑一遍推理，按算子维度输出每一类操作的耗时占比和调用次数。我一般会导出模型后，用推理引擎的分析模式跑几十次，取平均值，然后把耗时Top 10的算子列出来。
这里有一个细节容易被忽略：分析的时候不要只跑一次，因为第一次推理有初始化开销，而动态形状、缓存预热都会影响结果。我习惯先把模型在空数据上跑若干轮做预热，再统计。另外，输出结果里除了耗时，还要看"调用次数"和"数据量"。有的算子虽然单次很快，但被调用了几千次，累加起来就成了大头；有的算子单次中等偏慢，但输入输出张量特别大，说明访存压力集中在它身上。
拿到这份体检单之后，压缩方案就有的放矢了。我的实际经验是：耗时排名前几位的算子往往不超过五种类型，把这些算子的实现参数（比如通道数、卷积核大小、输入分辨率）和计算强度一起看，基本就能判断该走量化、剪枝还是运行时优化。
1.3 为什么"换小模型"不总是最佳选择
既然模型太大，直接换一个参数量更小、业内成熟的轻量骨干网络行不行？这确实是一条路，但多数项目里并不划算。
小模型通常是在通用数据集上预训练的，而你的业务数据往往有很强的领域特性——比如工业质检里的瑕疵种类、语音场景里的噪声分布。从大模型换成小模型意味着模型要重新适配你的数据分布，这个适配过程对数据量、标注质量的要求都不低。相比之下，压缩原模型是在保留模型已经学到的知识基础上做减法，微调成本通常比重新训练小模型低，也更可控。
还有一个很现实的原因：很多线上系统里的预处理、后处理逻辑都是围绕原模型输入输出设计的，换模型等于动整条链路。压缩原模型则可以把接口完全保持不变，只替换中间的计算部分。所以在没有明确理由换架构的情况下，我倾向于先把压缩这条路走完再考虑别的。
2. 量化：把精度从浮点换成长整数，卡点不在数学而在数据
量化是目前收益最大、落地最快的压缩手段之一。把模型权重和激活值从32位浮点降到8位整数，模型体积直接缩到原来的四分之一，推理速度在支持整数指令的硬件上还能再上一个台阶。但它也是翻车率最高的环节，因为问题几乎都出在数据分布的处理上。
2.1 量化一次的数学账：scale、zero point 和动态范围
量化在数学上并不复杂。以对称量化为例，核心就是给一组浮点数值找一个缩放系数scale，然后做四舍五入：
import numpy as np def quantize_symmetric(tensor, bits=8): # 计算动态范围 max_abs = np.abs(tensor).max() qmin, qmax = -(2 ** (bits - 1)), 2 ** (bits - 1) - 1 scale = max_abs / qmax # 量化 q = np.round(tensor / scale).astype(np.int8) # 反量化参考 dequant = q.astype(np.float32) * scale return q, scale这里最关键的是max_abs到底取多少。如果直接取整个张量的绝对值最大值，那只要张量里有一个离群的极端值，scale就会被拉得很大，其他所有值的量化精度全被牺牲掉。于是我一般会先看一遍权重和激活的分布直方图，再决定是直接取min/max，还是做百分位截断，或者用基于信息量的方法寻找最优截断点。
另外还要区分权重量化和激活量化。权重的分布相对稳定，在线下就能算好scale；激活的值是推理时实时产生的，需要拿一批有代表性的输入先跑一遍，统计输出的分布，再确定scale。后者在实现上更麻烦，但效果差异很大，我后面单独讲。
2.2 校准集怎么选：别用训练集疯狂抽样本，要用"真实部署数据"
激活量化的scale必须通过"校准"确定，也就是拿一批数据跑一遍，记录激活值分布。这个校准集的选择，直接决定量化后的精度能保住多少。
我踩过最大的一个坑，就是第一次做量化时直接从训练集里随机抽了两百张原图做校准。离线测试精度掉得不多，上了线上数据之后，某些类别的准确率明显下滑。后来排查发现，训练集里的图像大多是经过增强的、构图规整的样本，而线上真实输入里有大量亮度异常、遮挡严重、拍摄角度刁钻的图。校准集和真实分布不匹配，scale就定偏了。
正确的做法是：校准集必须从真实部署环境里采样。如果产品还没上线，就拿最接近线上分布的数据，最好是原始、未经增强的样本。数量不需要太多，一两百张往往就能给出足够稳定的统计结果。另外一个经验是校准集要覆盖"边界情况"——比如分类任务里把易混淆的类别样本放进去，目标检测里把大小目标混合着放，这样激活值的动态范围才完整。
2.3 哪些层一量化就崩：我的敏感层清单
不是所有层都适合量化成INT8。我在多个模型上做过逐层敏感性测试，发现有几类层特别容易出问题。
第一层和最后一层是最典型的。输入层的数值范围直接受原始图像或文本特征影响，波动大；输出层往往要和阈值比较、做归一化，精度损失会直接影响最终决策。我的习惯是这两类层保留FP16，或者干脆保持FP32。
注意力机制里的Softmax也是重灾区。Softmax输出的概率值很多都集中在接近0的区间，量化后大量值被怼到0，类间差异就变得模糊。如果模型里有注意力结构，我不会把Softmax的输出强行量化成INT8，而是单独切成高精度计算，或者在量化配置里跳过这一层。
还有一个隐蔽的坑是归一化层。现在很多推理引擎会自动把归一化层融合进卷积里，这个融合在训练时就该体现。如果模型里还带着独立的归一化层，量化时它的均值和方差是浮点计算的，被量化后误差会被网络层层放大。我一般会在导出模型之前先做归一化折叠，把均值方差吸收进前一层卷积的权重和偏置里，然后再量化，精度会稳很多。
2.4 量化后如何找回精度：混合精度与微调
把敏感层单独拎出来保持高精度，这就是混合精度量化。实现上很简单，就是在量化配置里给指定的算子类型或张量名设置不同的精度。用这种方式，大部分场景里精度损失能控制在1%以内。
如果混合精度还不够，就需要考虑量化感知训练了——在训练过程中模拟量化的舍入误差，让模型参数学着适应量化噪声。这个方案成本确实高一些，需要重新跑训练流程，但换来的是几乎无损的INT8精度。我的判断标准是：离线测试精度损失超过2%且混合精度救不回来，再上量化感知训练；否则就先不动训练流程，只在推理侧做调整。
3. 剪枝：参数删掉一半不难，难在让删完的模型还能真正提速
量化主要解决"每个数值占多少空间"的问题，剪枝解决的是"哪些数值根本不需要存在"的问题。剪枝听起来很直观：把不重要的连接或者通道删掉。但这里有一个很多人没想透的地方——参数删掉了，推理速度不一定变快。
3.1 结构化非结构化：稀疏模型在推理引擎里能不能真正提速
剪枝有两种基本形式。非结构化剪枝是对单个权重做取舍，删完之后模型变成稀疏矩阵，权重的存储量确实下降了，但在通用推理引擎里，稀疏矩阵要想提速必须有专门的稀疏计算内核。没有这种内核，稀疏权重还是会被当成稠密矩阵去算，理论上的FLOPs减少完全体现不到延迟上。很多做剪枝的同学拿到的就是这个结果：模型文件小了，实际跑起来一点没快。
结构化剪枝按通道、卷积核或者注意力头整块删。因为删除后网络结构变得规整，CPU、GPU上的通用算子都能直接受益，推理延迟会有可测量的下降。代价是精度损失通常比非结构化剪枝大一些，对剪枝位置的判断要求更高。
我的选择非常明确：在通用部署场景里，优先做结构化剪枝。非结构化剪枝更适合那些底层内核已经专门优化了稀疏计算的专门硬件，普通业务项目很少具备这个条件。
3.2 用敏感性分析决定"剪哪里、剪多少"
剪枝最忌讳的做法是拿一个全局阈值，把所有权重绝对值小于阈值的通道全删掉。不同层对剪枝的容忍度差异很大，有的层剪掉40%通道精度几乎不掉，有的层剪掉5%就开始崩。
我实际操作的方法是敏感性分析：对每个候选层单独做一次小规模剪枝实验，每次只剪这一层、设置一个比例（比如20%），剪完不微调直接评估精度下降幅度。把所有层的下降幅度画成一条曲线，准确率掉得少的层就是高容忍度层，优先剪、可以多剪；准确率掉得快的层说明它承载的信息高度集中，尽量少剪甚至不剪。
这里有个技巧：分析的时候要用验证集的一个固定子集做快速评估，不要每次都在全量数据上跑。敏感性分析的目的只是排序，不需要绝对精确的精度值。剪枝比不是一步到位的，我更建议渐进式剪枝：每轮只增加一小部分剪枝比例，比如每轮5%到10%，剪完做轻量微调，再继续下一轮，直到精度跌破阈值。这样能比较平滑地找到每个层的剪枝极限。
3.3 剪完之后的微调策略：直接重训还是先只调分类头
剪枝完成之后，模型精度一定会掉一些，微调是必须的。但微调的力度和范围有讲究。
如果是浅层剪枝、精度损失很小（比如不到1%），我不动全模型，只把最后输出层用较小的学习率重新训练十几个迭代就够。之前试过在这个阶段把所有层全放开、用正常学习率训练，结果模型反而在业务数据上发生过拟合，线上效果不如只调输出层。
如果剪枝幅度大，精度损失超过几个点，那就需要把整个网络放开重训练，但学习率要比正常训练低一到两个数量级。原因不难理解：剪完之后模型处在"大体结构正确但局部细节被破坏"的状态，大学习率很容易把这些残存的正确信息也冲掉。我一般先用低学习率恢复精度到原来的95%以上，稳定后再略微提高学习率做正常训练。
还有一个细节：剪枝微调和蒸馏结合起来效果好得多。具体怎么做，我在下一节一起讲，因为这两件事是配合着做的。
4. 蒸馏：把大模型的"判断余量"传承给小模型
剪枝和量化把模型变小了，但变小的过程中必然损失信息。知识蒸馏做的是另一件事：让一个能力更强的大模型充当"老师"，把它的判断能力教给压缩后的小模型。它不是压缩手段本身，却是让压缩效果保真的关键配套。
4.1 软标签为什么比硬标签更有信息量
分类任务的标准训练用的是硬标签，也就是"这张图是猫"，其余的都当成错误答案。但现实中类别之间是有相似度的，猫和狗的相似度比猫和汽车高得多。如果训练时只告诉模型"猫是对的、其他全错"，这个相似度信息就浪费了。
老师模型在推理时会输出一组Softmax概率，这就是软标签。假设老师对一张猫的图输出的是"猫0.7、狗0.2、兔子0.08、汽车0.02"，这里面的0.2和0.08就是隐藏的知识。学生模型学习软标签，等于同时学到了"这是猫"和"猫与狗有多像"这两层信息。这就是蒸馏的核心逻辑——软标签里装着类间关系。
为了让类间关系展示得更充分，蒸馏时会给Softmax加一个温度参数：把逻辑值除以温度T之后再算概率。温度越高，概率分布越平缓，类间差异越细腻；温度太低，又退化成硬标签。这个温度是蒸馏里最重要的超参数之一。
4.2 蒸馏、剪枝、量化的组合顺序：我跑通的一条管线
蒸馏什么时候做？我试过几种顺序，目前比较稳定的一条管线是：
第一步，先训练好完整的原模型，作为老师。 第二步，对老师模型做结构化剪枝，得到结构紧凑的学生雏形。 第三步，让学生模型去学习老师模型的软标签输出，同时仍然结合一部分硬标签训练。这一步一方面恢复剪枝损失掉的精度，另一方面把老师在大数据集上学到的类间关系传递给学生。 第四步，对训练好的学生模型做量化，并保留敏感层为高精度。
这个顺序的逻辑是：先剪枝把结构变小，再用蒸馏把精度补回来，最后量化降低数值精度。如果先量化再剪枝，会导致剪枝结构的判断基于已经损失了精度的模型，容易选错剪枝位置。先蒸馏再剪枝也有问题，因为教师边界是浮点模型上划出来的，剪枝结构变化后蒸馏信号已经不那么有效。
4.3 蒸馏时最容易忽略的三个超参数
温度T是最显眼的参数，一般取3到7之间。太低学生学不到类间关系，太高所有类别的概率被拉平，等于给学生灌噪声。我习惯先粗做一组T的扫描，取验证集上精度最优的值，再细调。
第二个是损失权重alpha。蒸馏损失和硬标签损失的配比很关键。alpha太大，学生太依赖老师，老师犯的错它也会继承；alpha太小，蒸馏形同虚设。经验上alpha在0.5到0.8之间比较常见，但最终还是要看验证集曲线。
第三个是多被忽略的师生结构差异问题。如果老师和学生的输出维度不一致，比如老师最后一层隐藏层宽度比学生大很多，直接匹配输出概率还好，想匹配中间特征就需要额外的投影层。我的建议是最开始先从只匹配最终输出概率开始，这个最简单、也最容易复现；确需匹配中间表示时，再加投影层并逐步放宽对齐权重，不要一步到位把所有层都强行对齐。
5. 推理侧加速：模型变小之后，要让运行时真的"跑快"
压缩手段把参数和计算量降下来了，但推理引擎如果不会"聪明地执行"，这些收益会被运行时低效浪费掉。模型压缩是给推理加速打基础，真正压出延迟还得看运行时这一层。
5.1 算子融合：把多次内存往返合成一次
现在的网络结构都是由一个个小算子拼起来的。以卷积后接激活函数为例，如果不做任何优化，引擎会把卷积的输出完整写回内存，再读出来算激活，再写回去。每一趟读和写都是耗时，数据量大的时候这些开销甚至比卷成本身还高。
算子融合的思路就是把这些小算子合并成一个大的计算内核，让数据在寄存器或者高速缓存里就完成全部处理，只有最终结果才写回内存。我见过的典型融合是把卷积、归一化、激活函数合成为一个算子，光这一步在边缘设备上通常就能带来20%以上的加速。元素级算子、残差结构的相加操作、以及连续的点乘操作，都属于适合融合的对象，但不同推理引擎支持的融合范围差异很大，需要拿实际模型去验证。
5.2 内存布局与形状优化：通道维放哪里，不是习惯问题
同样一份张量数据，在内存里的排列方式会影响缓存的命中率。具体来说，图像张量默认是通道在外的布局，但很多底层计算库对通道在后的布局优化更好。推理引擎在编译优化模型时通常会做布局转换，但对于自己手写或者拐弯抹角的模型结构，这一步不一定做得彻底。
我在部署时会给推理引擎明确的布局选择，并在配置中允许它做布局转换。转换本身有一点点开销，但如果是批量推理，一次转换带来的收益比开销大得多。另一个相关的问题是动态形状。输入尺寸如果每次都变，引擎无法提前做好内存规划，很多优化策略也施展不开。我的经验是：如果业务允许，尽量固定输入形状；必须动态时，也要把变动范围限制在一个小集合里，让引擎可以按这几种形状分别做内存预分配。
5.3 部署环境实测：批大小、并发、线程数一起调
模型压缩做完之后，实际部署时的参数对延迟影响非常大。这些参数不是拍脑袋定的，而是要实测。
单条输入延迟和吞吐量之间往往要取一个平衡。批大小设成2或4时，单条输入的额外开销被摊薄，总吞吐上升，但单条延迟可能略微变差。我一般会用两类指标同时做压测：P99延迟和每秒处理条数。如果业务对实时性要求高，批大小压到最小；如果服务允许攒一批处理，就测出吞吐和延迟的帕累托曲线，选拐点附近的值。
线程数也是个隐形变量。把线程数设为物理核心数通常是最稳的，设过大反而会因为线程切换和资源争抢拖慢速度。推理引擎的内存池最好提前分配好，避免每次请求都临时申请内存。这些都不难做，但线上效果差异非常明显，值得花一个下午来回测。
5.4 我验证过的一套组合拳流程
把压缩和运行时优化串起来，我目前沉淀的流程是这样的：
先用性能分析器确认瓶颈算子类型；接着做权重量化为主、激活量为辅的INT8量化，敏感层保持高精度，快速评估精度损失；如果损失可控，就基于量化后的模型做结构化剪枝，配合敏感性分析确定比例；剪完做低学习率微调加蒸馏恢复精度；最后导出通用交换格式，在目标推理引擎里开启算子融合、布局优化、静态形状，再对批大小和线程数做一轮参数扫描。
每一步做完都要立即实测延迟和精度，不要等全部做完再统一验收。因为每一步的收益会叠加，但每一步的坑也会叠加，早发现早定位。
6. 压缩成果怎么验收：别只盯着模型体积和精度
压缩项目最容易出现的问题是验收标准过于单一——模型文件变小了、准确率看起来没掉，就宣布成功。但上线之后才发现延迟不稳定、显存没降多少、或者某些长尾输入效果崩了。我建议从四个维度做完整验收。
6.1 一套完整的评估指标：延迟、吞吐、内存、功耗
我整理了一张验收时必看的指标表，供你直接抄：
| 指标 | 说明 | 测试方式 |
|---|---|---|
| 模型体积 | 压缩前后存储占用 | 直接比较导出文件大小 |
| 推理延迟 | 单条输入的耗时，看P50、P95、P99 | 预热后压测，多轮取统计量 |
| 吞吐量 | 每秒处理条数 | 固定并发压测 |
| 内存/显存峰值 | 部署时的资源占用 | 监控工具观察峰值 |
| 功耗（端侧） | 电量消耗与发热 | 端侧实测，比较单位任务能耗 |
| 精度保持 | 业务核心指标差异 | 和压缩前模型在相同测试集上对比 |
其中P99延迟特别值得关注。有的压缩方案把平均延迟降得很好，但偶发的高延迟尾巴还在，这在线上体验里非常致命。我会单看P99曲线在压测过程中的波动，如果抖动幅度超过平均延迟的两倍，宁可把方案调保守一点。
6.2 上线前必须做的回归检查
离线测试集通过不代表线上没问题。我总结过几类回归检查，每一次压缩方案上线前都会过一遍。
用线上真实流量里的数据切片做一轮回放测试，对比压缩前后模型每个类别的输出分布是否一致。重点看长尾类别，这些类别样本少，压缩带来的误差容易被均摊掉，但单拎出来可能已经崩了。数值稳定性也要查，量化后模型的输出偶尔会出现个别极端值，需要在后处理里做截断，避免影响业务逻辑。还有输入分布漂移的可能——如果校准集是上个月采的，而这个月线上分布变了，scale和剪枝比例都需要重新评估。
6.3 两个值得记录的翻车现场与补救
我做过一个文本分类模型的INT8量化，离线测试精度只掉了0.3个百分点，结果在灰度阶段发现特定话题类别的召回率掉了快10个百分点。排查后发现问题出在校准集：当时偷懒直接用了训练集里去掉增强的样本做校准，激活分布和线上差异明显。补救方法是重新采了一批包含长尾类别的真实线上样本来校准，召回率立刻恢复。这个案例让我彻底记住了"校准集必须贴近真实部署分布"这条铁律。
另一个案例是给端侧设备做剪枝，在服务器推理引擎上测出延迟下降30%，部署到设备之后反而变慢。原因很简单：设备的推理内核不支持结构化稀疏模式，剪掉的通道并没有带来实际加速。从那以后，我坚持在目标硬件上做最终验收，而不是用服务器或开发机的性能推断端侧表现。这个建议也送给所有做端侧部署的同学，性能数字一定以最终运行环境为准。
压缩和加速这条路没有一次性的万能方案，每个模型、每种部署环境都有它自己的脾气。但我可以负责任地说，只要你按"先定位瓶颈、再组合手段、最后严格验收"这个节奏走，绝大多数项目都能在不换硬件的前提下挤出一倍以上的性能余量。实际操作中慢慢积累每个层、每个算子、每类数据的"手感"，会比任何现成工具都更管用。
