办公室里那台用了三四年的笔记本，被人拿来跑一个 7B 参数的对话模型。风扇转得很急，回答要等十几秒才冒出来。于是有人提议：能不能把它压小一点，塞进内存里？这个念头听起来像工程细节，却是模型压缩这类工作最常见的起点。
问题在于，压小之后会发生什么，很少有人提前说清。
压下去的是体积，还是等待时间
量化把权重从十六位浮点换成八位、四位整数，文件体积和内存占用随之下降，这一步相对直观。但推理是否变快，要看硬件有没有对应的整数运算指令，也要看瓶颈在算力还是内存带宽。在一些设备上，权重被压小了，反量化却带来额外开销，端到端延迟未必改善，甚至可能变慢。
所以判断一次模型压缩是否划算，得回到具体链路：输入多长、批大小多少、跑在什么芯片上。只对比模型文件的大小，容易得出漂亮却用不上的结论。
剪枝与蒸馏，动的是不同的东西
剪枝删掉不重要的连接或通道，蒸馏则换了一种训练方式，让小模型去拟合大模型的输出分布。两者常被并列提起，但作用点不一样。
- 结构化剪枝能真正减少计算量，代价是可能伤到某些通道的表达能力。
- 非结构化剪枝留下稀疏权重，需要专门的库和硬件支持，否则省下的存储换不来速度。
- 蒸馏学到的是行为，不是参数本身，学生模型的上限受训练数据和温度设置影响。
这几条路径经常叠加使用，先蒸馏再量化，或者先剪枝后微调。叠加本身没问题，麻烦的是每加一步，误差就在悄悄累积，而排查时很难定位是哪一步引入的。
精度损失不均匀，平均指标会骗人
压缩后的模型在常见问题上几乎看不出差别，一旦进入长尾输入、罕见实体或多步推理，回答就开始含糊。平均评测分数下降一点点，背后可能是个别场景大幅退化，另一些场景几乎无感。
因此评估时按业务切片分别看，比看一个总分更有意义。尤其是那些输入分布偏离训练集的环节，往往是压缩代价最先暴露的地方。有人把这叫“最后一公里”，其实它更像是一道需要反复测量的坡。
有些场景，其实不必压
如果目标设备并不缺内存，瓶颈在别处，压缩带来的收益有限，却引入了额外的维护成本：版本要重新验证，精度要重新对齐，出问题时要多查一层。反过来，如果设备资源紧、离线可用是硬需求、对响应时间敏感，那么接受一定精度折损换取落地，是合理的取舍。
还有一种情况容易被忽略：任务对细粒度数值本身敏感时，低比特表示可能直接破坏判断依据。这时候与其硬压，不如换更小的模型结构，或者把任务拆开，只让必须的部分留在端侧。
把大模型装进旧设备，本质上不是一场压缩比的竞赛，而是一次关于资源、精度和维护成本的权衡。模型压缩能做的事有边界，认清边界，比多压一位比特更有价值。