把大模型塞进手机、车机或一块开发板，是很多团队绕不开的场景。屏幕上看起来只是加载慢一点，背后却牵动内存带宽、功耗、散热和响应时间。于是，“模型压缩”被频繁提起。它听起来像把文件打包变小，实际更像一次有损改写：计算图还在，数值精度、连接关系或输出分布已经被重新安排。
先问压缩改变了什么
常见的压缩手段可以粗略分成几类：
- 量化：用更低比特表示权重或激活值，减少存储和带宽压力，但舍入误差会在层间累积。
- 剪枝：去掉部分连接或结构，让模型稀疏化；稀疏能否转化为实际速度，还取决于运行时是否支持。
- 蒸馏：让小模型学习大模型的输出分布，得到的是新的学生模型，而不是原模型的缩小副本。
- 低秩分解与结构重参数化：通过矩阵近似或等价变换减少计算，往往需要和具体算子一起看。
这些方法经常组合使用。问题在于，压缩指标常常停留在文件大小、参数量或单次推理时延上，而使用者真正关心的是任务表现是否稳定。一个模型在测试集上还能答对，不等于在长尾输入、边界条件和连续对话里仍然可靠。模型压缩因此不只是工程打包，它也在重新划定能力边界。
压缩之后，能力不会平均保留
有损改写的特点是，损失不一定均匀分布。高频模式、常见表达和结构规整的输入，通常更容易在压缩后维持原有表现；低频组合、细粒度区分、需要多步推理的任务，则可能先露出破绽。原因不神秘：低精度表示会吃掉小差异，剪枝会改变信息通路，蒸馏会把教师模型的输出偏好编码进学生模型。它们都在改变模型“看见”问题的方式。
所以评估压缩结果时，单看平均指标容易漏掉风险。更务实的做法，是把真实业务中的失败样本、边界输入和连续使用场景拿出来做对照，并观察延迟、内存占用和功耗是否真的下降。若运行时没有对应算子支持，纸面上的稀疏或低比特未必能变成设备上的收益。模型压缩的难点，往往不在压缩算法本身，而在压缩、部署和任务评价之间的对齐。
把它当作一次重新设计
我更愿意把模型压缩看成一次重新设计，而不是收尾阶段的瘦身。先明确哪些能力不能丢，再决定用哪种损失去换资源；先确认目标硬件支持什么，再选择量化或稀疏策略；先准备能暴露问题的评估集，再谈压缩比例。否则，模型确实变小了，使用成本却可能转移到调试、回退和用户困惑上。
模型压缩不会凭空创造能力，也不会无条件保留能力。它做的是一笔交易：用可接受的精度变化，换取更现实的部署条件。交易是否划算，取决于场景，而不是压缩工具本身。