在一台几年前的手机上跑语言模型，最先卡住的往往不是算法，而是内存。权重装不下，就得反复从存储里搬，搬一次慢一次。很多人第一次意识到模型体积是个工程问题，就是在这样的场景里。
于是有了「模型压缩」这个说法。它听上去像把文件打包成 zip，实际做法要复杂得多，也更像一次有明确代价的取舍。
压缩压的到底是什么
常见路径大致三条。量化是把权重从高精度浮点换成低位整数，用更少的比特表示同一个数；剪枝是删掉对输出影响小的连接甚至整块结构，让矩阵变稀疏或者直接变小；蒸馏则是让小模型去学大模型的输出分布，体积的缩减发生在训练阶段，而不是训练完成之后。
三条路的共同点，是把表示精度和参数量当成可以花出去的东西。花多少，取决于你打算把它放在哪里跑。
省下来的体积，不一定变成速度
有个容易忽略的细节：模型变小，不等于推理变快。稀疏矩阵在通用硬件上未必比稠密矩阵跑得快；低位量化如果没有对应的算子支持，反量化那一步的开销会把收益吃掉。真正决定速度的，常常是内存带宽和算子实现，而非参数的绝对数量。
所以认真做模型压缩的人，最后都会去翻目标设备的规格：有没有对应的指令集，缓存多大，带宽多少。脱离硬件谈压缩比，意义有限。
压缩会带走一些东西
量化带来精度损失，这一点通常被承认，但损失并不均匀——有些任务几乎无感，有些会在特定输入上突然失效。剪枝更隐蔽，被删掉的结构在训练分布上看不出问题，遇到分布外的输入时，脆弱性才显出来。
这也是为什么压缩之后通常要重做一轮评测，而且不能只用原来那套评测集。真正值得关心的是“失败模式被改成了什么样”，而不只是平均指标掉了多少。
它能解决什么，不能解决什么
把边界划清楚会省很多事。压缩擅长的是“必须在本地、必须在有限算力和内存里跑起来”的场合：离线语音、输入法、车载语音、设备上的异常检测。它不负责让模型变聪明，那是训练阶段的问题。
还有一点值得提醒：压缩不是一次性动作。模型更新了，量化参数要重新标定；换了芯片，剪枝策略可能要重做。把它当成发布前顺手做的一步，通常会返工。
回到那台旧手机。它最后能不能跑起来，取决于你愿意接受多大的回答质量下滑——这个决定不由技术做出，而由人做出。模型压缩只是把选项摆出来，顺便把代价标清楚。