在一台内存吃紧的开发板上跑推理，最先暴露的问题往往不是算法思路，而是模型文件一加载，剩余空间就所剩无几。于是团队开始谈模型压缩。它听起来像部署前的收尾动作，实际却会把训练阶段留下的选择重新翻出来：哪些参数可以粗一点，哪些层不能碰，精度掉下去之后业务是否还能接受。
省下来的空间，来自哪里
常见做法大致分几类：量化降低数值表示精度；剪枝去掉对输出影响有限的连接或结构；蒸馏让一个小模型学习大模型的输出分布；也有低秩分解、权重共享等路线。它们共同指向存储和计算开销，但副作用不同。量化改动的是数值表达，剪枝改动的是网络结构，蒸馏改动的是训练目标和学生模型。把这些手段混成一句“压一压”，后面往往要花更多时间定位问题。
先问代价，再问收益
模型压缩的收益不只体现在文件大小。内存占用、首包延迟、吞吐和功耗都可能受影响，但每项收益都要用别的东西换。量化可能让某些算子落到不支持的路径，剪枝可能让稀疏结构在通用硬件上跑不出预期速度，蒸馏则需要重新准备训练流程和评估集。工程上常见的情况是：离线指标变化不大，线上却因为输入分布偏移出现新的错误。压缩不是一次性动作，评估集也要跟着扩。
边界比工具重要
决定是否压缩之前，先明确约束：目标设备的内存和算力是多少，延迟预算是多少，精度下降的容忍范围在哪里，后续模型迭代频率有多高。约束不清楚，压缩很容易变成盲目试参数。还要看部署链路，训练框架、推理引擎和硬件算子是否支持压缩后的结构。一个在实验环境里能跑通的方案，到了生产环境可能卡在格式转换或算子缺失上。
另一个容易被忽略的问题是维护。压缩后的模型通常需要单独的导出、校准和回归流程。若团队没有把这些步骤沉淀成脚本，下一次模型更新就会重复踩坑。因此，模型压缩不应只由算法同学完成，部署、测试和业务方都要提前知道取舍条件。
把它当作设计问题
换个角度看，模型压缩不是给已有模型“减肥”，而是把部署约束提前放进模型设计。训练时考虑目标硬件的位宽和算子支持，评估时把延迟和内存纳入指标，导出时保留可复现的校准数据，后续迭代才不至于每次都从零开始。它也不总能解决所有问题：如果业务本身需要复杂推理，压缩只能挪动成本，不能凭空消除成本。
所以，当下一次显存或时延告警出现时，先别急着找工具。把约束写清楚，把代价列出来，再决定用哪种模型压缩手段。省下来的那部分空间，往往对应着一组需要被认真管理的工程选择。