一台用了三四年的轻薄本，风扇一转起来就像在抗议，还是有人想在上面跑本地模型。想法很朴素：把模型压缩一下，参数少一点，内存占用低一点，也许就能用。真动手之后才会发现，难点不在于能不能压，而在于压完之后，你还认不认得它。
省下来的到底是什么
模型压缩听起来像是一个动作，实际上是一组取舍。剪枝去掉一部分连接，量化把高精度浮点换成更窄的表示，蒸馏让小模型去模仿大模型的输出分布，低秩分解则假设权重矩阵里存在可以合并的方向。它们的共同前提并不是“变小”，而是“有一部分信息可以不要”。
这个前提在大模型上常常成立：参数越多，冗余越多，删掉一些，整体表现未必看得出变化。但“看不出”取决于你用什么看。拿一套规整的评测题去测，分数可能稳稳的；换成用户真实的输入，比如带错别字、带上下文指代、带口语省略的表达，能力下降的地方就暴露出来了。
损失往往藏在长尾里
量化的误差会累积，单层看不出来，几十层叠上去，某些少见词元的概率分布就会被抹平。剪枝带来的稀疏结构，未必被硬件友好地支持，名义上少了参数，实际延迟没降多少，这类落差在工程里并不少见。蒸馏的问题更隐蔽：学生模型学到的是教师的输出习惯，包括那些似是而非的自信。教师错的地方，它也可能照单全收。
所以判断压缩是否成功，只看平均表现不够。得挑那些样本少、表达杂、边界模糊的输入去看，那才是模型真正吃力的地方。
它更像维护，而不是一次性的手术
模型会迭代，线上流量会漂移，压缩时选定的校准集，过几个月可能就不再代表真实请求的分布。这意味着模型压缩不是交付前的一道工序，而是一项要跟着模型版本走的维护工作。把它当成一次性的手术、做完就归档，后面再回头排查，代价通常更高。
动手前值得先回答的三个问题
- 压完之后，用哪批数据、哪套指标来判定“还能用”？这套指标和业务真正在意的目标是不是同一件事。
- 收益究竟落在延迟、内存还是成本上？如果瓶颈在别处，压缩可能只是把资源从一处挪到另一处。
- 出了问题能不能回退？原始模型和对照评测的通道有没有留着。
把模型放进原本放不进去的设备，这件事本身有价值，但价值来自“能落地”，不来自压缩比例这个数字。我的看法是：先把度量做对，再决定压到哪一步；顺序反了，省下来的算力往往又会以另一种方式还回去。