把模型塞进手机、车机或摄像头时，先遇到的往往不是“聪明不聪明”，而是内存够不够、发热快不快、首字延迟能不能接受。模型在服务器上跑得通，不代表在端侧也跑得顺。模型压缩因此出现：它不改变任务定义，而是重新安排参数、计算和存储的分布，让同一套能力更贴近有限硬件。
现场先撞上的是带宽和功耗
推理时，很多时间花在搬运权重和激活值上，算力反而不是唯一瓶颈。内存带宽有限，缓存装不下，芯片就得频繁访问外部存储，延迟和功耗随之上升。模型压缩的一个直接目标，是减少需要搬运的字节数，或减少参与计算的连接数。对离线设备而言，这往往比追求更高理论算力更贴近部署现实。
三条常见路径，各自压的是不同东西
- 剪枝：去掉贡献有限的连接、通道或结构块，让网络变稀疏。结构化剪枝对硬件友好，非结构化稀疏则要看运行库是否接得住。
- 量化：把浮点权重和激活值换成低比特表示，减少存储占用，也可能借助整数运算提速。难点在异常值、激活范围和校准数据分布。
- 蒸馏：让小模型学习大模型的输出分布或中间表示。它传递的不只是标签，还有类别之间的软关系。
这些方法经常叠加使用，但叠加不等于免费。剪枝后重新训练、量化后校准、蒸馏时选择教师信号，都会引入额外工程成本。模型压缩真正考验的，是能否把精度损失控制在业务可接受范围内，而不是把文件体积压到某个数字。
精度不是唯一账本
一个压缩后的模型，离线评测可能只掉一点指标，上线后却可能在某些长尾输入上变得不稳定。原因不神秘：量化误差会改变激活分布，剪枝可能削掉低频但关键的模式，蒸馏则可能把教师模型的偏差一起继承。因此，评估不能只看平均准确率，还要看分场景表现、鲁棒性和失败样本。模型压缩不是一次性的格式转换，更像一次需要回归测试的部署改造。
还有一个常被忽略的边界：压缩带来的收益取决于硬件和运行时。同样的稀疏模型，在支持稀疏计算的加速器上可能省下时间，在通用处理器上却未必。量化也是如此，低比特格式能否被算子库高效执行，决定了它只是省存储，还是也能省延迟。
先问清楚要换什么
做模型压缩之前，先把约束写清楚：是内存放不下，还是首屏延迟超标；是功耗受限，还是批量吞吐不够。不同约束对应不同手段。若只是存储吃紧，量化可能已经够用；若计算量本身过大，剪枝或结构重设计更对路；若缺少标注数据，蒸馏可以提供一条迁移路径。判断标准不该是“压得多狠”，而是“换来了什么，又付出了什么”。
这类改造的工程价值，往往藏在那些不显眼的部署细节里：一次校准集选择、一次算子回退、一次失败样本复盘。它不制造新的智能，却决定了已有智能能否落到真实设备上。需要把这笔账算清楚，而不只是盯着压缩率数字。