机房角落那台边缘推理盒子装上去三年了，外壳积了一层灰。最近它开始间歇性卡顿，运维下意识觉得是硬件老化。查下来，卡顿是从模型换到新一代之后开始的：同一块板子，同一个散热条件，参数量大了不到一倍，推理延迟却明显跳了一档。换硬件要走采购和停机流程，于是讨论转向另一个方向——能不能先把模型本身弄轻一点。
模型压缩通常就是在这种时刻被想起来的。它不算新话题，但真正落到项目里，很少按计划排进流程，更多是被显存、功耗或交付周期逼出来的临时决定。
省下来的那部分，是从哪儿挪走的
工程上常见的做法大致三类。把权重从高精度浮点换成低精度整数，参数数量没变，但每个参数占的位宽少了，带宽和存储跟着降；去掉网络里贡献有限的结构，计算量随之减少；再或者让一个小模型去对齐一个大模型的输出，用容量换速度。三条路的共同点是，省下来的东西都不是凭空来的。
精度损失最容易被低估。公开测试集上的分数往往只掉一点点，因为那份数据干净、分布集中。设备装到现场就是另一回事：光线会变，输入会缺，传感器会漂。量化带来的误差会沿层累积，剪枝删掉的也许正是长尾场景里那点微弱却关键的响应。实验室里不到一个百分点的差距，落到每天处理上万帧的产线上，可能表现为某一类样本的集中误判，而这类问题在验收阶段很难靠抽样发现。
它其实是一次不太容易回退的决定
还有一个常被忽略的维度：可回退性。原始模型留着，压缩版本出问题时还能换回去；但不少团队为了省存储、省部署复杂度，把原模型归档甚至丢弃，等到现场反馈异常，手里已经没有可比对的东西了。更麻烦的是版本管理——压缩后的模型和原始模型的训练日志、评估记录如果对不上，后面再想做微调，基本等于从头再来。
所以我的看法是，模型压缩不该被当成交付前的收尾工序，交给某个人在最后两周赶出来。它更像一个架构层面的选择：如果一开始就清楚目标设备的算力边界和内存上限，模型结构、输入分辨率、层数这些决定就该往那个边界上靠，而不是先做一个大的，再想办法削。
验证要放回它将要生活的环境里
至于怎么判断一次压缩是否可以接受，比较务实的做法是换一套评估口径。不再只看整体准确率，而是看现场采集的那批难例在压缩前后的表现差异，看延迟的分布而不只是均值，看极端输入下会不会崩。这些检查做起来琐碎，成本却不比换一块板子高。
回到那台积灰的盒子，最后的处理是把量化版本重新在现场数据上跑了两周。延迟确实回来了，但一类低照度样本的误检率有所上升，最终没有全量替换，只在不涉及这类场景的工位上先用了。这大概就是模型压缩真实的模样：它不会凭空把模型变小，而是一次明确的交换，你得先想清楚拿什么去换。