做端侧功能时，常遇到一个尴尬：模型在开发机上跑得通，装进应用后却要等，发热也上来了。于是团队开始谈模型压缩。但真正棘手的不在“把文件变小”，而在决定把哪部分计算挪走、把哪部分精度留下。
先看预算，不只看体积
模型压缩容易被理解成参数变少、安装包变小。到了设备上，限制往往来自内存带宽、算子支持、峰值功耗和冷启动时间。一个体积缩小的模型，如果频繁触发不友好的算子，推理未必顺畅。反过来，某些结构经过量化后文件不算小，却因为内存访问方式不同，延迟表现也可能变化。压缩的目标不是追求一个数字，而是把有限的计算预算重新分配。
误差要落在能承受的地方
剪枝、量化、蒸馏这些手段，本质上都在改变信息流动方式。剪枝删掉看似不重要的连接，量化用更低比特表示权重和激活，蒸馏让小模型学习大模型的输出分布。问题在于，误差不会平均消失，它会集中到某些输入上。离线评测里平均指标好看，到了长尾场景可能突然失灵。因此，做模型压缩时要先问：业务能接受哪种错误？是偶尔识别偏差，还是连续输出不稳定？把误差落到可观测、可兜底的位置，需要与压缩率一起看。
上线之后，观测不能只靠一次评测
压缩后的模型进入真实环境，会面对不同芯片、系统版本和并发状态。实验室里的固定输入很难覆盖这些变化。较稳妥的做法是保留一条可回退的路径，记录推理耗时、内存峰值和输出置信度的分布，按设备分层观察。这里不必追求复杂平台，先把关键指标留下来，才能判断问题来自模型本身，还是来自部署链路。
还有一个常被忽略的边界：不是所有任务都适合压缩。对延迟极敏感、输入分布又窄的功能，轻量规则或传统算法可能降低维护成本；对输出容错低、解释要求高的环节，压缩带来的不确定性需要单独评估。模型压缩是工程取舍，不是默认选项。把它放回具体设备、具体任务和具体维护成本里看，很多争论会回到可验证的条件上。