给一台三年前的手机加语音唤醒，先撞上的往往不是算法，而是内存。模型文件几百兆，加载时占一块，推理时还要再翻一倍。这时候讨论的重点不是模型有多聪明，而是它能不能塞进去。模型压缩处理的正是这类问题：让同一个模型在更小的空间里跑起来，同时尽量保住它原本的判断力。
“压缩”这个词容易让人误解
它不像打包文件那样解压后分毫不差。压缩通常是有损的，动的是网络结构和数值精度，一旦改了，模型的行为就会跟着变。所以真正要问的问题不是“能压到多小”，而是“压完之后，哪些输入上的表现会掉”。这个问题的答案，往往要等到业务侧的反馈才浮出来。
几条常见的路径
- 剪枝：把权重里贡献接近零的连接或通道去掉。非结构化剪枝压得狠，但稀疏矩阵在通用硬件上未必跑得快；结构化剪枝更好落地，代价是要重新训练一段时间。
- 量化：把浮点权重和激活换成低比特整数。收益直接，风险在于长尾输入——校准集覆盖不到的分布，误差会被放大。
- 蒸馏：让小模型去学大模型的输出分布，而不只是学标签。它需要一个愿意配合的教师模型和足够有代表性的数据。
- 低秩分解与结构重设计：从网络本身下手，把大矩阵拆成小矩阵，或者在设计阶段就选轻量结构。这类做法见效慢，但后患也少。
掉点只是第一层代价
很多人以为压缩的代价就是精度掉一两个点，实际上更麻烦的常常在别处。量化后的模型如果碰上硬件不支持的算子，框架会悄悄回退到浮点实现，结果模型是小了，延迟却没降，甚至因为插了转换层而变慢。剪枝带来的稀疏性如果没有对应的运行库支持，压缩率只是纸面上的数字。
还有一层是维护成本。压缩模型往往和原始模型并行存在，两套导出流程、两套测试基线。一旦训练侧改了数据或损失函数，压缩这条链路要重新走一遍。团队如果没有把这件事写进常规流程，过几个月就会没人说得清线上跑的是哪个版本。
顺序比方法更值得计较
我的判断是，压缩不该被当成训练结束后的收尾动作。先定部署侧的具体指标——目标设备的内存上限、可接受的单次推理耗时、功耗预算——再倒推模型规模，比先训一个大模型再想办法削小要省事得多。很多返工都来自顺序颠倒：模型定型了才发现跑不动，只能在精度和体积之间硬挤。
蒸馏和量化对数据的要求也常被低估。量化需要一份能代表真实输入的校准集，如果校准数据全是干净的近场语音，那到了嘈杂环境里误差会明显变大。这不是方法本身的错，而是准备环节省了功夫。
也不是所有场景都需要压
服务端批量推理时，吞吐和显存利用率往往比单次延迟更重要，这时候硬压反而可能得不偿失。真正紧迫的是端侧：手机、车机、摄像头、可穿戴设备，它们的内存和散热都是硬约束。判断标准其实很朴素——如果不压就跑不起来，那就压；如果压了只是让账面上的数字好看一点，那值得再想想。
压缩之后还有一个容易被忽略的动作：持续观察模型的输出分布有没有漂移。有损变换带来的偏差不总是均匀的，它可能只在某几类输入上冒头，而这几类恰好是低频但重要的。把监控做在压缩链路的下游，比事后排查要轻松。
模型压缩说到底是一道工程取舍题，没有普适解。把约束条件写清楚，把代价算明白，剩下的就是接受不完美。