在展厅里演示一个对话模型很容易，把它装进一台三年前买的手机、在断网状态下跑起来，是另一回事。内存不够、发热、首字延迟变长，问题会在几分钟内暴露。模型压缩处理的正是这段落差：同样的能力，怎么在更小的空间和更低的算力里维持住。
先弄清楚被压的是什么
模型占地方，主要不是因为“参数个数”这一个数字。权重通常以浮点数保存，每个数字占的字节数决定了文件体积；推理时还要额外缓存中间结果，序列越长，这块开销越显眼。所以压缩往往同时面对两件事：静态的存储占用，和运行时的工作内存。
常见的做法有这么几类：
- 降低数值精度，用更少的位宽表示权重和激活值，体积与带宽压力随之下降；
- 去掉对输出影响较小的连接或结构，让计算图变稀；
- 用较小的模型去学大模型的输出分布，把能力迁移到更轻的骨架里；
- 把大矩阵拆成低秩近似，用更少的乘法完成近似计算。
它们并不互斥，工程上常常叠加使用，代价则分散在不同的地方。
压缩比的数字容易骗人
一个模型被压到原来的一小部分，听起来干脆，实际影响却不均匀。语言模型里，有些能力对精度非常敏感，位宽一降，长尾知识、数值推理、格式遵循可能先出问题；而另一些日常问答几乎察觉不到变化。同一个压缩结果，在不同任务上的表现差异，可能比压缩前后的差异还大。
这也是为什么只看困惑度或单一分数不够。真正决定能不能上线的，往往是那些具体而琐碎的条件：显存峰值、首字延迟、批处理下的吞吐、长时间运行的温度曲线。模型压缩在这里更像一门测量工作，先定义清楚约束，再决定压哪一层、压到什么程度。
边界在哪里
压缩不会凭空产生效率。低精度计算需要硬件支持，否则省下的存储会变成转换开销；稀疏结构如果得不到算子层面的配合，理论上的加速在实测里可能消失。换句话说，压缩方案和部署环境是绑在一起的，脱离目标设备谈压缩比例，意义有限。
另一个容易被忽略的边界是维护成本。压缩后的模型往往需要单独一套评测与回归流程，上游模型一更新，这套流程就得重跑。团队如果只把压缩当成一次性的优化动作，后面的麻烦会慢慢积累。
我的判断是，模型压缩的价值不在于把参数变小这件事本身，而在于它迫使团队把“能力”和“成本”放在同一张表上衡量。什么时候该压、压到哪里停，答案通常不在论文里，而在那台旧设备的实测曲线里。