一块算力有限的板子，一个跑不动的模型，中间隔着几周的加班。很多团队第一次认真对待模型压缩，都是在这种处境里发生的。
压缩听起来像减法：参数少一点、精度低一点、层数浅一点。真做起来更像在做交换。你拿走一部分计算和存储，就得决定用什么去补——补时间、补精度，或者补一段以后没人敢动的代码。
先弄清它到底占在哪
“模型太大”是个模糊说法。占存储、占带宽、占算力，是三件不同的事。有的模型参数量不算夸张，但访存密集，瓶颈在数据搬运而不是乘加运算，这类模型做量化收益有限，换一种算子融合反而更直接。也有模型权重占了几百兆，推理时却只走其中一小部分路径，压缩空间藏在结构里而不是数值精度里。
不先分清瓶颈，压缩很容易变成一场凭直觉的修剪：删了一轮，精度掉了一截，然后靠调学习率和小样本微调把分数追回来，最后没人说得清省下来的那点开销值不值。
几种常见做法，各自要付的账
- 量化：把权重和激活从高精度压到低精度。工程改动相对小，收益直接，代价在数值范围的处理上。激活里的离群值会拉低整体精度，通常要用一批校准数据来定缩放系数，校准集选得偏，线上表现就会偏。
- 剪枝：按重要性去掉通道或连接。非结构化剪枝的稀疏率看着可观，落到通用硬件上未必真加速，得靠专门的稀疏算子配合。结构化剪枝对硬件友好，但精度回落通常更明显，往往要配合再训练。
- 蒸馏：让小模型去学大模型的输出分布。它不动结构本身，更像一次重新训练，成本压在数据和算力上，还需要一个愿意被学的“老师”。
- 低秩分解：把大矩阵拆成两个小矩阵相乘。前提是权重里确实存在冗余，否则拆完精度掉得很快，尤其在注意力相关的投影矩阵上。
这几条路不互斥，工程上常见的组合是先用蒸馏把结构定下来，再叠量化。叠加不等于收益相加，误差也会叠加，中间需要留出验证环节。
压缩之后，怎么说明它还行
评测集上的分数只是门槛。压缩往往先伤长尾：那些样本少、表述不规范、边界模糊的输入。平均值看起来没怎么动，具体到某类用户、某种口音、某段冷门业务，体验可能已经变了。
所以验证不能只看一个总分。分层看，看最差的那一层；跑一遍真实日志里的输入分布，而不是只跑清洗过的测试集；把压缩前后的输出差异做成可回看的记录。这些做法不新鲜，但经常被跳过。
它不该是最后一步
把模型压缩放在上线前的收尾阶段，是很多项目默认的顺序，也是很多返工的起点。如果从训练阶段就清楚目标硬件的显存、带宽和延迟预算，结构选择、精度策略、蒸馏方案可以一起设计，后面的压缩就不必在既成事实上做减法。
模型压缩本身不缺方法，缺的是判断：清楚哪一部分开销真正卡住了链路，清楚哪一点精度可以交换出去，也清楚哪些东西交换不了——比如一段只有原作者看得懂的推理代码，和一批没人记得怎么标注的校准数据。这些不在论文的表格里，却常常决定一次压缩能走多远。