2. 嵌入式AI基础
在模型量化与嵌入式部署工程中，算法工程师最容易犯的错误，是把嵌入式设备当成“缩小版的服务器”。事实上，嵌入式AI的运行环境与云端GPU服务器存在本质差异：算力有限、内存紧张、功耗受限、外设接口固定，甚至编译器与运行时都可能是裁剪过的。理解这些约束，是后续量化策略选择、算子替换、内存复用与部署调优的前提。
一、嵌入式系统架构：从通用到专用
嵌入式系统通常由处理器核心、存储器、外设接口、电源管理与时钟系统组成。与通用计算机不同，嵌入式系统强调“面向特定任务、资源受限、实时性可控”。在AI场景下，系统架构可以粗略分为三层：计算层（MCU/SoC/NPU/DSP）、存储层（Flash、SRAM、DRAM、Cache）、接口层（摄像头、麦克风、传感器、通信总线）。
MCU（微控制器）通常集成CPU核心、Flash、SRAM和常用外设，成本低、功耗低，适合关键词唤醒、简单分类等轻量任务。SoC（片上系统）则把CPU、GPU、NPU、DSP、ISP、内存控制器等集成在一颗芯片上，适合图像识别、语音识别等复杂推理。NPU（神经网络处理单元）是专为矩阵乘加、卷积等算子设计的加速器，能效比远高于通用CPU。DSP（数字信号处理器）擅长滤波、FFT、定点运算，在音频与信号处理链路中仍然不可替代。
二、内存层次：量化部署的隐形战场
嵌入式AI的性能瓶颈往往不在算力，而在内存。上图展示了典型的内存层次：寄存器与Cache最快但容量极小，SRAM/TCM延迟低但通常只有几百KB，DRAM/PSRAM容量可达MB级但带宽和功耗代价高，Flash/eMMC用于持久化存储模型权重。量化部署的核心目标之一，就是让模型权重和中间激活尽量停留在SRAM中，减少对DRAM的访问。
以TFLite Micro为例，其内存规划器会为每个张量分配偏移量，并尝试复用生命周期不重叠的缓冲区。如果模型量化后仍超出SRAM容量，就会触发“arena溢出”错误。此时需要结合算子融合、权重复用、分块计算等策略，而不是简单换更大内存的芯片。
关键参数对照：在Cortex-M7上，SRAM通常为512KB～1MB，主频400～600MHz；在Cortex-A76 + NPU的SoC上，DRAM为2～8GB，NPU算力可达1～10TOPS。两者相差三个数量级，部署策略必须完全不同。
三、算力与功耗约束：能效比才是硬指标
嵌入式设备通常由电池供电或通过PoE供电，功耗预算可能只有几百毫瓦到几瓦。算力再高，如果功耗超标，产品就无法落地。因此，评估硬件平台时不能只看TOPS，而要看TOPS/W（每瓦算力）和实际推理延迟。
| 平台类型 | 典型算力 | 功耗范围 | 适用场景 |
|---|---|---|---|
| MCU（Cortex-M4/M7） | 0.01～0.5 GOPS | 10～200 mW | 关键词唤醒、手势识别 |
| 低功耗SoC + NPU | 0.5～4 TOPS | 0.5～3 W | 人脸识别、目标检测 |
| 边缘计算盒子 | 4～32 TOPS | 5～25 W | 多路视频分析、工业质检 |
| 云端GPU服务器 | 100～1000+ TOPS | 200～700 W | 训练、大规模推理 |
从表中可以看出，嵌入式AI的算力与功耗跨度极大。量化正是连接“高精度模型”与“低功耗硬件”的桥梁：INT8量化通常能带来2～4倍的速度提升和2～4倍的能效改善，而精度损失可以控制在1%以内。
四、常见硬件平台与选型案例
目前主流的嵌入式AI平台包括：STMicroelectronics的STM32系列（MCU，配合X-CUBE-AI）、NXP的i.MX RT系列（跨界MCU）、Espressif的ESP32-S3（带向量指令）、Rockchip的RK3588（NPU 6TOPS）、Google Coral Edge TPU、NVIDIA Jetson Nano/Orin系列、以及Horizon Robotics的旭日系列。选型时需要综合考虑算力、内存、功耗、工具链成熟度和量化支持程度。
以一个智能门锁场景为例：需求是本地人脸识别，功耗低于1W，成本控制在50元以内。可选方案是ESP32-S3 + 轻量级人脸检测模型（如MobileNetV1-0.25），模型量化到INT8后约200KB，推理延迟约300ms。如果换成RK3588，虽然推理更快，但功耗和成本都超出预算。这就是典型的“算力过剩不如能效匹配”。
选型建议：先确定模型量化后的内存占用和单次推理的MAC数量，再反推所需算力与内存带宽，最后匹配平台。不要先选芯片再硬塞模型。
五、常见误区与复盘
- 误区一：只看TOPS，不看内存带宽。NPU算力再高，如果权重无法及时从DRAM搬运到片上，实际利用率可能不到30%。
- 误区二：忽略算子支持度。某些NPU只支持特定卷积核尺寸和激活函数，量化后算子被回退到CPU，反而更慢。
- 误区三：量化后不验证内存峰值。INT8权重虽然减半，但中间激活可能因量化参数校准不当而膨胀，导致arena溢出。
- 误区四：忽视工具链版本。不同版本的TFLite Micro、ONNX Runtime、厂商SDK对量化算子的支持差异很大，部署前必须锁定版本并做回归测试。
# 典型TFLite Micro内存规划日志（示意）
arena_size: 262144 bytes
tensor[0] input 1x96x96x3 INT8 offset=0 size=27648
tensor[1] conv1 1x48x48x8 INT8 offset=27648 size=18432
tensor[2] conv2 1x24x24x16 INT8 offset=46080 size=9216
...
total_used: 258560 bytes
status: OK (fits in arena)复盘来看，嵌入式AI部署不是“把模型跑起来”就结束了，而是要在算力、内存、功耗、成本四重约束下找到最优解。量化是手段，不是目的；理解硬件架构与内存层次，才能让量化策略真正落地。