第一章：模型压缩概述——为什么需要模型压缩？
说实话，我刚开始做模型部署那会儿，也想过这个问题。
模型在服务器上跑得好好的，准确率也漂亮，干嘛非要折腾压缩？直到我第一次把训练好的模型往嵌入式设备上一放——好家伙，512MB的内存直接爆了，推理速度慢得像幻灯片。那一刻我才真正明白：模型压缩不是锦上添花，而是落地的前提。
1.1 为什么需要模型压缩？
你想想看，现在主流的视觉模型，像ResNet-152、EfficientNet-B7，参数量动辄几千万甚至上亿。在GPU集群上训练没问题，但到了手机、摄像头、自动驾驶边缘盒子上，情况就完全不一样了。
我归纳了三个最核心的痛点：
- 存储瓶颈：一个ResNet-152模型文件大概240MB。手机App动辄几十个模型，光模型文件就占几个G，用户不卸载才怪。
- 内存瓶颈：推理时中间特征图占的内存往往是模型本身的3-5倍。我在项目中遇到过，模型只有50MB，但推理时内存飙到800MB，直接OOM崩溃。
- 算力瓶颈：边缘设备的算力通常是GPU的百分之一。一个在V100上只要10ms的模型，到了树莓派上可能要跑10秒——这谁受得了？
核心结论：模型压缩解决的是「模型太大跑不动」和「跑得太慢来不及」这两个工程落地中最头疼的问题。
1.2 模型压缩的三大目标
做压缩这么多年，我个人习惯把目标总结成三个词：体积小、速度快、精度高。但注意，这三者不是独立的，而是互相制约的三角关系。
| 目标 | 具体含义 | 典型指标 | 我踩过的坑 |
|---|---|---|---|
| 体积小 | 模型文件占用的存储空间更小 | 模型文件大小（MB/GB） | 曾经把模型从200MB压到20MB，结果精度掉了8个点，白干 |
| 速度快 | 推理延迟更低，吞吐量更高 | FPS、延迟（ms） | 剪枝后速度没提升，后来发现是底层库不支持稀疏计算 |
| 精度高 | 压缩后准确率下降在可接受范围内 | Top-1/Top-5准确率 | 量化到INT8时，分类任务掉点0.5%，但检测任务掉了3% |
1.3 三大目标的权衡艺术
说白了，模型压缩就是在做「取舍」。我经常跟团队说：没有免费的午餐。你想把体积压到原来的十分之一，还想速度翻倍，同时精度一点不掉——这基本不可能。
但好消息是，大部分业务场景并不要求精度完全无损。比如：
- 手机上的美颜滤镜：精度掉1-2%用户根本感知不到
- 安防监控的人脸检测：只要不出现漏检，掉点0.5%完全可以接受
- 工业质检：这个就得谨慎了，掉点0.1%可能就意味着多出几千个次品
我的经验：做压缩前，先跟业务方确认精度容忍度。我曾经吃过亏，花了三周把模型压到极致，结果业务方说「其实掉1%以内就行」——白白浪费了两周时间。
1.4 什么时候不该做压缩？
嗯，这里要注意。不是所有场景都需要压缩。我总结了几种「别折腾」的情况：
- 服务器端推理：如果模型跑在云端GPU集群上，带宽和算力都充足，压缩反而可能引入额外开销
- 精度敏感型任务：比如医疗影像诊断、金融风控，精度是第一位，压缩带来的风险不值得
- 快速原型验证：项目初期先跑通流程，压缩优化可以放到后面再做
避坑指南：我曾经在一个快速迭代的项目中，一上来就做量化压缩，结果每次模型更新都要重新校准数据集，迭代速度反而变慢了。后来学乖了——先跑通，再优化。
1.5 压缩技术的全景图
为了让你有个整体印象，我把主流压缩技术列了个表。后面每一章我们都会深入讲解：
| 技术方向 | 核心思路 | 典型方法 | 我常用的场景 |
|---|---|---|---|
| 剪枝 | 去掉不重要的连接或通道 | 结构化剪枝、非结构化剪枝 | 移动端分类模型 |
| 量化 | 降低数值精度（FP32→INT8） | 训练后量化、量化感知训练 | 边缘端检测模型 |
| 知识蒸馏 | 大模型教小模型 | Logit蒸馏、特征蒸馏 | 小模型精度不够时 |
| 轻量化设计 | 从零设计更高效的网络 | MobileNet、ShuffleNet | 新项目起步阶段 |
| 矩阵分解 | 用低秩矩阵近似高秩矩阵 | SVD分解、CP分解 | 全连接层较多的模型 |
我个人习惯的做法是：先量化，再剪枝，最后蒸馏。这个顺序不是固定的，但大部分场景下，量化带来的收益最大、成本最低，适合优先做。
1.6 本章小结
啰嗦了这么多，其实就三句话：
- 为什么压缩：因为模型太大、太慢、太占资源，跑不到目标设备上
- 三大目标：体积小、速度快、精度高——但三者需要权衡
- 怎么做：剪枝、量化、蒸馏、轻量化设计、矩阵分解，各有适用场景
下一章，我会带你从最常用的剪枝技术开始，手把手教你如何给模型「瘦身」。到时候我会分享一个我在安防项目中的实战案例——那个模型从120MB压到15MB，速度提升了4倍，精度只掉了0.3%。嗯，这个案例值得期待。