训练好的模型被搬到手机、车机或一块开发板上，第一件麻烦事往往不是算法，而是内存。模型文件要占空间，权重读取要占带宽，推理时还要给中间结果留缓冲区。设备一旦开始“喘气”，工程团队就会想到模型压缩。
这个词听起来像把大模型硬塞进小盒子，但现场的问题没这么简单。压缩并非没有代价，它要回答的是：哪些参数可以少放一点，哪些计算可以合并，哪些精度损失可以被任务容忍。换句话说，模型压缩省下的是存储、带宽和算力，代价则可能出现在精度、稳定性或调试成本上。
先看它到底在省什么
部署时容易被感知的是体积。权重从浮点数变成低比特表示，模型文件会小下来，加载和传输都轻一些。另一层是计算：稀疏化、剪枝、算子融合，试图让推理过程少做无用功。还有一层不太显眼，是内存访问。很多端侧推理的瓶颈不在乘加次数，而在反复搬运权重和中间张量。压缩若能减少访问次数，收益可能来自访问次数，而不只是参数量。
所以，它并不等于“把模型变小”这一件事。它更像一组围绕部署约束展开的工程动作：量化改变数值表示，剪枝去掉部分连接或结构，蒸馏让一个小模型学习大模型的行为，低秩分解则尝试用更紧凑的形式表达权重。每条路都在处理不同层面的浪费，也都带着自己的前提。
压缩之后，麻烦才刚开始
量化常被看作容易落地的一步，但把权重和激活压到低比特后，数值范围、溢出和舍入误差都会变得敏感。某些层对精度下降不敏感，另一些层却可能因为一点点扰动就偏离原来的输出分布。剪枝也一样，结构化剪枝对硬件友好，却可能伤到模型的表达能力；非结构化剪枝看似保留更多连接，实际运行未必能换来同等速度。蒸馏则依赖教师模型和训练数据，学生模型学到的可能是任务相关的捷径，而不是完整的决策边界。
这也是为什么模型压缩很难脱离具体任务谈效果。语音唤醒、图像分类、文本生成对延迟和精度的容忍度不同，硬件支持的算子也不同。同一个压缩方案，在这块芯片上跑得动，换一块板子可能就要重做。压缩带来的不是一次性动作，而是一轮又一轮的验证：精度有没有越界，延迟是否稳定，内存峰值是否可控，异常输入下会不会出现难解释的输出。
什么时候该停手
压缩的边界，往往不在算法本身，而在收益是否还值得继续投入。继续压低比特可能让模型文件再小一点，但调试成本、校准数据成本和维护成本会上升。继续剪枝可能让计算再少一点，但任务精度和鲁棒性开始变得难以预测。工程上更现实的问题是：当前约束是否真的卡在模型上，还是卡在数据管线、预处理或内存分配上。若瓶颈不在权重，压缩能带来的改善就有限。
我倾向于把模型压缩看成一种“部署侧的翻译”：把训练阶段相对宽裕的表达，翻译成设备能承受的形式。翻译得好，模型仍然可靠；翻译得急，问题会在真实输入里慢慢露出来。它值得被认真使用，但不该被当成默认答案。先量清楚瓶颈，再决定压哪里、压到什么程度；一上来追求极致小模型，容易把问题推到后面。