把大模型塞进手机，最先遇到的不是算法问题，而是内存和发热。应用打开时转圈，电量往下掉，用户不会关心参数规模，只会觉得这功能不好用。端侧部署的紧张感，往往从这些具体时刻开始。
模型压缩常被理解成“把模型变小”。这句话不算错，但容易漏掉代价。参数变少、精度变低、层被合并之后，推理速度可能上来，内存占用可能下降，可输出质量、稳定性以及长尾场景的表现，也会跟着发生变化。真正要回答的问题不是能压到多小，而是压完之后，哪些能力可以退，哪些不能退。
先看约束，再看方法
一个模型跑在什么设备上，决定了压缩策略的起点。浏览器里的小工具、车载语音、离线翻译、手机相册分类，对延迟、内存、功耗的要求并不一样。有的场景可以接受一次请求多等几百毫秒，有的场景只要卡顿一次就会被放弃。压缩如果脱离部署环境谈技巧，容易变成实验室里的数字游戏。
常见做法大致分几类。剪枝关注冗余结构，把贡献弱的连接或通道去掉；量化把高精度数值换成低比特表示，减少存储和计算开销；蒸馏让一个小模型学习大模型的输出行为；低秩分解则试图用紧凑矩阵近似原结构。这些方法经常组合使用，因为它们处理的是不同层面的浪费。
- 剪枝之后，稀疏结构未必能被硬件高效利用，压缩率不等于实际加速。
- 量化会引入数值误差，某些对精度敏感的层需要保留较高精度。
- 蒸馏依赖教师输出，教师本身的偏差也会被学生继承。
- 低秩分解需要看权重分布，不是所有层都适合做同样处理。
这些限制说明，模型压缩不是一次性动作，而是和推理框架、硬件特性、业务指标绑在一起的工程选择。纸面上的参数量下降，落到真实设备上，可能被内存访问、算子支持、批处理方式抵消。编辑在审稿时看到“压缩后效果几乎不变”这类表述，通常会追问：在哪些输入上不变，失败时错得多严重，用户能不能感知。
模型压缩的边界
有些团队把压缩当成上线前的最后一刀，结果反复返工。稳妥的做法，是在模型设计阶段就留下可压缩空间，比如控制层宽、减少不必要的分支、提前确定哪些能力必须保留。压缩不是给模型“瘦身”的惩罚，而是部署约束下的一次重新分配。
也需要承认，压缩有做不到的事。它可以让端侧推理变轻，却很难凭空补上训练数据里的空白；它可以降低显存压力，却不能保证长尾输入仍然稳定；它可以把响应时间压到可用范围，却不代表交互设计就此合理。把压缩当成万能钥匙，往往会在真实用户面前暴露问题。
所以，讨论压缩时，不妨少问“能压多少”，多问“压完之后，谁还在为效果负责”。这个问题没有统一答案，但能逼着团队把延迟、内存、效果和失败成本放在同一张桌上谈。对端侧 AI 来说，这种具体的取舍，值得被记录。