晚上给手机语音助手发一句话，界面转了两圈才回应。用户看到的是“慢”，工程侧面对的却可能是另一串问题：模型权重要占内存，推理要读带宽，连续运行还要控制发热。端侧设备没有数据中心那样的散热和供电余量，于是模型压缩被频繁提起。
但模型压缩并不等于把文件压小。它真正处理的是计算图、参数量、数值精度和内存访问之间的关系。一个模型能装进设备，不代表它跑得顺；能跑起来，也不代表回答质量稳定。压缩的难点往往不在“变小”那一刻，而在变小之后，系统是否仍然可控。
先看约束，再看方法
如果瓶颈是存储和内存带宽，量化通常更直接：把浮点权重或激活值换成更低比特表示，减少读取成本。但低位宽会带来数值误差，某些层对误差敏感，可能需要保留更高精度。工程上常见混合策略，而不是整模型一刀切。
剪枝处理的是冗余结构。把不重要的连接、通道或注意力头去掉，理论上能减少计算量。不过稀疏结构不一定在通用硬件上自动变快，除非运行库和硬件支持相应的稀疏模式。否则参数量下降，实际延迟未必同步下降。
蒸馏则换了一个思路：让小模型学习大模型的输出分布或中间表示。它不直接删除结构，而是把“经验”迁移到更小的网络里。效果取决于教师模型、数据分布和训练细节，不能简单理解为小模型必然接近大模型。
- 量化：关注数值范围、校准数据和算子支持，适合内存与带宽受限场景。
- 剪枝：关注稀疏结构能否被硬件和推理引擎有效利用。
- 蒸馏：关注训练成本、数据覆盖和迁移目标，不只是模型尺寸。
压缩之后，问题才展开
模型压缩落地时，团队通常要同时看几件事：首包延迟、持续推理的功耗、内存峰值、输出稳定性，以及更新模型后的回归测试。压缩比例提高，可能换来更小的占用，也可能让长尾输入更容易出错。这个取舍很难用单一数字概括。
还有一个常被忽略的边界：压缩会改变误差分布。某些任务对平均精度不敏感，却对特定类别或边界条件敏感。上线前如果只测平均表现，容易漏掉局部退化。更稳妥的做法是把压缩模型放回真实链路，观察它在噪声输入、连续请求和低电量状态下的反应。
因此，模型压缩更像一项系统工程，而不是一次独立的算法操作。它需要算法、编译、硬件和产品侧共同确认：省下来的资源是否转化为可感知的体验，精度损失是否落在可接受范围，维护成本是否被低估。省什么、保什么，才是这道题真正要回答的部分。