把模型放进一台内存只有几GB的设备里，最先撞上的往往不是算法好不好，而是带宽和功耗。工程上给出的答案通常叫模型压缩：把同样的能力装进更小的空间。这个词听起来像一次瘦身，实际更像一组彼此拉扯的取舍。
常见做法大致四类：量化把权重从高精度换成低位宽；剪枝删掉贡献小的连接或通道；蒸馏让小模型去模仿大模型的输出分布；低秩分解则把大矩阵拆成两个更瘦的矩阵相乘。它们可以叠加，但每叠加一层，调试难度也上一档。
省下来的到底是什么
很多人以为压缩省的是存储。多数时候真正的瓶颈在推理时的内存访问——权重搬不进缓存，算力再足也只能等数据。量化之所以在端侧被大量采用，不只是文件变小，而是同样的带宽能喂进更多参数。反过来，如果一个模型本来就算力受限、访存充裕，那么压缩带来的收益可能远不如预期。
所以动手前值得先量一遍：延迟预算是多少毫秒，内存上限卡在哪，精度掉到什么程度业务还能接受。这三个数字定不下来，方案就没法选。
精度那笔账，落在长尾上
量化误差通常不是均匀分布的。常见输入下几乎看不出差别，一旦遇到罕见表达、超长输入或者生僻字符，误差会被放大。校准集的代表性因此变得关键：用一份过于干净的样本去定缩放系数，模型在真实流量里就容易露出破绽。
我的看法是，评估压缩效果时别只看平均值。把线上日志里那些“奇怪但真实”的请求挑出来单独测，往往比跑一遍标准测试集更有信息量。模型压缩的难点很少在压缩本身，而在压完之后你是否还看得见它出错的地方。
不同位置的压缩，目标不一样
- 训练侧压缩更多是为了让大模型跑得动、存得下，容忍一定的精度回退，靠后续微调补回来。
- 端侧压缩面对的是固定硬件，算子支持、内存对齐、功耗墙都是硬约束，方案往往要跟着芯片走。
- 服务端压缩看重吞吐与并发成本，批处理尺寸一变，合适的位宽选择也可能跟着变。
这意味着不存在一套通用配置。同一个模型，放到手机上、放进机柜里，压缩策略大概率要重做一遍，甚至重新训练。
边界在哪里
压缩不是无限度的。参数量减到某个程度，模型会先丢掉组合推理的能力，再丢掉对细节的敏感度，最后连格式都维持不住。这条线很难事先算出来，只能一点点试。
有人习惯把模型压缩当成部署前的最后一道工序，我更倾向于把它提前——在模型结构定下来的时候就考虑目标硬件的内存节奏，后续返工会少很多。至于工具链，量化库和剪枝框架已经足够多，缺的往往不是工具，而是对“压到什么程度还算同一个模型”的判断标准。这个标准只能由具体业务来定，任何通用经验都替代不了。