📚 课程目录第1章边缘AI与Tengine初探

1. 边缘AI与Tengine初探

各位同学，欢迎来到《边缘AI图像识别》的第一章。我是你们这门课的主讲，一个在嵌入式AI领域摸爬滚打了七八年的工程师。今天咱们不聊虚的，直接切入正题——边缘AI到底是什么？为什么我们需要Tengine这样的框架？以及，你手头那块开发板，到底能不能跑起模型来？

先说说概念。边缘计算，说白了就是把计算能力从云端下沉到靠近数据源的地方。你想想看，一个摄像头采集到画面，如果非要传到云端去识别，网络延迟、带宽成本、数据隐私，全是坑。

我几年前做过一个智慧安防项目，摄像头在偏远矿区，4G信号时好时坏。每次人脸识别请求发到云端，来回要两三秒。等结果回来，人早走远了。后来我们把模型直接部署在摄像头旁边的边缘盒子上，延迟降到100毫秒以内。这就是边缘计算的价值——实时性、低带宽、隐私保护。

  核心观点： 边缘AI不是云端的替代品，而是互补品。适合的场景包括：实时推理（自动驾驶、工业质检）、数据敏感（医疗影像、人脸支付）、网络不稳定（野外监控、车载终端）。

把AI模型从云端搬到边缘，听起来简单，做起来全是坑。我总结了几条最头疼的：

算力受限： 云端有A100、V100，边缘端呢？RK3588的NPU算力也就6 TOPS，树莓派更是只有可怜的0.5 TOPS。模型稍微大一点，帧率直接掉到个位数。
内存瓶颈： 边缘设备通常只有2-8GB内存，而一个MobileNetV3模型就要几十MB。更别提多模型并行时的内存碎片问题。
功耗约束： 很多边缘设备是电池供电的，比如无人机、手持终端。你不能为了跑模型让设备十分钟就没电。
算子兼容性： 这是最隐蔽的坑。你在PC上用PyTorch训练好的模型，里面可能用了某个自定义算子。到了边缘端的NPU上，这个算子根本不支持。我曾经被这个坑过，一个模型在PC上跑得好好的，部署到RK3588上直接报错，查了两天才发现是某个激活函数不兼容。

避坑指南： 选模型时，尽量用边缘端NPU原生支持的算子。比如RK3588的NPU对ReLU、Conv2D、MaxPool支持很好，但对一些冷门算子（如Mish、Swish）可能要走CPU回退，性能会大打折扣。

好，问题摆在这了。怎么解决？市面上有很多推理框架，比如TensorRT、ONNX Runtime、NCNN、MNN。但我个人习惯用Tengine，原因有三：

跨平台统一API： 同一套代码，可以在ARM Linux、x86、Android、甚至MCU上编译运行。我不用为每个平台重写推理逻辑。
NPU原生加速： Tengine对RK3588的NPU、树莓派的VideoCore GPU都有深度优化。它能把模型的计算图自动切分，把能跑在NPU上的算子卸载到NPU，剩下的走CPU。
模型格式兼容： 支持TensorFlow、PyTorch、ONNX、Caffe等主流格式。你训练好的模型，几乎不用改就能导入Tengine。

说白了，Tengine就像一个「翻译官」+「调度员」。它把你的模型翻译成边缘端硬件能听懂的语言，然后调度CPU、GPU、NPU协同工作。

小提示： Tengine是开源框架，GitHub上可以直接拉代码。它的社区很活跃，遇到问题提issue一般当天就有回复。我个人觉得，它的文档质量在国产框架里算第一梯队。

这门课主要围绕两块开发板展开：RK3588和树莓派4B/5。为什么选它们？我列个对比表，你一看就明白。

我的建议是：如果你做产品原型，直接上RK3588。它的NPU能让你跑MobileNetV3-SSD这种模型达到30fps以上。如果只是学习验证，树莓派完全够用，但要做好心理准备——没有NPU，纯靠CPU推理，帧率会低很多。

我记得有一次帮客户做边缘盒子选型，他们一开始选了树莓派，结果发现跑YOLOv5s只有2fps，根本没法用。后来换成RK3588，直接干到25fps。所以选板子这件事，一定要先想清楚你的目标帧率和模型复杂度。

下面这张SVG图，把本章的核心知识点串起来了。你可以把它当作一个「思维导图」，后续每章都会围绕这个框架展开。

这一章我们聊了边缘AI的核心概念、边缘端的实际挑战、Tengine框架的优势，以及两块主流开发板的选型对比。说白了，边缘AI不是把云端的模型直接「搬」过来，而是要针对硬件特点做适配和优化。Tengine就是帮你做这件事的工具。