把一个大模型装进手机，最先碰到的往往不是算法问题，而是内存。一次端侧语音助手的调试中，权重刚加载完，应用还没开始推理，系统已经弹出内存告警。那一刻你会意识到，模型压缩不是论文里的可选技巧，而是部署前绕不开的现实约束。
参数规模为什么会和设备较劲
训练阶段追求容量，推理阶段却要看延迟、功耗和存储。同一个模型，在服务器上跑得动，不代表在耳机、手表或千元机上跑得动。模型压缩要处理的，正是这种“训练时宽松、部署时紧张”的落差。
但压缩不是把数字改小那么简单。参数减少、位宽降低，都会改变模型对输入的响应方式。有些任务对细微扰动不敏感，压缩后几乎无感；有些任务依赖长尾细节，压过头就会出错。
几条常见路径，各自解决不同问题
- 量化：把浮点权重和激活换成低比特表示，减少存储和带宽压力，常用于推理加速。难点在于保持数值范围，避免溢出或精度塌陷。
- 剪枝：去掉贡献较小的连接或结构，让模型变稀疏。稀疏不等于一定快，硬件是否支持稀疏计算，决定了收益能不能落地。
- 知识蒸馏：用大模型指导小模型训练，把行为迁移过去。它更像训练策略，而不是事后修剪。
- 低秩分解：用更少的秩近似原矩阵，适合部分层，但对非结构化权重未必友好。
这些方法经常组合使用。先蒸馏得到小模型，再量化压缩，最后按硬件剪枝。顺序不同，结果可能差很多。
压缩的边界在哪里
模型压缩的收益有明确上限。压缩率越高，模型保留的能力越少，但“能力”本身要看任务定义。一个用于关键词唤醒的模型，和一个用于多轮对话的模型，对压缩的容忍度完全不同。脱离任务谈压缩比，意义不大。
另一个容易被忽略的点是工具链。压缩后的模型要落到具体推理框架，算子支持、内存布局、量化校准数据都会影响最终表现。实验室里的指标和端侧的真实延迟之间，往往隔着一段工程距离。
我的判断是，先明确部署约束——内存上限、延迟预算、功耗窗口——再选压缩方法。反过来，先压再找场景，通常会陷入反复调参。模型压缩不是让模型变小的魔法，而是一组需要和硬件、任务一起权衡的工程选择。