把一个已经跑通的模型塞进更小的机器里，工程上常见的反应是“压一下”。真正动手时才会发现，模型压缩并不是把文件改小那么简单：参数少了一半，延迟未必减半；显存够用了，吞吐可能没动。这些落差，往往决定项目是省下一笔开销，还是多出一轮返工。
三个指标不是一回事
参数量、显存占用、单次推理延迟，经常被混着谈。它们之间没有固定比例。压缩改变的是计算图里的形状和数值精度，而硬件执行时看的是内存带宽、并行度、算子是否被支持。一个层被削薄之后，如果剩下的计算无法填满硬件的并行单元，时间并不会按比例下降。
所以讨论压缩收益时，先问一句：省下来的显存，最后被谁用掉了？如果答案是“腾给更大的批处理”，那收益体现在吞吐上；如果只是让监控面板好看，这笔账就要重算。
量化最先被用，也最容易出问题
把浮点换成低比特整数，改动小、收益直接，通常是最先尝试的手段。问题多出在校准环节：用来估计数值范围的样本如果和线上分布不一致，误差会集中在少数层上爆发。逐层检查、对敏感层保留更高精度，是常见做法，代价是执行路径变复杂，某些算子缺少低比特实现时还会回退，把收益吃掉一部分。
剪枝的账要放到硬件上算
纸面上删掉乘加，不等于执行时真的变快。非结构化稀疏如果硬件不吃，剩下的可能只是额外的索引开销。按通道、按头做结构化裁剪，形状对齐，执行路径才有机会缩短。删完之后还要留出微调的余量，否则精度掉下去，前面的节省又会被重新训练的成本追平。
蒸馏换的是时间与数据
让小模型去学大模型的输出分布，前提是教师本身足够稳定，且训练数据与线上分布接近。否则小模型学到的是教师的偏差，在真实输入上表现得更脆。这条路不省数据，也不省验证，只是把成本从推理端挪到了训练端。
目标函数写错，压缩就白做
把参数量当成考核指标，是最常见的偏差。参数量好看的模型，端到端延迟可能并没有改善。更务实的顺序是：先在真实设备上测出瓶颈在哪一段，再决定压什么。如果瓶颈在数据预处理或调度，模型压缩能带来的变化有限。
另一个容易被忽略的点是验证成本。压缩后的模型需要重新跑一遍评测集和线上回流，这部分开销要计入总账。对迭代频繁的模型，反复压缩再验证的代价，可能高于直接换一台更合适的机器。
什么时候不该压
模型还在快速变化、精度余量很薄、或者任务对细微偏差极为敏感时，等一等通常更划算。压缩是一项工程取舍，不是默认动作。它真正有价值的地方，不在于把模型做小，而在于把有限的算力和显存重新分配到更值得的地方——比如更长的上下文、更密的检索，或者干脆留给线上流量的波动。