把模型放进一台没有独立显卡的设备，工程团队很快就会遇到一个朴素问题：内存放不下，延迟也不稳定。此时“能不能小一点”往往比“能不能再准一点”更急。模型压缩于是被推到台前，但它并不是一个按钮，按下去就能等比例缩小。
压缩动的是哪一层
从工程视角看，模型压缩大致在三个位置做减法。量化降低数值精度，让权重和激活占用更少空间；剪枝去掉不重要或可替代的连接、通道乃至结构；蒸馏则让一个小模型学习大模型的输出行为。三者常被混在一起谈，实际约束并不相同：量化依赖校准数据和硬件支持，剪枝会改变网络结构，蒸馏需要可用的教师模型与训练流程。
这也解释了一个常见误会：文件变小不等于推理就快。若运行环境对低精度计算支持有限，或稀疏结构无法被有效利用，压缩后的模型仍可能卡在同样的瓶颈上。模型压缩的目标不是把数字压到最小，而是让模型在给定内存、功耗和时延约束下保持可用。
先找不能动的地方
压缩最容易伤到的，往往不是平均表现，而是边缘输入。某些层对精度变化敏感，某些通道承载了长尾样本的信号，量化校准集若覆盖不足，问题会在上线后才显露。因此，评估不能只看一个汇总结果，还要看分场景表现、极端输入、内存峰值和尾延迟。
- 量化前确认校准数据是否覆盖真实输入分布，别只拿干净样本试。
- 剪枝后检查结构是否被目标硬件真正利用，避免纸面稀疏。
- 蒸馏时保留失败样本的对比，别让小模型只学会常见路径。
边界比技巧更值得说
部署现场很少存在通用配方。摄像头端、车载设备、离线终端，对功耗、内存和响应时间的要求不同，可接受的精度损失也不同。一个压缩方案在实验室跑通，不代表在温度变化、内存碎片或并发请求下仍然稳定。工程上更可靠的做法，是把压缩当作约束翻译：先写清楚不能退让的边界，再决定量化、剪枝还是蒸馏，或者干脆换一个模型规格。
我的判断是，模型压缩的价值不在于制造“小模型”的神话，而在于把部署约束摆到桌面上。它提醒团队：精度、速度、内存和成本彼此牵制，任何压缩都要付出代价。真正需要回答的，不是压缩率能到多少，而是压缩之后，模型在真实输入上是否仍然可信。