手机背面开始发热，屏幕上的回复一个字一个字往外蹦，比网络对面的服务慢半拍。这类演示最近不少，问题也很集中：模型想留在本地，可内存和电先撑不住了。
于是话题绕不开模型压缩。但这个词容易被当成一件具体的事，实际上它是一组取舍的总称，每种取舍都把成本挪到别处。
压下去的往往不是算力
直觉上，压缩是为了让计算变少。可真跑一次推理，权重从内存搬到计算单元的次数，常常比乘法本身更耗电。端侧的第一道关是搬运：同样一次推理，能不能少读几个字节。
理解这一点，很多方案的选择就顺了。它不一定让浮点运算数明显下降，但能减少内存占用和带宽压力——而这正是手机、车机、摄像头上真正稀缺的东西。
三种常见手段，各自把代价挪到哪
- 量化：把权重和激活从浮点换成低位整数。省内存、省带宽，通用硬件上也容易吃到好处。代价是精度损失不均匀，某些层、某些输入分布对数值范围格外敏感，需要逐层去看。
- 剪枝：删掉不重要的连接，甚至整块结构。非结构化剪枝看着参数掉得多，落到通用硬件上却未必更快；结构化剪枝更容易真正省下时间，但约束更强，可能伤到能力。
- 蒸馏：让小模型去学大模型的输出分布。软标签里带着类别之间的相对关系，信息量比硬标签多。代价是训练流程变长，学生模型的天花板也受老师限制。
这几样通常叠着用，可收益很难简单相加，有时还会互相抵消：量化之后再做剪枝，敏感性判断得重算一遍。
稀疏之下还有个硬件问题
剪枝常被描述成“参数减半”，听起来很干脆。但稀疏矩阵要在通用芯片上跑到理论加速，需要内核与硬件配合。否则省下的只是存储，延迟照旧。判断一个模型压缩方案，先问它在目标设备上实测的延迟和功耗，比看参数量更有意义。
退化不是均匀发生的
能力下滑很少平均分布。闲聊、改写、格式化输出这类任务，压过之后往往还站得住；需要多步推理、涉及长尾知识、卡在边界条件上的输入，则会先出问题。只看一份平均指标，很容易得出乐观结论。
更实用的做法，是从自己的业务里挑一批“最不该答错”的样本，压缩前后各跑一遍，看失败集中在哪。这个动作不复杂，却能省掉很多返工。
我个人的判断是，端侧模型的较量，最后不太可能落在谁的数字更小上，而落在谁更清楚自己愿意在哪一类错误上让步。模型压缩做的正是这件事：与其说它把模型变小，不如说它把取舍摆到台面上，让你一项一项签字。