在一台日常使用的手机上跑视觉模型，更容易暴露问题的常常不是存储，而是连续推理后的发热和掉电。模型文件看起来不大，运行时却要反复搬运权重、占用内存带宽，还要和相机、屏幕、系统调度抢资源。这时谈模型压缩，如果只盯着“文件小了多少”，很容易把问题问偏。
先问省什么，再问怎么压
模型压缩常被当成一个体积问题，但端侧部署的约束至少有三层：存储、运行时内存和计算开销。剪枝减少连接，量化降低数值位宽，蒸馏让一个小模型模仿大模型的输出，它们作用的位置并不相同。量化可能让权重更容易搬运，却未必减少某些算子的耗时；剪枝能改变稀疏结构，但若硬件和推理库不配合，节省可能停在纸面。蒸馏更微妙，它改变的是训练目标和模型容量，不只是给原模型“瘦身”。
因此，模型压缩的起点不该是选一种方法，而是列清楚约束：目标设备的内存带宽够不够，首帧延迟是否敏感，长时间运行会不会降频，模型更新频率有多高。约束不同，压缩策略的侧重点也会变。
精度之外，还有维护成本
压缩带来的误差并不总以“准确率掉了多少”呈现。它可能表现为某些输入上的不稳定，比如低照度图像、带噪声的语音，或者长尾类别上的置信度漂移。更麻烦的是，这些问题未必在离线评测中暴露，却会在真实设备的连续运行中出现。于是，压缩后的模型需要更细的回归测试和线上监测，不能只看一个平均指标。
另一个容易被忽略的成本是工具链。一个压缩模型能否顺利导出、编译、在目标芯片上跑起来，往往比压缩算法本身更耗时间。若团队每次换设备都要重做一轮适配，压缩省下的算力可能被工程开销抵消。对产品团队来说，可维护性、可复现性和回滚路径，和压缩率一样需要写进方案。
压缩不是终点，而是部署的一部分
模型压缩更像是部署设计的一部分，而不是训练结束后的补救动作。若在训练阶段就考虑目标硬件的算子支持、内存布局和量化友好性，后续压缩会少一些反复。反过来，压缩结果也应反馈给训练：哪些层对位宽敏感，哪些结构在设备上不划算，这些信息能帮助下一轮模型设计。
所以，看到“模型变小”时，不妨多问一句：省下的是存储、带宽、时延，还是只是报表上的数字？答案不同，压缩是否值得，也会有不同的判断。