电梯里没有信号，语音助手转了两秒还没把一句话转成文字。屏幕上没有报错，只是那个小圆圈一直转。很多端侧功能的挫败感并不来自模型不会做，而来自它做得太慢、占得太多。这时人们会想到模型压缩：把参数、位宽或计算路径收一收，让模型在本地跑起来。
但压缩不是把文件从几百兆改成几十兆就结束了。模型在设备上运行时，占用的不只是存储，还有内存带宽、算子实现和前后处理的时间。一个体积变小的模型，如果遇到设备不支持的计算格式，推理时仍可能被反复拆解、搬运，最后省下的空间没有换成流畅的体验。
变小之后，代价去了哪里
常见的压缩手段各有自己的账本。量化把浮点权重和激活压到更低位数，直接减少内存占用和部分计算量，但误差会在层间累积；剪枝去掉不重要的连接或结构，能让模型稀疏，却不一定被现有硬件高效利用；蒸馏让一个小模型学习大模型的输出分布，省下参数，却需要重新训练和调参。它们不是把模型无损折叠，而是把成本从存储挪到别处。
所以讨论模型压缩时，我倾向于先问一句：省下来的资源准备换什么？如果目标是离线可用，内存峰值和冷启动时间值得盯紧；如果目标是连续交互，首字时延和功耗需要单独看；如果目标只是降低安装包体积，那又是另一套衡量方式。问题不同，压缩策略的落点也不同。
评估要回到整条链路
模型压缩的边界，往往不在压缩算法本身，而在整条链路。麦克风采集、降噪、特征提取、推理、后处理，任何一段的等待都会叠加到用户感知里。只看模型文件的体积，或者只看单次推理的耗时，容易忽略数据搬运和线程调度。压缩后的模型可能需要更多次小算子调用，也可能让缓存命中率变化，这些都不会写在体积数字里。
实际做评估时，我会把设备放回真实场景：弱网、后台有其他任务、电量不充裕、连续说几句。记录端到端时延、内存峰值、功耗和错误类型，再判断压缩带来的误差是否落在可接受范围内。误差不是均匀消失的，它可能集中在某些口音、某些长句或某些背景噪声里。只测几条干净样本，很难看清边界。
还有一点常被忽略：压缩会改变模型的失败方式。原本能给出大致答案的输入，压缩后可能变得犹豫，或者输出格式开始漂移。对产品来说，稳定地拒绝至少让系统知道如何回退，而自信地胡说会把错误带到下游。因此评估时不能只看平均表现，也要看错误是否可解释、是否可回退。
我不认为模型压缩是一个一次性的优化动作。它更像在有限资源下重新分配预算：把内存让给缓存，把算力让给关键层，把误差控制在业务能接住的地方。它不承诺把大模型塞进任何设备，也不承诺所有场景都能受益。承认这些边界，反而能让压缩回到工程问题本身。