深夜的会议室里，产品经理把一台旧手机推到桌上：“这个功能能不能离线跑？”屏幕上的识别界面还在转圈，网络一断，演示就停了。把模型搬到端侧，听起来像拷个文件，真做起来却会撞上内存、算力和功耗的限制。模型压缩因此被摆上桌面。
很多人把模型压缩理解成“把参数量变小”。这只说对一半。压缩的目标不是得到更小的文件，而是让模型在目标设备上稳定推理，并给系统、相机、通信留出余量。文件小，不代表运行时就省；权重变小，也不代表访存次数会同步下降。
先看内存带宽，不只看体积
端侧推理常卡在数据搬运。每一层都要读权重、写中间结果，内存带宽和缓存命中会影响响应。只做权重量化，体积可能下降，但算子没有配套实现时，运行时仍要拆包、反量化，收益会被吃掉。工程上常见的做法，是把压缩和推理框架一起看：哪些层适合低比特，哪些层要保持精度，哪些算子能融合，哪些中间结果可复用。
同一个模型在不同设备上的表现可能差别很大。不是方法忽好忽坏，而是内存层级、指令集和运行时支持不同。脱离目标硬件谈“压到多小”，意义有限。
精度回退不是一条直线
压缩会带来精度回退，但回退往往不均匀。有些任务对整体误差不敏感，少量低比特量化后仍能工作；有些任务对局部细节敏感，比如小目标识别、低信噪比语音。离线评测集上的平均指标，不一定覆盖真实场景的边角情况。
所以，压缩方案要和评测集一起设计。与其只看总分，不如把失败样本按场景拆开：弱光、遮挡、远距离、口音、背景噪声。看看压缩后新增的错误集中在哪一类。若某类错误不可接受，就要回到层级策略，而不是继续调一个全局参数。
更新和维护常被低估
模型上线后不会静止。业务要加类别，设备要适配新系统，数据分布也会漂移。压缩模型如果和训练流程绑得太紧，每次更新都可能重走量化、校准、转换和回归测试。团队需要一条可重复的流水线：训练产出原始模型，压缩配置独立管理，转换和评测自动执行，端侧包体能追溯版本。
端侧设备还高度碎片化。不同内存、不同芯片、不同系统版本，意味着策略不能只针对一台样机。稳妥的做法，是先划出支持范围，再在范围内选择压缩粒度和回退方案。模型压缩不是一次性动作，更像一项持续维护的工程约定。
边界比参数更值得先问
回到那间会议室，真正要先回答的不是“能压到多小”，而是“断网时哪些功能必须可用，延迟能接受到什么程度，错误会造成什么后果”。边界清楚了，压缩才有坐标。否则，团队容易在参数上反复试探，却说不清为什么压、压到什么程度算够。
模型压缩的价值，不在于把模型做成一个漂亮的小文件，而在于让推理在真实设备上可部署、可维护、可解释。它解决的是工程约束，不是概念表演。下一次有人问“能不能离线跑”，不妨先摊开设备清单和失败样本，再谈压缩。