去年冬天，一个朋友把模型往开发板上搬，第一版跑起来就卡在内存上。他盯着报错问我，是不是只能上模型压缩了。我说先别急，得看压完之后，原来那点判断力还剩多少。
这大概是很多团队都会撞上的时刻。训练阶段一路顺风，越靠近部署，算力和显存越是硬门槛。模型压缩不是新话题，只是被大模型重新推到了台前。
省掉的是哪一部分
常见的做法大致三条：
- 把权重从高精度换成更低的位宽，用更少的比特存同样的数值；
- 剪掉对输出影响有限的连接或结构，让网络稀疏一些；
- 让小模型去学大模型的输出分布，也就是蒸馏。
三条路方向不同，目标一致：把推理时要搬的数据量和要做的计算降下来。听着像纯工程活，其实每一步都在做取舍。量化引入数值误差，剪枝改变网络结构，蒸馏则高度依赖教师输出的质量。这些偏差在实验室的平均指标里常常被抹平，到了真实输入上，会以别的方式冒头。
压缩比不是越高越好
有个容易被忽略的点：压缩带来的损失不是均匀分布的。分类任务里，头部类别往往扛得住，长尾样本先出问题；生成任务里，短句看起来正常，长文本到后半段开始跑偏。也就是说，平均精度掉一个点，不代表所有输入都掉一个点。
所以真正要问的不是能压到多小，而是哪些输入不能出错。结构化输出、涉及数值计算的回答、需要保持格式一致的场景，对扰动更敏感；而一些粗粒度的意图判断，宽容度就高得多。这个判断必须回到业务本身，没法靠通用结论代替。
它更像训练流程的一部分
不少人把模型压缩当成部署前的最后一道工序，训练完、导出、压缩、上线。这个顺序省事，但代价是压缩阶段没有反馈回路。更稳妥的做法是让压缩参与评估：用贴近真实分布的数据重新跑一遍，看错误集中在哪，再决定是调压缩策略，还是回到训练端补数据。
还有一点常被低估——压缩后的模型需要重新建立信心。它在基准集上的表现说明不了太多，真正有用的是那些曾经让原模型犹豫的边界样本。这些样本往往不多，但决定了上线之后用户会不会觉得“这东西变笨了”。
能做与不能做
模型压缩能把一个原本放不下的模型塞进有限的硬件，这是它最实际的价值。但它不能让一个本身信息不足的模型凭空变准，也不该被当成绕过数据问题的捷径。如果压缩之后要靠大量后处理去修补输出，那多半说明压缩的粒度或位置选错了。
回到那块开发板。后来我们把输入分布重新梳理了一遍，只对一部分层做量化，剪枝留得保守，模型跑起来了，延迟也够用。它没有变得更聪明，但也没有在关键时刻掉链子。对多数落地场景来说，这大概就是压缩该有的样子：不追求极致，只求把该保住的保住。