1、嵌入式AI模型部署概述：边缘计算与嵌入式AI、模型部署的挑战与机遇、性能评估的核心指标
各位同学，欢迎来到《嵌入式平台模型部署性能评估手册》的第一章。我是你们的老朋友，一个在嵌入式AI坑里摸爬滚打了好几年的工程师。今天咱们不聊虚的，直接切入正题——聊聊嵌入式AI模型部署到底是个什么事儿。
说实话，我刚入行那会儿，觉得把模型塞进芯片里跑起来就行了。后来才发现，这事儿远没那么简单。你想想看，一个在服务器上跑得飞快的模型，到了嵌入式设备上可能连动都动不了。为什么会这样？因为环境完全不同了。
1.1 边缘计算与嵌入式AI
先说说边缘计算。这个概念其实不新，但最近几年特别火。说白了，就是把计算能力从云端拉到离数据源更近的地方。比如摄像头、传感器、工业控制器这些设备，它们本身就能做推理，不用非得把数据传到云端再等结果。
嵌入式AI呢，就是在这个边缘侧跑AI模型。我习惯把嵌入式AI分成两类：一类是MCU级别的，比如STM32、ESP32这种，资源极其有限；另一类是应用处理器级别的，比如树莓派、Jetson Nano这种，稍微宽裕一些。但不管哪一类，都跟云端服务器没法比。
核心区别：云端部署追求的是“准不准”，嵌入式部署追求的是“能不能跑起来、跑得快不快、功耗够不够低”。
我记得有一次给客户做智能门锁的人脸识别方案。模型在PC上精度98%，但移植到MCU上后，单次推理耗时3秒多，电池撑不过一天。客户直接说：“这玩意儿还不如用密码锁。”嗯，这就是嵌入式AI的现实——模型再准，跑不动就是废的。
1.2 模型部署的挑战与机遇
挑战有哪些？我列几个最头疼的：
- 算力瓶颈：嵌入式芯片的算力通常是云端GPU的千分之一甚至万分之一。你想想看，一个ResNet-50在服务器上跑一次只要几毫秒，在MCU上可能要几秒钟。
- 内存限制：很多MCU的RAM只有几百KB，Flash也就几MB。模型参数稍微大一点就装不下。我遇到过最夸张的一次，模型量化后还有2.3MB，但目标芯片的Flash只有1MB——只能从头剪枝。
- 功耗约束：电池供电的设备，功耗是硬指标。推理一次消耗多少毫焦，直接影响续航。我曾经为了省0.5mA的电流，把模型从FP32量化到INT8，精度掉了0.3%，但功耗降了40%。值不值？我觉得值。
- 工具链碎片化：每个芯片厂商都有自己的部署工具。TensorFlow Lite、ONNX Runtime、TVM、TensorRT……你得挨个学。我建议新手先盯住一个平台吃透，别贪多。
但机遇同样明显。边缘AI的市场正在爆发。智能家居、工业视觉、可穿戴设备、自动驾驶……这些场景都需要在本地做实时推理。而且，硬件厂商也在拼命优化——NPU、TPU、DSP这些加速器越来越普及。说白了，现在正是入局的好时机。
我的建议：别一上来就追求最先进的模型。先把手头的硬件摸透，搞清楚它能跑什么量级的模型，再反过来选模型结构。这叫“硬件驱动设计”，比“模型驱动设计”靠谱得多。
1.3 性能评估的核心指标
好，到了最关键的部分。怎么判断一个模型在嵌入式平台上部署得好不好？不能光凭感觉，得有数据说话。我个人习惯关注四个核心指标：
1.3.1 延迟（Latency）
延迟就是模型从输入到输出花的时间。单位通常是毫秒。这个指标最直观，也最容易被用户感知。比如智能门锁，如果人脸识别延迟超过1秒，用户体验就很差。
但要注意，延迟不是固定的。它受很多因素影响：
- 输入数据大小（比如图像分辨率）
- 模型结构（层数、通道数）
- 硬件负载（CPU是否在干别的活）
- 是否使用加速器（NPU、GPU）
我习惯的做法是：在设备空闲时测10次，取平均值；再在设备满载时测10次，取平均值。两个数据都要记录。为什么？因为实际场景中设备不可能永远空闲。
避坑指南：我曾经只测了空闲时的延迟，结果产品上线后用户投诉反应慢。查了半天才发现，设备后台在同时跑OTA升级和日志上传。从那以后，我每次测试都会加上“背景负载”这一项。
1.3.2 吞吐量（Throughput）
吞吐量是单位时间内能处理的数据量。比如每秒能处理多少帧图像，或者每分钟能处理多少次推理请求。这个指标对视频流处理、批量推理这类场景特别重要。
延迟和吞吐量是相关的，但不是一回事。举个例子：一个模型单次推理延迟是10ms，但如果你用流水线并行，吞吐量可能达到每秒200帧。反过来，如果延迟是5ms但只能串行处理，吞吐量可能只有每秒100帧。
| 场景 | 更关注延迟 | 更关注吞吐量 |
|---|---|---|
| 智能门锁 | ✅ | |
| 视频监控 | ✅ | |
| 工业质检 | ✅ | ✅ |
| 语音唤醒 | ✅ |
1.3.3 功耗（Power Consumption）
这个指标在嵌入式领域比延迟还重要。电池供电的设备，功耗直接决定续航。功耗通常用毫瓦（mW）表示，但更专业的做法是测“每次推理的能耗”，单位是毫焦（mJ）。
怎么测？我一般用两种方法：
- 硬件测量：用电流探头接在电源线上，配合示波器或功率分析仪。最准，但需要设备。
- 软件估算：通过芯片的PMU（电源管理单元）读取功耗数据。方便，但精度稍差。
我记得有一次做智能音箱的唤醒词检测。模型在DSP上跑，功耗只有2mW，但换到CPU上跑就变成了15mW。客户要求续航6个月，算下来只能用CPU方案的话电池得大一倍。最后我们硬是把模型从CPU搬到了DSP上，精度没降，功耗降了7倍。
小技巧：量化是降功耗的利器。从FP32降到INT8，功耗通常能降50%-70%。但要注意，有些芯片对INT8的支持并不好，反而更慢。一定要实测。
1.3.4 内存占用（Memory Footprint）
内存占用包括两部分：模型参数占用的Flash（或ROM），以及运行时占用的RAM。嵌入式设备的内存是硬约束，超了就跑不起来。
我习惯用这个公式估算：
总内存占用 = 模型参数大小 + 中间激活值大小 + 输入输出缓冲区大小 + 系统开销其中中间激活值往往被忽略，但它可能比模型参数还大。比如一个深度卷积网络，中间层的特征图可能占几MB的RAM。我建议用工具（比如Netron或TensorFlow Lite的analyzer）提前分析一下，别等到烧录了才发现内存不够。
另外，内存占用和延迟、功耗是相互影响的。比如你用更大的batch size可以提高吞吐量，但RAM占用会成倍增加。你得在它们之间找平衡。
总结一下这四个指标的关系：
- 延迟和吞吐量：通常负相关，但可以通过并行化改善
- 功耗和延迟：正相关，跑得快通常功耗高
- 内存占用：影响其他三个指标，但往往是最硬的约束
没有完美的方案，只有最适合你场景的方案。
好了，第一章就到这里。内容不多，但都是基础中的基础。下一章我们会深入聊模型量化的具体方法，包括怎么选量化位宽、怎么处理量化误差。到时候我会拿一个实际项目中的案例来拆解，保证干货满满。
记住一句话：嵌入式AI部署，不是把模型塞进去就完事了，而是要在延迟、吞吐量、功耗、内存之间找到那个“刚刚好”的点。这个点，就是你的产品竞争力。
公众号:蓝海资料掘金营，微信deep3321