深夜的实验室里，一块开发板跑不动刚训好的模型。不是算力不够，是内存装不下。多数团队先想到换硬件，然后才回头看模型本身。后者通常更便宜，也更麻烦。
模型压缩这个词听起来像一个动作，实际上是一组手段的统称：把浮点权重换成低比特整数、剪掉贡献微弱的连接、用一个小网络去模仿大网络的输出、把权重矩阵拆成两个更瘦的矩阵相乘。它们解决的问题不同，代价也不在同一个地方。
省下来的空间，都有出处
量化常被拿来先试。把 32 位浮点换成 8 位整数，权重体积和带宽压力会立刻下降，不少推理芯片对整数运算也更友好。但数值精度不是均匀损失的：有些层对舍入误差很敏感，尤其是输出分布本身就窄的那些层。校准用的样本如果和线上数据分布对不上，误差会在层与层之间慢慢累积，最后表现为某些输入上莫名其妙的输出。
剪枝的逻辑更直观——不重要的连接删掉。问题在于“不重要”是相对于训练数据说的，删完之后网络往往要再训练一轮才能恢复。而且稀疏结构能否真的换来速度，取决于底层算子是否支持。纸面上很高的稀疏比例，落到实际硬件上可能只省了存储，没省时间。
蒸馏换了个思路：不去改原模型，而是训练一个小模型去学它的行为。这招在有大量无标注数据时比较好用，但它有天花板——小模型的容量决定了它能学到多少，教师再强也传不过去。
压缩率不是目标
工程上容易走偏的地方，是把压缩率当成 KPI。压缩率好看，任务指标掉点，这笔账最后还是要还。更合理的问法是：这个任务能容忍多大的行为偏移？一个离线批处理的分类任务，和一个实时交互的语音前端，容忍度差得很远。前者的误差可以靠后处理兜住，后者一旦延迟抖动或识别漂移，体验立刻塌。
所以评估要回到任务本身：不是看权重少了多少，而是看压缩后的模型在你真正关心的那批输入上，输出变了多少、变得可不可接受。
另一个常见的顺序错误，是把模型压缩安排在部署前的最后一步。等到模型结构、输入分辨率、前后处理都定死了再动手，可调整的空间已经很小。如果在训练阶段就把量化感知、结构约束一并考虑进去，后面的返工会少很多。
说到底，模型压缩是一次预算分配：算力、内存、延迟、精度，几个口袋里的钱互相挪。没有哪一项可以无限让步，也没有一套参数能通用。难的不是调用某个压缩工具，而是判断哪一部分可以粗糙、哪一部分必须精确。这个判断没法外包给工具，只能由做这个产品的人自己给出。