把推理代码从开发机搬到一块资源有限的板子上，常见的现场不是算力不够，而是内存先见底。模型文件看起来不大，加载后张量、缓存和中间结果一并展开，留给系统的余量很快被吃掉。这时谈模型压缩，讨论的其实不是“能不能压小”，而是压小之后，设备是否还能稳定跑完一段连续任务。
文件大小只是入口
一个模型从训练框架导出，到真正在端侧执行，中间要经过格式转换、算子映射和内存规划。文件体积缩小，可能来自权重精度降低，也可能来自结构裁剪，还可能只是换了存储格式。不同来源的“变小”，对运行时的影响并不一样。只看文件大小，容易把部署问题误判成压缩问题。
更值得盯住的是内存带宽和缓存行为。权重被反复读取，若访问模式不连续，压缩带来的收益会被搬运开销抵消。某些设备上，模型能装进存储，却装不进运行时的连续内存；能完成单次推理，却在连续请求下因缓存抖动变慢。模型压缩若只处理静态体积，不处理这些动态约束，落地时就会留下缝隙。
压缩之后，算子还要接得住
量化、剪枝、蒸馏常被放在同一张图里讨论，但它们改变模型的方式不同。量化改变数值表示，剪枝改变结构稀疏性，蒸馏把行为转移到另一个模型。端侧推理引擎对算子支持有边界，压缩后的结构若落到未覆盖的路径，可能被回退到通用实现，速度未必改善。这不是压缩本身失效，而是压缩与运行时没有对齐。
- 先确认目标设备的内存上限和常驻占用，不只看模型文件。
- 把预处理、后处理和中间张量纳入预算，避免只算权重。
- 用真实输入长度测试连续推理，观察延迟波动和内存回收。
- 保留可回退路径，压缩版本与原始版本在同一套接口下验证。
它更像部署工程，而非一次算法动作
模型压缩容易被视为训练结束后的一个步骤，实际更像部署工程的一部分。压缩策略要和硬件特性、推理框架、输入分布一起确定。离线指标只能说明模型在样本上的表现，连续运行时的内存曲线、温度变化和请求间隔，才更接近设备现场。把压缩当成一次性动作，往往会忽略版本迭代后结构变化带来的重新适配。
我的判断是，模型压缩的价值不在“更小”这个单点，而在让模型与设备之间形成可解释的余量。余量意味着面对输入长度变化、并发请求和系统后台占用时，仍有调整空间。做不到这一点，压缩就只是把问题从存储挪到运行时。对大多数端侧项目来说，先测量再压缩，往往能减少返工。