企业官网建设流程全解析

模型在训练服务器上跑得欢，一提到上线部署就头疼：显存不够、延迟超标、带宽吃紧，甚至边缘设备上连加载都费劲。这种“训练舒服、部署遭罪”的局面，我相信做算法或者做系统优化的朋友都深有体会。神经网络压缩这门手艺，解决的就是这个问题——把训练好的大模型想办法“瘦身”，体积缩小、推理加速、内存占用压下来，同时尽量保住精度。这篇实战指南是我在多个压缩项目里踩过坑、填过坑之后整理出来的完整思路，覆盖剪枝、量化、知识蒸馏和低秩分解这四条主流技术路线，适合正要入门模型压缩的工程师、准备做端侧部署的算法同学，以及在压缩过程中被精度掉点和加速失效反复折磨的老手。

标题里说的“大模型”，未必特指参数规模千亿百亿的生成式模型，哪怕是一个几十MB的视觉模型，放到移动端或者嵌入式设备上，同样算得上“大”。压缩的目标始终一致：让模型在受限的算力和内存环境下尽可能发挥原有能力。所以这篇文章里的经验，对校园里的课程设计、工业界的边缘部署、甚至云上GPU推理的成本优化都有参考价值。文章按“总-分-总”的节奏展开：先讲压缩技术的整体选型逻辑，再逐个拆解四种具体手法的实操细节，最后给一份问题排查速查表和一条完整的端到端压缩路线。

1. 为什么要压缩：先算清楚这笔账

1.1 模型资源消耗的三个大头

在动手压缩之前，务必要搞清楚模型到底“卡”在哪个环节。一个深度学习模型在部署时的资源消耗，主要落在三个地方：存储体积、内存占用和计算延迟。

存储体积最好理解，就是模型文件占用的磁盘或Flash空间。一个5000万参数的模型，FP32权重一参数4字节，光参数文件就接近200MB。放到服务器上问题不大，放到手机App里就有点尴尬了，放到几十KB存储空间的MCU上则根本不可能。内存占用就更复杂一些，推理的时候除了权重本身，中间层的激活值也要占内存，输入分辨率一大，“激活值爆炸”比“参数爆显存”来得更快。计算延迟则是实际用户能感知到的指标：一次前向传播跑多久，直接决定了每秒能处理多少请求，或者摄像头画面能否达到实时帧率。

我见过不少项目组，上来就默认“模型太大所以要压缩”，结果一顿操作之后发现速度没快多少，或者精度掉得厉害。原因往往就是没先搞清楚瓶颈在存储、内存还是延迟。压缩手段各有侧重：剪枝主要降计算量和权重存储，量化主要降低单位参数的内存占用和计算开销，蒸馏可以直接换一个更小的模型结构，低秩分解则适合特定的大矩阵结构。先定位瓶颈，再选方案，这是压缩任务里最关键的第一步。

1.2 四条技术路线的定位与选型

为了直观地做技术选型，我把四种主流压缩方法的核心差异整理成一张表，这是我做项目时反复对照的框架。

选型的核心逻辑可以归纳成一句话：“如果模型本身有冗余，先剪枝；如果冗余不大但精度足够，上量化；如果精度不够又想换小模型，用蒸馏；如果参数集中在全连接层，补一枪低秩分解。”

1.3 压缩目标的量化定义

压缩项目必须在一开始就定义清楚“成功”的标准。我给所有压缩任务都建议明确三个数字：目标体积、目标延迟、可接受的精度损失。

比如一个图像分类模型，原始FP32权重98MB，在一颗中端ARM CPU上单帧推理耗时45ms，Top-1精度76.3%。压缩目标可以定为“权重降到28MB以内，单帧推理降到20ms以内，Top-1精度不低于74.5%”。注意，这三个指标要同时约定，不能只压一个。我遇到过只定了体积目标，结果模型确实小了，但推理慢到不可用的项目，就是因为剪枝只删了权重没减通道，实际计算量没降。

有个经验是“精度损失要按任务类型区别对待”。分类任务掉0.5-1个点往往是可接受的，检测任务敏感得多，分割任务则对边界细节极其敏感。目标检测中的小目标、细粒度分类里的相似类别，常常是压缩后最先“崩掉”的部分。所以压缩之前最好记录好原始模型在各类别、各尺度的详细表现，方便压缩后做针对性回归。

2. 模型剪枝实操：直接从结构上去冗余

