手机视频通话一会儿就温热，语音助手反应慢半拍，很多人先怪网络。可当推理被塞进设备本地，发热和延迟往往来自另一处：模型要搬动的权重、要占用的内存、要完成的计算，都挤在有限的电力和带宽里。模型压缩之所以被反复提起，不是因为模型天生越轻越好，而是因为端侧环境先给出了硬约束。
省下的不只是安装包
把压缩理解成“把文件变小”，只对了一半。安装包大小影响存储和分发，推理时真正吃紧的，常常是内存带宽和临时缓存。权重反复读取，功耗和延迟就会冒头。量化让数值表示更紧凑，剪枝减少冗余连接，蒸馏把一套行为迁移到较小的网络里，它们指向的都是同一件事：让一次推理少搬一点、少算一点、少等一点。
- 存储压力下降，应用更容易装进普通设备；
- 内存占用收敛，后台被系统清理的概率可能降低；
- 计算量减少，首字延迟和持续功耗有机会改善。
压缩也有代价
但压缩不是免费的。数值精度降低后，边缘样本出错概率会上升；剪枝过度，模型的稳定性会变差；蒸馏得到的较小网络，未必能完整继承原模型处理长尾输入的能力。麻烦在于，这些损失不一定在常规测试里暴露，却可能在口音、噪声、少见表达或极端光照下出现。因此，模型压缩更像一次有明确边界的工程取舍，而不是把模型交给某个工具就结束。
先定预算，再谈方法
实际工作里，先问清楚设备侧预算：可用内存、功耗上限、可接受延迟、最怕出错的场景分别是什么。不同答案会导向不同组合。有的场景需要压低峰值内存，有的看重持续运行时的发热，有的则不能容忍某类输入退化。先确定这些约束，再选择量化、剪枝或蒸馏，并保留一套贴近真实使用的回归测试，才不至于把问题从“跑不动”换成“偶尔答错”。
所以，模型压缩真正节省的，是工程团队对约束的尊重：知道哪里可以省，也知道哪里不能省。它不保证模型变聪明，只帮助模型在有限条件下完成该做的事。