一个训练好的模型，动辄几十上百亿参数。推理服务上线前，工程师常要做一件事：把它变小。这个过程被统称为模型压缩。听起来像打包行李，挤出多余空气就行，实际做起来远没有那么轻松。
压缩不是把文件变小
把模型文件从几个 GB 压到几百 MB，技术上并不难。难的是压完之后，模型在真实输入上的反应是否还和原来接近。参数被量化成更低的位宽，注意力头的权重被合并，层被裁掉一部分，这些操作都会改变模型内部的数值分布。某个原本稳定输出的判断，可能会在边界样本上开始摇摆。
所以做模型压缩的人，关注的从来不是体积本身，而是压缩前后行为的一致性。一个常见的做法是保留一小批校准数据，观察压缩后每一层的输出偏移，挑偏移大的地方单独处理。这本质上是在做取舍：哪些计算可以粗糙一点，哪些不能。
被删掉的是什么
参数里存的不是知识条目，而是统计规律。某些权重看起来很小，几乎不影响大部分输入，但可能在长尾场景里起着微弱却关键的作用。压缩算法通常依据某种重要性度量来决定去留，而这个度量本身是有偏的——它更擅长保护高频模式，对罕见输入不够敏感。
这就解释了为什么有些模型压缩后，在常规测试集上表现几乎不变，一到真实流量里就露怯。真实世界的输入分布比测试集更散，那些被压掉的微弱信号，恰好在某些边缘情况下是决定性的。
它什么时候真的有用
模型压缩的价值高度依赖部署条件。在端侧设备上，内存和算力都是硬约束，一个没法塞进手机的模型再准也没有意义。在需要低延迟响应的场景里，压缩换来的推理速度是实打实的体验改善。这类情况下，压缩不是可选项，而是前提。
但如果服务跑在资源充裕的集群上，把模型压小带来的收益就很有限。省下的显存可能只是让同一张卡多跑一个副本，而精度损失却要长期承担。这时候更值得问的是：为什么非要压？是成本压力，还是仅仅因为别人都在做。
一件需要持续观察的事
压缩不是一次性动作。模型上线后，输入分布会慢慢漂移，原本校准过的误差范围可能被突破。比较稳妥的做法，是把压缩后的模型当成一个新模型来对待，单独建立监控，单独做回归验证，而不是默认它继承了原模型的一切表现。
从这个角度看，模型压缩与其说是把大模型变小，不如说是在有限资源下重新定义模型的能力边界。边界画在哪里，取决于业务能容忍多少不确定性。这个问题没有通用答案，只能一个个场景去试。