2.1 剪枝的对象与判断标准

剪枝的直觉很简单：一个模型里不是所有参数都有用，把“不重要”的参数删掉，模型变小，计算变快。但“不重要”怎么定义？这是剪枝技术最核心的问题。

实际项目里我常用的重要度指标有三种。第一种是权重的绝对值大小，一般认为绝对值小的参数对输出贡献有限，适合做非结构化剪枝。第二种是BN层的gamma系数，在带BN（BatchNorm）的卷积网络里，每个通道在进入下一层之前会执行“缩放”，这个缩放系数gamma在训练过程中被自动调整，gamma值小的通道意味着该通道的输出被抑制，可以剪掉整个通道。第三种是基于梯度/二阶信息的敏感性指标，理论上更精准，但计算成本高，我在工业项目里用得很少。

推荐优先采用BN gamma作为结构化剪枝的重要度指标，原因很实在：实现简单，可以直接在现有CNN上操作，不需要额外训练，而且效果在主流分类网络上表现稳定。做法是统计所有BN层的gamma绝对值分布，设定一个剪枝比例，把小于阈值的通道连带着前后卷积层的相应行列一起删除。

2.2 结构化剪枝的PyTorch实现

下面这段代码是我在项目里常用的结构化剪枝核心逻辑，以带BN的卷积层为对象，按通道剪枝。

import torch import torch.nn as nn def prune_conv_bn_by_gamma(conv, bn, prune_ratio, skip_bn=False): """ conv: 源卷积层 bn: 紧随卷积层之后的 BatchNorm2d prune_ratio: 裁剪比例，0.0 ~ 1.0 """ gamma = bn.weight.detach().abs() num_channels = gamma.size(0) keep_num = max(int(num_channels * (1 - prune_ratio)), 1) # 按 gamma 值排序，保留前 keep_num 个通道 _, keep_idx = torch.topk(gamma, keep_num) keep_idx, _ = torch.sort(keep_idx) # 裁剪当前卷积层的输出通道 conv.weight.data = conv.weight.data[keep_idx, :, :, :] if conv.bias is not None: conv.bias.data = conv.bias.data[keep_idx] # 裁剪 BN 层的全部统计量 bn.weight.data = bn.weight.data[keep_idx] bn.bias.data = bn.bias.data[keep_idx] bn.running_mean.data = bn.running_mean.data[keep_idx] bn.running_var.data = bn.running_var.data[keep_idx] # 返回保留的通道索引，用于裁剪后续层的输入通道 return keep_idx

这段代码只处理了单层的前半部分。真正的麻烦在于“后续层怎么同步裁剪”。假设卷积A输出64个通道，接一个BN，再接卷积B输入也是64个通道。裁掉A的32个输出通道后，B的输入通道也必须裁掉对应的32个，否则维度对不上。实际网络中还存在共享权重的层、残差连接和拼接操作，这些都要单独处理。

残差结构是剪枝最大的坑。以ResNet为例，残差分支和shortcut分支的通道数必须一致。如果两个分支分别属于两条独立的BN统计链，裁剪结果可能两边保留的通道索引对不上。我的做法是：先在所有参与残差对齐的层之间收集gamma值，按分组排序，保证每一次裁剪时残差两侧保留的通道完全一致。简单说，就是让 shortcut 对应的通道跟随主分支一起保留。这块逻辑虽然繁琐，但写一次之后可以做成通用工具，后期收益巨大。

2.3 剪枝后的微调与参数设定

剪枝完成只是第一步，剪掉的模型直接拿去推理，精度大概率会掉。必须有微调环节来恢复精度。这里的关键参数有三个：微调epoch数、学习率和batch size。

我的经验是，剪枝比例在20%以下时，通常微调3到5个epoch就能恢复到接近原始精度；剪枝比例在30%到50%时，需要10到20个epoch，且学习率应降低为原来的0.1倍左右。例如原始训练使用学习率0.05，剪枝后微调可以从0.005开始，并根据验证集精度动态衰减。不要用原始训练的学习率直接微调，那会让模型在已经收敛的区域剧烈震荡，精度反而进一步恶化。

另一个容易被忽视的点是：剪枝不要一次到位，最好采用“渐进剪枝”策略。比如目标剪掉50%的通道，不要一次性剪完，而是分4到5次，每次剪10%到15%，然后微调数轮，再剪下一轮。渐进式的精度恢复效果明显好于一次性裁剪，尤其在结构化剪枝中，因为每一层的重要度会随着裁剪过程发生迁移——某个通道在第一轮不重要被剪掉后，它的下游依赖通道可能反而变得更重要了，渐进剪枝可以捕捉到这种变化。

