在地铁闸机前举起手机，人脸识别转了两圈才通过；车载语音助手听完指令，停顿半秒才回应。开发者把模型文件从原始体积缩到可接受范围，设备仍然会在某些时刻卡一下。这个现象提醒我们，模型压缩不是把文件变小就结束，它把问题从存储转移到了计算现场。
文件变小，等待没有消失
压缩后的模型通常要经过格式转换、算子融合、内存布局调整，才进入推理引擎。文件体积下降，运行时却可能因为反量化、访存模式变化或算子回退产生额外开销。设备端还要和相机、麦克风、显示管线争抢资源，某个环节抖动，用户感知到的就是一次停顿。模型压缩在这里像一次重新布线：线短了，接头和拐弯未必少。
几种手段，各自带着约束
常见做法可以放在一张工程清单里看：
- 量化把权重或激活映射到有限位宽，收益常出现在存储与带宽侧，代价是数值误差和校准成本；
- 剪枝去掉部分连接或结构，改变稀疏模式后，硬件能否顺畅执行才是关键；
- 蒸馏用另一套训练信号约束输出，流程涉及训练资源与数据分布；
- 矩阵分解把权重矩阵拆成若干小块，推理时的合并与访存需要一起考虑。
这些手段并不存在通用答案。一个方案在云端GPU上跑得通，换到端侧NPU，可能因为算子支持不全而退回CPU执行。压缩强度、校准集、层间策略都要围绕目标设备重做。把模型压缩当成一次离线导出，容易漏掉部署侧的适配工作。
把评估放回设备现场
讨论压缩效果时，体积是一条线，延迟、功耗、内存峰值和输出稳定性是另外几条线。端侧场景里，平均延迟会掩盖偶发卡顿，峰值内存会决定应用能否在后台存活，连续调用后的温升会影响持续时间。稳妥的做法，是在目标设备上跑一段接近真实使用的输入序列，记录每层耗时、算子回退和内存分配，再决定压缩策略。只盯文件大小，容易把问题推到用户面前。
留一点回退空间
模型压缩进入产品后，还需要保留可观测性和回退路径。端侧设备型号分散，系统版本和驱动差异会放大压缩带来的不确定性。工程上可以准备分层开关：某类算子异常时切回未压缩分支，或者对特定输入启用保守路径。这样的设计不追求把模型压到某个极限，而是让压缩后的系统在真实环境里可解释、可维护。压缩的边界，往往不在算法本身，而在设备、输入与运维共同构成的现场。