深夜给一台旧手机装上新功能，模型文件还没跑起来，内存先告急。做端侧应用的人常遇到这种场景：算法在训练环境里表现正常，到了目标设备，延迟、发热、存储都开始紧张。模型压缩因此被频繁提起，但它并不是一个按钮，按下去就能把大模型变成小模型。
先看瓶颈在哪里
压缩之前，值得先问：限制到底来自哪里。是权重占用存储，是运行时内存峰值过高，是算子在某类芯片上效率不好，还是功耗预算不允许长时间推理。不同瓶颈对应不同手段。量化主要降低数值位宽，可能减少存储和带宽压力；剪枝试图去掉冗余连接或结构，但稀疏模型在通用硬件上未必带来速度收益；知识蒸馏让较小模型学习较大模型的输出行为，重点在训练策略而非单纯删参数。把这几类方法统称为模型压缩没问题，但落到工程里，每一条路径的代价并不一样。
变小不等于变快
一个常见的误会是：参数少了，推理一定快。实际还要看硬件是否支持低精度运算，编译器能否把算子融合，内存访问是否连续，批处理大小是否合适。某些压缩后的模型在纸面指标上看起来不错，端到端却因为反量化开销或算子回退而变慢。评估时把完整链路放到目标设备上跑，只看文件大小并不够。尤其当模型被拆到不同处理器上执行，调度和数据搬运本身也会吃掉收益。
评估要回到业务指标
压缩会改变模型行为，尤其在小样本、长尾输入或边界场景中，误差可能被放大。因此评估不能只盯一个平均分数，还要看任务真正关心的部分：误触发是否增加，响应是否稳定，极端输入下是否退化。对很多产品来说，可接受的压缩方案是在质量、延迟、内存和功耗之间找到可持续的组合，而不是追求最小体积。这也是模型压缩常被忽略的部分：它更像一场面向约束的设计，而不是一次孤立的文件瘦身。
压缩前可以排查的四件事
- 目标设备的内存峰值出现在加载、推理还是后处理阶段。
- 瓶颈是算力、带宽、算子支持，还是功耗与散热限制。
- 业务能否接受特定输入上的质量波动，评估集是否覆盖这些输入。
- 压缩后的模型能否被现有工具链稳定编译和部署，回退路径是否清楚。
这些问题看起来朴素，却能避免把压缩做成一次只在实验室成立的演示。模型压缩的价值，往往不在模型文件变小那一刻，而在它让原本跑不起来的场景有了可维护的落地方式。