2. 边缘计算与AI基础
在讨论边缘AI功耗与实时性优化之前，必须先建立三个基础认知：边缘计算把算力放在哪里、AI推理在设备内部如何一步步执行、以及不同边缘设备的资源边界在哪里。只有把这三件事对齐，后续的量化、剪枝、调度与功耗调优才有明确的优化对象。
一、边缘计算架构：云、边、端三层协同
边缘计算并不是“把云搬到设备上”，而是把计算任务按延迟、带宽、隐私和能耗约束分层放置。典型架构分为三层：端侧（传感器、MCU、手机、摄像头）、边缘侧（网关、边缘服务器、Jetson、工控机）、云侧（训练集群、模型仓库、全局调度）。端侧负责采集与轻量推理，边缘侧负责中等规模推理与多路汇聚，云侧负责训练、模型下发与长周期分析。
这种分层带来的核心收益是：数据不必全部上传，推理可以在毫秒级完成，带宽和云端算力被显著节省。但代价是边缘设备必须自己承担模型加载、内存占用和持续功耗，这正是本课程要解决的主要矛盾。
二、AI推理流程：从输入到输出的六个阶段
边缘AI推理通常包含六个阶段：数据采集 → 预处理 → 模型加载 → 前向计算 → 后处理 → 输出/上报。其中前向计算是算力消耗主体，但预处理和后处理在边缘设备上往往被低估，尤其是图像缩放、归一化和NMS，可能占用可观的CPU时间。
- 数据采集：摄像头、麦克风、传感器以固定频率产生数据，决定推理的输入节奏。
- 预处理：resize、归一化、量化、格式转换（如NHWC转NCHW）。
- 模型加载：将模型权重从存储读入内存，首次加载耗时明显。
- 前向计算：卷积、矩阵乘、激活函数，是功耗与延迟的主要来源。
- 后处理：解码、NMS、阈值过滤、坐标映射。
- 输出/上报：本地控制、屏幕显示或通过MQTT/HTTP上报边缘侧。
三、常见边缘设备及其资源约束
不同设备的资源边界差异巨大，选型和优化策略必须与硬件匹配。下表给出四类典型设备的资源画像与适用场景。
| 设备类型 | 典型算力 | 内存 | 功耗 | 适用模型 | 主要约束 |
|---|---|---|---|---|---|
| MCU（如STM32） | < 1 GOPS | 几十KB ~ 几MB | mW 级 | TinyML、关键词唤醒 | 内存极小、无操作系统 |
| 树莓派 4B | ~ 0.1 TOPS（CPU） | 2~8 GB | 3~7 W | MobileNet、YOLO-tiny | 无NPU、散热有限 |
| Jetson Nano / Orin | 0.5 ~ 40 TOPS | 4~32 GB | 5~25 W | YOLOv5/v8、分割模型 | 功耗墙、散热设计 |
| 手机（骁龙/天玑） | 数 TOPS ~ 数十 TOPS | 6~16 GB | 1~5 W（推理） | MobileNet、轻量Transformer | 热降频、后台限制 |
四、案例与场景：智能摄像头的人形检测
以一个园区智能摄像头为例：摄像头端（端侧）以15fps采集1080p画面，若全部上传云端，带宽约4Mbps/路，100路就是400Mbps，成本极高。实际方案是在边缘网关（Jetson Orin）上部署YOLOv8n，先做人形检测，仅当检测到人时才上传截图和坐标。
# 边缘侧推理伪代码
frame = camera.read() # 采集
input_tensor = preprocess(frame) # resize + 归一化
boxes = model.infer(input_tensor) # 前向计算
results = nms(boxes, iou_thres=0.45) # 后处理
if len(results) > 0:
mqtt.publish("event/person", results) # 仅事件上报
该方案把上行带宽降低约90%，推理延迟控制在30ms以内。但代价是Jetson持续运行在15W左右，若散热不足会触发降频，延迟抖动增大。这说明实时性与功耗是一对需要联合调优的变量。
五、常见误区与复盘
- 误区一：只看峰值算力。TOPS高不代表实际推理快，内存带宽、算子支持、量化精度都会影响真实性能。
- 误区二：忽略预处理开销。在树莓派上，图像resize可能比模型前向还慢，必须用硬件加速或流水线并行。
- 误区三：把云侧模型直接搬到端侧。未量化、未剪枝的大模型在边缘设备上往往无法达到实时要求。
- 误区四：忽视热设计。Jetson和手机在持续推理下会降频，标称算力无法长期维持。