在会议室里演示语音助手，网络通畅时一切顺畅；把同一套模型装进离线设备，风扇开始响，响应慢半拍。这时候团队才会认真讨论模型压缩——原因很实际：内存和功耗都有硬性限制，不会因为演示好看就放宽。
压缩并不等于把文件变小
一个常见的误解，是把模型压缩理解成“另存为小一号”。它真正改动的是计算方式和数值表示。量化把权重从较高位宽换成较低位宽；剪枝删掉贡献接近零的连接；蒸馏让小模型去模仿大模型的输出分布；低秩分解把大矩阵拆成两个较窄的矩阵相乘。这几种做法的目标并不相同：量化省带宽，剪枝省算力，蒸馏省结构，分解省参数。混着用很常见，但每叠加一层，误差也在叠加，调参的人得清楚自己正在拿哪一项换哪一项。
掉的那几分，常常掉在要紧处
平均指标好看，不代表能上线。压缩带来的退化往往集中在长尾输入上：口音重的语音、光线差的图片、结构少见的句子。评测集上掉一点点，在真实场景里可能表现为某一类请求整段失效，而这类请求恰好来自付费用户。所以做模型压缩时，我更愿意先翻失败样例，而不是先盯总体分数。把退化样本按类型分开看，常常能反过来指导该保留哪些层、该对哪部分权重更宽容。
硬件决定了能压到哪一步
同一个量化方案，在不同芯片上的收益可能差很远。有的加速器对低位宽有原生支持，有的需要额外的指令拆解，跑起来反而更慢。因此压缩方案很难脱离部署目标单独设计。先确认跑在什么设备上、推理框架支持哪些算子、内存带宽大概是什么量级，再回头选方法，通常比先压完再找地方跑要省事得多。这也解释了一个现象：同一篇方法在不同团队手里效果不一样，差别常常不在算法，而在部署链条。
有些情况下不值得压
如果模型只在服务端运行、延迟预算宽松，压缩带来的收益有限，维护两套模型的成本反而更高。如果任务对数值精度敏感，压缩引入的偏差需要额外的校准和回归测试，这部分工作量常被低估。还有一种情况更容易被忽略：模型仍在快速迭代时过早压缩，等于把优化工作绑定在一个随时会变的版本上，下一版权重一换，前面的调优又得重来。
我更倾向于把模型压缩看成一份工程取舍的记录：为了换回多少内存、延迟和成本，放弃了多少精度，这个交换在什么条件下成立。写清楚这些条件，比压出一个更小的文件更有价值。