设想一个离线识别功能被塞进手机相册：模型文件不算大，跑起来却让内存曲线陡然上升，连续拍照后机身发热，切到后台还可能被系统收回。团队最初以为把文件压小就能解决，真正上手后才发现，模型压缩要处理的是另一套账本。
文件变小，不等于跑得轻
模型体积只是表象。运行时占用的内存、算子调度、权重读取带宽、临时缓冲区，都会影响体验。一个文件更小的模型，若算子碎片多、访存不连续，端侧延迟未必下降。反过来，某些为部署友好的结构在压缩后反而更稳。所以模型压缩的第一步不是选工具，而是明确约束：是内存峰值卡住，还是首帧等待太长，或是持续推理让电量吃不消。目标不同，手法差别很大。
量化、剪枝、蒸馏，各自解决不同问题
量化把权重和激活从较高位宽映射到较低位宽，直接减少存储与带宽压力。它看起来简单，难点在校准：用哪批数据确定缩放范围，异常值怎么处理，哪些层需要保留更高精度。校准集偏离真实输入时，离线指标可能还体面，线上却出现偶发误判。
剪枝更像整理房间，去掉贡献有限的连接或结构。非结构化剪枝能压出漂亮的稀疏率，却不一定被通用运行时高效利用；结构化剪枝对硬件更友好，但会改变网络形状，需要重新训练和调参。两者都不是“剪完就完”。
蒸馏则换了一个思路：让小模型学习大模型的输出分布，而不只盯硬标签。它往往能改善小模型的泛化，但前提是教师模型足够可靠、数据分布贴近任务。教师本身有偏差，学生也会继承。把蒸馏当成万能药，通常会失望。
压缩比不是奖杯
压缩常被简化成一个比例：压到多少、小了多少。但在真实部署里，比例只是中间指标。更值得看的是目标设备上的端到端表现：预处理、推理、后处理加在一起的时间，内存峰值是否稳定，长时间运行会不会降频，异常输入下能否及时回退。某些团队为了追求更激进的压缩比，把模型推到精度边缘，结果靠后处理规则打补丁，维护成本反而上升。
我的判断是，模型压缩应当被视为部署流程的一部分，而不是模型训练后的收尾动作。它需要和硬件选型、运行时版本、数据回流一起考虑。压缩后的模型也要进入持续评估：新场景出现时，校准数据是否要更新，剪枝结构是否还适配，蒸馏学生是否跟得上教师迭代。缺少这些环节，压缩只是一次性动作，无法支撑长期运行。
有些时候，不压更合适
如果模型更新频繁、任务对细粒度差异敏感，或者目标平台缺少对应算子支持，强行压缩可能带来更多联调工作。还有一种常见误区：把压缩当成替代架构优化的手段。模型本身设计冗余、输入分辨率不合理、后处理链路过重，单靠压缩很难根治。先做剖面分析，再决定压哪里，顺序不能反。
端侧智能的边界，往往不是由参数规模单独决定，而是由内存、功耗、延迟和工程维护共同划出。它的价值，在于让这些约束之间多出一点腾挪空间；它不负责制造奇迹，只负责把可用的模型送到可用的地方。