实操时还要注意评估时机。每次剪枝后、微调前，都建议跑一次完整的验证集，记录“剪切后未微调精度”和“剪切后微调精度”。这两个数字能帮你判断是剪多了，还是微调不够。如果剪切后精度骤降超过5个点，说明剪枝比例过大或重要度指标失效，赶紧回退，别硬着头皮微调。

3. 量化实战：把FP32变成INT8，延迟立刻降一截

3.1 量化表示与对称/非对称

量化的本质很简单：用更少、更离散的数值来表示权重和激活。FP32是32位浮点，INT8是8位定点，数据表示范围从大约±3.4e38缩小到-128到127，需要用缩放因子（scale）和零点（zero point）把原始实数映射到可表示的整数区间。

非对称量化公式是： q = round(r / scale) + zero_point 其中scale = (r_max - r_min) / (q_max - q_min)。对称量化进一步假设zero_point为0，直接q = round(r / scale)，简化了计算。权重一般适合对称量化，因为权重分布通常关于0对称；激活则更适合非对称量化，因为ReLU后的激活值都是非负的。这个差异在很多推理框架里是默认配置，但自定义实现时一定要确认。

按量化发生的时机，又分为训练后量化（Post-Training Quantization, PTQ）和量化感知训练（Quantization-Aware Training, QAT）。PTQ不需要重新训练，拿一批校准数据统计激活的范围即可，速度快、成本低，是绝大多数场景的首选。QAT需要在训练过程中模拟量化的舍入误差，让模型权重适应量化后的表示，精度更高，但要多跑一轮训练。工程上我一般这样决策：能用PTQ解决问题就不上QAT；PTQ精度掉点超过1个百分点，且用校准集调校后仍然不行，才考虑QAT。

3.2 训练后量化的完整落地步骤

以PyTorch为例，训练后量化主要分五步：准备模型、设定量化配置、插入量化观察点、校准、转换。校准非常关键，需要准备一个能代表真实数据分布的校准集，规模通常100到1000张图就够。

import torch from torch.quantization import quantize_fx # 1. 准备模型 model.eval() # 2. 配置量化后端，x86 用 fbgemm，ARM 上用 qnnpack model.qconfig = torch.quantization.get_default_qconfig('fbgemm') # 3. 插入 QuantStub / DeQuantStub 以及观察器 m = torch.quantization.QuantWrapper(model) # 4. 校准：跑几个 batch，统计激活分布 m.eval() with torch.no_grad(): for images, _ in calib_loader: m(images) # 5. 转换为量化模型 torch.quantization.convert(m, inplace=True)

校准集的选择直接决定PTQ效果。我第一次做量化时，图省事直接用了训练集里的前100张图。结果发现激活值范围统计严重偏向某个类别的亮度分布，量化后的模型在暗光样本上精度崩了。后来改用从训练集和验证集中随机采样的方式，模拟真实推理时的数据分布，问题才解决。

常见的坑还有敏感层问题。比如输入层、最后的分类层、检测网络的输出头，对这些层直接量化往往掉点严重。我的做法是保留敏感层为FP32，只对网络主体做INT8量化，这个操作在多数框架里只需要一个“保持浮点”的白名单配置。精度和加速之间的取舍要具体实验，不要一刀切全量化。

3.3 量化感知训练与敏感层保护

当PTQ精度不佳时，QAT是保精度的重要手段。QAT的核心是在前向传播时模拟量化误差，让模型在这些误差存在的情况下继续训练。实际操作里，为了模拟“量化误差”，在训练过程中插入伪量化节点，该节点在前向时将其输入量化再反量化，产生可微的舍入近似。

QAT的训练配置与剪枝微调有类似之处：学习率要更低，通常取原始训练的0.01到0.05倍；epoch数不必太长，5到10轮就够。QAT并不是把模型从零训练一遍，而是在原始模型基础上做“适应性调整”。所以初始权重加载原始权重，再小幅微调。

理论上量化以描述数值范围的scale为核心。训练中scale参数本身也是可学习或动态更新的。早期的QAT方案在一开始就冻结scale，结果训练的分布稍微一变，量化误差就放大。后来我改成每次训练迭代时重新统计激活的scale，效果明显更稳。

