把模型放进手机、摄像头或车载设备，工程师常会先碰到同一组约束：内存不够、算力有限、功耗也不能放开。于是“先压一压”成了默认动作。但模型压缩真正难的地方，往往不在压下去的那一步，而在压完之后——你还能不能解释清楚，它为什么仍然有效。
变小是结果，不是目的
围绕模型压缩，工程上常见几类手段：量化把权重和激活从较高精度换成较低精度，剪枝去掉看起来贡献不大的连接或通道，蒸馏让小模型去拟合大模型的输出，低秩分解用更少的参数近似原来的计算。这些方法可以叠加使用，本身并不神秘。它们共同的前提是：模型里存在冗余。而这个前提是否成立，取决于任务、数据和部署环境，不能一概而论。
所以“压到多小”不是一个可以单独回答的问题。更实际的说法是：在给定的延迟和内存预算下，精度损失能不能被接受，损失又出现在哪些输入上。前者靠离线评测能看出来，后者往往要等模型上线、遇到真实流量才暴露。
压缩之后，误差会挪位置
一个常被低估的现象是，压缩并不会均匀地削弱模型，它更像是把误差重新分布。某些样本上几乎看不出差别，另一些样本上却可能出现明显偏移。做模型压缩的人如果只盯着整体指标，很容易忽略这种局部变化；而这些变化恰好可能落在业务真正在意的那部分输入上。
因此评测集的设计比压缩算法本身更值得花时间。除了常规验证集，还需要覆盖边缘情况、长尾输入和上线后可能出现的分布偏移。否则压缩带来的风险会被平均数字掩盖。
维护成本也是成本
压缩还会改变模型的维护方式。原始模型更新一版，压缩流程通常要跟着重跑：重新校准量化参数、重新确定剪枝结构、重新做蒸馏。如果这条链路没有自动化，压缩就会从一次性优化变成持续负担。另一个容易被忽略的点是可解释性——结构被改动后，排查问题的路径也变了，原先熟悉的调试手段未必还适用。
我倾向于把模型压缩看成一个约束优化问题，而不是单纯的体积缩减。它要求团队同时回答三件事：能接受多少精度损失、愿意承担多少维护工作、以及是否保留了回退方案。这三件事没有统一答案，也不存在一劳永逸的配置。
边界在哪里
有些场景适合压缩：输入分布相对稳定、延迟敏感、硬件资源紧张。也有些场景不太适合，比如任务本身对细微差异很敏感，或者模型规模还没到需要压缩的程度。判断依据应该是实测的收益与代价，而不是“别人都在压”。
模型压缩的价值，归根到底体现在它能否让一个模型在真实环境里稳定工作，而不是体现在压缩比这个数字上。想清楚要丢掉什么、能承受丢掉什么，比选哪种算法更靠前。