一、嵌入式AI概述：什么是嵌入式AI、为什么需要推理框架、主流框架概览与选型痛点
1.1 到底什么是嵌入式AI？
嵌入式AI，说白了就是把深度学习模型塞进资源受限的设备里跑。比如你家的智能摄像头、语音助手、工业传感器，这些设备没有强大的GPU，内存可能只有几百兆，甚至几十兆。
我刚开始接触这个领域时，也觉得挺魔幻的——一个只有几百MHz的Cortex-M核，居然能跑人脸检测？后来做多了才明白，嵌入式AI的核心不是「跑得动」，而是「跑得巧」。
它和云端AI最大的区别在于：数据不上云，推理在本地。你想想看，一个工业质检摄像头，每秒钟要处理30帧画面，如果每帧都上传到云端，延迟和带宽都受不了。嵌入式AI就是在设备端直接完成推理，只把结果传出去。
嵌入式AI的典型特征：
- 算力受限：CPU主频通常200MHz-2GHz，无独立GPU
- 内存紧张：RAM从几十KB到几GB不等
- 功耗敏感：电池供电场景下，功耗可能限制在几瓦甚至毫瓦级
- 实时性要求高：比如自动驾驶的决策延迟必须小于100ms
1.2 为什么需要推理框架？
你可能会问：我直接用TensorFlow/PyTorch训练好的模型，放到板子上跑不行吗？
嗯，这里要注意。训练框架和推理框架完全是两码事。训练框架关心的是梯度下降、反向传播，而推理框架只关心一件事——怎么把前向计算跑得又快又省。
我记得第一次在树莓派上直接跑一个训练好的ResNet-50，结果一张图片推理花了3秒多。后来换了推理框架，做了量化、算子融合，直接降到200毫秒。这就是推理框架的价值。
具体来说，推理框架解决了这几个核心问题：
- 模型压缩：把FP32的权重量化成INT8，模型体积缩小4倍，速度提升2-4倍
- 算子优化：针对特定硬件（ARM、RISC-V、NPU）做汇编级优化
- 内存管理：复用张量内存，避免频繁申请释放
- 异构计算：自动把计算任务分配到CPU、GPU、NPU上
我的经验：选推理框架时，别只看benchmark上的跑分。我在项目中遇到过，某个框架在骁龙865上跑得飞快，换到RK3588上直接崩了。硬件适配的深度，往往比纸面性能更重要。
1.3 主流推理框架概览
目前市面上主流的嵌入式推理框架，我按生态和适用场景分成了三类：
| 框架名称 | 主要维护方 | 适用硬件 | 核心优势 |
|---|---|---|---|
| TensorFlow Lite | ARM、x86、Android | 生态最全，文档丰富 | |
| ONNX Runtime | Microsoft | 多平台 | 模型格式统一，跨框架 |
| NCNN | 腾讯 | ARM、x86、Vulkan | 轻量级，移动端优化好 |
| MNN | 阿里巴巴 | ARM、x86、Metal | 推理速度快，内存占用低 |
| Tengine | OPEN AI LAB | ARM、RISC-V、NPU | 国产化，异构支持好 |
| Paddle Lite | 百度 | ARM、x86、NPU | 与PaddlePaddle深度绑定 |
我个人习惯把框架分成「大而全」和「小而美」两类。TFLite和ONNX Runtime属于前者，什么都能跑，但体积大、依赖多。NCNN和MNN属于后者，专为移动端设计，代码精简，但支持的算子相对少一些。
1.4 选型痛点，我踩过的坑
选推理框架这件事，说难不难，说简单也不简单。我总结了几条血泪教训：
痛点一：算子兼容性
我曾经把一个训练好的YOLOv5模型，用TFLite转换后，发现有个自定义的Focus层不支持。折腾了两天，最后只能手写算子。所以选框架前，一定要先检查你的模型里有没有「冷门算子」。
痛点二：硬件适配深度
有些框架号称支持NPU，但实际只做了CPU fallback。你想想看，花了大价钱买NPU芯片，结果推理还是跑在CPU上，那还不如直接用便宜的方案。我建议选框架时，直接问厂商要NPU的benchmark数据，别只看宣传。
痛点三：社区活跃度
框架的bug修复速度，直接决定你的开发进度。我遇到过某个小众框架，提了issue两周没人回，最后只能自己啃源码。相比之下，TFLite和NCNN的社区响应就快得多。
1.5 我的选型建议
如果你刚开始做嵌入式AI，我建议从NCNN或TFLite入手。原因很简单：
- NCNN：代码量小，容易看懂，适合学习原理
- TFLite：生态最全，遇到问题网上基本都能搜到答案
等你有了一定经验，再根据具体硬件去选。比如用瑞芯微的芯片，可以看看RKNN；用寒武纪的，就看看CNRT。说白了，硬件厂商自己的SDK，往往优化得最到位。
嗯，这一章先讲到这里。下一章我会手把手带你搭建NCNN的推理环境，并跑通第一个分类模型。到时候你会发现，嵌入式AI其实没那么神秘。