3.4 推理框架对量化收益的影响

量化在纸面上的收益是“模型体积变为1/4，计算延迟大幅下降”，但这个收益能不能真正兑现，取决于推理框架和硬件。

在CPU上，是否支持高效的INT8指令至关重要。x86平台通常需要AVX512或者VNNI扩展指令集，ARM平台则需要对应的dotprod指令支持。如果硬件不支持INT8 SIMD，那么框架会回退到浮点计算或逐元素模拟，速度反而比直接跑FP32更慢。GPU上情况类似，INT8运算在Tensor Core上有明显加速，但在没有Tensor Core的老款显卡上可能毫无收益。因此在做量化切换之前，务必确认目标设备、驱动、推理框架三者对INT8的支持程度，这是决定量化能否落地的前提。

此外，量化模型的算子融合也影响最终速度。最常见的是把Conv+BN+ReLU融合成一个量化卷积算子。融合后减少了一次内存读写，延迟能进一步下降。我在一个检测模型上做过对比：单独量化延迟大约降到65%，再做算子融合能再降到约45%。融合的配置在大多数部署框架里是自动的，但自动不一定最优，还是需要自己看profile日志确认融合是否生效。

4. 知识蒸馏实操：换个小结构，让大模型教你

4.1 从“结果对齐”到“分布对齐”

剪枝和量化都是“基于同一个网络结构做精简”，知识蒸馏的思路不同：直接换一个更小的模型结构，然后让大模型当老师，通过模仿输出来训练这个小模型。

最初的蒸馏直觉，是让学生的输出结果尽可能接近老师的输出结果。但仔细想一下，如果只有一个分类标签“猫”，老师模型不仅输出“猫”的概率，还会输出“猫很像狸花猫”“猫有点像狗”这样的软分布信息。这些“软标签”包含了大模型对样本的细致理解，比硬标签“猫”信息量丰富得多。蒸馏正是利用了这一点，让学生去拟合老师输出的完整概率分布。

4.2 蒸馏损失设计与温度参数

蒸馏的标准做法是使用温度T软化概率分布，然后用KL散度约束学生分布向老师分布靠近。一个经典蒸馏损失设计如下：

def distillation_loss(student_logits, teacher_logits, labels, T=4.0, alpha=0.7): import torch.nn.functional as F # 老师分布软化 soft_target = F.softmax(teacher_logits / T, dim=-1) # 学生分布取对数软化 student_log_soft = F.log_softmax(student_logits / T, dim=-1) # KL散度 kd_loss = F.kl_div(student_log_soft, soft_target, reduction='batchmean') * (T * T) # 标准交叉熵 ce_loss = F.cross_entropy(student_logits, labels) # 加权组合 return alpha * kd_loss + (1 - alpha) * ce_loss

注意代码里乘了T*T这个系数。因为softmax被温度T软化后，梯度会按1/T²倍缩小，如果不乘回这个系数，kd_loss在训练中的梯度贡献会随温度升高而变弱，学生模型的优化会非常缓慢。这个细节很多开源代码里都有，但自己实现时容易漏。

温度T的选取同样讲究。T越小，分布越尖锐，越接近硬标签；T越大，分布越平滑，样本间的细节关系保留得越多。分类任务里T取3到5比较常见，检测任务里T取4到8也有效。T不是一成不变的，可以在一轮训练中逐渐降低温度，让模型先从平滑分布中学习全局关系，再逐步逼近真实标签，这种方式在实践中往往比固定T收敛更稳。

蒸馏训练还有一个容易被忽略的细节：老师的logits要在训练前一次性缓存下来，不要每次迭代都现算。老师模型往往很大，如果整个epoch都跑老师前向传播，训练成本几乎翻倍。缓存之后，每个样本对应的软标签直接加载，训练速度大幅提升。当然，如果老师是动态更新的，或者软标签依赖强数据增强后的输入，缓存策略就不能用了。

4.3 蒸馏与剪枝、量化的组合用法

知识蒸馏最被低估的价值，是作为剪枝和量化之后的“精度恢复器”。剪枝后模型结构变小，直接微调可能回不到原始精度，但用原始大模型当老师做蒸馏微调，常常能多恢复不少精度。量化感知训练同理，可以用原始FP32模型作为老师，帮助学生模型适应量化误差。

