假设一台旧手机要离线运行语音助手。屏幕点亮后，用户不会关心参数规模，只会关心一句话说完多久有反应、机身是否发烫、电量掉得快不快。模型压缩常被描述成“把模型变小”的手艺，真正落到这个场景里，它更像在有限的内存带宽、存储空间和散热条件之间重新排布计算。
把模型做大，通常意味着表达能力变强，但部署成本也跟着上升。内存访问、算子调度、缓存命中，这些工程细节会决定一次推理是否顺畅。压缩之所以必要，不是单纯追求文件体积，而是让模型适应设备侧的约束：读得少、算得少、等得少。这个目标听起来直接，做起来却要面对精度损失、实现复杂度和维护成本。
几种常见手段，解决的不是同一个问题
量化改变数值表示，让权重或激活以更低位宽参与计算；剪枝去掉对输出影响较小的连接或结构；知识蒸馏让一个小模型学习大模型的输出分布；低秩分解则试图用更紧凑的矩阵近似原有变换。它们经常被放在同一个工具箱里，但作用点不同。量化偏向存储与计算效率，剪枝偏向稀疏结构，蒸馏偏向训练过程，分解偏向矩阵形态。混用时，误差可能叠加，调试成本也会上升。
- 量化要关注校准数据和异常值，否则误差会在某些输入上放大。
- 剪枝后的稀疏结构未必能被硬件直接利用，形式上的稀疏不等于实际加速。
- 蒸馏依赖教师模型的质量与任务匹配度，迁移不好会留下难以解释的偏差。
- 低秩分解对层结构敏感，拆得过头会伤到关键表示。
模型压缩真正难的地方，往往不在压缩算法本身，而在评估。离线指标好看，不代表端侧体验顺畅；平均误差可接受，也不代表长尾输入稳定。部署前需要把延迟、内存占用、能耗和任务指标放在同一张表里看，还要留出回滚和分层降级的空间。否则，压缩后的模型可能只是把问题从服务器搬到了用户手里。
边界比技巧更值得先想清楚
讨论模型压缩时，容易陷入只追求更小体积的惯性。实际工程里，压缩比例是一个受业务约束的变量：设备内存预算、响应时限、更新频率、可接受的精度波动，都会改变答案。对需要频繁更新的模型，压缩流程要能复现；对长周期维护的设备，压缩后的可解释性和故障定位同样重要。只盯着体积，容易忽略这些隐性成本。
另一个常被低估的点是数据分布。压缩会改变模型对输入的敏感方式，原本稳定的边界可能变窄。上线前的测试集如果过于干净，问题会被遮住。稳妥的做法是把真实使用中的噪声、口音、光照、网络抖动等因素纳入评估，哪怕测试规模不大，也要覆盖关键失败模式。模型压缩不是一次性的格式转换，而是围绕部署条件反复校准的过程。
所以，当有人问“这个模型能不能压到旧设备上”，实际的问法是：压到什么程度、在哪些输入上会退化、退化后如何兜底、维护成本由谁承担。把这些问题拆开，它才会从一句口号变成可执行的工程决策。