在会议室里演示一个语音助手，手机刚跑几分钟就发热降频，回答开始变慢。问题未必出在模型“不够聪明”，而是它来得太重：权重占内存，推理读带宽，持续运行还牵动功耗。端侧部署常被拿来讨论的一步，是把模型改小；但模型压缩并不等于简单删参数，它更像在有限资源里重新分配预算。
省下来的不只是一个体积数字
如果只看安装包大小，压缩似乎很直观。可设备运行时，模型要反复读取权重、做矩阵运算、缓存中间结果。内存带宽、峰值内存、时延抖动、发热后的持续性能，都会影响体验。一个体积更小的模型，如果算子不适合硬件，或者频繁在内存之间搬运数据，实际响应未必跟着变好。因此讨论模型压缩时，先要问：端侧真正缺的是存储、带宽、算力，还是电量与散热？不同答案对应不同做法。
几种常见思路，各有各的代价
量化把高精度数值换成更低精度表示，通常能减少存储和带宽压力，但需要看数值范围与异常值，校准不当会让输出变得不稳定。剪枝去掉部分连接或结构，思路像给模型做减法，稀疏结构能否被硬件高效利用却要看实现。蒸馏让一个小模型学习大模型的输出分布，效果依赖数据与训练策略，不是把大模型“复制”过去。低秩分解、结构重参数化等方法也常被提及，它们往往要与具体网络结构和部署工具链一起考虑。
- 先明确瓶颈：存储、时延、功耗还是内存占用。
- 把效果评估放到真实输入上，而不是只跑一套固定样例。
- 关注压缩后的模型在长尾输入、噪声和连续运行下的表现。
效果变差不是唯一风险
模型压缩之后，平均指标看起来接近，并不意味着体验一致。有些能力会以不容易察觉的方式退化：对否定句不敏感，遇到口音或背景噪声容易误判，长文本里前后信息对不上。还有工程侧的代价：压缩模型可能需要新的推理算子、额外的转换步骤，更新和回滚也会增加维护复杂度。若团队只把压缩当成一次性的离线操作，后续维护容易变成负担。
该不该压，要看场景而不是习惯
并非所有端侧任务都需要压缩。如果请求可以稳定回到云端，且时延可接受，本地保留一个轻量兜底模型也有其位置；如果涉及隐私、离线可用或即时响应，端侧推理的价值才值得认真考虑。我的判断是，模型压缩应当从约束出发，而不是从“模型越大越好”或“越小越省”出发。先写清楚体验目标，再决定压缩比例与评估口径；回归测试和灰度空间也应纳入计划，而不是只盯着体积数字。
说到底，压缩省下的是资源，不是责任。它把问题从“能不能跑”推到“跑得稳不稳、错得可不可控”。把这两件事分开看，端侧部署才不容易被一个体积数字带偏。