我推荐的顺序是：先做结构化剪枝 → 再用原始权重初始化剪枝后的结构 → 用原始全精度模型做蒸馏式微调 → 最后做量化 → 量化感知训练时再次以未量化的全精度模型为老师。这套组合拳是一种“加法式精度恢复”，每一步操作造成的精度损失都能得到及时补偿，整体掉点控制在很低水平。

组合使用时要注意训练资源规划。蒸馏微调和QAT的训练都要在目标数据集上跑，如果数据集很大，资源消耗不容小觑。我的经验是先用小规模子集做方案验证，确认精度恢复趋势后再扩展到全量数据。不要一上来就跑全量，否则一轮实验往往几个小时过去，结果却不理想，时间成本太高。

5. 低秩分解与综合压缩路线

5.1 低秩分解的适用边界

低秩分解对很多人来说比较陌生，我先用一个类比说明。一个矩阵如果高度相关，其信息可能集中在前几个主方向上，那么可以把一个大矩阵近似表示为两个小矩阵的乘积。假设权重矩阵W的形状是m×n，通过SVD分解为U、Σ、V三个矩阵，只保留前r个奇异值，得到近似分解W ≈ U_r Σ_r V_r。如果r远小于min(m, n)，参数总量从m×n降为(m×n)×r，存储量显著下降。

SVD在编程库里只占几行代码，但实际部署的时候有两个麻烦。第一个麻烦是分解后的两个矩阵在推理时依然需要连续两次矩阵乘法，虽然参数少了，但计算量不一定同步下降，具体要看层的形状和分解秩的选择。第二个麻烦是某些推理框架对非标准结构支持不好，两个小矩阵反而引入额外的算子调度开销。因此在CNN主干网络里我很少单独用低秩分解，它更适用于全连接层、Embedding层和大规模推荐模型的排序层。

5.2 一条端到端综合压缩的实战路线

为了让文章不只停留在“拆解单个技术”，我整理一条端到端的综合压缩路线，以一个典型的图像分类模型为例，展示数值变化过程。

初始条件：ResNet-50结构，ImageNet数据集，模型权重约98MB，FP32推理单帧耗时45ms，Top-1精度76.3%。部署硬件的FP32算力有限，目标是将延迟压到20ms以内，权重压到30MB以内，精度不低于74.5%。

第一步，定位瓶颈。该模型在目标CPU上单帧45ms，其中大部分时间消耗在卷积层计算。存储瓶颈为98MB。于是主策略选择结构化剪枝+量化。

第二步，结构化剪枝。统计所有BN层gamma绝对值。浅层感受野小、信息密集，裁剪比例控制在0.2；深层冗余更多，比例调到0.4。同时保证残差两侧通道对齐。剪枝后权重从98MB降到约42MB，计算量下降到原来的约55%。

第三步，蒸馏式微调。以原始ResNet-50为老师，剪枝后的模型为学生，T=4，alpha=0.6，学习率0.002，微调15个epoch。最终Top-1精度从剪枝后的74.1%恢复到了75.8%。

第四步，INT8量化。准备500张训练集和验证集的混合校准图，先对敏感层保持FP32，其余层做PTQ。转换后权重从42MB降到约12MB，单帧延迟从24ms降到17ms。

第五步，延迟不达标，继续叠算子融合。确认Conv+BN+ReLU融合生效，延迟进一步降到14ms。此时精度实测为75.2%，满足目标。整条路线下来，体积从98MB降到12MB，延迟从45ms降到14ms，精度损失为1.1个百分点，全部符合预期。

5.3 压缩后的评估体系建立

压缩项目的验收不是“跑一次验证集看个acc”就结束。我建议建立一套每次压缩变更都要执行的回归评估体系，至少包含四个维度：精度指标（分类top1/top5、检测mAP等）、延迟指标（单帧/多帧平均值、p95延迟）、体积指标（参数文件大小）、稳定性指标（多次推理方差）。

延迟测量有个细节：要在设备温度稳定后再测，连续跑几十次，取平均值或p95，不要只跑一两次就下结论。CPU/GPU的降频和缓存预热对延迟影响很大，我见过有人在设备刚启动时测延迟，数据忽高忽低，根本不能作为优化决策依据。建议编写一个自动化基准脚本，锁频率、预热、循环测量，把结果以表格或JSON形式归档。

