一块开发板放在桌上，风扇没转，屏幕上跑着一个几亿参数的模型。旁边的人问：这么大的模型，怎么塞进这么小的内存？答案是模型压缩。这个词听起来像把行李抽真空，体积小了，东西还在。实际做起来，更接近搬家时决定扔什么、留什么，而扔掉的往往不是垃圾。
先弄清楚压的是什么
模型压缩不是单一技术，它更像一组手段的统称。常见路径包括剪枝、量化、知识蒸馏和低秩分解。剪枝删掉权重里接近零的连接，量化把浮点数换成低位整数，蒸馏让一个小模型去模仿大模型的输出分布，低秩分解则把大矩阵拆成两个更小的矩阵相乘。
这些手段针对的对象不同。剪枝动的是网络结构，量化动的是数值精度，蒸馏动的是训练方式。把它们混为一谈，容易得出“压缩一定掉点”或者“压缩一定无损”的结论，两边都不准确。
量化最容易被低估的地方
量化常被描述成“把 fp32 换成 int8，速度翻几倍”。这句话省略了前提：硬件是否真的支持低位整数运算，算子是否都被覆盖，激活值的分布是否适合直接截断。在实际部署里，一个模型的部分层可以量化，另一些层因为数值范围特殊，量化后误差明显放大，最后只能保留原精度。结果是混合精度方案，而非整齐划一的低位模型。
还有校准。量化需要一批样本估计激活范围，这批样本选得偏，模型在真实输入上的表现就会漂移。这一点在离线评测里不容易暴露，上线后才慢慢显形。所以谈模型压缩时，量化带来的收益要和校准成本一起看，而不是只看模型文件小了多少。
剪枝的悖论
剪枝的逻辑很直观：权重小的连接贡献小，删掉。但稀疏矩阵在通用硬件上不一定跑得快。删掉的是参数，留下的是不规则的内存访问模式，GPU 的并行效率反而可能下降。除非硬件和推理库对稀疏结构有专门支持，否则压缩后的模型文件变小，推理时间未必同步缩短。
这也是模型压缩落地时经常遇到的错位：指标上模型更小，工程上却更麻烦。真正决定部署可行性的，往往是算子支持、内存布局和批处理策略，而不只是参数量。
蒸馏换的是另一种成本
知识蒸馏不直接删参数，它训练一个结构更小的学生模型去逼近教师模型的输出。好处是学生模型可以按目标硬件重新设计，不必迁就原结构。代价是训练环节变重：需要教师模型的推理结果，需要设计温度参数和损失组合，还需要足够的训练数据覆盖教师的行为边界。
换句话说，蒸馏把成本从推理端挪到了训练端。对于只需要部署一次的离线场景，这笔账可能划算；对于频繁迭代的线上服务，重新蒸馏的开销要计入周期。
压缩的边界在哪里
一个务实的判断是：模型压缩解决的是资源约束，不解决能力约束。它能让一个模型在给定内存和算力下跑起来，但不会让模型理解它原本不理解的东西。压缩率越高，留给数值表达的余地越小，误差累积越难控制。到了某个点，继续压得到的收益，抵不过调参和验证投入的成本。
所以更合理的做法是先明确约束：目标设备的内存上限、可接受的延迟、能容忍的精度波动。然后再选手段，而不是先定一个压缩率目标再倒推方案。顺序反过来，往往会在部署阶段返工。
那块开发板上的模型最终跑起来了，风扇依然没转。但代价是有的：一部分层保留了原精度，校准样本重选了两轮，推理库也换了版本。压缩不是让模型凭空变轻，而是把重量从一个地方挪到另一个地方。看清楚挪去了哪里，比记住压缩率更有用。