边缘AI基础：边缘计算与云计算的对比、边缘AI的硬件平台与软件栈
在正式进入人体活动识别（Human Activity Recognition, HAR）项目之前，我们必须先厘清一个核心问题：为什么在边缘端做AI推理，而不是把所有数据都上传到云端？这不仅是技术选型问题，更是产品化落地的战略问题。本章将从边缘计算与云计算的本质差异出发，深入剖析MCU、GPU、NPU三类硬件平台的适用边界，并梳理TensorFlow Lite、ONNX Runtime、Edge Impulse三条主流软件路径的工程特性，为后续传感器融合与模型部署打下坚实的架构基础。
上图展示了云端与边缘在系统架构上的核心差异。云端拥有近乎无限的算力，但物理距离和网络不确定性带来了不可控的时延；边缘设备虽然资源受限，却能在数据产生的源头完成实时决策。对于人体活动识别这类需要毫秒级响应的应用，边缘计算几乎是唯一合理的选择。
2.1 边缘计算与云计算的本质对比
核心原理：从“数据搬运”到“计算下沉”
传统云计算模式中，传感器数据需要经过“采集→传输→云端推理→结果返回”四个阶段。以IMU（惯性测量单元）数据为例，一个以100Hz采样、6轴数据（加速度+陀螺仪）的传感器，每秒产生约1200字节数据。如果持续上传，一天将产生约100MB流量。这不仅是带宽成本问题，更关键的是，当网络抖动或断连时，整个系统将陷入瘫痪。
边缘计算的核心思想是将推理任务下沉到靠近数据源的位置。在HAR场景中，这意味着MCU或嵌入式GPU直接读取IMU数据，在本地完成特征提取和分类，仅将高层的语义结果（如“正在走路”“跌倒”）通过低带宽链路发送给云端或网关。这种模式将时延从百毫秒级压缩到个位数毫秒，同时大幅降低功耗和流量成本。
判断方法：五个维度决定部署位置
| 维度 | 云端优先 | 边缘优先 |
|---|---|---|
| 时延要求 | >100ms可接受 | <10ms必须保证 |
| 数据隐私 | 可脱敏上传 | 敏感数据不出设备 |
| 网络稳定性 | 依赖可靠连接 | 离线必须可用 |
| 功耗预算 | 无严格限制 | 电池供电，mW级 |
| 模型复杂度 | 大规模深度学习 | 轻量化模型（<10MB） |
在实际项目中，我们通常采用“边缘为主、云端为辅”的混合架构。边缘设备负责实时推理和紧急响应，云端负责模型更新、跨设备数据聚合和长期趋势分析。
案例拆解：可穿戴跌倒检测系统的架构选型
假设我们要设计一款老人佩戴的跌倒检测手环。初始方案采用云端推理：手环通过蓝牙将IMU数据转发到手机，手机再通过4G上传到云端。实测发现，从跌倒发生到云端返回报警平均耗时1.8秒，且在地下室或电梯内完全失效。更严重的是，连续上传导致手环电池仅能维持6小时。
重新设计后，我们在手环的Cortex-M4F MCU上部署了一个12KB的决策树模型（基于时域特征：合加速度幅值、姿态角变化率）。模型在本地完成推理，仅在检测到疑似跌倒时通过BLE发送报警信号。改进后，端到端时延降至80ms，电池续航提升到14天，且完全支持离线工作。这个案例清晰地展示了边缘计算在实时性和功耗上的决定性优势。
2.2 边缘AI硬件平台：MCU、GPU与NPU的选型逻辑
核心原理：算力与功耗的帕累托前沿
边缘AI硬件可以看作一个从“极低功耗微控制器”到“高性能嵌入式GPU”的连续谱系。MCU（如STM32F4、ESP32-S3）集成ARM Cortex-M系列内核，主频通常在80-240MHz，拥有数十至数百KB的SRAM，功耗在几十mW量级。它们适合运行经过极致量化的轻量模型（如决策树、二值化神经网络）。GPU（如NVIDIA Jetson Orin）则提供数百GFLOPS的算力，但功耗高达5-60W，适合需要处理视频流或复杂CNN的场景。NPU（神经网络处理单元）是介于两者之间的“专用加速器”，例如瑞萨RA8系列、恩智浦i.MX 8M Plus，它们通过硬件卷积引擎实现低功耗下的高效推理。
判断方法：三步锁定目标平台
- 计算需求估算：先确定模型所需的乘加运算次数（MACs）。例如，一个1D-CNN处理6通道IMU数据，每帧128个采样点，约需5M MACs。若要求实时处理（100帧/秒），则需500M MACs/s。
- 功耗预算匹配：可穿戴设备通常限制在50mW以内，此时只能选择MCU+NPU组合；智能音箱等插电设备可放宽到2-5W，可选用高性能GPU。
- 开发效率权衡：MCU开发需要交叉编译和底层优化，周期较长；GPU平台支持Python和主流深度学习框架，迭代速度快，但成本更高。
| 平台类型 | 代表芯片 | 算力 | 功耗 | 典型应用 |
|---|---|---|---|---|
| MCU | STM32H7 | ~1 GOPS | 50-200mW | 智能手环、工业传感器 |
| GPU | Jetson Orin Nano | ~40 TOPS | 5-10W | 机器人、边缘视频分析 |
| NPU | i.MX 8M Plus | ~2.3 TOPS | 1-2W | 智能家居中控、工业视觉 |
实战场景：传感器融合项目的硬件选型
在本课程的HAR项目中，我们推荐使用ESP32-S3作为入门平台。它集成了240MHz双核Xtensa LX7处理器、512KB SRAM，并内置向量指令扩展，可以高效运行INT8量化的MobileNetV1（输入为6通道IMU数据）。如果后续需要融合摄像头数据，则建议升级到Jetson Orin Nano，利用其GPU加速处理视觉特征。
2.3 边缘AI软件栈：从训练到部署的工程链路
核心原理：模型转换与运行时优化
边缘AI软件栈的核心任务是将云端训练的模型转换为目标硬件可高效执行的格式。这个过程涉及三个关键步骤：模型优化（剪枝、量化）、格式转换（生成中间表示）、运行时推理（调用硬件加速单元）。TensorFlow Lite（TFLite）和ONNX Runtime分别背靠Google和微软生态，而Edge Impulse则提供从数据采集到部署的完整SaaS平台。
操作流程：TFLite在MCU上的部署路径
# 1. 训练并保存模型（Keras示例）
model.save('har_model.h5')
# 2. 转换为TFLite格式并量化
converter = tf.lite.TFLiteConverter.from_keras_model(model)
converter.optimizations = [tf.lite.Optimize.DEFAULT]
converter.representative_dataset = representative_dataset_gen
tflite_model = converter.convert()
# 3. 生成C++字节数组（用于MCU）
with open('model.tflite', 'rb') as f:
data = f.read()
c_array = ', '.join(f'0x{b:02x}' for b in data)
print(f'const unsigned char model[] = {{{c_array}}};')ONNX Runtime则更适合需要跨框架兼容的场景。例如，你可以用PyTorch训练模型，导出为ONNX格式，再通过ONNX Runtime的C API在Linux嵌入式设备上运行。其优势在于支持更丰富的算子集，且对动态输入形状的处理更灵活。
案例拆解：Edge Impulse端到端工作流
Edge Impulse将整个流程封装为可视化流水线：数据采集（通过手机或开发板蓝牙上传IMU样本）→特征工程（自动提取时域/频域特征）→模型训练（内置多种分类器）→部署（一键生成Arduino库或C++源码）。我们曾在一个跌倒检测项目中，仅用2小时就完成了从数据标注到在STM32上部署的全流程，准确率达到94%。但需要注意的是，该平台对自定义网络结构的支持有限，且免费版有数据量限制。
常见误区与复盘
- 误区一：认为量化一定会导致精度大幅下降。实际上，对于IMU数据这类低维输入，INT8量化通常能保持95%以上的原始精度。
- 误区二：忽略内存布局。在MCU上，TensorFlow Lite Micro要求所有张量内存对齐到4字节，否则会触发硬件异常。
- 误区三：混淆“推理框架”与“训练框架”。TensorFlow Lite只能做推理，不能训练；若需在设备端增量学习，需额外引入TinyML框架。
总结本章，边缘AI并非云计算的简单替代，而是互补关系。硬件选型应遵循“算力够用、功耗可控、成本可接受”的原则，软件栈则需根据团队技术栈和产品迭代速度灵活选择。在下一阶段的实战中，我们将基于ESP32-S3和TFLite Micro，逐步搭建一个完整的IMU数据采集与实时识别系统。