1、边缘计算与模型压缩概述
边缘计算的定义
边缘计算，说白了就是把计算能力从云端搬到离数据源更近的地方。你想想看，传统的云计算模式是「设备采集数据 → 上传云端 → 云端处理 → 返回结果」，这一来一回，延迟就上去了。
我个人习惯把边缘计算理解成「本地大脑」。它是在网络边缘侧，靠近物或数据源头的分布式计算架构。举个例子，你家的智能摄像头如果靠云端做人脸识别，每次都要等数据传上去再传回来，那门禁响应得等好几秒，用户体验就很差。
我在项目中遇到过不少这样的场景：工厂里的质检摄像头，每秒要处理几十张图片。如果全走云端，网络带宽根本扛不住。所以边缘计算的核心价值就三个字——低延迟、高带宽、本地化。
边缘计算的关键特征：
- 数据在本地处理，减少网络传输
- 响应时间通常在毫秒级
- 支持离线运行，不依赖云端
- 保护数据隐私，敏感数据不出设备
为什么需要模型压缩
好，问题来了。既然边缘设备这么好用，那直接把云端训练好的模型部署上去不就行了？
嗯，这里要注意。边缘设备的资源是非常有限的。我见过很多嵌入式设备，内存只有几百MB，算力可能连云端GPU的百分之一都不到。你想想看，一个ResNet-152模型，参数有6000多万，大小超过200MB。这种模型放到边缘设备上，根本跑不起来。
为什么会这样？主要有三个瓶颈：
- 存储瓶颈：边缘设备的Flash和RAM都很小，大模型装不下
- 计算瓶颈：边缘CPU/GPU算力有限，推理速度慢得无法接受
- 功耗瓶颈：大模型推理时功耗高，电池供电的设备撑不了多久
我曾经在一个智能门锁项目上吃过亏。当时直接把一个MobileNetV2部署上去，结果推理一次要3秒，功耗还特别高，电池两天就没电了。后来做了量化压缩，推理时间降到200毫秒，功耗也降了70%。
我的经验：模型压缩不是可选项，而是边缘部署的必选项。如果你想把AI模型真正落地到产品中，压缩这一步绕不开。
模型压缩的挑战
压缩听起来简单，做起来坑不少。我踩过的坑，今天跟大家分享一下。
挑战一：精度损失
压缩必然会带来精度下降。你想想看，把32位浮点数变成8位整数，信息肯定有损失。关键是怎么把损失控制在可接受范围内。我记得有一次做INT8量化，模型精度从98%掉到了85%，后来花了整整两周调校准数据集，才恢复到96%。
挑战二：硬件适配
不同的边缘设备，支持的指令集不一样。有的芯片支持INT8加速，有的只支持FP16。我建议你在选型前先确认好目标硬件的算子支持情况，不然压缩完了发现跑不了，那就尴尬了。
挑战三：部署复杂度
压缩后的模型往往需要特定的推理框架。比如TensorRT、OpenVINO、TFLite这些。每个框架都有自己的格式和限制，迁移起来挺折腾的。
避坑指南：我曾经在一个项目里，把模型压缩到原来的1/4，精度只掉了0.5%，心里还挺美。结果部署到设备上一跑，发现某些算子不支持，推理速度反而更慢了。所以压缩前一定要先做硬件兼容性评估。
模型压缩的目标
说了这么多挑战，那压缩的目标到底是什么？我个人总结为四个字——小、快、准、省。
| 目标 | 说明 | 量化指标 |
|---|---|---|
| 小 | 模型体积小，能装进边缘设备 | 模型大小 < 设备Flash容量 |
| 快 | 推理速度快，满足实时性要求 | 推理延迟 < 业务要求阈值 |
| 准 | 精度损失在可接受范围内 | 精度下降 < 1%~3% |
| 省 | 功耗低，适合电池供电设备 | 功耗 < 设备热设计功耗 |
说白了，压缩就是在四个目标之间找平衡。你不可能既要模型极小，又要精度完全不掉，还要推理飞快。实际项目中，我一般会先定一个「可接受的精度下限」，然后在这个前提下尽量压缩。
举个例子，一个目标检测模型，业务要求mAP不能低于85%。那我就先压缩到85%的精度，看看模型大小和推理速度是多少。如果还不够小，再考虑剪枝或者知识蒸馏。
我的建议：压缩不是一锤子买卖。我习惯用「压缩-评估-调整」的循环来做。先快速试一个方案，看精度和性能，不行再换。别想着一步到位，那容易翻车。
小结
这一章我们聊了边缘计算是什么，为什么需要模型压缩，以及压缩过程中会遇到哪些坑。说白了，边缘计算让AI真正落地到实际场景中，而模型压缩是让AI能在资源受限的设备上跑起来的关键技术。
下一章，我会带大家深入聊聊量化的基本原理。到时候会讲定点数和浮点数的转换，还有对称量化和非对称量化的区别。这些都是实际项目中天天要用的东西，咱们到时候细聊。