一个常见的开发场景是：模型在实验环境里跑得不错，等到要放进客户的边缘设备，才发现内存不够、延迟超标、功耗也压不下来。于是团队临时加一轮模型压缩，剪枝、量化、蒸馏轮番上阵，指标勉强达标，但线上表现开始变得难以解释。问题往往不在压缩技术本身，而在于它被安排得太晚。
压缩不是收尾，而是设计的一部分
把模型压缩放在训练完成之后，等于在既定结构上做减法。减法的空间有限，而且每一步都在改变模型的行为边界。剪枝去掉一部分权重，量化把浮点换成低精度，蒸馏让一个小模型去模仿大模型的输出分布——这些动作都会让模型偏离原来的解，只是偏离多少、偏向哪里，常常缺乏足够的观察。
更合理的做法，是在确定部署约束时就把它纳入考虑。目标硬件支持哪些精度、内存预算有多少、可接受的响应时间是什么量级，这些信息如果能在模型设计阶段进入讨论，压缩就不再是补救措施，而是一种约束条件下的正常选择。
三种路径，各自的代价不一样
剪枝的思路是去掉对输出影响较小的连接或通道，换取更小的参数量和更快的推理。它的麻烦在于稀疏结构未必能被硬件高效利用，名义上的压缩率有时换不来实际的加速。
量化把高精度数值映射到低位宽表示，收益直接，工程上也相对成熟。但低精度会放大数值误差，对分布敏感的层尤其需要留意。校准数据选得不对，量化后的模型可能在某些输入上表现正常，在另一些输入上却明显失准。
蒸馏则是换一个更小的模型去学习大模型的输出，包括那些软标签里的相对关系。它不直接缩减原模型，而是转移能力。代价是训练成本上升，而且学生模型的上限受自身容量限制，不是所有任务都能靠蒸馏补回来。
这三种方式经常被组合使用，但组合不等于叠加收益。每加一层变换，误差就可能累积，验证的复杂度也随之上升。工程上更稳妥的做法是一次只改动一个变量，把每次变化带来的影响记录清楚。
压缩之后，怎么确认它还是原来的模型
只看总体准确率是不够的。压缩带来的退化往往集中在长尾样本、边界输入或者特定类别上，平均值会把这些问题平均掉。更有效的做法是分层看指标：对关键场景单独评估，对容易出错的输入构造针对性测试集，观察压缩前后的差异是否落在可接受范围内。
另一个容易被忽略的环节是行为一致性。模型压缩之后，输出的分布可能发生变化，即使类别判断没变，置信度的含义也可能变了。如果下游系统依赖这些分数做阈值决策，就需要重新校准，而不是沿用原来的阈值。
- 记录压缩前后的逐层误差，定位退化发生的位置。
- 对关键输入单独建测试集，不混在总体指标里。
- 重新检查置信度阈值，避免下游逻辑失效。
- 保留原始模型作为对照，便于回溯问题。
边界在哪里
模型压缩有它解决不了的问题。如果任务本身需要较大的表示能力，压缩到某个程度之后，退化会急剧出现，这时候继续调参的收益很低，应该回到任务定义和模型选择上重新考虑。另一个边界是硬件适配：压缩方案要和目标平台的算子支持匹配，否则理论上的收益在实机上可能落空。
所以它更像一个需要前置的工程决策，而不是一个可以随时调用的后处理工具。把约束说清楚，把验证做扎实，压缩才能成为可预期的环节，而不是上线前的一场赌博。