会议室里那台旧笔记本刚跑起本地模型，风扇声先盖过了发言。有人半开玩笑说，把模型压小一点不就行了。问题在于，模型压缩常被理解成“把文件变小”，可端侧部署真正卡住的，往往是内存峰值、首字延迟、持续推理时的发热，以及压缩后任务行为是否还稳定。
先问约束，再谈方法
如果目标设备内存紧张，减少参数占用可能直接决定能不能加载；如果目标是交互响应，计算路径和算子支持往往直接决定体验；如果是长时间运行，能耗和温升又会把问题拉回现实。模型压缩不是一个单独动作，更像在若干约束下做组合：量化改变数值表示，剪枝去掉部分连接或结构，蒸馏让一个小模型学习大模型的输出行为。它们各自解决不同层面的压力，也各自带来新的检查项。
量化听起来直接，把浮点换成低比特表示，体积和带宽压力会下降，但异常值、激活分布和算子实现都可能影响结果。剪枝也不是删减本身就会带来收益，非结构化稀疏在通用硬件上未必转化为实际速度，结构化调整又要重新面对精度与工程适配。蒸馏则依赖教师模型和数据分布，学生模型学到的是输出习惯，不是全部能力。把这些方法当成按钮，会忽略它们改变的是模型的行为边界。
压缩之后，模型还是原来那个吗
这是压缩里容易被跳过的问题。离线指标看起来平稳，不代表线上任务没有漂移。一个用于摘要的模型，压缩后可能仍能生成通顺句子，却可能漏掉否定条件；一个用于信息抽取的模型，短文本表现正常，遇到长尾格式就开始不稳定。评估时只看单一分数不够，需要把真实任务拆成若干切片：短输入、长输入、含否定、含数字、格式混乱、连续多轮。不是为了追求漂亮报表，而是确认压缩把余量花在了哪里。
工程上可以保留分层策略：高敏感任务走保守配置，低风险路径接受激进压缩；线上保留回退和灰度，出现异常时能定位到具体算子或版本。压缩的难点不只在算法，也在版本管理和评估闭环。压缩一次就结束的思路，放到持续迭代的系统里往往不成立。
它更像系统工程，而非单点技巧
我倾向于把压缩看成部署约束的翻译过程：把“手机别烫”“旧设备能跑”“响应别拖沓”“任务别漂移”翻译成内存、算力、带宽和评估指标，再选择组合方案。方法本身没有脱离场景的抽象答案。先明确不能让步的约束，再决定压缩力度；从流行方法出发，反而容易绕开场景。
所以，当风扇停下来、手机不烫了，工作并没有结束。还要看压缩后的模型在真实输入前是否仍然可靠。模型压缩的价值，不在于把文件做小这件事本身，而在于让模型在受限环境里保持可解释的取舍。这个取舍说清楚了，部署才算有起点。