把一个大模型塞进手机或一块边缘开发板，最先遇到的往往不是算法问题，而是内存。加载权重时显存不够，推理一轮要几百毫秒，风扇转起来，电量掉得比预想快。于是「模型压缩」被摆到桌面：量化、剪枝、蒸馏、低秩分解，名字听起来都很直接——把模型变小。
但变小只是开始。真正需要回答的是：省下来的那部分，换来了什么，又丢掉了什么。
一次端侧部署里的取舍
假设要把一个视觉模型放到功耗受限的设备上。工程师通常会先试量化，把浮点权重压到更低比特。文件体积下降明显，加载变快，这几乎是立竿见影的。可接着测试发现，某些类别的识别结果开始漂移，尤其是低对比度图像，错误并非均匀分布，而是集中出现在原本就边缘的样本上。
这提示一件事：模型压缩并不是等比例地削弱能力。它更像是在参数空间里做取舍，压缩策略决定了哪些能力被保留、哪些被牺牲。量化对数值范围敏感，剪枝对冗余结构敏感，蒸馏则依赖教师模型的输出分布是否真的传达了有用的信息。选哪种方法，取决于你更在意延迟、体积还是某几类任务的稳定性。
所以实际工程里，压缩很少是一次完成的。它往往是一个循环：压缩、评测、定位退化、调整策略、再压缩。这个循环的成本常常被低估，因为评测集必须贴近真实场景，否则压缩后的模型在实验室过关，上线后却出问题。
省下的算力不等于省下的体验
另一种常见误解是把压缩等同于降本。模型小了，单次推理确实更省，但如果精度下降导致需要更多次调用、更复杂的后处理，或者需要人工兜底，总账未必划算。模型压缩的价值不在于把数字做小，而在于让原本跑不起来的场景跑起来，比如离线环境、低功耗设备、对响应时间敏感的前端交互。
在这类场景里，判断标准应该换成用户体验：首字延迟是否可接受，连续使用是否稳定，异常输入下是否会出现明显偏差。压缩只是手段，体验才是约束条件。
边界在哪里
值得注意的是，压缩有它的适用边界。当一个任务本身对细粒度差异高度敏感，或者训练数据覆盖不足，压缩放大的往往正是原有的薄弱环节。此时与其继续压，不如回头检查数据与任务定义。另一类边界是维护成本：过度定制的压缩方案会绑定特定硬件与推理框架，后续换设备、换版本时迁移代价不小。
更务实的做法，是把模型压缩纳入整体部署设计，而不是当作上线前的一道补救工序。先明确设备约束与体验底线，再决定压缩的力度和方式，同时留出可回退的余地。毕竟，模型变小是为了让系统更好用，而不是为了让指标看起来更漂亮。