把一个大模型塞进几年前的笔记本，或者一台没有独立显卡的手机，碰到的往往不是算法问题，而是内存。权重加载到一半，系统开始频繁换页，风扇转起来，推理速度掉到没法用。这时候谈模型压缩，才不是论文里的名词，而是一道很具体的算术题：手上这台设备，到底能给出多少内存、多少算力、多少功耗预算。
参数多，不等于每个都需要
训练阶段的模型通常留了余量。不少权重对最终输出的贡献很小，激活值分布也有明显的长尾。压缩要做的事，是把这些余量识别出来，再用一种硬件能接受的方式去掉。识别本身不算难，难在去掉之后模型还能不能稳住。
几条常见路径，各有各的代价
量化是把浮点权重和激活换成低比特表示，实现起来直接，工程里也常见。但它不是简单截断：校准集选得不对，异常值会把整段动态范围撑坏，精度掉得莫名其妙。
剪枝走的是另一条路，按重要性去掉连接或整个通道。非结构化剪枝看着稀疏率很高，实际跑起来未必快，因为通用硬件对不规则稀疏并不友好；结构化剪枝牺牲一点灵活性，换来的是实打实的延迟下降。
知识蒸馏不直接动原模型，而是让一个小模型去拟合大模型的输出分布。它更像重新训练，成本落在数据和时间上。低秩分解则把大矩阵拆成两个小矩阵相乘，数学上干净，工程上要看层结构是否配合。
压缩之后，问题才刚开始
有些团队在验证集上看到指标没怎么变，就认为模型压缩已经完成。上线后才发现，长尾输入、口音、光照变化这些场景里，退化是悄悄发生的。压缩会放大模型原本就存在的脆弱点，只是这些脆弱点在原始模型上被参数量掩盖了。
所以压缩方案要和评测方式一起设计。延迟、内存占用、功耗这些指标得在目标设备上测，不是在服务器上估算。任务对误差的容忍度也不同，分类和生成面对同一个压缩比，反应可能完全不一样。
我的判断是，模型压缩本质上是工程取舍，不是算法表演。先明确约束，再选工具，往往比反过来省事。至于那些被剪掉、被量化掉的参数，它们并没有消失，只是从模型里转移到了工程决策里——你得为每一次删除负责。