把模型放进一台离线设备里，问题常常不是“它够不够聪明”，而是它是否装得下、跑得动、发热是否可接受。云端可以靠更多机器分担压力，终端却要面对内存、电量和响应时间的硬约束。模型压缩在这里不是锦上添花，而是让模型从实验环境走向日常设备的一道工程工序。
但“变小”本身并不是目标。一个被压得很小的模型，如果输出变得不稳定，或者在真实输入上频繁失手，省下来的资源很快会被返工和补丁吃掉。讨论模型压缩时，我更愿意先问：要解决的是存储、计算、功耗，还是传输？不同约束会导向不同做法，也会带来不同的副作用。
它到底在压什么
模型体积和推理开销并不完全是一回事。参数占用主要看存储与加载，计算量取决于结构和算子，访存和调度又会影响实际速度。把参数从高精度换成低精度，能减少占用，但某些层对精度更敏感；剪掉看似不重要的连接，可能降低计算量，却让硬件利用率变得不整齐；用一个小模型去学习大模型的行为，思路清晰，前提是任务边界相对稳定。
这些方法经常被放在一起谈，实际使用时却要分开验证。量化改变数值表示，剪枝改变结构稀疏性，蒸馏改变学习目标。它们都能被归入模型压缩，但失败方式不同。把它们当成一套可以随意叠加的工具，容易在某一环得到漂亮的离线指标，却在端到端链路上暴露问题。
场景比方法更早决定答案
端侧部署通常关心冷启动、内存峰值和持续推理时的功耗。批量服务更在意吞吐和延迟分布。离线归档则更看重存储占用。场景不同，压缩后的模型需要接受的检查也不同。只看文件大小，可能会忽略解压和加载带来的额外开销；只看单次推理时间，也可能漏掉长时间运行后的降频。
评估时可以把“模型压缩”拆成几个可观察的问题：压缩后精度在哪些输入上变化明显？内存峰值是否真的下降？算子是否被设备支持？更新和回滚是否仍然简单？这些问题不新鲜，却常常在演示阶段被跳过。我的判断是，压缩方案的价值不在于用了多少技巧，而在于它是否把约束讲清楚，并留下可维护的退路。
边界：不是所有模型都值得压
如果模型本身很小，或者调用频率很低，压缩带来的收益可能抵不过额外工程复杂度。如果任务对细微误差非常敏感，压缩后需要更谨慎的验证集和回归测试。还有一种常见误区，是把压缩当成弥补数据问题的办法；模型学不到的东西，通常不会因为变小而自动学会。
更现实的做法，是先确认瓶颈在哪里，再决定是否引入模型压缩。它更像一次针对部署条件的重新设计，而不是给模型打一个通用补丁。把这句话记住，很多争论会变得具体：我们不是要让模型“看起来更小”，而是要让它在给定设备、给定功耗、给定维护能力下稳定工作。