一台装在产线旁的边缘盒子，算力有限，内存也有限，却要跑一个原本在数据中心里训练出来的视觉模型。工程师的第一反应往往是：压一压。这个“压”，就是模型压缩的日常起点。它不是学术论文里的抽象名词，而是很多团队在部署阶段绕不开的一道工序。
先搞清楚被什么卡住
模型压缩常被当成一个统一动作，实际上它要解决的问题并不相同。有的是推理延迟超标，单帧处理时间压不下来；有的是内存装不下，权重加载就失败；还有的是功耗受限，设备靠电池供电，不能长时间满负荷运算。约束不同，压缩策略的侧重点也不同。
如果延迟是瓶颈，减少计算量更关键，剪枝和结构简化会更直接；如果内存是瓶颈，降低参数存储位宽往往更有效，量化就成了主要手段。反过来，若只是想把一个能力较强的模型迁移到轻量结构上，知识蒸馏的思路更合适。把这三者混为一谈，容易在错误的方向上反复调参。
三种手段，各有各的代价
剪枝的思路是去掉模型中贡献较小的连接或通道，让网络变稀疏。听上去很直观，但稀疏并不自动等于加速。很多硬件对稀疏结构的支持有限，剪完之后参数少了，实际推理未必更快，反而可能因为访存不规则而变慢。真正落到部署，结构化剪枝通常比非结构化剪枝更容易获得收益。
量化则是把浮点权重和激活值换成低精度表示。它带来的收益比较实在：存储占用下降，访存带宽压力减轻，部分硬件上还能启用更快的整数运算。但量化会引入误差，尤其是激活值的动态范围在不同输入下波动较大时，校准做得不细，精度掉得会比预期明显。工程上常见做法是保留部分敏感层的高精度，其余层压缩，用局部妥协换整体可用。
蒸馏不直接改结构，而是让小模型去学习大模型的输出分布。它的好处是目标明确，小模型可以按部署条件重新设计。难点在于数据和训练成本：蒸馏需要足够的样本，也需要调好温度等超参数，否则小模型学到的只是表面模仿。它更像是重新培养，而不是简单裁剪。
压缩之后，问题才刚开始
很多团队在模型压缩完成后松一口气，但真正的麻烦常在之后出现。精度指标在验证集上看着还行，上线后遇到分布偏移的输入，误差会被放大。压缩模型对输入扰动往往更敏感，边界样本上的表现容易退化。这时候需要的不是再压一轮，而是回到数据侧，确认训练分布和实际场景是否匹配。
另一个容易被低估的是维护成本。压缩后的模型结构可能变得不规整，导出、算子兼容、后续微调都会增加复杂度。有的团队为了省一点推理开销，把模型改得难以复现，等到需要迭代时又得从头再来。压缩方案是否可持续，和压缩率本身同样重要。
还有一点值得提醒：不是所有场景都值得压缩。当设备算力尚有余量，或者模型规模本来就不大时，投入工程资源去做精细压缩，收益可能有限。判断标准应该回到业务约束上——延迟、内存、功耗、成本，哪一项真正卡住了，就针对哪一项动手。
把它当成一次设计，而不是一次修补
更合理的做法，是在模型设计阶段就把部署条件纳进来。训练时考虑目标硬件的算子支持，选择对量化友好的结构，预留可裁剪的冗余通道，这些都能让后续的模型压缩少走弯路。压缩不该是上线前的临时补救，而应是训练与部署之间的一条常规链路。
说到底，模型压缩的核心不是“变小”，而是“在给定约束下保留尽可能多的有效能力”。它要求工程师清楚自己舍弃的是什么，也要清楚舍弃之后系统还能不能稳住。想明白这一点，压缩才不至于变成一场只看体积数字的自我安慰。