回归评估不只是为了验证自己改对了，更重要的是为了后面“换人继续优化”时能快速对比。压缩项目通常周期不短，中间会换人交接，稳定的评估基线能让新人快速定位问题所在。这一点我在维护多个模型压缩任务时深有体会：没有基准，等于闭着眼睛改代码。

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

6.1 剪枝后精度掉点严重

剪枝后模型精度崩掉，是最常见也最打击人的问题。我按排查优先级整理出了三个主要原因。

第一，剪枝比例太大。很多朋友照着教程一把梭，直接剪50%，结果精度掉5个点以上。建议从10%到20%的小比例开始，观察每增加10%的剪枝比例带来的精度变化曲线，找到“临界值”，在临界值附近再细调。这个曲线每个模型都不一样，凭经验预设往往是错的。

第二，残差结构没处理好。ResNet这类结构，如果shortcut分支和主分支裁剪的通道不对齐，模型结构都会出问题，更别提精度了。我在实践中给所有参加残差对齐的卷积层统一建立“通道分组”，按分组做对齐裁剪。如果出现维度不匹配的诊断错误，优先检查这块。

第三，微调策略不当。剪枝后直接用大学习率训练，或微调epoch太少，精度恢复不够。更隐蔽的问题是只在部分层上微调，而把其他层冻结了。剪枝理论上会改变所有层的特征分布，全层微调常常比只调尾部效果好得多。建议微调时全层放开，配合较小的学习率。

6.2 剪枝/量化后推理速度没有提升

压缩完看延迟毫无变化，甚至变慢了，这种项目我也接过几个。原因往往不在压缩算法本身，而在硬件和推理框架的适配。

剪枝速度没有提升，十有八九是因为“结构化剪枝没有真正落在有效计算路径上”。如果框架还在用稠密矩阵计算，通道虽然少了，但算子依然按原始矩阵运算执行，等于没剪。这种情况需要检查推理框架是否真正支持动态形状推理，或者能否导出实际裁剪后的计算图。另一个常见问题是裁剪后通道数不均匀，导致内存访问不连续、缓存命中率低，速度自然上不去。可以尝试把保留的通道数对齐到硬件友好的偶数，比如8的倍数。

量化后速度没有提升，则要先检查算子是否真的跑到INT8内核上了。很多框架会在算子不支持量化时静默回退到FP32，表面上看模型量化了，实际关键算子还是浮点运算。建议在推理日志中打开算子统计，逐一确认每个算子使用的是INT8还是FP32。此外，量化模型的批量大小也很关键，batch太小可能被框架启动开销淹没，延迟数字很难看。

6.3 问题速查表

我把之前提到的典型问题整理成速查表，开工前对照一遍，能省去大量调试时间。

6.4 压缩项目的提效习惯

最后分享一个团队协作层面的建议。压缩实验的变量很多，剪枝比例、微调epoch、温度参数、量化校准集大小，任何一个变化都会影响最终结果。建议从一开始就建立“实验参数记录表”，每跑一次实验，就把模型结构、压缩手法、参数配置、精度结果、延迟结果、体积结果全部记录下来。这个习惯在项目初期看似繁琐，但到了后期调优和复盘时，价值巨大。

我个人的习惯是使用固定格式的实验日志，每条记录包含：配置文件的commit哈希、压缩前后模型指标、推理环境（硬件、框架版本）、校准集构成。这样任何一个结果都能追溯到完全可复现的配置，而不是靠记忆。压缩项目反复试错是常态，有了完整日志，你会发现很多“玄学掉点”其实只是某一个参数被悄悄改了。

写在最后：压缩本身也是一次“瘦身”

我实际做过好几个压缩项目之后，最强烈的一个体会是“压缩不是一次性的动作，而是迭代优化的循环”。整个流程可以总结为：先定位瓶颈，再设定量化目标，然后选择技术路线，动手实现，跑回归评估，记录结果，再回到定位瓶颈这一步重新审视。很多时候，经过两三轮迭代，才能找到精度和速度的最优点。

还有一个小技巧想分享给读者：剪枝和量化的组合收益，通常不是加法而是乘法。剪枝把计算量降了一半，量化又把每次计算的单位开销降了一半，两者叠加之后，延迟往往不是降50%，而是能降到原来的四分之一甚至更低。所以当单个方法无法满足目标时，别急着把某个方案的参数推到极限，先想想能不能叠加另一个维度的优化。压缩的本质不是把某一个操作做到极致，而是让模型在多个冗余维度上同时“瘦身”。