1. 模型压缩概述：为什么需要模型压缩？
大家好，我是这门课的主讲。今天咱们聊聊模型压缩——这个在AI落地中绕不开的话题。
先问个问题：你辛辛苦苦训练好的模型，精度不错，但一放到手机或嵌入式设备上，跑不动了。为什么？
说白了，模型太大、太慢、太耗电。我最早做端侧部署时，一个ResNet-50在手机上推理一次要3秒多，手机烫得能煎鸡蛋。老板问我：“这玩意儿能上线吗？”我哑口无言。
模型压缩，就是来解决这个问题的。
1.1 为什么需要模型压缩？
咱们从三个维度看：
- 速度：用户等不了。你想想看，一个实时视频检测系统，每帧推理超过30ms，画面就卡顿了。模型压缩能让推理速度提升几倍甚至几十倍。
- 体积：存储和带宽有限。一个BERT模型动辄几百MB，手机App安装包才多大？我见过一个项目，模型太大导致用户下载失败率飙升了15%。
- 功耗：电池扛不住。边缘设备、IoT设备，功耗是硬约束。模型每做一次推理，芯片都在耗电。压缩后的模型，计算量小了，电池自然更耐用。
核心观点：模型压缩不是“锦上添花”，而是“雪中送炭”。没有压缩，很多AI应用根本落不了地。
1.2 模型压缩的三大目标
我习惯把压缩目标归纳为三个词：快、小、省。
| 目标 | 核心指标 | 典型场景 | 我踩过的坑 |
|---|---|---|---|
| 速度 | 推理延迟（ms）、吞吐量（FPS） | 实时检测、语音交互 | 剪枝后速度没提升，因为底层库不支持稀疏计算 |
| 体积 | 模型文件大小（MB） | 移动端App、Web端加载 | 量化后模型小了，但某些层精度崩了 |
| 功耗 | 每帧能耗（mJ）、电池续航 | 智能手表、无人机、安防摄像头 | 只关注算力，忽略了内存访问功耗 |
这三个目标往往互相牵制。比如，单纯追求体积小，可能牺牲速度；只优化速度，功耗不一定降。所以，实际项目中要权衡取舍。
1.3 主流技术路线全景图
模型压缩不是单一技术，而是一套组合拳。我画了一张图，帮你快速建立全局认知。
这张图涵盖了四大主流技术路线：
- 剪枝：去掉不重要的连接或通道。结构化剪枝对硬件友好，非结构化剪枝压缩率更高但需要特殊库支持。
- 量化：用更低精度表示权重和激活。FP32→INT8，模型体积直接缩到1/4，速度翻倍。我做过一个项目，量化后模型从200MB降到50MB，推理快了3倍。
- 知识蒸馏：用大模型（教师）教小模型（学生）。学生模型体积小，但能学到教师的知识。嗯，这里要注意：教师模型不能太强，否则学生学不动。
- 低秩分解：把大矩阵拆成几个小矩阵相乘。适合全连接层和卷积层，但分解后精度容易掉。
我的经验：别指望一种技术解决所有问题。实际落地时，往往是“组合拳”效果最好。比如，先蒸馏一个轻量学生模型，再对它做8bit量化，最后做一次结构化剪枝。这套流程我在三个项目里验证过，精度损失控制在1%以内，速度提升5倍以上。
1.4 技术选型：怎么选？
不同场景，侧重点不同。我列了一个选型参考表：
| 场景 | 首选技术 | 次选技术 | 避坑提醒 |
|---|---|---|---|
| 移动端App | 量化（INT8） | 结构化剪枝 | 注意芯片是否支持INT8加速 |
| 云端推理 | 知识蒸馏 | 非结构化剪枝 | 蒸馏时教师模型不要太大，否则训练成本高 |
| 嵌入式/IoT | 结构化剪枝 + 量化 | 低秩分解 | 内存带宽往往是瓶颈，不只是算力 |
| 自动驾驶 | 量化（FP16） | 知识蒸馏 | 安全场景慎用INT8，精度损失可能致命 |
⚠️ 重要提醒：我曾经在一个项目中，只关注了模型体积，忽略了推理框架对量化算子的支持。结果模型是变小了，但推理速度反而慢了。所以，选技术前，先搞清楚你的部署环境支持什么。
1.5 本章小结
模型压缩不是可选项，而是必选项。三大目标——速度、体积、功耗——决定了你的AI产品能不能真正用起来。
四大技术路线——剪枝、量化、蒸馏、低秩分解——各有优劣。没有银弹，只有组合拳。