把一个大模型塞进手机，最先撞上的不是算法问题，而是内存。一个参数量可观的模型，权重加载进来就要占掉几百兆甚至更多空间，推理时还要额外缓冲区。用户不会关心这些，他们只在意点开相机后那半秒有没有卡顿。工程团队于是面对一个很实际的选择：要么把模型做小，要么把设备做大——后者显然不现实。模型压缩因此从论文里的技巧，变成了产品能不能落地的分水岭。
先弄清楚要压掉的是什么
很多人把模型压缩理解成“把文件变小”，这个说法省事，但容易误导。模型体积只是表象，真正影响体验的是三件事：存储占用、内存带宽、计算量。三者并不总是同步变化。一个模型可以在磁盘上很小，但推理时依然要频繁搬运权重，功耗和延迟照样下不来。
所以压缩的目标通常是分层的。对于端侧场景，先看能不能装得下，再看跑得快不快，最后才看精度掉了多少。这个顺序不能颠倒，否则容易做出一个指标漂亮、体验糟糕的结果。
三条常见路径，各有各的代价
剪枝的思路最直观：模型里有很多权重接近零，删掉它们对输出影响有限。结构化剪枝删整个通道或注意力头，硬件友好；非结构化剪枝删单个权重，压缩率高但需要稀疏计算支持，否则实际加速有限。这里的矛盾在于，稀疏度越高，剩下的参数越难重新训练回原来的效果。
量化走的是另一条路。它不删参数，而是降低每个参数的表示精度，比如从浮点数换成低比特整数。这样做的好处是模型体积和带宽同时下降，很多芯片对低精度计算还有专门优化。代价是数值范围被压缩，激活值里偶尔出现的极端值容易造成精度损失，需要校准数据来平衡。
知识蒸馏则换了个角度：让小模型去学大模型的输出分布，而不只是学标签。它压缩的不只是参数，还有“行为”。但蒸馏对训练流程要求更高，教师模型的质量、温度参数的设置、数据分布是否匹配，都会影响学生模型最终能学到多少。
实际产品里很少只用一种。常见的组合是先蒸馏得到一个结构更紧凑的模型，再量化部署，最后根据硬件特性做局部剪枝。模型压缩在这里更像一套配比方案，而不是某个单点技术。
压缩的边界，往往不在算法里
一个容易被忽略的事实是：压缩效果高度依赖下游任务。同一个模型，用在图像分类上掉一个点可能无感，用在文本生成上却可能让输出变得重复、逻辑断裂。精度指标是一条平均线，而用户体验落在长尾上。
另一层限制来自硬件。低比特量化在部分芯片上能获得明显加速，在另一些芯片上反而因为缺少指令支持而变慢。剪枝产生的稀疏结构，如果没有对应的算子库，压缩率再高也只是纸面数字。这也是为什么端侧部署团队常常要和应用、芯片两边一起对齐，单靠算法侧优化很难闭环。
还有维护成本。压缩后的模型往往需要单独的训练和评测流程，一旦上游基座模型更新，压缩管线要重新跑一遍。团队规模有限时，这部分开销容易被低估。
它解决的是“能不能用”，不是“好不好用”
对多数端侧功能来说，模型压缩决定的是下限：能不能在合理功耗内跑起来。至于输出质量的上限，仍然取决于原始模型的能力和任务本身。把压缩当成万能手段，期待它同时解决延迟、成本和效果，往往会失望。
更务实的看法是，把它当作部署链路中的一个约束条件。先明确设备的内存预算和延迟容忍度，再倒推可接受的压缩强度，最后用真实场景的数据验证精度损失是否可接受。这个顺序听起来笨，但比先压再调要省事得多。模型压缩的技术会继续演进，而这条从约束出发的思路，短时间内不会过时。