把一个大模型装进消费级显卡，或者装进一台手机，最先遇到的限制往往来自显存和带宽，算力反而不是主要瓶颈。权重从显存搬到计算单元这段路，耗时经常超过计算本身。模型压缩要处理的，就是这段路上的冗余。
四类手段，各自动的是不同的账
量化改的是数值表示。原来一个权重占两个字节，换成八位甚至四位整数，搬运量随之下降。代价是数值精度，需要校准数据来定缩放系数；系数选得不好，误差会在层与层之间累积。
剪枝动的是结构。把接近零的权重、整行整列的通道、甚至整个注意力头拿掉，稀疏化之后计算量确实减少，但只有在硬件和推理框架真正支持稀疏计算时，省下来的才会变成时间；否则只是模型文件变小了。
知识蒸馏换的是模型本身。让小模型去学大模型输出的概率分布，而不只是学硬标签，学生因此能继承一些大模型对“接近答案”的判断力。它和前面两种手段不冲突，常常叠加使用。
低秩分解则是数学上的拆解，把一个宽矩阵近似成两个窄矩阵相乘。理论上参数变少了，实际收益还要看矩阵形状和算子实现；形状不规整时，收益会被抵消掉一部分。
指标掉得不多，不等于没丢东西
压缩报告里常写“精度损失可忽略”。这句话在平均意义上有时成立，但平均值会掩盖分布。模型压缩对高频、常见输入的影响通常温和，对低频、长尾、需要细粒度区分的输入，退化可能明显得多。困惑度涨了零点几，在开放生成任务里可能表现为偶尔的逻辑跳跃，这种退化很难用单一数字捕捉。
所以评估压缩效果时，除了通用测试集，还得看自己业务里那批难样本的表现。如果手头没有这样的集合，压缩后的模型在上线前，风险其实是未知的。
部署时才浮现的成本
- 算子支持：量化后的算子未必被推理框架完整覆盖，落到 CPU 或某些加速器上，可能退回未优化的路径。
- 校准与复现：量化需要一批有代表性的校准数据；数据分布漂了，量化参数就该重做。
- 维护复杂度：同一套业务并存全精度和压缩版本，版本对齐、行为差异排查都会增加工作量。
这些成本不在压缩比里，却真实消耗工程时间。
我更愿意看端到端的账
判断一次模型压缩是否值得，压缩比和参数量减少比例都不是终点。真正值得看的是：端到端延迟降了多少，单位请求的成本降了多少，业务指标掉了多少，出问题时能不能定位。四个数放在一起，才构成一次可交代的折中。
模型压缩本质上是一组工程折中，不是免费的午餐。它把问题从“能不能算得动”转移到“愿不愿意接受某种退化”，而这个选择，只能由具体业务来回答。