在开发机上跑得好好的模型，装进手机或一块边缘板卡之后，第一次推理就可能出现明显问题：内存峰值达到上限，帧率掉下来，机身开始发热。这时候团队才会认真讨论模型压缩。它并不只是把文件体积改小，而是一整套关于“在哪里让步”的工程选择。
先看清楚瓶颈落在哪一环
很多人默认算力是瓶颈，于是先想着换更快的芯片。但推理过程里，权重从内存搬到计算单元的次数往往更值得关注。参数量大，意味着每次前向都要搬运大量数值；带宽不够，算力再足也只能等待数据。所以模型压缩的第一层意义是减少搬运：让参与计算的数值更少、更小，缓存装得下，访存次数降下来。
几条常见路径，代价各不相同
- 量化：把浮点权重和激活换成低位宽的整数表示。省内存也省带宽，但需要校准；输入分布偏离校准集时，误差会被放大。
- 剪枝：删掉贡献小的连接或整块结构。非结构化剪枝压缩率高，却不一定在通用硬件上变快；结构化剪枝对硬件友好，精度损失需要重新训练来补。
- 蒸馏：让小模型去学大模型的输出分布，而不只是学标签。它对数据和学生网络容量都很敏感，教师给出的软信息未必都能被接住。
- 低秩分解与结构重设计：把大矩阵拆成小矩阵相乘，或者直接换用更省算子的结构。这种改动较大，往往要连着训练流程一起调整。
这些方法经常叠加使用，顺序不同，结果差别不小。先量化再剪枝，和先剪枝再量化，最终达到的精度点未必一样。
真正的决策是把误差预算分配出去
压缩做深之后，问题就不再是“用哪种方法”，而是“哪些部分可以粗糙一点”。一个网络里，不同层的敏感度并不均匀，有些层稍微降精度整体就崩，有些层砍掉一大块几乎看不出变化。这个判断没法靠经验拍板，得靠校准数据和逐层评估。校准集的选择也容易被低估：它必须贴近真实输入分布，否则量化的缩放因子会算偏，线上表现和测试结果对不上。
也有不该压的时候
并非所有场景都值得做模型压缩。服务端批量推理，显存和带宽相对宽裕，把工程精力投在调度和批处理上可能更划算；任务本身对数值极敏感时，压缩带来的收益可能抵不过反复调参的成本。判断标准其实很朴素：延迟、内存、成本这三项里，哪一项真的卡住了上线，就先解决哪一项。
我更愿意把模型压缩看作一次需要留存证据的取舍：每一次降低位宽、每一次剪掉结构，都要能回答“误差增加了多少、换回了什么”。它不该只是项目收尾阶段的补救动作，而应该在确定部署目标时就被纳入设计。压得下去，也说得清楚，才算真正完成。