给一台旧手机装上新的端侧助手，第一次启动往往不是回答得快不快，而是屏幕先转了几秒。内存吃紧、机身发热、响应断续，这些体验问题把“模型压缩”从论文里的参数表拉回到工程现场。它听起来像是把模型改小，实际更像在内存、延迟和效果之间重新分配预算。
先别把“变小”当成目标
模型压缩的常见动作包括剪枝、量化和蒸馏。剪枝去掉部分连接或结构，量化用低比特表示权重和激活，蒸馏让较小的模型学习另一个模型的输出分布。它们都能让模型体积或计算量下降，但下降的位置不同：有的省存储，有的省带宽，有的改善缓存命中，有的只在特定硬件上才显出效果。把这些收益混为一谈，很容易在部署时发现账对不上。
端侧部署的隐形账本
在设备侧，用户感知的是首字延迟、连续对话的稳定性和电量消耗。一个模型经过压缩后文件变小，如果算子被切得很碎，调度开销可能反而上升；量化后吞吐提升，若校准数据偏离真实输入，输出质量也可能波动。于是评估不能只看模型大小，还要看峰值内存、运行时算子支持、批大小变化下的延迟曲线，以及出错后的回滚成本。
- 设备侧可用内存是多少，峰值还是常驻？
- 响应预算落在首字延迟还是持续吞吐？
- 输入分布会不会随季节、场景或用户习惯漂移？
- 更新频率和回滚路径是否清晰？
压缩不是一次性动作
模型压缩更像部署流程中的一段循环：先确定可接受的误差范围，再选择压缩手段，接着在目标设备上测延迟和内存，最后根据失败样本调整策略。训练后量化省事，但校准集的选择很关键；剪枝需要看结构是否被硬件友好地支持；蒸馏则依赖教师模型输出是否覆盖了真实场景。我的判断是，许多压缩方案在实验室里成立，到了设备上却失效，问题往往不在算法本身，而在目标函数没写清楚——到底要省内存、省功耗，还是换响应速度。
边界比技巧更值得先问
有些任务适合压缩，比如输入格式相对稳定、错误可被界面兜底、模型更新不频繁的场景；有些任务则要谨慎，比如对细粒度判断敏感、长尾输入多、设备碎片化严重的场景。把模型压缩放回系统里看，它从来不是孤立步骤：内存预算、推理框架、硬件算子、产品容错度都会改变结论。先问清楚这些约束，再谈压缩比例，通常比追逐某个新方法更接近可用。