把训练好的模型塞进一台内存紧张的设备，是不少算法工程师都会遇到的时刻。电脑上跑得通的模型，换到手机、摄像头或工控盒子里，可能连加载都费劲。于是“模型压缩”被提上日程。它听起来像把文件打包变小，实际工作却远不止改一个体积参数。
先看约束，而不是先看压缩率
端侧部署的约束通常来自几处：可用内存、推理时延、功耗，以及芯片对算子类型的支持。压缩之前，如果不把这些条件写清楚，很容易出现一种情况——模型确实变小了，但推理速度没有改善，或者精度在特定输入上明显波动。模型压缩不是孤立动作，它要和运行环境一起看。
一个常见的误区是把压缩率当成唯一目标。压缩率看起来直观，却可能掩盖后端的适配成本。比如某些量化方案需要硬件提供对应指令支持，剪枝后的稀疏结构也未必能被推理框架有效利用。文件小了，计算路径没有变短，收益就会打折。
几种思路，各自的边界
量化、剪枝、知识蒸馏经常被放在一起讨论。它们解决的问题并不完全相同。量化关注数值表示，用更低比特承载权重或激活；剪枝关注结构稀疏，去掉对输出影响较小的连接或通道；蒸馏则让一个小模型学习大模型的行为。工程上，这些方法可以组合，但每增加一层处理，评估成本也会上升。
- 量化要关注异常值分布和校准集是否贴近真实输入，否则局部误差可能被放大。
- 剪枝要关注硬件和框架是否真正支持稀疏收益，不能只看参数数量变化。
- 蒸馏要关注教师模型输出的稳定性，以及学生模型是否继承了不该继承的偏差。
这里没有一套通用配方。模型压缩的效果依赖任务、数据分布和部署栈。一个在图像分类上可行的设置，换到语音或检测任务，可能需要重新验证。把方法当成按钮，按下去就期待收益，往往会失望。
评估要回到真实输入
压缩后的模型不能只看离线验证集。真实输入往往更杂：光照变化、噪声、长尾样本、连续帧之间的差异，都可能让压缩误差暴露出来。评估时，除了任务指标，还应看时延分布、内存峰值和不同设备上的稳定性。若条件允许，保留一份与线上分布接近的回归集，比单次对比更稳妥。
另一个容易忽略的点是版本管理。压缩模型往往伴随预处理、后处理或校准参数变化，若没有记录这些细节，后续排查会变得困难。模型压缩不只是模型文件的事，它会把整条推理链路一起牵动。
把压缩当成一次工程取舍
更务实的做法，是先明确不可退让的指标，再决定压缩力度。若时延是硬约束，就从算子适配和内存访问入手；若存储是主要矛盾，再考虑更激进的表示方式。压缩之后，用同一套输入做回归，观察误差是否落在可接受范围，而不是只看平均值。
压缩正在从“把模型变小”的技巧，变成端侧系统设计的一部分。它需要算法、框架和硬件之间的沟通，也需要对失败案例保持耐心。省下来的不只是存储，还有对部署边界的理解。